Sisteme In Format Ice de Gestiune

Cristian Georgescu

SISTEME INFORMATICE DE GESTIUNE

Sisteme informatice de gestiune

pagina 4


pagina 5

CUPRINS 1.Abordarea sistemica 1.1.-Sistem; noţiuni generale 1.2.-Conceptul de analiză sistemică 2.Sisteme informaţionale 2.1.-Comunicarea în sistemele informaţionale 2.2.-Fluxuri de informaţii 2.3.-Locul şi rolul sistemului informaţional 3.Sisteme informatice 3.1. -Definire 3.2. -Ciclul de viaţă al unui sistem informatic 4.Metoda MERISE 4.1. –Prezentare 4.2. –Ciclul de viaţă

4.2.1. –Elaborarea temei de realizare a sistemului informatic

4.2.2. –Proiectarea logică 4.2.3. –Proiectarea tehnică 4.2.4. –Elaborarea programelor 4.2.5. –Implementarea, exploatarea şi

întreţinerea 4.3. –Ciclul de abstractizare 4.3.1. -Modelul conceptual al datelor 4.3.2. –Modelul logic al datelor 4.3.3. –Modelul fizic al datelor 4.3.4. –Modelul conceptual al comunicaţiilor 4.3.5. –Modelul conceptual al prelucrărilor 4.3.6. –Modelul organizaţional al prelucrărilor 4.3.7. –Modelul operaţional al prelucrărilor 4.4. –Ciclul de decizie 5.Abordări orientate spre date şi spre prelucrări Bibliografie


pagina 6

1. ABORDAREA SISTEMICĂ 1.1. Sistem; noţiuni generale Conceptul de sistem apare în forme embrionare în filosofia antică greacă. Afirmând că "întregul este mai mult decât suma păţilor", Aristotel dă o primă definiţie noţiunii de sistem care se va dezvolta şi va evolua timp de peste 2000 de ani pentru a ajunge la forma actuală abia la începutul secolului XX. Cel care începe închegarea unei teorii privind sistemele este biologul german L. von Bertalanffy care între 1928 şi 1950 publică o serie de lucrări ce postulează că "universul este organizat în sisteme şi ansambluri de elemente aflate în interacţiune" şi care reprezintă începuturile teoriei generale a sistemelor. Economistul american E. Boulding pune bazele teoriei sistemelor în 1956, teorie reluată şi dezvoltată de atunci de foarte mulţi cercetători. Un sistem poate fi definit ca o secţiune a realităţii în care se identifică un ansamblu de fenomene, obiecte, procese, fiinţe sau grupuri, interconectate printr-o mulţime de relaţii reciproce, precum şi cu mediul înconjurător şi care acţionează în comun în vederea realizării unor obiective bine definite. Caracteristic pentru noţiunea de sistem este posibilitatea ca ansamblul de elemente componente ale sistemului să poata fi divizat în subsisteme. Structurarea sistemului în subsisteme se face după reguli stabilite în funcţie de scopul urmărit.


pagina 7

Mulţimea relaţiilor dintre componentele unui sistem precum şi relaţiile între componente şi ansamblu formează structura sistemului, iar mulţimea caracteristicilor unui sistem, la un moment dat, determină starea sa. Relaţiile dintre elemente se analizează observând şi studiind logic funcţiile şi mecanismele lor individuale. După precizarea acestor funcţii şi mecanisme, orice soluţie avută în vedere poate fi evaluată pentru întregul sistem, tinând seama de diverse criterii de eficienţă şi de restricţiile practice asociate elementelor funcţionale. Elementele unui sistem pot avea relaţii între ele (relaţii endogene) cât şi relaţii cu mediul înconjurător (relaţii exogene). Ca urmare, pentru a caracteriza noţiunea de sistem este necesar să punem în evidenţă următoarele 5 laturi: • mulţimea elementelor • relaţiile între elemente -relaţii endogene • intrările şi ieşirile în şi din sistem-relaţii exogene • caracterul variabil în timp al elementelor sistemului • scopul, finalitatea sistemului Pentru descrierea unui sistem şi a evoluţiei sale se asociază "starea sistemului" care este un şir de variabile, un vector ale cărui componente variabile în timp permit cunoaşterea sistemului în orice moment. Folosind vectorul de stare al sistemului, şi vectorii de intrare, ieşire, comandă etc. se poate asocia sistemului un sistem de ecuaţii de stare care permit studiul şi sinteza unor clase de sisteme. Pentru analiza comportamentului sistemelor, în ansamblul lor, s-a propus conceptul de "cutie neagră" care reprezintă sistemul ca un tot, făcând abstracţie de procesele sale interne.


Cutia neagră primeşte impulsuri din mediul înconjurător (intrările) şi le transformă în acţiuni asupra mediului (ieşirile). Mecanismul transformării intrărilor în ieşiri poate fi descris cu ajutorul unor funcţii care au diverse forme particulare, în funcţie de natura sistemului. Sistemul devine "cibernetic" atunci când apare reglarea (conexiunea inversă sau feedback-ul). În 1948 matematicianul american Norbert Wiener prin publicarea lucrării sale fundamentale "Cybernetics", pune bazele acestei ştiinte a controlului şi comunicării.

Figura 1.1. Sistem cibernetic

Fie sistemul S definit prin vectorul intrărilor X şi prin vectorul ieşirilor Y; transformarea intrărilor în ieşiri se poate descrie în mod simplificat prin aplicarea operatorului liniar F. Y = F X Mărimile Y ale ieşirilor se compară cu vectorul obiectivelor propuse Z şi întrucât de cele mai multe ori apar abateri (Y#Z) este necesară intervenţia unui

pagina 8


"regulator" R care va genera mărimea de reglare Δx, cu rolul de a aduce ieşirile la nivelul obiectivelor stabilite ceea ce se poate scrie:

Z = F ( X + Δx) Sistemele cibernetice constituie o clasă importantă de sisteme. Sistemele economice sunt structurate, de obicei, ca două subsisteme "subsistemul condus" şi "subsistemul conducător". Traducând în termenii prezentaţi anterior, subsistemul condus este sistemul S iar subsistemul conducător este regulatorul R. Dată fiind proprietatea sistemelor de a putea fi împărţite în subsisteme care la rândul lor se pot diviza în alte subsisteme s.a.m.d., în continuare se va folosi noţiunea de subsistem numai în cazurile când este necesară punerea în evidenţă a relaţiei de incluziune într-un alt sistem.

Din punct de vedere al modului cum se analizează ieşirile (reacţiile) sistemului condus şi al modului cum se generează mărimile de reglare (deciziile) sistemele pot fi: Sistem deschis necontrolat.

Figura 1.2. Sistem deschis necontrolat.

pagina 9


În acest tip de sistem sistemul conducător emite o decizie D fară a cunoaşte reacţia sistemului condus la această decizie. Sistem închis controlat.

Figura 1.3. Sistem închis controlat

În acest caz în urma deciziei D a sistemului conducător, sistemul condus furnizează informaţia I ca o reacţie la decizia D. Sistem controlat autoreglabil univariant.

Figura 1.4. Sistem controlat autoreglabil univariant.

pagina 10


Sistemul controlat apare atunci când între forma primară a deciziei D preconizată de sistemul conducător şi forma realizată de sistemul condus nu este o concordanţă perfectă. În acest caz conducătorul luând în considerare diferenţele între ce s-a preconizat şi ce s-a realizat intervine cu noi decizii pentru a determina sistemului condus să se conformeze deciziei iniţiale D. Sistem controlat autoreglabil bivariant.

Figura 1.5. Sistem controlat autoreglabil bivariant Dacă în urma unor perturbaţii conducătorul reevaluează decizia sa primară poate să preconizeze o formă modificată a obiectivului iniţial. Sistemul este bivariant pentru că pe parcursul realizării deciziei atât forma iniţială cât şi cea finală s-au modificat.

pagina 11


pagina 12

1.2. Conceptul de analiza sistemică Ţinându-se cont de complexitatea deosebită a celor mai multe sisteme existente în natură, economie, etc., studierea sistemelor se face într-o manieră aparte numită abordare sistemică. Abordarea carteziană constă în a repera şi a izola fiecare subproblemă pentru o prelucrare ulterioară. Prin aceasta nu se va putea rezolva însă ansamblul problemei. Abordarea sistemică propune o viziune unică şi globală a problemei de rezolvat. În loc de a se începe analiza prin divizarea sistemului în componente din ce în ce mai mici şi mai uşor de stăpânit, toate componentele sunt considerate în ansamblul lor ("aspect spaţial") atât pe parcursul analizei, proiectării cât şi al procesului de conducere ("aspect temporal"). De fapt, numai în acest fel este posibil să se înţeleagă şi să se anticipeze corect comportarea posibilă a sistemului. O caracteristică esenţială a abordării sistemice este accentul pe care îl pune, în cazul analizei, pe interdependenţele dintre elementele sistemului şi pe observarea critică a calităţii acestora. Abordarea sistemică, s-a dovedit de mare utilitate în rezolvarea problemelor mari şi complexe, referitoare la oameni şi maşini. Abordarea sistemica este o noţiune care reuneşte trei activităţi importante: • analiza sistemelor • proiectarea (ingineria) sistemelor • conducerea sistemelor. Analiza de sistem poate fi considerată un mijloc de abordare a cercetării, sau chiar disciplină în sine, deoarece acest concept a început să fie folosit pe scară largă în mai toate domeniile.


pagina 13

Analiza sistemelor presupune parcurgerea următoarelor etape:

1.Prima etapă constă în formularea problemei. Pentru toate lucrările ulterioare este important ca analistul să examineze critic formularea problemei de către utilizator. Este bine să se aibă în vedere că la acest prim contact între analist şi utilizator pot apare probleme de comunicare între cei doi, datorate unor incompatibilităţi de limbaj. Orice eroare minoră în formularea problemei sau orice înţelegere eronată poate genera mari inconveniente prin amplificarea ei cu fiecare etapă parcursă.

2.De asemenea este deosebit de important să se

examineze minuţios formularea obiectivelor pentru că în acest domeniu sunt posibile inconsecvente: "să se maximizeze eficienţa concomitent cu încadrarea în cheltuielile minime".

3.Adeseori în optimizarea sistemelor apar dificultăţi

cauzate de faptul că este greu sau chiar imposibil să se analizeze întreaga problemă. Se poate recurge în astfel de situaţii la optimizarea fiecărui subsistem analizat, dar sistemul în întregul său nu poate fi decât suboptimal fiind necesară deci precizarea clară a limitelor problemei.

4.Analiza cerinţelor utilizatorului constă în

identificarea şi evaluarea necesităţilor lui reale.

5.Precizarea criteriilor de măsurare a eficienţei sistemului trebuie făcută înainte de evaluarea soluţiilor propuse prin stabilirea unui grup de mărimi reprezentative.


pagina 14

6.Analiza funcţională se concretizează într-o listă

amănunţită a funcţiunilor şi aprecierilor care trebuie îndeplinite. La analizele funcţionale o deosebită importanţă o are reprezentarea grafică în scheme bloc.

7.Pe masură ce se completează lista restricţiilor care

acţionează asupra sistemului devine posibilă cercetarea efectelor interacţiuni lor asupra întregului sistem. Identificarea restricţiilor şi evaluarea efectului lor asupra eficienţei sistemului reprezintă un alt aspect important.

8.Pe măsura avansării în analiza sistemului se

conturează diferitele soluţii posibile care satisfac restricţiile impuse. Obiectivul acestei faze este de a identifica diversele variante fără a adâncii analizele privind cheltuielile pe care le implică. Într-un sistem informatic, de exemplu, este necesar să se determine gradul în care hardware-ul şi software-ul avute în vedere oferă posibilităţi de dezvoltare ulterioară.

9.După precizarea variantelor posibile se trece la compararea şi evaluarea acestora. Este de dorit ca atât cheltuielile cât şi eficienţa să fie exprimate baneşte.

Proiectarea sistemelor este un proces de concepţie tehnică, asociat de obicei cu dezvoltarea sau cu modificarea importantă a unui sistem. Acest proces se împarte în: • proiectarea propriuzisă a sistemelor şi • proiectarea operării sistemelor


pagina 15

Proiectarea propriuzisă a sistemelor se împarte la rândul ei în:

• proiectarea preliminară • proiectarea de detaliu

La proiectarea preliminară se evaluează soluţiile de proiectare a transpunerii specificaţiilor funcţionale precizate în faza de analiză a sistemului şi apoi se selectează soluţia de proiectare. Proiectarea de detaliu cuprinde transpunerea concepţiei de proiectare, conturată în faza de proiectare preliminară în specificaţii de detaliu. Este necesară în această fază împărţirea lucrărilor pe echipe dar totodată trebuie să existe un grup de integrare a sistemului care să se ocupe exclusiv de problema asigurării funcţionalităţii corespunzătoare a fiecărui subsitem nu numai în parte ci şi în cadrul sistemului în ansamblu. Un aspect oarecum neglijat în tehnica sistemelor este proiectarea operării lor. Adeseori se consideră că proiectarea s-a terminat odată cu momentul în care sistemul este livrat beneficiarului. Un astfel de punct de vedere poate contribui la eşecul unui sistem tot atât de mult ca şi proiectarea lui defectuoasă. Operarea sistemelor este uneori neglijată din cauză că proiectanţii sunt în mod firesc mai interesaţi să soluţioneze problemele tehnice ale proiectării şi în mai mică masură problemele legate de limitele fizice şi psihice ale personalului operaţional şi de întreţinere. În plus concepţia de a adapta omul la maşină a creat obiceiul de a angaja pentru operare şi întreţinere acei oameni ale căror însusiri fizice şi psihice pot fi considerate compatibile cu caracteristicile echipamentului. Pe măsura sporirii complexităţii sistemelor, trebuie


pagina 16

acordată o atenţie deosebită noţiunilor de fiabilitate şi mentenabilitate. Conducerea sistemelor cuprinde stabilirea metodologiei şi a structurilor organizatorice pentru planificarea, directivarea şi controlul activităţilor de proiectare a sistemelor ca şi pentru funcţionarea lor. Conducerea funcţionarii sistemelor se numeşte "conducere operaţională". Pe de altă parte există conducerea însăşi a proiectării sau dezvoltării sistemului. Conducerea sistemelor nu reprezintă o fază a proiectării sistemelor ci este funcţiunea de comandă şi control care se desfăşoară de-a lungul ciclului de viaţă al sistemului. Cea mai mare contribuţie la eficienţa conducerii unui sistem o are identificarea momentelor şi criteriilor de efectuare a controlului, astfel încât să se poată stăpânii desfăşurarea activităţilor. Pe lângă controlul corespunzător principalelor etape conducerea trebuie să efectueze o permanentă urmărire şi coordonare. Acest sistem de control poate fi mai eficient dacă: • se realizează previziuni asupra evoluţiilor viitoare; • se planifică reexaminări periodice ale proiectelor.

Integrarea sistemului şi controlul configuraţiei sunt două activităţi de conducere care trebuie să-şi dovedească prezenţa pe parcursul fiecărei faze a proiectării sistemelor. Pentru integrarea sistemului conducerea trebuie să asigure compatibilitatea mecanică, electrică, etc. dar şi compatibilitatea informaţională. Controlul configuraţiei constă din metodele folosite pentru a orienta şi urmării modificările în diversele etape ale ciclului de viaţă al sistemului.


pagina 17

Am enumerat mai sus o serie de etape şi de probleme pe care trebuie să le urmeze şi să le rezolve analistul de sistem. Analiza de sistem înseamnă cunoaşterea sistemului, cunoaştere care se traduce printr-o reprezentare la nivel cerebral a sistemului în ansamblul său. De fapt prin analiza s-a transpus realitatea mai întâi într-un model cerebral pe care analistul îl va transforma şi îl va prezenta sub forma unui model matematic, grafic, etc.. Această activitate de percepere şi reprezentare a realităţii nu este deloc uşoara şi presupune în mod obligatoriu participarea activă a beneficiarului sistemului.


pagina 18

2. SISTEME INFORMAŢIONALE 2.1. Comunicarea în sistemele informaţionale Noţiunea de informaţie este complexă şi de mare generailitate. La momentul apariţiei sale, conceptul de informaţie a suscitat dispute filosofice pe tema caracterului material al acesteia. Norbert Winer spunea: " Informaţia este informaţie, nu este materie sau energie." Informaţia este un tip deosebit de raport între procesele materiale, raport ce nu există în afara acestor procese. Se poate afirma că informaţia reprezintă un atribut fundamental al materiei alături de masă, câmp şi substanţă. Informaţia ca atribut fundamental al materiei este prezentă atât în materia vie (informaţia genetică) cât şi în cea nevie .

Pentru determinarea riguroasă a cantităţii de informaţie se foloseşte un aparat matematic bazat pe elemente din teoria probabilităţilor.

Fie un experiment X rezultatele sale pun în evidenţă un număr finit de evenimente elementare independente x1,x2,..,xn, având asociate probabilităţile de realizare p1,p2,...,pn. Presupunem că experimentul X reprezintă un sistem complet de evenimente, adică prin efectuarea sa se va obţine cu siguranţă unul din evenimentele xk Є X , deci Σpk = 1 ; k=1,..,n. Realizarea unui eveniment înlătură o cantitate de nedeterminare, deci întrucât informaţia reprezintă o nedeterminare înlăturată sensul variaţiei nedeterminării este inversul


sensului variaţiei informaţiei, unitatea de măsură fiind aceiaşi. Notând cu H(X) măsura gradului de nedeterminare, care este egală cu cantitatea medie de informaţie furnizată de realizarea unui eveniment se poate scrie:

H(X) = H(p1,p2,...,pn) În anul 1948 Claude Shannon în lucrarea "Teoria matematica a comunicaţiei" a dat expresia cantităţii de nedeterminare (şi deci a informaţiei):

Shannon a preluat cercetările unui precursor al său în domeniul teoriei informaţiei R.V.Hartley care încă din anul 1928 a introdus noţiunea de cantitate de informaţie, definind-o astfel:"Informaţia obţinută prin precizarea unei variante din cele n echiprobabile este egală cu logaritmul lui n în baza 2".

I = log2 n = -log2 p unde p=1/n reprezintă probabilitatea de realizare a unei variante. Relaţia stabilită de Hartley se obţine ca un caz particular din formula lui Shannon atunci când evenimentele sunt echiprobabile;

p1 = p2 =....= pn = p= 1/n Măsura informaţiei calculată cu formula lui Shannon se

pagina 19


numeşte şi ENTROPIE INFORMAŢIONALĂ prin analogie cu entropia termodinamică, care masoară de asemenea gradul de nedeterminare al unui fenomen.

Transferul informaţiilor, deciziilor, datelor şi cerinţelor între diferite procese şi/sau între diferite sisteme sau subsisteme creează o problematică complementară cantităţii de informaţie: problema COMUNICARII. Fie:

Figura 2.1. Modelul comunicării

unde: E - este emiţătorul de informaţie R - este receptorul de informaţie C - este canalul de comunicaţie Caracterul esenţial al procesului de comunicare este reprezentat de mesaj şi această cantitate care caracterizează mesajul - definit ca o secvenţă de semne elementare - este legată de lungimea sa, de dimensiunile în spaţiu şi timp ale suportului său, sau ale canalului de transfer (lungimea cuvântului, suprafaţa unui disc, a unui tablou, numărul de semne imprimate), dar mai ales de improbabilitatea ocurenţei (apariţiei) sale, adică de combinaţia pe care o realizează. Această cantitate de noutate sau originalitate transportată de la E la R se adaugă la sistemul de cunoştinţe şi de

pagina 20


pagina 21

experienţă pe care îl au atât E cât şi R şi se înscrie în memoria lor. Semnele există înainte de crearea mesajului sau a actului de comunicare. Este vorba aici de a constitui un repertoriu, de a le clasa într-o ordine în funcţie de frecvenţa de întrebuinţare; în pasul următor vom deduce probabilitatea lor de apariţie (de ocurenţă) şi, în consecinţă, informaţia pe care ele o transportă.

Informaţia depinde deci de repertoriul comun atât al transmiţătorului cât şi al receptorului. Această masură presupune faptul că mesajul este decompozabil în mod obiectiv într-o serie de semne identificabile şi enunţabile. Procesul fundamental al comunicării între emiţător şi receptor prin intermediul unui canal fizic înseamnă: • a găsi semne care pot fi recunoscute într-un

repertoriu prin intermediul unui canal fizic; • a găsi semne care pot fi recunoscute într-un

repertoriu deţinut de emiţător; • a le aduce şi ale transmite prin ceea ce numim un

canal de comunicaţie; • identificarea de către receptor a fiecărui semn pe

care îl primeşte cu cele pe care le are deja în propriul său repertoriu.

Comunicarea ideilor nu are loc decât în măsură în care cele două repertorii au o parte comună. Pe măsură ce acest proces continuă în procesele dotate cu memorie şi cu estimare statistică, cum este cazul inteligenţei umane, percepţia semnelor mereu identice vine să modifice din ce în ce mai mult în repertoriul receptorului, căruia îi este subordonat. Este vorba de sistemul de învăţare.


pagina 22

În comunicare emiţătorul creează o formă, o imagine, o idee, pe care o codifică apoi în momentul emisiei. La rândul său, receptorul, plecând de la mesaj construieşte o altă formă. Calitatea comunicării se măsoară prin indentitatea dintre forma percepută şi forma creată. Leibnitz a arătat că orice mesaj poate fi considerat o alegere între o mulţime de cazuri posibile, alegere care se poate transforma într-un număr suficient de mare de dileme succesive. Fiecare dintre aceste alternative, fiecare din aceste alegeri între două posibiliăţti care se exclud (da-nu; 0-1), dacă ele sunt egal probabile pentru receptor, reprezintă o unitate de informaţie sau BIT (binary digit: cifră binară sau problemă binară). Avem astfel o unitate de măsură a informaţiei începând cu numărul de dileme susceptibile a defini mesajul fară ambiguitate.

Receptorul uman nu este capabil să sesizeze decât o cantitate limitată de originalitate pe unitatea de timp, adică un anume debit de informaţie, funcţie de canalul de percepţie (văz auz, pipăit, telepatie, etc.) Caracterul optim al mesajelor nu este dat de maximul de informţie ci de maximul de impact adică de probabilitatea de a înţelege, deci de a proiecta forme asupra mesajului primit.

E necesar aici un exces, o risipă de semne, şi apare o altă mărime numerică, legată de mesaj, care joacă un rol important în comunicaţie: REDUNDANŢA. Ea înseamna excesul relativ al numărului de semne faţă de cel care ar fi fost strict necesar pentru a transmite aceiaşi cantitate de originalitate.


Figura 2.2. Alegerea optimului de redundanţă Orice mesaj poate fi caracterizat prin conţinutul său de informaţie şi poate să se situeze într-un punct definit al unei scări care merge de la banalitatea totală până la originalitatea totală.

Redundanţa variază deci în raport invers proporţional cu informaţia. Inteligibilitatea unui mesaj este legată de redundanţa sa. Ea reprezintă maximul pentru un mesaj total banal şi este nulă pentru un mesaj perfect original.

Valoarea mesajului se traduce atunci prin diferite rate de redundanţă, (Figura 2.2.) care prezintă un maxim în funcţie de caracteristicile receptorului. Fie:

pagina 23


Figura 2.3. Comunicarea în prezenţa perturbaţiei unde: E - este emiţătorul de informaţie R - este receptorul de informaţie C - este canalul de comunicaţie P - este perturbaţia

Modelul matematic al unui sistem de transmitere a informaţiei este format din două mulţimi finite X, Y şi o probabilitate condiţionată p(y|x), definită pe Y pentru orice x Є X. X este mulţimea simbolurilor care se emit iar Y mulţimea simbolurilor ce se recepţionează.

Probabilitatea p(y|x) se numeşte probabilitatea de recepţie condiţionată de ceea ce se emite şi caracterizeză perturbaţia existentă pe canalul sistemnului respectiv. A cunoaşte canalul de comunicaţie înseamnă a cunoaşte probabilităţile p(y|x) pentru toate simbolurile x Є X şi y Є Y.

Mărimea H(X|Y) reprezintă cantitatea medie de informaţie necesară pentru a se recepţiona mulţimea Y şi depinde de probabilitatea condiţionată p(x|y), care la rândul ei, este determinată de probabilitatea p(y|x) ce caracterizează perturbaţia pe canal.

Nedeterminarea H(X|Y) apare datorită perturbaţiei; ea este preţul pe care trebuie să-l plătim

pagina 24


pagina 25

perturbaţiei pentru ca să putem recepţiona semnalele y Є Y.

Dacă H(X|Y) reprezintă cantitatea medie de informaţie care se pierde pe canal şi dacă de la sursa se transmite o cantitate de informatie H(X), la recepţie va ajunge numai cantitatea de informatie

Q=H(X) - H(X|Y) Mărimea denumită CAPACITATEA CANALULUI este dată de relaţia:

C = MAX (H(X) - H(X|Y)) si ea pune în evidenţă cantitatea de informaţie care poate să circule în mod util prin canalul dat. Diferenţa H(X) - H(X|Y) raportată la uinitatea de timp se mai numeşte viteză de transmitere a informaţiei. Capacitatea canalului este deci viteza maximă de transmitere a informaţie pe canalul respectiv.


pagina 26

2.2. Fluxuri de informaţii Fie graful G0(X,L) unde: X este mulţimea elementelor şi L este legea de corespondenţă (mulţimea de perechi de puncte distincte din X); • Un punct xi din X este numit NOD. • O pereche de puncte xi,xj este numită LATURA sau

ARC. • Mulţimea punctelor { x1,x2,...,xl } din mulţimea X

desemnează un DRUM de lungime L dacă perechile { xi,xi+1 } sunt laturi;

• Distanţa între două puncte ale unui graf este egală cu lungimea căii celei mai scurte dintre ele.

Pe acest graf G0(X,L) se defineşte un alt graf numit GRAF INFORMAŢIONAL G1(X,C). Între cele două grafuri există o deosebire: legea de corespondenţă. În timp ce G0 reglementează relaţiile organizatorice G1 reglementeză relaţiile informaţionale. Laturile grafului G1 se numesc CANALE INFORMAŢIONALE. În mulţimea {C} a canalelor informaţionale se pot defini două submulţimi: C1={c Є C|c=canal pur informaţional} C2={c Є C|c=canal decizional} Pe mulţimea {C} putem defini mulţimea {F} a fluxurilor. Fluxul este acea cantitate de informaţie care circulă pe un canal. El poate fi: • informaţional • decizional DRUM INFORMAŢIONAL este succesiunea de arce adiacente ce permit trecerea fluxului informaţional de la un nod la altul.


pagina 27

LUNGIMEA UNUI DRUM INFORMAŢIONAL este dată de numărul de arce din care este format. Drumul poat fi: • deschis (numai informaţional) • închis (informaţional - decizional) Tipuri de fluxuri informaţionale. Fie un flux F(A,B) unde A şi B sunt noduri iar fluxul F circulă pe canalul AB: • când informaţia circulă de la un nivel organizatoric A

inferior la un nivel superior B, fluxul se numeşte ascendent.

• când informaţia circulă de la A la B şi ele sunt pe acelaşi nivel organizatoric, fluxul se numeşte orizontal.

• când informaţia circulă de la A situat la un nivel organizatoric superior la B aflat pe un nivel organizatoric inferior, fluxul se numeşte descendent.

• când A şi B aparţin aceluiaşi sistem S, fluxul F(A,B) se numeşte intern.

• când A sau B nu aparţin sistemului S fluxul se numeşte extern.

• când conţinutul, direcţia şi periodicitatea fluxului sunt prestabilite, fluxul se numeşte periodic.

• când nici conţinutul nici periodicitatea nu sunt reglementate, fluxul se numeşte de moment sau întâmplător.


pagina 28

2.3. Locul şi rolul sistemului informaţional Circulaţia informaţiei din momentul producerii unui eveniment în procesul condus şi până când pe baza cunoaşterii lui, se declanşează un nou eveniment precum şi precizarea conţinutului informaţiei, destinaţiei, locului stocării, etc. alcătuiesc sistemul informaţional. Totalitatea metodelor, tehnicilor, mijloacelor, privite ca ansamblu integrat care asigură înregistrarea, culegerea, transmiterea, prelucrarea şi valorificarea informaţiilor de orice natură definesc sistemul informaţional. Un sistem informaţional se crează şi se dezvoltă odată cu organismul sau activitatea pe care o reflectă. Într-un sistem economic sistemul informaţional asigură legătura în ambele sensuri între sistemul condus sau de execuţie şi sistemul conducător sau decizional (Figura 2.4.).

Orice sistem economic presupune existenţa unei componente operaţionale care poate fi orice sistem de producţie de bunuri sau servicii. Sistemul condus asigură desfăşurarea activităţilor specifice sistemului în vederea realizării obiectivului global pentru care a fost creat. Sistemul condus se compune din ansamblul actorilor operaţionali din întreprindere şi care: • utilizează informaţiile prezente în sistemul

informaţional; • utilizează regulile de comportament din sistemul

informaţional.


Figura 2.4. Locul sistemului infirmaţional

Spre exemplu un vânzător dintr-o societate care se ocupă cu vânzări prin corespondenţă, primeşte o comandă telefonică de la un client nou. Sistemul informaţional este acela care: • îi furnizează informaţia că este vorba de un client

nou; • îi furnizează regula de acţiune care se traduce prin

aplicarea unui comision de 10% asupra vânzărilor. Astfel sistemul operaţional adaugă o nouă informaţie în sistemul informaţional (numele clientului, adresa clientului, etc). Sistemul conducător asigură previziunea comanda, organizarea, coordonarea şi controlul desfăşurării activităţilor în vederea îndeplinirii obiectivelor sistemului.

pagina 29


pagina 30

El este compus din ansamblul actorilor care fixează şi adaptează obiectivele şi strategia întreprinderii utilizând informaţiile prezente în sistemul informaţional. Sistemul conducător intervine asupra sistemul informaţional în sensul adaptării la obiectivele şi la strategia întreprinderii, modificând natura informaţiilor şi regulile de comportament. Spre exemplu conducerea unei bănci decide ca clienţii săi să nu mai fie consideraţi ca persoane ci ca gospodării (familii) ceea ce duce la schimbarea naturii informaţiei. O societate decide să schimbe modul de facturare prin editarea facturii pe calculator în momentul prezentării clientului. Rezultă de aici o acţiune asupra regulilor de comportament, facturarea actualizând stocul fără a mai fi nevoie de o procedură ulterioară.

Prin situarea sa între sistemul conducător şi sistemul operaţional sistemului informaţional asigură următoarele funcţiuni: • culegerea datelor care consemnează realitatea

economică din cadrul proceselor operaţionale. • preluarea informaţiilor de la alte sisteme şi împreună

cu cele din sistemul operaţional să asigure prelucrarea, valorificarea şi arhivarea lor.

• obţinerea şi transmiterea către conducerea proprie şi către organele supraordonate a informaţiilor necesare fundamentării deciziilor sau a urmăririi efectelor acestora.

• transmiterea de informaţii de rutina altor procese informaţionale.

• preluarea şi transmiterea fără modificări a deciziilor care provin de la organele supraordonate către procesul decizional propriu.


Figura 2.5. Sistemul informaţional

Având în vedere caracterul dinamic al sistemului economic, în mod obiectiv şi sistemul informaţional trebuie să fie într-o continuă adaptare şi perfecţionare. Elemente ale sistemului economic pot reprezenta perturbaţii pentru sistemul informaţional dar acesta fiind un sistem cibernetic există posibilitatea adaptării şi funcţionării celor două sisteme în concordanţă. În sistemul informaţional privit ca sistem cibernetic conexiunea inversă o constituie : • deciziile pentru menţinerea echilibrului sistemului

economic în ansamblu; • deciziile luate de conducerea subsistemului

informaţional pentru buna funcţionare şi perfecţionare a acestuia.

Reacţia inversă se concretizează prin informaţia economică necesară conducerii sistemului economic atât pentru fundamentarea deciziilor cât şi pentru urmărirea efectelor acestora.

pagina 31


Sistemul informaţional are caracter cibernetic şi datorită faptului că are capacitatea de autoreglare astfel încât el este întotdeauna în concordanţă cu sistemul economic pe care îl reflecta.

Figura 2.6. Sistemul informaţional; sistem cibernetic

Funcţiile de previziune, organizare, coordonare şi control, atribute ale sistemului conducător, devin în societatea modernă din ce în ce mai complicate. Din această cauză în procesul de conducere apare

pagina 32


pagina 33

necesitatea unor metode care să permită stăpânirea fluxurilor informaţionale din şi spre sistemul condus, şi care să permită conducerii sesizarea problemelor ce pot să apară în viitor. Întreprinderea este pusă în situaţia de a prelucra toate aceste fluxuri informaţionale şi de a-şi alege propria cale din mult mai multe variante pe care le are la dispoziţie. Aceste posibilităţi complexe de acţiune se traduc printr-un nivel mai mare al fluxurilor informaţionale care intră şi ies din întreprindere, fluxuri care trebuie analizate şi controlate de conducerea întreprinderii. Deciziile elaborate trebuie să stea la baza conturării mai multor variante de evoluţie care să cuprindă simultan criterii de timp, băneşti şi de performanţă. Apare în acest caz o situaţie potenţială de risc, generată mai ales de imposibilitatea de a controla noul val de complexitate.


pagina 34

3. SISTEME INFORMATICE 3.1. Definire Din definiţia sistemului informaţional reiese că obiectivul global urmărit este tratarea şi valorificarea informaţiei la toate nivelele sistemului în care se crează şi se dezvoltă. Metodele, mijloacele şi tehnicile utilizate în realizarea obiectivului caracterizează modul de prelucrare a datelor. Putem avea o prelucrare manuală, automată sau interactivă. Deşi la început calculatorele electronice erau folosite în exclusivitate pentru calcule tehnico-ştiintifice, începând cu cel de-al şaptelea deceniu al secolului nostru, acestea sunt utilizate pe o scară tot mai largă pentru prelucrarea automată a datelor referitoare la procesele şi fenomenele economice, la rezolvarea pe cale automată a unor probleme generate în procesul decizional. Prelucrarea automată a datelor a apărut odată cu utilizarea calculatoarelor electronice în realizarea proceselor informaţionale. Pentru definirea sistemului informatic prezentăm un set de trei definiţii unanim acceptate, dar care pun accentul pe una sau alta dintre trăsături, completându-se reciproc. • Atunci când în sistemul informaţional predomină

utilizarea calculatoarelor electronice, se spune că el este un sistem informatic.


pagina 35

• Un sistem informatic poate fi definit ca un ansamblu

tehnico-organizatoric de automatizare a culegerii şi prelucrării informaţiilor destinate desfăşurării procesului de conducere, în scopul asigurării unei eficienţe cât mai mari a activităţii economico-sociale respective.

• Partea componentă a sistemului informaţional prin

care se asigură, pe baza folosirii tehnicii de calcul şi în primul rând a calculatoarelor electronice, tratarea raţională a datelor şi a informaţiei, cu eficienţă sporită, constituie un sistem informatic.

În timp ce prima definiţie pune accentul pe aspectul tehnic, adică pe utilizarea calculatoarelor, cea de-a doua vizează aspectul de organizare şi raţionalizare a circuitului informaţiilor destinate conducerii. Ultima definiţie este cea care reuneşte cele două aspecte subliniate de primele definiţii adăugând şi relaţia de incluziune a sistemului informatic în sistemul informaţional. Sistemul informatic se asociază obligatoriu unui sistem informaţional şi este subordonat unui proces decizional. Prin tratarea datelor cu tehnica de calcul sunt eliminate erorile de informare care se repercutează negativ asupra calităţii desfăşurării activităţilor. Sistemul informatic, ca parte a sistemului informaţional, trebuie structurat ca sistem cibernetic cu două bucle de reglaj. Bucla principală de reglaj reflectă principalele influenţe cu mediul înconjurător: legăturile cu băncile, cu beneficiarii, etc. Bucla secundară este ca o buclă de autoreglaj care face faţă în principal


pagina 36

perturbaţiilor interne din sistem. Structura cibernetică cu două bucle de reglaj a sistemului informatic este necesară şi suficientă pentru ca sistemul să poată fi folosit ca instrument al conducerii. În condiţiile unei orientări a activităţii spre piaţă, strategia întreprinderii poate suferi modificări substanţiale, în funcţie de situaţiile conjuncturale apărute. Dacă, în urma unor perturbaţii de acest fel, conducătorul reevaluează decizia sa primară (planul iniţial), poate să preconizeze o formă modificată a obiectivului iniţial. În acest caz, când pe parcursul realizării deciziei, atât forma iniţială cât şi cea finală s-au modificat, putem vorbi despre sistemul informatic ca despre un sistem bivariant. Sistemul informatic este format, în esenţă, din următoarele categorii de elemente: 1. calculatoare electronice şi alte echipamente 2. metode şi tehnici de tratare a datelor şi a informaţiei 3. colecţii organizate de date 4. proceduri şi programe de tratare a datelor 5. cadre de specialitate În cadrul sistemelor informatice, calculatorul electronic devine un factor de sprijinire a analizei şi deciziei de maximă importanţă, prin rezolvarea problemelor de optimizare, atât la nivelul elaborării programelor de activitate, cât şi pe parcursul executării lor. Un sistem informatic este conceput prin colaborarea dintre specialişti din domenii conexe iar realizarea unui sistem informatic este un proces complex, de durată şi care necesită activităţi specifice de analiză, proiectare, programare şi implementare.


pagina 37

Sistemul informaţional trebuie să devină, prin introducerea sistemului informatic, instrument de reglare şi autoreglare a sistemului economic. Obiectivul global urmărit este creşterea fiabilităţii sistemului economic studiat. Din activitatea practică de realizare a sistemelor informatice se desprind următoarele principii pentru realizarea sistemelor informatice. 1. Sistemul este pentru beneficiar, ceea ce implică:

• participarea permanentă a beneficiarului în toate etapele de realizare a sistemului;

• întocmirea documentaţiilor orientate către beneficiar într-un limbaj accesibil acestuia;

• aprobarea de către beneficiar a tuturor propunerilor făcute în proiect;

• responsabilitatea viitorului utilizator pentru implementarea sistemului, pentru corectitudinea datelor folosite şi pentru pregătirea personalului necesar exploatării sistemului;

2. Problema cheie este cea a oamenilor nu a

echipamentelor, şi în special a analiştilor-proiectanţi de sisteme, specialişti care au o influenţă hotărâtoare asupra modului de realizare a sistemelor.

3. Sistemele informatice trebuiesc justificate din punct de vedere cantitativ şi calitativ, deoarece reprezintă investiţii importante.

4. Realizarea sistemului informatic este un proces iterativ, ceea ce înseamnă că întâi trebuie stabilit numai cadrul general, detalierea făcându-se apoi treptat, în mai multe iteraţii.

5. Când nu putem să planificăm ceva nu putem să facem corect acel lucru, principiu valabil nu numai în informatică. În virtutea acestui principiu trebuie


pagina 38

permanent urmărite şi reactualizate planificările iniţiale pe măsura realizării sistemului. De asemenea, trebuie acordată o deosebită atenţie modului de etapizare a lucrărilor şi mărimii etapelor pe care vrem să le realizăm.

6. Procedurile manuale sunt la fel de importante ca şi programele, de corecta lor proiectare depinzând durata de implementare şi modul de funcţionare a sistemului.

7. Trecerea de la vechiul sistem la noul sistem este ea însăşi un sistem şi de aceea trebuie tratată cu mare atenţie. Proiectantul de sistem are de fapt în faţă trei sisteme: cel vechi, cel nou şi cel care face trecerea de la vechiul mod de lucru la cel nou.

8. Sistemul trebuie să aibă o bună documentaţie în toate etapele de realizare.


pagina 39

3.2. Ciclul de viaţă al unui sistem infomatic Din cele prezentate anterior se constată că restructurarea unui sistem informaţional este un proces complex. Analistul de sistem trebuie să parcurgă o serie de etape şi să rezolve o mulţime de probleme. Analiza de sistem înseamnă cunoaşterea sistemului, cunoaştere care se traduce printr-o reprezentare la nivel cerebral a sistemului în ansamblul său. De fapt prin analiză s-a transpus realitatea mai întâi într-un model cerebral pe care analistul îl va transforma şi îl va prezenta sub forma unui model matematic, grafic, etc.. Această activitate de percepere şi reprezentare a realităţii nu este de loc uşoară şi presupune participarea activă a tuturor membrilor echipei de proiectare dar şi a beneficiarului sistemului într-un context uman, material şi organizatoric, propice realizării sistemului. Mediul de proiectare al unui sistem informatic constă în unitatea proceselor de dezvoltare, a metodelor de definire, descriere, abstractizare, modificare, rafinare şi documentare precum şi modalitatea de automatizare a aplicării metodelor. Când vorbim despre procesul de reorganizare a unui sistem informaţional, trebuie să descriem un model care să prevadă ceea ce va apărea în procesul de dezvoltare. Această etapizare va arăta ce trebuie făcut, cum va fi realizat, când va fi terminat şi cine va folosi ceea ce s-a realizat. Un bun model al procesului de prelucrare trebuie să respecte trei cerinţe principale. • Trebuie să aibă o mare putere descriptivă, putând să

descrie esenţialul în mod realist.


pagina 40

• Trebuie să permită descrierea însuşi a procesului de dezvoltare şi a modului de conducere a dezvoltării procesului.

• Trebuie de asemenea să acopere cazurile neprevăzute şi schimbările continue care intervin într-un astfel de proces.

În general, modelul trebuie să aibă capacitatea de a putea descrie o mare varietate de sisteme şi de subsisteme ale acestora. Există un mare număr de modele care descriu procesul de realizare a unui sistem informatic denumite generic "modele ale ciclului de viată". Modelul WATERFALL (în cascadă).

Este cel mai vechi şi cel mai cunoscut model. A fost dezvoltat în perioada anilor '60, caracteristica principală constând în parcurgerea unor etape numite "faze". (Figura 4.1.)

1. Analiza cerinţelor. Definirea şi analiza necesităţilor

utilizatorului. 2. Specificaţia. Translaţia cerinţelor într-o descriere

generală a sistemului. 3. Proiectarea. Crearea unei abstractizări a sistemului în

concordanţă cu specificaţiile anterioare. 4. Implementarea. Crearea sistemului care

implementează ceea ce s-a proiectat. 5. Testarea. Determină dacă implementarea satisface

cerinţele. 6. Mentenanţa. Modificarea sistemului necesară pentru

a fixa problemele apărute. Ciclul de viaţă se repetă în cadrul acestei faze.


Figura 3.1. Modelul Waterfall

Se constată că fiecare fază constituie o trecere de la un nivel de abstractizare ridicat (puţine detalii) la un nivel mai scăzut de abstractizare (mai multe detalii). Cu toate că există o bogată experienţă şi tradiţie în aplicarea cu succes a modelului, există unele probleme.

În primul rând modelul nu este suficient de descriptiv în ceea ce priveşte activităţile care interferă prin toate fazele ciclului de viaţă cum ar fi: conducerea proiectului, asigurarea calităţii, verificarea şi validarea. Spre exemplu o eroare de specificare poate să nu fie descoperită decât

pagina 41


pagina 42

foarte târziu, şi este extrem de greu de revenit la faza la care s-a produs eroarea.

În al doilea rând modelul a fost dezvoltat într-o perioadă când sistemele de mici dimensiuni şi cu arhitectură compactă erau dominante.

În ultimul rând modelul nu se pretează la transpunerea sa pe calculator. El a fost dezvoltat într-o perioadă când proiectarea asistată de calculator nu era deloc înţeleasă. Modelul INCREMENTAL (RAPID-PROTOTYPING).

Acest model (al prototipizării rapide) a fost creat pentru a acoperi deficienţele modelului WATERFALL cu care se aseamănă din mai multe puncte de vedere. Diferenţa principală constă în introducerea conceptului de dezvoltare incrementală.

Dezvoltarea incrementală constă în crearea unor mici salturi de la vechea variantă de sistem la noua variantă care conţine un plus de funcţiuni. Produsul final nu este văzut ca un sistem monolit livrabil integral la o singură dată, ci este realizat şi livrat dintr-o serie de etape succesive corespunzătoare fiecărei iteraţii. Numai la sfârşit sistemul este disponibil integral, dar până atunci fiecare increment poate lucra ca un sistem de sine stătător. (Figura 4.2.) Modelul incremental elimină necesitatea furnizării cerinţelor, specificaţiilor generale şi a celor detaliate înaintea începerii etapei de proiectare. Aceste specificaţii numite "builds" (baselined intermediate software products) sunt în mod formal specificate la începutul fiecărui increment. Acest lucru permite posibilitatea schimbării cerinţelor prin adăugarea lor în pasul următor.


Figura 3.2. Modelul incremental

Şi în acest model există posibilitatea erorilor în formularea cerinţelor dar spre deosebire de modelul Waterfall acestea pot fi corectate de la un pas la altul pe parcursul realizării sistemului. În plus se poate simula funcţionalitatea sistemului, scopul său fiind furnizarea unor feed-back-uri rapide proiectanţilor şi conducătorilor fără o pierdere inutilă de timp, eliminându-se posibilitatea construirii unui sistem greşit. Fiecare increment realizat în fiecare pas de dezvoltare al sistemului se poate constitui într-un

pagina 43


pagina 44

prototip al viitorului sistem. Fiecare acest prototip poate să se regăsească sau nu în sistemul final dar regula generală care trebuie urmărită constă în planificarea eliminării acestor prototipuri. Acest model reuşeşte să integreze corect activităţile care acoperă tot ciclul de viaţă al sistemului, cum ar fi: • Coordonarea proiectului constă în capacitatea de a

controla versiunile sistemului de elaborat, pentru ca acestea să fie în realitate incrementări ale versiunii anterioare şi nu nişte modificări arbitrare şi neautorizate. Numai acele modificări care vor determina schimbări favorabile în dezvoltarea sistemului vor fi aprobate.

• Verificarea constă în stabilirea în continuu a corespondenţei între ce s-a solicitat şi ce s-a realizat.

• Validarea, trebuie să aibă în vedere că sistemul construit să nu prezinte goluri şi incoerenţe.

Dezvoltarea incrementală este ca o sabie cu două tăişuri, pentru că permiţând etapizarea sistemului în versiuni succesive, orice problemă apărută şi nerezolvată la un moment dat implică suspendarea etapelor următoare.

Dezavantajul implicat de această situaţie este totuşi mult mai mic, decât necazul produs de descoperirea erorii numai la finalizarea sistemului.

Un alt avantaj constă în posibilitatea dezvoltării simultane a mai multor sisteme, fiecare în diferite stadii ale ciclului de viaţă. Aceasta măreşte capacitatea conducerii de a acoperii un domeniu mai vast putându-se aloca mai bine resursele, dar trebuie ţinut cont că pot apărea situaţii în care este greu de estimat necesarul de resurse mai ales în situaţiile neprevăzute apărute în diferiţii paşi de dezvoltare ai sistemelor coordonate.


Modelul ciclului de concepţie în “V”.

Dezvoltarea unui sistem urmărind abordarile anterioare poate fi descompusă într-o succesiune de faze: specificaţii, concepţie, programare şi mentenanţă după unii autori sau analiză preliminară, proiectare logică, proiectare tehnică, programare, implementare, exploatare şi întreţinere, după altii. (variante ale modelului Waterfall).

Figura 3.4. Ciclul de concepţie în V

pagina 45


pagina 46

Pentru evidenţierea faptului că anumite faze ale ciclului de viaţă sunt condiţionate de faze anterioare s-a propus reprezentarea ciclului de viaţă al unui sistem informatic ca un ciclu de concepţie în “V” (Figura 3.4.). Se observă că etapele din braţul descendent sunt validate de cele situate pe braţul ascendent. Asfel concepţia arhitecturii aplicaţiei va trebui să răspundă testelor de funcţionare a componentelor luate fiecare în parte dar şi în ansamblu.

Această schemă pune clar în evidenţă principalul inconvenient al abordărilor clasice. Nu se poate valida analiza făcută la începutul proiectului decât atunci când toate activităţile de programare, testare şi integrare sunt terminate. Modelul OPERAŢIONAL. Acest model porneşte de la o altă abordare decât modelele anterioare şi anume prin concentrarea efortului de definire asupra aspectului operaţional. Mecanismul implementării nu este ascuns ci stă la baza specificaţiilor de definire. Cu alte cuvinte, modelul operaţional creează specificaţii executabile (numite şi specificaţii operaţionale) care sunt ulterior transformate într-o eficientă implementare. Astfel comportamentul extern al sistemului există implicit în cadrul specificaţiilor în timp ce structura internă nu. În acest tip de model proiectarea se referă direct la condiţiile de mediu în timp ce celelalte modele pun accentul pe separarea cerinţelor (comportamentul extern) de structura internă a sistemului. Prin realizarea legăturii între specificaţiile operaţionale şi structura internă a sistemului, se


constată că modelul operaţional este "orientat pe problemă" spre deosebire de celelate modele care sunt "orientate pe implementare".

Figura 3.3. Modelul operaţional

Unul dintre avantajele modelului operaţional este marea sa putere descriptivă orientată direct spre rezolvarea problemei. Spre deosebire de modelul incremental care porneşte de la o descriere liberă a specificaţiilor de definire, modelul operaţional are descrieri formale, riguroase şi care pot fi uşor analizate. Acest fapt îi permite să poată foarte uşor să fie transpus pe calculator. Ca dezavantaje se constată contradicţia dintre necesitatea transformării cerinţelor externe într-o structură internă înainte ca aceasta să fi fost definită. Deoarece modelul nu este prea răspândit evaluarea posibilităţilor sale este dificil de făcut mai ales pentru sisteme de mari dimensiuni. El este în schimb mai folosit pentru realizarea sistemelor mici.

pagina 47


pagina 48

Din parcurgerea sumară a acestor modele se observă că modelul Waterfall este un model atractiv care se bazează pe o lungă perioadă de aplicare, fapt care îi conferă avatajul numeroaselor experimentări în situaţii dintre cele mai diferite. Modelul Incrememtal include în ciclul de viaţă activităţi de conducere şi dezvoltare prin paşi succesivi, realizând un feed-back rapid între proiectanţi şi utilizatori. Modelul de concepţie în “V” pune în evidenţă faptul că o fază o validează pe precedenta (similar modelului Waterfall) dar şi faptul că numai fazele terminale realizează adevărata validare a etapelor de început. Modelul Operaţional realizează specificaţii "executabile", măreşte rolul automatizării şi stabileşte o strânsă legatură între specificaţii şi implementare. Cu toate acestea se constată că un model perfect bazat pe ciclul de viaţă al sistemului informatic nu se poate realiza, mai ales datorita unor condiţii subiective. Adesea un proiect trebuie început de la dorinţele unui viitor utilizator care are o vagă idee despre ceea ce va trebui să se realizeze, şi numai după ce sistemul s-a realizat aproape integral se hotărăşte că nu este de fapt ceea ce a dorit. Este extrem de greu de modelat această situaţie: "Nu ştiu ceea ce vreau dar ştiu ceea ce nu doresc". Practica ne-a demonstrat că folosirea unui model imperfert şi incomplet este totuşi mult mai utilă decât renunţarea la orice fel de model. Dar modelul nu este totul. Avem nevoie de un set de prescripţii pentru desfăşurarea activităţilor cerute de etapele unui model bazat pe ciclul de viaţă, prescripţii utilizate pentru proiectarea sistemului. Am definit prin aceasta metoda de proiectare. Metoda de proiectare are o dublă responsabilitate:


pagina 49

• de a creea produsul • de a implementa o parte din modelul ciclului de

viaţă. Încercarea de a găsi cea mai bună metodă de realizare a sistemelor informatice este un subiect de cercetare deosebit de important. Problema cu cele mai multe metode este că ele au atât reguli implicite cât şi explicite. Regulile explicite sunt prezentate de obicei în documentaţia de realizare dar cele implicite nu sunt prezentate nicăieri. Când se realizează un sistem informatic apar o multitudine de probleme şi este aproape imposibil să se repete procesul original pentru crearea unui alt sistem. Metoda nu furnizează numai paşii care trebuie parcurşi ci precizează şi ce decizii trebuiesc luate în paşii respectivi. Este foarte important, în acest caz, ca la livrarea proiectului să se furnizeze şi metoda după care a fost realizat. Ultimul aspect care trebuie abordat este "automatizarea" metodei de proiectare. Acest termen este preferat termenului de "instrumente de dezvoltare" (software tools), care vizează punctual o anumită operaţie. Automatizare înseamnă un suport pentru o metoda şi este o parte integrată în procesul de dezvoltare a sistemului informatic. Dar soluţionarea cu succes a problematicii constă în integrarea coerentă a metodelor folosite într-o metodologie, şi nu în automatizarea lor. Automatizarea are o mulţime de avantaje. Cel mai important constă în reducerea muncii în aplicarea metodelor, şi într-un anume fel este cea mai realistă manieră de aplicare a metodelor. Apectul birocraic al celor mai multe metode presupune păstrarea unei cantitaţi mari de informaţii care este imposibil de gestionat manual pentru sisteme de o anumită mărime.


pagina 50

Automatizarea implică o scădere a costurilor de dezvoltare şi planificare rezultând o creştere calitativă a activităţii creative deoarece proiectanţii şi conducătorii proiectului sunt degrevaţi de aspectele de rutină. De cele mai multe ori automatizarea facilitează învăţarea şi comunicarea între membrii proiectului.


pagina 51

IV. METODA M E R I S E 4.1. Prezentare Apariţia metodei MERISE marchează o dată importantă în istoria prelucrării informaţiilor. Această apariţie rezultă pe de o parte din contextul generalizării prelucrărilor conversaţionale, consecinţă a salturilor tehnologice din anii '70, şi pe de altă parte, rezultă în urma numeroaselor lucrări asupra bazelor de date şi asupra "abordării sistemice". MERISE s-a născut în Franţa în jurul anilor 1978-1979 ca urmare a unei vaste consultări lansate de către Ministerul Industriilor cu scopul de a realiza o metodă modernă de concepere şi realizare a sistemelor informatice. Între 1986 şi 1989 metoda MERISE s-a impus cu adevărat devenind un standard cu un număr de utilizatori în continuă creştere atât în domeniul public cât şi în cel privat. Statisticile publicate în Franţa în 1990 au confirmat această evoluţie deoarece dintre întreprinderile mari şi mijlocii care foloseau o metoda de analiză-proiectare, 60% aleseseră deja MERISE. MERISE acumulează continuu şi completează cămpul său de aplicabilitate integrând noi extensii. Patru sunt direcţiile principale de evoluţie: • integrarea arhitecturilor client/server; • o mai buna poziţionare în raport cu metodele anglo-

saxone; • o abordare orientată pe obiecte;


pagina 52

• dezvoltarea unui mediu metodologic european concretizat astăzi prin proiectul EUROMETHODE.

Consfătuirea cu tema "MERISE et les autres" desfăşurată la Versailles între 5 şi 7 octombrie 1994 a avut ca subtitlu "Ce sisteme informatice pentru o lume în schimbare?" şi şi-a propus dezbaterea poziţiei acestei metode în raport cu alte abordări metodologice. MERISE are numeroşi adepţi care o utilizează cu pasiune, dar şi opozanţi care o consideră o metodă greoaie. Dacă anumite proiecte sunt uneori nereuşite aceasta este din cauza unei folosiri inadecvate a metodei. Folosirea metodei MERISE implică o investiţie personală care presupune o mare rigoare şi folosirea unor tehnici complexe. Această investiţie personală nu a fost facută, uneori, în cele mai bune condiţii şi în această situaţie, pentru anumiţi conducători de proiecte, metoda pare greoaie. Pentru a reuşi, un proiect MERISE trebuie să aibă obligatoriu adeziunea şi participarea utilizatorilor. Metoda presupune construirea de modele la nivel conceptual, organizaţional şi operaţional furnizând astfel legăturile existente în sistemele informaţionale. (Figura 4.1.)


Figura 4.1. Nivelele metodei Merise

NIVELUL CONCEPTUAL constă în analiza sistemului informaţional în termenii obiectivelor, fără a ţine cont de nici un concept legat de organizare ("ce trebuie făcut şi cu ce date?"). Trebuie studiate separat în plan conceptual, pe de o parte datele şi organizarea lor şi pe de altă parte prelucrările.

pagina 53


pagina 54

În termeni de organizare a datelor se face apel la formalismul entitate-relaţie şi aceasta se traduce prin entităţi de baza şi relaţii între aceste entităţi. La acest nivel, cu ajutorul unei grafici adecvate se constituie modelul conceptual al datelor (MCD), care permite o descriere statică a sistemului informaţional cu ajutorul conceptelor de entitate şi asociaţie. MCD permite reprezentarea datelor din realitatea înconjurătoare independent de opţiunile tehnice, pentru a uşura gândirea în timpul activităţii de concepţie.

În termeni de organizare a prelucrărilor aceste entităţi vor fi descrise prin prelucrările pentru care ele sunt cauze şi consecinţe. Această etapă are ca scop definirea operaţiilor principale care trebuie efectuate în domeniul studiat. Se va stabili o diagramă de flux (modelul conceptual al comunicaţiilor MCC) care permite descrierea informaţiilor schimbate global în sistem prin intermediul actorilor şi fluxurilor. Pornind de la această diagramă, se va trece spre modelul conceptual al prelucrărilor (MCP). Rezultatul său final se va concretiza sub formă schematică într-un model "eveniment-operaţie-rezultat" care va trebui să răspundă la întrebările: ce trebuie făcut în interiorul sistemului informaţional, sub impulsul căror evenimente şi ce rezultate se obţin? NIVELUL ORGANIZAŢIONAL constă în integrarea în analiză a criteriilor legate de organizare. După ce nivelul conceptual a exprimat realitatea percepută în ansamblul său, nivelul organizaţional exprimă această realitate aşa cum este ea trăită de actorii participanţi, indiferent care ar fi aceştia. La acest nivel nu se face nici o distincţie între oameni şi maşini. La nivelul datelor este necesară orientarea către o clasă de soluţii, şi apare modelul logic al datelor (MLD) care este o transcriere a modelului conceptual al datelor. Are loc, în privinţa datelor, o


pagina 55

transformare a lor dar nu o îmbogăţire a lor. Nivelul conceptual al datelor este o descriere completă a sistemului. Date noi pot fi create la nivele inferioare (crearea unei redundanţe în vederea minimizării numărului de accesări la una din entităţi) dar în nici un caz nu se pot crea informaţii noi. Situaţia este diferită la nivelul prelucrărilor. Trecerea de la nivelul conceptual (MCP) la nivelul organizaţional (MOP) se concretizeaza prin ataşarea evenimentelor definite anterior, actorilor. În aceste proceduri globale vor apare întotdeauna actori care au în plus noţiunea de restricţie temporală şi organizatorică. La nivelul prelucrărilor evenimentele descrise au mai ales o dominantă spaţială decât una temporală şi se completează nivelul conceptual răspunzând la întrebările cine? şi unde?. NIVELUL OPERAŢIONAL este o reprezentare a mijloacelor care vor fi efectiv folosite pentru a gestiona datele şi prelucrările şi constă în furnizarea soluţiilor tehnice răspunzând la întrebarea cum?. La nivelul datelor se va trece de la o clasă de soluţii la una singură. Aceasta se concretizeaza prin utilizarea unui anumit SGBD. Se face o alegere privind metodele de stocare şi de acces la informaţii. Se construieşte la acest nivel modelul fizic al datelor (MFD) care este transformarea modelului logic al datelor (MLD) prin echivalarea noţiunilor de tablou şi coloane cu noţiunile de relaţie şi atribute din modelul logic al datelor. La nivelul prelucrărilor se procedează la împărţirea proiectului în programe. Modelul operaţional va descrie arhitectura programelor care vor executa anumite funcţii, dar în nici un caz la acest nivel nu va exista o activitate de programare efectivă.


pagina 56

Fiecare din aceste nivele are ca obiectiv principal furnizarea unui anumit număr de documente care să permită sinteza procesului de gândire. Aceste documente, indispensabile elaborării, sunt leagate de cele rezultate din analiza datelor. Punerea în aplicare a modelelor de prelucrare la orice nivel, conceptual, organizaţional sau operaţional are nu numai scopul de a defini prelucrările de efectuat dar şi opţiunile alese în elaborarea modelelor datelor. Abordarea analizei cu ajutorul metodei MERISE se face după trei axe constituind ceea ce numim "cele trei cicluri". (Figura 4.2.) Analistul trebuie să parcurgă toate cele trei cicluri pe parcursul realizării sistemului. Aceste trei cicluri se desfăşoară simultan. 1.Ciclul de abstractizare este realizat prin formalismul celor trei nivele conceptual, organizaţional şi operaţional şi se va aplica asupra prelucrărilor şi datelor. 2.Ciclul de viaţă presupune trei mari etape: • concepţia sau perioada studiului sistemului existent

şi apoi a noului sistem; • realizarea care acoperă proiectarea şi exploatarea

sistemului; • întreţinerea care va permite sistemului să evolueze şi

să se adapteze modificărilor de mediu şi noilor obiective până în momentul în care nu va mai fi capabil de adaptare şi va fi inlocuit cu un nou sistem.

3.Ciclul de decizie care cuprinde toate deciziile luate pe parcursul desfăşurării proiectului, mai generale la început şi apoi din ce în ce mai precise.


Figura 4.2. Cele trei cicluri ale metodei Merise

Aceste noţiuni sumar prezentate se adresează

atât utilizatorilor (cei care solicită serviciile) cât şi informaticienilor (furnizorii de prestaţii). Eficacitatea şi validitatea unei analize constă în calitatea comunicaţiei dintre beneficiar şi proiectant iar calitatea comunicaţiei este obţinută, în parte, graţie utilizării corecte a unei metode de analiză.

pagina 57


pagina 58

4.2. Ciclul de viaţă În ţara noastră ultima reglementare metodologică în domeniul ciclului de viaţă cu aplicabilitate în economie şi având caracter de directivă aparţine Institutului Central de Infornatică şi datează din decembrie 1977. Conform acestei metodologii realizarea sistemelor informatice se desfăşoară în şase etape: elaborarea temei de realizare, elaborarea concepţiei sistemului informatic (proiectarea logică), proiectarea tehnică, elaborarea programelor, implementarea, exploatarea şi întreţinerea. 4.2.1. Elaborarea temei de realizare a sistemului

informatic. În această etapă iniţială se examinează posibilitatea realizării unui nou sistem informatic, sau modificării sistemului existent. Stimulul declanşator al acestei etape trebuie să fie de regulă viitorul beneficiar. Principala activitate în acest stadiu este cunoaşterea generală a problemei şi a obiectivelor care trebuie realizate, la un nivel care să permită să se stabilescă dacă este sau nu necesar să se treacă la etapa următoare. Elaborarea temei de realizare este etapa prin care se cunoaşte situaţia actuală, se furnizează un diagnostic şi se caută soluţiile posibile. În aceastaă etapă trebuie elaborată o soluţie independentă de mijloacele de realizare. Rezultatele acestei etape constau în "caietul de sarcini" şi "specificaţiile funcţionale generale".


pagina 59

De obicei această etapă, frecvent denumită şi studiu de oportunitate sau analiză preliminară implică timp şi efort relativ redus, doar din partea unor specialişti cu experienţă şi care au mai întocmit lucrări similare. Obiectivul principal al acestei etape este formularea cerinţelor informaţionale ale sistemului de conducere. Activităţile din cadrul acestei etape sunt : • studiul sistemului existent, • evaluarea sistemului existent, • evaluarea gradului de pregătire a întreprinderii, • formularea cerinţelor şi a restricţiilor pentru

realizarea sistemului informatic. În cadrul acestei ultime activităţi, cea mai importantă din prima etapă intră: • definirea obiectivelor şi performanţelor noului

sistem; • stabilirea domeniului şi funcţiunilor noului sistem

informatic; • definirea cerinţelor şi restricţiilor informaţionale pe

probleme şi funcţiuni; • estimarea resurselor disponibile pentru proiectarea,

implementarea şi exploatarea noului sistem. În realizarea etapizată a sistemului informatic tebuie, în primul rând, cunoscut sistemul existent. Echipa de proiectare trebiuie să aibă ca punct de plecare un tablou de probleme elaborat împreună cu conducerea întreprinderii. Pe baza acestuia se trece la studiul sistemului prin care se urmăreşte definirea caracteristicilor generale şi analiza activităţilor desfăşurate. De asemenea studiul sistemului presupune şi analiza modului în care sistemul informaţional asigură legăturile între sistemul conducător şi sistemul condus.


pagina 60

Pe baza concluziilor rezultate din studiul sistemului, se evaluează critic sistemul informaţional şi se formulează cerinţele şi restrictiile pentru realizarea sistemului informatic. Printre tehnicile şi metodele de analiza a sistemului existent se numară:

1. Tehnica documentării 2. Metoda analizei-diagnostic 3. Metoda diagramelor de flux informaţional 4. Metoda evidenţei economice 5. Metoda anchetelor 6. Metoda scenariilor

1. Tehnica documentării. Prin tehnica documentării se urmăreşte culegerea şi prelucrarea informaţiilor cu caracter teoretic şi practic privind sistemul studiat. Pentru atingerea acestui obiectiv, documentarea trebuie să se desfaşoare într-o ordine logică folosind ca instrument principal de lucru documentele care reglementează existenţa şi funcţionarea sistemului respectiv. Astfel de documente sunt: organigrama, regulamentul de organizare şi funcţionare, alte acte nomative. Prin organigramă sunt reprezentate grafic gruparea compartimentelor de muncă după criterii funcţionale, subordonarea acestora, repartizarea lor şi legăturile dintre compartimente. În acest mod organigrama vizualizează natura şi poziţia fiecărui compartiment. Ea reflectă obiectivele sistemului economic, responsabilităţile, delegările de autoritate şi legăturile funcţionale. Informaţiile cu caracter general obţinute prin analiza organigramei pot fi completate


pagina 61

prin studiul regulamentului de organizare şi funcţionare a sistemului. Aspecte de detaliu asupra modului de desfaşurare a activităţilor sunt completate prin parcurgerea actelor normative care reglementează prestarea lor. Analiza situaţiei existente este completată prin documentarea asupra unor studii şi proiecte informatice elaborate în alte întreprinderi cu profil apropiat. Rezultatele documentării urmează a fi sistematizate şi sintetizate pe domenii de probleme care apar în tabloul întocmit pe baza comenzii beneficiarului. 2.Metoda analizei-diagnostic. Această metodă îşi propune să furnizeze informaţii asupra sistemului existent. Analiza-diagnostic este o metodă colectivă de lucru aplicată de echipa de proiectare. Diagnosticul constă în relevarea anomaliilor manifestate în organizarea şi funcţionarea sistemului şi în stabilirea remediilor corespunzatoare. Prin cercetarea activităţilor desfăşurate se stabilesc direcţiile de dezvoltare pentru sistemul existent. Obiectivele analizei-diagnostic sunt: • Realizarea unui sistem de organizare şi conducere

perfecţionat flexibil la modificările care apar. Prin analiza-diagnostic urmează să se stabilească în ce măsură structura organizatorică satisface necesităţile conducerii şi posibilităţile de creştere a fiabilităţii sistemului prin tratarea automată a datelor.

• Prevenirea factorilor perturbatorii care generează efecte negative asupra sistemului economic sub aspect structural, funcţional şi al nivelului de performanţă.


pagina 62

• Identificarea căilor de restabilire a echilibrului, de compensare sau eliminare a factorilor perturbatorii. Acest obiectiv, cumulat cu cel precedent, poate fi îndeplinit prin abordarea globală a întreprinderii privită ca sistem dinamic, închis şi adaptabil.

• Concluziile analizei-diagnostic stau la baza analizei critice a sistemului existent şi sunt ghidul necesar realizării sistemului informatic.

Realizarea presupune luarea în considerare a următoarelor aspecte: • strategia de dezvoltare a întreprinderii; • condiţiile de materializare pe baza resurselor

disponibile; • priorităţi care se impun în funcţie de condiţii; În aplicarea metodei se recomandă parcurgerea următoarelor etape de lucru: • culegerea informaţiilor privind organizarea şi

funcţionarea sistemului existent; • formularea obiectivelor, care se realizează prin

conturarea ţelurilor urmărite şi a modalităţilor de realizare;

• enunţarea instrucţiunilor privind desfăşurarea acţiunilor;

• realizarea practică a instrucţiunilor; • analiza informaţiilor culese şi evaluarea rezultatelor; Dacă soluţiile rezultate nu sunt edificatoare asupra obiectivelor urmărite atunci analiza diagnostic se reia. Concluziile analizei-diagnostic, corelate cu rezultatele documentării, constituie baza cunoaşterii sistemului şi a posibilităţilor de perfecţionare. 3. Metoda diagramelor de flux informaţional. Identificarea caracteristicilor sistemului de conducere necesită detalierea analizei sistemului


pagina 63

informaţional. În acest scop se apelează la metoda diagramelor de flux a documentelor şi a momentelor lor de completare urmărind raţionalizarea sistemului informaţional şi ameliorarea funcţionării acestuia. Diagramele de flux informaţional dau o descriere sistemica a unui proces sau a unui ciclu de muncă cu suficiente detalii, care odată analizate pot duce la o îmbunătăţire a activităţii respective. Fiecare element component al diagramei este astfel reprezentat încât să ajute pe analist să-şi formeze o imagine clară asupra sistemului studiat. Majoritatea diagramelor combină reprezentarea scrisă cu cea grafică şi figurativă pentru a se asigura participarea deplină a tuturor persoanelor interesate. Schemele sunt instrumente excelente în prezentarea propunerilor de ameliorare a metodelor de muncă la toate nivelurile de conducere. 4. Metoda evidenţei economice. Evidenţa economică reprezintă un ansamblu de procedee şi tehnici de urmărire a fenomenelor şi proceselor care au avu loc în domeniul vieţii economice. Prin conţinut evidenţa economică este componenta majoră a sistemului informaţional economic. Orice operaţie de flux real al valorilor materiale şi băneşti trebuie să se găsească consemnată în documentele de evidenţă economică. După procedeele şi tehnicile folosite în investigarea realităţii economice evidenţa economică se constituie în trei forme distincte: a)- evidenţa tehnico-operativă b)- evidenţa contabilă c)- evidenţa statistică


pagina 64

a) Evidenţa tehnico-operativă constă în consemnarea şi centralizarea datelor privind procesele şi fenomenele economice la locul şi în momentul producerii lor. Evidenţa tehnico - operativă furnizează informaţii necesare conducerii operative.

b) Evidenţa contabilă sau contabilitatea urmăreşte

formarea existenţa şi folosirea mijloacelor economice şi a surselor lor de formare. Prin conţinut contabilitatea este cea mai importantă componentă a evidenţei economice. Ea asigură continuitatea circuitului informaţional între evidenţa tehnico-operativă şi cea statistică şi este principala sursă de informaţii a conducerii tactice şi strategice.

c) Evidenţa statistică sau statistica oglindeşte şi caracterizează procesele în ansamblul lor prin studierea unor fenomene social-economice de masă. Cu ajutorul statisticii se poate studia evoluţia unor fenomene în perioadele anterioare pentru a determina evoluţia lor viitoare.

5.Metoda anchetelor. Prin această metodă se culeg informaţii cantitative şi calitative pe domenii şi probleme fiind o metodă de investigare analitică. Pentru ca investigarea să ducă la rezultate concludente, în aplicarea tehnicilor este necesar să se aibă în vedere următoarele principii: • selectarea persoanelor de interogat având în vedere

poziţia lor în sistem şi competenţa lor profesională; • antrenarea subiecţilor aleşi la emiterea de idei noi

privind modul de desfăşurare a activităţilor; • acceptare ideilor emise fară o judecată imediată a

valorii lor;


pagina 65

• stimularea gândirii participanţilor prin formularea de întrebări adecvate;

• verificarea rezultatelor prin îmbinarea modului de aplicare al tehnicilor;

Respectarea acestor principii asigură luarea în considerare a comportamentului subiectilor investigaţi, şi în consecinţă, culegerea de informaţii critice asupra stării şi funcţionării sistemului. Metoda anchetelor se constituie dintr-un complex de tehnici cu caracter interogativ cum sunt: A) tehnica chestionarului B) tehnica interviului C) tehnica observării directe A. Tehnica chestionarului presupune utilizarea chestionarului ca instrument de culegere a informaţiilor referitoare la obiectivele analizei. Întocmirea chestionarului cuprinde trei faze distincte: 1. Faza pregatitoare, în care se delimitează cu

exactitate obiectivele chestionării. Astfel de obiective pot fi: a) analiza activităţilor de bază; b) principali indicatori economici folosiţi; c) identificarea caracteristicilor sistemului de

conducere; d) identificarea metodelor şi tehnicilor folosite în

prelucrarea datelor. În această fază este necesar să se indice gradul de detaliere a informaţiilor şi modul de prelucrare ulterioară. 2. Faza de întocmire a chestionarului.


pagina 66

În funcţie de obiective şi subiecţii ce urmează a fi supuşi chestionării, se stabilesc numărul şi tipul de întrebări. Numărul mediu de întrebări într-un chestionar trebuie să fie cuprins între 15 şi 20. Un număr prea mic de întrebări nu poate furniza informaţiile dorite şi nu justifică efortul făcut pentru organizarea chestionarului, iar un număr prea mare de întrebări oboseşte subiectul chestionat ceea ce duce la emiterea de răspunsuri pripite, neconcludente pentru analiza de sistem. Activarea subiecţilor se poate asigura prin folosirea mai multor tipuri de întrebări, cum sunt: • întrebări închise, cu un număr redus de răspunsuri

precodificate prin care subiecţii se pronunţă asupra unor informaţii culese prin alte metode şi tehnici;

• întrebări factuale asupra unor fapte obiective, de verificare a aptitudinilor, de identificare a unei stări de fapt, de clarificare a unor aspecte ale analizei;

• întrebări deschise la care numărul răspunsurilor poate varia de la un subiect la altul.

După locul ocupat în chestionar, întrebările se grupează astfel: • introductive, în problema analizată; • "de filtru" prin care se precizează condiţionarea între

întrebări; • de bifurcare prin care se identifică numărul

întrebărilor la care se va răspunde în continuare dacă s-a răspuns afirmativ la întrebarea anterioară şi numărul întrebărilor înlănţuite în cazul în care răspunsul anterior a fost negativ;

• de motivare a unor răspunsuri; • de control a exactităţii răspunsurilor şi de identificare

a subiectului chestionat. Pentru ca formularea întrebărilor să fie corectă şi corespunzatoare realizării obiectivelor, la această


pagina 67

acţiune trebuie să participe, pe lângă informaticieni sociologi, psihologi, statisticieni. 3. Faza de verificare a chestionarului.

Prin testări se urmăreşte modul în care rezultatele chestionării concordă cu obiectivele investigaţiei. În funcţie de constatările faptice, se corectează formularea întrebărilor şi ordinea lor în chestionar. În întocmirea şi completarea chestionarului este recomandată respectarea următoarelor reguli:

• formularea simplă, clară, concisă şi explicită a întrbărilor;

• asigurarea libertăţii subiecţilor de a completa sau nu chestionarul printr-o întrebare introductivă;

• evitarea formulării de întrebări tendenţioase, ipotetice, prezumptive, insuficient de clare;

• asigurarea unei succesiuni logice a întrebărilor; • schimbarea ordinii răspunsurilor precodificate în

formulare pentru a se elimina tendinţa de alegere a primului răspuns;

• includerea în chestionar a unor întrebări de control prin care să se asigure veridicitatea răspunsurilor.

Completarea chestionarului de un număr reprezentativ de subiecţi, asigură obţinerea de informaţii relevante pentru analiza sistemului. B. Tehnica interviului Prin această tehnică se urmăreşte obţinerea într-un interval de timp redus, de informaţii privind orientările practice, metodele şi strategiile existente sau preconizate în rezolvarea problemelor analizate.


pagina 68

Interviul asigură obţinerea de informaţii recente şi verificarea informaţiilor obţinute prin alte metode sau tehnici. Alegerea subiectilor de intervievat se face având în vedere următoarele constatări practice: • persoanele care ocupă poziţii medii în ierarhia

structurii organizatorice furnizează informaţiile cele mai apropiate de realitate;

• colectarea de informaţii corecte presupune intervievarea nu numai a personalului de conducere ci şi a celui de execuţie;

• competenţa subiecţilor trebuie verificată în prealabil;

• lipsa unei atitudini critice poate să semnifice reţineri în exprimarea ideilor.

Procedura de aplicare a interviului cuprinde trei etepe: 1. Etapa pregătitoare constă în următoarele:

• însuşirea terminologiei utilizate în domeniul studiat;

• formularea şi coordonarea întrebărilor; • cunoaşterea prealabilă a subiecţilor; • alegerea momentelor propice pentru luarea

interviului (de obicei, partea medie a perioadei de activitate).

2. Etapa de desfăşurare a interviului. În această etapă se

cer a fi respectate următoarele reguli: • menţinerea discuţiei în limitele problemei

analizate, • acordarea unor momente de gândire, • formularea de întrebări ajutătoare, • evitarea consemnării de răspunsuri fără

argumentaţie • insistarea asupra aspectelor neclare


pagina 69

• sesizarea stărilor de reţinere în a critica aspectele negative ale activităţii analizate;

• evitarea discuţiilor în contradictoriu; • solicitarea de recomandări şi din partea altor

persoane competente din domeniul analizat. 3. Etapa de culegere şi prelucrare a informaţiilor se realizează prin consemnarea în raportul de interviu a răspunsurilor cu precizarea aspectelor neclarificate şi a posibilităţilor de completare a rezultatelor. Concluziile interviului reflectă starea elementelor sau a proceselor analizate şi posibilităţile de remediere a deficienţelor existente. C. Tehnica observării directe. Observarea directă a activităţilor, asigură cunoaşterea nemijlocită a sistemului existent. Prin tehnica observării directe se studiază sarcinile care formează conţinutul unei activităţi. În analiza actvităţii de producţie, spre exemplu, prin consemnarea operaţiilor efectuate asupra produsului şi a timpilor de execuţie se conturează structura ciclului de fabricaţie şi alte aspecte ale producţiei cum sunt:

• tipuri de produse fabricate • tehnologii aplicate • locuri de muncă • dotarea cu utilaje

Dacă obiectivele propuse prin observarea directă sunt clar precizate, atunci aplicarea acestei tehnici duce la concluzii reale care nu pot fi obţinute prin alte metode. Tehnica observării directe foloseşte instrumente specifice de lucru:


pagina 70

• sondaje • cronometrări • analiza posturilor ( locurilor de muncă)

Prin aplicarea acestora se relevă stări de fapt şi posibilităţi pentru ameliorarea funcţionarii sistemului.

În cadrul anchetelor combinarea tehnicilor menţionate asigură clarificarea problemelor de rezolvat prin cunoaşterea detaliată a sistemului şi obţinerea de informaţii privind posibilităţile de raţionalizare a activităţilor. Rezultatele relevă deficienţele existente şi impiicaţiile tratării automate a datelor. 6.Metoda scenariilor. Metoda scenariilor se bazează pe un ansamblu de procedee şi instrumente prin care se stabileşte succesiunea logică a evenimentelor, în scopul de a arăta cum se poate evolua pas cu pas spre o situaţie viitoare plecând de la situaţia actuală. Pentru fiecare alternativă se urmăreşte evoluţia sistemului reperându-se noi puncte nodale. Prin abordarea globală a sistemului sunt elaborate scenarii calitative care stau la baza elaborării scenariilor cantitative. Situaţia cercetărilor previzionare la nivel global se justifică prin aceea că evenimentele care depind de fenomene generale sunt, pe termen lung, mai uşor de prevăzut decât acelea care depind de circumstanţe particulare.

Obiectivele principale urmărite prin aplicarea metodei scenariilor sunt: • predicţia dezvoltării, a evoluţiei unor fenomene şi

procese;


pagina 71

• stimularea gândirii în studiul unei probleme decizionale;

• analiza detaliată a aspectelor dinamice. În realizarea acestor obiective se urmăreşte parcurgerea următoarelor etape de lucru:

1. Stabilirea obiectivelor concrete ale cercetarii.

• starea spre care se speră că pot fi dirijate evenimentele;

• alegerea variantelor ce se ramifică din punctele nodale.

2. Studiul contextului în care se va dezvolta sistemul. • reprezentarea factorilor de influenţă şi impactul

lor asupra sistemului; • la baza elaborării modelelor vor sta seriile

dinamice ale indicatorilor ce reflectă acţiunea factorilor.

3. Scrierea scenariilor prin abordare globală şi descrierea evoluţiei sistemului în dinamică, ţinând cont de modificările care apar în structura sistemului.

4. Stabilirea tendinţelor în funcţie de care va evolua sistemul, dacă asupra lui nu se exercită acţiuni voluntare externe.

5. Extragerea rezultatelor prin reţinerea acelor tendinţe manifestate care corespund obiectivelor propuse.

4.2.2. Proiectarea logică (elaborarea concepţiei sistemului informatic). Obiectivul acestei etape îl constituie elaborarea proiectului de ansamblu al sistemului informatic, pe baza cerinţelor şi restricţiilor formulate în tema de realizare. Scopul acestei etape constă în determinarea obiectivelor detaliate şi cerinţelor noului sistem. Determinarea cerinţelor se face prin studiul organizaţiei


pagina 72

pe care o va servi sistemul, accentul punându-se pe beneficiile pe care le va aduce sistemul propus. Principalele activităţi care se desfăşoară în cadrul etapei de concepţie a sistemului informatic sunt următoarele: • definirea sistemului informatic, cuprinzând

delimitarea ariei şi a legăturilor sale externe; estimarea dimensiunilor sistemului; definirea structurii logice a datelor şi definirea proceselor de prelucrare a datelor;

• adoptarea soluţiei de principiu pentru codificarea datelor şi conversia fişierelor;

• proiectarea de principiu a noului flux informaţional; • stbilirea necesarului de echipamente, configuraţiile

necesare, precum şi modul de procurare a echipamentelor;

• stabilirea condiţiilor de montaj, funcţionare şi exploatare;

• centralizarea cheltuielilor de dotare; • stabilirea necesarului de produse program noi; • structurarea sistemului informatic pe componente,

cu luarea în considerare a mai multor variante; • definirea intrărilor, ieşirilor, şi prelucrărilor necesare; • elaborarea graficului de eşalonare pentru proiectarea

şi implementarea componentelor sistemului; • evaluarea efectelor pe care le va produce noul sistem

informatic; • estimarea eficienţei economice. • măsuri pregătitoare pentru realizarea sistemului;

Activtatea cea mai importantă în cadrul elaborării concepţiei sistemului informatic este analiza circuitului informaţional. Aceasta înseamnă că fluxurile parţiale urmează a primi coerenţă prin studiul legăturilor şi prelucrărilor înlănţuite. În acest fel este posibil să se


pagina 73

delimiteze cu claritate graniţele sistemului informatic şi legăturile sale externe.

Aplicarea metodelor de analiză a circuitului informaţional se bazează pe următoarele constatări practice: • fiecare activitate are un circuit informaţional propriu;

delimitarea sistemului informatic presupune analiza distinctă a fiecărei activităţi;

• analiza fiecărei activităţi este condiţionată de cunoaşterea obiectivelor sistemului economic şi de reglementările care definesc sistemul informaţional;

• în activitatea de gestiune economică operaţiile de prelucrare a datelor nu sunt diversificate şi au caracter ciclic (operatiile aritmetice şi logice simple reprezintă circa 80% din totalul operaţiilor de prelucrare);

• pentru fiecare activitate, intrările condiţioneaza şi sunt condiţionate de ieşirile informaţionale;

• prelucrarea datelor de intrare specifice unei activităţi în scopul obţinerii ieşirilor dorite defineşte transformările informaţionale şi determină circuitul informaţional al activităţii;

Stabilirea ieşirilor şi intrărilor informaţionale sunt determinante în organizarea datelor, în timp ce transformările informaţionale determină organizarea prelucrărilor. Bazate pe aceste constatări, metodele de analiză a sistemului informaţional şi de delimitare a ariei şi a legăturilor externe ale sistemului informatic mai des utilizate sunt: 1 - metoda analizei ieşirilor; 2 - metoda orientată pe activităţi; 3 - metoda răspunsului la stimuli; 4 - metoda compartimentală; 5 - metode analizei celulare.


pagina 74

1. Metoda analizei ieşirilor. Metoda analizei ieşirilor constă în parcurgerea fluxurilor informaţionale invers, de la informaţia finală (de ieşire) spre informaţia iniţială (de intrare). Aceasta analiză se face pe baza diagramelor de flux informaţional. Prin parcurgerea întregului circuit informaţional, se determină:

• volumul datelor de ieşire; • volumul datelor de intrare; • prelucrările efectuate pe parcursul circuitului; • purtătorii de informaţie; • caracteristicile datelor.

Metoda analizei ieşirilor permite obţinerea unei imagini complete asupra circuitului informaţional. Totodată, pot fi remarcate deficienţe de circuit şi posibilităţi de raţionalizare a sistemului informaţional. 2. Metoda orientată pe activităţi. Prin aplicarea acestei metode se urmăreşte definirea completă a aspectelor informaţionale care caracterizează fiecare activitate. Parcurgerea fluxurilor informaţionale pe fiecare activitate asigură cunoaşterea detaliată a sarcinilor şi a operaţiilor care definesc activităţile. Analiza unei activităţi se face independent de celelalte, redând caracteristicile şi intercondiţionările interne ale activităţii. Metoda orientată pe activităţi este eficientă în sisteme în care se manifestă autonomia activităţilor prin relaţii de interdependenţă reduse.


pagina 75

3. Metoda răspunsului la stimuli. Metoda răspunsului la stimuli are ca punct de plecare un stimul oarecare, cum ar fi: o comandă, un produs, o fază de fabricaţie etc. Analizând amănunţit stimulul, se stabilesc legăturile dintre activităţi şi compartimentele întreprinderii. După identificarea stimulilor la care trebuie să se raspundă, se determină compartimentele implicate şi documentele la care se referă stimulul. În continuare se urmăreşte fluxul principal al informaţiilor cu stabilirea punctelor în care apar ramificaţii şi identificarea punctelor de control. Analiza se completează cu studiul fluxurilor secundare. Pentru activităţi complexe, metoda răspunsului la stimuli asigură observarea conexiunilor şi demarcarea operaţiilor principale de cele secundare. 4. Metoda compartimentală. În aplicarea metodei compartimentale se stabilesc acţiunile care se realizează într-un compartiment şi legăturile compartimentului studiat cu celelalte compartimente. Pentru activităţi sau părţi din activităţile desfăşurate în compartiment se determină intrările, prelucrările şi ieşirile informaţionale necesare realizării sarcinilor compartimentului. Metoda compartimentală este aplicabilă în întreprinderi în care compartimentele prezintă o autonomie mai mare în cadrul structurii organizatorice. 5. Metoda analizei celulare. La baza metodei analizei celulare stă principiul de ierarhizare a componentelor sistemului informaţional


după gradul lor de complexitate. Fiecărei componente de tip subsistem i se asociază un rang. Subsistemul de rang zero este componenta elementară şi se numeşte celulă. Pentru o celulă C intrările X={x1,x2,....,xn}, ieşirile Y={y1,y2,..,ym} şi transformările T ale intrărilor în ieşiri definesc celula respectivă:

C = { X , Y , T } Dacă ieşirea celulei i constituie intrare pentru celula j, atunci Ci şi Cj formează un lanţ notat simbolic:

L = { Ci , Cj }

Figura 4.3. Lanţ de celule

Mărimile Yi şi Xj (ieşirile din celula i şi intrările în celula j) desemnează acelaşi element. Această dublă semnificaţie constituie o redundanţă informaţională. Reducerea unor asfel de redundanţe se face prin introducerea conceptului de generaţie. Elementul Xj este un operand de generaţia j. Ca urmare a transformării efectuate în celula j, apare generaţia j+1 de operanzi ceea ce se exprimă prin relaţia:

pagina 76 Xj+1,r = T Xj,r


în care r semnifică numărul de ordine al operandului în cadrul generaţiei.

Figura 4.4. Generaţii de operanzi

Două sau mai multe lanţuri de celule care au cel puţin un punct comun, formează un arbore de celule:

A = { Lk , Lm } Doi sau mai mulţi arbori legaţi în serie, paralel sau mixt formează o structură complexă. (Figura 4.5.) Convenţii: • operanzii primari (datele primare) constituie operanzi

de generaţia zero. ( X01, X02, X03, X04); • transformările operanzilor de generaţia zero

formează familia de operatori de generaţia 1 (T11, T12, T13);

• celulele sunt reprezentate de operatorii lor prevăzuţi cu doi indici; primul indică generaţia, iar al doilea numărul de ordine al operatorului în cadrul familiei;

• ieşirile unui operator sunt de aceiaşi generaţie cu operatorul, indiferent de generaţia intrărilor;

• operatorii în lant sunt de generaţii monoton crescătoare;

pagina 77


• un operand poartă o singură pereche de indici chiar şi când constituie intrări pentru mai mulţi operatori de aceiaşi generaţie sau de generaţii diferite.

Figura 4.5. Arbore de celule La nivelul întreprinderii un operator se constituie din reguli de lucru al căror suport fizic poate fi material sau imaterial. Celula în care acţionează un operator se delimitează în funcţie de necesităţile analizei celulare. Eficienţa metodei creşte prin combinarea aplicării ei cu alte metode.

pagina 78

Codificarea datelor. Premiza principală a realizării de componente viabile ale sistemului informatic, cu parametri superiori de exploatare este codificarea datelor care urmează a fi prelucrate cu echipamentele de calcul. O metodologie adecvată de codificare contribuie în mare măsură la realizarea eficienţei scontate pentru întregul sistem informatic. Aceasta asigură eliminarea


pagina 79

volumului mare de redundanţă informaţională şi raţionalizarea procesului de tratare a datelor.

Operaţia de codificare a datelor constă în stabilirea unei corespondente biunivoce între elementele sistemului informaţional (documente, operaţii, produse, materiale etc.) şi o multime de simboluri (cifre, litere etc.). Datele de codificat constituie vocabularul de intrare, iar simbolurile de reprezentare formeaza limbajul de codificare. Rezultatele codificarii se concretizează în sisteme de coduri care semnifică alfabetul de ieşire.

Desfăşurarea operaţiei de codificare presupuue respectarea următoarelor principii:

• adoptarea aceloraşi norme în determinarea

vocabularului de intrare; • folosirea unui limbaj de codificare accesibil, astfel

încât interpretarea alfabetului de ieşire să se facă fără dificultăţi;

• respectarea biunivocităţii între vocabularul de intrare şi limbajul de codificare. În finalul codificării, la fiecare element al vocabularului trebuie să corespundă un cod unic determinat;

• previziunea evoluţiei codurilor care să asigure posibilitatea actualizării sistemelor de coduri fără perturbaţii;

• sistemele de coduri adoptate să fie sugestive în redarea legăturilor dintre fenomene, procese şi documente;

• adaptarea codificarii în vederea prelucrării electronice a datetor.

Între codurile interne sistemului economic şi codurile folosite în economia naţionala, urmează a se stabili modalităţi de conversie care să asigure obţinerea ieşirilor informaţionale necesare în exterior.


pagina 80

Într-o abordare metodologica, codificarea constă în următoarele activităţi: A. Stabilirea caracteristicilor generale ale codurilor. • Determinarea vocabularului de intrare şi a

caracteristicilor acestuia. • Analiza structurii informaţiilor din vocabularul de

intrare pentru fixarea structurii generale a codului pe grupe de elemente ale sistemului informaţional. Necesităţile de prelucrare impun utilizarea de coduri prin care să se indice locul de stocare sau de utilizare conturile în care se consemnează natura şi apartenenţa elementelor codificate.

• Determinarea alfabetului de ieşire în funcţie de mărimea vocabularului de intrare şi de structura generală a codurilor. Codurile care definesc alfabetul de ieşire, trebuie să conţină un minimum de simboluri de reprezentare.

• Fixarea sistemelor de coduri astfel încât acestea să asigure maximum de uniformitate a codificării.

Principalele sisteme de coduri utilizate sunt: 1. Sistemul în ordine numerică (naturală) este utilizat

pentru elemente temporare ale sistemului, fără periodicitate. Orice element nou apărut afectează întregul sistem de coduri.

2. Sistemul în serie este o dezvoltare a sistemului în ordine naturală prin rezervarea de numere pentru eventuale apariţii de noi elemente în vocabularul de intrare.

3. Sistemul pe grupe constă în atribuirea unui anumit număr de coduri fiecărei clase de elemente de reprezentat. În general codul ijk (i = 1, m ; j = 1, n ;


pagina 81

k = 1, p) indică grupa i subgrupa j şi sortimentul k al elementului reprezentat.

4. Sistemul zecimal presupune divizarea vocabularului de intrare în zece grupe iar fiecare grupă în zece subgrupe s.a.m.d. În practica economică acest sistem este adoptat pentru codificarea conturilor de evidenţă.

5. Sistemul în şah se bazează pe construirea de tabele în care fiecare dimensiune specifică o caracteristică a elementelor de reprezentat, iar elementele tabelului sunt numere în ordine naturală. Aplicarea sistemului este recomandabilă pentru clase de elemente care rămân neschimbate, ca spre exemplu, pentru codificarea pieselor şi subansamblelor unui utilaj.

6. Sistemul repetitiv constă în realizarea codului din caracteristicile elementelor de codificat. Sfera sistemului este limitată la un vocabular de intrare mai puţin complex;

7. Sisteme combinate cum ar fi: sistemul în ordine naturală pentru clase ale vocabularului de intrare, sistemul în serie pentru grupe şi sistemul repetitiv pentru elemente.

8. Sisteme binare prin care se asociaza cifre binare elementelor vocabularului de intrare. Construirea codurilor se bazează pe algebra booleeana şi pe conceptele teoriei mulţimilor. Sistemele binare au o largă aplicare în codicarea datelor de intrare în prelucrarea electronică. Spre exemplu, sistemul EBCDIC de reprezentare a datelor pe 8 biti şi sistemul ASCII de reprezentare a datelor pe 7 biti sunt cele mai folosite.

Dată fiind importanţa codurilor în efectuarea prelucrării datelor, o atenţie deosebită trebuie acordată corectitudini fiecărui cod utilizat. În acest scop la cod se adaugă o cifră de control care să permită verificarea


pagina 82

corectitudinii accstuia în orice moment al tratării informaţiei reprezentate. Cifra de control se stabileşte după algoritmi diferiţi. B. Clasificarea elementelor vocabularului de intrare de la general la particular până la nivel elementar cu respectarea normelor legale. Operaţiile şi documentele se grupează după locul şi rolul lor în sistem, materialele după natură, proprietăţi, mod de gestionare. C. Precizarea termninologiei standard de codificare la care se pretează fiecare clasă de elemente a vocabularului de intrare. D. Codificarea propriu-zisă prin stabilirea corespondenţei între vocabularul de intrare şi alfabetul de ieşire. E. Unificarea terminologiei şi atribuirea codurilor. În toate documentele de uz intern urmează a se atribui coduri elementelor sistemului informaţional. F. Actualizarea codurilor constă în adăugări de coduri pentru elementele nou intrate în sistem şi în eliminări de coduri perimate pentru elemente care nu se mai utilizează. Estimarea eficienţei economice a sistemelor informatice. Asimilarea lucrărilor de realizare a unui sistem informatic cu lucrările de investiţii, face ca determinarea şi urmărirea eficienţei să fie un aspect major al realizării sistemului informatic. Obiectivul global urmărit este creşterea efectului util al fiecărui leu cheltuit.

Eficienţa, ca raport între efectul util şi efortul făcut pentru obţinerea efectului scontat, se urmăreşte sub aspecte multiple. (productivitatea muncii, indici de utilizare ai resurselor, norme de consum, etc.)


pagina 83

Din punct de vedere informaţional, satisfacerea nevoilor de informare ale conducerii, entropia informaţională, costul informaţiei, redau eficienţa sistemului informaţional. În consecinţă, aspectele de eficienţă se referă nu numai la resursele şi efectele imediate ale realizării unei investiţii; prin studiul cheltuielilor necesare şi al efectelor directe şi indirecte pe o perioadă mai mare de timp. Ele includ şi urmărirea fiabilităţii obiectivului investiţiei după darea lui în exploatare. Evaluarea cheltuielilor. Cheltuielile de realizare a sistemului informatic se constituie din cheltuielile de investiţii necesare elaborării şi introducerii sistemului informatic. În cheltuielile de exploatare se includ şi cele necesare întreţinerii sistemului în scopul creşterii performanţelor acestuia. În etapa de analiză şi proiectare a sistemului informatic, sunt angajate cheltuieli curente cu salariile echipei de proiectare (în situaţia când proiectarea se face cu forţe proprii).

Declanşarea activităţilor de conconceptie, implică efectuarea de cheltuieli pentru pregătirea cadrelor proprii de informatică ce vor asigura exploatarea sistemului.

De asemenea, încă din această etapă de lucru, apare necesară pregătirea psiho-socială a personalului întreprinderii asupra utilităţii sistemului informatic. În acest scop sunt necesare cheltuieli cu desfăşurarea de prezentări demonstrative privind avantajele prelucrării automate a datelor şi implicaţiile scontate. Scopul unor astfel de acţiuni este de a se asigura din timp participarea activă a personalului la realizarea schimbărilor pe care le va genera introducerea sistemului informatic, evitându-se opoziţia surdă a celor vizaţi să fie atinşi de noua tehnologie.


pagina 84

O categorie importantă de cheltuieli este cea a cheltuielilor cu tehnica de calcul, care cuprinde în afară de cheltuielile pentru achizitionarea şi instalarea echipamentelor (hardware) şi cheltuieli cu procurarea şi adaptarea unor aplicaţii tip şi a unor produse-program generalizabile (software). Aceasta asigură încă de la început, scurtarea perioadei de analiză-proiectare, reducerea efortului de programare şi creşterea performanţelor de exploatare a sistemului informatic.

Cheltuielile pentru realizarea sistemului informatic se împart în: 1. cheltuieli iniţiale ( Ci ):

• cheltuieli pentru promovarea noii soluţii; • cheltuieli pentru analiză şi proiectare; • cheltuieli pentru procurarea şi adaptarea

produselor software tipizate; • cheltuieli pentru procurarea configuraţiei

hardware; • cheltuieli pentru amenajarea spaţiilor necesare

instalării echipamentelor. 2. cheltuieli de exploatare ( Ce ):

• cheltuieli cu salariile personalului de informatică; • cheltuieli pentru perfecţionarea pregătirii

personalului; • cheltuieli cu materialele consumabile şi cu

amortizarea tehnicii de calcul; • cheltuieli cu întreţinerea curentă şi reparaţii; • cheltuieli pentru întreţinerea software a

sistemului informatic (adaptarea sistemului informatic).


Din categoria cheltuielilor iniţiale cea mai mare pondere o reprezintă cheltuielile cu proiectarea sau cu procurarea aplicaţiilor tipizate grupate în cheltuieli cu software-ul şi cheltuieli cu achiziţia echipamentelor care constituie cheltuielile cu hardware-ul. Analiza evoluţiei raportului acestor cheltuieli pe o perioadă lungă de timp este consemnată în figura 4.6.

Figura 4.6. Ponderea cheltuielilor cu hardware-ul şi

software-ul într-un sistem informatic

Din punctul de vedere al eşalonării pe parcursul ciclului de viaţă al sistemului cheltuielile cu hardware-ul sunt grupate preponderent la începutul perioadei de realizare a sistemului informatic, iar cheltuielile cu software-ul au o repartizare diferită pe durata ciclului de viată. Tema de realizare consumă aproximativ 5% din totalul cheltuielilor cu proiectarea, proiectarea logică şi

pagina 85


pagina 86

proiectarea tehnică mai consumă încă 35% din resurse, pentru elaborarea programelor şi testarea lor se mai cheltuiesc 40% din fonduri iar pentru implementare 20%. Aceste procente sunt relative la costurile de proiectare, care la rândul lor reprezintă doar 20% din totalul costului sistemului pe parcursul întregului ciclu de viaţă. Cheltuielile pentru exploatare şi întreţinere sunt în mare măsură dependente de stabilitatea mediului economic în care este implementat dar se estimează că aceste cheltuieli se ridică la aproximativ 80% din costul total al sistemului. Evaluarea efectelor. Introducerea şi exploatarea sistmului informatic generează efecte directe şi indirecte, care pot fi estimate prin indicatori cantitativi şi calitativi. Stabilirea efectelor economice cantitative se realizează prin determinarea factorilor care contribuie la modificarea mărimii cheltuielilor de producţie pe elemente primare sau pe articole de calculaţie ale costului de producţie ca urmare a prelucrării electronice a datelor pe perioada de viaţă a sistemului informatic. Aceste efecte se materializează în economii de resurse materiale şi umane. La materii prime şi materiale de bază, rezultă economii prin calcularea şi urmărirea normelor şi a consumurilor specifice cu ajutorul tehnicii de calcul. Pentru materialele auxiliare, economiile rezultă printr-o mai bună dimensionare a stocurilor şi prin urmărirea exactă a consumurilor. Estimarea cheltuielilor de transport-aprovizionare se face în raport cu implicaţiile sistemului informatic asupra reducerii timpului pentru aprovizionare. La salarii, calculul economiilor se bazează pe estimarea economiilor relative de personal tehnic, economic, administrativ prin evaluarea volumului de muncă înainte şi după introducerea sistemului informatic.


pagina 87

Relaţia de calcul este următoarea:

Ep = Ne * (Mn/Mv - 1) * N/T în care: • Ep este economia de personal; • Mv este volumul de muncă înainte de introducerea

sistemului informatic; • Mn este volumul de muncă după introducerea

sistemului informatic; • Ne este numărul de lucrători pentru exploatarea şi

întreţinerea sistemului informatic; • N este numărul lunilor de funcţionare a sistemului

informatic; • T este durata ciclului de prelucrare electronică a

datelor, în luni. Economia relativă de personal este privită pe durata de existenţă a sistemului informatic, este exprimată şi cu ajutorul ponderii lucrărilor din evidenţa economică în condiţiile prelucrării electronice a datelor faţă de prelucrarea în sistem manual. Prin centralizarea economiilor de personal rezultă economii la fondul de salarii. Coeficientul de reducere relativă a fondului de salarii se aplică şi contribuţiei privind asigurările sociale şi fondului de şomaj. La suma economiilor enunţate mai sus se adaugă cele obţinute ca urmre a gestiunii raţionale a tuturor resurselor financiare. În categoria efectelor economice cantitative se adaugă profitul suplimentar. În calcule, punctul de plecare îl constituie stabilirea sporului de producţie ca urmare a funcţionării sistemului informatic. Relaţiile de calcul sunt următoarele:


pagina 88

Sp = Q1 * N * Kf - Q0 * N + Spe unde: • Sp este sporul de producţie ca urmare a funcţionării

sistemului informatic; • Q0,Q1 reprezintă valoarea producţiei înainte şi

respectiv după introducerea sistemului informatic; • N este numărul de ani estimat pentru funcţionarea

sistemului informatic; • Kf este coeficientul modificării valorii mijloacelor de

producţie în primul an de funcţionare a sistemului informatic faţă de anul precedent;

• Spe este sporul efectiv a valorii producţiei pe durata exploatării sistemului informatic.

Calculul profitului suplimentar (Ps) datorat introducerii sistemului informatic se face având în vedere profitul scontat ce se obţine în primul an de aplicare a sistemului informatic (P1) profitul normat (Pn) exprimat în mărimi relative:

Ps = P1 * Sp / Q1 sau

Ps = Pn * Sp

Aplicarea modelelor de normare a costurilor permite ca determinarea economiilor şi a profitului suplimentar să se realizeze global prin abaterea dintre preţul normat şi preţul efectiv înainte şi după introducerea sistemului informatic. La cheltuielile variabile, după determinarea mărimii influenţei factorilor cantitativi şi calitativi, abaterea


pagina 89

suplimentară semnifică influenţa introducerii sistemului informatic asupra costului productiei. Pentru cheltuielile fixe, creşterea gradului de automatizare a producţiei duce la obţinerea de economii prin accentuarea tendinţei de scădere a cheltuielilor fixe pe unitatea de produs.

Pe lângă efectele economice cantitative menţionate, funcţionarea sistemului informatic generează efecte indirecte (calitative) cum sunt: • îmbunătăţirea formei şi a conţinutului documentelor

tehnice şi economice; • raţionalizarea sistemului de evidenţă economică; • orientarea personalului din compartimentele

funcţionale de la activităţi de rutină spre activităţi de concepţie;

• îmbunătăţirea controlului asupra activităţii de gestiune economică;

• transformarea informaţiei privind costul producţiei în instrument de reglare operativă;

• creşterea posibilităţilor de analiză economico-financiară.

Dată fiind amploarea şi complexitatea lucrărilor din domeniul informaticii, se impune elaborarea unui buget pentru această activitate constituit din:

• bugetul investitiilor; • buget de exploatare; • buget de încasări şi cheltuieli.

Bugetul informatic asigură estimarea detaliată a efortului şi efectelor elaborarii, introducerii şi exploatării sistemului informatic. De asemenea prin buget se realizeaza eşalonarea resurselor şi a modului lor de utilizare pe etape, perioade şi responsabilităţi.


pagina 90

Estimarea eficienţei globale. Eficienţa globală a sistemului informatic este exprimată prin indicatorii: • coeficientul de eficienţă globală (Ke);

Ke = (Ec + Ps) / (Ci + Ce)

• durata de recuperare a cheltuielilor (Dr).

Dr = 1 / Ke

unde: • Ec este suma economiilor rezultate din funcţionarea

sistemului informatic; • Ci sunt cheltuielile iniţiale; • Ce sunt cheltuielile de exploatare; • Ps este profitul suplimentar.

Reducerea cheltuililor cu caracter informatic constituie calea principală de creştere a eficienţei sistemului informatic. Cu cât durata de recuperare a cheltuielilor cu caracter informatic este mai mică, cu atât profitul suplimentar este mai mare ca urmare a faptului că în perioada dintre momentul recuperării cheltuielilor şi abandonarea folosirii sistemului informatic, economiile se transformă în profit. Eficienţa globală creşte şi ca urmare a prelungirii duratei de viaţă a sistemului informatic.

Din punct de vedere organizatoric, eficienţa sistemului informatic se poate determina cu ajutorul indicatorul "entropia informaţională" (H) prin care se măsoară gradul de nedeterminare pe care îl înlătură informaţiile din sistem. Diferenţa dintre entropia informaţională calculată înainte şi după introducerea


pagina 91

sistemului informatic, semnifică, în cifre absolute, creşterea gradului de organizare a întrepriderii.

Eficienţa globală a unui sistem informatic trebuie apreciată şi prin prisma implicaţiilor introducerii prelucrării electronice a datelor asupra conducerii: • previziunea stărilor şi a funcţionării sistemului

economic capătă determinări realiste ca urmare a elaborării şi a folosii unor modele adecvate;

• organizarea sistemului economic comportă îmbunătăţiri substanţiale prin raţionalizarea structurii organizatorice şi prin posibilitatea integrării metodelor de conducere previzionară;

• deciziile primesc noi determinări calitative prin sporirea gradului de obiectivitate;

• coordonarea activităţilor se bazează pe informaţii necesare reglării funcţionării sistemului economic la diverse nivele;

• se asigură controlul prin informarea operativă şi oportună asupra dereglărilor care apar în funcţionarea organismului economic.

Eficienţa sistemului informatic se exprimă şi prin prisma timpului mediu de răspuns. Timpul mediu de răspuns este diferenţa, în unităţi de timp, dintre momentul punerii la dispoziţia utilizatorului a unei informaţii şi momentul cererii informaţiei respective. Aprecierea eficienţei economice cu ajutorul timpului mediu de răspuns se realizează cu ajutorul coeficienţilor:

Kt = tm0 /tm1 şi

Kc = Ct1 / Ct0


pagina 92

în care: • tm0,tm1 reprezintă timpii medii de muncă necesari

înainte şi după introducerea sistemului informatic; • Ct0,Ct1 reprezintă costurile totale înainte şi după

introducerea sistemului informatic. Eficienţa globală a sistemului informatic se estimează prin raportul

Eg=Kc / Kt

care exprimă corelaţia dintre scurtarea timpului mediu şi costul pe care aceasta îl generează. Sistemul informatic este performant dacă raportul este subunitar şi apropiat de valoarea zero.

Se consideră că o lucrare de concepţie în domeniul informaticii este, în primul rând, o lucrare de creaţie în domeniul conducerii, incluzând problematica perfecţionării mecanismului economico-financiar şi a interacţiunilor micro şi macro economice. Activităţile de informatică sunt menite să asigure condiţii de creştere a producţiei prin reflectarea în sistemul informatic, a factorilor de influenţă asupra rezultatelor financiare ale întreprinderii. Estimarea eficienţei economice a sistemului informatic, având în vedere implicaţiile complexe ale realizării şi exploatării componentelor informatice, atestă faptul că sistemul informatic concură la promovarea eficienţei economice în toate sectoarele de activitate prin creşterea efectelor utile şi concentrarea efortului asupra acţiunilor de concepţie şi de conducere a întreprinderii.


pagina 93

4.2.3. Proiectarea tehnică.

Este etapa în care se definitivează mijloacele tehnice necesare (echipamente, programe, proceduri manuale....) prin care fluxul informaţional stabilit anterior este transformat într-un flux cu prelucrare automată a datelor. Efortul principal este de proiectare pură. Frecvent, datele furnizate din proiectarea logică pot fi găsite incomplete, astfel că vor fi necesare iteraţii şi corecţii care pot afecta soluţia propusă din puct de vedere tehnologic, economic sau operaţional. În această etapă obiectivul principal îl reprezintă elaborarea componentelor funcţionale detaliate ale sistemului şi a specificaţiilor de definire a programelor. Sarcina activităţilor din această etapă ce se desfaşoară la nivelul subsistemelor sau chiar al aplicaţiilor revine integral analiştilor de sistem. Activităţile desfăşurate în această etapă sunt: • proiectarea funcţională detaliată pe componente şi a

legăturilor dintre acestea; • stabilirea cerinţelor şi a condiţiilor tehnice de

realizare a programelor; • elaborarea programelor de lucru pentru etapa

următoare şi stabilirea resurselor necesare. Activităţile de proiectare tehnică au ca obiectiv materializarea concepţiei sistemului informnatic prin proiectarea funcţională amanunţită a componentelor sistemului şi a legăturilor dintre componente. Pe baza definirii complete şi precise a sistemului informatic din etapele precedente, în etapa de proiectare tehnică sunt concepute specificaţiile de realizare pe compnnente


pagina 94

(subsistem, aplicaţie). Proiectul tehnic rezultat din desfăşurarea activităţilor etapei, pentru o componentă, constituie baza programării şi a implementării componentei respective. Plecând de la ieşirile informaţionale dorite de utilizator, sunt elaborate modelele de obţinere a ieşirilor din intrările disponibile prin definirea colecţiilor de date şi a procedurilor de tratare a datelor din colecţii. Aceste activităţi urmăresc definirea detaliată a tehnologiei de prelucrare a datelor. În elaborarea tehnologiei de prelucrare a datelor, o deosebită atenţie trebuie acordată proiectării fluxului tratării datelor urmărind ca, prin colecţile de date şi fluxul prelucrărilor să se reflecte fidel realitatea. De asemenea, prezintă interes major verificarea funcţionalităţii componentelor proiectate sub aspectul completitudinii şi al corectitudinii operaţiilor de tratare a datelor. Perfornanţele sistemului informatic sunt determinate, în mare măsură, de metodele de organizeare a datelor. Modalităţile de constituire a colecţiilor de date sunt determinante asupra prelucrărilor, în timp ce organizarea colecţiilor de date este condiţionată la rândul ei de definirea fluxului tehnologic al datelor. În organizarea datelor sunt determinante: studiile pentru delimitarea ariei şi a legăturilor externe ale sistemului informatic, modelele de obţinere a ieşirilor din intrări, volumul datelor de prelucrat, cerinţele de informare ale conducerii. Metodelele utilizate în organizarea datelor sunt : • metoda fişierelor independente, • metoda bazei de date. Metoda fişierelor independente constă în crearea de fişiere pe suport accesibil prelucrării automate a datelor, pentru înmagazinarea datelor prelucrate în


pagina 95

cadrul fiecărei componente a sistemului informatic. Un fişier este constituit dintr-o submulţime de date omogene relative la o clasă de elemente a sistemului informaţional. (ex. fişierul de stocuri din aplicaţia de gestiunea materialelor). În general pentru fiecare entitate distinctă a sistemului informaţional (materiale, produse, personal, etc.) se constiuie fişiere cu caracter permanent care reflectă starea elementelor la un moment dat. Operaţiile curente din sistemul economic constituie tranzacţii şi sunt reflectate în fişiere temporare. (ex:intrări şi ieşiri de materiale). Prin aplicarea datelor operaţionale conţinute în fişierele temporare asupra datelor de structură din fişierele permanente rezultă ieşirile informaţionale scontate şi se asigură actualizarea fişierelor permanente. În urma actualizărilor fişierele permanente vor cuprinde starea entităţilor "la zi".

Fişiere permanente (cartoteci, registre cataloage etc.) şi fişiere temporare (centralizatoare, jurnale ...) sunt utilizate şi în condiţiile prelucrării manuale a datelor.

Metoda fişierelor independente asigură rapiditate în organizarea datelor şi a prelucrărilor. În acelaşi timp efortul de definire completă şi corectă a sistemului informatic este mai redus prin proiectarea tehnică detaliată a fiecărei componente şi integrarea ulterioară a componentelor proiectate în sistemul informatic. Această metodă este frecvent utilizată în practică pentru probleme de mici dimensiuni. Creşterea complexităţii sistemului duce la creşterea numărului de fişiere necesare ceea ce generează dificultăţi sporite de întreţinere. Utilizarea de fişiere independente conduce la o flexibilitate redusă a sistemului informatic, modificarea structurii fişierelor implicând refacerea programelor care le utilizează. Prin


pagina 96

duplicarea datelor în mai multe fişiere se generează redundanţe informaţionale, utilizarea neraţională a suporţilor de informaţie şi dificultăţi în actualizarea şi controlul datelor. Pornind de la aceste neajunsuri constatate la organizarea datelor în fişierelor independente se poate folosi ca alternativa metoda bazelor de date. Datele din sistemul informatic sunt organizate în colecţii care se numesc baze de date şi care au o serie de proprietăţi şi caracteristici ce vor fi arătate ulterior. Trecerea de la fişierele independente către bazele de date s-a făcut în timp prin mai multe etape: • fiecare program de calcul utiliza date şi fişiere

specifice, proprii pentru obţinerea rezultatelor dorite. (metoda fişierelor independente).

• mai multe programe folosite în rezolvarea unor probleme similare, utilizau date şi fişiere comune, grupate în colecţii mai mari specifice domeniului respectiv.

• toate programele utilizate folosesc o colecţie unică de date, o aşa zisă "bază de date" în care sunt incluse toate datele necesare .

Necesitatea unor mari baze de date comune a fost simţită nu numai de fabricanţii de calculatoare şi de proiectanţii de sisteme informatice, ci şi de utilizatorii sistemelor elaborate. Toţi au constatat că în sistemele de o anumită mărime, în care se lucrează cu volume mari de date, este nevoie să se găsească o serie de modalităţi, tehnici şi metode eficiente pentru definirea organizarea, memorarea şi actualizarea datelor în forme din ce în ce mai performante. Sistemele informatice în care se utilizeaza conceptul de bază de date prezintă unele avantaje: • Reducerea considerabilă a nivelului de redundanţă al

datelor memorate. Folosind bazele de date comune


pagina 97

se pot obţine informaţii uniforme, atât temporal cât şi fizic. Se evită actualizarile parţiale a aceloraşi date în fişiere diferite.

• Utilizarea aceloraşi date în mai multe activităţi. Având un sistem unitar pentru definirea şi regăsirea datelor, implementarea unor noi programe se face relativ uşor. Procedurile folosite pe măsura construirii şi dezvoltării sistemului fiind cât mai uniforme, exploatarea se face mult mai sigur şi eficient.

• Controlul centralizat, integritatea şi securitatea datelor sunt posibile în astfel de sisteme deoarece definirea structurilor de date, modul lor de gestionare şi accesul la acestea sunt în mâna unui singur grup coordonator (denumit în general administrator al bazei de date).

• Independenţa datelor faţa de programe şi suporţii fizici de memorare generează creşterea calităţii şi fiabilităţii sistemului informatic.

Deoarece nu există o definiţie general acceptată, vom denumi o bază de date "un absamblu unitar organizat şi structurat de date a cărui gestionare se face printr-un sistem specializat denumit sistem pentru gestionarea bazelor de date (SGBD)". Prin gestionarea bazelor de date se întelege îndeplinirea unor funcţii specifice de operare asupra lor: creare/generare, actualizare/ţinere la zi, interogare şi reorganizare. Ansamblul format din: • baza de date, • sistemul care o gestionează (SGBD), • echipamentele de calcul utilizate pentru

înregistrarea, memorarea şi pentru prelucrările efectuate asupra datelor din baza de date,


pagina 98

• procedurile automate şi neautomate suplimentare necesare pentru gestionarea datelor, în afara celor din SGBD,

reprezintă BANCA DE DATE. În concepţia modernă de realizare a sistemelor informatice "banca de date" devine subsitemul central, prin el realizându-se principalele legături dintre majoritatea celorlalte subsisteme şi aplicaţii în primul rând a celor care lucreazâ cu datele din baza de date. Un SGBD are trei componente principale: • utilizatorul sistemului; • administratorul bazei de date; • gestionarul bazei de date. Utilizatorul primeşte răspuns la cererile de informaţii pe care le face direct pentru el sau pentru alte persoane. Sunt mai multe categorii de utilizatori: • utilizatorul profesionist care pentru a primi

răspunsurile solicitate scrie programe, deci are cunoştinţe de programare;

• utilizatorul nespecialist, care pentru formularea unor întrebări, scrie o serie de comenzi sau instrucţiuni relativ simple, dar pentru a căror utilizare are nevoie de un anumit instructaj (câteva zile);

• utilizatorul nespecialist, de cele mai multe ori un conducător, care nu trebuie să facă decât nişte operaţii elementare pentru a obţine informaţiile dorite (utilizatori "press-button").

Administratorul bazei de date este o funcţie absolut necesară pentru buna funcţionare a SGBD-ului. Se constată că administratorul bazei de date este necesar totdeauna în cadrul sistemelor informatice chiar când nu folosim conceptul de bază de date. El este reprezentat de o persoană sau un grup de persoane care controlează


pagina 99

şi coordonează modul de introducere a datelor, modificările ce li se aduc şi accesul la ele. Administratorul trebuie să acorde o deosebită atenţie factorilor care afectează memorarea şi regăsirea datelor şi de aceea are nevoie de cunoştinţe aprofundate privind datele necesare în cadrul organizaţiei şi modul cum acestea sunt folosite. Gestionarul nu mai este o persoană sau un grup de persoane ca în cazul primelor două componente, ci o combinaţie de echipamente de calcul şi de programe care asigură accesul la date conform instrucţiunilor primite de la utilizatori şi de la administrator. În acest scop gestionarul trebuie să aibă o interfaţă cu toate limbajele de programare convenţionale admise de SGBD-ul respectiv. Gestionarul îndeplineşte unele funcţii care în sistemele anterioare erau îndeplinite de compilatoare, asambloare, editoare de legături, programe utilitare, etc.. Gestionarul formează un fel de graniţă între programele de aplicaţie şi mecanismele de acces la date. Gestionarul interpretează cererile de date "logice" ale diverşilor utilizatori şi cu ajutorul mecanismelor sale de acces extrage şi transferă datele solicitate de aceştia. Utilizatorul nu ştie cum şi unde sunt memorate datele. Se spune că tot acest proces este "transparent" utilizatorului, în sensul că este parcurs fără a fi cunoscut de el în mod intim, ci numai în principiu.

Prin metoda bazei de date se urmăreşte organizarea datelor din sistem astfel încât datele memorate pe suport magnetic de mare capacitate să răspundă necesităţilor de prelucrare şi utilizare ale tuturor componentelor sistemului informatic şi ale tuturor utilizatorilor. Respectarea principiilor privind unicitatea datelor, independenţa datelor, consultarea concurentă a datelor necesită efectuarea analizei şi


pagina 100

proiectării sistemului informaţional prin abordare globală şi structurarea lui detaliată.

Activităţile ce ar trebui realizate pentru determinarea specificaţiei logice de definire a bazei de date sunt: 1. Trecerea în revistă a tuturor cerinţelor de informare

necesare pentru rezolvarea diverselor probleme. Cu acest prilej se va stabili o ordine de prioritate în înlocuirea subsistemelor şi lucrărilor manuale cu cele în care gestiunea datelor şi furnizarea rezultatelor se face prin intermediul tehnicii de calcul.

2. Se examinează toate datele necesare pentru satisfacerea cerinţelor de informare cu stabilirea legăturilor informaţionale care trebuie să existe între acestea.

3. Se realizează o serie de analize şi studii detaliate privind datele care se vor utiliza în sistem. Abia acum se poate vedea dacă avem nevoie de un SGBD.

4. Se întocmeşte pe baza rezultatelor obţinute în activităţile anterioare, specificaţia pentru baza de date, care este o documentaţie ce cuprinde: • datele şi structurile de date propuse a fi incluse în

baza de date; • o schemă care să reprezinte legăturile

informaţionale dintre subsisteme şi aplicaţii; • schema cu structurile logice de date şi legăturile

dintre ele; • restricţiile hardware şi software avute în vedere; • cerinţele suplimentare pentru SGBD-ul care

urmează să fie utilizat cum ar fi: volumul intrărilor, al ieşirilor, timpii de răspuns solicitaţi, principalele prelucrări, etc.

În funcţie de datele de memorat şi de relaţiile dintre ele într-o bază de date pot să apară următoarele tipuri de structuri:


pagina 101

• structura punctuală pentru entităţi independente; • structura ierarhică liniară pentru entităţi cu relaţii

liniare între ele; • structura ierarhică arborescentă pentru descrierea

relaţiilor dintre entităţi de tipul “un tată are mai mulţi fii”;

• structura de tip reţea pentru entităţi cu relaţii complexe între ele, rezultată prin generalizarea structurilor ierarhice liniare şi arborescente;

• structura relaţională când datele nu mai sunt privite ca înregistrări ci ca relaţii.

Buna funcţionare a unui sistem informatic lucrând cu conceptul de baza de date depinde în mare măsură de modul cum se proiectează această bază de date. Alegerea variantei de proiectare a circuitului informaţional este condiţionată de modul în care aceasta asigură funcţionalitatea componentei respective. Verificarea funcţionalităţii necesită stabilirea posibilităţilor de obţinere a datelor de ieşire din datele de intrare ale componentei proiectate. Descrierea condiţiilor logice şi a regulilor de obţinere a datelor de ieşire din datele de intrare este realizată eficient folosind tehnica tabelelor de decizii. Această tehnică se bazează pe constatarea că vederea este cel mai dezvoltat simţ uman. Un tabel de decizii se bucură de toate avantajele pe care le oferă un tabel oarecare provenind din faptul că sunt clare, concise şi uşor de citit. Plecând de la ideea că orice operaţie sau ansamblu de operaţii poate fi condiţionată sau necondiţionată, tehnica tabelelor de decizii dă o formă tabelara procesului de prelucrare a datelor.

O tabelă de decizii este constituită din patru părţi (cadrane): 1. condiţii (criterii) pentru luarea deciziilor (C1;

C2;...Cm);


2. intrări ale condiţiilor (IC); combinaţii ale intrărilor posibile redau reguli în luarea deciziilor (R);

3. decizii (acţiuni) posibile (D1,D2,....Dp); succesiunea verticală a denumirii deciziilor indică ordinea în care urmează a fi executate deciziile;

4. intrările deciziilor (ID) prin care se specifică ce decizii urmează a fi luate pentru fiecare regulă.

CADRANUL I (condiţii)

CADRANUL II (intrări ale condiţiilor)

CADRANUL III

(decizii)

CADRANUL IV (intrări ale deciziilor)

Figura 4.7. Cadranele unei tabele de decizii Tabela de decizii descrie toate variantele posibile ale valorilor condiţiilor şi deciziile corespunzătoare fiecărei combinaţii a acestor valori în soluţionarea unei probleme. Citirea tabelei de decizii se face de sus în jos astfel: "dacă se realizează condiţia C1 şi dacă se realizează condiţia C2 şi dacă ... atunci se ia decizia Dk".

R1 R2 R3 R4 R5 R6 R7 R8

pagina 102

C1 Se solicta mat. X de cal. I

Da Da Da Da Nu Nu Nu Nu

C2 Depozitul dispune de

Da Nu Nu Nu Da Da Nu


mat. X de cal I C3 Depozitul

dispune de mat. X de calit. II în cantitate Q

Da Da Nu Da Nu Nu Nu

C4 Solicitantul accepta schimbarea calităţii

Da Nu Da Nu

D1 Elibereaza mat. X de calit. I în cant. Q

* *

D2 Eliberează mat. X de calit. II în cant. Q

* *

D3 Emite comanda de aprov. pt. mat. X de calit. I

* *

D4 Emite comanda de aprov. pt. mat. X de calit. II

* *

Figura 4.8. Tabelă de decizii

În funcţie de valorile întâlnite pentru intrările condiţiilor tabelele de decizii pot fi: a) cu intrări limitate; când intrările condiţiilor sunt

explicitate numai prin valori DA sau NU (0 sau 1); b) cu intrări extinse; când intrările fiecărei condiţii ale

unei tabele de decizii sunt explicitate prin mai multe valori (0, 1, 2,...);

pagina 103


pagina 104

c) cu intrări mixte; când din necesităţile analizei problemei rezultă condiţii cu intrări explicitate, fie prin valori DA sau NU fie prin mai mult de două valori.


pagina 105

4.2.4. Elaborarea programelor.

După ce specificaţiile de realizare au fost

întocmite şi aprobate, ele vor fi repartizate diverselor grupe de specialişti care au responsabilitatea să le execute şi ulterior să le asambleze. Etapa este consacrată elaborării programelor şi procedurilor manuale, aferente componentelor sistemului informatic, precum şi testării componentelor. În funcţie de necesităţile problemei dar şi de cunoştinţele proiectanţilor, în această etapă se pot folosi tehnici de programare ca: • programarea modulară; • programarea structurată; • programarea orientată pe obiecte; sau , eventual soluţii hibride conform nivelului de stăpânire a tehnicilor respective. Programarea modulară. Operaţia de împărţire a unei probleme complexe, concepută din punct de vedere logic ca un tot unitar, nu este uşoară pentru că întotdeauna trebuie avut în vedere ca părţile în care a fost descompus întregul să nu-i schimbe scopul iniţial şi totodată să permită, relativ usor, reconstituirea întregului atunci când este necesar. În acest sens trebuie respectate două reguli: • fiecare componentă trebuie să îndeplinească o

anumită funcţie bine precizată în cadrul întregului; • între componente este necesar să se stabilească

foarte exact legăturile, astfel ca fiecare parte să-şi poată realiza relativ independent funcţia specificată şi în acelaşi timp să poată contribui la funcţiile generale ale întregului.


pagina 106

Prin modularitate înţelegem proprietatea sau

posibilitatea ca un proces să poată fi descompus în parţi componente, cu legături bine stabilite între ele, astfel ca obiectivul general al procesului să poată fi cât mai eficient realizat. Una din definiţiile date noţiunii generale de modularitate aparţine lui Russel Armstong, care considera că un sistem este modular atunci când este realizat dintr-o mulţime de elemente căreia îi este asociată o lege de structură. A găsi legea de structură înseamnă a prospecta interfaţa dintre module. După acelaşi autor, proiectarea interfeţei dintre module este simplificată dacă modulele au fost concepute astfel încât să aibă o funcţionalitate bine definită.

Modularizarea sistemelor informatice ţine seamă de unele caracteristici ale acestora: • sunt realizate şi implementate într-un timp

îndelungat (de ordinul anilor); • introducerea sistemelor informatice conduce la

cheltuieli importante; • sistemele informatice sunt folosite de un număr

mare de utilizatori, răspândiţi uneori pe zone întinse; • cerinţele utilizatorilor sunt mereu schimbate şi

completate. Ţinând seama de cele de mai sus se poate face o modularizare pe trei nivele a sistemelor informatice:

a) nivelul 1 - sistem; b) nivelul 2 - subsistem; c) nivelul 3 - aplicaţie.

a) Sistemul informatic trebuie să urmărească şi să

contribuie la realizarea obiectivelor generale ale întreprinderii, fixate pe o perioadă lungă de timp. Deoarece obiectivele şi restricţiile generale se pot


pagina 107

schimba în timpul realizării sistemului informatic este necesară o revedere şi o redefinire periodică a acestora. Acolo unde planurile de perspectivă ale întreprinderii, sunt cunoscute pentru o perioadă mai scurtă decât cea prevazută pentru realizarea şi implementarea sistemului informatic, pot aparea neconcordanţe imprevizibile, care pot conduce la efecte negative.

b) Subsistemul corespunde, de regulă, unor obiective derivate din cele generale, rezultate prin detalierea acestora. Există unele tendinţe de împărţire a sistemelor informatice în subsisteme după structura ierarhică şi organizatorică astfel:

• strategic • tactic • operativ,

sau după precizarea funcţiilor sale: • producţie • comercial • financiar-contabil • personal • cercetare- dezvoltare.

Între aceste componente (subsisteme) trebuie să existe legături (interfeţe) clare, cât mai puţine şi cât mai rigide, în sensul că odată stabilite să nu mai fie practic modificate.

c) Aplicaţia, ca unitate componentă a subsistemului, contribuie în general la satisfacerea unor obiective specifice şi se dezvoltă de obicei la nivelul unor compartimente sau activităţi din cadrul întreprinderii. În structura sistemului pe trei nivele aplicaţia se găseşte pe ultimul nivel, şi construirea sistemului informatic se face treptat prin realizarea de aplicaţii asamblate în cadrul nivelurilor superioare.


pagina 108

Adâncind nivelul de detaliere al sistemului informatic putem adăuga încă două nivele:

d) program; e) modul de program.

d) Aplicaţia la rândul ei este constituită dintr-o serie de

programe şi proceduri manuale legate între ele şi care îndeplinesc funcţiile cerute.

e) La rândul lor programele sunt de cele mai multe ori divizate în mai multe părţi, numite "module program" independente din punct de vedere logic. Modulele sunt compuse din instrucţiuni scrise într-un limbaj de programare.

La nivelul programelor modularitatea se mai numeşte şi micro modularitate. Corelarea modulelor sau cuplarea modulelor este o măsura a independenţei modulelor, şi poate avea mai multe forme: • corelarea externă, când modulele utilizează aceleaşi

date globale ale sistemului; • corelarea prin control, când unul din module

controlează execuţia celorlalte în mod explicit, prin chei de control sau variabile de control a căror valoare indică modul de continuare a execuţiei;

• corelarea internă sau prin conţinut, când un modul referă direct alt modul;

• corelarea prin date, când la apelarea unui modul de către altul toate datele de intrare sau de ieşire ale modulului apelat sunt comunicate sub formă de parametrii.

Un alt element caracteristic este ponderea sau tăria modulelor care reflectă modul de formare şi conţinutul modulului. Există mai multe posibilităţi de divizare a programelor în module şi anume:


pagina 109

• divizarea întâmplătoare, care dă tăria cea mai slabă modulelor căci programul este împărţit arbitrar în module;

• divizarea logică, are ca rezultat module ce efectuează o funcţie la fiecare apelare;

• divizarea clasică, prin care modulul efectuează mai multe funcţii necorelate între ele prin date;

• divizarea prin comunicare, când modulele efectuează mai multe funcţii corelate prin date;

• divizarea funcţională, când modulele efectuează o singură funcţie care le este specifică.

Modularizarea este una din sarcinile principale ale proiectanţilor de sisteme informatice şi este în cele mai multe cazuri, o operaţie complicată de care depinde în mare măsură modul cum va funcţiona în final sistemul. În acest scop, în cadrul proiectelor mari, pe baza unor experienţe anterioare, adaptate la specificul respectiv, se elaborează reguli şi chiar norme care trebuie avute în vedere la împărţirea în componente la toate nivelurile. În fond, aceste reguli decurg din conceptul general de modularitate, stabilind în principal că un modul trebuie: • să îndeplinească o funcţie unică, lucru extrem de

avantajos atunci când se fac modificări; • să fie complet; • să aibă cât mai puţine interfeţe cu ale module; • să permită o înţelegere uşoară a problemelor pe care

le rezolvă; • să se poată încadra în diversele tipuri de

modularitate ale sistemului. Avantaje ale modularizării:


pagina 110

1) Posibilitatea divizării întregului în părţi mai simple şi mai uşor de realizat.

2) Independenţa modulelor permite elaborarea şi testarea separată a acestora.

3) Fiecare modul poate fi realizat prin tehnicile (limbajele) cele mai adecvate funcţiei pe care o îndeplineşte.

4) Posibilitatea construiri a unei biblioteci de module testate (module standard) disponibile tuturor proiectanţilor.

5) Simplificarea întreţinerii sistemului (programului). 6) Permite abordarea de la simplu la complex şi permite

o încărcare echilibrată a fiecarui membru din echipa de proiectare.

Dezavantajele modularizarii: 1) Mulţi proiectanţi nu înţeleg modularizarea sau nu se

pot acomoda cu ea. 2) Modularitatea cere eforturi suplimentare în faza de

proiectare. 3) Proiectanţii nu cunosc problema în ansamblu ci

numai parţi ale ei. 4) Concepţia modulară duce la realizarea de programe

care încarcă suplimentar unitatea centrală a calculatorului cu funcţiile de dispecerizare şi comunicare între module.

Noţiunea de modularitate este însoţită aproape întotdeauna de un alt concept, cel de "top-down". "Top-down" înseamnă "de sus în jos" sau "descendent". În linii mari el ar putea fi explicat astfel: în procesul general de cunoaştere se începe cu aspectul general, "în mare" al fenomenului, după care, treptat, acesta se detaliază, se cunoaşte în profunzime, până la un anumit nivel, considerat suficient pentru scopul urmărit. Dacă


pagina 111

modularizarea înseamnă procesul de descompunere a unui întreg în părţi componente, metoda cea mai obişnuită, pentru ca împărţirea să fie corect făcută, este tocmai cea "top-dovn". Trăgând o concluzie mai generală, se poate spune că în orice fel de proces de cunoaştere din lumea reală, metoda universal valabilă este cea a analizei descendente, "top-down". Programarea structurată. Pentru abordarea unei probleme complexe în realizarea a unui sistem informatic se impun preocupări pentru scăderea raportului cost/ performanţă, prin aplicarea unor principii de structurare atât în fazele de proiectatre cât şi în cele de realizare a sistemelor informatice. Principiile generale privind realizarea acestor produse informatice trebuie aplicate în mod consecvent în toate fazele de realizare. Aceste principii se referă în primul rând la: • Identificarea funcţiilor necesare pentru realizarea

produsului, analog cu determinarea părţilor componente ale unui produs industrial.

• Descompunerea consecvent descendentă (top-down) în procesul de identificare a funcţiilor componente ale proiectului. Introducând noţiunea de "nivel al functiilor" (Nf) şi punând convenţional nivelul rădăcinii structurii Nf=0, putem defini nivelul unei funcţii oarecare ca fiind egal cu nivelul funcţiei din care descinde plus unu. Funcţiile cu nivelul cel mai ridicat se mai numesc şi "primitive" ale structurii iar cea cu nivelul zero se numeşte rădăcina structurii.

• Realizarea modulară a produsului, presupune izolarea funcţiilor găsite în faza de identificare, apoi determinarea interfeţelor dintre module.


pagina 112

• Normalizarea primitivelor structurilor funcţionale (primitivele structurii).

La un anumit nivel de descompunere în ierarhia funcţiilor unei structuri se găsesc algoritmii de rezolvare ai subproblemelor. Pentru realizarea oricărui algoritm este suficientă utilizarea unui set restrâns de structuri funcţionale primitive. Aceste structuri vor fi considerate structuri elementare. Tehnica de programare care îşi propune să respecte aceste principii şi care va fi tratată în continuare este numită programarea structurată.

Pentru a crea o imagine generală a efortului de definire a programării structurate prezentăm o serie de definiţii posibile apărute pe o perioadă mai lungă de timp, cu menţiunea că cele din anii de început ai conceptului prezintă mai mult constatări de circumstanţă şi au o notă uşor ironică: 1. Este o întoarcere la bun-simt. 2. Este metodă generală după care programează cei mai

buni programatori. 3. Este programarea fără GO TO. 4. Este procesul prin care se controlează numărul de

interacţiuni dintre un proces şi contextul său, astfel încât numărul de interacţiuni să fie o funcţie liniară depinzând de câţiva parametrii ai procesului.

5. Este programarea TOP-DOWN. 6. Programarea structurată se ocupă de convertirea

unor scheme logice arbitrar de mari şi complexe în forme standard, astfel încât să poată fi reprezentate prin iterarea şi compunerea unui număr mic de structuri logice de control standard.

7. Este o manieră de a organiza şi codifica programe astfel încât să fie cât mai uşor de înţeles şi de modificat.


pagina 113

8. Scopul programării structurate este de a controla complexitatea prin teorie şi disciplină.

9. Programarea structurată poate fi caracterizată nu prin absenţa instrucţiunii GO TO ci prin prezenţa structurii.

10. O funcţie majoră a structurii programelor este de a face posibilă demonstrarea corectitudinii lor.

11. Programarea structurată nu este o soluţie totală, ea constă, de fapt, în folosirea unor notaţii formale pentru a gândi ordonat.

12. Procesul de organizare a gândirii care duce la o expresie inteligibilă a procesului de calcul într-un timp rezonabil.

13. Arta simplităţii. Sintetizând se poate ajunge la următoarea definiţie: "Programarea structurată constă dintr-o mulţime de restricţii şi reguli de programare care forţează programul să urmeze o formă strânsă, în acest fel eliminându-se mulţi din factorii care conduc la erori şi care complică activitatea de testare şi întreţinere." Examinarea structurii interne a unui program, evidenţiază existenta unei structuri ierarhice între componentele unui program, fiecare componentă fiind coordonată de componenta de nivel superior şi coordonând componenta de nivel inferior. Ideea structurilor încuibate (nested-logic) conduce la o dispunere a elementelor componente într-o formă în care să se poată distinge nivelele ierarhice, astfel încât fiecare nivel de prelucrare să reprezinte o detaliere a nivelelor precedente. Pentru definirea structurii “nested-logic” a unui program se utilizează ca instrument de lucru diagrama de structură. Blocurile “nested-logic” folosite în diagrama de structură sunt:


pagina 114

• SECVENŢA care marchează grupul de enunţuri care se execută în ordinea în care au fost scrise.

• SELECŢIA care marchează separarea enunţurilor în două grupe şi executarea unei sau alteia din aceste grupe în funcţie de o anumită condiţie.

• ITERAŢIA care marchează un grup de enunţuri cu execuţie repetată de un număr de ori (inclusiv repetarea de zero ori ceea ce echivalează cu eliminarea grupului de enunţuri).

Regulile de structurare ale blocurilor sunt: • punctul de intrare într-un bloc este unic; • punctul de ieşire dintr-un bloc este unic; • blocul iterativ începe prelucrarea prin testarea

condiţiei de ieşire din ciclu; • un bloc poate conţine orice combinaţie de blocuri

care satisfac condiţiile de mai sus. Blocurile diagramei de structură sunt reprezentate prin dreptunghiuri identificate printr-un nume înscris în interior. Diagrama de structură este reprezentarea grafică a unei structuri de prelucrare pe nivele de detaliere conform următoarelor reguli: • nivelele de detaliere se parcurg de sus în jos; • fiecare nivel reprezintă o detaliere a nivelului

precedent; • blocurile situate pe un acelaşi nivel ierarhic se

parcurg de la stânga la dreapta; • terminarea parcurgerii unui nivel presupune

parcurgerea următorului bloc din nivelul anterior. Regulile de citire a diagramei de structură sunt:


pagina 115

• Citirea operaţiei de trecere de la un nivel superior către un nivel inferior se face utilizând expresia "constă din".

• Citirea operaţiei de trecere de la un bloc la alt bloc de pe acelaşi nivel se face utilizând expresia "urmat de".

• Citirea operaţiei de trecere de la un nivel inferior către un nivel superior se face prin trecerea la următorul bloc al nivelului superior utilizând expresia "urmat de".

• Un cerculeţ marcat în colţul din drapta sus al unui bloc identifică un bloc opţional şi se citeşte utilizând expresia "sau".

• Un asterisc marcat în colţul din dreapta sus al unui bloc identifică un bloc cu execuţie repetată şi se citeşte utilizând expresia "mai multe".

Reprezentarea blocurilor “nested-logic” utilizate în diagrama de structura şi corespondenţa lor cu reprezentarea din schemele logice clasice este prezentată in figura 4.9. TEOREMA DE STRUCTURĂ: Oricare ar fi schema logică S aparţinând mulţimii schemelor logice clasice şi care reprezintă structura logică a unui proces de prelucrare, există cel puţin o transformare T pentru care S'= T(S) astfel încât: 1. S' este echivalentă cu S; 2. S' este o schemă cu structură “nested-logic”.


Figura 4.9. Structuri elementare în programarea

structurată

pagina 116

Programarea orientata pe obiecte. Pentru problemele de natură economică, în limbajele de programare clasice, cea mai mare parte a atenţiei era acordată descrieirii structurilor de date deoarece, practic, prelucrările etectuate asupra lor sunt destul de simple şi nu necesită un efort de programare deosebit. Spre exemplu în limbajul COBOL aproximativ 79% din lungimea codului sursă este ocupată de descrierea structurilor de date. În timp, odată cu creşterea complexităţii programelor, a apărut necesitatea unei organizări riguroase a muncii. Ca o etapă superioară capabilă să rezolve în bună măsură problemele ivite, s-a impus programarea structurată. De-a lungul anilor, în special datorită


pagina 117

creşterii dimensiunii produselor software, şi acest instrument a devenit la rându-i depăşit. Sporirea complexităţii programelor aducea după sine dificultăţi reale legate de întreţinerea unor programe mamut. Cu alte cuvinte, deşi preţul produselor era în creştere, calitatea lor tindea să scadă. În căutarea unei soluţii care să scoată informatica din situaţia dificilă în care se afla, s-a pornit de la ideea că o bună reprezentare a temei de rezolvat este deseori cauza transformarii unei probleme complexe într-una deosebit de simplă. În urma diversificarii căutărilor, au apărut limbaje având la bază noţiunea de "cadru" ("frame") şi cele care pornesc de la ideea de "acţiune", ambele noţiunii folosite în inteligenţa artificială. Prima categorie implementează "operaţii" asupra unor "modele de entităţi" iar cea de a doua susţine faptul că "obiectele nu sunt simple elemente pasive asupra cărora se fac prelucrări, ci, dimpotrivă, menirea obiectelor rezidă în a activa prelucrările ce le vor suporta ele însele.

Deşi teoria programării orientate pe obiecte era bine fundamentată de peste 20 de ani, ideea nu a prins cu adevărat decât în ultimii ani. Programarea pe obiecte în loc să separe iremediabil datele de cod nu face altceva decât să contopească cele două elemente.

Primele limbaje cu adevărat demne de acest nume au fost SIMULA (1965) şi SIMULA-2 (1967), iar prin anii '70 SMALLTALK. Cel mai mare dezavantaj al lor, din punct de vedre al penetrării pe piaţă, a fost însuşi faptul că au apărut ca limbaje de sine stătătoare, având o răspândire relativ redusă. Din acest motiv puţini programatori erau dispuşi să abandoneze limbajele consacrate în acele momente, doar de dragul de a lucra obiectual. O bună perioadă de timp metoda programării obiectuale a fost uitată.


pagina 118

În anii '80 în urma acceptării definitive a limbajului C, un colectiv condus de Bjarne Stroustrup încearcă introducerea conceptului de "clasă" într-un dialect numit "C with classes". Ideea prinde contur şi în 1983 ia naştere prima versiune a noului limbaj C++. Aproape imediat apar şi partizanii fanatici ai OOP-ului aflat acum la a doua tinereţe. Termenul de OOP provine din "Object Oriented Programming" care desemnează disciplina programării obiectuale sau orientată-obiect.

Profitând deci de marea popularitate în rândul soft-iştilor şi de multitudinea domeniilor de aplicaţie (de la grafica interactivă la exploatarea reţelelor de calculatoare şi chiar până la proiectarea compilatoarelor) moftul devine modă şi moda certitudine. Acest succes extraordinar s-a datorat faptului că limbajul C++ nu face nimic altceva decât să-i dea un nou avânt unuia dintre cele mai la moda limbaje ale momentului "C".

OOP introduce conceptul de INCAPSULARE prin care se ating următoarele obiective: • facilitatea deosebită de localizare a erorilor • modularizarea problemei de rezolvat.

Notiunea de “clasă” conţine declaraţii de variabile şi declaraţii de funcţii care operează asupra variabilelor. Funcţiile se numesc funcţii membru sau metode iar variabilele variabile membru. Cu ajutorul claselor, un programator îsi poate defini orice tip de dată dorit, împreună cu setul de operaţii. Toate aceste informatii sunt încapsulate într-o “clasă”. Astfel prin “clasă” vom înţelege un tip abstract de dată, definit de utilizator.

Un “obiect” este o variabilă declarată ca fiind de tipul “clasă”. Altfel spus un “obiect” este o instanţiere (o realizare) a unei clase. Prin intermediul claselor se pot separa informaţiile de implementare (mecanism intern) de cele de utilizare (mecanism extern).


pagina 119

Un alt termen introdus de OOP, este “moştenirea”. În urma definirii unei clase, cu un minim de efort şi timp se pot preciza seturi de clase asemănatoare, având totuşi o trăsătură distinctivă. Având o clasă B putem defini o altă clasă D care să moştenească sau să preia toate caracteristicile clasei B la care să se poată adăuga altele noi, proprii doar acesteia din urmă. Prima clasă se va numi "clasă de bază" iar cea de-a doua "clasă derivată". Moşetenirea stă la baza altor concepte novatoare cum ar fi “polimorfismul” dar elementul esenţial al programarii obiectuale rămâne "încapsularea".

“Polimorfismul” constă în faptul că într-o ierarhie de clase obţinute prin moştenire, o metodă poate avea forme diferite de la un nivel la altul, specifice respectivului nivel din ierarhie. Aşa cum în lumea vie hrănirea este universal valabilă ea deosebindu-se de la o clasă la alta de vietăţi, tot aşa şi în cazul OOP metoda poate avea forme diferite de la o clasă la alta.

În momentul de faţă piaţa informatică este invadată de biblioteci şi colecţii de clase. Menirea lor este de a permite un coeficient cât mai ridicat de reutilizare a codului scris. Pe de altă parte, pornind de la aceste clase, utilizatorul poate crea prin moştenire alte clase, care să-l ajute să-şi rezolve problema în mod optim. În plus, programatorul are garanţia folosirii unor proceduri scurte, inteligibile şi nu în ultimul rând corecte.

Un alt domeniu de utilizare a bibliotecilor de clase este cel al realizării prototipurilor unor produse software. Prin prototip se înţelege un program funcţional, simplificat şi care să dea o imagine clară a produsului final. Utilitatea lor constă în faptul că, într-un timp foarte scurt şi cu un efort minim din partea producătorului, clientul poate avea o imagine destul de


pagina 120

clară asupra produsului final. Pentru o aplicaţie oarecare prototipul nu trebuie să conţină algoritmul optim, clientul urmând să poată înlocui doar acele module care sunt deficitare din anumite puncte de vedere.


pagina 121

4.2.5. Implementarea, exploatarea şi întreţinerea.

Implementarea este etapa în care sistemul se testează în condiţii reale. Etapa începe când componentele individuale, care au fost testate şi acceptate, pot fi asamblate pentru testarea şi includerea în sistem pe baza specificaţiilor şi manualelor elaborate în etapa anterioară. Circuitul informaţional existent este înlocuit cu noul circuit prin lansarea în execuţie a programelor şi verificarea practică a modului de obţinere a rezultatelor, acestea constituind activităţile de implementare a sistemului informatic.

Etapa se consideră terminată când sistemul este acceptat de beneficiar. Unele activităţi pregătitoare ale implementării pot începe încă din etapa precedentă. Activităţile aferente implementării sunt următoarele:

• pregătirea implementării; • executarea procedurilor de conversie; • testarea în condiţii reale; • evaluarea rezultatelor obţinute şi verificarea

performanţelor sistemului; • definitivarea documentaţiei. Etapa de exploatare începe când informaţiile din sistem sunt furnizate în mod curent beneficiarului. În paralel cu exploatarea sistemului se desfăşoară întreţinerea sistemului. Exploatarea este legată de problemele curente zilnice ale menţinerii sistemului în stare de funcţionare, în timp ce întreţinerea constă în activităţi de evaluare periodică legate de modificările ce trebuiesc făcute pentru a menţine sistemul viabil.


pagina 122

4.3. Ciclul de abstractizare 4.3.1. Modelul conceptual al datelor

Pentru realizarea unui model conceptual al datelor este necesară folosirea unei reprezentări sub forma de text a realităţii aşa cum a fost ea înteleasă de analist. Ea se rezumă la descrierea literară ca urmare a analizei, putându-se deduce din aceasta entităţile, asociaţiile etc. care vor constitui mai departe modelul conceptual al datelor. Concepte utilizate în MCD a) entitate - este reprezentarea în sistemele informaţionale a unui obiect material sau imaterial având o existenţă proprie şi conformă cu necesităţile gestiunii întreprinderii. În general se utilizează un substantiv comun ca nume de entitate, nume ales astfel încât să sublinieze cât mai bine relaţia cu componenta din sistem pe care o reprezintă. b) realizarea unei entităţi - este un element individualizat apartinând entităţii. Spre exemplu informaţiile relative la salariatul Popescu sunt o realizare a entităţii SALARIAT. c) asociaţia - reprezintă o relaţie între entităţi. Numărul entităţilor care intervin în relaţie caracterizează dimensiunea asociaţiei: • asociaţii binare între două entităţi;


• asociaţii ternare între trei entităţi; • asociaţii n-are între n entităţi. În general se utilizează ca nume de asociaţie un verb care să sublinieze cât mai bine relaţia dintre entităţi. Spre exemplu asociaţia LUCREAZA permite să se înţeleagă faptul că un SALARIAT lucrează într-o SECTIE.

Figura 4.10. Asociaţie

d) realizarea unei asociaţii - este o asociaţie individualizată adică o pereche, triplet, etc. constituit dintr-o singură apariţie a fiecărei entităţi participante la relaţie. Spre exemplu în afirmaţia "salariatul Popescu lucrază în departamentul Personal" cuplul Popescu/Personal este o realizare a asociaţiei LUCREAZA. e) asociaţie reflexivă - este o relaţie care există între realizarea unei entităţi şi o altă realizare a aceleiaşi entităţi. Spre exemplu asociaţia INCADRAT este o asociaţie reflexivă care traduce faptul că un anumit SALARIAT are posibilitatea de a încadra (angaja) alţi salariaţi.

pagina 123


Figura 4.11. Asociaţie reflexivă

f) legătura - reprezintă o relaţie între o entitate şi o asociaţie. Ea este caracterizată prin cardinalitatea sa. Se poate distinge printr-un nume, ceea ce este foarte practic în cazul asociaţiilor reflexive. g) cardinalitate - permite să se exprime funcţionalitatea şi totalitatea sau parţialitatea unei relaţii: • cardinalitatea minimală - este numărul minim de

participări ale realizări unei entităţi la realizările unei asociaţii;

• cardinalitatea maximală - este numărul maxim de participări ale realizării unei entităţi la realizările unei asociaţii.

pagina 124


Figura 4.12. Cardinalitate

Spre exemplu dacă se examinează MCD-ul următor:

Figura 4.13. Exemplu cu entităţi, asociaţie şi

cardinalităţi se poate spune că aceste cardinalităţi indicate între entităţile SALARIAT şi asociaţia LUCREAZA se traduc astfel: • orice salariat lucrează în cel puţin o secţie, • orice salariat lucrează în cel mult o secţie, • adică orice salariat lucrează într-o singură secţie. În

acelaşi fel cardinalităţile dintre SECTIE şi asociaţia LUCREAZA se traduc prin: într-o secţie lucrează cel

pagina 125


pagina 126

puţin un salariat şi într-o secţie lucrează cel mult n salariaţi, adică mai mulţi salariaţi.

Se constată că toate cardinalităţile permit să

transpună realitatea şi în consecinţă alegerea lor este primordială. În plus, după cum se va vedea în continuare, ele au o influenţă deloc neglijabilă asupra MFD.

Cardinalităţile principale sunt constituite din următoarele combinaţii: 0,1 - niciunul sau unul singur 1,1 - unul şi unul singur 0,n - niciunul sau mai mulţi 1,n - cel puţin unul sau mai mulţi Este posibil să se genereze şi alte cardinalităţi decât acestea, spre exemplu 0,2 dar în modelul fizic al datelor cardinalităţile superioare lui 1 sunt transformate în cardinalităţi n. h) informaţia - este componenta elementară a sistemelor informaţionale. (ex. nume, prenume, cod postal, etc.) i) domeniul - permite să se formalizeze ansamblul valorilor care stau la baza informaţiilor. Toate valorile luate de informaţii şi care sunt transferate entităţilor constituie ansamblul valorilor din sistemele informaţionale. Exemple: domeniul dobânzilor - numere pozitive cu 7 întregi şi 2 zecimale; domeniul numelor - alfabetic cu majuscule. j) proprietate - este informaţia care se ataşază unei entităţi sau unei asociaţii. Ea poate referi un domeniu


deci ea îi poate moştenii caracteristicile (tip, lungime, listă de valori).

Numele fiecărei proprietăţi poate fi înscris în simbolul entităţii sau asociaţiei atunci când acestea sunt purtătoare de atribute. Exemplu: entitatea SALARIAT are proprietăţile marca, nume, prenume, iar asociaţia INCADRAT are proprietăţile data de început şi data de sfirsit.

Figura 4.14. Proprietăţi

k) identificatorul unei entităţi - este constituit din una sau mai multe proprietăţi particulare ale unei entităţi astfel încât la fiecare valoare a identificatorului corespunde o singura realizare a entităţii. Toate entităţile trebuie să posede un identificator care poate fi compus din una sau mai multe proprietăţi. Prin convenţie proprietăţile cu rol de identificator sunt subliniate. De exemplu proprietatea MARCA este identificatorul entităţii SALARIAT adică poate defini fără ambiguitate fiecare salariat.

pagina 127


Figura 4.15. Identificator

l) identificatorul unei asociaţii - este intotdeauna obţinut prin concatenarea indentificatorilor entităţilor participante la asociaţie. Acest identificator nu figurează în MCD. m) legatură-identificator. S-a văzut necesitatea ca fiecare entitate să aibă un identificator, dar în anumite cazuri acesta nu este suficient. Dacă se urmăreste MCD-ul următor:

Figura 4.16. Legatură identificator

pagina 128


pagina 129

se constată că cele două entităţi sunt legate printr-o relaţie de compoziţie. S-ar putea dori să se definească identificatorul "cod lucrare" din entitatea elementară LUCRARE, relativ la identificatorul "cod proiect" din entitatea compusă PROIECT. Dar cum este posibil ca două lucrări să aibă acelaşi cod dacă ele aparţin unor proiecte diferite, se va putea identifica fară ambiguitate o lucrare prin codul său şi prin codul proiectului căruia îi aparţine. În acest caz legătura care porneşte de la entitatea elementară este numită LEGATURĂ-IDENTIFICATOR, şi are obligatoriu cardinalitatea 1,1. Pe grafic această cardinalitate apare între paranteze, diferenţiindu-se în acest fel de o legatură 1,1 normală. n) legatura de moştenire. Moştenirea poate fi exprimată ca o legătură particulară între entităţi în acelaşi timp foarte apropiate dar totuşi diferite. Datorită acestui concept de entitate generală sau mamă, se exprimă caracteristicile comune mai multor entităţi formând o aceiaşi familie. Conceptul complementar de entităţi specializate, particulare sau fiice ale unei entităţi generale exprimă caracteristicile proprii fiecărui membru al familiei. Se vorbeşte de asemenea de legături generice între entităţi tip şi sub-tip. Toate proprietăţile definite pentru entitatea generală sunt moştenite de către entităţile specializate. În acelaşi timp toate asociaţiile unei entităţi generale sunt valabile pentru entităţile specializate. Această noţiune permite îmbogăţirea considerabilă a MCD punând în evidenţă noţiunile de tip şi sub-tip în sînul unei aceleiaşi entităţi.


În plus ea permite utilizatorului să genereze un MFD care ţine cont într-adevar de specificaţiile arătate. Se evită astfel, fie redundanţa informaţională fie înlocuirea coloanelor care au valori nule. Fie de exemplu entitatea ANGAJAT, care cuprinde angajaţii de gen masculin şi pe cei de gen feminin. Se poate reprezenta această particularitate prin noţiunea de moştenire considerând entităţile ANGAJAT MASCULIN şi ANGAJAT FEMININ ca entităţi specializate ale entităţii generale ANGAJAT. Reprezentarea constă într-o legătură cu sageată care pleacă din entitatea fiică şi puncteză entitatea mamă. Un simbol în forma de semicerc este desenat în mijlocul legăturii şi serveşte ca punct de întâlnire pentru alte legături venind de la alte entităţi fiică.

Figura 4.17. Moştenire Reguli de normalizare a MCD Elaborarea unui MCD se realizează în mai multe etape, şi este adesea supusă modificărilor pe parcursul realizării proiectului informatic. Una din etapele

pagina 130


pagina 131

esenţiale ale realizarii unui MCD este verificarea modelului aplicând un numar de reguli numite reguli de normalizare. Se obţine în acest fel un modelul cu redundanţă minima în stocarea datelor. REGULA 1. Toate entităţile trebuie să posede un identificator. REGULA 2. Toate proprietăţile unei entităţi sau unei asociaţii trebuie să fie elementare, adică nedecompozabile. REGULA 3. Pentru fiecare realizare a unei entităţi sau asociaţii, două proprietăţi nu pot reprezenta aceiaşi informaţie reală, adică nu pot să aibă valori repetate pentru o aceiaşi realizare a entităţii sau asociaţiei. REGULA 4. Toate proprietăţile, altele decât indentificatorul, trebuie să depindă în întregime de identificator şi nu numai de o parte din el. REGULA 5. Fiecare proprietate trebuie să depindă direct de identificator şi nu prin intermediul uneia sau mai multor proprietăţi. Dacă modelul îndeplineşte regulie 1,2 şi 3 este în PRIMA FORMĂ NORMALĂ. Dacă îndeplineşte şi regula 4 modelul este în A DOUA FORMĂ NORMALĂ. Dacă îndeplineşte şi regula 5 modelul este în A TREIA FORMĂ NORMALĂ.


Exemplu: "Un salariat al unei întreprinderi, împărţită în secţii, lucrează într-o singură secţie şi participă la minim două proiecte. Fiecare secţie are un cod şi o denumire." Această prezentare se traduce în urmatorul MCD.

Figura 4.18. Model nenormalizat

Regulile normalizării nu sunt respectate, şi nu se poate spune nici măcar dacă este în prima formă normală. De altfel: • nici o proprietate nu este identificator (R1) • proprietatea ADRESA nu este elementară (R2) • este o repetare a numelor de proiect (R3). Dacă se admite că pentru o secţie dată nu există doi salariaţi având acelaşi nume, se va putea alege ca identificator cuplul COD_SECTIE, NUME. Proprietatea ADRESA se descompune de exemplu în două proprietăţi elementare STRADA şi ORAS. Repetarea numelui de proiect se va traduce cu ajutorul unei entităţi PROIECT şi a unei asociaţii PARTICIPA. Se obţine astfel următorul MCD.

pagina 132


Figura 4.20. Model în prima formă normală

Acest MCD este acum în prima formă normală. Se poate constata că nu este respectată regula 4. Cuplul COD_SECTIE, NUME identifică fără ambiguitate fiecare salariat, dar proprietatea DEN_SECTIE nu depinde decât de o parte a identificatorului, proprietatea COD_SECTIE. Pentru a respecta a doua formă normală, se adaugă entităţii SALARIAT o nouă proprietate denumită MARCA care identifică fără ambiguitate fiecare salariat din întreprindere, iar DEN_SECTIE depinde direct de MARCA. Se obţine următorul MCD:

Figura 4.21. Model în a doua formă normală

pagina 133


Acest model este acum în a doua formă normală dar nu este în a treia formă normală pentru că nu este respectată regula 5. Se constată că proprietatea DEN_SECTIE nu depinde direct de identificator, dar depinde mai curând de proprietatea COD_SECTIE. Dependenţa de identificator nu este directă ci mai degrabă tranzitivă prin intermediul proprietăţii COD_SECTIE. Pentru a elimina acest inconvenient este suficient să se introducă o nouă entitate SECTIE şi o asociaţie LUCREAZA care arată faptul că un salariat lucrează într-o secţie. Se obţine următorul MCD care este acum în a treia formă normală.

Figura 4.22. Model în a treia formă normală

În concluzie prima formă normală este suficientă pentru implementarea unui ansamblu de date, dar trebuie urmărită atingerea celei de-a treia forme normale pentru a minimiza redundanţa informaţională şi în consecinţă riscurile discordanţelor dintre date. Normalizarea este deci un proces prin excelenţă intelectual, căci bazat pe analiza semantică a proprietăţilor şi plecând de la un ansamblu amorf de date se obţine un model conceptual în a treia formă normală.

pagina 134


pagina 135

4.3.2. Modelul logic al datelor

În timp ce modelul conceptualal al datelor este independent de sistemul de gestiune al fişierelor utilizat, la nivel organizaţional trebuiesc integrate soluţiile de organizare a datelor astfel încât formalismul entitate/relaţie să poată fi transcris cât mai exact, la nivelul fizic, în termenii limbajului de gestiune a datelor ales. Alegerea depinde de tipul software-ului avut la dispoziţie, şi noul model rezultat (modelul logic al datelor - MLD) trebuie să ţină cont de posibilităţile acestui software fără însă să intre în detaliile tehnice ale metodelor de stocare şi de acces specifice următorului nivel, nivelul fizic. Alegerea sistemului de gestiune a datelor se poate face între fişiere şi baze de date. Utilizarea fişierelor constă în înmagazinarea pe suport accesibil prelucrării automate, a datelor prelucrate în cadrul fiecărei componente a sistemului informatic. Un fişier se constituie dintr-o submulţime de date relativ omogene relative la o clasă de elemente a sistemului informaţional. Identificatorul unui fişier este o proprietate aleasă astfel încât la fiecare valoare a acestei proprietăţi să corespundă o singură realizare a unui articol din fişier. Articolul dintr-un fişier este o colecţie de proprietăţi care se referă la acelaşi element. O realizare a articolului reprezintă ansamblul proprietăţilor pentru un articol individualizat. Se pot distinge două feluri de fişiere: • fişiere clasice de tip BASIC, FORTRAN, COBOL etc. • fişiere secvenţial-indexate multicriteriale tip DBASE.


pagina 136

Cu fişierele clasice accesul după criterii multiple este dificil şi sisteme de gestiune a fişierelor ca de exemplu cel din COBOL nu permit decât funcţii de adăugare, căutare, modificare şi ştergere. Orice altă operaţie rămâne în sarcina programatorului. La fişierele secvenţial-indexate multicrteriale accesul se face după mai multe chei, este mult mai uşor şi sunt oferite mai multe posibilităţi de prelucrare. Metoda fişierelor prezintă inconveniente majore, idiferent de tipul de fişiere folosit: • existenţa renundanţelor; • apariţia unor probleme de coerenţă; • procedurile de securitate trebuiesc programate; • programatorul trebuie să gestioneze el însuşi relaţiile

între fişiere • programatorul trebuie să cunoască metodele de

stocare şi de acces; • creşterea complexităţii sistemului duce la dificultăţi

sporite de întreţinere. Ca urmare a persistenţei acestor inconveniente în informatica mondială s-a impus un nou concept care a devenit dominant încă din anii '70. Acesta este conceptul de bază de date. În sistemele de o anumită complexitate sunt necesare metode performante pentru definirea, organizarea memorarea şi actualizarea datelor. Astfel o bază de date poate fi definită ca un ansamblu de date organizat unitar şi structurat a cărui gestionare se face printr-un sistem specializat denumit sistem pentru gestionarea bazelor de date (SGBD). Notiunea de bază de date este caracterizată de urmatoarele: • structurarea datelor; • redundanţă minimă; • coerenţa datelor; • acces după criterii multiple;


pagina 137

• date legate între ele conform cu MCD; • independenţa programelor şi datelor; • securitatea datelor; • actualizare şi interogarea concurentă.

În funcţie de datele de memorat şi de relaţiile dintre ele într-o bază de date pot să apară următoarele tipuri de structuri: • structura arborescentă; când există o singură

legătură între două entităţi ale bazei de date, de la "tată" la "fiu", exploatarea facându-se fie pe traseul "tată-fii" fie invers "fiu-tată".

• structura reţea; când o înregistrare "fiu" poate avea mai multe înregistrări "tată", care permite căutarea în toate direcţiile pornind de la orice entitate. Trebuie menţionat aici modelul CODASYL (Conferance on Data Systems Languages) elaborat la începutul anilor '70, şi ale cărui norme sunt respectate de numeroase sisteme de baze de date.

• structura relaţională; când entitatea este privită ca o relaţie între proprietăţi şi nu ca o înregistrare, asigurându-se o independenţă totală a programelor faţă de date.

Trecerea de la MCD la MLD se poate face către toate tipurile de organizare a datelor, inclusiv către organizarea în fişiere clasice, dar mai utilizate sunt MLD CODASYL şi MLD relaţional. În cele ce urmează vom dezvolta trecerea către MLD relaţional. Modelul logic al datelor utilizează concepte ale modelului relaţional şi presupune dispunerea datelor sub formă de tablouri cu două dimensiuni numite tabele sau relaţii. Pentru a facilita înţelegerea regulilor de trecere de la MCD la MLD trebuiesc definite următoarele concepte:


pagina 138

a) tabel. Un tabel corespunde unei entităţi sau unei asociaţii din MCD şi este alcătuit din linii şi coloane. b) linie. O linie corespunde noţiunii de realizare a entităţii sau asociaţiei. c) coloana. Noţiunea de coloană corespunde noţiunii de proprietate. d) cheie primară. Noţiunea de cheie primară corespunde noţiunii de identificator. e) cheie straină. O coloană a unui tabel este numită cheie straină dacă ea corespunde unei chei primare dintr-un alt tabel. Cheia primară permite accesul la coloanele tabelului de referinţă evitând repetiţiile. Reguli de trecere de la MCD la MLD REGULA 1. Entităţile devin tabele. Proprietăţile devin coloane de tabele. Identificatorii entităţilor devin chei primare ale tabelelor. REGULA 2. Când o asociaţie binară are o legătură 0,1 sau 1,1 şi o alta de cardinalitate 0,n sau 1,n apare o migraţie a cheilor entităţii legate de legatura de cardinalitate 0,n sau 1,n spre cealaltă entitate. Fie MCD-ul din figura 4.23, care prezintă faptul că un "beneficiar" caracterizat prin proprietăţile "cod fiscal" (identificator) şi "nume beneficiar" primeşte una sau mai multe facturi caracterizate printr-un "număr factură" (identificator) şi "valoare factură". O factură este primită de un singur beneficiar .


Figura 4.23. Reguli de trecere de la MCD la MLD;

exemplu Asociaţia nu se transformă într-un tabel la nivelul MLD, dar este explicitată plasând în tabelul "factura" cheia primară a tabelului "beneficiar" care devine o cheie straină. Se obţine astfel următorul MLD:


exemplu Dacă ASOCIAŢIA din MCD prezentată anterior are proprietatea "data" (data primirii facturii) atunci MCD şi MLD corespunzător arată astfel:

pagina 139



exemplu Dacă se utilizează conceptul de LEGATURĂ-IDENTIFICATOR ca în MCD-ul următor care arată că o factură este constituită din una sau mai multe poziţii (rânduri în factură), iar o poziţie aparţine unei singure facturi,


exemplu identificatorul entităţii "poziţii" va fi format din concatenarea identificatorilor entităţilor participante la asociaţie, conform MLD de mai jos:

pagina 140



exemplu REGULA 3. Dacă o asociaţie binară este purtătoarea a două legături de cardinalitate 0,n sau 1,n asociaţia devine un tabel în MLD, în care migrează cheile entităţilor. Asociaţia devine un tabel, în care cheia primară este obţinută prin concatenarea identificatorilor entităţilor participante la asociaţie. Dacă asociaţia are proprietăţi, acestea devin coloane în tabelul care rezultă din asociaţie. Considerând următoarea situaţie: "un client poate să nu cumpere sau să cumpere n produse, iar un produs poate să nu fie cumpărat sau să fie cumpărat de n clienti" , modelele conceptual şi fizic vor arăta ca în figura 4.28.

pagina 141



exemplu Noţiunea de asociaţie din MCD poate fi deci tradusă în funcţie de cardinalităţile asociate , în două feluri: • prin utilizarea conceptului de cheie straină (regula 2); • prin utilizarea unui nou tabel (regula 3). Cardinalităţile alese la nivel conceptual determină deci în mare parte structura fizică, fiind necesară o mare atenţie în alegerea lor. REGULA 4. Atunci când o asociaţie binară are două legături de cardinalitate 0,1 sau 1,1 apare o dublă migraţie a identificatorilor entităţilor. Fie următorul MCD şi corespunzător acestuia următorul MLD.

pagina 142



exemplu În MLD se păstrează cele două entităţi provocându-se în fiecare din ele migrarea reciprocă a identificatorilor. Când asociaţia binară are două legături 0,1 sau 1,1 şi o proprietate, atunci asociaţia se transformă într-un tabel prin trecerea de la MCD la MLD. REGULA 5. Această regulă priveşte în special entităţile generatoare şi entităţile specifice. Fie MCD următor:


exemplu

pagina 143


Există mai multe posibilităţi de a obţine MLD din care o prezentăm pe cea mai simplă, adică crearea unui tabel pentru fiecare entitate, ceea ce se traduce prin migrarea identificatorului şi a proprietăţilor de la entitatea generatoare (mamă) în fiecare entitate fiică:


exemplu Atunci când entitatea generatoare este în asociaţie cu o altă entitate, apare o combinaţie între REGULA 2 şi regulile menţionate mai înainte, rezultatele obţinute fiind în funcţie de cardinalităţile asociaţiei.

pagina 144


pagina 145

4.3.3. Modelul fizic al datelor

Descrierea unui model fizic este strâns legată de sistemul de gestiune a datelor ales. În practică se întâlnesc frecvent trei tipuri de soluţii tehnice: 1. Utilizarea unui sistem de gestiune a fişierelor clasic

având ca metodă principală accesul secvenţial-indexat. Fişierele indexat secvenţiale sau “cu index rar” presupun memorarea înregistrărilor într-un fişier numit fişier principal, în ordinea crescătoare a cheilor şi grupate pe pagini. Se adaugă un fişier de index, ce conţine pentru fiecare pagină din fişierul principal câte o înregistrare cu valoarea celei mai mari chei din pagină şi adresa de început a paginii. Fişierul de index este ordonat crescător în raport cu valoarea cheii. De cele mai multe ori pagina corespunde unui bloc, înlănţuirea blocurilor în ordine crescătoare a cheilor permite parcurgerea secvenţială ordonată a fişierului. Atunci când în fişierul de index se găseşte acelaşi număr de înregistrări cu cele din fişierul principal fişierul se numeşte “cu index dens”. Pentru fişierele de dimensiuni foarte mari, se poate considera fişierul de index din organizarea secvenţial indexată ca fişier principal căruia i se ataşează un fişier cu index rar. Procedând recursiv până se obţine un fişier index ce conţine un singur bloc, se obţine o structură indexată pe mai multe nivele, foarte flexibilă şi eficientă, numită structură B-arbore de la denumirea din limba engleză “balanced trees”.

2. Utilizarea unui sistem de baze de date de tip CODASYL;


pagina 146

Sistemul CODASYL este unul reprezentativ pentru modelul de organizare tip reţea. Acesta se poate implementa uşor prin asocierea a câte unui fişier la fiecare entitate. Înregistrările fişierului corespund realizărilor entităţii şi câmpurile înregistrării corespund atributelor entităţii. Modelul reţea este apropiat de forma de reprezentare a bazelor de date sub forma diagramelor entitate-asociaţie. Deosebirea constă doar în faptul că toate relaţiile ce apar pot fi numai binare de tipul unu-la-unu şi mai-mulţi-la-unu. Această restricţie permite reprezentarea grafică a unei baze de date de tip reţea sub forma unui graf direcţionat numit reţea. Într-o reţea nodurile corespund entităţilor şi relaţiile sunt reprezentate prin săgeţi între noduri de la tată la fiu. Structura de reprezentare reţea este dezvoltarea structurii arborescente permiţănd ca orice colecţie de date să aibă mai multe colecţii de date superioare. O relaţie R de forma mai-mulţi-la-unu de la entitatea E1 la entitatea E2 se implementează ca o mulţime de liste circulare numite inele având capetele în fişierul asociat lui E2. Un inel de capăt e2 aparţinând lui E2 conţine toate elementele e1 aparţinând lui E1 care sunt în relaţie cu e2. Modelul reţea este folosit din ce în ce mai puţin, fiind eficient doar în cazul unor baze de date foarte mari. De aceea acest tip de baze de date nu mai sunt studiate şi dezvoltate.

3. Utilizarea unui sistem de baze de date de tip relaţional. Modelul relaţional se bazează pe noţiunea matematică de relaţie, aşa cum este ea definită de teoria mulţimilor, şi anume ca o submulţime a produsului cartezian al unei liste finite de mulţimi numite domenii. Elementele unei relaţii se numesc


pagina 147

tupluri, iar numărul de domenii (nu toate distincte) din produsul cartezian se numeşte aritatea relaţiei. De obicei relaţiile sunt reprezentate sub forma unor tabele în care fiecare rând reprezintă un tuplu şi fiecare coloană reprezintă valorile tuplurilor dintr-un domeniu dat al produsului cartezian. În reprezentarea sub formă de tabel a unei relaţii, coloanelor şi respectiv domeniilor corespunzătoare lor li se asociază nume intitulate atribute. Mulţimea atributelor unei relaţii se numeşte schemă relaţională. Un alt mod de a defini relaţiile este următorul: prin relaţie înţelegem o mulţime de funcţii definite pe o mulţime de atribute cu valori în reuniunea unor domenii, cu restricţia ca valoarea corespunzătoare fiecărui atribut să se afle în domeniul asociat acelui atribut. Mulţimea tuturor schemelor relaţionale corespunzatoare unei aplicaţii se numeşte schema bazei de date relaţionale, iar conţinutul curent al relaţiilor la un moment dat se numeşte bază de date relaţională. În modelul relaţional entităţile sunt reprezentate sub formă de relaţii în care schema relaţională conţine toate atributele entităţii şi fiecare tuplu al relaţiei corespunde unui element al entităţii. La atributele entităţii se pot adăuga în relaţie şi alte atribute suplimentare utilizate pentru exprimarea relaţiilor între entităţi.

Descrierea modelului fizic al datelor (MFD) va fi facută în limbajul sistemului de gestiune corespunzător soluţiei alese. În plus, mediul de dezvoltare va influenţa şi el foarte mult MFD.


pagina 148

4.3.4. Modelul conceptual al comunicaţiilor

Acest model, numit şi graf actori-flux, permite descrierea informaţiilor schimbate la nivel global în sistem. Conceptele utilizate sunt: a) actor. Se întelege prin actor tot ceea ce joacă un rol în transmiterea unei informaţii şi care produce un flux informaţional (pesoană fizică, juridică, clădire, servicii) Actorii se împart în două categorii: • actori interni, care fac parte din organizaţie; • actori externi organizaţiei sau domeniului studiat. b) flux. Un flux este un schimb de bunuri, bani sau informaţii între un actor emiţător şi unul receptor. Se disting în particular următoarele fluxuri: • fluxuri fizice • fluxuri monetare • fluxuri de informaţii Printre fluxurile de informaţii, în funcţie de natura suportului se va vorbi de flux informaţional oral, documentar sau informatic. O altă clasificare a fluxurilor este în funcţie de locul emiţătorului în raport cu domeniul studiat: • flux intern, atunci când este emis de un actor intern

domeniului; • flux extern, atunci când este emis de un actor extern

domeniului.

c) ordonarea fluxurilor. Această operaţie permite observarea înlănţuirii fluxurilor, putându-se deosebi fluxurile primare de fluxurile secundare.


d) flux primar. Un flux primar este un flux care apare la cel mai scăzut nivel organizatoric într-un domeniu de gestiune. Într-un domeniu contabil, un flux primar va fi de exemplu un borderou de mişcări, document situat în amonte de fluxuri ca jurnalele, cartea mare, balanţa, bilanţul etc.. e) flux secundar. Un flux secundar este un flux a cărui emisie este subordonată preexistentei unuia sau mai multor fluxuri primare sau secundare. De exemplu, emiterea unei facturi este subordonată recepţiei unei comenzi. f) graful fluxurilor. Graful fluxurilor este un graf ale cărui noduri sunt actori iar arcele orientate sunt fluxurile schimbate.

Figura 4.32. Modelul conceptual al comunicaţiilor pagina 149


pagina 150

4.3.5. Modelul conceptual al prelucrărilor

Prelucrările constituie partea dinamică a sistemului informaţional. Ele descriu acţiunile ce trebuie executate asupra datelor pentru obţinerea rezultatelor scontate. Prelucrările nu sunt de fapt decât traducerea regulilor de gestiune care compun activitatea sistemului economic. Reprezentarea schematică face apel la următoarele concepte: 1)domeniu. Noţiunea de domeniu în sensul de "domeniu de gestiune" corespunde unei părţi a sistemului care conţine subansamble coerente. Exemplu: domeniul comercial, domeniul financiar, domeniul personal. 2)procese. Procesele reprezintă subansamble ale unui domeniu. Se recurge la această împărţire atunci când sistemul de studiat este foarte vast. Exemplu: Domeniul comercial al unei întreprinderi poate cuprinde trei procese: urmărire reprezentanţi, primire comenzi şi urmărire comenzi. 3) operaţie. O operaţie este o activitate prin care se produc fluxuri informaţionale. O operaţie este definită imaterial, fără restricţii organizatorice. Ea descrie la fel de bine gestiunea manuală cât şi pe cea automată. O operaţie poate utiliza una sau mai multe entităţi şi/sau asociaţii pentru acţiuni de creare, modificare, ştergere sau consultare. O operaţie se descompune în acţiuni.


Exemplu: O operaţie în domeniul "Evidenţa personalului" ar putea fi "Obţinerea adeverinţei de salariu". Simbolul pentru operaţie este:

Figura 4.33. Operaţie

4) acţiune. O acţiune este o funcţie elementară. Între acţiunile unei operaţii nu există aşteptare, şi derularea lor este secvenţială. O acţiune poate referi una sau mai multe REGULI DE GESTIUNE O operaţie poate utiliza una sau mai multe entităţi şi/sau asociaţii pentru acţiuni de creare, modificare, ştergere sau consultare. Simbolul este:

Figura 4.34. Acţiune

pagina 151


pagina 152

5) reguli de gestiune. O regulă de gestiune este o reglementare care la nivelul întreprinderii se va aplica sistematic. Regulile de gestiune vor servi la definirea ansamblului de reguli care trebuiesc respectate pentru acţiuni. O aceeaşi regulă de gestiune se poate aplica uneia sau mai multor acţiuni. Exemple: 1. Trebuie aplicat 2% reducere clienţilor ale căror

comenzii din anul precedent au depăşit 4.000.000 lei;

2. Comenzile către furnizor trebuie să fie vizate de către şeful serviciului aprovizionare.

6) eveniment. În timpul analizei unei operaţii trebuie întotdeauna să se pună întrebarea "care sunt evenimentele care concură la declanşarea unei operaţii?". Un eveniment se defineşte ca un flux de orice natură, sau un fapt care permite lansarea unei operaţii. Un eveniment va fi în general desemnat printr-un verb la participiu document, ci trebuie conservat aspectul dinamic al descrierii. Se va spune mai bine "comanda primită" decât "comanda". Exemple: Cererea unui deviz este un eveniment. Faptul că suntem în a cincea zi din lună este de asemenea un eveniment. Simbolul pentru eveniment este:


Figura 4.35. Eveniment

Un eveniment are un nume, un cod, şi un alias care apare între paranteze. Se vor distinge: • evenimente declanşatoare, care declanşează o

operaţie sub controlul unei condiţii de sincronizare; • evenimente rezultate, produse de către o operaţie ca

urmare a unei reguli de emisie. Declanşarea unei operaţii este în general condiţionată de prezenţa mai multor evenimente declanşatoare. Aceste evenimente nu apar în acelaşi moment, deci apare necesitatea condiţionării declanşării operaţiei cu o condiţie de sincronizare a evenimentelor declanşatoare. În acelaşi fel, operaţiile, nu generează întotdeauna aceleaşi evenimente rezultante. Producerea evenimentelor rezultante va fi deci supusă regulilor de emisie.

pagina 153


Figura 4.36. Evenimente declanşatoare şi rezultante Evenimentele 1 şi 2 declanşează o operaţie alcătuită din două acţiuni 1 şi 2, iar evenimentele 3 şi 4 sunt rezultatul operaţiei. 7) condiţia de sincronizare. Condiţia de sincronizare este exprimată printr-o condiţie booleană care leagă evenimentele declanşatoare prin operaţii logice ŞI, SAU, NU. Operaţia nu este declanşată decât atunci când condiţia este îndeplinită. Este recomandată folosirea alias-ului pentru descrierea condiţiei de sincronizare. În exemplul din figura 4.37., operaţia nu va fi declanşată decât dacă evenimentul A se produce în acelaşi timp cu evenimentul B sau C. Dacă un singur eveniment este necesar pentru declanşarea operaţiei, condiţia de sincronizare dispare din reprezentarea grafică. 8) regula de emisie. O regulă de emisie defineşte condiţia sub care evenimentele rezultate vor fi produse de către o operaţie. O operaţie poate avea una sau mai multe reguli

pagina 154


de emisie, o regulă gestionând emisia unuia sau a mai multor evenimente rezultate.

Figura 4.37. Condiţia de sincronizare

Figura 4.38. Regula de emisie pagina 155


O operaţie poate să nu aibă regulă de emisie. În acest caz emisia evenimentelor este necondiţionată şi se traduce cu ajutorul cuvântului "totdeauna". O regulă de emisie poate avea un alias pentru uşurarea afişării simbolului operaţiei în cazul în care textul care defineşte regula este prea lung.

Figura 4.39. Modelul conceptual al comunicaţiilor; Exemplu

pagina 156


pagina 157

Evenimentele 1, 2 şi 3 declanşează operaţia 1 punându-se condiţia de sincronizare “a ŞI (b SAU c)”. Operaţia 1 este constituită din acţiunile 1 şi 2 care conduc la regula 2 de emisie. Evenimentele 4 şi 5 sunt rezultate produse de operaţia 1. Operaţia 2 compusă din acţiunea 3 este declanşată de evenimentul 5. Evenimentul 6 este întotdeauna emis de operaţia 2. 9) reguli de creare a unui MCP. Crearea unui MCP poate părea uşoară la prima vedere, dar se poate constata că există tendinţa de a se comite două tipuri de erori: • erori de modelare; • erori de validare a modelului.

10) erori de modelare Erorile de modelare sunt datorate în general dificultăţilor pe care le întâlnim în timpul analizei unui proces în separarea părţii conceptuale de partea organizaţională. Trebuie să ne amintim tot timpul că MCP trebuie să exprime ce trebuie făcut, dar nu arată când trebuie făcut şi nici unde trebuie făcut (concepte organizaţionale) şi încă şi mai puţin cum trebuie făcut (concept operaţional). Cu titlu de exemplu să încercăm modelarea procesului de selecţie a unui candidat la ocuparea unui


post. Această modelare se sprijină pe următoarea prezentare sub formă de text. "La primirea dosarului, un angajat efectuează controlul documentelor din dosar. După care se studiază curriculum vitae-ul redactat de candidat şi care face parte din documentele depuse în dosar. Atunci când aceste controale sunt favorabile, se trimite o convocare pe adresa candidatului"

Figura 4.40. MCP; Erori de modelare

pagina 158


Fără a putea spune că acest model este fals se pot formula totuşi următoarele observaţii: 1. nici un eveniment extern, după venirea dosarului, nu

justifică împarţirea prelucrărilor aşa de detaliat (scrisoarea de respingere reprezintă de fapt numai un singur eveniment);

2. s-a ţinut cont în acest model de o restricţie organizaţională, asimilând o operaţie desfăşurată într-un anumit loc de muncă unei operaţii conceptuale;

În general, atunci când o serie de operaţiuni se înlănţuie fără evenimente externe sau interne justificate cu adevărat, nu trebuie să aibă loc o detaliere a operaţiunilor. Se poate propune următorul MCP:

Figura 4.41. MCP corectat

pagina 159


pagina 160

11) erorile legate de validarea modelului. După conceperea unui MCP, este posibil să se aplice câteva reguli de validare. Aceste reguli, elementare, fac apel mai ales la bunul simţ. a) Reguli legate de operaţiuni. Când s-a plasat o operaţie în model trebuie verificate următoarele: • o operaţie este un ansamblu de acţiuni

neîntreruptibile, adică nu sunt supuse aşteptării unor evenimente. Dacă acest lucru nu este posibil, trebuie folosite mai multe operaţii;

• o operaţie trebuie să fie omogenă, adică fără prelucrări alternative dezechilibrate în interior. O operaţie neomogenă poate să ascundă producerea unor evenimente interne neprevăzute care ar antrena împărţirea operaţiei în mai multe operaţii omogene;

• trebuie să se obţină un rezultat în toate situaţiile; • o operaţie este întotdeauna precedată de cel puţin un

eveniment; • o regulă de emisie trebuie să coexiste întotdeauna cu

contrariul său (afară de cazul "totdeauna"); b)Reguli legate de condiţiile de sincronizare. Când se introduce în model o condiţie de sincronizare, este preferabil să se verifice să nu fie întotdeuna falsă şi să nu existe posibilitatea ca sincronizarea să fie activată de evenimente care sosesc la momente diferite, acesta fiind cazul operaţiei care depinde de mai mult decât de un singur eveniment şi când operaţia este declanşată de fapt de sosirea unui singur eveniment.


Figura 4.42. MCP; Sincronizare nerecomandată

Acest tip de operaţie nu este recomandat pentru că prin condiţia de sincronizare A SAU B producerea evenimentului 1 sau a evenimentului 2 va declanşa operaţia fără nici o aşteptare, fapt care contrazice definiţia sincronizării. În acest sens modelul di figura 4.43. prezintă o anume incoerenţă pentru că producerea evenimentului "b" declanşează imediat şi necondiţionat operaţia 2, ceea ce înseamnă că operaţiile 1 şi 2 sunt în realitate una singură. Este de preferat în acest caz modelul din figura 4.44.

pagina 161


Figura 4.43. MCP cu incoerenţe

Figura 4.44. MCP corectat

pagina 162


12) reguli legate de funcţionarea unui MCP. MCP nu este numai un model static de reprezentare a prelucrărilor, dar este în acelaşi timp un model dinamic a cărui funcţionare este supusă anumitor reguli care depind în cea mai mare parte de context. Se vor aborda numai cazurile în care funcţionarea modelului este imposibilă sau nedeterminată, adică vor fi abordate noţiunile de conflict şi de ciclu. a) Noţiunea de conflict. Se spune că există un conflict relativ la un eveniment dacă acest eveniment contribuie la mai multe sincronizări. Astfel următorul MCP prezintă o situaţie conflictuală:

Figura 4.45. MCP cu conflict

pagina 163


pagina 164

Apariţia evenimentului 2 va putea într-un mod nedeterminat să contribuie la activarea operaţiilor 1 şi 2. Acest conflict poate fi rezolvat în două feluri: • cardinalitatea producerii evenimentului 2 este 2 şi în

acest caz cele două apariţii ale evenimentului 2 sunt folosite în cele două sincronizări;

• condiţiile de participare ale evenimentului 2 la cele două operaţii sunt exclusive.

b) Noţiunea de ciclu. Când o operaţie are ca eveniment declanşator un eveniment pe care ea îl produce nemijlocit sau prin intermediul mai multor operaţii, ne găsim în prezenţa unui ciclu. Folosirea ciclurilor, cu condiţia să fie valide, este o tehnică ce permite să se reducă sensibil mărimea MCP-ului. Un astfel de ciclu (figura 4.46.) este controlat şi condiţiile sale de pornire şi de terminare trebuie să fie clare. Astfel pornirea ciclului se face cu ajutorul evenimentului "start” şi oprirea se face cu ajutorul evenimentului "stop". Aceste evenimente nu sunt fictive, dar corespund în general în practică evenimentelor care introduc restricţii temporale de tipul: "întâi ale lunii, începutul perioadei, 15 ale lunii ..." Validarea modelelor. Validarea modelelor are ca obiectiv sinteza între analiza datelor şi analiza prelucrărilor. Ea permite verificarea între MCD şi MCP. Verificarea acestei coerenţe are ca regulă esenţială verificarea ca toate entităţile şi asociaţiile MCD-ului să fie utilizate de cel puţin o operaţie a MCP.


Figura 4.46. MCP cu ciclu

Entitatea sau asociaţia trebuie atunci să fie asociată unui eveniment declanşator sau rezultant, sau să intervină într-o regulă de gestiune sau un calcul. Când lipsa coerenţei este constatată se poate interveni asupra MCD. Aceasta se poate traduce prin:

pagina 165


pagina 166

• adăugarea de proprietăţi care reprezintă informaţii a căror necesitate nu a fost banuită;

• adăugarea de noi asociaţii care stabilesc dependenţe între entităţi care nu erau corect precizate.

Asocierea modelului datelor cu modelul prelucrărilor este unica operaţie care permite validarea MCD. Operaţia de validare permite trecerea de la un MCD brut la un MCD validat.


pagina 167

4.3.6. Modelul organizaţional al prelucrărilor

Anumite concepte au fost definite la modelul conceptual al prelucrărilor, deci se vor prezenta numai conceptele noi specifice MOP. 1) procedura. O procedură este o succesiune de faze aparţinând aceluiaşi proces şi executat de actori. Este un subansamblu al unui proces din MCP decalaşat de unul sau mai multe evenimente. MOP trebuie să fie stabilit cu grija căci el constituie prima viziune globală şi coerentă a sarcinilor efectuate de către actori, schimburile dintre actori, datele la care fac apel actorii şi restricţiile organizaţionale. 2) actorii. Un actor este o entitate organizaţională însărcinată să efectueze un anumit număr de faze. Un actor aparţinând domeniului studiat este numit actor intern, iar în caz contrar este numit actor extern. Actorii sunt coloanele principale în MOP. O coloană actor dintr-o procedură constituie o "procedură actor". Astfel fiecare procedură actor trebuie să pună în evidenţă contribuţia actorului în cadrul unui proces dat. Procedura actor cuprinde ansamblul sarcinilor efectuate de către un actor, MOP permiţând astfel stabilirea lucrărilor executate de fiecare actor. 3) faza.


O fază este o înlănţuire ninteruptibilă de task-uri cu aceiaşi periodicitate, executate de un actor intern sau extern. O fază este reprezentată grafic prin simbolul:

Figura 4.47. Faza

Acest formalism permite să se vizualizeze imediat: • denumirea fazei; • numele prelucrărilor sau task-urilor care compun

faza; • condiţiile de sincronizare ale evenimentelor

declanşatoare; • regulile de emisie ale evenimentelor rezultante. În plus, o fază relevă caracteristicile următoare: • natura sau tipul prelucrării; • derularea prelucrării; • locul unde se desfăşoară.

O fază poate utiliza una sau mai multe tabele ale unui MLD, pentru consultare, creare, modificare sau ştergere. 4) tipul unei faze.

pagina 168


pagina 169

Tipul unei faze este gradul său de automatizare. O fază este manuală sau automată. O fază poate fi în întregime automată sau interactivă. 5) derularea unei faze. Derularea unei faze se caracterizează prin periodicitatea sa şi prin durata sa. Pentru durată se va indica ora de început şi durata maximă a fazei. 6) locul de desfăşurare a activităţii. Locul de desfăşurare a activităţii înglobează conceptul de actor căruia i se atribuie caracteristici organizaţionale. Aceste caracteristici sunt tipul locului de desfăşurare, responsabilul şi resursele. Tipul locului reprezintă ansamblul locurilor unde acţiunile unei operaţii conceptuale se pot efectua. Resursele sunt ansamblul mijloacelor care permit realizarea anumitor acţiuni ale unei operaţii. Resursele pot fi consumabile sau reutilizabile. Caracteristicile legate de desfăşurarea unei faze sunt indicate în coloana "perioadă" a MOP iar tipul este indicat în coloana "tip". Actorul sau locul de desfăşurare a activităţii relativ la o faza este indicat prin coloana unde figurează faza. La fiecare operaţie conceptuală din MCP îi corespunde una sau mai multe faze. 7) task. O fază este descompusă în task-uri. Un task reprezintă o funcţiune elementară. Un task poate folosi una sau mai multe reguli de organizare. Conceptul de task este foarte important pentru că el stă la baza dezvoltărilor ulterioare. 8) eveniment.


pagina 170

Conceptul de eveniment este acelaşi care a fost definit în MCP, cu deosebirea că noţiunea cuprinde şi alte tipuri de evenimente care îmbracă mai ales aspectul organizaţional (introducerea unei comenzi, decizia superiorului, etc.) Aceste evenimente, iniţiate prin regulile de organizare, vor avea un efect deloc neglijabil asupra împărţirii operaţiilor conceptuale în faze. 9) reguli de organizare. O regulă de organizare decurge dintr-o alegere organizatorică. O regulă de organizare poate fi aplicată unuia sau mai multor task-uri. Ele corespund adesea unei reguli de gestiune căreia i se dă o dimensiune organizatorică. Exemplu: O regulă de gestiune spune că "orice client trebuie să fie solvabil". La nivel organizaţional, se îmbogăţesşte această regulă precizând modul de calcul prin care să se permită verificarea solvabilităţii clientului. Astfel, orice regulă de calcul poate fi o regulă organizaţională. 10) modul. Conceptul de modul permite să se arate cu ce mijloc (în general informatic) poate să se execute un task. Un modul constă din: un ecran de culegere, un program de editare, etc.. Un acelasi modul poate fi utilizat de unul sau mai multe task-uri. Un modul poate utiliza unul sau mai


multe tabele ale unui MLD, în consultare, creare, modificare sau ştergere. Pentru exemplificare prezentăm un model ipotetic privind prelucrarea unor cereri de aprovizionare.

Figura 4.48. Modelul organizaţional al prelucrărilor

Reguli de concepere a unui MOP.

pagina 171

MOP poate fi dedus din MCP. Analiza restricţiilor organzaţionale condiţionează în întregime trecerea de la MCP la MOP. El se caracterizează prin luarea în


pagina 172

considerare a restricţiilor organizaţionale. Se trece într-adevar de la un ansamblu de lucrări finalizate (operaţiile conceptuale), la un ansamblu de lucrări organizate (task-urile), având numeroase restricţii organizaţionale. Metoda va consta în analiza restricţiilor organizaţionale şi în împarţirea fiecărei operaţiuni conceptuale. 1) Analiza restricţiilor organizaţionale. Analiza restricţiilor organizaţionale va permite punerea în evidenţă a noilor actori şi a noilor evenimente. Evenimentele unui MOP pot fi conceptuale sau numai organizaţionale. Un eveniment este conceptual dacă el decurge direct dintr-un MCP şi este organizaţional în caz contrar. Evenimentele organizaţionale pot fi purtătoare sau nu de date. În cazul în care ele sunt purtătoare de informaţii, ele fac obiectul unei descrieri, care va servi la validarea modelelor de date. În cazul când ele nu sunt purtătoare de date, acestea sunt evenimente de tipul "resursă disponibilă" şi nu este necesar să se reprezinte în MOP. În acest caz, se vor regăsi în coloana "perioadă" sau "tip". 2) Împarţirea fiecărei operaţiuni conceptuale. Punerea în evidenţă a unor noi actori şi/sau a unor noi evenimente va permite împărţirea fiecărei operaţii conceptuale în faze. Fiecărei operaţiuni conceptuale din MCP îi va corespunde: • o fază unică în MOP; este cazul unei operaţii

conceptuale care poate fi complet executată de un actor într-o aceiaşi unitate de timp.

• mai multe faze în MOP; este cazul unei operaţii conceptuale care trebuie să fie împarţită în mai


pagina 173

multe subansamble de periodicităţi diferite pentru unele acţiuni sau o împărţire rezultând dintr-o restricţie organizatorică.

Pentru mai buna descompunere a unei operaţii

conceptuale, este necesar să se procedeze la o analiză ascendentă plecând de la rezultate spre evenimente. Astfel, o operaţie conceptuală dă întotdeuna cel puţin o faza de producere a unui rezultat. Eventual, dacă sunt necesare calcule prea lungi pentru producerea rezultatului se poate defini o fază de calcul specific. Se vor distinge atâtea faze de achiziţie de date câte fluxuri informaţionale necesită o introducere de date. Ansamblul fazelor astfel obţinute, prin descompunerea procedurii funcţionale, pot fi eventual din nou combinate dacă: • la ele nu participă decât un singur actor; • nu necesită decât resurse identice; • nu au loc decât în acelaşi moment; • nu sunt supuse unei aşteptări de natura

organizaţională. În cursul descompunerii unei operaţii conceptuale, este frecventă obţinerea unei faze care a fost deja determinată anterior. În acest caz nu se va reţine decât o singură fază. Se constată că metoda nu constă în analiza restricţiilor organizaţionale şi apoi împărţirea fiecărei operaţii conceptuale, ci mai curând împărţirea operaţiilor în acelaşi timp cu analiza restricţiilor organizaţionale. Orice fază trebuie să fie caracterizată de o unitate de loc, o unitate de timp şi o unitate de resurse. Validarea modelelor are ca obiectiv sinteza între analiza datelor şi analiza prelucrărilor. Ea permite


pagina 174

verificarea coerenţei între MLD şi MOP. Verificarea acestei coerenţe se efectuează la două niveluri: • toate tabelele din MLD sunt necesare; • orice coloană din MLD este utilizată de cel puţin o

operaţie din MOP. Coloana trebuie să figureze la un eveniment declanşant sau rezultant, sau să intervină într-o regulă organizatorică. Un al doilea nivel mult mai detaliat care verifică dacă accesul la o tabelă este necesar în raport cu obiectivele task-ului care se efectuează. Când se constată o lipsă de coerenţă poate fi necesară intervenţia în modelele de date şi chiar modificarea la nivelul MCD. Aceasta se poate traduce prin: • adăugarea de proprietăţi care reprezintă informaţii a

căror necesitate nu a fost bănuită; aceasta poate conduce la o anumită denormalizare a modelului de date;

• adăugarea de noi asociaţii care stabilesc dependenţe între entităţi care nu erau corect precizate;

• adăugarea la nivelul MLD a unor noi indecşi care asigură timpi de răspuns mai bun.


pagina 175

4.3.7. Modelul operaţional al prelucrărilor

Scopul modelului operaţional al prelucrărilor (MOpP) este de a descrie arhitectura programelor care vor fi realizate pornind de la fazele descrise în MOP. Aceste programe vor fi: programe "batch" sau programe de prelucrare a tranzacţiilor (pentru faze în "timp real"). Se recomandă respectarea câtorva reguli în funcţie de tipul programelor. Astfel pentru programele "batch": • împărţirea acestora după periodicitatea de

prelucrare; • împarţirea după tipul de prelucrare (validare,

calcul,actualizare, editare) Pentru prelucrarea tranzacţiilor se recomandă următoarele reguli: • fiecărui ecran îi va corespunde o tranzacţie; • fiecare tranzacţie va fi structurată în afişare ecran,

introducere date, prelucrare ecran (normalizare I.S.O.);

• stabilirea normelor ergonomice pentru afişarea ecranului şi introducerea datelor;

• împărţirea prelucrărilor în validări, calcule, actualizări şi editări;

Descrierea nivelului operaţional al prelucrărilor va evolua foarte mult în următorii ani prin utilizarea limbajelor de baze de date ca SQL şi prin generalizarea programării orientate pe obiecte.


pagina 176

4.4. Ciclul de decizie

Ciclul de decizie cuprinde toate deciziile luate pe parcursul desfăşurării proiectului, mai generale la început şi apoi din ce în ce mai precise. Deciziile globale trebuie luate de directorul general, dar la fiecare nivel trebuie consultat personalul implicat. Ierarhia deciziilor care se pot lua este următoarea: • împărţirea sistemului informaţional în domenii; • orientările generale în ceea ce priveşte gestiunea,

organizarea şi soluţiile tehnice; • planificarea dezvoltării; • alegerea între procedurile manuale şi automate; • alegerea procedurilor ce se vor executa în timp real; • determinarea locurilor de muncă şi a sarcinilor

respective; • conceperea ecranelor, listelor, etc.

În responsabilitatea conducerii cade în mod normal iniţierea proiectului şi ulterior terminării acestuia evaluarea reuşitei proiectului. Această observaţie ne duce spre ideea că o corectă abordare a ciclului de decizie trebuie începută de la nivelul sistemului informaţional, prin împărţirea sistemului în zone de interes şi prin stabilirea orientărilor generale. Totodată trebuie făcută o diferenţa între atitudinea decizională pasivă, care lasă lucrurile să evolueze în mod “natural” şi o politică managerială consecventă în direcţia informatizării. Din constantările practice se observă o etapizare "naturală" în introducerea prelucrării automate a datelor.


pagina 177

Această etapizare depinde de condiţiile obiective existente în economie: • starea tehnologiei hardware; • starea tehnicilor de rezolvare a problemelor

fundamentale; • riscul pe care-l implică deficienţele de organizare. Deşi tehnologia hardware este uniformă în cea mai mare parte a lumii, tehnica rezolvării problemelor fundamentale, variază de la industrie la industrie şi de la întreprindere la întreprindere. Valoarea riscului pe care-l implică, deficienţele de organizare variază de la caz la caz. Pragul de la care o anumită activitate devine riscantă este o problemă subiectivă şi se stabileşte în funcţie de nivelul acceptat al probabilităţii de producere a evenimentelor nefavorabile. Dar miza depăşirii eventualelor dificultăţi este mare deoarece un succes mai însemnat realizat de o întreprindere va stârni un ecou rapid în rândul celorlalte. Etapizarea pătrunderii calculatoarelor într-o întreprindere, sintetizată pe baza mai multor constatări practice este următoarea: 1. aplicaţii de bază ale calculatoarelor; 2. aplicaţii intradivizionare ale calculatoarelor; 3. aplicaţii interdivizionare ale calculatoarelor; 4. aplicaţii avansate ale calculatoarelor. Această etapizare nu presupune o intervenţie coordonată în direcţia informatizării. Bineânţeles că în cazul unei opţiuni ferme de realizare a unui sistem informatic se va putea aborda direct etapa finală în utilizare a calculatoarelor. 1. Prima arie de aplicaţii într-o întreprindere productivă este aceea în care se cere un efort individual, sau cel mult, cooperarea între grupuri mici.


pagina 178

Ca rezultat, aplicaţiile iniţiale sunt limitate la proiecte de proporţii şi complexităţi reduse. în plus hard-ul se alege dintre cele mai ieftine alternative, din cauza tendinţei normale de limitare a riscului financiar în introducerea unei tehnologii noi şi nu prea cunoscute. Accentul în primele aplicaţii se pune pe înlocuirea muncii umane în activităţi de sortare, raportari scrise şi rezolvări de ecuaţii. 2. O altă etapă este aceea când se utilizează personalul dintr-un singur compartiment şi este caracterizată prin întreţinerea şi punerea la zi a fişierelor şi printr-un nivel mai ridicat al complexitatii. Aplicaţiile includ state de plată, stocuri, registre contabile generale, balanţe, calculul dividentelor, evidenţa mijloacelor fixe, etc.. 3. Cea de-a treia etapă se caracterizează prin încercarea de rezolvare a unor probleme economice care cer un număr limitat de cooperari între sectoare. Există un interes crescând pentru optimizarea sistemelor complexe şi de regulă, majoritatea întreprinderilor urmăresc să câştige maximum prin optimizarea planificării şi utilizării echipamentelor electronice. După cum sarcinile de lucru cresc pentru echipamentele de calcul ale intreprinderii, există tendinţa de a favoriza aplicaţiile mai urgente, astfel încât apar cozi de aşteptare în vederea punerii la punct a celorlalte aplicaţii. O rezolvare a acestei probleme este descentralizarea responsabilităţilor de calcul.

În această etapă se încearcă şi câteva din aplicaţiile cele mai simple de comandă a proceselor de producţie. Comanda proceselor şi-a câştigat o largă apreciere în industriile unde produsele sunt elaborate fie în flux continuu sau proces intermitent şi unde controlul permanent al materiei prime, împreună cu controlul


pagina 179

condiţiilor de funcţionare, determină îmbunătăţirea produselor şi reducerea cheltuielilor de producţie. 4. La sfârşitul etapei a treia devine clar pentru multe întreprinderi că apropierea treptată de rezolvarea problemei şi de păstrarea înregistrărilor nu ţine pasul cu cerinţa întreprinderii pentru informare şi răspuns. Un răspuns la această problemă este implementarea unui sistem informatic integrat. În industriile care au o producţie de masă, cu utilizarea unei tehnologii omogene, aceste sisteme pot fi introduse fără prea mari dificultăţi. Totuşi, majoritatea întreprinderilor productive au o tehnologie extrem de diversificată în ceea ce priveşte primirea comenzilor, achiziţionarea de materii prime, distribuirea, depozitarea şi mecanismul de desfacere. Un element simplu ce exemplifică eterogenitatea schimburilor de informaţii este numărul de formulare diferite utilizate în interiorul întreprinderii. Cu toate că aceste sisteme sunt deseori denumite sisteme informatice de conducere, elementul lor comun este necesitatea unei baze de date integrate.

În opoziţie cu atitudinea pasivă se află acţiunea

conştientă prin care strategia întreprinderii trebuie să beneficieze de o serie de orientări generale care să-i permită câştigarea unor avantaje competitive. În acest sens modelul următor permite corelarea scopurilor întreprinderii cu avantajele potenţiale dar şi cu efortul necesar. Conducătorul este pus aşadar în faţa unei probleme foarte importante şi deloc uşoară. Este evident că are nevoie de o tehnologie informatică, dar care aplicaţii informatice din cele existente sau dintre cele oferite pe piaţă au o importanţă strategică şi pot influenţa în mod decisiv potenţialul firmei? El trebuie să ştie când tehnologia informatică este un element critic


pagina 180

pentru întreprinderea sa. O cale posibilă pentru o investigaţie de acest fel o constituie Modelul strategic tip grilă (The Strategic Gril Model; Figura 4.49.) care permite determinarea importanţei şi impactului strategic prin situarea firmei într-un cadran cu două dimensiuni: • impactul strategic al sistemelor existente; • impactul strategic al dezvoltării sistemelor (sistemele

viitoare) În cadranul 1 “suport” (de sprijin) sistemele informatice sunt văzute ca având un impact redus asupra activităţii firmei şi tind să rămană aşa şi în viitor. Dependenţa activităţii firmei de sistemele informatice este considerabil scăzută. Tehnologia informatică este percepută ca un sprijin funcţional fără să implice investiţii semnificative şi sunt coordonate de la un nivel ierarhic mijlociu şi scăzut. În cadranul 2 “factory” (de fabricaţie) deşi sistemele informatice sunt importante în afacerile firmei ele nu sunt în centrul dezvoltării strategice. Un posibil exemplu l-ar putea constitui o întreprindere în care producţia este condusă prin sisteme de control în timp real dar viitoarele dezvoltări ale sistemului informatic nu vor influenţa semnificativ activitatea firmei. În cadranul 3 “turnaround” (revenire) sistemele informatice nu au fost foarte importante în trecut dar realizarea de noi sisteme a început să devină critică pentru activitatea viitoare a firmei. Firma realizează această schimbare de optică nu numai datorită unei creşteri a activităţii ci mai ales pentru menţinerea pe piaţă într-un mediu economic perturbat. Se poate exemplifica acestă situaţie cu o întreprindere în care planurile de dezvoltare sunt puternic legate de tehnologia informatică.


Figura 4.49. Modelul strategic “grila”

În cadranul 4 “strategic” se reprezintă firmele a căror activitate depinde în mod critic de existenţa sistemelor informatice. O performanţă scăzută ori căderea acestor sisteme poate fi cauza unor disfuncţionalităţi majore. Mai mult, dezvoltarea sistemului informatic este critică pentru activitatea firmei şi trebuie să cadă în sarcina conducerii executive a firmei. Rolul important al tehnologiei informatice este remarcat şi de volumul semnificativ de investiţii din acest domeniu. Exemple de firme din acest cadran sunt băncile, companiile de asigurări, firme de brokeraj, ziare, institute de cercetări de marketing, etc. Situarea întreprinderii în acest cadran trebuie să vizeze lanţul

pagina 181


pagina 182

producţie-desfacere, existând posibilitatea ca diferite alte activităţi să se găseasca în celelalte cadrane. Acest model permite o privire statică asupra prezentului şi viitoarei dependenţe de sistemele informatice. De altfel este important de urmărit mişcarea în timp în interiorul grilei. Trecerea din cadranul “suport” în “strategic” se poate face sub presiunea progresului tehnologic, a competiţiei de pe piaţa sau a unor noi obiective în dezvoltarea firmei. La fel de importantă este acţiunea conducătorului şi la nivelul dezvoltării componentelor sistemului informatic, cu observaţia că în acest caz este vorba de o conducere de nivel inferior. O proastă conducere poate afecta succesul proiectului mai mult decât alţi factori, dar acest fapt, în mod surprinzător, este mai puţin înţeles în procesul de dezvoltare a software-ului. Toate modelele anterioare ale ciclului de viaţă nu tratează conducerea ca un model distinct ci privesc conducerea proiectului ca o parte inseparabilă a procesului de dezvoltare a software-ului. Pentru clarificarea acestui aspect s-a recurs la următoarele diagrame care evidenţiează implicarea factorului de conducere în realizarea proiectului. (Figura 4.50.) La acest nivel de prezentare condiţia iniţială este “iniţierea proiectului” şi rezultatul este “proiect realizat”. Resursele reprezintă tot ceea ce s-a consumat pentru realizarea proiectului. Pentru furnizarea mai multor amănunte această diagramă poate fi detaliată pentru şase etape ale ciclului de viaţă al proiectului: analiza preliminară, proiectarea logică, proiectarea tehnică, construcţia, implementarea şi testarea.


Figura 4.50. Conducerea proiectului

În figura 4.51. este prezentat modelul conducerii procesului pe parcursul ciclului de viaţă al sistemului. Modelul este numit “model comportamental” sau “model de conducere pe bază de evenimente”. El arată stările în care se poate afla sistemul şi este folosit pentru descrierea dependenţelor, pentru alocarea resurselor şi pentru finanţare. Dreptunghiurile reprezintă stări sau grupuri de stări legate între ele în diferite moduri, iar intrările şi ieşirile sunt evenimente care permit tranziţia de la o stare la alta. Stările, permit conducătorului de proiect comunicarea şi măsurarea activităţiil asociate proiectului în dezvoltare. Se observă că evenimentele sau condiţiile de ieşire asociate stărilor sunt stabilite pentru ca managerul să ştie când o anumită fază este completă astfel încât să poată începe următoarea.

pagina 183


Figura 4.51. Conducerea proiectului pe etape ale ciclului de viaţă

AC (Asigurarea Calităţii) reprezintă semnalul prin care care să se garanteze că produsul se conformează unor standarde IEEE Standard for Sofware Quality. Calitatea produsului constă în totalitatea trăsăturilor sau caracteristicilor sale care îi permit să se conformeze necesităţilor utilizatorului. Controlul calităţii constă în acţiunile necesare pentru măsurarea caracteristicilor produsului şi compararea lor cu specificaţiile. Calitatea nu poate fi testată în produs dar ea trebuie să fie construită în interiorul produsului. Procesul trebuie să înceapă din primele etape şi să continuie până la şfârşitul ciclului de viaţă, pentru că fiecare etapă constituie o nouă ocazie pentru alte tipuri de erori. CM (Componenţa Managementului) este aspectul care permite identificarea în timp a acelor puncte pentru

pagina 184


pagina 185

efectuarea contrulului modificărilor, pentru monitorizarea integrităţii şi trasabilităţii produsului pe parcursul ciclului de viaţă. Aceasta permite conducătorului să cunoască ce s-a făcut, ce se realizează acum şi cu ce se va continua mai departe. V+V (Verificarea şi Validarea) se referă la cât de bine produsul corespunde din punct de vedere funcţional, al cerinţelor de performanţă şi al interpretării corecte a cerinţelor. Punctul principal al verificării şi validării este clientul adică dacă ceea ce i s-a furnizat corespunde cerinţelor sale.

Aşa cum s-a văzut din cele prezentate conducerea proiectului este activitatea care traversează întregul ciclu de viaţă. Conducătorul trebuie să fie atent în deciziile luate, trebuie să posede informaţiile corecte pentru luarea deciziilor şi să nu ia decizii compensatorii atunci când s-a greşit. Mai mult chiar, conducerea proiectului nu implică numai manipularea resurselor bani şi timp ci şi a resursei umane.

În procesele de decizie, chiar în stabilirea obiectivelor intervin puternic motivaţiile personale şi interpersonale. Complexul de atitudini, motivaţii, intentii, stări afective etc. constituie împreună "comportamentul uman" care trebuie avut în vedere de conducător în cele două accepţiuni ale sale: • factorul uman din interiorul echipei de proiectare; • comportamentul uman din sistemul studiat ca obiect

de analiza al echipei de proiectare.


pagina 186

V. Abordări orientate spre date şi prelucrări

Ralizarea unui sistem informaţional-decizional performant este rezultatul unui cumul de factori. Este cert că nu factorii individuali sunt cei cu influenţă hotărâtoare ci ansamblul interacţiunii lor. Acest ansamblu de factori trebuie analizat şi modelat în aşa fel încât să se obţină performanţa maximă. Dacă prin extensie spunem că modelarea efectuată pentru realizarea sistemului este ea însăşi un factor, putem afirma că într-adevăr acesta este unul important. Modelarea situaţiei existente sau a celei dorite trebuie să fie capabilă să reprezinte realitatea la un moment dat dar şi să se poată adapta la modificările pe care ea însăşi le preconizează.

Analizând modelele de reprezentare a realităţii propuse de metoda Merise, se observă două tipuri de reprezentare. • Prima este bazată pe postulatul că un sistem trebuie

să realizeze anumite funcţii (existenţa unui material în stoc, înlănţuirea etapelor pentru construcţia unei case, etc. ). Această abordare este cea a descompunerii funcţionale.

• A doua se preocupă de faptul că un sistem informatic este un sistem de relaţii între entităţi. Spre exemplu se descrie un individ ca un ansamblu compus dintr-un nume, unul sau mai multe prenume, un cod numeric personal şi având unul sau mai mulţi copii. În acelaşi sens o casă este un ansamblu de fundaţii, pereţi, uşi şi ferestre.


pagina 187

Sosirea buldozerului

Sosirea muncitori lor

Inceput activitate buldozer

Inceputul lucrului echipei

Anuntare proiectant

Sapatura terminata

Beton disponibil

Pregatirea echipeiPregatirea buldozeruluiverificarea prezenteirepartizarea sarcini lor

verificarea combustibiluluiverificarea prezentei soferincalzirea motorului

Saparea fundatii lorsapatura brutafinisaj sapatura

non OK OK

Turnarea betonului pregatire cofraj

pregatire armaturaturnare betonasteptare intarire

Terminare turnare fundati i

Figura 5.1. Exemplificare cu modelul conceptual al

datelor


pagina 188

Descompunerea funcţională îşi propune să abordeze sistemul ca un prestator de servicii care să răspundă la anumite întrebări. De exemplu “Câţi clienţi au fost vizitaţi de la începutul lunii?”. Furnizarea răspunsului presupune desfăşurarea unei serii de acţiuni: determinarea primei zi lucrătoare din lună, găsirea clienţilor vizitaţi de la acea dată şi până la zi şi afişarea rezultatului. Funcţia “găsirea clienţilor vizitaţi de la începutul lunii şi până la zi” se descompune ea însăşi în acces la fişierul de clienţi, selecţionarea numărului de clienţi vizitaţi începând de la acea dată, eliminarea clienţilor vizitaţi de două ori, etc.. Acest demers ar părea natural în măsura în care ar reproduce ceea ce face un salariat căruia i se pune această întrebare. Se poate distinge o dublă acţiune. • O împărţire temporală prin care sarcinile trebuiesc

îndeplinite unele după altele. În exemplul dat nu pot fi selectionaţi clienţii înainte de stabilirea primei zi lucrătoare din lună. Această dimensiune temporală pune în relief secvenţialitatea sarcinilor şi sincronizarea lor.

• Împărţirea procedurilor în subproceduri prin care sarcinile globale sunt împărţite în activităţi care pot fi din nou împărţite la rândul lor. Procesul se repetă până când sarcinile elementare sunt suficient de simple.

Descompunerea funcţională va fi exemplificată cu ajutorul modelului conceptual al prelucrărilor din metoda Merise. Indiferent de modaliatea practică de realizare a diagramei funcţionale particularitatea acestei abordări constă în urmărirea unei aplicaţii prin toate trasformările pe care le exercită asupra datelor. Este vorba de o structurare a prelucrărilor. Analiza prin descompunerea


pagina 189

funcţională permite să se găsesască sub-proceduri comune, putându-se atunci să se construiască o singură procedură care va fi utilizată de mai multe ori în mai multe locuri. Avantajul constă în faptul că a fost scrisă o singură dată iar eventualele modificări se vor face într-un singur loc aplicându-se tuturor funcţiilor la care procedura comună participă. Ca o alternativă la structurarea prelucrărilor s-a lansat spre sfârşitul anilor ’80 analiza structurilor de date. O problemă este reprezentată printr-un sistem de relaţii dintre elementele care-l compun. Abordarea se canalizează spre definirea elementelor de model şi spre stabilirea reţelei de relaţii care le leagă. Prezentarea acestui sistem de relaţii se face cu ajutorul diagramei entitate-relaţie. Entităţile reprezintă fiinţe sau obiecte purtătoare a anumitor proprietăţi iar relaţiile reprezintă interacţiunile dintre entităţi. O relaţie se poate exprima printr-o frază al cărui complement sunt entităţile iar verbul este relaţia dintre ele. Pentru exemplificare s-a folosit modelul conceptual al prelucrărilor din metoda Merise pentru aceiaşi problemă a construcţiei unei case.

Figura 5.2. introduce noţiunea de cardinalitate (un şofer face parte dintr-o echipă şi numai una iar într-o echipă pot fi zero sau mai mulţi şoferi) dar spre deosebire de structurarea prelucrărilor situaţia prezentată de diagrama entitate-relaţie este statică (se prezintă datele dar nu se precizează dacă ele sunt în mişcare sau în repaus). Diagrama entitate-relaţie explică ce sunt fundaţiile şi ce este necesar pentru a le construi dar nu explică maniera prin care se poate face. Tot pe lista minusurilor se poate adăuga, că unui singur model îi corespunde un număr infinit de realizări posibile exprimându-se un ansamblu de relaţii posibile fără a se impune un sens de lectură.


pagina 190

Figura 5.2. Exemplificare cu modelul conceptual al prelucrărilor

Pe de altă parte modelul este recunoscut ca durabil în măsura în care reprezintă realitatea fundamentală a domeniului de activitate modelat şi este extrem de adaptabil. Înlocuirea unui şef de echipă sau introducerea unei noi maşini ( entităţi) cu ajutorul căreia se vor săpa gropile nu schimbă major sistemul.

1,10,1

1,1

0,1

1,n1,n

0,n

0,n

0,n1,1

1,1

SoferEchipanume

0,1

Buldozernumar Groapa

locul in terenadancimeasuprafata

sef de echipanumar de membrii

Fundatiacoddata terminariisuprafata

Cofrajtipmaterialmarca beton

conduce

face parte

definit de

sapa

construita

cofrata


pagina 191

Abordările orientate spre date şi spre prelucrări îşi au rădăcina în două sisteme de gândire diferite: • Analiza prin prelucrări îşi găseşte sursa în noţiunea

de metodă în sensul în care aceasta îşi propune să rezolve o problemă printr-un cadru procedural. Acest cadru fixează etapele şi înlănţuirea lor astfel încât intrările şi ieşirile corespund fiecărei etape. Această gândire este esenţialmente carteziană şi analiza prin structura prelucrărilor este legată de acest curent de gândire.

• Analiza structurilor de date studiază problema modelării punându-se accentul pe relaţiile dintre elementele din model. Această abordare este cea inaugurată de şcoala sistemică. Software-ul este înainte de toate conceptualizat ca un component al sistemului de organizare global al întreprinderii. Conceperea sa începe prin analiza definirii sistemului şi a frontierelor sale.

Trebuie remarcat totuşi că însăşi metoda de dezvoltare, procesul sau metodologia, pune în evidenţă o abordare carteziană chiar dacă aceasta se referă preponderent la o modelare orientată spre structurarea datelor.

Ceea ce trebuie remarcat este faptul că aceste două concepte au stat la baza metodelor actuale de proiectare. Cu toate că metoda MERISE realizează prin modelele de date şi prelucrări o dublă abordare a sistemului, persistă totuşi unele inconveniente. • Fazele de studii sunt prea lungi şi neproductive.

Împărţirea lucrului ce decurge din abordarea prin sarcini specializate şi din ciclul de concepţie în V fac dificilă obţinerea de rezultate notabile. Această abordare impune o înţelegere globală a concepţiei


pagina 192

anterioare programarii. Adesea până când grupul de studii să termine caietul de sarcini necesităţile s-au schimbat iar în proiectele de o anumită dimensiune lungimea fazelor face foarte posibilă frecventa schimbare a analiştilor. Presiunea este foarte mare la începutul proiectului, atunci când deciziile cele mai importante trebuiesc luate plecându-se de la un minim de elemente. Deci, abordările tradiţionale sunt caracterizate printr-o dificultate ridicată o primelor etape când orice eroare poate avea consecinţe grave.

• Comunicarea este dificilă mai ales cu neinformaticienii. Implicarea utilizatorilor în proiect este adesea dificilă, principala dificultate constând în formularea cerinţelor într-un format propriu modelării. Comunicarea în sens invers nu este nici ea mai uşoară, pe de o parte din cauza necunoaşterii de către client a limbajului informatic dar mai ales datorită necunoaşterii suportului de comunicaţie. De la un anumit nivel de complexitate verificarea diagramelor entitate-relaţie şi de structurare a prelucrărilor de către un neinformatician devine imposibilă.

• Abordările orientate spre date şi funcţiuni sunt ireconciliabile. Analiza structurii datelor permite obţinerea de programe mai evoluate dar ea nu permite reprezentarea scopului aplicaţiei a ceea ce utilizatorul aştepta de la ea. Trebuie deci ca mai târziu să se descrie aceasta prin modelarea prelucrărilor. Din această cauză în marile proiecte era necesară o dublă abordare. O echipă trebuie să se ocupe de structurarea datelor şi alta de serviciile pe care sistemul urmează să le ofere utilizatorilor, adică de structurarea prelucrărilor. Problememle cu adevărat dificile apar la integrarea datelor cu prelucrările în procesul de realizare dar mai ales în


pagina 193

faza de mentenanţă când apare frecvent fenomenul de regresie. Acesta constă în faptul că modificarea prelucrărilor într-o zonă a aplicaţiei afectează datele utilizate de întreg sistemul. Se poate demonstra că această problemă decurge tocmai din contradicţia dintre date şi prelucrări.

• Abordarea prin prelucrări impune ca o funcţie

utilizată în mai multe locuri să nu existe decât într-un singur exemplar. În arborescenţa programului ea va fi ridicată către vârful arborescenţei pentru a putea fi utilizată de toate celelate funcţii care o apelează.

• Securitatea datelor impune ca accesul la ele să fie făcut de un număr minim de funcţii. Deci atunci când o dată este modificabilă de mai multe proceduri este imposibil de a găsi originea modificărilor. Există deci tendinţa de coborâre a funcţiei de acces pentru a evita modificările intempestive.

Aceste considerente au stat la baza naşteri unei noi abordări, numită orientatată obiect, care are la origine rezolvarea problemelor de simulare. Într-o astfel de abordarea nu mai este vorba de analiza funcţiilor sau de studierea relaţiilor dintre elemente ci mai curând de situarea în interiorul lor reproducând comportamentul la anumite evenimente. Din această abordare se naşte conceptul de obiect ca entitate ce reacţionează singură şi este independentă. Deşi metoda MERISE preia unele aspecte ale abordării obiectuale rămâne în sarcina viitoarelor cercetări integrarea reală a conceptului obiectual. Bibliografie.


pagina 194

(1) Gh. Boldur Lăţescu, Gh. Ciobanu, I. Băncilă - "Analiza sistemelor complexe"; Editura ştiintifică şi enciclopedică Bucureşti 1982 (2) I.Roşca, E.Macovei, N.Davidescu, V.Răileanu “Proiectarea sistemelor informatice financiar-contabile” Editura didactică şi pedagogică Bucureşti 1993 (3) Dumitru Oprean "Metode şi tehnici utilizate în realizarea sistemelor informatice" Editura Dacia 1980 (4) Mihai Păun, 1997, Analiza sistemelor economice,Ed.All (5) C. Georgescu - "Suport de curs - Proiectarea sistemelor informatice"; Facultatea de Ştiinte economice şi administrative; februarie 1995 (6) A. Benabdelhafid, E.Reppert - " Elements de conceeption D'un systeme de logistique integree"; Congres "Merise et les autres" 5-7 octobre 1994, Versailles (7) Robert N. Carette - "Software Engineering Environments - Concepts and technology" ; Intertexty Publications, Inc. McGraw-Hill,Inc. New york 1986 (8) Joseph Gabay "Apprendre et pratiquer MERISE" Paris, Editions MASSON 1993 (9) Joseph Gabay "MERISE - etudes des cas" Paris, Editions MASSON 1991

(10) Tawfik Jelassi - "Competing through information technology - Strategy and implementation"; Prentice Hall Publishing, November 1994.

(11) H. B. Maynard - "Manual de inginerie industriala"; Editura tehnica 1975 (12) Jean-Patrick Matheron "Comprendre MERISE" Paris, Editions EYROLLES , 1987, 1990

Sisteme In Format Ice de Gestiune

Documents

Transcript of Sisteme In Format Ice de Gestiune