Sunteți pe pagina 1din 192

Cristian Georgescu

SISTEME INFORMATICE DE GESTIUNE

Sisteme informatice de gestiune

pagina 4

Sisteme informatice de gestiune

CUPRINS 1.Abordarea sistemica 1.1.-Sistem; noiuni generale 1.2.-Conceptul de analiz sistemic 2.Sisteme informaionale 2.1.-Comunicarea n sistemele informaionale 2.2.-Fluxuri de informaii 2.3.-Locul i rolul sistemului informaional 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 ntreinerea 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 comunicaiilor 4.3.5. Modelul conceptual al prelucrrilor 4.3.6. Modelul organizaional al prelucrrilor 4.3.7. Modelul operaional al prelucrrilor 4.4. Ciclul de decizie 5.Abordri orientate spre date i spre prelucrri Bibliografie
pagina 5

Sisteme informatice de gestiune

1. ABORDAREA SISTEMIC 1.1. Sistem; noiuni generale

Conceptul de sistem apare n forme embrionare n filosofia antic greac. Afirmnd c "ntregul este mai mult dect suma pilor", Aristotel d o prim definiie noiunii 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 lucrri ce postuleaz c "universul este organizat n sisteme i ansambluri de elemente aflate n interaciune" 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 muli cercettori. Un sistem poate fi definit ca o seciune a realitii n care se identific un ansamblu de fenomene, obiecte, procese, fiine sau grupuri, interconectate printr-o mulime de relaii reciproce, precum i cu mediul nconjurtor i care acioneaz n comun n vederea realizrii unor obiective bine definite. Caracteristic pentru noiunea 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 funcie de scopul urmrit.
pagina 6

Sisteme informatice de gestiune

Mulimea relaiilor dintre componentele unui sistem precum i relaiile ntre componente i ansamblu formeaz structura sistemului, iar mulimea caracteristicilor unui sistem, la un moment dat, determin starea sa. Relaiile dintre elemente se analizeaz observnd i studiind logic funciile i mecanismele lor individuale. Dup precizarea acestor funcii i mecanisme, orice soluie avut n vedere poate fi evaluat pentru ntregul sistem, tinnd seama de diverse criterii de eficien i de restriciile practice asociate elementelor funcionale. Elementele unui sistem pot avea relaii ntre ele (relaii endogene) ct i relaii cu mediul nconjurtor (relaii exogene). Ca urmare, pentru a caracteriza noiunea de sistem este necesar s punem n eviden urmtoarele 5 laturi: mulimea elementelor relaiile ntre elemente -relaii endogene intrrile i ieirile n i din sistem-relaii exogene caracterul variabil n timp al elementelor sistemului scopul, finalitatea sistemului Pentru descrierea unui sistem i a evoluiei sale se asociaz "starea sistemului" care este un ir de variabile, un vector ale crui componente variabile n timp permit cunoaterea sistemului n orice moment. Folosind vectorul de stare al sistemului, i vectorii de intrare, ieire, comand etc. se poate asocia sistemului un sistem de ecuaii 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, fcnd abstracie de procesele sale interne.
pagina 7

Sisteme informatice de gestiune

Cutia neagr primete impulsuri din mediul nconjurtor (intrrile) i le transform n aciuni asupra mediului (ieirile). Mecanismul transformrii intrrilor n ieiri poate fi descris cu ajutorul unor funcii care au diverse forme particulare, n funcie de natura sistemului. Sistemul devine "cibernetic" atunci cnd apare reglarea (conexiunea invers sau feedback-ul). n 1948 matematicianul american Norbert Wiener prin publicarea lucrrii sale fundamentale "Cybernetics", pune bazele acestei tiinte a controlului i comunicrii.

Figura 1.1. Sistem cibernetic Fie sistemul S definit prin vectorul intrrilor X i prin vectorul ieirilor Y; transformarea intrrilor n ieiri se poate descrie n mod simplificat prin aplicarea operatorului liniar F. Y=FX Mrimile Y ale ieirilor se compar cu vectorul obiectivelor propuse Z i ntruct de cele mai multe ori apar abateri (Y#Z) este necesar intervenia unui
pagina 8

Sisteme informatice de gestiune

"regulator" R care va genera mrimea de reglare x, cu rolul de a aduce ieirile 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 conductor". Traducnd n termenii prezentai anterior, subsistemul condus este sistemul S iar subsistemul conductor este regulatorul R. Dat fiind proprietatea sistemelor de a putea fi mprite n subsisteme care la rndul lor se pot diviza n alte subsisteme s.a.m.d., n continuare se va folosi noiunea de subsistem numai n cazurile cnd este necesar punerea n eviden a relaiei de incluziune ntr-un alt sistem. Din punct de vedere al modului cum se analizeaz ieirile (reaciile) sistemului condus i al modului cum se genereaz mrimile de reglare (deciziile) sistemele pot fi: Sistem deschis necontrolat.

Figura 1.2. Sistem deschis necontrolat.


pagina 9

Sisteme informatice de gestiune

n acest tip de sistem sistemul conductor emite o decizie D far a cunoate reacia sistemului condus la aceast decizie. Sistem nchis controlat.

Figura 1.3. Sistem nchis controlat n acest caz n urma deciziei D a sistemului conductor, sistemul condus furnizeaz informaia I ca o reacie la decizia D. Sistem controlat autoreglabil univariant.

Figura 1.4. Sistem controlat autoreglabil univariant.


pagina 10

Sisteme informatice de gestiune

Sistemul controlat apare atunci cnd ntre forma primar a deciziei D preconizat de sistemul conductor i forma realizat de sistemul condus nu este o concordan perfect. n acest caz conductorul lund n considerare diferenele ntre ce s-a preconizat i ce s-a realizat intervine cu noi decizii pentru a determina sistemului condus s se conformeze deciziei iniiale D. Sistem controlat autoreglabil bivariant.

Figura 1.5. Sistem controlat autoreglabil bivariant Dac n urma unor perturbaii conductorul reevalueaz decizia sa primar poate s preconizeze o form modificat a obiectivului iniial. Sistemul este bivariant pentru c pe parcursul realizrii deciziei att forma iniial ct i cea final s-au modificat.

pagina 11

Sisteme informatice de gestiune

1.2. Conceptul de analiza sistemic inndu-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 uor de stpnit, toate componentele sunt considerate n ansamblul lor ("aspect spaial") att pe parcursul analizei, proiectrii ct i al procesului de conducere ("aspect temporal"). De fapt, numai n acest fel este posibil s se neleag i s se anticipeze corect comportarea posibil a sistemului. O caracteristic esenial a abordrii sistemice este accentul pe care l pune, n cazul analizei, pe interdependenele dintre elementele sistemului i pe observarea critic a calitii acestora. Abordarea sistemic, s-a dovedit de mare utilitate n rezolvarea problemelor mari i complexe, referitoare la oameni i maini. Abordarea sistemica este o noiune care reunete trei activiti importante: analiza sistemelor proiectarea (ingineria) sistemelor conducerea sistemelor. Analiza de sistem poate fi considerat un mijloc de abordare a cercetrii, sau chiar disciplin n sine, deoarece acest concept a nceput s fie folosit pe scar larg n mai toate domeniile.
pagina 12

Sisteme informatice de gestiune

Analiza sistemelor presupune parcurgerea urmtoarelor etape: 1.Prima etap const n formularea problemei. Pentru toate lucrrile ulterioare este important ca analistul s examineze critic formularea problemei de ctre 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 incompatibiliti de limbaj. Orice eroare minor n formularea problemei sau orice nelegere eronat poate genera mari inconveniente prin amplificarea ei cu fiecare etap parcurs. 2.De asemenea este deosebit de important s se examineze minuios formularea obiectivelor pentru c n acest domeniu sunt posibile inconsecvente: "s se maximizeze eficiena concomitent cu ncadrarea n cheltuielile minime". 3.Adeseori n optimizarea sistemelor apar dificulti cauzate de faptul c este greu sau chiar imposibil s se analizeze ntreaga problem. Se poate recurge n astfel de situaii la optimizarea fiecrui subsistem analizat, dar sistemul n ntregul su nu poate fi dect suboptimal fiind necesar deci precizarea clar a limitelor problemei. 4.Analiza cerinelor utilizatorului const identificarea i evaluarea necesitilor lui reale. n

5.Precizarea criteriilor de msurare a eficienei sistemului trebuie fcut nainte de evaluarea soluiilor propuse prin stabilirea unui grup de mrimi reprezentative.
pagina 13

Sisteme informatice de gestiune

6.Analiza funcional se concretizeaz ntr-o list amnunit a funciunilor i aprecierilor care trebuie ndeplinite. La analizele funcionale o deosebit importan o are reprezentarea grafic n scheme bloc. 7.Pe masur ce se completeaz lista restriciilor care acioneaz asupra sistemului devine posibil cercetarea efectelor interaciuni lor asupra ntregului sistem. Identificarea restriciilor i evaluarea efectului lor asupra eficienei sistemului reprezint un alt aspect important. 8.Pe msura avansrii n analiza sistemului se contureaz diferitele soluii posibile care satisfac restriciile impuse. Obiectivul acestei faze este de a identifica diversele variante fr a adncii analizele privind cheltuielile pe care le implic. ntr-un sistem informatic, de exemplu, este necesar s se determine gradul n care hardwareul i software-ul avute n vedere ofer posibiliti de dezvoltare ulterioar. 9.Dup precizarea variantelor posibile se trece la compararea i evaluarea acestora. Este de dorit ca att cheltuielile ct i eficiena s fie exprimate banete. Proiectarea sistemelor este un proces de concepie tehnic, asociat de obicei cu dezvoltarea sau cu modificarea important a unui sistem. Acest proces se mparte n: proiectarea propriuzis a sistemelor i proiectarea operrii sistemelor
pagina 14

Sisteme informatice de gestiune

Proiectarea propriuzis a sistemelor se mparte la rndul ei n: proiectarea preliminar proiectarea de detaliu La proiectarea preliminar se evalueaz soluiile de proiectare a transpunerii specificaiilor funcionale precizate n faza de analiz a sistemului i apoi se selecteaz soluia de proiectare. Proiectarea de detaliu cuprinde transpunerea concepiei de proiectare, conturat n faza de proiectare preliminar n specificaii de detaliu. Este necesar n aceast faz mprirea lucrrilor pe echipe dar totodat trebuie s existe un grup de integrare a sistemului care s se ocupe exclusiv de problema asigurrii funcionalitii corespunztoare a fiecrui subsitem nu numai n parte ci i n cadrul sistemului n ansamblu. Un aspect oarecum neglijat n tehnica sistemelor este proiectarea operrii 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 eecul unui sistem tot att de mult ca i proiectarea lui defectuoas. Operarea sistemelor este uneori neglijat din cauz c proiectanii sunt n mod firesc mai interesai s soluioneze problemele tehnice ale proiectrii i n mai mic masur problemele legate de limitele fizice i psihice ale personalului operaional i de ntreinere. n plus concepia de a adapta omul la main a creat obiceiul de a angaja pentru operare i ntreinere acei oameni ale cror nsusiri fizice i psihice pot fi considerate compatibile cu caracteristicile echipamentului. Pe msura sporirii complexitii sistemelor, trebuie
pagina 15

Sisteme informatice de gestiune

acordat o atenie deosebit noiunilor de fiabilitate i mentenabilitate. Conducerea sistemelor cuprinde stabilirea metodologiei i a structurilor organizatorice pentru planificarea, directivarea i controlul activitilor de proiectare a sistemelor ca i pentru funcionarea lor. Conducerea funcionarii sistemelor se numete "conducere operaional". Pe de alt parte exist conducerea nsi a proiectrii sau dezvoltrii sistemului. Conducerea sistemelor nu reprezint o faz a proiectrii sistemelor ci este funciunea de comand i control care se desfoar de-a lungul ciclului de via al sistemului. Cea mai mare contribuie la eficiena conducerii unui sistem o are identificarea momentelor i criteriilor de efectuare a controlului, astfel nct s se poat stpnii desfurarea activitilor. Pe lng controlul corespunztor principalelor etape conducerea trebuie s efectueze o permanent urmrire i coordonare. Acest sistem de control poate fi mai eficient dac: se realizeaz previziuni asupra evoluiilor viitoare; se planific reexaminri periodice ale proiectelor. Integrarea sistemului i controlul configuraiei sunt dou activiti de conducere care trebuie s-i dovedeasc prezena pe parcursul fiecrei faze a proiectrii sistemelor. Pentru integrarea sistemului conducerea trebuie s asigure compatibilitatea mecanic, electric, etc. dar i compatibilitatea informaional. Controlul configuraiei const din metodele folosite pentru a orienta i urmrii modificrile n diversele etape ale ciclului de via al sistemului.
pagina 16

Sisteme informatice de gestiune

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 cunoaterea sistemului, cunoatere care se traduce printr-o reprezentare la nivel cerebral a sistemului n ansamblul su. De fapt prin analiza s-a transpus realitatea mai nti 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 realitii nu este deloc uoara i presupune n mod obligatoriu participarea activ a beneficiarului sistemului.

pagina 17

Sisteme informatice de gestiune

2. SISTEME INFORMAIONALE 2.1. Comunicarea n sistemele informaionale Noiunea de informaie este complex i de mare generailitate. La momentul apariiei sale, conceptul de informaie a suscitat dispute filosofice pe tema caracterului material al acesteia. Norbert Winer spunea: " Informaia este informaie, nu este materie sau energie." Informaia este un tip deosebit de raport ntre procesele materiale, raport ce nu exist n afara acestor procese. Se poate afirma c informaia reprezint un atribut fundamental al materiei alturi de mas, cmp i substan. Informaia ca atribut fundamental al materiei este prezent att n materia vie (informaia genetic) ct i n cea nevie . Pentru determinarea riguroas a cantitii de informaie se folosete un aparat matematic bazat pe elemente din teoria probabilitilor. Fie un experiment X rezultatele sale pun n eviden un numr finit de evenimente elementare independente x1,x2,..,xn, avnd asociate probabilitile de realizare p1,p2,...,pn. Presupunem c experimentul X reprezint un sistem complet de evenimente, adic prin efectuarea sa se va obine cu siguran unul din evenimentele xk X , deci pk = 1 ; k=1,..,n. Realizarea unui eveniment nltur o cantitate de nedeterminare, deci ntruct informaia reprezint o nedeterminare nlturat sensul variaiei nedeterminrii este inversul
pagina 18

Sisteme informatice de gestiune

sensului variaiei informaiei, unitatea de msur fiind aceiai. Notnd cu H(X) msura gradului de nedeterminare, care este egal cu cantitatea medie de informaie furnizat de realizarea unui eveniment se poate scrie: H(X) = H(p1,p2,...,pn) n anul 1948 Claude Shannon n lucrarea "Teoria matematica a comunicaiei" a dat expresia cantitii de nedeterminare (i deci a informaiei):

Shannon a preluat cercetrile unui precursor al su n domeniul teoriei informaiei R.V.Hartley care nc din anul 1928 a introdus noiunea de cantitate de informaie, definind-o astfel:"Informaia obinut 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. Relaia stabilit de Hartley se obine ca un caz particular din formula lui Shannon atunci cnd evenimentele sunt echiprobabile; p1 = p2 =....= pn = p= 1/n Msura informaiei calculat cu formula lui Shannon se
pagina 19

Sisteme informatice de gestiune

numete i ENTROPIE INFORMAIONAL prin analogie cu entropia termodinamic, care masoar de asemenea gradul de nedeterminare al unui fenomen. Transferul informaiilor, deciziilor, datelor i cerinelor ntre diferite procese i/sau ntre diferite sisteme sau subsisteme creeaz o problematic complementar cantitii de informaie: problema COMUNICARII. Fie:

Figura 2.1. Modelul comunicrii unde: E - este emitorul de informaie R - este receptorul de informaie C - este canalul de comunicaie Caracterul esenial 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 spaiu i timp ale suportului su, sau ale canalului de transfer (lungimea cuvntului, suprafaa unui disc, a unui tablou, numrul de semne imprimate), dar mai ales de improbabilitatea ocurenei (apariiei) sale, adic de combinaia pe care o realizeaz. Aceast cantitate de noutate sau originalitate transportat de la E la R se adaug la sistemul de cunotine i de
pagina 20

Sisteme informatice de gestiune

experien pe care l au att E ct 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 funcie de frecvena de ntrebuinare; n pasul urmtor vom deduce probabilitatea lor de apariie (de ocuren) i, n consecin, informaia pe care ele o transport. Informaia depinde deci de repertoriul comun att al transmitorului ct i al receptorului. Aceast masur presupune faptul c mesajul este decompozabil n mod obiectiv ntr-o serie de semne identificabile i enunabile. Procesul fundamental al comunicrii ntre emitor i receptor prin intermediul unui canal fizic nseamn: a gsi semne care pot fi recunoscute ntr-un repertoriu prin intermediul unui canal fizic; a gsi semne care pot fi recunoscute ntr-un repertoriu deinut de emitor; a le aduce i ale transmite prin ceea ce numim un canal de comunicaie; identificarea de ctre receptor a fiecrui semn pe care l primete cu cele pe care le are deja n propriul su repertoriu.

Comunicarea ideilor nu are loc dect n msur n care cele dou repertorii au o parte comun. Pe msur ce acest proces continu n procesele dotate cu memorie i cu estimare statistic, cum este cazul inteligenei umane, percepia semnelor mereu identice vine s modifice din ce n ce mai mult n repertoriul receptorului, cruia i este subordonat. Este vorba de sistemul de nvare.
pagina 21

Sisteme informatice de gestiune

n comunicare emitorul creeaz o form, o imagine, o idee, pe care o codific apoi n momentul emisiei. La rndul su, receptorul, plecnd de la mesaj construiete o alt form. Calitatea comunicrii se msoar prin indentitatea dintre forma perceput i forma creat. Leibnitz a artat c orice mesaj poate fi considerat o alegere ntre o mulime de cazuri posibile, alegere care se poate transforma ntr-un numr suficient de mare de dileme succesive. Fiecare dintre aceste alternative, fiecare din aceste alegeri ntre dou posibiliti care se exclud (da-nu; 0-1), dac ele sunt egal probabile pentru receptor, reprezint o unitate de informaie sau BIT (binary digit: cifr binar sau problem binar). Avem astfel o unitate de msur a informaiei ncepnd cu numrul de dileme susceptibile a defini mesajul far ambiguitate. Receptorul uman nu este capabil s sesizeze dect o cantitate limitat de originalitate pe unitatea de timp, adic un anume debit de informaie, funcie de canalul de percepie (vz auz, pipit, telepatie, etc.) Caracterul optim al mesajelor nu este dat de maximul de informie ci de maximul de impact adic de probabilitatea de a nelege, deci de a proiecta forme asupra mesajului primit. E necesar aici un exces, o risip de semne, i apare o alt mrime numeric, legat de mesaj, care joac un rol important n comunicaie: REDUNDANA. Ea nseamna excesul relativ al numrului de semne fa de cel care ar fi fost strict necesar pentru a transmite aceiai cantitate de originalitate.

pagina 22

Sisteme informatice de gestiune

Figura 2.2. Alegerea optimului de redundan Orice mesaj poate fi caracterizat prin coninutul su de informaie i poate s se situeze ntr-un punct definit al unei scri care merge de la banalitatea total pn la originalitatea total. Redundana variaz deci n raport invers proporional cu informaia. Inteligibilitatea unui mesaj este legat de redundana 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 funcie de caracteristicile receptorului. Fie:
pagina 23

Sisteme informatice de gestiune

Figura 2.3. Comunicarea n prezena perturbaiei unde: E - este emitorul de informaie R - este receptorul de informaie C - este canalul de comunicaie P - este perturbaia

Modelul matematic al unui sistem de transmitere a informaiei este format din dou mulimi finite X, Y i o probabilitate condiionat p(y|x), definit pe Y pentru orice x X. X este mulimea simbolurilor care se emit iar Y mulimea simbolurilor ce se recepioneaz. Probabilitatea p(y|x) se numete probabilitatea de recepie condiionat de ceea ce se emite i caracterizez perturbaia existent pe canalul sistemnului respectiv. A cunoate canalul de comunicaie nseamn a cunoate probabilitile p(y|x) pentru toate simbolurile x X i y Y. Mrimea H(X|Y) reprezint cantitatea medie de informaie necesar pentru a se recepiona mulimea Y i depinde de probabilitatea condiionat p(x|y), care la rndul ei, este determinat de probabilitatea p(y|x) ce caracterizeaz perturbaia pe canal. Nedeterminarea H(X|Y) apare datorit perturbaiei; ea este preul pe care trebuie s-l pltim
pagina 24

Sisteme informatice de gestiune

perturbaiei pentru ca s putem recepiona semnalele y Y. Dac H(X|Y) reprezint cantitatea medie de informaie care se pierde pe canal i dac de la sursa se transmite o cantitate de informatie H(X), la recepie va ajunge numai cantitatea de informatie Q=H(X) - H(X|Y) Mrimea denumit CAPACITATEA CANALULUI este dat de relaia: C = MAX (H(X) - H(X|Y)) si ea pune n eviden cantitatea de informaie care poate s circule n mod util prin canalul dat. Diferena H(X) - H(X|Y) raportat la uinitatea de timp se mai numete vitez de transmitere a informaiei. Capacitatea canalului este deci viteza maxim de transmitere a informaie pe canalul respectiv.

pagina 25

Sisteme informatice de gestiune

2.2. Fluxuri de informaii Fie graful G0(X,L) unde: X este mulimea elementelor i L este legea de coresponden (mulimea 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. Mulimea punctelor { x1,x2,...,xl } din mulimea X desemneaz un DRUM de lungime L dac perechile { xi,xi+1 } sunt laturi; Distana ntre dou puncte ale unui graf este egal cu lungimea cii celei mai scurte dintre ele. Pe acest graf G0(X,L) se definete un alt graf numit GRAF INFORMAIONAL G1(X,C). ntre cele dou grafuri exist o deosebire: legea de coresponden. n timp ce G0 reglementeaz relaiile organizatorice G1 reglementez relaiile informaionale. Laturile grafului G1 se numesc CANALE INFORMAIONALE. n mulimea {C} a canalelor informaionale se pot defini dou submulimi: C1={c C|c=canal pur informaional} C2={c C|c=canal decizional} Pe mulimea {C} putem defini mulimea {F} a fluxurilor. Fluxul este acea cantitate de informaie care circul pe un canal. El poate fi: informaional decizional DRUM INFORMAIONAL este succesiunea de arce adiacente ce permit trecerea fluxului informaional de la un nod la altul.
pagina 26

Sisteme informatice de gestiune

LUNGIMEA UNUI DRUM INFORMAIONAL este dat de numrul de arce din care este format. Drumul poat fi: deschis (numai informaional) nchis (informaional - decizional)

Tipuri de fluxuri informaionale. Fie un flux F(A,B) unde A i B sunt noduri iar fluxul F circul pe canalul AB: cnd informaia circul de la un nivel organizatoric A inferior la un nivel superior B, fluxul se numete ascendent. cnd informaia circul de la A la B i ele sunt pe acelai nivel organizatoric, fluxul se numete orizontal. cnd informaia circul de la A situat la un nivel organizatoric superior la B aflat pe un nivel organizatoric inferior, fluxul se numete descendent. cnd A i B aparin aceluiai sistem S, fluxul F(A,B) se numete intern. cnd A sau B nu aparin sistemului S fluxul se numete extern. cnd coninutul, direcia i periodicitatea fluxului sunt prestabilite, fluxul se numete periodic. cnd nici coninutul nici periodicitatea nu sunt reglementate, fluxul se numete de moment sau ntmpltor.

pagina 27

Sisteme informatice de gestiune

2.3. Locul i rolul sistemului informaional Circulaia informaiei din momentul producerii unui eveniment n procesul condus i pn cnd pe baza cunoaterii lui, se declaneaz un nou eveniment precum i precizarea coninutului informaiei, destinaiei, locului stocrii, etc. alctuiesc sistemul informaional. Totalitatea metodelor, tehnicilor, mijloacelor, privite ca ansamblu integrat care asigur nregistrarea, culegerea, transmiterea, prelucrarea i valorificarea informaiilor de orice natur definesc sistemul informaional. Un sistem informaional se creaz i se dezvolt odat cu organismul sau activitatea pe care o reflect. ntr-un sistem economic sistemul informaional asigur legtura n ambele sensuri ntre sistemul condus sau de execuie i sistemul conductor sau decizional (Figura 2.4.). Orice sistem economic presupune existena unei componente operaionale care poate fi orice sistem de producie de bunuri sau servicii. Sistemul condus asigur desfurarea activitilor specifice sistemului n vederea realizrii obiectivului global pentru care a fost creat. Sistemul condus se compune din ansamblul actorilor operaionali din ntreprindere i care: utilizeaz informaiile prezente n sistemul informaional; utilizeaz regulile de comportament din sistemul informaional.

pagina 28

Sisteme informatice de gestiune

Figura 2.4. Locul sistemului infirmaional Spre exemplu un vnztor dintr-o societate care se ocup cu vnzri prin coresponden, primete o comand telefonic de la un client nou. Sistemul informaional este acela care: i furnizeaz informaia c este vorba de un client nou; i furnizeaz regula de aciune care se traduce prin aplicarea unui comision de 10% asupra vnzrilor. Astfel sistemul operaional adaug o nou informaie n sistemul informaional (numele clientului, adresa clientului, etc). Sistemul conductor asigur previziunea comanda, organizarea, coordonarea i controlul desfurrii activitilor n vederea ndeplinirii obiectivelor sistemului.
pagina 29

Sisteme informatice de gestiune

El este compus din ansamblul actorilor care fixeaz i adapteaz obiectivele i strategia ntreprinderii utiliznd informaiile prezente n sistemul informaional. Sistemul conductor intervine asupra sistemul informaional n sensul adaptrii la obiectivele i la strategia ntreprinderii, modificnd natura informaiilor i regulile de comportament. Spre exemplu conducerea unei bnci decide ca clienii si s nu mai fie considerai ca persoane ci ca gospodrii (familii) ceea ce duce la schimbarea naturii informaiei. O societate decide s schimbe modul de facturare prin editarea facturii pe calculator n momentul prezentrii clientului. Rezult de aici o aciune asupra regulilor de comportament, facturarea actualiznd stocul fr a mai fi nevoie de o procedur ulterioar. Prin situarea sa ntre sistemul conductor i sistemul operaional sistemului informaional asigur urmtoarele funciuni: culegerea datelor care consemneaz realitatea economic din cadrul proceselor operaionale. preluarea informaiilor de la alte sisteme i mpreun cu cele din sistemul operaional s asigure prelucrarea, valorificarea i arhivarea lor. obinerea i transmiterea ctre conducerea proprie i ctre organele supraordonate a informaiilor necesare fundamentrii deciziilor sau a urmririi efectelor acestora. transmiterea de informaii de rutina altor procese informaionale. preluarea i transmiterea fr modificri a deciziilor care provin de la organele supraordonate ctre procesul decizional propriu.

pagina 30

Sisteme informatice de gestiune

Figura 2.5. Sistemul informaional Avnd n vedere caracterul dinamic al sistemului economic, n mod obiectiv i sistemul informaional trebuie s fie ntr-o continu adaptare i perfecionare. Elemente ale sistemului economic pot reprezenta perturbaii pentru sistemul informaional dar acesta fiind un sistem cibernetic exist posibilitatea adaptrii i funcionrii celor dou sisteme n concordan. n sistemul informaional privit ca sistem cibernetic conexiunea invers o constituie : deciziile pentru meninerea echilibrului sistemului economic n ansamblu; deciziile luate de conducerea subsistemului informaional pentru buna funcionare i perfecionare a acestuia. Reacia invers se concretizeaz prin informaia economic necesar conducerii sistemului economic att pentru fundamentarea deciziilor ct i pentru urmrirea efectelor acestora.
pagina 31

Sisteme informatice de gestiune

Sistemul informaional are caracter cibernetic i datorit faptului c are capacitatea de autoreglare astfel nct el este ntotdeauna n concordan cu sistemul economic pe care l reflecta.

Figura 2.6. Sistemul informaional; sistem cibernetic Funciile de previziune, organizare, coordonare i control, atribute ale sistemului conductor, devin n societatea modern din ce n ce mai complicate. Din aceast cauz n procesul de conducere apare
pagina 32

Sisteme informatice de gestiune

necesitatea unor metode care s permit stpnirea fluxurilor informaionale din i spre sistemul condus, i care s permit conducerii sesizarea problemelor ce pot s apar n viitor. ntreprinderea este pus n situaia de a prelucra toate aceste fluxuri informaionale i de a-i alege propria cale din mult mai multe variante pe care le are la dispoziie. Aceste posibiliti complexe de aciune se traduc printr-un nivel mai mare al fluxurilor informaionale care intr i ies din ntreprindere, fluxuri care trebuie analizate i controlate de conducerea ntreprinderii. Deciziile elaborate trebuie s stea la baza conturrii mai multor variante de evoluie care s cuprind simultan criterii de timp, bneti i de performan. Apare n acest caz o situaie potenial de risc, generat mai ales de imposibilitatea de a controla noul val de complexitate.

pagina 33

Sisteme informatice de gestiune

3. SISTEME INFORMATICE 3.1. Definire Din definiia sistemului informaional reiese c obiectivul global urmrit este tratarea i valorificarea informaiei 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. Dei la nceput calculatorele electronice erau folosite n exclusivitate pentru calcule tehnico-tiintifice, ncepnd 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 aprut odat cu utilizarea calculatoarelor electronice n realizarea proceselor informaionale. Pentru definirea sistemului informatic prezentm un set de trei definiii unanim acceptate, dar care pun accentul pe una sau alta dintre trsturi, completnduse reciproc. Atunci cnd n sistemul informaional predomin utilizarea calculatoarelor electronice, se spune c el este un sistem informatic.
pagina 34

Sisteme informatice de gestiune

Un sistem informatic poate fi definit ca un ansamblu tehnico-organizatoric de automatizare a culegerii i prelucrrii informaiilor destinate desfurrii procesului de conducere, n scopul asigurrii unei eficiene ct mai mari a activitii economico-sociale respective. Partea component a sistemului informaional prin care se asigur, pe baza folosirii tehnicii de calcul i n primul rnd a calculatoarelor electronice, tratarea raional a datelor i a informaiei, cu eficien sporit, constituie un sistem informatic.

n timp ce prima definiie pune accentul pe aspectul tehnic, adic pe utilizarea calculatoarelor, cea de-a doua vizeaz aspectul de organizare i raionalizare a circuitului informaiilor destinate conducerii. Ultima definiie este cea care reunete cele dou aspecte subliniate de primele definiii adugnd i relaia de incluziune a sistemului informatic n sistemul informaional. Sistemul informatic se asociaz obligatoriu unui sistem informaional i este subordonat unui proces decizional. Prin tratarea datelor cu tehnica de calcul sunt eliminate erorile de informare care se repercuteaz negativ asupra calitii desfurrii activitilor. Sistemul informatic, ca parte a sistemului informaional, trebuie structurat ca sistem cibernetic cu dou bucle de reglaj. Bucla principal de reglaj reflect principalele influene cu mediul nconjurtor: legturile cu bncile, cu beneficiarii, etc. Bucla secundar este ca o bucl de autoreglaj care face fa n principal
pagina 35

Sisteme informatice de gestiune

perturbaiilor 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 condiiile unei orientri a activitii spre pia, strategia ntreprinderii poate suferi modificri substaniale, n funcie de situaiile conjuncturale aprute. Dac, n urma unor perturbaii de acest fel, conductorul reevalueaz decizia sa primar (planul iniial), poate s preconizeze o form modificat a obiectivului iniial. n acest caz, cnd pe parcursul realizrii deciziei, att forma iniial ct i cea final sau modificat, putem vorbi despre sistemul informatic ca despre un sistem bivariant. Sistemul informatic este format, n esen, din urmtoarele categorii de elemente: 1. 2. 3. 4. 5. calculatoare electronice i alte echipamente metode i tehnici de tratare a datelor i a informaiei colecii organizate de date proceduri i programe de tratare a datelor 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, att la nivelul elaborrii programelor de activitate, ct i pe parcursul executrii lor. Un sistem informatic este conceput prin colaborarea dintre specialiti din domenii conexe iar realizarea unui sistem informatic este un proces complex, de durat i care necesit activiti specifice de analiz, proiectare, programare i implementare.
pagina 36

Sisteme informatice de gestiune

Sistemul informaional trebuie s devin, prin introducerea sistemului informatic, instrument de reglare i autoreglare a sistemului economic. Obiectivul global urmrit este creterea fiabilitii sistemului economic studiat. Din activitatea practic de realizare a sistemelor informatice se desprind urmtoarele 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 documentaiilor orientate ctre beneficiar ntr-un limbaj accesibil acestuia; aprobarea de ctre beneficiar a tuturor propunerilor fcute n proiect; responsabilitatea viitorului utilizator pentru implementarea sistemului, pentru corectitudinea datelor folosite i pentru pregtirea personalului necesar exploatrii sistemului; 2. Problema cheie este cea a oamenilor nu a echipamentelor, i n special a analitilor-proiectani de sisteme, specialiti care au o influen hotrtoare asupra modului de realizare a sistemelor. 3. Sistemele informatice trebuiesc justificate din punct de vedere cantitativ i calitativ, deoarece reprezint investiii importante. 4. Realizarea sistemului informatic este un proces iterativ, ceea ce nseamn c nti trebuie stabilit numai cadrul general, detalierea fcndu-se apoi treptat, n mai multe iteraii. 5. Cnd nu putem s planificm ceva nu putem s facem corect acel lucru, principiu valabil nu numai n informatic. n virtutea acestui principiu trebuie
pagina 37

Sisteme informatice de gestiune

permanent urmrite i reactualizate planificrile iniiale pe msura realizrii sistemului. De asemenea, trebuie acordat o deosebit atenie modului de etapizare a lucrrilor i mrimii etapelor pe care vrem s le realizm. 6. Procedurile manuale sunt la fel de importante ca i programele, de corecta lor proiectare depinznd durata de implementare i modul de funcionare a sistemului. 7. Trecerea de la vechiul sistem la noul sistem este ea nsi un sistem i de aceea trebuie tratat cu mare atenie. 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 documentaie n toate etapele de realizare.

pagina 38

Sisteme informatice de gestiune

3.2. Ciclul de via al unui sistem infomatic Din cele prezentate anterior se constat c restructurarea unui sistem informaional este un proces complex. Analistul de sistem trebuie s parcurg o serie de etape i s rezolve o mulime de probleme. Analiza de sistem nseamn cunoaterea sistemului, cunoatere care se traduce printr-o reprezentare la nivel cerebral a sistemului n ansamblul su. De fapt prin analiz s-a transpus realitatea mai nti 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 realitii nu este de loc uoar i presupune participarea activ a tuturor membrilor echipei de proiectare dar i a beneficiarului sistemului ntr-un context uman, material i organizatoric, propice realizrii 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 aplicrii metodelor. Cnd vorbim despre procesul de reorganizare a unui sistem informaional, trebuie s descriem un model care s prevad ceea ce va aprea n procesul de dezvoltare. Aceast etapizare va arta ce trebuie fcut, cum va fi realizat, cnd va fi terminat i cine va folosi ceea ce s-a realizat. Un bun model al procesului de prelucrare trebuie s respecte trei cerine principale. Trebuie s aib o mare putere descriptiv, putnd s descrie esenialul n mod realist.
pagina 39

Sisteme informatice de gestiune

Trebuie s permit descrierea nsui a procesului de dezvoltare i a modului de conducere a dezvoltrii procesului. Trebuie de asemenea s acopere cazurile neprevzute i schimbrile 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 numr 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 constnd n parcurgerea unor etape numite "faze". (Figura 4.1.) 1. Analiza cerinelor. Definirea i analiza necesitilor utilizatorului. 2. Specificaia. Translaia cerinelor ntr-o descriere general a sistemului. 3. Proiectarea. Crearea unei abstractizri a sistemului n concordan cu specificaiile anterioare. 4. Implementarea. Crearea sistemului care implementeaz ceea ce s-a proiectat. 5. Testarea. Determin dac implementarea satisface cerinele. 6. Mentenana. Modificarea sistemului necesar pentru a fixa problemele aprute. Ciclul de via se repet n cadrul acestei faze.
pagina 40

Sisteme informatice de gestiune

Figura 3.1. Modelul Waterfall Se constat c fiecare faz constituie o trecere de la un nivel de abstractizare ridicat (puine detalii) la un nivel mai sczut de abstractizare (mai multe detalii). Cu toate c exist o bogat experien i tradiie n aplicarea cu succes a modelului, exist unele probleme. n primul rnd modelul nu este suficient de descriptiv n ceea ce privete activitile care interfer prin toate fazele ciclului de via cum ar fi: conducerea proiectului, asigurarea calitii, verificarea i validarea. Spre exemplu o eroare de specificare poate s nu fie descoperit dect
pagina 41

Sisteme informatice de gestiune

foarte trziu, i este extrem de greu de revenit la faza la care s-a produs eroarea. n al doilea rnd modelul a fost dezvoltat ntr-o perioad cnd sistemele de mici dimensiuni i cu arhitectur compact erau dominante. n ultimul rnd modelul nu se preteaz la transpunerea sa pe calculator. El a fost dezvoltat ntr-o perioad cnd proiectarea asistat de calculator nu era deloc neleas. Modelul INCREMENTAL (RAPID-PROTOTYPING). Acest model (al prototipizrii rapide) a fost creat pentru a acoperi deficienele modelului WATERFALL cu care se aseamn din mai multe puncte de vedere. Diferena 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 conine un plus de funciuni. Produsul final nu este vzut ca un sistem monolit livrabil integral la o singur dat, ci este realizat i livrat dintr-o serie de etape succesive corespunztoare fiecrei iteraii. Numai la sfrit sistemul este disponibil integral, dar pn atunci fiecare increment poate lucra ca un sistem de sine stttor. (Figura 4.2.) Modelul incremental elimin necesitatea furnizrii cerinelor, specificaiilor generale i a celor detaliate naintea nceperii etapei de proiectare. Aceste specificaii numite "builds" (baselined intermediate software products) sunt n mod formal specificate la nceputul fiecrui increment. Acest lucru permite posibilitatea schimbrii cerinelor prin adugarea lor n pasul urmtor.
pagina 42

Sisteme informatice de gestiune

Figura 3.2. Modelul incremental i n acest model exist posibilitatea erorilor n formularea cerinelor dar spre deosebire de modelul Waterfall acestea pot fi corectate de la un pas la altul pe parcursul realizrii sistemului. n plus se poate simula funcionalitatea sistemului, scopul su fiind furnizarea unor feed-back-uri rapide proiectanilor i conductorilor fr o pierdere inutil de timp, eliminndu-se posibilitatea construirii unui sistem greit. Fiecare increment realizat n fiecare pas de dezvoltare al sistemului se poate constitui ntr-un
pagina 43

Sisteme informatice de gestiune

prototip al viitorului sistem. Fiecare acest prototip poate s se regseasc sau nu n sistemul final dar regula general care trebuie urmrit const n planificarea eliminrii acestor prototipuri. Acest model reuete s integreze corect activitile 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 incrementri ale versiunii anterioare i nu nite modificri arbitrare i neautorizate. Numai acele modificri care vor determina schimbri favorabile n dezvoltarea sistemului vor fi aprobate. Verificarea const n stabilirea n continuu a corespondenei ntre ce s-a solicitat i ce s-a realizat. Validarea, trebuie s aib n vedere c sistemul construit s nu prezinte goluri i incoerene. Dezvoltarea incremental este ca o sabie cu dou tiuri, pentru c permind etapizarea sistemului n versiuni succesive, orice problem aprut i nerezolvat la un moment dat implic suspendarea etapelor urmtoare. Dezavantajul implicat de aceast situaie este totui mult mai mic, dect necazul produs de descoperirea erorii numai la finalizarea sistemului. Un alt avantaj const n posibilitatea dezvoltrii simultane a mai multor sisteme, fiecare n diferite stadii ale ciclului de via. Aceasta mrete capacitatea conducerii de a acoperii un domeniu mai vast putnduse aloca mai bine resursele, dar trebuie inut cont c pot aprea situaii n care este greu de estimat necesarul de resurse mai ales n situaiile neprevzute aprute n diferiii pai de dezvoltare ai sistemelor coordonate.
pagina 44

Sisteme informatice de gestiune

Modelul ciclului de concepie n V. Dezvoltarea unui sistem urmrind abordarile anterioare poate fi descompus ntr-o succesiune de faze: specificaii, concepie, programare i mentenan dup unii autori sau analiz preliminar, proiectare logic, proiectare tehnic, programare, implementare, exploatare i ntreinere, dup altii. (variante ale modelului Waterfall).

Figura 3.4. Ciclul de concepie n V

pagina 45

Sisteme informatice de gestiune

Pentru evidenierea faptului c anumite faze ale ciclului de via sunt condiionate de faze anterioare s-a propus reprezentarea ciclului de via al unui sistem informatic ca un ciclu de concepie n V (Figura 3.4.). Se observ c etapele din braul descendent sunt validate de cele situate pe braul ascendent. Asfel concepia arhitecturii aplicaiei va trebui s rspund testelor de funcionare a componentelor luate fiecare n parte dar i n ansamblu. Aceast schem pune clar n eviden principalul inconvenient al abordrilor clasice. Nu se poate valida analiza fcut la nceputul proiectului dect atunci cnd toate activitile de programare, testare i integrare sunt terminate.

Modelul OPERAIONAL. Acest model pornete de la o alt abordare dect modelele anterioare i anume prin concentrarea efortului de definire asupra aspectului operaional. Mecanismul implementrii nu este ascuns ci st la baza specificaiilor de definire. Cu alte cuvinte, modelul operaional creeaz specificaii executabile (numite i specificaii operaionale) care sunt ulterior transformate ntr-o eficient implementare. Astfel comportamentul extern al sistemului exist implicit n cadrul specificaiilor n timp ce structura intern nu. n acest tip de model proiectarea se refer direct la condiiile de mediu n timp ce celelalte modele pun accentul pe separarea cerinelor (comportamentul extern) de structura intern a sistemului. Prin realizarea legturii ntre specificaiile operaionale i structura intern a sistemului, se
pagina 46

Sisteme informatice de gestiune

constat c modelul operaional este "orientat pe problem" spre deosebire de celelate modele care sunt "orientate pe implementare".

Figura 3.3. Modelul operaional Unul dintre avantajele modelului operaional este marea sa putere descriptiv orientat direct spre rezolvarea problemei. Spre deosebire de modelul incremental care pornete de la o descriere liber a specificaiilor de definire, modelul operaional are descrieri formale, riguroase i care pot fi uor analizate. Acest fapt i permite s poat foarte uor s fie transpus pe calculator. Ca dezavantaje se constat contradicia dintre necesitatea transformrii cerinelor externe ntr-o structur intern nainte ca aceasta s fi fost definit. Deoarece modelul nu este prea rspndit evaluarea posibilitilor sale este dificil de fcut mai ales pentru sisteme de mari dimensiuni. El este n schimb mai folosit pentru realizarea sistemelor mici.

pagina 47

Sisteme informatice de gestiune

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 experimentri n situaii dintre cele mai diferite. Modelul Incrememtal include n ciclul de via activiti de conducere i dezvoltare prin pai succesivi, realiznd un feed-back rapid ntre proiectani i utilizatori. Modelul de concepie n V pune n eviden faptul c o faz o valideaz pe precedenta (similar modelului Waterfall) dar i faptul c numai fazele terminale realizeaz adevrata validare a etapelor de nceput. Modelul Operaional realizeaz specificaii "executabile", mrete rolul automatizrii i stabilete o strns legatur ntre specificaii 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 condiii subiective. Adesea un proiect trebuie nceput de la dorinele 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 hotrte c nu este de fapt ceea ce a dorit. Este extrem de greu de modelat aceast situaie: "Nu tiu ceea ce vreau dar tiu ceea ce nu doresc". Practica ne-a demonstrat c folosirea unui model imperfert i incomplet este totui mult mai util dect renunarea la orice fel de model. Dar modelul nu este totul. Avem nevoie de un set de prescripii pentru desfurarea activitilor cerute de etapele unui model bazat pe ciclul de via, prescripii utilizate pentru proiectarea sistemului. Am definit prin aceasta metoda de proiectare. Metoda de proiectare are o dubl responsabilitate:
pagina 48

Sisteme informatice de gestiune

de a creea produsul de a implementa o parte din modelul ciclului de via. ncercarea de a gsi 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 att reguli implicite ct i explicite. Regulile explicite sunt prezentate de obicei n documentaia de realizare dar cele implicite nu sunt prezentate nicieri. Cnd 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 paii care trebuie parcuri ci precizeaz i ce decizii trebuiesc luate n paii 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 operaie. Automatizare nseamn un suport pentru o metoda i este o parte integrat n procesul de dezvoltare a sistemului informatic. Dar soluionarea cu succes a problematicii const n integrarea coerent a metodelor folosite ntr-o metodologie, i nu n automatizarea lor. Automatizarea are o mulime 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 pstrarea unei cantitai mari de informaii care este imposibil de gestionat manual pentru sisteme de o anumit mrime.
pagina 49

Sisteme informatice de gestiune

Automatizarea implic o scdere a costurilor de dezvoltare i planificare rezultnd o cretere calitativ a activitii creative deoarece proiectanii i conductorii proiectului sunt degrevai de aspectele de rutin. De cele mai multe ori automatizarea faciliteaz nvarea i comunicarea ntre membrii proiectului.

pagina 50

Sisteme informatice de gestiune

IV. METODA 4.1. Prezentare

MERISE

Apariia metodei MERISE marcheaz o dat important n istoria prelucrrii informaiilor. Aceast apariie rezult pe de o parte din contextul generalizrii prelucrrilor conversaionale, consecin a salturilor tehnologice din anii '70, i pe de alt parte, rezult n urma numeroaselor lucrri asupra bazelor de date i asupra "abordrii sistemice". MERISE s-a nscut n Frana n jurul anilor 1978-1979 ca urmare a unei vaste consultri lansate de ctre 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 adevrat devenind un standard cu un numr de utilizatori n continu cretere att n domeniul public ct i n cel privat. Statisticile publicate n Frana n 1990 au confirmat aceast evoluie deoarece dintre ntreprinderile mari i mijlocii care foloseau o metoda de analiz-proiectare, 60% aleseser deja MERISE. MERISE acumuleaz continuu i completeaz cmpul su de aplicabilitate integrnd noi extensii. Patru sunt direciile principale de evoluie: integrarea arhitecturilor client/server; o mai buna poziionare n raport cu metodele anglosaxone; o abordare orientat pe obiecte;
pagina 51

Sisteme informatice de gestiune

dezvoltarea unui mediu metodologic european concretizat astzi prin proiectul EUROMETHODE. Consftuirea cu tema "MERISE et les autres" desfurat 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 poziiei acestei metode n raport cu alte abordri metodologice. MERISE are numeroi adepi care o utilizeaz cu pasiune, dar i opozani care o consider o metod greoaie. Dac anumite proiecte sunt uneori nereuite aceasta este din cauza unei folosiri inadecvate a metodei. Folosirea metodei MERISE implic o investiie personal care presupune o mare rigoare i folosirea unor tehnici complexe. Aceast investiie personal nu a fost facut, uneori, n cele mai bune condiii i n aceast situaie, pentru anumii conductori de proiecte, metoda pare greoaie. Pentru a reui, un proiect MERISE trebuie s aib obligatoriu adeziunea i participarea utilizatorilor. Metoda presupune construirea de modele la nivel conceptual, organizaional i operaional furniznd astfel legturile existente n sistemele informaionale. (Figura 4.1.)

pagina 52

Sisteme informatice de gestiune

Figura 4.1. Nivelele metodei Merise NIVELUL CONCEPTUAL const n analiza sistemului informaional n termenii obiectivelor, fr a ine cont de nici un concept legat de organizare ("ce trebuie fcut i cu ce date?"). Trebuie studiate separat n plan conceptual, pe de o parte datele i organizarea lor i pe de alt parte prelucrrile.
pagina 53

Sisteme informatice de gestiune

n termeni de organizare a datelor se face apel la formalismul entitate-relaie i aceasta se traduce prin entiti de baza i relaii ntre aceste entiti. La acest nivel, cu ajutorul unei grafici adecvate se constituie modelul conceptual al datelor (MCD), care permite o descriere static a sistemului informaional cu ajutorul conceptelor de entitate i asociaie. MCD permite reprezentarea datelor din realitatea nconjurtoare independent de opiunile tehnice, pentru a uura gndirea n timpul activitii de concepie. n termeni de organizare a prelucrrilor aceste entiti vor fi descrise prin prelucrrile pentru care ele sunt cauze i consecine. Aceast etap are ca scop definirea operaiilor principale care trebuie efectuate n domeniul studiat. Se va stabili o diagram de flux (modelul conceptual al comunicaiilor MCC) care permite descrierea informaiilor schimbate global n sistem prin intermediul actorilor i fluxurilor. Pornind de la aceast diagram, se va trece spre modelul conceptual al prelucrrilor (MCP). Rezultatul su final se va concretiza sub form schematic ntr-un model "eveniment-operaie-rezultat" care va trebui s rspund la ntrebrile: ce trebuie fcut n interiorul sistemului informaional, sub impulsul cror evenimente i ce rezultate se obin? NIVELUL ORGANIZAIONAL const n integrarea n analiz a criteriilor legate de organizare. Dup ce nivelul conceptual a exprimat realitatea perceput n ansamblul su, nivelul organizaional exprim aceast realitate aa cum este ea trit de actorii participani, indiferent care ar fi acetia. La acest nivel nu se face nici o distincie ntre oameni i maini. La nivelul datelor este necesar orientarea ctre o clas de soluii, i apare modelul logic al datelor (MLD) care este o transcriere a modelului conceptual al datelor. Are loc, n privina datelor, o
pagina 54

Sisteme informatice de gestiune

transformare a lor dar nu o mbogire a lor. Nivelul conceptual al datelor este o descriere complet a sistemului. Date noi pot fi create la nivele inferioare (crearea unei redundane n vederea minimizrii numrului de accesri la una din entiti) dar n nici un caz nu se pot crea informaii noi. Situaia este diferit la nivelul prelucrrilor. Trecerea de la nivelul conceptual (MCP) la nivelul organizaional (MOP) se concretizeaza prin ataarea evenimentelor definite anterior, actorilor. n aceste proceduri globale vor apare ntotdeauna actori care au n plus noiunea de restricie temporal i organizatoric. La nivelul prelucrrilor evenimentele descrise au mai ales o dominant spaial dect una temporal i se completeaz nivelul conceptual rspunznd la ntrebrile cine? i unde?. NIVELUL OPERAIONAL este o reprezentare a mijloacelor care vor fi efectiv folosite pentru a gestiona datele i prelucrrile i const n furnizarea soluiilor tehnice rspunznd la ntrebarea cum?. La nivelul datelor se va trece de la o clas de soluii la una singur. Aceasta se concretizeaza prin utilizarea unui anumit SGBD. Se face o alegere privind metodele de stocare i de acces la informaii. Se construiete la acest nivel modelul fizic al datelor (MFD) care este transformarea modelului logic al datelor (MLD) prin echivalarea noiunilor de tablou i coloane cu noiunile de relaie i atribute din modelul logic al datelor. La nivelul prelucrrilor se procedeaz la mprirea proiectului n programe. Modelul operaional va descrie arhitectura programelor care vor executa anumite funcii, dar n nici un caz la acest nivel nu va exista o activitate de programare efectiv.
pagina 55

Sisteme informatice de gestiune

Fiecare din aceste nivele are ca obiectiv principal furnizarea unui anumit numr de documente care s permit sinteza procesului de gndire. Aceste documente, indispensabile elaborrii, sunt leagate de cele rezultate din analiza datelor. Punerea n aplicare a modelelor de prelucrare la orice nivel, conceptual, organizaional sau operaional are nu numai scopul de a defini prelucrrile de efectuat dar i opiunile 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 realizrii sistemului. Aceste trei cicluri se desfoar simultan. 1.Ciclul de abstractizare este realizat prin formalismul celor trei nivele conceptual, organizaional i operaional i se va aplica asupra prelucrrilor i datelor. 2.Ciclul de via presupune trei mari etape: concepia sau perioada studiului sistemului existent i apoi a noului sistem; realizarea care acoper proiectarea i exploatarea sistemului; ntreinerea care va permite sistemului s evolueze i s se adapteze modificrilor de mediu i noilor obiective pn 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 desfurrii proiectului, mai generale la nceput i apoi din ce n ce mai precise.

pagina 56

Sisteme informatice de gestiune

Figura 4.2. Cele trei cicluri ale metodei Merise Aceste noiuni sumar prezentate se adreseaz att utilizatorilor (cei care solicit serviciile) ct i informaticienilor (furnizorii de prestaii). Eficacitatea i validitatea unei analize const n calitatea comunicaiei dintre beneficiar i proiectant iar calitatea comunicaiei este obinut, n parte, graie utilizrii corecte a unei metode de analiz.

pagina 57

Sisteme informatice de gestiune

4.2. Ciclul de via n ara noastr ultima reglementare metodologic n domeniul ciclului de via cu aplicabilitate n economie i avnd caracter de directiv aparine Institutului Central de Infornatic i dateaz din decembrie 1977. Conform acestei metodologii realizarea sistemelor informatice se desfoar n ase etape: elaborarea temei de realizare, elaborarea concepiei sistemului informatic (proiectarea logic), proiectarea tehnic, elaborarea programelor, implementarea, exploatarea i ntreinerea. 4.2.1. Elaborarea informatic. temei de realizare a sistemului

n aceast etap iniial se examineaz posibilitatea realizrii unui nou sistem informatic, sau modificrii sistemului existent. Stimulul declanator al acestei etape trebuie s fie de regul viitorul beneficiar. Principala activitate n acest stadiu este cunoaterea 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 urmtoare. Elaborarea temei de realizare este etapa prin care se cunoate situaia actual, se furnizeaz un diagnostic i se caut soluiile posibile. n aceasta etap trebuie elaborat o soluie independent de mijloacele de realizare. Rezultatele acestei etape constau n "caietul de sarcini" i "specificaiile funcionale generale".
pagina 58

Sisteme informatice de gestiune

De obicei aceast etap, frecvent denumit i studiu de oportunitate sau analiz preliminar implic timp i efort relativ redus, doar din partea unor specialiti cu experien i care au mai ntocmit lucrri similare. Obiectivul principal al acestei etape este formularea cerinelor informaionale ale sistemului de conducere. Activitile din cadrul acestei etape sunt : studiul sistemului existent, evaluarea sistemului existent, evaluarea gradului de pregtire a ntreprinderii, formularea cerinelor i a restriciilor pentru realizarea sistemului informatic. n cadrul acestei ultime activiti, cea mai important din prima etap intr: definirea obiectivelor i performanelor noului sistem; stabilirea domeniului i funciunilor noului sistem informatic; definirea cerinelor i restriciilor informaionale pe probleme i funciuni; estimarea resurselor disponibile pentru proiectarea, implementarea i exploatarea noului sistem. n realizarea etapizat a sistemului informatic tebuie, n primul rnd, 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 urmrete definirea caracteristicilor generale i analiza activitilor desfurate. De asemenea studiul sistemului presupune i analiza modului n care sistemul informaional asigur legturile ntre sistemul conductor i sistemul condus.
pagina 59

Sisteme informatice de gestiune

Pe baza concluziilor rezultate din studiul sistemului, se evalueaz critic sistemul informaional i se formuleaz cerinele i restrictiile pentru realizarea sistemului informatic. Printre tehnicile i metodele de analiza a sistemului existent se numar: 1. 2. 3. 4. 5. 6. Tehnica documentrii Metoda analizei-diagnostic Metoda diagramelor de flux informaional Metoda evidenei economice Metoda anchetelor Metoda scenariilor

1. Tehnica documentrii. Prin tehnica documentrii se urmrete culegerea i prelucrarea informaiilor cu caracter teoretic i practic privind sistemul studiat. Pentru atingerea acestui obiectiv, documentarea trebuie s se desfaoare ntr-o ordine logic folosind ca instrument principal de lucru documentele care reglementeaz existena i funcionarea sistemului respectiv. Astfel de documente sunt: organigrama, regulamentul de organizare i funcionare, alte acte nomative. Prin organigram sunt reprezentate grafic gruparea compartimentelor de munc dup criterii funcionale, subordonarea acestora, repartizarea lor i legturile dintre compartimente. n acest mod organigrama vizualizeaz natura i poziia fiecrui compartiment. Ea reflect obiectivele sistemului economic, responsabilitile, delegrile de autoritate i legturile funcionale. Informaiile cu caracter general obinute prin analiza organigramei pot fi completate
pagina 60

Sisteme informatice de gestiune

prin studiul regulamentului de organizare i funcionare a sistemului. Aspecte de detaliu asupra modului de desfaurare a activitilor sunt completate prin parcurgerea actelor normative care reglementeaz prestarea lor. Analiza situaiei existente este completat prin documentarea asupra unor studii i proiecte informatice elaborate n alte ntreprinderi cu profil apropiat. Rezultatele documentrii 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 informaii 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 funcionarea sistemului i n stabilirea remediilor corespunzatoare. Prin cercetarea activitilor desfurate se stabilesc direciile de dezvoltare pentru sistemul existent. Obiectivele analizei-diagnostic sunt: Realizarea unui sistem de organizare i conducere perfecionat flexibil la modificrile care apar. Prin analiza-diagnostic urmeaz s se stabileasc n ce msur structura organizatoric satisface necesitile conducerii i posibilitile de cretere a fiabilitii sistemului prin tratarea automat a datelor. Prevenirea factorilor perturbatorii care genereaz efecte negative asupra sistemului economic sub aspect structural, funcional i al nivelului de performan.
pagina 61

Sisteme informatice de gestiune

Identificarea cilor 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 realizrii sistemului informatic. Realizarea presupune luarea n considerare a urmtoarelor aspecte: strategia de dezvoltare a ntreprinderii; condiiile de materializare pe baza resurselor disponibile; prioriti care se impun n funcie de condiii; n aplicarea metodei se recomand parcurgerea urmtoarelor etape de lucru: culegerea informaiilor privind organizarea i funcionarea sistemului existent; formularea obiectivelor, care se realizeaz prin conturarea elurilor urmrite i a modalitilor de realizare; enunarea instruciunilor privind desfurarea aciunilor; realizarea practic a instruciunilor; analiza informaiilor culese i evaluarea rezultatelor; Dac soluiile rezultate nu sunt edificatoare asupra obiectivelor urmrite atunci analiza diagnostic se reia. Concluziile analizei-diagnostic, corelate cu rezultatele documentrii, constituie baza cunoaterii sistemului i a posibilitilor de perfecionare. 3. Metoda diagramelor de flux informaional. Identificarea caracteristicilor sistemului de conducere necesit detalierea analizei sistemului
pagina 62

Sisteme informatice de gestiune

informaional. n acest scop se apeleaz la metoda diagramelor de flux a documentelor i a momentelor lor de completare urmrind raionalizarea sistemului informaional i ameliorarea funcionrii acestuia. Diagramele de flux informaional dau o descriere sistemica a unui proces sau a unui ciclu de munc cu suficiente detalii, care odat analizate pot duce la o mbuntire a activitii respective. Fiecare element component al diagramei este astfel reprezentat nct 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 evidenei economice. Evidena economic reprezint un ansamblu de procedee i tehnici de urmrire a fenomenelor i proceselor care au avu loc n domeniul vieii economice. Prin coninut evidena economic este componenta major a sistemului informaional economic. Orice operaie de flux real al valorilor materiale i bneti trebuie s se gseasc consemnat n documentele de eviden economic. Dup procedeele i tehnicile folosite n investigarea realitii economice evidena economic se constituie n trei forme distincte: a)- evidena tehnico-operativ b)- evidena contabil c)- evidena statistic
pagina 63

Sisteme informatice de gestiune

a)

Evidena tehnico-operativ const n consemnarea i centralizarea datelor privind procesele i fenomenele economice la locul i n momentul producerii lor. Evidena tehnico - operativ furnizeaz informaii necesare conducerii operative. Evidena contabil sau contabilitatea urmrete formarea existena i folosirea mijloacelor economice i a surselor lor de formare. Prin coninut contabilitatea este cea mai important component a evidenei economice. Ea asigur continuitatea circuitului informaional ntre evidena tehnico-operativ i cea statistic i este principala surs de informaii a conducerii tactice i strategice. Evidena statistic sau statistica oglindete i caracterizeaz procesele n ansamblul lor prin studierea unor fenomene social-economice de mas. Cu ajutorul statisticii se poate studia evoluia unor fenomene n perioadele anterioare pentru a determina evoluia lor viitoare.

b)

c)

5.Metoda anchetelor. Prin aceast metod se culeg informaii 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 urmtoarele principii: selectarea persoanelor de interogat avnd n vedere poziia lor n sistem i competena lor profesional; antrenarea subiecilor alei la emiterea de idei noi privind modul de desfurare a activitilor; acceptare ideilor emise far o judecat imediat a valorii lor;
pagina 64

Sisteme informatice de gestiune

stimularea gndirii participanilor prin formularea de ntrebri adecvate; verificarea rezultatelor prin mbinarea modului de aplicare al tehnicilor; Respectarea acestor principii asigur luarea n considerare a comportamentului subiectilor investigai, i n consecin, culegerea de informaii critice asupra strii i funcionrii sistemului. Metoda anchetelor se constituie dintr-un complex de tehnici cu caracter interogativ cum sunt: A) tehnica chestionarului B) tehnica interviului C) tehnica observrii directe A. Tehnica chestionarului presupune utilizarea chestionarului ca instrument de culegere a informaiilor referitoare la obiectivele analizei. ntocmirea chestionarului cuprinde trei faze distincte: 1. Faza pregatitoare, n care se exactitate obiectivele chestionrii. Astfel de obiective pot fi: a) b) c) delimiteaz cu

analiza activitilor de baz; principali indicatori economici folosii; 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 informaiilor i modul de prelucrare ulterioar. 2. Faza de ntocmire a chestionarului.
pagina 65

Sisteme informatice de gestiune

n funcie de obiective i subiecii ce urmeaz a fi supui chestionrii, se stabilesc numrul i tipul de ntrebri. Numrul mediu de ntrebri ntr-un chestionar trebuie s fie cuprins ntre 15 i 20. Un numr prea mic de ntrebri nu poate furniza informaiile dorite i nu justific efortul fcut pentru organizarea chestionarului, iar un numr prea mare de ntrebri obosete subiectul chestionat ceea ce duce la emiterea de rspunsuri pripite, neconcludente pentru analiza de sistem. Activarea subiecilor se poate asigura prin folosirea mai multor tipuri de ntrebri, cum sunt: ntrebri nchise, cu un numr redus de rspunsuri precodificate prin care subiecii se pronun asupra unor informaii culese prin alte metode i tehnici; ntrebri factuale asupra unor fapte obiective, de verificare a aptitudinilor, de identificare a unei stri de fapt, de clarificare a unor aspecte ale analizei; ntrebri deschise la care numrul rspunsurilor poate varia de la un subiect la altul. Dup locul ocupat n chestionar, ntrebrile se grupeaz astfel: introductive, n problema analizat; "de filtru" prin care se precizeaz condiionarea ntre ntrebri; de bifurcare prin care se identific numrul ntrebrilor la care se va rspunde n continuare dac s-a rspuns afirmativ la ntrebarea anterioar i numrul ntrebrilor nlnuite n cazul n care rspunsul anterior a fost negativ; de motivare a unor rspunsuri; de control a exactitii rspunsurilor i de identificare a subiectului chestionat. Pentru ca formularea ntrebrilor s fie corect i corespunzatoare realizrii obiectivelor, la aceast
pagina 66

Sisteme informatice de gestiune

aciune trebuie s participe, pe lng informaticieni sociologi, psihologi, statisticieni. 3. Faza de verificare a chestionarului. Prin testri se urmrete modul n care rezultatele chestionrii concord cu obiectivele investigaiei. n funcie de constatrile faptice, se corecteaz formularea ntrebrilor i ordinea lor n chestionar. n ntocmirea i completarea chestionarului este recomandat respectarea urmtoarelor reguli: formularea simpl, clar, concis i explicit a ntrbrilor; asigurarea libertii subiecilor de a completa sau nu chestionarul printr-o ntrebare introductiv; evitarea formulrii de ntrebri tendenioase, ipotetice, prezumptive, insuficient de clare; asigurarea unei succesiuni logice a ntrebrilor; schimbarea ordinii rspunsurilor precodificate n formulare pentru a se elimina tendina de alegere a primului rspuns; includerea n chestionar a unor ntrebri de control prin care s se asigure veridicitatea rspunsurilor. Completarea chestionarului de un numr reprezentativ de subieci, asigur obinerea de informaii relevante pentru analiza sistemului. B. Tehnica interviului Prin aceast tehnic se urmrete obinerea ntrun interval de timp redus, de informaii privind orientrile practice, metodele i strategiile existente sau preconizate n rezolvarea problemelor analizate.

pagina 67

Sisteme informatice de gestiune

Interviul asigur obinerea de informaii recente i verificarea informaiilor obinute prin alte metode sau tehnici. Alegerea subiectilor de intervievat se face avnd n vedere urmtoarele constatri practice: persoanele care ocup poziii medii n ierarhia structurii organizatorice furnizeaz informaiile cele mai apropiate de realitate; colectarea de informaii corecte presupune intervievarea nu numai a personalului de conducere ci i a celui de execuie; competena subiecilor trebuie verificat n prealabil; lipsa unei atitudini critice poate s semnifice reineri n exprimarea ideilor. Procedura de aplicare a interviului cuprinde trei etepe: 1. Etapa pregtitoare const n urmtoarele: nsuirea terminologiei utilizate n domeniul studiat; formularea i coordonarea ntrebrilor; cunoaterea prealabil a subiecilor; alegerea momentelor propice pentru luarea interviului (de obicei, partea medie a perioadei de activitate). 2. Etapa de desfurare a interviului. n aceast etap se cer a fi respectate urmtoarele reguli: meninerea discuiei n limitele problemei analizate, acordarea unor momente de gndire, formularea de ntrebri ajuttoare, evitarea consemnrii de rspunsuri fr argumentaie insistarea asupra aspectelor neclare
pagina 68

Sisteme informatice de gestiune

sesizarea strilor de reinere n a critica aspectele negative ale activitii analizate; evitarea discuiilor n contradictoriu; solicitarea de recomandri i din partea altor persoane competente din domeniul analizat.

3. Etapa de culegere i prelucrare a informaiilor se realizeaz prin consemnarea n raportul de interviu a rspunsurilor cu precizarea aspectelor neclarificate i a posibilitilor de completare a rezultatelor. Concluziile interviului reflect starea elementelor sau a proceselor analizate i posibilitile de remediere a deficienelor existente. C. Tehnica observrii directe. Observarea direct a activitilor, asigur cunoaterea nemijlocit a sistemului existent. Prin tehnica observrii directe se studiaz sarcinile care formeaz coninutul unei activiti. n analiza actvitii de producie, spre exemplu, prin consemnarea operaiilor efectuate asupra produsului i a timpilor de execuie se contureaz structura ciclului de fabricaie i alte aspecte ale produciei 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 obinute prin alte metode. Tehnica observrii directe folosete instrumente specifice de lucru:
pagina 69

Sisteme informatice de gestiune

sondaje cronometrri analiza posturilor ( locurilor de munc) Prin aplicarea acestora se relev stri de fapt i posibiliti pentru ameliorarea funcionarii sistemului. n cadrul anchetelor combinarea tehnicilor menionate asigur clarificarea problemelor de rezolvat prin cunoaterea detaliat a sistemului i obinerea de informaii privind posibilitile de raionalizare a activitilor. Rezultatele relev deficienele existente i impiicaiile tratrii automate a datelor. 6.Metoda scenariilor. Metoda scenariilor se bazeaz pe un ansamblu de procedee i instrumente prin care se stabilete succesiunea logic a evenimentelor, n scopul de a arta cum se poate evolua pas cu pas spre o situaie viitoare plecnd de la situaia actual. Pentru fiecare alternativ se urmrete evoluia sistemului repernduse noi puncte nodale. Prin abordarea global a sistemului sunt elaborate scenarii calitative care stau la baza elaborrii scenariilor cantitative. Situaia cercetrilor previzionare la nivel global se justific prin aceea c evenimentele care depind de fenomene generale sunt, pe termen lung, mai uor de prevzut dect acelea care depind de circumstane particulare. Obiectivele principale urmrite prin aplicarea metodei scenariilor sunt: predicia dezvoltrii, a evoluiei unor fenomene i procese;
pagina 70

Sisteme informatice de gestiune

stimularea gndirii n studiul unei probleme decizionale; analiza detaliat a aspectelor dinamice. n realizarea acestor obiective se urmrete parcurgerea urmtoarelor 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 elaborrii modelelor vor sta seriile dinamice ale indicatorilor ce reflect aciunea factorilor. 3. Scrierea scenariilor prin abordare global i descrierea evoluiei sistemului n dinamic, innd cont de modificrile care apar n structura sistemului. 4. Stabilirea tendinelor n funcie de care va evolua sistemul, dac asupra lui nu se exercit aciuni voluntare externe. 5. Extragerea rezultatelor prin reinerea acelor tendine manifestate care corespund obiectivelor propuse. 4.2.2. Proiectarea logic sistemului informatic). (elaborarea concepiei

Obiectivul acestei etape l constituie elaborarea proiectului de ansamblu al sistemului informatic, pe baza cerinelor i restriciilor formulate n tema de realizare. Scopul acestei etape const n determinarea obiectivelor detaliate i cerinelor noului sistem. Determinarea cerinelor se face prin studiul organizaiei
pagina 71

Sisteme informatice de gestiune

pe care o va servi sistemul, accentul punndu-se pe beneficiile pe care le va aduce sistemul propus. Principalele activiti care se desfoar n cadrul etapei de concepie a sistemului informatic sunt urmtoarele: definirea sistemului informatic, cuprinznd delimitarea ariei i a legturilor sale externe; estimarea dimensiunilor sistemului; definirea structurii logice a datelor i definirea proceselor de prelucrare a datelor; adoptarea soluiei de principiu pentru codificarea datelor i conversia fiierelor; proiectarea de principiu a noului flux informaional; stbilirea necesarului de echipamente, configuraiile necesare, precum i modul de procurare a echipamentelor; stabilirea condiiilor de montaj, funcionare 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 intrrilor, ieirilor, i prelucrrilor necesare; elaborarea graficului de ealonare pentru proiectarea i implementarea componentelor sistemului; evaluarea efectelor pe care le va produce noul sistem informatic; estimarea eficienei economice. msuri pregtitoare pentru realizarea sistemului;

Activtatea cea mai important n cadrul elaborrii concepiei sistemului informatic este analiza circuitului informaional. Aceasta nseamn c fluxurile pariale urmeaz a primi coeren prin studiul legturilor i prelucrrilor nlnuite. n acest fel este posibil s se
pagina 72

Sisteme informatice de gestiune

delimiteze cu claritate graniele sistemului informatic i legturile sale externe. Aplicarea metodelor de analiz a circuitului informaional se bazeaz pe urmtoarele constatri practice: fiecare activitate are un circuit informaional propriu; delimitarea sistemului informatic presupune analiza distinct a fiecrei activiti; analiza fiecrei activiti este condiionat de cunoaterea obiectivelor sistemului economic i de reglementrile care definesc sistemul informaional; n activitatea de gestiune economic operaiile de prelucrare a datelor nu sunt diversificate i au caracter ciclic (operatiile aritmetice i logice simple reprezint circa 80% din totalul operaiilor de prelucrare); pentru fiecare activitate, intrrile condiioneaza i sunt condiionate de ieirile informaionale; prelucrarea datelor de intrare specifice unei activiti n scopul obinerii ieirilor dorite definete transformrile informaionale i determin circuitul informaional al activitii; Stabilirea ieirilor i intrrilor informaionale sunt determinante n organizarea datelor, n timp ce transformrile informaionale determin organizarea prelucrrilor. Bazate pe aceste constatri, metodele de analiz a sistemului informaional i de delimitare a ariei i a legturilor externe ale sistemului informatic mai des utilizate sunt: 1 - metoda analizei ieirilor; 2 - metoda orientat pe activiti; 3 - metoda rspunsului la stimuli; 4 - metoda compartimental; 5 - metode analizei celulare.
pagina 73

Sisteme informatice de gestiune

1. Metoda analizei ieirilor. Metoda analizei ieirilor const n parcurgerea fluxurilor informaionale invers, de la informaia final (de ieire) spre informaia iniial (de intrare). Aceasta analiz se face pe baza diagramelor de flux informaional. Prin parcurgerea ntregului circuit informaional, se determin: volumul datelor de ieire; volumul datelor de intrare; prelucrrile efectuate pe parcursul circuitului; purttorii de informaie; caracteristicile datelor. Metoda analizei ieirilor permite obinerea unei imagini complete asupra circuitului informaional. Totodat, pot fi remarcate deficiene de circuit i posibiliti de raionalizare a sistemului informaional. 2. Metoda orientat pe activiti. Prin aplicarea acestei metode se urmrete definirea complet a aspectelor informaionale care caracterizeaz fiecare activitate. Parcurgerea fluxurilor informaionale pe fiecare activitate asigur cunoaterea detaliat a sarcinilor i a operaiilor care definesc activitile. Analiza unei activiti se face independent de celelalte, rednd caracteristicile i intercondiionrile interne ale activitii. Metoda orientat pe activiti este eficient n sisteme n care se manifest autonomia activitilor prin relaii de interdependen reduse.

pagina 74

Sisteme informatice de gestiune

3. Metoda rspunsului la stimuli. Metoda rspunsului la stimuli are ca punct de plecare un stimul oarecare, cum ar fi: o comand, un produs, o faz de fabricaie etc. Analiznd amnunit stimulul, se stabilesc legturile dintre activiti 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 urmrete fluxul principal al informaiilor cu stabilirea punctelor n care apar ramificaii i identificarea punctelor de control. Analiza se completeaz cu studiul fluxurilor secundare. Pentru activiti complexe, metoda rspunsului la stimuli asigur observarea conexiunilor i demarcarea operaiilor principale de cele secundare. 4. Metoda compartimental. n aplicarea metodei compartimentale se stabilesc aciunile care se realizeaz ntr-un compartiment i legturile compartimentului studiat cu celelalte compartimente. Pentru activiti sau pri din activitile desfurate n compartiment se determin intrrile, prelucrrile i ieirile informaionale necesare realizrii 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 informaional
pagina 75

Sisteme informatice de gestiune

dup gradul lor de complexitate. Fiecrei componente de tip subsistem i se asociaz un rang. Subsistemul de rang zero este componenta elementar i se numete celul. Pentru o celul C intrrile X={x1,x2,....,xn}, ieirile Y={y1,y2,..,ym} i transformrile T ale intrrilor n ieiri definesc celula respectiv: C={X,Y,T} Dac ieirea 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 Mrimile Yi i Xj (ieirile din celula i i intrrile n celula j) desemneaz acelai element. Aceast dubl semnificaie constituie o redundan informaional. Reducerea unor asfel de redundane se face prin introducerea conceptului de generaie. Elementul Xj este un operand de generaia j. Ca urmare a transformrii efectuate n celula j, apare generaia j+1 de operanzi ceea ce se exprim prin relaia: Xj+1,r = T Xj,r
pagina 76

Sisteme informatice de gestiune

n care r semnific numrul de ordine al operandului n cadrul generaiei.

Figura 4.4. Generaii de operanzi Dou sau mai multe lanuri de celule care au cel puin un punct comun, formeaz un arbore de celule: A = { Lk , Lm } Doi sau mai muli arbori legai n serie, paralel sau mixt formeaz o structur complex. (Figura 4.5.) Convenii: operanzii primari (datele primare) constituie operanzi de generaia zero. ( X01, X02, X03, X04); transformrile operanzilor de generaia zero formeaz familia de operatori de generaia 1 (T11, T12, T13); celulele sunt reprezentate de operatorii lor prevzui cu doi indici; primul indic generaia, iar al doilea numrul de ordine al operatorului n cadrul familiei; ieirile unui operator sunt de aceiai generaie cu operatorul, indiferent de generaia intrrilor; operatorii n lant sunt de generaii monoton cresctoare;
pagina 77

Sisteme informatice de gestiune

un operand poart o singur pereche de indici chiar i cnd constituie intrri pentru mai muli operatori de aceiai generaie sau de generaii diferite.

Figura 4.5. Arbore de celule La nivelul ntreprinderii un operator se constituie din reguli de lucru al cror suport fizic poate fi material sau imaterial. Celula n care acioneaz un operator se delimiteaz n funcie de necesitile analizei celulare. Eficiena metodei crete prin combinarea aplicrii ei cu alte metode. Codificarea datelor. Premiza principal a realizrii 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 msur la realizarea eficienei scontate pentru ntregul sistem informatic. Aceasta asigur eliminarea
pagina 78

Sisteme informatice de gestiune

volumului mare de redundan informaional i raionalizarea procesului de tratare a datelor. Operaia de codificare a datelor const n stabilirea unei corespondente biunivoce ntre elementele sistemului informaional (documente, operaii, 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 ieire. Desfurarea operaiei de codificare presupuue respectarea urmtoarelor principii: adoptarea acelorai norme n determinarea vocabularului de intrare; folosirea unui limbaj de codificare accesibil, astfel nct interpretarea alfabetului de ieire s se fac fr dificulti; respectarea biunivocitii ntre vocabularul de intrare i limbajul de codificare. n finalul codificrii, la fiecare element al vocabularului trebuie s corespund un cod unic determinat; previziunea evoluiei codurilor care s asigure posibilitatea actualizrii sistemelor de coduri fr perturbaii; sistemele de coduri adoptate s fie sugestive n redarea legturilor dintre fenomene, procese i documente; adaptarea codificarii n vederea prelucrrii electronice a datetor. ntre codurile interne sistemului economic i codurile folosite n economia naionala, urmeaz a se stabili modaliti de conversie care s asigure obinerea ieirilor informaionale necesare n exterior.
pagina 79

Sisteme informatice de gestiune

ntr-o abordare metodologica, codificarea const n urmtoarele activiti: A. Stabilirea caracteristicilor generale ale codurilor. Determinarea vocabularului de intrare i a caracteristicilor acestuia. Analiza structurii informaiilor din vocabularul de intrare pentru fixarea structurii generale a codului pe grupe de elemente ale sistemului informaional. Necesitile de prelucrare impun utilizarea de coduri prin care s se indice locul de stocare sau de utilizare conturile n care se consemneaz natura i apartenena elementelor codificate. Determinarea alfabetului de ieire n funcie de mrimea vocabularului de intrare i de structura general a codurilor. Codurile care definesc alfabetul de ieire, trebuie s conin un minimum de simboluri de reprezentare. Fixarea sistemelor de coduri astfel nct acestea s asigure maximum de uniformitate a codificrii. Principalele sisteme de coduri utilizate sunt: 1. Sistemul n ordine numeric (natural) este utilizat pentru elemente temporare ale sistemului, fr periodicitate. Orice element nou aprut afecteaz ntregul sistem de coduri. 2. Sistemul n serie este o dezvoltare a sistemului n ordine natural prin rezervarea de numere pentru eventuale apariii de noi elemente n vocabularul de intrare. 3. Sistemul pe grupe const n atribuirea unui anumit numr de coduri fiecrei clase de elemente de reprezentat. n general codul ijk (i = 1, m ; j = 1, n ;
pagina 80

Sisteme informatice de gestiune

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 rmn 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 puin 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 mulimilor. 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 importana codurilor n efectuarea prelucrrii datelor, o atenie deosebit trebuie acordat corectitudini fiecrui cod utilizat. n acest scop la cod se adaug o cifr de control care s permit verificarea
pagina 81

Sisteme informatice de gestiune

corectitudinii accstuia n orice moment al tratrii informaiei reprezentate. Cifra de control se stabilete dup algoritmi diferii. B. Clasificarea elementelor vocabularului de intrare de la general la particular pn la nivel elementar cu respectarea normelor legale. Operaiile i documentele se grupeaz dup locul i rolul lor n sistem, materialele dup natur, proprieti, 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 corespondenei ntre vocabularul de intrare i alfabetul de ieire. E. Unificarea terminologiei i atribuirea codurilor. n toate documentele de uz intern urmeaz a se atribui coduri elementelor sistemului informaional. F. Actualizarea codurilor const n adugri de coduri pentru elementele nou intrate n sistem i n eliminri de coduri perimate pentru elemente care nu se mai utilizeaz. Estimarea eficienei economice a sistemelor informatice. Asimilarea lucrrilor de realizare a unui sistem informatic cu lucrrile de investiii, face ca determinarea i urmrirea eficienei s fie un aspect major al realizrii sistemului informatic. Obiectivul global urmrit este creterea efectului util al fiecrui leu cheltuit. Eficiena, ca raport ntre efectul util i efortul fcut pentru obinerea efectului scontat, se urmrete sub aspecte multiple. (productivitatea muncii, indici de utilizare ai resurselor, norme de consum, etc.)
pagina 82

Sisteme informatice de gestiune

Din punct de vedere informaional, satisfacerea nevoilor de informare ale conducerii, entropia informaional, costul informaiei, redau eficiena sistemului informaional. n consecin, aspectele de eficien se refer nu numai la resursele i efectele imediate ale realizrii unei investiii; prin studiul cheltuielilor necesare i al efectelor directe i indirecte pe o perioad mai mare de timp. Ele includ i urmrirea fiabilitii obiectivului investiiei dup darea lui n exploatare. Evaluarea cheltuielilor. Cheltuielile de realizare a sistemului informatic se constituie din cheltuielile de investiii necesare elaborrii i introducerii sistemului informatic. n cheltuielile de exploatare se includ i cele necesare ntreinerii sistemului n scopul creterii performanelor acestuia. n etapa de analiz i proiectare a sistemului informatic, sunt angajate cheltuieli curente cu salariile echipei de proiectare (n situaia cnd proiectarea se face cu fore proprii). Declanarea activitilor de conconceptie, implic efectuarea de cheltuieli pentru pregtirea cadrelor proprii de informatic ce vor asigura exploatarea sistemului. De asemenea, nc din aceast etap de lucru, apare necesar pregtirea psiho-social a personalului ntreprinderii asupra utilitii sistemului informatic. n acest scop sunt necesare cheltuieli cu desfurarea de prezentri demonstrative privind avantajele prelucrrii automate a datelor i implicaiile scontate. Scopul unor astfel de aciuni este de a se asigura din timp participarea activ a personalului la realizarea schimbrilor pe care le va genera introducerea sistemului informatic, evitndu-se opoziia surd a celor vizai s fie atini de noua tehnologie.
pagina 83

Sisteme informatice de gestiune

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 aplicaii tip i a unor produse-program generalizabile (software). Aceasta asigur nc de la nceput, scurtarea perioadei de analiz-proiectare, reducerea efortului de programare i creterea performanelor de exploatare a sistemului informatic. Cheltuielile pentru realizarea sistemului informatic se mpart n: 1. cheltuieli iniiale ( Ci ): cheltuieli pentru promovarea noii soluii; cheltuieli pentru analiz i proiectare; cheltuieli pentru procurarea i adaptarea produselor software tipizate; cheltuieli pentru procurarea configuraiei hardware; cheltuieli pentru amenajarea spaiilor necesare instalrii echipamentelor. 2. cheltuieli de exploatare ( Ce ): cheltuieli cu salariile personalului de informatic; cheltuieli pentru perfecionarea pregtirii personalului; cheltuieli cu materialele consumabile i cu amortizarea tehnicii de calcul; cheltuieli cu ntreinerea curent i reparaii; cheltuieli pentru ntreinerea software a sistemului informatic (adaptarea sistemului informatic).

pagina 84

Sisteme informatice de gestiune

Din categoria cheltuielilor iniiale cea mai mare pondere o reprezint cheltuielile cu proiectarea sau cu procurarea aplicaiilor tipizate grupate n cheltuieli cu software-ul i cheltuieli cu achiziia echipamentelor care constituie cheltuielile cu hardware-ul. Analiza evoluiei 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 ealonrii 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

Sisteme informatice de gestiune

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 rndul lor reprezint doar 20% din totalul costului sistemului pe parcursul ntregului ciclu de via. Cheltuielile pentru exploatare i ntreinere sunt n mare msur 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 mrimii cheltuielilor de producie pe elemente primare sau pe articole de calculaie ale costului de producie ca urmare a prelucrrii 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 urmrirea normelor i a consumurilor specifice cu ajutorul tehnicii de calcul. Pentru materialele auxiliare, economiile rezult printr-o mai bun dimensionare a stocurilor i prin urmrirea exact a consumurilor. Estimarea cheltuielilor de transport-aprovizionare se face n raport cu implicaiile 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 86

Sisteme informatice de gestiune

Relaia de calcul este urmtoarea: 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 numrul de lucrtori pentru exploatarea i ntreinerea sistemului informatic; N este numrul lunilor de funcionare 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 lucrrilor din evidena economic n condiiile prelucrrii 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 contribuiei privind asigurrile sociale i fondului de omaj. La suma economiilor enunate mai sus se adaug cele obinute ca urmre a gestiunii raionale a tuturor resurselor financiare. n categoria efectelor economice cantitative se adaug profitul suplimentar. n calcule, punctul de plecare l constituie stabilirea sporului de producie ca urmare a funcionrii sistemului informatic. Relaiile de calcul sunt urmtoarele:
pagina 87

Sisteme informatice de gestiune

Sp = Q1 * N * Kf - Q0 * N + Spe unde: Sp este sporul de producie ca urmare a funcionrii sistemului informatic; Q0,Q1 reprezint valoarea produciei nainte i respectiv dup introducerea sistemului informatic; N este numrul de ani estimat pentru funcionarea sistemului informatic; Kf este coeficientul modificrii valorii mijloacelor de producie n primul an de funcionare a sistemului informatic fa de anul precedent; Spe este sporul efectiv a valorii produciei pe durata exploatrii sistemului informatic. Calculul profitului suplimentar (Ps) datorat introducerii sistemului informatic se face avnd n vedere profitul scontat ce se obine n primul an de aplicare a sistemului informatic (P1) profitul normat (Pn) exprimat n mrimi 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 preul normat i preul efectiv nainte i dup introducerea sistemului informatic. La cheltuielile variabile, dup determinarea mrimii influenei factorilor cantitativi i calitativi, abaterea
pagina 88

Sisteme informatice de gestiune

suplimentar semnific influena introducerii sistemului informatic asupra costului productiei. Pentru cheltuielile fixe, creterea gradului de automatizare a produciei duce la obinerea de economii prin accentuarea tendinei de scdere a cheltuielilor fixe pe unitatea de produs. Pe lng efectele economice cantitative menionate, funcionarea sistemului informatic genereaz efecte indirecte (calitative) cum sunt: mbuntirea formei i a coninutului documentelor tehnice i economice; raionalizarea sistemului de eviden economic; orientarea personalului din compartimentele funcionale de la activiti de rutin spre activiti de concepie; mbuntirea controlului asupra activitii de gestiune economic; transformarea informaiei privind costul produciei n instrument de reglare operativ; creterea posibilitilor de analiz economicofinanciar. Dat fiind amploarea i complexitatea lucrrilor din domeniul informaticii, se impune elaborarea unui buget pentru aceast activitate constituit din: bugetul investitiilor; buget de exploatare; buget de ncasri i cheltuieli. Bugetul informatic asigur estimarea detaliat a efortului i efectelor elaborarii, introducerii i exploatrii sistemului informatic. De asemenea prin buget se realizeaza ealonarea resurselor i a modului lor de utilizare pe etape, perioade i responsabiliti.

pagina 89

Sisteme informatice de gestiune

Estimarea eficienei globale. Eficiena global 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 funcionarea sistemului informatic; Ci sunt cheltuielile iniiale; Ce sunt cheltuielile de exploatare; Ps este profitul suplimentar. Reducerea cheltuililor cu caracter informatic constituie calea principal de cretere a eficienei sistemului informatic. Cu ct durata de recuperare a cheltuielilor cu caracter informatic este mai mic, cu att profitul suplimentar este mai mare ca urmare a faptului c n perioada dintre momentul recuperrii cheltuielilor i abandonarea folosirii sistemului informatic, economiile se transform n profit. Eficiena global crete i ca urmare a prelungirii duratei de via a sistemului informatic. Din punct de vedere organizatoric, eficiena sistemului informatic se poate determina cu ajutorul indicatorul "entropia informaional" (H) prin care se msoar gradul de nedeterminare pe care l nltur informaiile din sistem. Diferena dintre entropia informaional calculat nainte i dup introducerea
pagina 90

Sisteme informatice de gestiune

sistemului informatic, semnific, n cifre absolute, creterea gradului de organizare a ntrepriderii. Eficiena global a unui sistem informatic trebuie apreciat i prin prisma implicaiilor introducerii prelucrrii electronice a datelor asupra conducerii: previziunea strilor i a funcionrii sistemului economic capt determinri realiste ca urmare a elaborrii i a folosii unor modele adecvate; organizarea sistemului economic comport mbuntiri substaniale prin raionalizarea structurii organizatorice i prin posibilitatea integrrii metodelor de conducere previzionar; deciziile primesc noi determinri calitative prin sporirea gradului de obiectivitate; coordonarea activitilor se bazeaz pe informaii necesare reglrii funcionrii sistemului economic la diverse nivele; se asigur controlul prin informarea operativ i oportun asupra dereglrilor care apar n funcionarea organismului economic. Eficiena sistemului informatic se exprim i prin prisma timpului mediu de rspuns. Timpul mediu de rspuns este diferena, n uniti de timp, dintre momentul punerii la dispoziia utilizatorului a unei informaii i momentul cererii informaiei respective. Aprecierea eficienei economice cu ajutorul timpului mediu de rspuns se realizeaz cu ajutorul coeficienilor: Kt = tm0 /tm1 i Kc = Ct1 / Ct0
pagina 91

Sisteme informatice de gestiune

n care: reprezint timpii medii de munc necesari tm0,tm1 nainte i dup introducerea sistemului informatic; reprezint costurile totale nainte i dup Ct0,Ct1 introducerea sistemului informatic. Eficiena global a sistemului informatic se estimeaz prin raportul Eg=Kc / Kt care exprim corelaia 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 concepie n domeniul informaticii este, n primul rnd, o lucrare de creaie n domeniul conducerii, incluznd problematica perfecionrii mecanismului economico-financiar i a interaciunilor micro i macro economice. Activitile de informatic sunt menite s asigure condiii de cretere a produciei prin reflectarea n sistemul informatic, a factorilor de influen asupra rezultatelor financiare ale ntreprinderii. Estimarea eficienei economice a sistemului informatic, avnd n vedere implicaiile complexe ale realizrii i exploatrii componentelor informatice, atest faptul c sistemul informatic concur la promovarea eficienei economice n toate sectoarele de activitate prin creterea efectelor utile i concentrarea efortului asupra aciunilor de concepie i de conducere a ntreprinderii.

pagina 92

Sisteme informatice de gestiune

4.2.3. Proiectarea tehnic. Este etapa n care se definitiveaz mijloacele tehnice necesare (echipamente, programe, proceduri manuale....) prin care fluxul informaional 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 gsite incomplete, astfel c vor fi necesare iteraii i corecii care pot afecta soluia propus din puct de vedere tehnologic, economic sau operaional. n aceast etap obiectivul principal l reprezint elaborarea componentelor funcionale detaliate ale sistemului i a specificaiilor de definire a programelor. Sarcina activitilor din aceast etap ce se desfaoar la nivelul subsistemelor sau chiar al aplicaiilor revine integral analitilor de sistem. Activitile desfurate n aceast etap sunt: proiectarea funcional detaliat pe componente i a legturilor dintre acestea; stabilirea cerinelor i a condiiilor tehnice de realizare a programelor; elaborarea programelor de lucru pentru etapa urmtoare i stabilirea resurselor necesare. Activitile de proiectare tehnic au ca obiectiv materializarea concepiei sistemului informnatic prin proiectarea funcional amanunit a componentelor sistemului i a legturilor dintre componente. Pe baza definirii complete i precise a sistemului informatic din etapele precedente, n etapa de proiectare tehnic sunt concepute specificaiile de realizare pe compnnente
pagina 93

Sisteme informatice de gestiune

(subsistem, aplicaie). Proiectul tehnic rezultat din desfurarea activitilor etapei, pentru o component, constituie baza programrii i a implementrii componentei respective. Plecnd de la ieirile informaionale dorite de utilizator, sunt elaborate modelele de obinere a ieirilor din intrrile disponibile prin definirea coleciilor de date i a procedurilor de tratare a datelor din colecii. Aceste activiti urmresc definirea detaliat a tehnologiei de prelucrare a datelor. n elaborarea tehnologiei de prelucrare a datelor, o deosebit atenie trebuie acordat proiectrii fluxului tratrii datelor urmrind ca, prin colecile de date i fluxul prelucrrilor s se reflecte fidel realitatea. De asemenea, prezint interes major verificarea funcionalitii componentelor proiectate sub aspectul completitudinii i al corectitudinii operaiilor de tratare a datelor. Perfornanele sistemului informatic sunt determinate, n mare msur, de metodele de organizeare a datelor. Modalitile de constituire a coleciilor de date sunt determinante asupra prelucrrilor, n timp ce organizarea coleciilor de date este condiionat la rndul ei de definirea fluxului tehnologic al datelor. n organizarea datelor sunt determinante: studiile pentru delimitarea ariei i a legturilor externe ale sistemului informatic, modelele de obinere a ieirilor din intrri, volumul datelor de prelucrat, cerinele de informare ale conducerii. Metodelele utilizate n organizarea datelor sunt : metoda fiierelor independente, metoda bazei de date. Metoda fiierelor independente const n crearea de fiiere pe suport accesibil prelucrrii automate a datelor, pentru nmagazinarea datelor prelucrate n
pagina 94

Sisteme informatice de gestiune

cadrul fiecrei componente a sistemului informatic. Un fiier este constituit dintr-o submulime de date omogene relative la o clas de elemente a sistemului informaional. (ex. fiierul de stocuri din aplicaia de gestiunea materialelor). n general pentru fiecare entitate distinct a sistemului informaional (materiale, produse, personal, etc.) se constiuie fiiere cu caracter permanent care reflect starea elementelor la un moment dat. Operaiile curente din sistemul economic constituie tranzacii i sunt reflectate n fiiere temporare. (ex:intrri i ieiri de materiale). Prin aplicarea datelor operaionale coninute n fiierele temporare asupra datelor de structur din fiierele permanente rezult ieirile informaionale scontate i se asigur actualizarea fiierelor permanente. n urma actualizrilor fiierele permanente vor cuprinde starea entitilor "la zi". Fiiere permanente (cartoteci, registre cataloage etc.) i fiiere temporare (centralizatoare, jurnale ...) sunt utilizate i n condiiile prelucrrii manuale a datelor. Metoda fiierelor independente asigur rapiditate n organizarea datelor i a prelucrrilor. n acelai timp efortul de definire complet i corect a sistemului informatic este mai redus prin proiectarea tehnic detaliat a fiecrei componente i integrarea ulterioar a componentelor proiectate n sistemul informatic. Aceast metod este frecvent utilizat n practic pentru probleme de mici dimensiuni. Creterea complexitii sistemului duce la creterea numrului de fiiere necesare ceea ce genereaz dificulti sporite de ntreinere. Utilizarea de fiiere independente conduce la o flexibilitate redus a sistemului informatic, modificarea structurii fiierelor implicnd refacerea programelor care le utilizeaz. Prin
pagina 95

Sisteme informatice de gestiune

duplicarea datelor n mai multe fiiere se genereaz redundane informaionale, utilizarea neraional a suporilor de informaie i dificulti n actualizarea i controlul datelor. Pornind de la aceste neajunsuri constatate la organizarea datelor n fiierelor independente se poate folosi ca alternativa metoda bazelor de date. Datele din sistemul informatic sunt organizate n colecii care se numesc baze de date i care au o serie de proprieti i caracteristici ce vor fi artate ulterior. Trecerea de la fiierele independente ctre bazele de date s-a fcut n timp prin mai multe etape: fiecare program de calcul utiliza date i fiiere specifice, proprii pentru obinerea rezultatelor dorite. (metoda fiierelor independente). mai multe programe folosite n rezolvarea unor probleme similare, utilizau date i fiiere comune, grupate n colecii mai mari specifice domeniului respectiv. toate programele utilizate folosesc o colecie unic de date, o aa zis "baz de date" n care sunt incluse toate datele necesare . Necesitatea unor mari baze de date comune a fost simit nu numai de fabricanii de calculatoare i de proiectanii de sisteme informatice, ci i de utilizatorii sistemelor elaborate. Toi au constatat c n sistemele de o anumit mrime, n care se lucreaz cu volume mari de date, este nevoie s se gseasc o serie de modaliti, 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 96

Sisteme informatice de gestiune

se pot obine informaii uniforme, att temporal ct i fizic. Se evit actualizarile pariale a acelorai date n fiiere diferite. Utilizarea acelorai date n mai multe activiti. Avnd un sistem unitar pentru definirea i regsirea datelor, implementarea unor noi programe se face relativ uor. Procedurile folosite pe msura construirii i dezvoltrii sistemului fiind ct 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 mna unui singur grup coordonator (denumit n general administrator al bazei de date). Independena datelor faa de programe i suporii fizici de memorare genereaz creterea calitii i fiabilitii sistemului informatic.

Deoarece nu exist o definiie general acceptat, vom denumi o baz de date "un absamblu unitar organizat i structurat de date a crui gestionare se face printr-un sistem specializat denumit sistem pentru gestionarea bazelor de date (SGBD)". Prin gestionarea bazelor de date se ntelege ndeplinirea unor funcii 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 prelucrrile efectuate asupra datelor din baza de date,
pagina 97

Sisteme informatice de gestiune

procedurile automate i neautomate suplimentare necesare pentru gestionarea datelor, n afara celor din SGBD, reprezint BANCA DE DATE. n concepia modern de realizare a sistemelor informatice "banca de date" devine subsitemul central, prin el realizndu-se principalele legturi dintre majoritatea celorlalte subsisteme i aplicaii n primul rnd 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 primete rspuns la cererile de informaii pe care le face direct pentru el sau pentru alte persoane. Sunt mai multe categorii de utilizatori: utilizatorul profesionist care pentru a primi rspunsurile solicitate scrie programe, deci are cunotine de programare; utilizatorul nespecialist, care pentru formularea unor ntrebri, scrie o serie de comenzi sau instruciuni relativ simple, dar pentru a cror utilizare are nevoie de un anumit instructaj (cteva zile); utilizatorul nespecialist, de cele mai multe ori un conductor, care nu trebuie s fac dect nite operaii elementare pentru a obine informaiile dorite (utilizatori "press-button"). Administratorul bazei de date este o funcie absolut necesar pentru buna funcionare a SGBD-ului. Se constat c administratorul bazei de date este necesar totdeauna n cadrul sistemelor informatice chiar cnd nu folosim conceptul de baz de date. El este reprezentat de o persoan sau un grup de persoane care controleaz
pagina 98

Sisteme informatice de gestiune

i coordoneaz modul de introducere a datelor, modificrile ce li se aduc i accesul la ele. Administratorul trebuie s acorde o deosebit atenie factorilor care afecteaz memorarea i regsirea datelor i de aceea are nevoie de cunotine aprofundate privind datele necesare n cadrul organizaiei 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 combinaie de echipamente de calcul i de programe care asigur accesul la date conform instruciunilor primite de la utilizatori i de la administrator. n acest scop gestionarul trebuie s aib o interfa cu toate limbajele de programare convenionale admise de SGBD-ul respectiv. Gestionarul ndeplinete unele funcii care n sistemele anterioare erau ndeplinite de compilatoare, asambloare, editoare de legturi, programe utilitare, etc.. Gestionarul formeaz un fel de grani ntre programele de aplicaie i mecanismele de acces la date. Gestionarul interpreteaz cererile de date "logice" ale diverilor utilizatori i cu ajutorul mecanismelor sale de acces extrage i transfer datele solicitate de acetia. Utilizatorul nu tie cum i unde sunt memorate datele. Se spune c tot acest proces este "transparent" utilizatorului, n sensul c este parcurs fr a fi cunoscut de el n mod intim, ci numai n principiu. Prin metoda bazei de date se urmrete organizarea datelor din sistem astfel nct datele memorate pe suport magnetic de mare capacitate s rspund necesitilor de prelucrare i utilizare ale tuturor componentelor sistemului informatic i ale tuturor utilizatorilor. Respectarea principiilor privind unicitatea datelor, independena datelor, consultarea concurent a datelor necesit efectuarea analizei i
pagina 99

Sisteme informatice de gestiune

proiectrii sistemului informaional prin abordare global i structurarea lui detaliat. Activitile ce ar trebui realizate pentru determinarea specificaiei logice de definire a bazei de date sunt: 1. Trecerea n revist a tuturor cerinelor de informare necesare pentru rezolvarea diverselor probleme. Cu acest prilej se va stabili o ordine de prioritate n nlocuirea subsistemelor i lucrrilor 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 cerinelor de informare cu stabilirea legturilor informaionale 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 ntocmete pe baza rezultatelor obinute n activitile anterioare, specificaia pentru baza de date, care este o documentaie ce cuprinde: datele i structurile de date propuse a fi incluse n baza de date; o schem care s reprezinte legturile informaionale dintre subsisteme i aplicaii; schema cu structurile logice de date i legturile dintre ele; restriciile hardware i software avute n vedere; cerinele suplimentare pentru SGBD-ul care urmeaz s fie utilizat cum ar fi: volumul intrrilor, al ieirilor, timpii de rspuns solicitai, principalele prelucrri, etc. n funcie de datele de memorat i de relaiile dintre ele ntr-o baz de date pot s apar urmtoarele tipuri de structuri:
pagina 100

Sisteme informatice de gestiune

structura punctual pentru entiti independente; structura ierarhic liniar pentru entiti cu relaii liniare ntre ele; structura ierarhic arborescent pentru descrierea relaiilor dintre entiti de tipul un tat are mai muli fii; structura de tip reea pentru entiti cu relaii complexe ntre ele, rezultat prin generalizarea structurilor ierarhice liniare i arborescente; structura relaional cnd datele nu mai sunt privite ca nregistrri ci ca relaii. Buna funcionare a unui sistem informatic lucrnd cu conceptul de baza de date depinde n mare msur de modul cum se proiecteaz aceast baz de date. Alegerea variantei de proiectare a circuitului informaional este condiionat de modul n care aceasta asigur funcionalitatea componentei respective. Verificarea funcionalitii necesit stabilirea posibilitilor de obinere a datelor de ieire din datele de intrare ale componentei proiectate. Descrierea condiiilor logice i a regulilor de obinere a datelor de ieire 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 uor de citit. Plecnd de la ideea c orice operaie sau ansamblu de operaii poate fi condiionat sau necondiionat, tehnica tabelelor de decizii d o form tabelara procesului de prelucrare a datelor. O tabel de decizii este constituit din patru pri (cadrane): 1. condiii (criterii) pentru luarea deciziilor (C1; C2;...Cm);
pagina 101

Sisteme informatice de gestiune

2. intrri ale condiiilor (IC); combinaii ale intrrilor posibile redau reguli n luarea deciziilor (R); 3. decizii (aciuni) posibile (D1,D2,....Dp); succesiunea vertical a denumirii deciziilor indic ordinea n care urmeaz a fi executate deciziile; 4. intrrile deciziilor (ID) prin care se specific ce decizii urmeaz a fi luate pentru fiecare regul. CADRANUL I (condiii) CADRANUL III (decizii) CADRANUL II (intrri ale condiiilor) CADRANUL IV (intrri ale deciziilor)

Figura 4.7. Cadranele unei tabele de decizii Tabela de decizii descrie toate variantele posibile ale valorilor condiiilor i deciziile corespunztoare fiecrei combinaii a acestor valori n soluionarea unei probleme. Citirea tabelei de decizii se face de sus n jos astfel: "dac se realizeaz condiia C1 i dac se realizeaz condiia C2 i dac ... atunci se ia decizia Dk". R1 Se solicta mat. Da X de cal. I Depozitul Da dispune de R2 Da Nu R3 Da Nu R4 Da Nu R5 Nu R6 Nu Da R7 Nu Da R8 Nu Nu

C1 C2

pagina 102

Sisteme informatice de gestiune

C3

C4

D1 D2 D3

D4

mat. X de cal I Depozitul dispune de mat. X de calit. II n cantitate Q Solicitantul accepta schimbarea calitii Elibereaza mat. * X de calit. I n cant. Q Elibereaz mat. X de calit. II n cant. Q Emite comanda de aprov. pt. mat. X de calit. I Emite comanda de aprov. pt. mat. X de calit. II

Da

Da

Nu

Da

Nu

Nu

Nu

Da

Nu

Da

Nu

* * * * *

Figura 4.8. Tabel de decizii n funcie de valorile ntlnite pentru intrrile condiiilor tabelele de decizii pot fi: a) cu intrri limitate; cnd intrrile condiiilor sunt explicitate numai prin valori DA sau NU (0 sau 1); b) cu intrri extinse; cnd intrrile fiecrei condiii ale unei tabele de decizii sunt explicitate prin mai multe valori (0, 1, 2,...);
pagina 103

Sisteme informatice de gestiune

c) cu intrri mixte; cnd din necesitile analizei problemei rezult condiii cu intrri explicitate, fie prin valori DA sau NU fie prin mai mult de dou valori.

pagina 104

Sisteme informatice de gestiune

4.2.4. Elaborarea programelor. Dup ce specificaiile de realizare au fost ntocmite i aprobate, ele vor fi repartizate diverselor grupe de specialiti care au responsabilitatea s le execute i ulterior s le asambleze. Etapa este consacrat elaborrii programelor i procedurilor manuale, aferente componentelor sistemului informatic, precum i testrii componentelor. n funcie de necesitile problemei dar i de cunotinele proiectanilor, n aceast etap se pot folosi tehnici de programare ca: programarea modular; programarea structurat; programarea orientat pe obiecte; sau , eventual soluii hibride conform nivelului de stpnire a tehnicilor respective. Programarea modular. Operaia de mprire a unei probleme complexe, conceput din punct de vedere logic ca un tot unitar, nu este uoar pentru c ntotdeauna trebuie avut n vedere ca prile n care a fost descompus ntregul s nu-i schimbe scopul iniial i totodat s permit, relativ usor, reconstituirea ntregului atunci cnd este necesar. n acest sens trebuie respectate dou reguli: fiecare component trebuie s ndeplineasc o anumit funcie bine precizat n cadrul ntregului; ntre componente este necesar s se stabileasc foarte exact legturile, astfel ca fiecare parte s-i poat realiza relativ independent funcia specificat i n acelai timp s poat contribui la funciile generale ale ntregului.
pagina 105

Sisteme informatice de gestiune

Prin modularitate nelegem proprietatea sau posibilitatea ca un proces s poat fi descompus n pari componente, cu legturi bine stabilite ntre ele, astfel ca obiectivul general al procesului s poat fi ct mai eficient realizat. Una din definiiile date noiunii generale de modularitate aparine lui Russel Armstong, care considera c un sistem este modular atunci cnd este realizat dintr-o mulime de elemente creia i este asociat o lege de structur. A gsi legea de structur nseamn a prospecta interfaa dintre module. Dup acelai autor, proiectarea interfeei dintre module este simplificat dac modulele au fost concepute astfel nct s aib o funcionalitate 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 numr mare de utilizatori, rspndii uneori pe zone ntinse; cerinele utilizatorilor sunt mereu schimbate i completate. innd 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 - aplicaie. a) Sistemul informatic trebuie s urmreasc i s contribuie la realizarea obiectivelor generale ale ntreprinderii, fixate pe o perioad lung de timp. Deoarece obiectivele i restriciile generale se pot
pagina 106

Sisteme informatice de gestiune

schimba n timpul realizrii 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 dect cea prevazut pentru realizarea i implementarea sistemului informatic, pot aparea neconcordane imprevizibile, care pot conduce la efecte negative. b) Subsistemul corespunde, de regul, unor obiective derivate din cele generale, rezultate prin detalierea acestora. Exist unele tendine de mprire a sistemelor informatice n subsisteme dup structura ierarhic i organizatoric astfel: strategic tactic operativ, sau dup precizarea funciilor sale: producie comercial financiar-contabil personal cercetare- dezvoltare. ntre aceste componente (subsisteme) trebuie s existe legturi (interfee) clare, ct mai puine i ct mai rigide, n sensul c odat stabilite s nu mai fie practic modificate. c) Aplicaia, ca unitate component a subsistemului, contribuie n general la satisfacerea unor obiective specifice i se dezvolt de obicei la nivelul unor compartimente sau activiti din cadrul ntreprinderii. n structura sistemului pe trei nivele aplicaia se gsete pe ultimul nivel, i construirea sistemului informatic se face treptat prin realizarea de aplicaii asamblate n cadrul nivelurilor superioare.
pagina 107

Sisteme informatice de gestiune

Adncind nivelul de detaliere al sistemului informatic putem aduga nc dou nivele: d) program; e) modul de program. d) Aplicaia la rndul ei este constituit dintr-o serie de programe i proceduri manuale legate ntre ele i care ndeplinesc funciile cerute. e) La rndul lor programele sunt de cele mai multe ori divizate n mai multe pri, numite "module program" independente din punct de vedere logic. Modulele sunt compuse din instruciuni scrise ntrun limbaj de programare. La nivelul programelor modularitatea se mai numete i micro modularitate. Corelarea modulelor sau cuplarea modulelor este o msura a independenei modulelor, i poate avea mai multe forme: corelarea extern, cnd modulele utilizeaz aceleai date globale ale sistemului; corelarea prin control, cnd unul din module controleaz execuia celorlalte n mod explicit, prin chei de control sau variabile de control a cror valoare indic modul de continuare a execuiei; corelarea intern sau prin coninut, cnd un modul refer direct alt modul; corelarea prin date, cnd la apelarea unui modul de ctre altul toate datele de intrare sau de ieire ale modulului apelat sunt comunicate sub form de parametrii. Un alt element caracteristic este ponderea sau tria modulelor care reflect modul de formare i coninutul modulului. Exist mai multe posibiliti de divizare a programelor n module i anume:
pagina 108

Sisteme informatice de gestiune

divizarea ntmpltoare, care d tria cea mai slab modulelor cci programul este mprit arbitrar n module; divizarea logic, are ca rezultat module ce efectueaz o funcie la fiecare apelare; divizarea clasic, prin care modulul efectueaz mai multe funcii necorelate ntre ele prin date; divizarea prin comunicare, cnd modulele efectueaz mai multe funcii corelate prin date; divizarea funcional, cnd modulele efectueaz o singur funcie care le este specific.

Modularizarea este una din sarcinile principale ale proiectanilor de sisteme informatice i este n cele mai multe cazuri, o operaie complicat de care depinde n mare msur modul cum va funciona n final sistemul. n acest scop, n cadrul proiectelor mari, pe baza unor experiene anterioare, adaptate la specificul respectiv, se elaboreaz reguli i chiar norme care trebuie avute n vedere la mprirea 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 funcie unic, lucru extrem de avantajos atunci cnd se fac modificri; s fie complet; s aib ct mai puine interfee cu ale module; s permit o nelegere uoar a problemelor pe care le rezolv; s se poat ncadra n diversele tipuri de modularitate ale sistemului.

Avantaje ale modularizrii:


pagina 109

Sisteme informatice de gestiune

1) Posibilitatea divizrii ntregului n pri mai simple i mai uor de realizat. 2) Independena modulelor permite elaborarea i testarea separat a acestora. 3) Fiecare modul poate fi realizat prin tehnicile (limbajele) cele mai adecvate funciei pe care o ndeplinete. 4) Posibilitatea construiri a unei biblioteci de module testate (module standard) disponibile tuturor proiectanilor. 5) Simplificarea ntreinerii sistemului (programului). 6) Permite abordarea de la simplu la complex i permite o ncrcare echilibrat a fiecarui membru din echipa de proiectare. Dezavantajele modularizarii: 1) Muli proiectani nu neleg modularizarea sau nu se pot acomoda cu ea. 2) Modularitatea cere eforturi suplimentare n faza de proiectare. 3) Proiectanii nu cunosc problema n ansamblu ci numai pari ale ei. 4) Concepia modular duce la realizarea de programe care ncarc suplimentar unitatea central a calculatorului cu funciile de dispecerizare i comunicare ntre module. Noiunea de modularitate este nsoit aproape ntotdeauna de un alt concept, cel de "top-down". "Topdown" nseamn "de sus n jos" sau "descendent". n linii mari el ar putea fi explicat astfel: n procesul general de cunoatere se ncepe cu aspectul general, "n mare" al fenomenului, dup care, treptat, acesta se detaliaz, se cunoate n profunzime, pn la un anumit nivel, considerat suficient pentru scopul urmrit. Dac
pagina 110

Sisteme informatice de gestiune

modularizarea nseamn procesul de descompunere a unui ntreg n pri componente, metoda cea mai obinuit, pentru ca mprirea s fie corect fcut, este tocmai cea "top-dovn". Trgnd o concluzie mai general, se poate spune c n orice fel de proces de cunoatere 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 preocupri pentru scderea raportului cost/ performan, prin aplicarea unor principii de structurare att n fazele de proiectatre ct 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 rnd la: Identificarea funciilor necesare pentru realizarea produsului, analog cu determinarea prilor componente ale unui produs industrial. Descompunerea consecvent descendent (top-down) n procesul de identificare a funciilor componente ale proiectului. Introducnd noiunea de "nivel al functiilor" (Nf) i punnd convenional nivelul rdcinii structurii Nf=0, putem defini nivelul unei funcii oarecare ca fiind egal cu nivelul funciei din care descinde plus unu. Funciile cu nivelul cel mai ridicat se mai numesc i "primitive" ale structurii iar cea cu nivelul zero se numete rdcina structurii. Realizarea modular a produsului, presupune izolarea funciilor gsite n faza de identificare, apoi determinarea interfeelor dintre module.
pagina 111

Sisteme informatice de gestiune

Normalizarea primitivelor (primitivele structurii).

structurilor

funcionale

La un anumit nivel de descompunere n ierarhia funciilor unei structuri se gsesc algoritmii de rezolvare ai subproblemelor. Pentru realizarea oricrui algoritm este suficient utilizarea unui set restrns de structuri funcionale 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 programrii structurate prezentm o serie de definiii posibile aprute pe o perioad mai lung de timp, cu meniunea c cele din anii de nceput ai conceptului prezint mai mult constatri de circumstan i au o not uor ironic: 1. Este o ntoarcere la bun-simt. 2. Este metod general dup care programeaz cei mai buni programatori. 3. Este programarea fr GO TO. 4. Este procesul prin care se controleaz numrul de interaciuni dintre un proces i contextul su, astfel nct numrul de interaciuni s fie o funcie liniar depinznd de civa 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 nct s poat fi reprezentate prin iterarea i compunerea unui numr mic de structuri logice de control standard. 7. Este o manier de a organiza i codifica programe astfel nct s fie ct mai uor de neles i de modificat.
pagina 112

Sisteme informatice de gestiune

8. Scopul programrii structurate este de a controla complexitatea prin teorie i disciplin. 9. Programarea structurat poate fi caracterizat nu prin absena instruciunii GO TO ci prin prezena structurii. 10. O funcie major a structurii programelor este de a face posibil demonstrarea corectitudinii lor. 11. Programarea structurat nu este o soluie total, ea const, de fapt, n folosirea unor notaii formale pentru a gndi ordonat. 12. Procesul de organizare a gndirii care duce la o expresie inteligibil a procesului de calcul ntr-un timp rezonabil. 13. Arta simplitii. Sintetiznd se poate ajunge la urmtoarea definiie: "Programarea structurat const dintr-o mulime de restricii i reguli de programare care foreaz programul s urmeze o form strns, n acest fel eliminndu-se muli din factorii care conduc la erori i care complic activitatea de testare i ntreinere." Examinarea structurii interne a unui program, evideniaz existenta unei structuri ierarhice ntre componentele unui program, fiecare component fiind coordonat de componenta de nivel superior i coordonnd 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 nct fiecare nivel de prelucrare s reprezinte o detaliere a nivelelor precedente. Pentru definirea structurii nestedlogic a unui program se utilizeaz ca instrument de lucru diagrama de structur. Blocurile nestedlogic folosite n diagrama de structur sunt:
pagina 113

Sisteme informatice de gestiune

SECVENA care marcheaz grupul de enunuri care se execut n ordinea n care au fost scrise. SELECIA care marcheaz separarea enunurilor n dou grupe i executarea unei sau alteia din aceste grupe n funcie de o anumit condiie. ITERAIA care marcheaz un grup de enunuri cu execuie repetat de un numr de ori (inclusiv repetarea de zero ori ceea ce echivaleaz cu eliminarea grupului de enunuri).

Regulile de structurare ale blocurilor sunt: punctul de intrare ntr-un bloc este unic; punctul de ieire dintr-un bloc este unic; blocul iterativ ncepe prelucrarea prin testarea condiiei de ieire din ciclu; un bloc poate conine orice combinaie de blocuri care satisfac condiiile 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 urmtoarelor reguli: nivelele de detaliere se parcurg de sus n jos; fiecare nivel reprezint o detaliere a nivelului precedent; blocurile situate pe un acelai nivel ierarhic se parcurg de la stnga la dreapta; terminarea parcurgerii unui nivel presupune parcurgerea urmtorului bloc din nivelul anterior. Regulile de citire a diagramei de structur sunt:
pagina 114

Sisteme informatice de gestiune

Citirea operaiei de trecere de la un nivel superior ctre un nivel inferior se face utiliznd expresia "const din". Citirea operaiei de trecere de la un bloc la alt bloc de pe acelai nivel se face utiliznd expresia "urmat de". Citirea operaiei de trecere de la un nivel inferior ctre un nivel superior se face prin trecerea la urmtorul bloc al nivelului superior utiliznd expresia "urmat de". Un cercule marcat n colul din drapta sus al unui bloc identific un bloc opional i se citete utiliznd expresia "sau". Un asterisc marcat n colul din dreapta sus al unui bloc identific un bloc cu execuie repetat i se citete utiliznd expresia "mai multe".

Reprezentarea blocurilor nested-logic utilizate n diagrama de structura i corespondena lor cu reprezentarea din schemele logice clasice este prezentat in figura 4.9. TEOREMA DE STRUCTUR: Oricare ar fi schema logic S aparinnd mulimii schemelor logice clasice i care reprezint structura logic a unui proces de prelucrare, exist cel puin o transformare T pentru care S'= T(S) astfel nct: 1. S' este echivalent cu S; 2. S' este o schem cu structur nested-logic.

pagina 115

Sisteme informatice de gestiune

Figura 4.9. Structuri elementare n programarea structurat

Programarea orientata pe obiecte. Pentru problemele de natur economic, n limbajele de programare clasice, cea mai mare parte a ateniei era acordat descrieirii structurilor de date deoarece, practic, prelucrrile 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 creterea complexitii programelor, a aprut necesitatea unei organizri riguroase a muncii. Ca o etap superioar capabil s rezolve n bun msur problemele ivite, s-a impus programarea structurat. De-a lungul anilor, n special datorit
pagina 116

Sisteme informatice de gestiune

creterii dimensiunii produselor software, i acest instrument a devenit la rndu-i depit. Sporirea complexitii programelor aducea dup sine dificulti reale legate de ntreinerea unor programe mamut. Cu alte cuvinte, dei preul produselor era n cretere, calitatea lor tindea s scad. n cutarea unei soluii care s scoat informatica din situaia 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 cutrilor, au aprut limbaje avnd la baz noiunea de "cadru" ("frame") i cele care pornesc de la ideea de "aciune", ambele noiunii folosite n inteligena artificial. Prima categorie implementeaz "operaii" asupra unor "modele de entiti" iar cea de a doua susine faptul c "obiectele nu sunt simple elemente pasive asupra crora se fac prelucrri, ci, dimpotriv, menirea obiectelor rezid n a activa prelucrrile ce le vor suporta ele nsele. Dei teoria programrii orientate pe obiecte era bine fundamentat de peste 20 de ani, ideea nu a prins cu adevrat dect n ultimii ani. Programarea pe obiecte n loc s separe iremediabil datele de cod nu face altceva dect s contopeasc cele dou elemente. Primele limbaje cu adevrat 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 penetrrii pe pia, a fost nsui faptul c au aprut ca limbaje de sine stttoare, avnd o rspndire relativ redus. Din acest motiv puini programatori erau dispui s abandoneze limbajele consacrate n acele momente, doar de dragul de a lucra obiectual. O bun perioad de timp metoda programrii obiectuale a fost uitat.
pagina 117

Sisteme informatice de gestiune

n anii '80 n urma acceptrii 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 natere prima versiune a noului limbaj C++. Aproape imediat apar i partizanii fanatici ai OOP-ului aflat acum la a doua tineree. Termenul de OOP provine din "Object Oriented Programming" care desemneaz disciplina programrii obiectuale sau orientat-obiect. Profitnd deci de marea popularitate n rndul soft-itilor i de multitudinea domeniilor de aplicaie (de la grafica interactiv la exploatarea reelelor de calculatoare i chiar pn la proiectarea compilatoarelor) moftul devine mod i moda certitudine. Acest succes extraordinar s-a datorat faptului c limbajul C++ nu face nimic altceva dect s-i dea un nou avnt unuia dintre cele mai la moda limbaje ale momentului "C". OOP introduce conceptul de INCAPSULARE prin care se ating urmtoarele obiective: facilitatea deosebit de localizare a erorilor modularizarea problemei de rezolvat. Notiunea de clas conine declaraii de variabile i declaraii de funcii care opereaz asupra variabilelor. Funciile se numesc funcii membru sau metode iar variabilele variabile membru. Cu ajutorul claselor, un programator si poate defini orice tip de dat dorit, mpreun cu setul de operaii. Toate aceste informatii sunt ncapsulate ntr-o clas. Astfel prin clas vom nelege 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 instaniere (o realizare) a unei clase. Prin intermediul claselor se pot separa informaiile de implementare (mecanism intern) de cele de utilizare (mecanism extern).
pagina 118

Sisteme informatice de gestiune

Un alt termen introdus de OOP, este motenirea. n urma definirii unei clase, cu un minim de efort i timp se pot preciza seturi de clase asemnatoare, avnd totui o trstur distinctiv. Avnd o clas B putem defini o alt clas D care s moteneasc sau s preia toate caracteristicile clasei B la care s se poat aduga altele noi, proprii doar acesteia din urm. Prima clas se va numi "clas de baz" iar cea de-a doua "clas derivat". Moetenirea st la baza altor concepte novatoare cum ar fi polimorfismul dar elementul esenial al programarii obiectuale rmne "ncapsularea". Polimorfismul const n faptul c ntr-o ierarhie de clase obinute prin motenire, o metod poate avea forme diferite de la un nivel la altul, specifice respectivului nivel din ierarhie. Aa cum n lumea vie hrnirea este universal valabil ea deosebindu-se de la o clas la alta de vieti, tot aa i n cazul OOP metoda poate avea forme diferite de la o clas la alta. n momentul de fa piaa informatic este invadat de biblioteci i colecii de clase. Menirea lor este de a permite un coeficient ct mai ridicat de reutilizare a codului scris. Pe de alt parte, pornind de la aceste clase, utilizatorul poate crea prin motenire alte clase, care s-l ajute s-i rezolve problema n mod optim. n plus, programatorul are garania folosirii unor proceduri scurte, inteligibile i nu n ultimul rnd corecte. Un alt domeniu de utilizare a bibliotecilor de clase este cel al realizrii prototipurilor unor produse software. Prin prototip se nelege un program funcional, 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 productorului, clientul poate avea o imagine destul de
pagina 119

Sisteme informatice de gestiune

clar asupra produsului final. Pentru o aplicaie oarecare prototipul nu trebuie s conin algoritmul optim, clientul urmnd s poat nlocui doar acele module care sunt deficitare din anumite puncte de vedere.

pagina 120

Sisteme informatice de gestiune

4.2.5. Implementarea, exploatarea i ntreinerea. Implementarea este etapa n care sistemul se testeaz n condiii reale. Etapa ncepe cnd componentele individuale, care au fost testate i acceptate, pot fi asamblate pentru testarea i includerea n sistem pe baza specificaiilor i manualelor elaborate n etapa anterioar. Circuitul informaional existent este nlocuit cu noul circuit prin lansarea n execuie a programelor i verificarea practic a modului de obinere a rezultatelor, acestea constituind activitile de implementare a sistemului informatic. Etapa se consider terminat cnd sistemul este acceptat de beneficiar. Unele activiti pregtitoare ale implementrii pot ncepe nc din etapa precedent. Activitile aferente implementrii sunt urmtoarele: pregtirea implementrii; executarea procedurilor de conversie; testarea n condiii reale; evaluarea rezultatelor obinute i verificarea performanelor sistemului; definitivarea documentaiei.

Etapa de exploatare ncepe cnd informaiile din sistem sunt furnizate n mod curent beneficiarului. n paralel cu exploatarea sistemului se desfoar ntreinerea sistemului. Exploatarea este legat de problemele curente zilnice ale meninerii sistemului n stare de funcionare, n timp ce ntreinerea const n activiti de evaluare periodic legate de modificrile ce trebuiesc fcute pentru a menine sistemul viabil.
pagina 121

Sisteme informatice de gestiune

4.3. Ciclul de abstractizare 4.3.1. Modelul conceptual al datelor Pentru realizarea unui model conceptual al datelor este necesar folosirea unei reprezentri sub forma de text a realitii aa cum a fost ea nteleas de analist. Ea se rezum la descrierea literar ca urmare a analizei, putndu-se deduce din aceasta entitile, asociaiile etc. care vor constitui mai departe modelul conceptual al datelor. Concepte utilizate n MCD a) entitate - este reprezentarea n sistemele informaionale a unui obiect material sau imaterial avnd o existen proprie i conform cu necesitile gestiunii ntreprinderii. n general se utilizeaz un substantiv comun ca nume de entitate, nume ales astfel nct s sublinieze ct mai bine relaia cu componenta din sistem pe care o reprezint. b) realizarea unei entiti - este un element individualizat apartinnd entitii. Spre exemplu informaiile relative la salariatul Popescu sunt o realizare a entitii SALARIAT. c) asociaia - reprezint o relaie ntre entiti. Numrul entitilor care intervin n relaie caracterizeaz dimensiunea asociaiei: asociaii binare ntre dou entiti;
pagina 122

Sisteme informatice de gestiune

asociaii ternare ntre trei entiti; asociaii n-are ntre n entiti. n general se utilizeaz ca nume de asociaie un verb care s sublinieze ct mai bine relaia dintre entiti. Spre exemplu asociaia LUCREAZA permite s se neleag faptul c un SALARIAT lucreaz ntr-o SECTIE.

Figura 4.10. Asociaie d) realizarea unei asociaii - este o asociaie individualizat adic o pereche, triplet, etc. constituit dintr-o singur apariie a fiecrei entiti participante la relaie. Spre exemplu n afirmaia "salariatul Popescu lucraz n departamentul Personal" cuplul Popescu/Personal este o realizare a asociaiei LUCREAZA. e) asociaie reflexiv - este o relaie care exist ntre realizarea unei entiti i o alt realizare a aceleiai entiti. Spre exemplu asociaia INCADRAT este o asociaie reflexiv care traduce faptul c un anumit SALARIAT are posibilitatea de a ncadra (angaja) ali salariai.

pagina 123

Sisteme informatice de gestiune

Figura 4.11. Asociaie reflexiv f) legtura - reprezint o relaie ntre o entitate i o asociaie. Ea este caracterizat prin cardinalitatea sa. Se poate distinge printr-un nume, ceea ce este foarte practic n cazul asociaiilor reflexive. g) cardinalitate - permite s se exprime funcionalitatea i totalitatea sau parialitatea unei relaii: cardinalitatea minimal - este numrul minim de participri ale realizri unei entiti la realizrile unei asociaii; cardinalitatea maximal - este numrul maxim de participri ale realizrii unei entiti la realizrile unei asociaii.

pagina 124

Sisteme informatice de gestiune

Figura 4.12. Cardinalitate Spre exemplu dac se examineaz MCD-ul urmtor:

Figura 4.13. Exemplu cu entiti, asociaie i cardinaliti se poate spune c aceste cardinaliti indicate ntre entitile SALARIAT i asociaia LUCREAZA se traduc astfel: orice salariat lucreaz n cel puin o secie, orice salariat lucreaz n cel mult o secie, adic orice salariat lucreaz ntr-o singur secie. n acelai fel cardinalitile dintre SECTIE i asociaia LUCREAZA se traduc prin: ntr-o secie lucreaz cel
pagina 125

Sisteme informatice de gestiune

puin un salariat i ntr-o secie lucreaz cel mult n salariai, adic mai muli salariai. Se constat c toate cardinalitile 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. Cardinalitile principale sunt constituite din urmtoarele combinaii: 0,1 - niciunul sau unul singur 1,1 - unul i unul singur 0,n - niciunul sau mai muli 1,n - cel puin unul sau mai muli Este posibil s se genereze i alte cardinaliti dect acestea, spre exemplu 0,2 dar n modelul fizic al datelor cardinalitile superioare lui 1 sunt transformate n cardinaliti n. h) informaia - este componenta elementar a sistemelor informaionale. (ex. nume, prenume, cod postal, etc.) i) domeniul - permite s se formalizeze ansamblul valorilor care stau la baza informaiilor. Toate valorile luate de informaii i care sunt transferate entitilor constituie ansamblul valorilor din sistemele informaionale. Exemple: domeniul dobnzilor - numere pozitive cu 7 ntregi i 2 zecimale; domeniul numelor - alfabetic cu majuscule. j) proprietate - este informaia care se ataaz unei entiti sau unei asociaii. Ea poate referi un domeniu
pagina 126

Sisteme informatice de gestiune

deci ea i poate motenii caracteristicile (tip, lungime, list de valori). Numele fiecrei proprieti poate fi nscris n simbolul entitii sau asociaiei atunci cnd acestea sunt purttoare de atribute. Exemplu: entitatea SALARIAT are proprietile marca, nume, prenume, iar asociaia INCADRAT are proprietile data de nceput i data de sfirsit.

Figura 4.14. Proprieti k) identificatorul unei entiti - este constituit din una sau mai multe proprieti particulare ale unei entiti astfel nct la fiecare valoare a identificatorului corespunde o singura realizare a entitii. Toate entitile trebuie s posede un identificator care poate fi compus din una sau mai multe proprieti. Prin convenie proprietile cu rol de identificator sunt subliniate. De exemplu proprietatea MARCA este identificatorul entitii SALARIAT adic poate defini fr ambiguitate fiecare salariat.

pagina 127

Sisteme informatice de gestiune

Figura 4.15. Identificator l) identificatorul unei asociaii - este intotdeauna obinut prin concatenarea indentificatorilor entitilor participante la asociaie. Acest identificator nu figureaz n MCD. m) legatur-identificator. S-a vzut necesitatea ca fiecare entitate s aib un identificator, dar n anumite cazuri acesta nu este suficient. Dac se urmreste MCD-ul urmtor:

Figura 4.16. Legatur identificator

pagina 128

Sisteme informatice de gestiune

se constat c cele dou entiti sunt legate printr-o relaie de compoziie. 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 lucrri s aib acelai cod dac ele aparin unor proiecte diferite, se va putea identifica far ambiguitate o lucrare prin codul su i prin codul proiectului cruia i aparine. n acest caz legtura care pornete de la entitatea elementar este numit LEGATUR-IDENTIFICATOR, i are obligatoriu cardinalitatea 1,1. Pe grafic aceast cardinalitate apare ntre paranteze, difereniindu-se n acest fel de o legatur 1,1 normal. n) legatura de motenire. Motenirea poate fi exprimat ca o legtur particular ntre entiti n acelai timp foarte apropiate dar totui diferite. Datorit acestui concept de entitate general sau mam, se exprim caracteristicile comune mai multor entiti formnd o aceiai familie. Conceptul complementar de entiti specializate, particulare sau fiice ale unei entiti generale exprim caracteristicile proprii fiecrui membru al familiei. Se vorbete de asemenea de legturi generice ntre entiti tip i sub-tip. Toate proprietile definite pentru entitatea general sunt motenite de ctre entitile specializate. n acelai timp toate asociaiile unei entiti generale sunt valabile pentru entitile specializate. Aceast noiune permite mbogirea considerabil a MCD punnd n eviden noiunile de tip i sub-tip n snul unei aceleiai entiti.
pagina 129

Sisteme informatice de gestiune

n plus ea permite utilizatorului s genereze un MFD care ine cont ntr-adevar de specificaiile artate. Se evit astfel, fie redundana informaional fie nlocuirea coloanelor care au valori nule. Fie de exemplu entitatea ANGAJAT, care cuprinde angajaii de gen masculin i pe cei de gen feminin. Se poate reprezenta aceast particularitate prin noiunea de motenire considernd entitile ANGAJAT MASCULIN i ANGAJAT FEMININ ca entiti specializate ale entitii generale ANGAJAT. Reprezentarea const ntr-o legtur cu sageat care pleac din entitatea fiic i punctez entitatea mam. Un simbol n forma de semicerc este desenat n mijlocul legturii i servete ca punct de ntlnire pentru alte legturi venind de la alte entiti fiic.

Figura 4.17. Motenire Reguli de normalizare a MCD Elaborarea unui MCD se realizeaz n mai multe etape, i este adesea supus modificrilor pe parcursul realizrii proiectului informatic. Una din etapele
pagina 130

Sisteme informatice de gestiune

eseniale ale realizarii unui MCD este verificarea modelului aplicnd un numar de reguli numite reguli de normalizare. Se obine n acest fel un modelul cu redundan minima n stocarea datelor. REGULA 1. Toate identificator. entitile trebuie s posede un

REGULA 2. Toate proprietile unei entiti sau unei asociaii trebuie s fie elementare, adic nedecompozabile. REGULA 3. Pentru fiecare realizare a unei entiti sau asociaii, dou proprieti nu pot reprezenta aceiai informaie real, adic nu pot s aib valori repetate pentru o aceiai realizare a entitii sau asociaiei. REGULA 4. Toate proprietile, altele dect 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 proprieti. Dac modelul ndeplinete regulie 1,2 i 3 este n PRIMA FORM NORMAL. Dac ndeplinete i regula 4 modelul este n A DOUA FORM NORMAL. Dac ndeplinete i regula 5 modelul este n A TREIA FORM NORMAL.
pagina 131

Sisteme informatice de gestiune

Exemplu: "Un salariat al unei ntreprinderi, mprit n secii, lucreaz ntr-o singur secie i particip la minim dou proiecte. Fiecare secie are un cod i o denumire." Aceast prezentare se traduce n urmatorul MCD.

Figura 4.18. Model nenormalizat Regulile normalizrii nu sunt respectate, i nu se poate spune nici mcar 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 secie dat nu exist doi salariai avnd acelai nume, se va putea alege ca identificator cuplul COD_SECTIE, NUME. Proprietatea ADRESA se descompune de exemplu n dou proprieti elementare STRADA i ORAS. Repetarea numelui de proiect se va traduce cu ajutorul unei entiti PROIECT i a unei asociaii PARTICIPA. Se obine astfel urmtorul MCD.

pagina 132

Sisteme informatice de gestiune

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 fr ambiguitate fiecare salariat, dar proprietatea DEN_SECTIE nu depinde dect de o parte a identificatorului, proprietatea COD_SECTIE. Pentru a respecta a doua form normal, se adaug entitii SALARIAT o nou proprietate denumit MARCA care identific fr ambiguitate fiecare salariat din ntreprindere, iar DEN_SECTIE depinde direct de MARCA. Se obine urmtorul MCD:

Figura 4.21. Model n a doua form normal


pagina 133

Sisteme informatice de gestiune

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 curnd de proprietatea COD_SECTIE. Dependena de identificator nu este direct ci mai degrab tranzitiv prin intermediul proprietii COD_SECTIE. Pentru a elimina acest inconvenient este suficient s se introduc o nou entitate SECTIE i o asociaie LUCREAZA care arat faptul c un salariat lucreaz ntr-o secie. Se obine urmtorul 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 urmrit atingerea celei de-a treia forme normale pentru a minimiza redundana informaional i n consecin riscurile discordanelor dintre date. Normalizarea este deci un proces prin excelen intelectual, cci bazat pe analiza semantic a proprietilor i plecnd de la un ansamblu amorf de date se obine un model conceptual n a treia form normal.
pagina 134

Sisteme informatice de gestiune

4.3.2. Modelul logic al datelor n timp ce modelul conceptualal al datelor este independent de sistemul de gestiune al fiierelor utilizat, la nivel organizaional trebuiesc integrate soluiile de organizare a datelor astfel nct formalismul entitate/relaie s poat fi transcris ct mai exact, la nivelul fizic, n termenii limbajului de gestiune a datelor ales. Alegerea depinde de tipul software-ului avut la dispoziie, i noul model rezultat (modelul logic al datelor - MLD) trebuie s in cont de posibilitile acestui software fr ns s intre n detaliile tehnice ale metodelor de stocare i de acces specifice urmtorului nivel, nivelul fizic. Alegerea sistemului de gestiune a datelor se poate face ntre fiiere i baze de date. Utilizarea fiierelor const n nmagazinarea pe suport accesibil prelucrrii automate, a datelor prelucrate n cadrul fiecrei componente a sistemului informatic. Un fiier se constituie dintr-o submulime de date relativ omogene relative la o clas de elemente a sistemului informaional. Identificatorul unui fiier este o proprietate aleas astfel nct la fiecare valoare a acestei proprieti s corespund o singur realizare a unui articol din fiier. Articolul dintr-un fiier este o colecie de proprieti care se refer la acelai element. O realizare a articolului reprezint ansamblul proprietilor pentru un articol individualizat. Se pot distinge dou feluri de fiiere: fiiere clasice de tip BASIC, FORTRAN, COBOL etc. fiiere secvenial-indexate multicriteriale tip DBASE.

pagina 135

Sisteme informatice de gestiune

Cu fiierele clasice accesul dup criterii multiple este dificil i sisteme de gestiune a fiierelor ca de exemplu cel din COBOL nu permit dect funcii de adugare, cutare, modificare i tergere. Orice alt operaie rmne n sarcina programatorului. La fiierele secvenial-indexate multicrteriale accesul se face dup mai multe chei, este mult mai uor i sunt oferite mai multe posibiliti de prelucrare. Metoda fiierelor prezint inconveniente majore, idiferent de tipul de fiiere folosit: existena renundanelor; apariia unor probleme de coeren; procedurile de securitate trebuiesc programate; programatorul trebuie s gestioneze el nsui relaiile ntre fiiere programatorul trebuie s cunoasc metodele de stocare i de acces; creterea complexitii sistemului duce la dificulti sporite de ntreinere. Ca urmare a persistenei 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 crui 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; coerena datelor; acces dup criterii multiple;
pagina 136

Sisteme informatice de gestiune

date legate ntre ele conform cu MCD; independena programelor i datelor; securitatea datelor; actualizare i interogarea concurent.

n funcie de datele de memorat i de relaiile dintre ele ntr-o baz de date pot s apar urmtoarele tipuri de structuri: structura arborescent; cnd exist o singur legtur ntre dou entiti ale bazei de date, de la "tat" la "fiu", exploatarea facndu-se fie pe traseul "tat-fii" fie invers "fiu-tat". structura reea; cnd o nregistrare "fiu" poate avea mai multe nregistrri "tat", care permite cutarea n toate direciile pornind de la orice entitate. Trebuie menionat aici modelul CODASYL (Conferance on Data Systems Languages) elaborat la nceputul anilor '70, i ale crui norme sunt respectate de numeroase sisteme de baze de date. structura relaional; cnd entitatea este privit ca o relaie ntre proprieti i nu ca o nregistrare, asigurndu-se o independen total a programelor fa de date. Trecerea de la MCD la MLD se poate face ctre toate tipurile de organizare a datelor, inclusiv ctre organizarea n fiiere clasice, dar mai utilizate sunt MLD CODASYL i MLD relaional. n cele ce urmeaz vom dezvolta trecerea ctre MLD relaional. Modelul logic al datelor utilizeaz concepte ale modelului relaional i presupune dispunerea datelor sub form de tablouri cu dou dimensiuni numite tabele sau relaii. Pentru a facilita nelegerea regulilor de trecere de la MCD la MLD trebuiesc definite urmtoarele concepte:
pagina 137

Sisteme informatice de gestiune

a) tabel. Un tabel corespunde unei entiti sau unei asociaii din MCD i este alctuit din linii i coloane. b) linie. O linie corespunde noiunii de realizare a entitii sau asociaiei. c) coloana. Noiunea de coloan corespunde noiunii de proprietate. d) cheie primar. Noiunea de cheie primar corespunde noiunii 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 evitnd repetiiile. Reguli de trecere de la MCD la MLD REGULA 1. Entitile devin tabele. Proprietile devin coloane de tabele. Identificatorii entitilor devin chei primare ale tabelelor. REGULA 2. Cnd o asociaie binar are o legtur 0,1 sau 1,1 i o alta de cardinalitate 0,n sau 1,n apare o migraie a cheilor entitii 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 proprietile "cod fiscal" (identificator) i "nume beneficiar" primete una sau mai multe facturi caracterizate printr-un "numr factur" (identificator) i "valoare factur". O factur este primit de un singur beneficiar .

pagina 138

Sisteme informatice de gestiune

Figura 4.23. Reguli de trecere de la MCD la MLD; exemplu Asociaia nu se transform ntr-un tabel la nivelul MLD, dar este explicitat plasnd n tabelul "factura" cheia primar a tabelului "beneficiar" care devine o cheie strain. Se obine astfel urmtorul MLD:

Figura 4.24. Reguli de trecere de la MCD la MLD; exemplu Dac ASOCIAIA din MCD prezentat anterior are proprietatea "data" (data primirii facturii) atunci MCD i MLD corespunztor arat astfel:

pagina 139

Sisteme informatice de gestiune

Figura 4.25. Reguli de trecere de la MCD la MLD; exemplu Dac se utilizeaz conceptul de LEGATURIDENTIFICATOR ca n MCD-ul urmtor care arat c o factur este constituit din una sau mai multe poziii (rnduri n factur), iar o poziie aparine unei singure facturi,

Figura 4.26. Reguli de trecere de la MCD la MLD; exemplu identificatorul entitii "poziii" va fi format din concatenarea identificatorilor entitilor participante la asociaie, conform MLD de mai jos:
pagina 140

Sisteme informatice de gestiune

Figura 4.27. Reguli de trecere de la MCD la MLD; exemplu REGULA 3. Dac o asociaie binar este purttoarea a dou legturi de cardinalitate 0,n sau 1,n asociaia devine un tabel n MLD, n care migreaz cheile entitilor. Asociaia devine un tabel, n care cheia primar este obinut prin concatenarea identificatorilor entitilor participante la asociaie. Dac asociaia are proprieti, acestea devin coloane n tabelul care rezult din asociaie. Considernd urmtoarea situaie: "un client poate s nu cumpere sau s cumpere n produse, iar un produs poate s nu fie cumprat sau s fie cumprat de n clienti" , modelele conceptual i fizic vor arta ca n figura 4.28.

pagina 141

Sisteme informatice de gestiune

Figura 4.28. Reguli de trecere de la MCD la MLD; exemplu Noiunea de asociaie din MCD poate fi deci tradus n funcie de cardinalitile asociate , n dou feluri: prin utilizarea conceptului de cheie strain (regula 2); prin utilizarea unui nou tabel (regula 3). Cardinalitile alese la nivel conceptual determin deci n mare parte structura fizic, fiind necesar o mare atenie n alegerea lor. REGULA 4. Atunci cnd o asociaie binar are dou legturi de cardinalitate 0,1 sau 1,1 apare o dubl migraie a identificatorilor entitilor. Fie urmtorul MCD i corespunztor acestuia urmtorul MLD.

pagina 142

Sisteme informatice de gestiune

Figura 4.29. Reguli de trecere de la MCD la MLD; exemplu n MLD se pstreaz cele dou entiti provocndu-se n fiecare din ele migrarea reciproc a identificatorilor. Cnd asociaia binar are dou legturi 0,1 sau 1,1 i o proprietate, atunci asociaia se transform ntr-un tabel prin trecerea de la MCD la MLD. REGULA 5. Aceast regul privete n special entitile generatoare i entitile specifice. Fie MCD urmtor:

Figura 4.30. Reguli de trecere de la MCD la MLD; exemplu


pagina 143

Sisteme informatice de gestiune

Exist mai multe posibiliti de a obine MLD din care o prezentm pe cea mai simpl, adic crearea unui tabel pentru fiecare entitate, ceea ce se traduce prin migrarea identificatorului i a proprietilor de la entitatea generatoare (mam) n fiecare entitate fiic:

Figura 4.31. Reguli de trecere de la MCD la MLD; exemplu Atunci cnd entitatea generatoare este n asociaie cu o alt entitate, apare o combinaie ntre REGULA 2 i regulile menionate mai nainte, rezultatele obinute fiind n funcie de cardinalitile asociaiei.

pagina 144

Sisteme informatice de gestiune

4.3.3. Modelul fizic al datelor Descrierea unui model fizic este strns legat de sistemul de gestiune a datelor ales. n practic se ntlnesc frecvent trei tipuri de soluii tehnice: 1. Utilizarea unui sistem de gestiune a fiierelor clasic avnd ca metod principal accesul secvenialindexat. Fiierele indexat secveniale sau cu index rar presupun memorarea nregistrrilor ntr-un fiier numit fiier principal, n ordinea cresctoare a cheilor i grupate pe pagini. Se adaug un fiier de index, ce conine pentru fiecare pagin din fiierul principal cte o nregistrare cu valoarea celei mai mari chei din pagin i adresa de nceput a paginii. Fiierul de index este ordonat cresctor n raport cu valoarea cheii. De cele mai multe ori pagina corespunde unui bloc, nlnuirea blocurilor n ordine cresctoare a cheilor permite parcurgerea secvenial ordonat a fiierului. Atunci cnd n fiierul de index se gsete acelai numr de nregistrri cu cele din fiierul principal fiierul se numete cu index dens. Pentru fiierele de dimensiuni foarte mari, se poate considera fiierul de index din organizarea secvenial indexat ca fiier principal cruia i se ataeaz un fiier cu index rar. Procednd recursiv pn se obine un fiier index ce conine un singur bloc, se obine 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 145

Sisteme informatice de gestiune

Sistemul CODASYL este unul reprezentativ pentru modelul de organizare tip reea. Acesta se poate implementa uor prin asocierea a cte unui fiier la fiecare entitate. nregistrrile fiierului corespund realizrilor entitii i cmpurile nregistrrii corespund atributelor entitii. Modelul reea este apropiat de forma de reprezentare a bazelor de date sub forma diagramelor entitate-asociaie. Deosebirea const doar n faptul c toate relaiile ce apar pot fi numai binare de tipul unu-la-unu i mai-muli-launu. Aceast restricie permite reprezentarea grafic a unei baze de date de tip reea sub forma unui graf direcionat numit reea. ntr-o reea nodurile corespund entitilor i relaiile sunt reprezentate prin sgei ntre noduri de la tat la fiu. Structura de reprezentare reea este dezvoltarea structurii arborescente permind ca orice colecie de date s aib mai multe colecii de date superioare. O relaie R de forma mai-muli-la-unu de la entitatea E1 la entitatea E2 se implementeaz ca o mulime de liste circulare numite inele avnd capetele n fiierul asociat lui E2. Un inel de capt e2 aparinnd lui E2 conine toate elementele e1 aparinnd lui E1 care sunt n relaie cu e2. Modelul reea este folosit din ce n ce mai puin, 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 relaional. Modelul relaional se bazeaz pe noiunea matematic de relaie, aa cum este ea definit de teoria mulimilor, i anume ca o submulime a produsului cartezian al unei liste finite de mulimi numite domenii. Elementele unei relaii se numesc
pagina 146

Sisteme informatice de gestiune

tupluri, iar numrul de domenii (nu toate distincte) din produsul cartezian se numete aritatea relaiei. De obicei relaiile sunt reprezentate sub forma unor tabele n care fiecare rnd reprezint un tuplu i fiecare coloan reprezint valorile tuplurilor dintr-un domeniu dat al produsului cartezian. n reprezentarea sub form de tabel a unei relaii, coloanelor i respectiv domeniilor corespunztoare lor li se asociaz nume intitulate atribute. Mulimea atributelor unei relaii se numete schem relaional. Un alt mod de a defini relaiile este urmtorul: prin relaie nelegem o mulime de funcii definite pe o mulime de atribute cu valori n reuniunea unor domenii, cu restricia ca valoarea corespunztoare fiecrui atribut s se afle n domeniul asociat acelui atribut. Mulimea tuturor schemelor relaionale corespunzatoare unei aplicaii se numete schema bazei de date relaionale, iar coninutul curent al relaiilor la un moment dat se numete baz de date relaional. n modelul relaional entitile sunt reprezentate sub form de relaii n care schema relaional conine toate atributele entitii i fiecare tuplu al relaiei corespunde unui element al entitii. La atributele entitii se pot aduga n relaie i alte atribute suplimentare utilizate pentru exprimarea relaiilor ntre entiti. Descrierea modelului fizic al datelor (MFD) va fi facut n limbajul sistemului de gestiune corespunztor soluiei alese. n plus, mediul de dezvoltare va influena i el foarte mult MFD.

pagina 147

Sisteme informatice de gestiune

4.3.4. Modelul conceptual al comunicaiilor Acest model, numit i graf actori-flux, permite descrierea informaiilor schimbate la nivel global n sistem. Conceptele utilizate sunt: a) actor. Se ntelege prin actor tot ceea ce joac un rol n transmiterea unei informaii i care produce un flux informaional (pesoan fizic, juridic, cldire, servicii) Actorii se mpart n dou categorii: actori interni, care fac parte din organizaie; actori externi organizaiei sau domeniului studiat. b) flux. Un flux este un schimb de bunuri, bani sau informaii ntre un actor emitor i unul receptor. Se disting n particular urmtoarele fluxuri: fluxuri fizice fluxuri monetare fluxuri de informaii Printre fluxurile de informaii, n funcie de natura suportului se va vorbi de flux informaional oral, documentar sau informatic. O alt clasificare a fluxurilor este n funcie de locul emitorului n raport cu domeniul studiat: flux intern, atunci cnd este emis de un actor intern domeniului; flux extern, atunci cnd este emis de un actor extern domeniului. c) ordonarea fluxurilor. Aceast operaie permite observarea nlnuirii fluxurilor, putndu-se deosebi fluxurile primare de fluxurile secundare.
pagina 148

Sisteme informatice de gestiune

d) flux primar. Un flux primar este un flux care apare la cel mai sczut nivel organizatoric ntr-un domeniu de gestiune. ntr-un domeniu contabil, un flux primar va fi de exemplu un borderou de micri, document situat n amonte de fluxuri ca jurnalele, cartea mare, balana, bilanul etc.. e) flux secundar. Un flux secundar este un flux a crui emisie este subordonat preexistentei unuia sau mai multor fluxuri primare sau secundare. De exemplu, emiterea unei facturi este subordonat recepiei unei comenzi. f) graful fluxurilor. Graful fluxurilor este un graf ale crui noduri sunt actori iar arcele orientate sunt fluxurile schimbate.

Figura 4.32. Modelul conceptual al comunicaiilor


pagina 149

Sisteme informatice de gestiune

4.3.5. Modelul conceptual al prelucrrilor Prelucrrile constituie partea dinamic a sistemului informaional. Ele descriu aciunile ce trebuie executate asupra datelor pentru obinerea rezultatelor scontate. Prelucrrile nu sunt de fapt dect traducerea regulilor de gestiune care compun activitatea sistemului economic. Reprezentarea schematic face apel la urmtoarele concepte: 1)domeniu. Noiunea de domeniu n sensul de "domeniu de gestiune" corespunde unei pri a sistemului care conine subansamble coerente. Exemplu: domeniul comercial, domeniul financiar, domeniul personal. 2)procese. Procesele reprezint subansamble ale unui domeniu. Se recurge la aceast mprire atunci cnd sistemul de studiat este foarte vast. Exemplu: Domeniul comercial al unei ntreprinderi poate cuprinde trei procese: urmrire reprezentani, primire comenzi i urmrire comenzi. 3) operaie. O operaie este o activitate prin care se produc fluxuri informaionale. O operaie este definit imaterial, fr restricii organizatorice. Ea descrie la fel de bine gestiunea manual ct i pe cea automat. O operaie poate utiliza una sau mai multe entiti i/sau asociaii pentru aciuni de creare, modificare, tergere sau consultare. O operaie se descompune n aciuni.
pagina 150

Sisteme informatice de gestiune

Exemplu: O operaie n domeniul "Evidena personalului" ar putea fi "Obinerea adeverinei de salariu". Simbolul pentru operaie este:

Figura 4.33. Operaie

4) aciune. O aciune este o funcie elementar. ntre aciunile unei operaii nu exist ateptare, i derularea lor este secvenial. O aciune poate referi una sau mai multe REGULI DE GESTIUNE O operaie poate utiliza una sau mai multe entiti i/sau asociaii pentru aciuni de creare, modificare, tergere sau consultare. Simbolul este:

Figura 4.34. Aciune

pagina 151

Sisteme informatice de gestiune

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 aciuni. O aceeai regul de gestiune se poate aplica uneia sau mai multor aciuni. Exemple: 1. Trebuie aplicat 2% reducere clienilor ale cror comenzii din anul precedent au depit 4.000.000 lei; 2. Comenzile ctre furnizor trebuie s fie vizate de ctre eful serviciului aprovizionare. 6) eveniment. n timpul analizei unei operaii trebuie ntotdeauna s se pun ntrebarea "care sunt evenimentele care concur la declanarea unei operaii?". Un eveniment se definete ca un flux de orice natur, sau un fapt care permite lansarea unei operaii. 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" dect "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:

pagina 152

Sisteme informatice de gestiune

Figura 4.35. Eveniment Un eveniment are un nume, un cod, i un alias care apare ntre paranteze. Se vor distinge: evenimente declanatoare, care declaneaz o operaie sub controlul unei condiii de sincronizare; evenimente rezultate, produse de ctre o operaie ca urmare a unei reguli de emisie. Declanarea unei operaii este n general condiionat de prezena mai multor evenimente declanatoare. Aceste evenimente nu apar n acelai moment, deci apare necesitatea condiionrii declanrii operaiei cu o condiie de sincronizare a evenimentelor declanatoare. n acelai fel, operaiile, nu genereaz ntotdeauna aceleai evenimente rezultante. Producerea evenimentelor rezultante va fi deci supus regulilor de emisie.

pagina 153

Sisteme informatice de gestiune

Figura 4.36. Evenimente declanatoare i rezultante Evenimentele 1 i 2 declaneaz o operaie alctuit din dou aciuni 1 i 2, iar evenimentele 3 i 4 sunt rezultatul operaiei. 7) condiia de sincronizare. Condiia de sincronizare este exprimat printr-o condiie boolean care leag evenimentele declanatoare prin operaii logice I, SAU, NU. Operaia nu este declanat dect atunci cnd condiia este ndeplinit. Este recomandat folosirea alias-ului pentru descrierea condiiei de sincronizare. n exemplul din figura 4.37., operaia nu va fi declanat dect dac evenimentul A se produce n acelai timp cu evenimentul B sau C. Dac un singur eveniment este necesar pentru declanarea operaiei, condiia de sincronizare dispare din reprezentarea grafic. 8) regula de emisie. O regul de emisie definete condiia sub care evenimentele rezultate vor fi produse de ctre o operaie. O operaie poate avea una sau mai multe reguli
pagina 154

Sisteme informatice de gestiune

de emisie, o regul gestionnd emisia unuia sau a mai multor evenimente rezultate.

Figura 4.37. Condiia de sincronizare

Figura 4.38. Regula de emisie


pagina 155

Sisteme informatice de gestiune

O operaie poate s nu aib regul de emisie. n acest caz emisia evenimentelor este necondiionat i se traduce cu ajutorul cuvntului "totdeauna". O regul de emisie poate avea un alias pentru uurarea afirii simbolului operaiei n cazul n care textul care definete regula este prea lung.

Figura 4.39. Modelul conceptual al comunicaiilor; Exemplu


pagina 156

Sisteme informatice de gestiune

Evenimentele 1, 2 i 3 declaneaz operaia 1 punnduse condiia de sincronizare a I (b SAU c). Operaia 1 este constituit din aciunile 1 i 2 care conduc la regula 2 de emisie. Evenimentele 4 i 5 sunt rezultate produse de operaia 1. Operaia 2 compus din aciunea 3 este declanat de evenimentul 5. Evenimentul 6 este ntotdeauna emis de operaia 2. 9) reguli de creare a unui MCP. Crearea unui MCP poate prea uoar la prima vedere, dar se poate constata c exist tendina 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 dificultilor pe care le ntlnim n timpul analizei unui proces n separarea prii conceptuale de partea organizaional. Trebuie s ne amintim tot timpul c MCP trebuie s exprime ce trebuie fcut, dar nu arat cnd trebuie fcut i nici unde trebuie fcut (concepte organizaionale) i nc i mai puin cum trebuie fcut (concept operaional). Cu titlu de exemplu s ncercm modelarea procesului de selecie a unui candidat la ocuparea unui
pagina 157

Sisteme informatice de gestiune

post. Aceast modelare se sprijin pe urmtoarea 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 cnd aceste controale sunt favorabile, se trimite o convocare pe adresa candidatului"

Figura 4.40. MCP; Erori de modelare


pagina 158

Sisteme informatice de gestiune

Fr a putea spune c acest model este fals se pot formula totui urmtoarele observaii: 1. nici un eveniment extern, dup venirea dosarului, nu justific mparirea prelucrrilor aa de detaliat (scrisoarea de respingere reprezint de fapt numai un singur eveniment); 2. s-a inut cont n acest model de o restricie organizaional, asimilnd o operaie desfurat ntr-un anumit loc de munc unei operaii conceptuale; n general, atunci cnd o serie de operaiuni se nlnuie fr evenimente externe sau interne justificate cu adevrat, nu trebuie s aib loc o detaliere a operaiunilor. Se poate propune urmtorul MCP:

Figura 4.41. MCP corectat


pagina 159

Sisteme informatice de gestiune

11) erorile legate de validarea modelului. Dup conceperea unui MCP, este posibil s se aplice cteva reguli de validare. Aceste reguli, elementare, fac apel mai ales la bunul sim. a) Reguli legate de operaiuni. Cnd s-a plasat o operaie n model trebuie verificate urmtoarele: o operaie este un ansamblu de aciuni nentreruptibile, adic nu sunt supuse ateptrii unor evenimente. Dac acest lucru nu este posibil, trebuie folosite mai multe operaii; o operaie trebuie s fie omogen, adic fr prelucrri alternative dezechilibrate n interior. O operaie neomogen poate s ascund producerea unor evenimente interne neprevzute care ar antrena mprirea operaiei n mai multe operaii omogene; trebuie s se obin un rezultat n toate situaiile; o operaie este ntotdeauna precedat de cel puin un eveniment; o regul de emisie trebuie s coexiste ntotdeauna cu contrariul su (afar de cazul "totdeauna"); b)Reguli legate de condiiile de sincronizare. Cnd se introduce n model o condiie 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 operaiei care depinde de mai mult dect de un singur eveniment i cnd operaia este declanat de fapt de sosirea unui singur eveniment.
pagina 160

Sisteme informatice de gestiune

Figura 4.42. MCP; Sincronizare nerecomandat Acest tip de operaie nu este recomandat pentru c prin condiia de sincronizare A SAU B producerea evenimentului 1 sau a evenimentului 2 va declana operaia fr nici o ateptare, fapt care contrazice definiia sincronizrii. n acest sens modelul di figura 4.43. prezint o anume incoeren pentru c producerea evenimentului "b" declaneaz imediat i necondiionat operaia 2, ceea ce nseamn c operaiile 1 i 2 sunt n realitate una singur. Este de preferat n acest caz modelul din figura 4.44.

pagina 161

Sisteme informatice de gestiune

Figura 4.43. MCP cu incoerene

Figura 4.44. MCP corectat


pagina 162

Sisteme informatice de gestiune

12) reguli legate de funcionarea unui MCP. MCP nu este numai un model static de reprezentare a prelucrrilor, dar este n acelai timp un model dinamic a crui funcionare este supus anumitor reguli care depind n cea mai mare parte de context. Se vor aborda numai cazurile n care funcionarea modelului este imposibil sau nedeterminat, adic vor fi abordate noiunile de conflict i de ciclu. a) Noiunea de conflict. Se spune c exist un conflict relativ la un eveniment dac acest eveniment contribuie la mai multe sincronizri. Astfel urmtorul MCP prezint o situaie conflictual:

Figura 4.45. MCP cu conflict


pagina 163

Sisteme informatice de gestiune

Apariia evenimentului 2 va putea ntr-un mod nedeterminat s contribuie la activarea operaiilor 1 i 2. Acest conflict poate fi rezolvat n dou feluri: cardinalitatea producerii evenimentului 2 este 2 i n acest caz cele dou apariii ale evenimentului 2 sunt folosite n cele dou sincronizri; condiiile de participare ale evenimentului 2 la cele dou operaii sunt exclusive. b) Noiunea de ciclu. Cnd o operaie are ca eveniment declanator un eveniment pe care ea l produce nemijlocit sau prin intermediul mai multor operaii, ne gsim n prezena unui ciclu. Folosirea ciclurilor, cu condiia s fie valide, este o tehnic ce permite s se reduc sensibil mrimea MCP-ului. Un astfel de ciclu (figura 4.46.) este controlat i condiiile 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 restricii temporale de tipul: "nti ale lunii, nceputul perioadei, 15 ale lunii ..."

Validarea modelelor. Validarea modelelor are ca obiectiv sinteza ntre analiza datelor i analiza prelucrrilor. Ea permite verificarea ntre MCD i MCP. Verificarea acestei coerene are ca regul esenial verificarea ca toate entitile i asociaiile MCD-ului s fie utilizate de cel puin o operaie a MCP.
pagina 164

Sisteme informatice de gestiune

Figura 4.46. MCP cu ciclu Entitatea sau asociaia trebuie atunci s fie asociat unui eveniment declanator sau rezultant, sau s intervin ntr-o regul de gestiune sau un calcul. Cnd lipsa coerenei este constatat se poate interveni asupra MCD. Aceasta se poate traduce prin:
pagina 165

Sisteme informatice de gestiune

adugarea de proprieti care reprezint informaii a cror necesitate nu a fost banuit; adugarea de noi asociaii care stabilesc dependene ntre entiti care nu erau corect precizate.

Asocierea modelului datelor cu modelul prelucrrilor este unica operaie care permite validarea MCD. Operaia de validare permite trecerea de la un MCD brut la un MCD validat.

pagina 166

Sisteme informatice de gestiune

4.3.6. Modelul organizaional al prelucrrilor Anumite concepte au fost definite la modelul conceptual al prelucrrilor, deci se vor prezenta numai conceptele noi specifice MOP. 1) procedura. O procedur este o succesiune de faze aparinnd aceluiai proces i executat de actori. Este un subansamblu al unui proces din MCP decalaat de unul sau mai multe evenimente. MOP trebuie s fie stabilit cu grija cci el constituie prima viziune global i coerent a sarcinilor efectuate de ctre actori, schimburile dintre actori, datele la care fac apel actorii i restriciile organizaionale. 2) actorii. Un actor este o entitate organizaional nsrcinat s efectueze un anumit numr de faze. Un actor aparinnd 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 contribuia actorului n cadrul unui proces dat. Procedura actor cuprinde ansamblul sarcinilor efectuate de ctre un actor, MOP permind astfel stabilirea lucrrilor executate de fiecare actor. 3) faza.

pagina 167

Sisteme informatice de gestiune

O faz este o nlnuire ninteruptibil de task-uri cu aceiai 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 prelucrrilor sau task-urilor care compun faza; condiiile de sincronizare ale evenimentelor declanatoare; regulile de emisie ale evenimentelor rezultante. n plus, o faz relev caracteristicile urmtoare: natura sau tipul prelucrrii; derularea prelucrrii; locul unde se desfoar.

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

pagina 168

Sisteme informatice de gestiune

Tipul unei faze este gradul su 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 desfurare a activitii. Locul de desfurare a activitii nglobeaz conceptul de actor cruia i se atribuie caracteristici organizaionale. Aceste caracteristici sunt tipul locului de desfurare, responsabilul i resursele. Tipul locului reprezint ansamblul locurilor unde aciunile unei operaii conceptuale se pot efectua. Resursele sunt ansamblul mijloacelor care permit realizarea anumitor aciuni ale unei operaii. Resursele pot fi consumabile sau reutilizabile. Caracteristicile legate de desfurarea unei faze sunt indicate n coloana "perioad" a MOP iar tipul este indicat n coloana "tip". Actorul sau locul de desfurare a activitii relativ la o faza este indicat prin coloana unde figureaz faza. La fiecare operaie conceptual din MCP i corespunde una sau mai multe faze. 7) task. O faz este descompus n task-uri. Un task reprezint o funciune elementar. Un task poate folosi una sau mai multe reguli de organizare. Conceptul de task este foarte important pentru c el st la baza dezvoltrilor ulterioare. 8) eveniment.
pagina 169

Sisteme informatice de gestiune

Conceptul de eveniment este acelai care a fost definit n MCP, cu deosebirea c noiunea cuprinde i alte tipuri de evenimente care mbrac mai ales aspectul organizaional (introducerea unei comenzi, decizia superiorului, etc.) Aceste evenimente, iniiate prin regulile de organizare, vor avea un efect deloc neglijabil asupra mpririi operaiilor 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 creia i se d o dimensiune organizatoric. Exemplu: O regul de gestiune spune c "orice client trebuie s fie solvabil". La nivel organizaional, se mbogeste aceast regul preciznd modul de calcul prin care s se permit verificarea solvabilitii clientului. Astfel, orice regul de calcul poate fi o regul organizaional. 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
pagina 170

Sisteme informatice de gestiune

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

Figura 4.48. Modelul organizaional al prelucrrilor

Reguli de concepere a unui MOP. MOP poate fi dedus din MCP. Analiza restriciilor organzaionale condiioneaz n ntregime trecerea de la MCP la MOP. El se caracterizeaz prin luarea n
pagina 171

Sisteme informatice de gestiune

considerare a restriciilor organizaionale. Se trece ntradevar de la un ansamblu de lucrri finalizate (operaiile conceptuale), la un ansamblu de lucrri organizate (task-urile), avnd numeroase restricii organizaionale. Metoda va consta n analiza restriciilor organizaionale i n mparirea fiecrei operaiuni conceptuale. 1) Analiza restriciilor organizaionale. Analiza restriciilor organizaionale va permite punerea n eviden a noilor actori i a noilor evenimente. Evenimentele unui MOP pot fi conceptuale sau numai organizaionale. Un eveniment este conceptual dac el decurge direct dintr-un MCP i este organizaional n caz contrar. Evenimentele organizaionale pot fi purttoare sau nu de date. n cazul n care ele sunt purttoare de informaii, ele fac obiectul unei descrieri, care va servi la validarea modelelor de date. n cazul cnd ele nu sunt purttoare de date, acestea sunt evenimente de tipul "resurs disponibil" i nu este necesar s se reprezinte n MOP. n acest caz, se vor regsi n coloana "perioad" sau "tip". 2) mparirea fiecrei operaiuni conceptuale. Punerea n eviden a unor noi actori i/sau a unor noi evenimente va permite mprirea fiecrei operaii conceptuale n faze. Fiecrei operaiuni conceptuale din MCP i va corespunde: o faz unic n MOP; este cazul unei operaii conceptuale care poate fi complet executat de un actor ntr-o aceiai unitate de timp. mai multe faze n MOP; este cazul unei operaii conceptuale care trebuie s fie mparit n mai
pagina 172

Sisteme informatice de gestiune

multe subansamble de periodiciti diferite pentru unele aciuni sau o mprire rezultnd dintr-o restricie organizatoric. Pentru mai buna descompunere a unei operaii conceptuale, este necesar s se procedeze la o analiz ascendent plecnd de la rezultate spre evenimente. Astfel, o operaie conceptual d ntotdeuna cel puin 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 attea faze de achiziie de date cte fluxuri informaionale necesit o introducere de date. Ansamblul fazelor astfel obinute, prin descompunerea procedurii funcionale, pot fi eventual din nou combinate dac: la ele nu particip dect un singur actor; nu necesit dect resurse identice; nu au loc dect n acelai moment; nu sunt supuse unei ateptri de natura organizaional. n cursul descompunerii unei operaii conceptuale, este frecvent obinerea unei faze care a fost deja determinat anterior. n acest caz nu se va reine dect o singur faz. Se constat c metoda nu const n analiza restriciilor organizaionale i apoi mprirea fiecrei operaii conceptuale, ci mai curnd mprirea operaiilor n acelai timp cu analiza restriciilor organizaionale. 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 prelucrrilor. Ea permite
pagina 173

Sisteme informatice de gestiune

verificarea coerenei ntre MLD i MOP. Verificarea acestei coerene se efectueaz la dou niveluri: toate tabelele din MLD sunt necesare; orice coloan din MLD este utilizat de cel puin o operaie din MOP. Coloana trebuie s figureze la un eveniment declanant 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. Cnd se constat o lips de coeren poate fi necesar intervenia n modelele de date i chiar modificarea la nivelul MCD. Aceasta se poate traduce prin: adugarea de proprieti care reprezint informaii a cror necesitate nu a fost bnuit; aceasta poate conduce la o anumit denormalizare a modelului de date; adugarea de noi asociaii care stabilesc dependene ntre entiti care nu erau corect precizate; adugarea la nivelul MLD a unor noi indeci care asigur timpi de rspuns mai bun.

pagina 174

Sisteme informatice de gestiune

4.3.7. Modelul operaional al prelucrrilor Scopul modelului operaional al prelucrrilor (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 tranzaciilor (pentru faze n "timp real"). Se recomand respectarea ctorva reguli n funcie de tipul programelor. Astfel pentru programele "batch": mprirea acestora dup periodicitatea de prelucrare; mparirea dup tipul de prelucrare (validare, calcul,actualizare, editare) Pentru prelucrarea tranzaciilor se recomand urmtoarele reguli: fiecrui ecran i va corespunde o tranzacie; fiecare tranzacie va fi structurat n afiare ecran, introducere date, prelucrare ecran (normalizare I.S.O.); stabilirea normelor ergonomice pentru afiarea ecranului i introducerea datelor; mprirea prelucrrilor n validri, calcule, actualizri i editri; Descrierea nivelului operaional al prelucrrilor va evolua foarte mult n urmtorii ani prin utilizarea limbajelor de baze de date ca SQL i prin generalizarea programrii orientate pe obiecte.

pagina 175

Sisteme informatice de gestiune

4.4. Ciclul de decizie Ciclul de decizie cuprinde toate deciziile luate pe parcursul desfurrii 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 urmtoarea: mprirea sistemului informaional n domenii; orientrile generale n ceea ce privete gestiunea, organizarea i soluiile tehnice; planificarea dezvoltrii; 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 iniierea proiectului i ulterior terminrii acestuia evaluarea reuitei proiectului. Aceast observaie ne duce spre ideea c o corect abordare a ciclului de decizie trebuie nceput de la nivelul sistemului informaional, prin mprirea sistemului n zone de interes i prin stabilirea orientrilor generale. Totodat trebuie fcut o diferena ntre atitudinea decizional pasiv, care las lucrurile s evolueze n mod natural i o politic managerial consecvent n direcia informatizrii. Din constantrile practice se observ o etapizare "natural" n introducerea prelucrrii automate a datelor.
pagina 176

Sisteme informatice de gestiune

Aceast etapizare depinde de condiiile obiective existente n economie: starea tehnologiei hardware; starea tehnicilor de rezolvare a problemelor fundamentale; riscul pe care-l implic deficienele de organizare. Dei tehnologia hardware este uniform n cea mai mare parte a lumii, tehnica rezolvrii problemelor fundamentale, variaz de la industrie la industrie i de la ntreprindere la ntreprindere. Valoarea riscului pe care-l implic, deficienele de organizare variaz de la caz la caz. Pragul de la care o anumit activitate devine riscant este o problem subiectiv i se stabilete n funcie de nivelul acceptat al probabilitii de producere a evenimentelor nefavorabile. Dar miza depirii eventualelor dificulti este mare deoarece un succes mai nsemnat realizat de o ntreprindere va strni un ecou rapid n rndul celorlalte. Etapizarea ptrunderii calculatoarelor ntr-o ntreprindere, sintetizat pe baza mai multor constatri practice este urmtoarea: 1. aplicaii de baz ale calculatoarelor; 2. aplicaii intradivizionare ale calculatoarelor; 3. aplicaii interdivizionare ale calculatoarelor; 4. aplicaii avansate ale calculatoarelor. Aceast etapizare nu presupune o intervenie coordonat n direcia informatizrii. Bineneles c n cazul unei opiuni ferme de realizare a unui sistem informatic se va putea aborda direct etapa final n utilizare a calculatoarelor. 1. Prima arie de aplicaii ntr-o ntreprindere productiv este aceea n care se cere un efort individual, sau cel mult, cooperarea ntre grupuri mici.
pagina 177

Sisteme informatice de gestiune

Ca rezultat, aplicaiile iniiale sunt limitate la proiecte de proporii i complexiti reduse. n plus hard-ul se alege dintre cele mai ieftine alternative, din cauza tendinei normale de limitare a riscului financiar n introducerea unei tehnologii noi i nu prea cunoscute. Accentul n primele aplicaii se pune pe nlocuirea muncii umane n activiti de sortare, raportari scrise i rezolvri de ecuaii. 2. O alt etap este aceea cnd se utilizeaz personalul dintr-un singur compartiment i este caracterizat prin ntreinerea i punerea la zi a fiierelor i printr-un nivel mai ridicat al complexitatii. Aplicaiile includ state de plat, stocuri, registre contabile generale, balane, calculul dividentelor, evidena mijloacelor fixe, etc.. 3. Cea de-a treia etap se caracterizeaz prin ncercarea de rezolvare a unor probleme economice care cer un numr limitat de cooperari ntre sectoare. Exist un interes crescnd pentru optimizarea sistemelor complexe i de regul, majoritatea ntreprinderilor urmresc s ctige maximum prin optimizarea planificrii i utilizrii echipamentelor electronice. Dup cum sarcinile de lucru cresc pentru echipamentele de calcul ale intreprinderii, exist tendina de a favoriza aplicaiile mai urgente, astfel nct apar cozi de ateptare n vederea punerii la punct a celorlalte aplicaii. O rezolvare a acestei probleme este descentralizarea responsabilitilor de calcul. n aceast etap se ncearc i cteva din aplicaiile cele mai simple de comand a proceselor de producie. Comanda proceselor i-a ctigat 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 178

Sisteme informatice de gestiune

condiiilor de funcionare, determin mbuntirea produselor i reducerea cheltuielilor de producie. 4. La sfritul etapei a treia devine clar pentru multe ntreprinderi c apropierea treptat de rezolvarea problemei i de pstrarea nregistrrilor nu ine pasul cu cerina ntreprinderii pentru informare i rspuns. Un rspuns la aceast problem este implementarea unui sistem informatic integrat. n industriile care au o producie de mas, cu utilizarea unei tehnologii omogene, aceste sisteme pot fi introduse fr prea mari dificulti. Totui, majoritatea ntreprinderilor productive au o tehnologie extrem de diversificat n ceea ce privete primirea comenzilor, achiziionarea de materii prime, distribuirea, depozitarea i mecanismul de desfacere. Un element simplu ce exemplific eterogenitatea schimburilor de informaii este numrul 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 opoziie cu atitudinea pasiv se afl aciunea contient prin care strategia ntreprinderii trebuie s beneficieze de o serie de orientri generale care s-i permit ctigarea unor avantaje competitive. n acest sens modelul urmtor permite corelarea scopurilor ntreprinderii cu avantajele poteniale dar i cu efortul necesar. Conductorul este pus aadar n faa unei probleme foarte importante i deloc uoar. Este evident c are nevoie de o tehnologie informatic, dar care aplicaii informatice din cele existente sau dintre cele oferite pe pia au o importan strategic i pot influena n mod decisiv potenialul firmei? El trebuie s tie cnd tehnologia informatic este un element critic
pagina 179

Sisteme informatice de gestiune

pentru ntreprinderea sa. O cale posibil pentru o investigaie de acest fel o constituie Modelul strategic tip gril (The Strategic Gril Model; Figura 4.49.) care permite determinarea importanei i impactului strategic prin situarea firmei ntr-un cadran cu dou dimensiuni: impactul strategic al sistemelor existente; impactul strategic al dezvoltrii sistemelor (sistemele viitoare) n cadranul 1 suport (de sprijin) sistemele informatice sunt vzute ca avnd un impact redus asupra activitii firmei i tind s rman aa i n viitor. Dependena activitii firmei de sistemele informatice este considerabil sczut. Tehnologia informatic este perceput ca un sprijin funcional fr s implice investiii semnificative i sunt coordonate de la un nivel ierarhic mijlociu i sczut. n cadranul 2 factory (de fabricaie) dei sistemele informatice sunt importante n afacerile firmei ele nu sunt n centrul dezvoltrii strategice. Un posibil exemplu l-ar putea constitui o ntreprindere n care producia este condus prin sisteme de control n timp real dar viitoarele dezvoltri ale sistemului informatic nu vor influena 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 creteri a activitii ci mai ales pentru meninerea pe pia ntr-un mediu economic perturbat. Se poate exemplifica acest situaie cu o ntreprindere n care planurile de dezvoltare sunt puternic legate de tehnologia informatic.

pagina 180

Sisteme informatice de gestiune

Figura 4.49. Modelul strategic grila n cadranul 4 strategic se reprezint firmele a cror activitate depinde n mod critic de existena sistemelor informatice. O performan sczut ori cderea acestor sisteme poate fi cauza unor disfuncionaliti 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 investiii din acest domeniu. Exemple de firme din acest cadran sunt bncile, companiile de asigurri, firme de brokeraj, ziare, institute de cercetri de marketing, etc. Situarea ntreprinderii n acest cadran trebuie s vizeze lanul
pagina 181

Sisteme informatice de gestiune

producie-desfacere, existnd posibilitatea ca diferite alte activiti s se gseasca n celelalte cadrane. Acest model permite o privire static asupra prezentului i viitoarei dependene de sistemele informatice. De altfel este important de urmrit micarea n timp n interiorul grilei. Trecerea din cadranul suport n strategic se poate face sub presiunea progresului tehnologic, a competiiei de pe piaa sau a unor noi obiective n dezvoltarea firmei. La fel de important este aciunea conductorului i la nivelul dezvoltrii componentelor sistemului informatic, cu observaia c n acest caz este vorba de o conducere de nivel inferior. O proast conducere poate afecta succesul proiectului mai mult dect ali factori, dar acest fapt, n mod surprinztor, este mai puin neles 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 urmtoarele diagrame care evidenieaz implicarea factorului de conducere n realizarea proiectului. (Figura 4.50.) La acest nivel de prezentare condiia iniial este iniierea proiectului i rezultatul este proiect realizat. Resursele reprezint tot ceea ce s-a consumat pentru realizarea proiectului. Pentru furnizarea mai multor amnunte aceast diagram poate fi detaliat pentru ase etape ale ciclului de via al proiectului: analiza preliminar, proiectarea logic, proiectarea tehnic, construcia, implementarea i testarea.

pagina 182

Sisteme informatice de gestiune

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 strile n care se poate afla sistemul i este folosit pentru descrierea dependenelor, pentru alocarea resurselor i pentru finanare. Dreptunghiurile reprezint stri sau grupuri de stri legate ntre ele n diferite moduri, iar intrrile i ieirile sunt evenimente care permit tranziia de la o stare la alta. Strile, permit conductorului de proiect comunicarea i msurarea activitiil asociate proiectului n dezvoltare. Se observ c evenimentele sau condiiile de ieire asociate strilor sunt stabilite pentru ca managerul s tie cnd o anumit faz este complet astfel nct s poat ncepe urmtoarea.

pagina 183

Sisteme informatice de gestiune

Figura 4.51. Conducerea proiectului pe etape ale ciclului de via AC (Asigurarea Calitii) reprezint semnalul prin care care s se garanteze c produsul se conformeaz unor standarde IEEE Standard for Sofware Quality. Calitatea produsului const n totalitatea trsturilor sau caracteristicilor sale care i permit s se conformeze necesitilor utilizatorului. Controlul calitii const n aciunile necesare pentru msurarea caracteristicilor produsului i compararea lor cu specificaiile. 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 pn la fritul ciclului de via, pentru c fiecare etap constituie o nou ocazie pentru alte tipuri de erori. CM (Componena Managementului) este aspectul care permite identificarea n timp a acelor puncte pentru
pagina 184

Sisteme informatice de gestiune

efectuarea contrulului modificrilor, pentru monitorizarea integritii i trasabilitii produsului pe parcursul ciclului de via. Aceasta permite conductorului s cunoasc ce s-a fcut, ce se realizeaz acum i cu ce se va continua mai departe. V+V (Verificarea i Validarea) se refer la ct de bine produsul corespunde din punct de vedere funcional, al cerinelor de performan i al interpretrii corecte a cerinelor. Punctul principal al verificrii i validrii este clientul adic dac ceea ce i s-a furnizat corespunde cerinelor sale. Aa cum s-a vzut din cele prezentate conducerea proiectului este activitatea care traverseaz ntregul ciclu de via. Conductorul trebuie s fie atent n deciziile luate, trebuie s posede informaiile corecte pentru luarea deciziilor i s nu ia decizii compensatorii atunci cnd s-a greit. 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 motivaiile personale i interpersonale. Complexul de atitudini, motivaii, intentii, stri afective etc. constituie mpreun "comportamentul uman" care trebuie avut n vedere de conductor n cele dou accepiuni ale sale: factorul uman din interiorul echipei de proiectare; comportamentul uman din sistemul studiat ca obiect de analiza al echipei de proiectare.

pagina 185

Sisteme informatice de gestiune

V. Abordri orientate spre date i prelucrri Ralizarea unui sistem informaional-decizional performant este rezultatul unui cumul de factori. Este cert c nu factorii individuali sunt cei cu influen hotrtoare ci ansamblul interaciunii lor. Acest ansamblu de factori trebuie analizat i modelat n aa fel nct s se obin performana maxim. Dac prin extensie spunem c modelarea efectuat pentru realizarea sistemului este ea nsi un factor, putem afirma c ntr-adevr acesta este unul important. Modelarea situaiei existente sau a celei dorite trebuie s fie capabil s reprezinte realitatea la un moment dat dar i s se poat adapta la modificrile pe care ea nsi le preconizeaz. Analiznd modelele de reprezentare a realitii propuse de metoda Merise, se observ dou tipuri de reprezentare. Prima este bazat pe postulatul c un sistem trebuie s realizeze anumite funcii (existena unui material n stoc, nlnuirea etapelor pentru construcia unei case, etc. ). Aceast abordare este cea a descompunerii funcionale. A doua se preocup de faptul c un sistem informatic este un sistem de relaii ntre entiti. Spre exemplu se descrie un individ ca un ansamblu compus dintrun nume, unul sau mai multe prenume, un cod numeric personal i avnd unul sau mai muli copii. n acelai sens o cas este un ansamblu de fundaii, perei, ui i ferestre.

pagina 186

Sisteme informatice de gestiune

Sosirea buldozerului

Sosirea muncitorilor

Pregatirea buldozerului verificarea combustibilului verificarea prezentei sofer incalzirea motorului

Pregatirea echipei verificarea prezentei repartizarea sarcinilor

Inceput activitate buldozer

Inceputul lucrului echipei

Saparea fundatiilor sapatura bruta finisaj sapatura non OK OK

Beton disponibil

Anuntare proiectant

Sapatura terminata

Turnarea betonului pregatire cofraj pregatire armatura turnare beton asteptare intarire Terminare turnare fundatii

Figura 5.1. Exemplificare cu modelul conceptual al datelor


pagina 187

Sisteme informatice de gestiune

Descompunerea funcional i propune s abordeze sistemul ca un prestator de servicii care s rspund la anumite ntrebri. De exemplu Ci clieni au fost vizitai de la nceputul lunii?. Furnizarea rspunsului presupune desfurarea unei serii de aciuni: determinarea primei zi lucrtoare din lun, gsirea clienilor vizitai de la acea dat i pn la zi i afiarea rezultatului. Funcia gsirea clienilor vizitai de la nceputul lunii i pn la zi se descompune ea nsi n acces la fiierul de clieni, selecionarea numrului de clieni vizitai ncepnd de la acea dat, eliminarea clienilor vizitai de dou ori, etc.. Acest demers ar prea natural n msura n care ar reproduce ceea ce face un salariat cruia i se pune aceast ntrebare. Se poate distinge o dubl aciune. O mprire temporal prin care sarcinile trebuiesc ndeplinite unele dup altele. n exemplul dat nu pot fi selectionai clienii nainte de stabilirea primei zi lucrtoare din lun. Aceast dimensiune temporal pune n relief secvenialitatea sarcinilor i sincronizarea lor. mprirea procedurilor n subproceduri prin care sarcinile globale sunt mprite n activiti care pot fi din nou mprite la rndul lor. Procesul se repet pn cnd sarcinile elementare sunt suficient de simple. Descompunerea funcional va fi exemplificat cu ajutorul modelului conceptual al prelucrrilor din metoda Merise. Indiferent de modaliatea practic de realizare a diagramei funcionale particularitatea acestei abordri const n urmrirea unei aplicaii prin toate trasformrile pe care le exercit asupra datelor. Este vorba de o structurare a prelucrrilor. Analiza prin descompunerea
pagina 188

Sisteme informatice de gestiune

funcional permite s se gsesasc sub-proceduri comune, putndu-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 modificri se vor face ntrun singur loc aplicndu-se tuturor funciilor la care procedura comun particip. Ca o alternativ la structurarea prelucrrilor s-a lansat spre sfritul anilor 80 analiza structurilor de date. O problem este reprezentat printr-un sistem de relaii dintre elementele care-l compun. Abordarea se canalizeaz spre definirea elementelor de model i spre stabilirea reelei de relaii care le leag. Prezentarea acestui sistem de relaii se face cu ajutorul diagramei entitate-relaie. Entitile reprezint fiine sau obiecte purttoare a anumitor proprieti iar relaiile reprezint interaciunile dintre entiti. O relaie se poate exprima printr-o fraz al crui complement sunt entitile iar verbul este relaia dintre ele. Pentru exemplificare s-a folosit modelul conceptual al prelucrrilor din metoda Merise pentru aceiai problem a construciei unei case. Figura 5.2. introduce noiunea de cardinalitate (un ofer face parte dintr-o echip i numai una iar ntro echip pot fi zero sau mai muli oferi) dar spre deosebire de structurarea prelucrrilor situaia prezentat de diagrama entitate-relaie este static (se prezint datele dar nu se precizeaz dac ele sunt n micare sau n repaus). Diagrama entitate-relaie explic ce sunt fundaiile i ce este necesar pentru a le construi dar nu explic maniera prin care se poate face. Tot pe lista minusurilor se poate aduga, c unui singur model i corespunde un numr infinit de realizri posibile exprimndu-se un ansamblu de relaii posibile fr a se impune un sens de lectur.
pagina 189

Sisteme informatice de gestiune


Sofer nume

1,1

face parte
0,n

Echipa sef de echipa numar de membrii


0,n

0,1

conduce definit de

1,1

Buldozer numar
1,n

0,n

sapa
1,n

Groapa locul in teren adancimea suprafata

0,1

construita

1,1

Fundatia cod data terminarii suprafata cofrata


0,1 1,1

Cofraj tip material marca beton

Figura 5.2. Exemplificare cu modelul conceptual al prelucrrilor Pe de alt parte modelul este recunoscut ca durabil n msura n care reprezint realitatea fundamental a domeniului de activitate modelat i este extrem de adaptabil. nlocuirea unui ef de echip sau introducerea unei noi maini ( entiti) cu ajutorul creia se vor spa gropile nu schimb major sistemul.
pagina 190

Sisteme informatice de gestiune

Abordrile orientate spre date i spre prelucrri i au rdcina n dou sisteme de gndire diferite: Analiza prin prelucrri i gsete sursa n noiunea de metod n sensul n care aceasta i propune s rezolve o problem printr-un cadru procedural. Acest cadru fixeaz etapele i nlnuirea lor astfel nct intrrile i ieirile corespund fiecrei etape. Aceast gndire este esenialmente cartezian i analiza prin structura prelucrrilor este legat de acest curent de gndire. Analiza structurilor de date studiaz problema modelrii punndu-se accentul pe relaiile 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 totui c nsi 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 prelucrri o dubl abordare a sistemului, persist totui unele inconveniente. Fazele de studii sunt prea lungi i neproductive. mprirea lucrului ce decurge din abordarea prin sarcini specializate i din ciclul de concepie n V fac dificil obinerea de rezultate notabile. Aceast abordare impune o nelegere global a concepiei
pagina 191

Sisteme informatice de gestiune

anterioare programarii. Adesea pn cnd grupul de studii s termine caietul de sarcini necesitile s-au schimbat iar n proiectele de o anumit dimensiune lungimea fazelor face foarte posibil frecventa schimbare a analitilor. Presiunea este foarte mare la nceputul proiectului, atunci cnd deciziile cele mai importante trebuiesc luate plecndu-se de la un minim de elemente. Deci, abordrile tradiionale sunt caracterizate printr-o dificultate ridicat o primelor etape cnd orice eroare poate avea consecine grave. Comunicarea este dificil mai ales cu neinformaticienii. Implicarea utilizatorilor n proiect este adesea dificil, principala dificultate constnd n formularea cerinelor ntr-un format propriu modelrii. Comunicarea n sens invers nu este nici ea mai uoar, pe de o parte din cauza necunoaterii de ctre client a limbajului informatic dar mai ales datorit necunoaterii suportului de comunicaie. De la un anumit nivel de complexitate verificarea diagramelor entitate-relaie i de structurare a prelucrrilor de ctre un neinformatician devine imposibil. Abordrile orientate spre date i funciuni sunt ireconciliabile. Analiza structurii datelor permite obinerea de programe mai evoluate dar ea nu permite reprezentarea scopului aplicaiei a ceea ce utilizatorul atepta de la ea. Trebuie deci ca mai trziu s se descrie aceasta prin modelarea prelucrrilor. 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 prelucrrilor. Problememle cu adevrat dificile apar la integrarea datelor cu prelucrrile n procesul de realizare dar mai ales n
pagina 192

Sisteme informatice de gestiune

faza de mentenan cnd apare frecvent fenomenul de regresie. Acesta const n faptul c modificarea prelucrrilor ntr-o zon a aplicaiei afecteaz datele utilizate de ntreg sistemul. Se poate demonstra c aceast problem decurge tocmai din contradicia dintre date i prelucrri. Abordarea prin prelucrri impune ca o funcie utilizat n mai multe locuri s nu existe dect ntr-un singur exemplar. n arborescena programului ea va fi ridicat ctre vrful arborescenei pentru a putea fi utilizat de toate celelate funcii care o apeleaz. Securitatea datelor impune ca accesul la ele s fie fcut de un numr minim de funcii. Deci atunci cnd o dat este modificabil de mai multe proceduri este imposibil de a gsi originea modificrilor. Exist deci tendina de coborre a funciei de acces pentru a evita modificrile intempestive. Aceste considerente au stat la baza nateri unei noi abordri, numit orientatat obiect, care are la origine rezolvarea problemelor de simulare. ntr-o astfel de abordarea nu mai este vorba de analiza funciilor sau de studierea relaiilor dintre elemente ci mai curnd de situarea n interiorul lor reproducnd comportamentul la anumite evenimente. Din aceast abordare se nate conceptul de obiect ca entitate ce reacioneaz singur i este independent. Dei metoda MERISE preia unele aspecte ale abordrii obiectuale rmne n sarcina viitoarelor cercetri integrarea real a conceptului obiectual. Bibliografie.
pagina 193

Sisteme informatice de gestiune

(1) Gh. Boldur Lescu, Gh. Ciobanu, I. Bncil "Analiza sistemelor complexe"; Editura tiintific i enciclopedic Bucureti 1982 (2) I.Roca, E.Macovei, N.Davidescu, V.Rileanu Proiectarea sistemelor informatice financiar-contabile Editura didactic i pedagogic Bucureti 1993 (3) Dumitru Oprean "Metode i tehnici utilizate n realizarea sistemelor informatice" Editura Dacia 1980 (4) Mihai Pun, 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

pagina 194

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