Sunteți pe pagina 1din 12

Unitatea de studiu 3

Introducere în dezvoltarea sistemelor informaţionale

Obiective:
x Explicarea conceptului de ciclu de viaţă al sistemelor informaţionale
x Caracterizarea celor mai cunoscute modele ale ciclurilor de viaţă ale dezvoltării sistemelor informaţionale
x Crearea unei imagini generale asupra etapelor proiectului de dezvoltare a unui sistem
x Evidenţierea rolului economistului contabil în dezvoltarea sistemelor informaţionale
Competenţe dobândite:
x Organizarea principalelor activităţi ale unui proiect de dezvoltare a unui sistem informaţional
x Alegerea modelului de organizare a activităţilor conform caracteristicilor unui proiect de sistem
informaţional
x Stabilirea responsabilităţilor atribuite economiştilor contabili în cadrul sistemelor informaţionale
Timpul mediu necesar asimilării: 5 ore

Datorită existenţei unui context din ce în ce mai competitiv şi a unei lumi aflată în continuă
schimbare, firmele trebuie să facă faţă provocărilor prin căutarea de noi soluţii, bazate pe obţinerea rapidă
de informaţii. Pentru a răspunde acestei nevoi, sistemul informaţional trebuie supus unor modificări
continue, plecând de la mici ajustări sau adaptări până la schimbări substanţiale sau chiar înlocuirea lui.
Schimbările sunt atât de constante şi frecvente, încât majoritatea firmelor sunt într-un proces continuu de
îmbunătăţire sau transformare a sistemelor. Ele sunt nevoite să efectueze diferite modificări, cel puţin
datorită unuia dintre următoarele motive:
x ca parte a unui program mai amplu de modernizare a întregului sistem. Multe firme întreprind
o serie de proiecte pentru modernizarea tehnologiei de prelucrare a datelor – hardware, sisteme
de operare, programe utilitare, aplicaţii informatice. Un astfel de proiect este iniţiat, de obicei, ca
parte a intenţiei de a înlocui aplicaţiile vechi, centralizate, cu altele noi, bazate pe tehnologia
client/server sau a sistemelor distribuite;
x modificarea unor aspecte funcţionale de bază. Firmele îşi reproiectează procesele de bază fie ca
rezultat al efortului continuu de îmbunătăţire permanentă a activităţilor, fie mult mai radical, ca
efect al reproiectării proceselor economice;
x schimbarea obiectivelor strategice ale organizaţiei. De multe ori, firmele sunt nevoite să-şi
regândească nu numai modul în care îşi desfăşoară activităţile, dar şi ceea ce ar trebui să facă
pentru a rezista competiţiei. În unele cazuri, firmele de producţie se transformă în firme
prestatoare de servicii, producătorii primari devin unităţi de asamblare a componentelor realizate
de alţii, se modifică liniile lor de afaceri şi se reexaminează nevoile clienţilor. Marile firme se
lipsesc de propriile divizii şi linii de producţie, păstrând ceea ce consideră a fi nucleul de bază al
afacerii lor;
x nevoia creşterii performanţelor aplicaţiilor informatice, funcţionalităţii diferitelor caracteristici
de exploatare sau îmbunătăţirea interfeţelor utilizator. Pe măsură ce condiţiile economice se
schimbă, cerinţele utilizatorilor sunt din ce în ce mai mari, în ceea ce priveşte extinderea
funcţionalităţii sistemelor existente. Creşterea numărului utilizatorilor de calculatoare şi
dezvoltarea aplicaţiilor cu interfeţe grafice schimbă aşteptările acestora în ceea ce priveşte
toleranţa la erori;
x necesitatea accesării directe şi într-un timp cât mai scurt a fişierelor firmei. Majoritatea
utilizatorilor de staţii de lucru sau PC-uri au din ce în ce mai multe fişiere proprii. Datele din
aceste fişiere provin din informaţii prelucrate de utilizator, sunt transferate de pe calculatorul lui
pe alt calculator, cu ajutorul diferiţilor suporţi de stocare, al diferitelor mecanisme de transfer al
fişierelor. Aceste transferuri sunt mari consumatoare de timp şi destul de greoaie. De aceea,
utilizatorii doresc un acces la date mult mai performant;
x modernizarea sistemului pentru valorificarea avantajelor oferite de tehnologiile de ultimă oră.
Producătorii de hardware cresc performanţele produselor oferite, din punct de vedere al vitezei şi
al capacităţii de stocare şi prelucrare. Utilizatorii sunt în continuă căutare de noi instrumente
care să conducă la creşterea eficienţei activităţilor pe care le desfăşoară, solicitând tot mai multe
aplicaţii noi.
În concluzie, motivele pentru iniţierea unui proiect de dezvoltare a unui nou sistem informaţional
sunt legate de:
x rezolvarea unei probleme;
x obţinerea de avantaje de pe urma apariţiei unei noi oportunităţi;
x pentru a răspunde unor obiective definite prin planul strategic al organizaţiei sau prin planul
sistemului informaţional.
În acest capitol, vom aborda câteva aspecte esenţiale privind dezvoltarea sistemelor, ce vor fi
detaliate în următoarele capitole. Se vor prezenta diferitele modele ale ciclurilor de viaţă ale dezvoltării
sistemelor, precum şi etapele ciclului de dezvoltare.

3.1 Ciclul de viaţă al dezvoltării


sistemelor informaţionale
În acest paragraf dorim să surprindem doar o sintagmă esenţială în activitatea de analiză şi proiectare
a sistemelor, ciclul de viaţă al dezvoltării sistemelor (CVDS) sau ciclul dezvoltării sistemelor (CDS).
Încă de la început, facem menţiunea că, indiferent de etapa istorică sau metodologică, sistemele sunt
abordate prin prisma ciclului lor de viaţă. Ele apar, se dezvoltă, descresc şi pier sau, printr-un nou ciclu,
se perfecţionează, dând naştere unei alte versiuni sau chiar unui nou sistem. Nu prezenţa ciclului de viaţă
al dezvoltării sistemelor trebuie discutată, ci formele de regăsire a acestuia în timp, în funcţie de cadrul în
care se realizează sistemul. Mutaţiile din domeniul tehnologiilor informaţionale şi al metodelor de
abordare a sistemelor s-au reflectat şi în ciclul de viaţă al dezvoltării sistemelor, fie prin schimbarea
etapelor acestuia, fie prin modificarea opticii de parcurgere a lor.
Cu convingerea că sunt puţine persoanele care contestă nefondat iminenta prezenţă a ciclului de viaţă
al dezvoltării sistemelor în activităţile specifice dezvoltării/realizării sistemelor, vom încerca să punctăm
câteva dintre modelele concrete în care se poate regăsi acesta.
Ciclul de viaţă al dezvoltării sistemelor este „o metodologie comună de dezvoltare a sistemelor din
multe organizaţii, caracterizată prin câteva faze care marchează evoluţia eforturilor de analiză şi
proiectare a sistemelor”1. Fazele sau etapele ciclului de viaţă sunt greu de prezentat, nu numai ca nume, ci
şi ca număr.
Prin parcurgerea materialelor de specialitate, se poate constata că numărul fazelor variază de la trei
(de exemplu: analiză, proiectare, implementare) la peste douăzeci. Firesc, în cel de-al doilea caz, nici
simpla enumerare a lor nu este edificatoare. La un moment dat, se poate vorbi chiar de o „concurenţă” în
domeniu. Fiecare autor încearcă să fie original, fie prin schimbarea numărului de etape, fie prin
modificarea numelor acestora. Totuşi, s-ar putea formula o concluzie.
În fazele incipiente de abordare a sistemelor, numărul etapelor se situa la aproximativ şase. Ele erau
descompuse pe activităţi, subactivităţi, operaţiune firească, apreciem noi, datorită influenţei gândirii
bazate pe descompunerea funcţională, care era la modă.
Prin trecerea la orientarea-procese şi orientarea-date, considerăm că s-au înregistrat două fenomene:
a) diversificarea etapelor;
b) revizuirea modelului sub care se manifestă ciclicitatea.
Aşadar, se înregistrează apariţia, uneori, a peste douăzeci de etape.
Odată cu tehnicile de dezvoltare rapidă a aplicaţiilor, prin sistemul prototipizării sau RAD (Rapid
Application Development) , cu varianta europeană PD (Participatory Design), numărul fazelor/etapelor s-
a redus din nou, operându-se chiar schimbări ale numelor acestora2. James Martin enumeră următoarele
faze ale ciclului de viaţă RAD: planificarea cerinţelor, proiectul utilizatorului, construcţia,
finisarea/fasonarea. Dacă facem trimitere la cele şase etape regăsite în majoritatea opiniilor (analiza
sistemelor, achiziţia sistemelor, proiectarea conceptuală, proiectarea fizică, implementarea şi conversia,
exploatarea şi întreţinerea), se observă cu uşurinţă diferenţele dintre ele.
În legătură cu numărul şi numele etapelor ciclului de viaţă al dezvoltării sistemelor, se observă, la
sfârşitul anilor 1980 şi începutul anilor 1990, o tendinţă de preluare a unor etape specifice

1
. Hoffer, J.A., George, J.F., Valacich, J.S. – Modern Systems Analysis and Design, The Benjamin/Cummings Publishing
Company, Inc., Menlo Park, 1996, p. 22.
2
. Martin, J. – Rapid Application Development, Macmillan Publishing Company, New York, 1991.
managementului proiectelor. De exemplu, identificarea şi selecţia proiectului, planificarea şi iniţierea
proiectului (numite de unii specialişti etapele microanalizei) preced analiza, proiectarea logică, proiec-
tarea fizică, implementarea, întreţinerea. Apar şi alte puncte de vedere. Ele pot fi asociate curentului creat
de Yourdon prin lucrarea, din 1989, privind analiza modernă structurată.
Indiferent de numărul şi numele etapelor ciclului de viaţă al dezvoltării sistemelor, o problemă este
mult mai importantă, şi anume ordinea şi felul în care se parcurg etapele respective, referită sub numele
de modele ale ciclului de viaţă al dezvoltării sistemelor.
Datorită simplei enumerări a etapelor, se poate trage concluzia, la prima vedere, că ordinea lor este
secvenţială, ceea ce nu este confirmat de realitate. Revenirile la etapele anterioare sunt foarte dese,
sfidând secvenţialitatea. E drept că, uneori, etapele se pot derula secvenţial, alteori iterativ, cu posibili-
tatea revenirii la etapele anterioare, conform variantei sugerate de modelul cascadă, sau unele etape se pot
derula în paralel. Alţi specialişti văd ciclul de viaţă ca pe o spirală, alţii ca pe un proces circular.
Literatura ultimilor ani însă lansează şi alte modele, cum sunt: în V, în X, tridimensional, minge de
baseball (sau de oină), fântână arteziană, piramidă, pinball (bila magică) ş.a.
Datorită marii diversităţi a opiniilor, considerăm binevenită o descriere sumară a mai multor modele,
cu atât mai mult cu cât în literatura noastră subiectul de faţă are un tratament derizoriu, ca să nu fim şi
mai categorici şi să spunem că nu i se acordă importanţa cuvenită.

3.1.1 Modelul cascadă


Modelul cascadă este unul de referinţă, asigurând trecerea de la o etapă la alta – ce-i drept, mai mult
teoretică – în ordine secvenţială. Realitatea a demonstrat că parcurgerea etapelor/fazelor într-o astfel de
ordine nu este o regulă, întrucât, de cele mai multe ori, se înregistrează reveniri la etapele anterioare sau
parcurgerea în paralel a unora dintre ele.
Modelul este lansat la începutul anilor 1970 de către W.W. Royce3 şi constă într-o descompunere a
ciclului de viaţă în faze secvenţiale. La rândul lor, fazele sunt structurate pe activităţi şi subactivităţi.
Trecerea de la o etapă la alta se realizează după ce precedenta a fost parcursă în întregime. Modelul se
aplică la nivel de sistem; or, tocmai aici este punctul slab, întrucât sistemele complexe, cu un număr mare
de aplicaţii ce interacţionează între ele, sunt greu de controlat. Deşi nu este descurajată abordarea iterativă
a unor faze sau componente ale lor, restricţiile de timp impuse de programarea calendaristică a etapelor
limitează efectele benefice ale acesteia, ca şi posibilităţile de revenire la etape anterioare. Modelul este
redat în fig. 3.1.
Modelului i se recunosc unele avantaje, cum ar fi:
x un control total asupra fazelor, în sensul că ele sunt ordonate şi, firesc, previzibile, prin
evidenţierea clară a ariei de întindere a fiecărei etape sau subcomponentă a ei;
x este uşor de însuşit de către membrii echipelor de analiză şi proiectare, inclusiv de cei noi, cu o
experienţă mai puţin vastă;
x fiecare etapă este însoţită de o documentaţie perfect structurată (controlată).
Definirea
cerinţelor

Analiza

Proiectarea

Implementarea

Testarea

Utilizarea şi
întreţinerea

3
. Royce, W.W. – „Managing the Development of Large Software Systems”, in Proceedings of IEEE, WESTCON, San
Francisco, 1970. Reprinted in Proceedings of the 9th International Conference on Software Engineering, Monterey, 1987, pp.
328-338.
Fig. 3.1 Modelul cascadă
Ca dezavantaje, amintim:
x sistemul se predă doar după parcurgerea tuturor etapelor, ceea ce înseamnă o lungă perioadă de
timp, suficient ca utilizatorii să-şi schimbe pretenţiile;
x nu corespunde intenţiilor de abordare dinamică a sistemelor;
x nu este deschis schimbărilor ce pot interveni pe parcurs.
Într-un anumit fel, modelul este folosit de către Booch, în 1991, în proiectarea sa orientată-obiect
(OOD – Object-Oriented Design), în fazele de proiectare şi implementare, precum şi de către Ivar
Jacobson, în modelul OOSE (Object- Oriented Software Engineering), în 1992, acoperind toate etapele.
Am putea spune că şi aliatul ulterior al celor doi, Rumbaugh, foloseşte într-o formă oarecare valenţele
modelului cascadă, doar că ele se regăsesc într-un mod aparte în modelul V, utilizat parţial.
Ideea de bază a modelului este regăsită şi în altele, cum ar fi modelul X, fântână arteziană sau cel
incremental. Firesc, şi numai cronologic, dacă am face analiza acestora, ele ar trebui să fie mai
performante decât „strămoşul” lor.

3.1.2 Modelul V
Modelul V este, aşa cum am menţionat anterior, o variantă a modelului cascadă, prin care se introduc
conceptele de sistem şi componente (subsisteme), aplicându-se teste explicite la un sistem ierarhic pentru
creşterea controlului asupra modului în care se desfăşoară etapele. Tocmai această înlesnire constituie o
latură a literei V. Prima este latura din stânga, parcursă descendent, şi conţine etapele propriu-zise, iar cea
de-a doua latură, din dreapta, se parcurge ascendent, pe ea realizându-se verificările şi validările
elementelor create anterior.
Modelul, redat în figura 3.2, punctează cu mai multă claritate separările dintre ceea ce implică
participarea utilizatorului, modelul arhitectural şi cel al implementării. Utilizatorul este implicat doar în
fazele din partea superioară a V-ului. Arhitectura sistemului este surprinsă în partea de mijloc a literei, iar
partea inferioară a ei se referă la faza de implementare, care ar putea consta fie din asamblarea
componentelor software, fie din codificarea unor componente.
Modelul se pretează şi în mediul orientat-obiect, deoarece încurajează prototipizarea, reutilizarea
unor structuri superioare. El oferă un control puternic asupra sistemului în curs de realizare, prin
structurile ierarhice şi modulare pe care le promovează, ceea ce îl face utilizabil şi în cazul sistemelor
complexe. Modelul devine şi mai puternic dacă promovează iteraţia, adică reluarea unor faze, activităţi
sau subactivităţi. De fapt, acesta este stilul adoptat de cei trei autori ai UML – Unified Modeling
Language (Booch, Jacobson şi Rumbaugh), modelul iterativ-incremental, anunţat de anumite performanţe
ale modelului V.
Definirea
Validare
cerinţelor

Proiectare Testare
sistem sistem

Proiectare Testare
subsistem subsistem
(componentă) (componentă)

Codificare/
asamblare
componente

Fig. 3.2 Modelul V

În cadrul acestui model se face, de asemenea, distincţie evidentă între verificare şi validare. Prima se
referă la testarea sistemului, în diverse stadii ale lui, dacă s-a construit corect din punct de vedere logic, în
timp ce validarea va scoate în evidenţă faptul că sistemul, în forma lui finală, răspunde sau nu cerinţelor
iniţiale4. Tocmai din această cauză, i se reproşează că lasă validarea prea târziu, după ce sistemul s-a
construit, ceea ce îl face ineficient.
În forma lui consacrată, modelul îi aparţine lui Ould, care îl lansează în 1990, anumite forme fiind
folosite şi de Rumbaugh, încă din 1991. El utilizează doar latura din stânga V-ului, fazele descendente, în
care un loc esenţial revine tratării sistemului pe componente.
Cea mai vădită preluare a filosofiei modelului V este regăsită în modelul X (Hodgson, 1991).

3.1.3 Modelul incremental


Modelul incremental este o altă formă a celui cascadă. De fapt, în modul de descriere a etapelor
incipiente nici nu există vreo diferenţă faţă de modelul cascadă, întrucât atât definirea cerinţelor, cât şi
analiza se efectuează la nivelul întregului sistem. După acestea se efectuează descompunerea proiectului
în subproiecte, ele fiind urmărite pe activităţi care vor concura la obţinerea componentelor necesare
sistemului final. Aceasta este, de fapt, filosofia de bază a modelului. Faţă de modelul V, cel incremental
oferă posibilitatea atingerii scopului final în două variante: sistem global livrat la sfârşit sau componente
livrate distinct, conform figurii 3.3.
Din descrierea de până acum rezultă câteva dintre avantajele modelului:
x se încadrează în principiul arhicunoscut „divide et impera”, prin posibilitatea abordării unor părţi
ale întregului;
x sistemul poate fi livrat şi pe componente realizate la perioade scurte de timp;
x proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorită
modularizării lui.
Dintre dezavantaje pot fi enumerate:
x imposibilitatea aplicării lui în toate cazurile, uneori neexistând elementele necesare
descompunerii întregului;
x componentele pot fi realizate numai după ce întregului sistem i se defineşte arhitectura, totul
derulându-se după principiile metodei top-down, ceea ce înseamnă încă o condiţie dură:
cunoaşterea şi formularea cerinţelor din faza incipientă de abordare a sistemului;
x fiind posibil de realizat pe părţi, eforturile de integrare a acestora în întreg sunt destul de mari,
vorbindu-se chiar despre o aşa-zisă testare multiplă de sisteme, cu trimitere la faptul că, de fiecare
dată când se adaugă o nouă componentă, sistemul poate fi considerat unul nou.
Proiectare
Definirea componentă-1 Instalare
cerinţelor componentă-1

Analiză Implementare Întreţinere


componentă-1 componentă-1

Arhitectura
sistemului
Proiectare Instalare
componentă-n componentă-n

Implementare Întreţinere
componentă-n componentă-n

Fig. 3.3 Modelul incremental

Teste de autoevaluare
TA 3.1
1. Enumeraţi trei motive pentru modificarea sau dezvoltarea unui nou sistem
informaţional.
2. Care sunt dezavantajele modelului cascadă?
Răspuns:

4
. Vezi şi Sommerville, I. – Software Engineering, 1st Edition, Addison-Wesley, Reading, 1989.
3.2 Prezentarea generală a etapelor
ciclului de viaţă al sistemelor informaţionale
Pentru a avea o imagine generală asupra etapelor care se parcurg în dezvoltarea unui sistem
informaţional, plecând de la principiile metodologiei structurate şi ale ciclului de viaţă în cascadă, vom
face o trecere în revistă a principalelor obiective urmărite în cadrul fiecărei etape, urmând a fi detaliate în
capitolele ce urmează.
Dezvoltarea sistemului începe prin identificarea unei probleme, a oportunităţilor care impun un astfel
de proces, precum şi prin stabilirea obiectivelor noului sistem, urmând planificarea fiecărei activităţi şi a
resurselor solicitate, ceea ce se constituie în aşa-numita microanaliză a sistemului, după care au loc
celelalte etape de dezvoltare propriu-zisă, respectiv analiza, proiectarea, implementarea, exploatarea şi
întreţinerea, aşa cum rezultă din fig. 3.4.
A.
IDENTIFICAREA ŞI
SELECŢIA PROIECTULUI

MICROANALIZA

B. INIŢIEREA ŞI
PLANIFICAREA
PROIECTULUI
FA
ZE
LE

C.
CI
CL

ANALIZA
UL
UI
DE
VI

Ă

D.
AL
DE
TREI ACTIVITĂŢI PRINCIPALE

PROIECTAREA LOGICĂ
ZV
OL

RI
IS
IST

E.
EM

PROIECTAREA FIZICĂ
EL
OR

F.

IMPLEMENTAREA

G.

ÎNTREŢINEREA

1. Identificarea potenţialelor proiecte de dezvoltare

2. Clasificarea şi ierarhizarea proiectelor

3. Selecţia proiectelor de dezvoltare

Fig. 3.4 Ciclul de viaţă al dezvoltării sistemelor


Etapa de microanaliză a proiectului are drept ţintă stabilirea unei strategii generale de dezvoltare a
sistemului informaţional la nivelul întregii firme, identificarea celor mai importante proiecte care ar trebui
desfăşurate în următoarea perioadă de timp, selectarea unuia sau mai multora dintre ele, în funcţie de
resursele de care dispune firma, dar şi de efectele sau urgenţa implementării lor, planificarea activităţilor
proiectului selectat, a resurselor necesare, elaborarea studiilor de fezabilitate.
După selecţia proiectului, cea mai importantă activitate o constituie definirea clară a problemei şi a
scopului pentru sistemul cerut, în sensul că trebuie să se înţeleagă ce se întâmplă la nivelul firmei, ce
obiective are firma şi cum noul sistem poate conduce la atingerea lor. În această etapă, nu se vor cunoaşte
toate funcţiile şi procesele de prelucrare de inclus în sistem, dar este important să se identifice exact care
sunt avantajele pe care le aduce noul sistem, ce activităţi economice sprijină şi ce probleme pot fi
rezolvate cu ajutorul lui.
Activităţile de planificare şi alocare a resurselor sunt strâns legate între ele, presupunând evidenţierea
clară a sarcinilor, activităţilor şi personalului necesar. Proiectele mari solicită elaborarea unor planificări
riguroase, cu jaloane şi proceduri de control specifice fiecărei etape sau fiecărui grup de activităţi.
Următorul pas îl constituie determinarea fezabilităţii. Multe proiecte sunt iniţiate ca parte a unui plan
strategic de dezvoltare a sistemului informaţional la nivelul întregii firme, în cadrul căruia pentru fiecare
proiect este necesar să se demonstreze că este cu adevărat necesar şi că se justifică eforturile depuse
pentru finalizarea lui. Analizele de fezabilitate urmăresc aspectele financiare, juridice, operaţionale,
tehnice şi de timp pentru a stabili dacă proiectul poate fi continuat sau nu, în funcţie de resursele
solicitate, perioada necesară recuperării investiţiilor, beneficiile cantitative şi calitative pe care le aduce,
modul în care răspunde obiectivelor firmei.
În final, planul de dezvoltare a sistemului este supus spre analiză conducerii. Dacă se obţine
aprobarea, proiectul poate fi iniţiat, în sensul că vor fi alocate fondurile necesare, se va organiza echipa de
dezvoltare şi vor fi puse la dispoziţie toate celelalte resurse solicitate, cum ar fi instrumentele de
dezvoltare, birourile, echipamentele.
După ce planul iniţial al proiectului a fost finalizat, se merge mai departe cu etapa de analiză, prin
care se urmăreşte identificarea şi documentarea cerinţelor funcţionale şi a celor informaţionale ale noului
sistem. Cuvintele cheie ale acestei etape sunt identificare şi înţelegere5, care presupun studierea sistemului
existent, determinarea cerinţelor pentru noul sistem, ierarhizarea cerinţelor, generarea şi evaluarea
variantelor de proiectare, elaborarea documentaţiei de analiză, evaluarea proiectului şi soluţiilor
identificate pentru a obţine aprobarea necesară continuării cu etapa de proiectare.
Culegerea informaţiilor se desfăşoară pentru a înţelege cât mai bine domeniul problemei, nevoile
informaţionale ale utilizatorilor, cunoaşterea în detaliu a modului în care funcţionează actualul sistem, în
sensul identificării celor 5 C6:
1. Ce persoane sunt afectate de actualul şi noul sistem?
2. Ce activităţi economice realizează fiecare dintre persoanele identificate?
3. Care este mediul în care se desfăşoară activităţile economice?
4. Care sunt momentele în care au loc procesele de prelucrare a datelor generate de activităţile
economice?
5. Ce presupune realizarea procedurilor din sistemul curent?
Din obţinerea răspunsurilor la cele cinci întrebări se poate identifica modul cum funcţionează
actualul sistem, scopul lui, punctele tari care trebuie păstrate în noul sistem şi cele slabe care ar trebui
eliminate sau înlocuite.
Analiza sistemului este o activitate esenţială în aflarea situaţiei existente şi a ceea ce se doreşte în
viitor. Informaţiile privind sistemul curent şi cerinţele pentru noul sistem se pot obţine prin intermediul
mai multor tehnici, cum ar fi observarea a ceea ce fac utilizatorii, intervievarea lor sau sondarea pe bază
de chestionare, analiza documentelor şi a procedurilor de lucru, a regulilor economice şi a
responsabilităţilor fiecărui loc de muncă care este influenţat sau influenţează funcţionarea sistemului, a
documentaţiei sistemul informatic existent. Pe lângă utilizatorii sistemului, este necesar să se culeagă
informaţii şi de la alte persoane interesate, respectiv reprezentanţii conducerii tactice şi strategice,
partenerii de afaceri, finanţatorii proiectului. De asemenea, se poate apela şi la ceea ce se întâlneşte sub
denumirea de metode moderne de culegere a cerinţelor, respectiv sesiunile JAD (Joint Application
Design) , sistemele de sprijinire a grupurilor de lucru, prototipizarea şi RAD (Rapid Application
Development) .

5
. Satzinger, J.W., Jackson, R.B., Burd, S.D. – op. cit., p. 36.
6
. Kendall, K.E., Kendall, J.E. – op. cit., p. 12.
Dar nu este suficientă simpla culegere a informaţiilor. Analiştii trebuie să le revizuiască, analizeze şi
structureze astfel încât cerinţele noului sistem să fie uşor înţelese. Această activitate este cunoscută sub
numele de structurarea cerinţelor şi implică construirea unor modele specifice: modelul proceselor,
modelul logicii proceselor şi modelul conceptual al datelor.
Obiectivul creării modelelor este de a transpune sub formă de diagrame principalele componente ale
sistemului (procese de prelucrare, intrări, ieşiri, locuri de stocare a datelor). Pe baza lor se construieşte un
aşa-zis dicţionar (depozit) al metadatelor, prin care sunt surprinse toate detaliile privind elementele
regăsite în diferitele modele create. De exemplu, se descrie formatul fluxurilor de date (tipul atributelor pe
care le conţin, mărimea lor, momentul în care se obţin sau sunt supuse proceselor de prelucrare ş.a.m.d.).
Atunci când apar restricţii de fonduri sau resurse, unele cerinţe identificate nu vor putea fi cuprinse
în noul sistem, ceea ce înseamnă că echipa de dezvoltare, împreună cu utilizatorii şi reprezentanţii
conducerii, trebuie să stabilească o ierarhie a lor, iar, mai departe, se identifică diferite soluţii de
proiectare a sistemului: dezvoltarea în interiorul firmei, cumpărarea unui pachet software existent pe
piaţă, externalizare. Soluţiile sunt supuse atenţiei conducerii, urmând să fie aleasă cea care răspunde cel
mai bine analizelor cost/beneficiu.
În finalul etapei de analiză, se pregăteşte o documentaţie necesară proiectării, prin care sunt
surprinse toate aspectele privind modul de funcţionare a sistemului curent, căror nevoi şi cerinţe trebuie
să răspundă noul sistem, ce funcţii trebuie să cuprindă şi ce obiective trebuie să sprijine.
În etapa de proiectare logică se urmăreşte dezvoltarea arhitecturii sistemului, pregătirea
specificaţiilor de proiectare a ieşirilor, intrărilor, bazelor de date, interfeţelor-utilizator, controalelor şi
procedurilor de realizare a copiilor de siguranţă, programelor etc., independent de platformele pe care
urmează să fie instalat sistemul. Aceste activităţi se bazează pe utilizarea informaţiilor culese şi a
modelelor create în timpul analizei.
Proiectarea logică se derulează prin intermediul a trei paşi sau subfaze:
x proiectarea formularelor/formatelor (pentru preluarea datelor) şi a rapoartelor, prin
intermediul cărora utilizatorii vor avea imaginea intrărilor şi ieşirilor noului sistem;
x proiectarea interfeţelor şi a dialogurilor, pentru evidenţierea modului de comunicare a
utilizatorului cu programele şi echipamentele;
x proiectarea logică a bazelor de date, prin care este descrisă structura standard a bazei de date a
sistemului, ce va fi uşor de implementat prin multitudinea de tehnologii existente în acest
domeniu.
Toate intrările şi ieşirile vor fi prezentate, în etapa proiectării logice, ca fluxuri ale datelor între
procesele de prelucrare sau între o sursă/destinaţie şi un proces, aşa cum au fost redate în diagramele
fluxurilor de date. De regulă, se poate proiecta câte un formular sau raport pentru fiecare flux de date.
Totuşi, punctul de plecare în modelarea logică îl constituie diagramele entitate-relaţie, deşi, în plus,
vor fi utilizate nu numai datele din acestea, ci şi cele descoperite în timpul proiectării logice. Similar, din
diagrama de acţiuni vor fi preluate evenimentele ce declanşează acţiunile utilizatorului, semnalate prin
meniuri, butoane, comenzi date calculatorului.
De menţionat că subfazele acestei etape nu trebuie să fie parcurse secvenţial, ele aflându-se într-o
strânsă interdependenţă.
După parcurgerea etapei de proiectare logică, în multe metodologii cunoscută şi ca proiectare
conceptuală sau, adesea, mai simplu, proiectarea sistemelor, o formulare destul de ambiguă, se trece la o
nouă etapă, proiectarea fizică, la rândul ei numită şi proiectare de detaliu. Ultimul nume este în legătură
cu proiectarea generală, o altă variantă de definire a proiectării logice. De fapt, printr-o astfel de referire
se scoate în relief faptul că în timpul proiectării logice se prezintă o imagine de ansamblu (generală) a
sistemului, în timp ce proiectarea fizică înseamnă o abordare detaliată a acestuia. Cu alte cuvinte, în etapa
de proiectare logică se acumulează informaţiile de natură să sintetizeze cerinţele utilizatorilor noului
sistem, operaţiune prestată de analiştii de sistem, iar în timpul proiectării fizice se prezintă punctele de
vedere ale specialiştilor, cum ar fi cei din domeniile bazelor de date, securităţii sistemelor, reţelelor de
calculatoare, controlului şi auditării sistemelor, programării ş.a. – pe scurt, ale tehnicienilor. Ca atare, şi
specificaţiile acestei etape nu vor avea un pronunţat caracter tehnic, preocupările fiind îndreptate spre
schiţarea structurii sistemului, şi nu spre modul concret de realizare a lui.
Proiectarea fizică implică parcurgerea următorilor paşi:
1. proiectarea fişierelor fizice şi a bazelor de date. O astfel de activitate înseamnă descrierea
modului în care vor fi stocate şi accesate datele în/din memoriile secundare şi cum se va asigura
controlul lor pentru a se oferi o securitate maximă.
2. proiectarea arhitecturii programelor. Se descriu programele sau modulele acestora care să fie în
strânsă concordanţă cu diagramele fluxurilor de date şi cu celelalte piese ale documentaţiei
realizate în etapele anterioare.
3. proiectarea strategiilor de prelucrare distribuită. Se vor prezenta modalităţile în care
utilizatorul poate să dispună de datele şi facilităţile de prelucrare oferite de reţelele de
calculatoare.
Cum etapa care urmează este implementarea, orice situaţii care nu convin specialiştilor trebuie să fie
rezolvate în timpul proiectării fizice, evitându-se cheltuielile suplimentare, mult mai mari, care ar putea să
apară după această etapă.
În timpul etapei de implementare, sistemul este construit, testat şi instalat. Obiectivul activităţilor
specifice nu este numai de asigurare a funcţionării sistemului, în concordanţă cu nevoile identificate, ci şi
a faptului că utilizatorii sunt instruiţi astfel încât firma să beneficieze de rezultatele prevăzute prin
exploatarea corespunzătoare a acestuia. Principalele activităţi care se desfăşoară în cadrul etapei sunt:
x realizarea şi testarea programelor;
x conversia sistemului prin înlocuirea vechilor proceduri şi a datelor în formatul cerut de noul
sistem;
x instalarea sistemului, prin care echipamentele sunt plasate în configuraţia proiectată, softul de
sistem şi de aplicaţii este instalat pe echipamente;
x instruirea utilizatorilor pentru oferirea tuturor explicaţiilor şi cunoştinţelor necesare exploatării
sistemului la parametrii la care a fost proiectat;
x elaborarea documentaţiei sistemului şi a manualelor de utilizare, exploatare şi întreţinere.
În final, sistemul se poate considera a fi funcţional, dar el trebuie supus revizuirilor periodice pentru
a se asigura întreţinerea acestuia, fie pentru corectarea eventualelor erori apărute în exploatarea lui, fie
pentru îmbunătăţirea caracteristicilor sau funcţiilor, ca răspuns la modificarea unor cerinţe
organizaţionale. Această etapă este, de obicei, cea mai costisitoare, având în vedere că timpul pe care şi-l
petrec specialiştii din departamentele informatice repezintă cam 48-60% din totalul timpului alocat pentru
dezvoltarea sistemului7.
Din punct de vedere al derulării unui proiect, fazele de identificare şi selecţie, iniţiere şi planificare a
proiectelor reprezintă microanaliza sistemului informaţional, complementată cu faza de analiză.
Proiectarea şi implementarea se referă la execuţia propriu-zisă a proiectului. Terminarea proiectului este
etapa care reliefează modalitatea de finalizare a acestuia, care poate fi una naturală, normală, de închidere
a proiectului, sau una nenaturală, impusă sau forţată atunci când se constată că nu se poate merge mai
departe (încă din faza de selecţie a proiectelor) sau când scopul pentru care a fost realizat sistemul a
dispărut.

3.3 Participanţii la dezvoltarea


sistemelor informaţionale
Dezvoltarea sistemelor presupune efortul unei echipe, mai mari sau mici, în funcţie de complexitatea
şi dimensiunea proiectului. Echipa are responsabilitatea determinării obiectivelor sistemului şi a
construirii lui, astfel încât funcţionarea lui să conducă la atingerea lor, la rezolvarea problemelor
economice sau exploatarea oportunităţilor care au stat la baza iniţierii proiectului.
Echipa are un manager de proiect, care coordonează eforturile de dezvoltare cu ajutorul diverselor
mijloace şi tehnici specifice managementului proiectelor. Alături de managerul de proiect, în echipa de
dezvoltare sunt incluşi stakeholder-ii (persoanele afectate, direct sau indirect, de dezvoltarea sistemului,
cum ar fi beneficiarii sau finanţatorii proiectului), utilizatorii sistemului, specialiştii în dezvoltarea
sistemelor, reprezentanţi ai conducerii şi alte categorii de persoane ce sprijină activităţile ciclului de viaţă
al sistemului.
Managerul de proiect are responsabilitatea coordonării resurselor umane, gestionării fondurilor
financiare şi a celorlalte resurse, finalizarea la timp a proiectului, stabilirea planurilor de comunicare între

7
. Kendall, K.E., Kendall, J.E. – op. cit., p. 14.
membrii echipei, a momentelor şi modului de monitorizare şi evaluare a derulării proiectului. În plus,
pentru asigurarea finalizării la timp a proiectului şi în bugetul alocat, managerul de proiect are ca
responsabilitate şi controlul calităţii proiectului, managementul riscurilor, gestiunea contractelor de
achiziţie.
El poate fi o persoană din cadrul departamentului informatic, un reprezentant al utilizatorilor sau un
consultant extern, angajat pe perioada proiectului. Indiferent de unde provine, managerul de proiect
trebuie să deţină competenţe economice, tehnice şi tehnologice, de gestiune a resurselor umane.
Stakeholder-ii sunt persoane care, direct sau indirect, beneficiază de proiectul de dezvoltare a
sistemului. Metodologiile moderne apelează din ce în ce mai mult la participarea activă, în procesul de
dezvoltare a sistemului, a beneficiarilor şi altor persoane interesate.
Utilizatorii sunt acele persoane care vor interacţiona direct şi în mod curent cu sistemul, putând fi
angajaţii firmei, managerii sau partenerii firmei. Utilizatorii au diferite roluri în timpul proiectului:
x sunt cei care explică modul de funcţionare a sistemului curent şi formulează nevoile şi cerinţele
informaţionale pentru cel nou;
x participă la evaluarea rezultatelor fiecărei etape din ciclul de dezvoltare al sistemului, oferind
feedback-ul de care au nevoie specialiştii pentru completarea, modificarea sau înţelegerea mai
bună a ceea ce trebuie să facă sistemul;
x controlează şi monitorizează periodic evoluţia proiectului;
x participă la testarea sistemului.
Pentru sistemele complexe, în care investiţiile şi valoarea dezvoltării sistemului sunt mari, este
benefic să existe în echipă şi un reprezentant al managementului strategic sau tactic, pentru că un prim
semnal de acceptare a noului sistem vine de aici. Din acest punct de vedere, cel mai important rol al
conducerii este de a sprijini şi încuraja proiectele de dezvoltare a sistemelor şi de aliniere a lor la
strategiile firmei. De asemenea, ei participă la stabilirea scopului şi obiectivelor sistemului, analiza
performanţelor înregistrate de departamentul informatic, selectarea proiectelor propuse şi a politicilor
privind luarea celor mai importante decizii legate de dezvoltarea sistemelor.
Din punct de vedere al calităţii de utilizatori ai sistemului, managerii participă la definirea cerinţelor
informaţionale pentru proiectele departamentelor pe care le coordonează, asistă analiştii în estimarea
costurilor şi beneficiilor, alocă membrii-cheie în echipele de dezvoltare a sistemelor, ca şi fondurile
necesare dezvoltării şi exploatării lor.
Din categoria specialiştilor în dezvoltarea sistemelor informaţionale, echipa proiectului ar putea avea
în componenţă analişti de sistem, proiectanţi, programatori, administratori de reţea.
Analiştii de sistem, în prima etapă a ciclului de viaţă, participă la identificarea oportunităţilor şi
obiectivelor sistemului, după care determină cerinţele informaţionale ale utilizatorilor şi asigură
modelarea acestora cu ajutorul diferitelor tehnici pe care le au la dispoziţie. Ei sunt cei care trebuie să
asigure cele două concepte de bază ale etapei de analiză: identificare şi înţelegere. De capacitatea lor de a
surprinde toate aspectele relevante ale sistemului curent şi ale celui nou, de a înţelege modul de
funcţionare, depind celelalte etape de dezvoltare şi, ca urmare, succesul implementării şi exploatării
noului sistem. În finalul etapei de analiză, ei sunt responsabili cu elaborarea specificaţiilor necesare etapei
de proiectare. Pentru că sunt mai apropiaţi de utilizatori, analiştii asigură legătura dintre aceştia şi ceilalţi
specialişti, legătură esenţială pentru reuşita sistemului, pentru că, de cele mai multe ori, proiectanţii şi
programatorii folosesc un limbaj tehnic, ce nu este la îndemâna şi pe înţelesul utilizatorilor. Acest lucru
face mult mai dificilă comunicarea dintre ei şi ar putea să afecteze reflectarea cerinţelor utilizatorilor în
proiectarea şi implementarea a sistemului. Nu în ultimul rând, analiştii participă la testarea şi conversia
sistemului, fiind cei care ştiu cel mai bine particularităţile domeniului economic căruia sistemul trebuie
să-i răspundă, precum şi la elaborarea documentaţiei finale şi a manualelor de utilizare.
Proiectanţii asigură transpunerea cerinţelor sistemului sub forma procedurilor de prelucrare, prin
apelarea la tehnici şi principii specifice proiectării interfeţelor-utilizator, bazelor de date, programelor. Tot
ei sunt cei care proiectează procedurile de control şi de asigurare a securităţii sistemului, realizând şi
specificaţiile necesare etapei de implementare. Calitatea de proiectant poate fi deţinută de proiectanţi ai
interfeţelor, administratori şi proiectanţi de baze de date, chiar şi de către analiştii de sistem.
Programatorii modifică sau dezvoltă programele pentru satisfacerea cerinţelor utilizatorilor,
preluând specificaţiile de proiectare pentru a dezvolta arhitectura programelor şi pentru scrierea efectivă a
codului sursă al acestora, apelând la limbaje de programare convenţionale, la generatoare de coduri sau la
limbaje orientate-obiect. De asemenea, ei participă la activităţile de testare pentru a se asigura că
programele rulează fără erori sau că nu au fost omise anumite funcţii sau proceduri. Un rol important le
revine în timpul exploatării şi întreţinerii sistemului, atunci când trebuie să intervină pentru eliminarea
anumitor erori neidentificate până la exploatarea sistemului, îmbunătăţirea unor componente sau
adăugarea unora noi.
Administratorii de reţea sunt implicaţi în dezvoltarea arhitecturii sistemului, în situaţia în care acesta
presupune o extindere la nivelul întregii organizaţii, participând la etapa de proiectare, prin definirea
proiectului de reţea, la etapa de implementare, asigurând configurarea reţelei necesare rulării programelor
şi exploatării bazelor de date în regim distribuit, astfel încât să se asigure accesul utilizatorilor la
informaţiile solicitate şi la care au drept de acces, indiferent de poziţia lor geografică.

3.4 Răspunsuri la testele de autoevaluare


TA 3.1 1) modificarea unor aspecte funcţionale de bază, schimbarea obiectivelor strategice ale
organizaţiei, modernizarea sistemului pentru valorificarea avantajelor oferite de tehnologiile de ultimă
oră. 2) perioada mare de timp pentru dezvoltare; nu corespunde intenţiilor de abordare dinamică a
sistemelor; nu este deschis schimbărilor ce pot interveni pe parcurs.

3.5 Lucrare de verificare


A. Alegeţi varianta/variantele corectă/e de răspuns:
1) Care dintre elementele de mai jos reprezinta modele ale ciclului de viata:
a) modelul cascada
b) modelul Intranet
c) modelul D
d) modelul UML
2) Utilizatorii pot fi implicati in urmatoarele activitati de dezvoltare a sistemului informational:
a) determinarea cerintelor noului sistem
b) scrierea programelor
c) proiectarea fizica a datelor
d) testarea programelor si a sistemelor
3) In cadrul etapelor ciclului de viata al sistemelor informationale se regasesc:
a) initierea si planificarea proiectului
b) analiza logica a sistemului
c) analiza fizica a sistemului
d) proiectarea logica a sistemului
e) proiectarea fizica a sistemului
f) implementarea sistemului

B. Răspundeţi la următoarele întrebări şi probleme:


1. Definiţi ciclul de viaţă al dezvoltării sistemelor informaţionale.
2. Care sunt obiectivele urmărite prin fiecare etapă a ciclului de viaţă al sistemelor?
3. Enumeraţi principalii membri ai unei echipe de dezvoltare a unui sistem informaţional.
4. Descrieţi rolul fiecărui membru al echipei de dezvoltare în cadrul principalelor etape ale
ciclului de viaţă.
5. Presupuneţi că faceţi parte dintr-o echipă desemnată pentru desfăşurarea unui proiect de
dezvoltare a unui sistem, prin care se va automatiza o parte din activităţile de producţie ale
unei firme. Pentru echipă sunt clare o serie de aspecte: automatizarea modului de urmărire a
activităţilor de producţie şi a stocului de produse finite. Ce nu este clar pentru echipă:
impactul sistemului asupra salariaţilor de la producţie; gradul de instruire de care vor avea
nevoie; dacă noul sistem va determina o creştere a productivităţii lor; cât de receptivi vor fi
la implementarea noului sistem.
În acelaşi timp, echipa recunoaşte că e posibil ca salariaţii să aibă anumite soluţii în ceea
ce priveşte încorporarea anumitor elemente în noul sistem. De asemenea, mulţi dintre
specialiştii echipei nu cunosc destul de bine particularităţile activităţii de producţie, dar au
mai lucrat la un sistem privind gestiunea stocurilor.
Se cere să se găsească răspunsuri la următoarele întrebări, aducând şi argumentarea
necesară:
x Sistemul propus este un sistem de gestiune a stocurilor, de producţie sau unul care le
cuprinde pe amândouă?
x Ce model al ciclului de viaţă ar trebui să abordeze echipa de dezvoltare?
x Care sunt activităţile proiectului în care ar trebui să fie implicaţi salariaţii de la producţie?

3.6 Bibliografie
1. Hoffer, J.A., George, J.F., Valacich, J.S. – Modern Systems Analysis and Design, The
Benjamin/Cummings Publishing Company, Inc., Menlo Park, 1996, p. 20-28
2. Oprea, D., Meşniţă, G., Dumitriu, F., Analiza sistemelor informaţionale, Ed. Universităţii “Al. I.
Cuza” Iaşi, 2005, pp. 151-173, 188-198
3. Satzinger, J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World,
Course Technology, Thomson Learning, Boston, 2002, p.34-45

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