Informatica manageriala

Prezentare 5

‹1›
 4.3. Elemente ale analizei de sistem
Un management eficient implica existenta unui sistem
informational fiabil, în masura sa faca fata solicitarilor procesului
de decizie. Aparitia unor discordante în procesul de decizie,
furnizarea cu întârziere a informatiilor, nerealismul acestora,
aparitia unor conflicte ca urmare a existentei unor circuite
paralele a caror existenta încalca criteriile de confidentialitate
impuse, pot fi cauze ale începerii unor procese de proiectare
sau reproiectare a sistemului informational.
El consta, de fapt, în implementarea unui nou set de
proceduri de procesare a informatiei.

Cea mai importanta problema în proiectarea unui sistem

informational consta în descrierea sistemului, a celui deja
existent dar si a celui care urmeaza a fi introdus. Importanta
deriva din complexitatea sistemului informational, în care foarte
‹#›
putine componente se pot identifica cu usurinta.
Situatia aceasta este urmare a faptului ca în economia
româneasca nu exista un standard referitor la sistemele
informationale. Chiar un sistem bazat pe tehnologia computerelor
are un ciclu de viata limitat, la fel ca un organism viu sau ca un
produs nou lansat pe piata. Proiectarea unui sistem informational
nou este stimulata de nevoia de a perfectiona procedurile
existente sau de a obtine un avantaj competitiv din valorificarea
unei noi oportunitati.
Primul pas al acesteia îl constituie delimitarea sferei de cuprindere
a proiectarii, prin identificarea cauzelor care determina slaba
functionare a sistemului informational, în ansamblul sau sau a
partilor sale componente.

Delimitarea sferei de cuprindere se poate face cu ajutorul

tabelelor de determinare, care pot oferi o imagine a relatiilor de tip
cauza-efect în propagarea lor de la efectul final catre cauza
initiala. Odata delimitata sfera de cuprindere se poate trece la
‹#›
proiectarea propriu-zisa.
Analiza organizaţională – care urmăreşte evaluarea sistemelor
organizaţionale precum şi a mediului şi care, în general, implică un studiu
detaliat asupra:
1- mediului;
2- structurii managementului;
3- personalului;
4- business-ului;
5- sistemelor înconjurătoare;
6- sistemele informatice prezente.
Analiza sistemului existent – premergător elaborării unui nou sistem
trebuie făcută o analiză a sistemului prezent (manual sau informatic).
Aceasta analiză implică studiul activităţilor, resurselor şi produselor. Se mai
analizează modul în care sistemul actual utilizează:
- hardware, software, persoanele, convertirea lor în produse informatice;
- cum se efectuează introducerea, transmiterea, prelucrarea şi controlul
datelor.
Analiza necesităţilor patrimoniale – este o etapă importantă în care paşii
urmăriţi sunt:
1. Determinarea necesităţilor informaţionale;
2. Determinarea posibilităţilor prezente de prelucrare a
informaţiilor;
‹#›
3. Elaborarea unui necesar funcţional.
‹#›
Etapa de analiză contine operatii generale care nu depind de domeniul sistem
(economic, tehnic, medical, etc.)
Analiza de sistem constă în:
- elaborarea unui model static al sistemului prin evidentierea
componentelor structurii sistemului şi a relatiilor dintre acestea (tehnica
diagramelor);
- elaborarea unui model dinamic al sistemului prin evidentierea stărilor
sistemului şi a tranzitiilor posibile între aceste stări (tehnica grafurilor de
tranzitii, retele Petri sau Grafcet);
- elaborarea unui model functional al sistemului prin identificarea
cerintelor informationale din sistem prin recunoasterea fluxurilor prelucrărilor de
date dar si a zonelor unde informatia este deja prelucrată automatizat sau cel
putin stocată electronic si a unor posibile noi trasee informationale mai eficiente
ce rezultă direct din activitatea de analiză de sistem în perspectiva informatizării
întregii activităti a sistemului respectiv - scopul final urmărit;
- intergrarea modelelor obtinute anterior pentru obtinerea unor
informatii complete despre sistem cu orientare către cerintele informationale
proprii sistemului dar si ale decidentilor umani.
Analiza componentelor sistemului si a legăturilor dintre acestea precum
si analiza stărilor si tranzitiilor se poate face prin tehnica diagramelor entitate-
relatie,
‹#› prin identificarea relatiilor (legăturilor) între entităti si clasificarea
acestora în tipuri după gradul legăturii si după participarea la relatie.
 Din punctul de vedere al informaticianului care se află în faza de
proiectare a unei baze de date pentru o aplicatie complexă, secventa cea mai
importantă din etapa de analiză este elaborarea modelului functional care
presupune stabilirea cerintelor informationale ale sistemului.
Elaborarea modelului functional are drept scop determinarea
transformărilor de date care se produc în cadrul sistemului în scopul satisfacerii
cerintelor informationale. Transformările de date se prezintă sub forma unor
diagrame de flux a prelucrărilor, în care nodurile reprezintă procesele de
prelucrare a datelor şi arcele reprezintă fluxurile de informatie.
O secventă din modelul functional pentru prelucrarea globală a datelor
poate avea forma din figura .

‹#›
 Pentru elaborarea modelului functional, cel mai important
pentru o analiză corectă, trebuie parcurse următoarele etape:
- identificarea datelor globale de intrare;
- identificarea datelor globale de ieşire din sistem;
- descompunerea sistemului în componente functionale;
- elaborarea schemelor diagramelor de flux pentru legăturile dintre
intrările şi ieşirile fiecărei componente a sistemului;
- identificarea eventualelor restrictii asupra circulatiei informatiilor;
- cresterea eficientei fluxurilor informationale prin adăugarea,
modificarea si suprimarea unor componente ale acestora.
Integrarea modelelor static, dinamic şi functional ale
domeniului sistem se poate finaliza în obtinerea unei solutii de
optim între două variante extreme, fiecare având avantaje si
dezavantaje.
O primă abordare constă în obtinerea unui model puternic
dependent de aplicatii (în special modelul functional) iar cealală
se referă la modelarea complet independentă de aplicatii,
‹#›
costisitoare însă eficientă.
4.4. Proiectarea propriu-zisa
Design-ul sistemului – dacă analiza sistemului descrie ce fel
de sistem trebuie folosit pentru îndeplinirea scopului, design-ul
sistemului specifică cum sistemul îşi va atinge obiectivele.
Design-ul este constituit din specificaţii utilizate pentru:
- dezvoltare de softuri;
- achiziţia de hardware;
- testarea sistemului;
- alte activităţi legate de implementarea sistemului.
Totodată, design-ul sistemului are la bază trei activităţi:
- designul interfaţei cu utilizatorul;
- datele utilizate;
- procesul.
Fazele proiectarii
Procesul de proiectare, care este întâlnit în literatura de
specialitate si sub termenii de rationalizare sau reproiectare,
este un proces complex, care poate sa afecteze întreg
‹#›
sistemul sau parti componente ale sale.
 . Criteriul de baza al proiectarii consta în eliminarea redundantelor
informationale. Privit la nivelul întregului sistem al întreprinderii comerciale,
procesul de eliminare a redundantelor este orientat pe urmatoarele etape:

• analiza comparativa a componentelor structurii organizationale în

vederea identificarii unor subcomponente care au atributii functionale similare
sau identice; daca apar situatii de acest gen se impune o redimensionare a
subcomponentelor în cauza, pentru a se respecta criteriul unicitatii atributiilor
functionale;

• analiza a competentelor specifice fiecarei atributii functionale a

componentelor organizationale, cu scopul eliminarii paralelismelor în
exercitarea sarcinilor; criteriul care sta la baza acestei analize este criteriul
unicitatii competentelor iar rezultatul acestei analize îl constituie delimitarea
clara a granitelor dintre subdiviziunile organizatorice în procesul exercitarii
functiilor
‹#› lor;
 o analiza a activitatilor specifice fiecarei competente , cu eliminarea
redundantelor derivate din existenta unor activitati care servesc aceluiasi
obiectiv, dar care se gasesc pe niveluri diferite de competente sau
functionale; criteriul aplicat este acela al unicitatii activitatilor;
construirea unei diagrame de relatii care sa cuprinda, pe de o parte,
relatiile dintre activitatile specifice fiecarei competente functionale, iar pe de
alta parte, relatiile dintre activitati complementare, dar care se gasesc pe
niveluri de competenta functionale diferite (relatii dintre servicii diferite sau
birouri diferite); criteriul utilizat este cel al unicitatii relatiei, iar scopul este
acela al eliminarii relatiilor care ar putea sa genereze suprapuneri de circuite
informationale sau dublari de fluxuri;
reprezentarea grafica a circuitelor informationale specifice fiecarei relatii,
care este o activitate orientata catre definirea continutului fiecarei informatii, a
purtatorilor de informatii si a traiectoriilor acestora; criteriul utilizat este acela
al unicitatii locului producerii unei informatii, iar prin reproiectarea purtatorilor
de informatii se pot elimina eventualele informatii inutile sau eventualele
dubluri de informatii;
informatizarea sistemului informational astfel, îmbunatatit.
‹#›
 4.4.1. Fazele ciclului de viată al produselor software conform metodelor de
proiectare ” in cascada” si ” in fantana”
Odată cu aparitia si dezvoltarea programării calculatoarelor au existat
numeroase încercări de standardizare a procesului de elaborare a produselor software.
Aspecte specifice ce însotesc elaborarea programelor, au determinat renuntarea la
conceptul de programare "artisticã", dupã instinct si imaginatie si au dat nastere unor
încercãri de abordare sistemicã a problematicii elaborãrii aplicatiilor, conducând în mod
firesc la formularea unor noi concepte, principii, metode si instrumente de construire a
programelor, cunoscute si sub denumirea de inginerie software. Ingineria software
urmãreste în esentã rezolvarea unor probleme specifice legate de analiza, proiectarea,
implementarea, testarea si întretinerea programelor si anume:
Stabilirea etapelor si a sub-etapelor prin care trece secvential un produs software
pe durata ciclului sãu de viatã, definirea continutului acestor sub-etape precum si a
parametrilor de demarcare între sub-etapele si etapele succesive.

Elaborarea unor proceduri clare de organizare si conducere a diferitelor activitãti

legate de realizarea programului (calitate, performantã). Obiectivul final al ingineriei
software este trecerea de la o activitate de elaborare a programelor, în care domina stilul
artizanal, de intuitie si improvizatie, de creatie tip "artã a programãrii" la o activitate
sistematicã care sã asigure - asa cum am mai subliniat - înalta calitate a programelor si
un cost cât mai scãzut al elaborãrii si întretinerii acestora. Ingineria software se referã la
utilizarea în mod riguros, sistematic si cu profesionalism a unor metode si instrumente
software adecvate, având în vedere anumite obiective si principii de bazã.
‹#›
De aproape trei decenii modelul "în cascadă" pare să domine
lumea informaticii. Acest model constă din 6 etape succesive
utilizate pentru rezolvarea oricărui proiect informatic. Conform
modelului "în cascadă"', ciclul de viată al unui produs software
constă din:
1.definirea proiectului;
2. întocmirea caietului de sarcini;
3. proiectarea produsului;
4. implementarea programelor;
5. testarea produsului;
6. întretinerea setului de programe.

‹#›
 Definirea proiectului presupune o bună întelegere a problemei de rezolvat,
schitarea interfetei cu utilizatorul şi stabilirea posibilitătilor de comunicare cu alte
produse informatice. Pornind de la aceste informatii se trece la elaborarea unui caiet
de sarcini care trebuie să contină descrierea tehnică a proiectului şi un prototip al
viitorului manual de utilizare.
În urma încheierii acestor primi paşi se va trece la faza de proiectare a
produsului. Prin proiectare se întelege stabilirea structurilor de date cele mai potrivite,
găsirea algoritmilor optimali, împărtirea programului în module independente şi
stabilirea interfetelor de comunicare între acestea. Cu alte cuvinte, este o fază de
definire abstractă a modului de realizare a obiectivelor specificate în caietul de sarcini.
Implementarea constituie începutul activitătii de programare, care va
continua şi pe parcursul următoarelor etape. În această fază modelul abstract obtinut
în urma proiectării va fi transpus în practică cu ajutorul limbajelor de programare.
După implementarea setului de module, se trece la testarea individuală a fiecăruia
dintre ele. Apoi modulele vor fi interconectate în cadrul produsului final, care va fi la
rândul său supus unui set de teste cât mai complete. În urma obtinerii unei functionări
corespunzătoare se poate finaliza şi manualul de utilizare.

Etapa de întretinere are la rândul ei două faze distincte:

- eliminarea erorilor ce survin după comercializarea produsului;
- modificarea programului existent, astfel încât să tină cont de evolutia
cererilor pietei.
Pentru fiecare astfel de modificare se va aplica întreg setul de paşi mentionat.
‹#›
 Fig. 4.4. Modelul în cascadă pentru dezvoltarea produselor software
formularea obiectivelor
proiectului în funcţie de
cerinţele beneficiarului

stabilirea unui prim set de

specificaţii pornind de la
obiectivele identificate

definitivarea unui caiet

de sarcini

proiectarea logică
(proiectarea sistemului)

proiectarea fizică
( proiectarea
programului)

implementarea

testarea modulelor
independente

testarea sistemului ca un
tot unitar

intrarea în exploatare

întreţinerea

‹#›
 Gruparea fazelor ciclului de viată ale unui produs software sugerează
existenta a trei etape de bază: analiza, proiectarea şi implementarea.
Analiza constă în realizarea unui dialog eficient cu beneficiarul sau potentialul
utilizator al produsului software, în urma căruia să poată fi stabilit un set de facilităti pe
care le va contine produsul final. Faza de proiectare are drept scop crearea unui
schelet functional pe care să se bazeze programatorii la implementare. Acest schelet
va trebui să asigure protejarea informaţiilor, independenta modulelor si coeziunea
produsului final.
Modelul "în cascadă" al ciclului de viată al unui produs software este numai
un cadru general în jurul căruia orice echipă de programatori îşi poate clădi propria sa
metodologie dedicată. În funcţie de dimensiunea unui proiect, cele şase etape pot fi
detaliate mai amănuntit, sau concentrate într-un număr mai redus de paşi.
Un proiect de uz intern şi de mici dimensiuni ar putea fi rezolvat în numai patru etape:
- stabilirea caietului de sarcini;
- proiectarea produsului;
- implementarea programului;
- testarea codului programului scris.
Un exemplu detaliat a ciclului de viată a unui produs software include:
- stabilirea specificaţiilor;
- proiectarea preliminară;
- proiectarea detaliată;
- implementarea;
- testarea la nivel de module;
- integrarea modulelor în cadrul proiectului final;
‹#› - validarea produsului;
- exploatarea programului.
Pornind de la modelul " în cascadă " au fost create variante, unele numai prin
schimbarea terminologiei, altele aducând modificări mai importante. Aceste
modele au la bază avantajul simplităţii şi clarităţii si constau din definirea unui
număr de etape distincte si a unui set relativ stabil de cerinte de intrare si iesire
pentru fiecare etapă. Astfel se pot evita revenirile şi modificările haotice ale
rezultatelor unei etape anterioare.
Orice model însă are avantaje şi dezavantaje. O primă problemă
constă în asigurarea eficienţei comunicării între beneficiari şi analisti. Lipsa unui
limbaj comun accesibil specialiştilor din diverse domenii creează confuzii care
sunt clarificate tocmai după încheierea analizei şi întocmirea caietului de
sarcini. În cadrul proiectelor de mari dimensiuni, se poate întâmpla ca pe
parcursul dezvoltării produsului software specificaţiile initiale să se modifice în
urma evoluţiilor ştiinţifice sau tehnologice înregistrate în diverse domenii ale
industriei. Principalul avantaj al modelului " în cascadă " constă în
"industrializarea" procesului de dezvoltare a software-ului, iar principalul său
dezavantaj constă în faptul că nu asigură decât o comunicare unidirecţională.
Ideea care a stat la baza acestui model a fost încercarea de a evita revenirea şi
modificarea rezultatelor fazelor precedente. Datorită eficientei relativ scăzute a
dialogului cu beneficiarul, s-a făcut simţită necesitatea introducerii unui
mecanism puternic de feedback, care să optimizeze dialogul specialiştilor din
domenii
‹#› de activitate complet diferite. Astfel a apărut modelul "în cascadă"' cu
prototipuri. Acesta introduce un nou parametru din caietul de sarcini - prototipul.
Prototipul reprezintă un program care simulează functionarea produsului final. O
asemenea simulare este utilă deoarece dă posibilitatea viitorului beneficiar să testeze
interfaţa cu utilizatorul (user interface) şi să evalueze setul de facilităti pe care le va
oferi programul final. Aceste etape vor avea loc într-o fază initială a dezvoltării
produsului, astfel încât orice modificare să implice un cost minim.
Folosirea prototipurilor facilitează în mod evident realizarea unui dialog
eficient între informaticieni şi beneficiarii lor. Atât unii cât şi ceilalti vor avea ocazia să
vadă dacă au înteles şi au fost înteleşi corect.
Prototipurile contin însă două inconveniente: tendinta înlocuirii întregului ciclu
de viată al produsului software cu un prototip în continuă evolutie si tendinta utilizării
prototipului ca nucleu al viitorului produs. Prima abordare duce la o îndepărtare de la
rigurozitatea modelului " în cascadă " şi conduce, în cel mai bun caz, la o "programare
intuitivă '' iar în cel mai rău caz, la un blocaj total în procesul de dezvoltare a
programului. Cea de a doua problemă constă în mirajul unui produs aproape finalizat
(prototipul) şi în tentatia de a mai "aranja" putin prototipul pentru a-l transforma într-un
produs cu aspect comercial. O astfel de improvizatie va afecta în mult eficienta
programului deoarece prototipul nu este decât o cale de experimentare a ceea ce ar
trebui să însemne programul final.
Au apărut mai multe metodologii de dezvoltare a produselor software, bazate
pe diversele variante ale modelului " în cascadă " care propun tehnici de lucru
capabile să coordoneze eforturile făcute în cadrul etapelor ciclului de viată al
produselor software.
‹#›