1

UNIVERSITATEA SPIRU HARET FACULTATEA DE SJSE Constanta SPECIALIZAREA MANAGEMENT CONSTANTA

INFORMATICA MANAGERIALA

Anul I semestrul 1

CONF. UNIV. DR. CLAUDIU CHIRU

2

INTRODUCERE ÎN ANALIZA ŞI PROIECTAREA

SISTEMELOR INFORMAŢIONALE

1. Noţiuni de bază şi definiţii Informatica: activitate pluridisciplinară orientată spre proiectarea şi exploatarea sistemelor

de prelucrare a informaţiilor, în scopul eficientizării şi rentabilizării activităţii umane. După

dicţionarul explicativ DEX, informatica este ştiinţa care se ocupă cu studiul prelucrării

informaţiei cu ajutorul calculatoarelor.

Sistemul: o secţiune a realităţii în care se identifică un ansamblu de elemente, interconectate

printr-o mulţime de relaţii reciproce, precum şi cu mediul înconjurător şi care acţionează în

comun în vederea realizării unor obiective bine definite. Fiecare sistem are un comportament

specific, determinat de natura elementelor din care este compus şi de relaţiile dintre ele. Un

exemplu de sistem (mecanic) este cutia de viteză din compunerea automobilelor.

Sistemul informaţional: o definiţie sumară care “ţine aproape” de definiţia sistemului, ar

putea prezenta sistemul informaţional drept ansamblul elementelor de structură

organizatorică din compunerea unei secţiuni a societăţii umane, împreună cu legăturile

funcţional-informaţionale dintre ele şi cu mediul social exterior, care acţionează în comun

pentru îndeplinirea scopului şi obiectivelor stabilite.

O definiţie mai riguroasă [3] consideră sistemul informaţional ca fiind un ansamblu tehnico-

organizatoric de proceduri de constatare, consemnare, culegere, verificare, transmitere,

stocare şi prelucrare a datelor, în scopul satisfacerii cerinţelor informaţionale necesare

conducerii procesului fundamentării şi elaborării deciziilor.

Sistemul informatic se interpune între sistemul condus şi sistemul de management, ca în

figura de mai jos [3].

Obiectivul sistemului informaţional este satisfacerea cerinţelor informaţionale necesare

conducerii în procesul de elaborare a deciziilor.

Activităţile care se derulează în cadrul sistemului informaţional sunt următoarele:

- culegerea şi consemnarea datelor primare de la locurile unde au loc procesele şi fenomenele economice, precum şi din spaţiul economic extern;

- verificarea, transmiterea şi stocarea datelor pe diferiţi purtători tehnici de informaţii; - prelucrarea manuală sau automată a datelor în concordanţă cu cerinţele conducerii; - selectarea informaţiilor necesare conducerii conform principiului selecţiei şi

informării prin excepţie.

Sistemul informatic constă din partea automatizată a sistemului informaţional (utilizatorii

implicaţi în automatizare şi cadrul organizatoric aferent) căreia i se adaugă şi alte elemente

necesare pentru automatizarea obţinerii informaţiilor necesare conducerii în procesul de

SISTEMUL CONDUS

SISTEMUL DE MANAGEMENT

Resurse

- materiale

- umane

- energetice

Produse finite

Servicii prestate

Informaţii din

afara sistemului

X Y

Informaţii în

afara sistemului

Sistemul

informaţional Informaţii Decizii

3

fundamentare şi elaborare a deciziilor şi anume : echipamente (hardware), programe

(software), comunicaţii, o bază ştiinţifică şi metodologică precum şi baza informaţională.

Baza ştiinţifică şi metodologică constă din modele matematice ale proceselor şi fenomenelor

economice, metode şi tehnici de realizare a sistemelor informatice.

Baza informaţională se referă la datele supuse prelucrării, fluxurile informaţionale, sistemele

şi nomenclatoarele de coduri.

Odată cu dezvoltarea cercetării operaţionale, a teoriei deciziei, a Internetului şi a

performanţelor calculatoarelor, au apărut sisteme informatice dedicate cum ar fi sistemele

suport de decizie şi sistemele expert, dar şi unele sisteme informatice de tip nou ca cele

pentru proiectare asistată de calculator, sistemele multimedia, sistemele pentru comerţul

elctronic şi sistemele deschise.

Sistemele suport de decizie sunt colaboratori ai decidentului, în timp ce sistemele expert sunt

sisteme de inteligenţă artificială şi se comportă ca un expert, adică rezolvă o mare parte din

procesul elaborării deciziilor, dar bineînţeles sunt avute în vedere numai deciziile referitoare

la problemele pentru care sistemul expert a fost conceput.

Sistemele suport de decizie trebuie să dispună de o componentă de gestiune a modelelor, una

de gestiune a datelor, una de asigurare a comunicaţiei şi interfaţa cu utilizatorii.

Sistemele expert trebuie să dispună de o bază de cunoştinţe, o bază de fapte, un spaţiu de

lucru, mecanisme rezolutive (de raţionament şi de inferenţă) mecanisme explicative şi

interfaţa utilizator.

În general cei care produc soft aplicativ nu prea au de ales în ce priveşte tipurile de sisteme

enumerate mai sus, pentru că tipul de sistem depinde de natura datelor şi prelucrărilor ce se

vor executa în acel sistem. Astfel dacă într-o problemă criteriile sunt preponderent

cantitative, iar caracteristicile problemei se formulerază cantitativ, modelarea se face foarte

bine algoritmic şi deci vom alege un sistem informatic.

Dacă avem de a face cu formulări mai mult calitative decât cantitative atunci ne vom orienta

asupra unui sistem suport de decizie sau a unui sistem expert, care nu exclud algorimii, dar

presupun şi baze de cunoştinţe.

Sistemele informatice tradiţionale folosesc baze de date relaţionale, dar în prezent se afirmă

tot mai mult sistemele orientate obiect.

Baza de date este un sistem de colecţii de date între care există o interdependenţă logică

multiplă, potrivit unor relaţii prestabilite cu ocazia definirii structurii datelor, destinat

satisfacerii operative a celor mai diverse solicitări provenite din partea unor grupuri diferite

de utilizatori. Utilizatorii bazelor de date sunt: administratorul, programatorii de aplicaţii şi

utilizatorii finali. Pentru lucrul cu baza de date ei dispun de o interfaţă soft, numită Sistemul

de Gestiune a Bazei de Date (SGBD). Unele aplicaţii încă mai folosesc fişiere.

Fişierul este o colecţie de date omogene din punct de vedere al naturii, conţinutului

informativ şi a criteriilor de prelucrare, conservată pe o memorie externă, în concordanţă cu

restricţiile impuse de procesul de prelucrare automată a datelor, pentru satisfacerea cerinţelor

de informare a unuia sau mai mulţi utilizatori.

Obiectul constituie componenta elementară dintr-un sistem orientat obiect.

Fiecare obiect posedă o stare, un comportament şi o identitate. Starea este formată din

ansamblul de valori ale atributelor sau proprietăţilor obiectului, comportamentul poate fi

definit ca ansamblul de operaţii pe care le poate executa obiectul, setul de responsabilităţi

asumate sau de servicii oferite altor obiecte, iar identitatea se referă la modul de reprezentare

şi de conservare a individualităţii fiecărui obiect, indiferent de transformările sau sau

schimbările de stare prin care va trece.

Practic pentru a genera un obiect trebuie să avem definită clasa de care aparţine obiectul.

4

Clasa seamănă foarte bine cu tabelul din bazele de date, adică putem să o descriem şi apoi să

generăm exemplare (instanţe) din acea clasă de obiecte numai că ea nu are numai atribute ci

are şi operaţii, adică comportament. O operaţie este implementată printr-o metodă.

Obiectele se interacţionează prin mesaje.

In programarea cu obiecte se disting aspecte ca moştenirea, polimorfismul, abstractizarea,

încapsularea, reeutilizarea şi persistenţa.

Analistul de sisteme informatice este specialistul care concepe şi realizează sisteme

informatice. Această funcţie poate fi ocupată de specialişti proveniţi din rândul absolvenţilor

de facultate având specializarea matematică-informatică, cibernetică economică,

contabilitate şi informatică de gestiune sau alte specializări asemănătoare, dar şi de alţi

specialişti cu studii superioare cum ar fi ingineri, fizicieni, economisti, etc. care au făcut

ulterior cursuri de analişti-programatori.

Se impune să remarcăm că elaborarea sistemelor informatice este un act de mare răspundere.

Această afirmaţie este justificată de investiţia relativ mare care trebuie făcută pentru a

informatiza o intreprindere/instituţie, de volumul mare de muncă necesar pentru realizarea

sistemului informatic (de regulă de ordinul a 1-2 ani-om şi chiar mai mult), de impactul social

al trecerii activităţii pe calculator. Ca urmare, între proiectant (unitatea/societatea de informa-

tică, unde sunt angajaţi analiştii) şi beneficiar, adică intreprinderea sau instituţia care va folosi

sistemul informatic, se încheie un contract având ca obiect realizarea sistemului informatic.

Este de la sine înţeles că analiştii ar trebui să cunoască specificul intreprinderii/instituţiei în

care va funcţiona sistemul informatic, intreprindere care în raport cu unitatea de informatică

la care lucrează analistul, este o unitate beneficiară. Cum analiştii nu pot, să cunoască

specificul tuturor unităţilor beneficiare cu care ar putea veni în contact în decursul timpului,

în echipa de realizare a sistemului informatic se cooptează şi specialişti din partea unităţii

beneficiare, care să aibă idee de ceea ce se poate face cu calculatorul, dar mai ales să ştie

foarte bine ce vor de la calculator, în contextul viitorului sistem informatic. Se crează deci o

echipă mixtă de realizare a sistemului informatic Este bine să se ştie că orice aplicaţie, pe lângă faptul că rezolvă problema pentru care a fost

concepută, trebuie să respecte şi legislaţia în domeniu, astfel încât rezultatele obţinute cu ea

să fie recunoscute de organele de control cum ar fi garda finaciară, curtea de conturi, ş.a.

Nerespectarea unor prevederi legale în vigoare, referitoare la procedura (modelul matematic

şi algoritmul) prin care se redactează anumite documente, competenţa celor care avizează şi

semnează astfel de documente, termenele de elaborare, numărul de exemplare, durata lor de

păstrare, siguranţa datelor, păstrarea secretului (dacă este cazul), etc., pe considerentul că

problema a fost rezolvată pe calculator, nu absolvă pe cel în cauză, de răspundere pentru

încălcarea legislaţiei!

2. Structura sistemelor informatice În conformitate cu abordarea funcţională, sistemele informatice sunt organizate pe

subsisteme, aplicaţii şi unităţi funcţionale sau proceduri logice. Pentru programatori mai sunt

relevante încă două nivele, inferioare unităţii funcţionale şi anume, unitatea de prelucrare sau

procedura automată şi modulul program . În general, subsistemul vizează o funcţie a unităţii

beneficiare sau un domeniu de activitate din unitatea în care este conceput sistemul. Aplicaţia

vizează o activitate, iar unitatea funcţională o subactivitate sau sarcină.

Aplicaţia este un pachet de programe ce serveşte la automatizarea prelucrării datelor aferente

unei activităţi distincte din cadrul unui domeniu de activitate (de exemplu poate exista o

aplicaţie pentru elaborarea statelor de plată, denumită pe scurt aplicaţia “salarii”). Într-o

aplicaţie pot fi implicate mai multe elemente de structură organizatorică. De exemplu în

5

elaborarea statelor de plată este implicat nu numai biroul financiar, care este titular pentru

această activitate, ci şi serviciul personal, sau dacă sistemul de plată presupune pontaj, va fi

implicat dispeceratul, secretariatul, etc.. Împlicarea mai multor elemente de structură

organizatorică într-o aplicaţie complică schema funcţională a aplicaţiei, dar de cele mai multe

ori, prezenţa mai multor elemente este inevitabilă.

De regulă aplicaţiile se derulează ciclic şi pentru a fi mai uşor trecute pe calculator, ciclul lor

de viaţă se descompune în subactivităţi cum ar fi preluarea datelor şi actualizarea bazei de

date, sau cea de elaborare liste de ieşire sau rapoarte, sau etapa de elaborare informaţii pentru

alte aplicaţii, etc.

Procedura logică sau unitatea funcţională este corespondentul subactivităţii din cadrul unei

aplicaţii din domeniul informatizării. Numai la acest nivel se poate face uşor, trecerea directă

de la structura logică a aplicaţiei la programe, ceea ce înseamnă că unei unităţi funcţionale i

se pot asocia din softul aplicaţiei, una sau mai multe unităţi de prelucrare sau proceduri

automate. Ultima situaţie este necesară mai ales atunci când şi în cadrul unei unităţi de

prelucrare, sunt implicate mai multe elemente de structură organizatorică.

În contextul unităţilor funcţionale, elementele de structură organizatorică folosesc

calculatorul în sesiuni de lucru la calculator când, de cele mai multe ori, nu se rulează un

singur program, ci una sau mai multe proceduri automate.

Procedura automată este o secvenţă bine definită de programe (module program), care odată

lansată în execuţie, se rulează după o schemă logică, fără întrerupere, până la sfârşit. De

exemplu preluarea pe calculator, validarea şi stocarea fişelor de pontaj pentru salarii poate

constitui o procedură în cadrul aplicaţiei numită salarii. Faptul că procedura se rulează

întotdeauna până la sfârsit, nu înseamnă că programele care fac parte din procedură se vor

rula toate de fiecare dată; rostul schemei logice care stă la baza procedurii, este tocmai acela

de a decide în funcţie de parametrii introduşi de utilizator şi de felul cum decurge rularea,

care program să se ruleze şi care să fie sărit, astfel încât procedura să înfăptuiască un act

coerent, raţional, să permită utilizatorului să controleze situaţia, mai precis să înfăptuiască o

etapă sau măcar acea parte dintr-o etapă din ciclul de viaţă al unei aplicaţii, care-i revine

biroului sau secţiei din care face parte utilizatorul respectiv.

Există şi proceduri manuale care deşi nu fac obiectul programării, ele pregătesc prelucrarea

automată a datelor, sau după caz, finalizează această acţiune. Proiectantul sistemului infor-

matic, trebuie să ţină seama de procedurile manuale şi să facă referiri la ele în cadrul etapei

de proiectare logică şi fizică precum şi ulterior în cadrul manualelor de utilizare şi respectiv

de exploatare, pentru că abia împreună cu aceste proceduri sistemul informatic este complet.

Structura sistemului informatic trebuie să fie cât mai puţin dependentă de structura

organizatorică a intreprinderii/instituţiei pentru care s-a conceput sistemul. Acest lucru

asigură sistemelor informatice o viaţă mai lungă, făcându-le să nu depindă de frecventele

schimbări de structură organizatorică, care au loc de obicei în secţiunile sociale unde sunt

implementate şi care, dacă sistemul s-ar baza pe ele, ar face ca acesta să trebuiască a fi

actualizat, pentru fiecare modificare de structură.

3. Concepţia logică de principiu a sistemului informatic În secţiunea 2 s-a specificat că sistemele informatice sunt structurate pe subsisteme, aplicaţii,

unităţi funcţionale, unităţi de prelucrare sau proceduri şi module program. Merită remarcat

că, indiferent de nivelul său, orice componentă a sistemului informatic presupune intrări,

prelucrări şi ieşiri, iar relaţiile dintre componente se realizează prin intermediul unei baze

informaţio-nale, care există şi în sistemul informaţional, dar în condiţiile informatizării, va fi

6

reflectată în colecţii omogene de date ce pot fi organizate în baze de fişiere sau date în funcţie

de sistemul specific de gestiune a datelor (SGF sau SGBD).

Concepţia logică concretă a unui sistem informatic dat se elaborează în etapa de proiectare

logică, dar este bine să ştim încă de pe acum ce este o concepţie logică de principiu a

sistemului informatic. Un asemenea model cuprinde:

a) Intrările în sistemul informatic: sunt acele modificări ale sistemului informaţional care

produc schimbări în colecţiile de date, adică tranzacţiile externe. Adeseori, modificările pe

care tranzacţiile externe le produc direct colecţiilor de date induc şi un al doilea val de

modificări ale acestora, sub forma tranzacţiilor interne. Astfel o factură ce însoţeşte o tranşă

de materiale venite de la furnizor este o tranzacţie externă, pentru că modifică soldul

materialelor cuprinse în factură, dar ea induce şi o modificare a soldului furnizorului

respectiv, ceea ce este o tranzacţie internă.

7

DOCUMENTE DE INTRARE IN SISTEMUL INFORMATIC

BAZA INFORMAÞIONALÃ NUCLEU DE INFORMAÞII

PRELUCRÃRI

SGBD sau SGF COLECÞII DE DATE ORGANIZATE IN FIª IERE SAU IEª IRI

INTRÃRI BAZE DE DATE TRANZACÞII EXTERNE

LISTE SITUAÞII TRANZACÞII INTERNE DE IEª IRE

OBÞINUTE DE SISTEMUL

PROCEDURI INFORMATIC CREARE EXPLOATARE

ACTUALIZARE LISTARE

MODIFICÃRI LISTE DE ERORI

REGLAREA FENOMENELOR ª I PROCESELOR ECONOMICE DIN UNITATEA BENEFICIARÃ.

Reprezentarea schematică a concepţiei logice de

principiu a sistemului informatic

Tranzacţiile externe provin din exteriorul sistemului electronic de calcul, în timp ce

tranzacţiile interne sunt produse de procedurile de actualizare şi exploatare a colecţiilor de

date. Este de datoria analistului de sisteme informatice să identifice încă din etapa de

proiectare logică efectele secundare ale intrărilor în sistem şi să consemneze necesitatea

procedurilor care vor materializa aceste efecte asupra colecţiilor de date, adică vor efectua

tranzacţiile interne ce se impun logic.

b) Prelucrările sistemului informatic: sunt efectuate de procedurile sistemului informatic şi

prin ele se urmăreşte să se realizeze actualizarea şi exploatarea colecţiilor de date. Dacă baza

informaţională este formată din ansamblul entităţilor informaţionale şi a atributelor pe care

8

acestea le au, colecţiile de date preiau numai mulţimea atributelor entităţilor din baza

informaţională, aşa numitul nucleu de informaţii. Legăturile dintre entităţi apar atunci când

ele au atribute comune. Mulţimea entităţilor informaţionale din baza informaţională trebuie să

fie unică şi neredundantă. Ea trebuie să asigure un fond centralizat de informaţii care să

asigure obţinerea ieşirilor solicitate de beneficiarul sistemului informatic.

c) Ieşirile sistemului informatic: sunt grupate în patru categorii:

- indicatori sintetici (ex. cifra de afaceri, profitul brut, fondul de rulment, capitalul

propriu, rata rentabilităţii, etc.);

- liste sau situaţii de ieşire, care grupează indicatori sintetici sau analitici sub formă

de tabel;

- grafice care redau dinamica indicatorilor sintetici sau analitici;

- indicatori sintetici şi analitici stocaţi pe suporturi magnetice care urmează a fi transmişi altor sisteme informatice;

Dată fiind complexitatea actului de elaborare a unui sistem informatic, de-a lungul timpului

în acest domeniu s-au aplicat diferite concepţii/paradigme şi metodologii.

4. Metode de abordare a sistemelor informatice Nu este greu de înţeles că realizarea unui sistem informatic, sau doar a unei aplicaţii,

presupune modelarea situaţiei reale şi utilizarea modelului creat, în realitatea cu care

operează calculatorul.

Modelarea este reprezentarea într-un mediu controlat, a proprietăţilor şi/sau fenomenelor şi

proceselor care caracterizează un obiect sau un sistem real. Cu alte cuvinte în modelare nu

există adevăr absolut; modelarea presupune abstracţie şi aducerea în atenţie numai a unor

aspecte ale realităţii studiate şi anume acele aspecte care prezintă interes pentru modelator.

Unul din mediile controlate în care se poate reproduce realitatea, deci unul în care se pot face

modele, este calculatorul. Pe calculator se realizează modele informaţionale.

Modelul informaţional este o abstracţie a unei entităţi şi această abstracţie poate fi făcută fie

pentru a crea un model general (de referinţă) care să fie apoi folosit pentru a crea exemple

concrete de sisteme informatice (cazul arhitecturilor de referinţă), fie pentru a crea modelul

informatic al unei entităţi anume, deci un model de transpunere. În cele ce urmează ne vom

referi exclusiv la modele de transpunere.

La crearea modelului intervine viziunea analistului despre realitatea pe care o studiază, adică

paradigma. Paradigma reprezintă "ochelarii" prin care analistul vede sistemul informaţional

real, acela pe care vrea să-l modeleze, dar nu toate viziunile sau concepţiile analiştilor ajung

să fie considerate paradigme. La începuturile existenţei sistemelor informatice, atenţia

analiştilor a fost concentrată spre latura funcţională a activităţii umane studiate şi cum o

funcţie a unui birou sau secţie nu putea fi analizată şi nici prelucrată în bloc, ea a fost

descompusă în activităţi (rezultând aplicaţiile informatice), activităţile au fost descompuse în

subactivităţi (rezultând procedurile), care la rândul lor au fost descompuse în operaţii, cărora

în calculator le corespondeau modulele program. S-a dezvoltat în aceste condiţii o abordare

funcţională a sistemelor informaţionale.

În informatica industrială funcţiei îi corespunde procesul, ceea ce a dus la abordarea

orientată spre proces.

Ulterior, locul fişierelor a fost luat de bazele de date şi corespunzător, locul sistemelor de

gestiune a fişierelor a fost luat de sistemele de gestiune a bazelor de date (SGBD).

Pe parcursul perfecţionării SGBD-urilor, s-a trecut la baze de date relaţionale, creându-se

impresia că elementul principal pe baza căruia trebuie perfecţionate SGBD-urile îl reprezintă

structura datelor. Avem astfel de a face cu o abordare orientată spre date.

9

Când s-a pus problema aplicaţiilor în timp real, factorul cel mai important se părea a fi

evenimentul. A apărut astfel orientarea spre evenimente.

Structurarea programelor a evoluat şi ea odată cu metodele de analiză, dar era din ce în ce

mai greu de ţinut pasul cu metoda de analiză, mai exact cu orientarea abordării sistemelor

informatice. Preocupările analiştilor-programatori pentru a pune în concordanţă structura

programelor cu metoda de analiză a sugerat o nouă abordare şi anume legarea evenimentelor

de obiect şi a programelor (numite de astă dată metode) de evenimente.

A apărut astfel orientarea pe obiecte, numai că spre deosebire de celelalte abordări, ea se

extinde şi în alte domenii de activitate, devenind un mod de a concepe realitatea, adică o

paradigmă.

Dată fiind complexitatea sistemelor informatice ele nu se pot obţine dintr-odată şi nici nu se

pot realiza după cum crede fiecare programator. Desigur la început aşa a fost, dar pe măsură

ce s-a acumulat experienţă, ea a fost materializată în metodologii.

Metodologia elaborării sistemelor informatice a fost concepută iniţial ca un ansamblu de

principii şi indicaţii, tehnici şi metode grupate şi ordonate ca să ducă la realizarea

sistemului informatic. Cuvântul “metodă” folosit în această definiţie nu are nimic de a face

cu metoda-program asociată evenimentelor unui obiect şi nici cu metoda de abordare a

sistemelor informaţionale. Aici prin metodă se înţelege un set de reguli aplicabile unui

domeniu restrâns din cadrul unei metodologii.

In prezent metodologia este văzută ca setul finit, particular definitoriu al unei metode

(metodă de abordare a sistemelor informatice), prin intermediul unui sistem coerent de

formulare şi/sau procese informatice, necesare pentru modelarea şi formalizarea totală a

unui sistem informatic.

Metodologiile evoluează odată cu tehnologia informaţiei, dar o metodologie de realizare a

sistemelor informatice trebuie să cuprindă:

- etapele/procesele de realizare a unui sistem informatic structurate în subetape , activităţi

sarcini precum şi conţinutul lor;

- fluxul realizării acestor etape sau procese, subetape şi activităţi;

- modalitatea de derulare a ciclului de viaţă a sistemului informatic;

- modul de abordare a sistemului;

- strategiile de lucru/metodele de realizare;

- regulile de formalizare a componentelor sistemului informatic;

- tehnicile, procedurile, instrumentele, normele şi standardele utilizate;

- modalităţile de conducere a proiectului (planificare, programare, urmărire) şi modul de

utilizare a resurselor financiare, umane şi materiale.

În legătură cu sistemele informatice se mai folosesc două noţiuni şi anume ciclul de

dezvoltare a sistemului informatic şi ciclul de viaţă al dezvoltării sistemelor.

Ciclul de viaţă al dezvoltării sistemelor (CVDS ) se extinde pe intervalul de timp cuprins

între decizia de elaborare a sistemului informatic şi decizia de abandonare sau de înlocuire cu

alt sistem informatic.

Ciclul de dezvoltare a sistemului informatic se extinde de la decizia de elaborare a

sistemului informatic până la momentul intrării sistemului în exploatare.

Ciclul de dezvoltare a sistemului este inclus în ciclul de viaţă al dezvoltării sistemelor.

În tabelul de mai jos sunt prezentate trei exemple de metodologii şi de etapizare ale ciclului

de dezvoltare. Aceste etape, sau altele (depinde de paradigma prin care vedem sistemul

informaţional şi de modelul ales pentru CVDS ), trebuie respectate la o scară

corespunzătoare şi în cazul aplicaţiilor.

10

De altfel, este recomandabil ca şi atunci când ne propunem să realizăm doar o aplicaţie, să

facem mai întâi o analiză a întregului sistem informatic, (evident "săpând" doar atât de adânc

cât este necesar pentru ca aplicaţia noastră să fie compatibilă cu aplicaţiile existente şi cu cele

care vor fi realizate în viitor) şi apoi să continuăm doar cu aplicaţia ce ne interesează. Metoda SSADM (1982) Metoda MERISE Metoda ICI din Romania - studiul de fezabilitate;

- analiza cerinţelor;

- specificarea cerinţelor;

- specificarea logică;

- proiectare fizică (inclusiv

programarea);

- studiul de evaluare;

- modelarea globală;

- modelarea conceptuală;

- modelarea organizaţională;

- logică;

- fizică;

- implementarea (inclusiv programarea).

- elaborarea temei de realizare;

- proiectarea de ansamblu;

- proiectarea de detaliu;

- elaborarea programelor;

- implementarea sistemului.

Lista metodologiilor nu se opreşte la cele trei sau patru exemple de mai sus, dar nici nu ne

propunem să facem aici o trecere în revistă a tuturor metodologiilor existente până în prezent.

Ceea ce ne interesează este să reţinem categoriile de metode cu specificul lor, pentru ca noi să

ne alegem una sau două metodologii care se pretează cel mai bine la specificul informaticii

de gestiune şi să le aprofundăm pentru a le folosi în activitatea noastră de viitor.

In acest sens remarcăm că după modul de abordare a sistemelor informatice există

metodologii cu abordare structurată şi metodologii cu abordare orientată obiecte.

Metodologiile cu abordare structurată presupun împărţirea sistemului în subsisteme pe baza

funcţiilor sistemului (cazul abordării funcţionale) sau în funcţie de date (abordarea bazată pe

date). Exemplele de metodologii de mai sus fac parte din categoria metodologiilor cu

abordare structurată.

Metodologiile cu abordare orientată obiect folosesc conceptele tehnologiei orientate pe

obiecte. Etapele ciclului de viaţă al dezvoltării orientate obiect sunt:

- analiza ; - proiectarea, divizată în

- proiectarea de sistem ; - proiectarea obiectelor ;

- implementarea.

Metodologiile cu abordare orientată obiect s-au dezvoltat la început cu multe

incompatibilităţi, ceea ce a făcut ca în 1997 să apară un standard cu privire la simboluri,

notaţii, tipuri de diagrame, tipuri de modele, etc. Acesta este cunoscut sub numele de Unified

Modeling Language sau UML.

UML nu numai că a standardizat dezvoltarea de produse soft bazate pe obiecte, dar a pus

bazele unui proces iterativ de dezvoltare a sistemelor informatice. Acesta se bazează pe

următoarele etape:

- definirea problemei; - structurarea soluţiei cu subetapele:

- stabilirea actorilor; - stabilirea cazurlor de utilizare; - stabilirea relaţiilor dintre cazurile de utilizare; - construirea diagramelor cazurilor de utilizare;

- analiza sistemului care cuprinde: - identificarea cazurilor de utilizare; - diagrama cu structura domeniului claselor; - iniţializarea diagramei de clase, a diagramei obiectuale, diagramele de stare

sau după caz, diagramele de activitate;

11

- pentru clasele cu comportament dinamic se construiesc diagramele de secvenţă şi diagramele de colaborare;

- construirea soluţiei; - proiectarea sistemului:

- proiectarea arhitecturii; - proiectarea de detaliu;

- implementarea sistemului. Ulterior s-a dezvoltat un ghid practic pentru utilizarea UML, numit Rational Unified

Processes sau RUP căruia i s-a asociat şi un CASE (Computer Aided System Engineering)

foarte cunoscut astăzi, numit Rational Rose.

Funcţionalităţi de modelare UML ca şi round-trip engineering (combinarea generării

automate de cod cu reverse engineering – generare de diagrame prin analiza codului) oferă şi

Visual Studio prin modulul Visual Modeler.

Într-un ghid practic ca RUP utilizatorul trebuie să descrie cine, ce şi cum face, întrebări

cărora în RUP le corespund conceptele de rol, document şi activitate.

În cazul RUP etapele ciclului de dezvoltare au o configuraţie mai stranie prin faptul că deşi

ele vizează procese, în documentaţie este specificat obiectul activităţii (de aceea în original

este vorba de workflow, adică fluxul de lucru).

Aceste etape/procese sunt:

- modelarea activităţii; - cerinţe; - analiză şi proiectare; - implementare; - testare; - dezvoltare; - managementul schimbării; - managementul proiectului; - mediul.

Se pleacă de la premiza că parcurgerea acestui flow se va face iterativ de mai multe ori şi din

puncte diferite. De asemeni se mai presupune că în cadrul fiecărei etape se pot parcurge patru

faze: iniţiere, elaborare, construcţie şi tranziţie.

Ca urmare fazele şi procesele de parcurs atunci când folosim un process de tip RUP se

reprezintă mai uşor sub forma unei matrici conţinând pe verticală procesele iar pe orizontală

cele patru faze pe care le poate parcurge oricare din cele 9 procese. Primele 6 procese sunt

grupate sub numele de nucleu sau procese de lucru, iar ultimele 6 constituie suportul sau

procese suport. La intersecţia unui proces cu fiecare din fazele prin care ar putea trece se

marchează cu linie curbă situată mai sus sau mai jos faţă de axa rândului respectiv, ponderea

fazei în cadrul procesului respectiv ca în rândul Analiză şi proiectare din tabelul de mai jos

(dacă în cadrul unei intersecţii/casete sunt mai multe iteraţii linia se va diviza corespunzător):

12

FAZE

Procese de

lucru

Iniţiere Elaborare Construcţie Tranziţie

Modelare

afacere

Cerinţe

Analiză şi

proiectare

Implementare

Testare

Dezvoltare

Procese

suport

Managementul

schimbării

Managementul

proiectului

Mediul

Iniţial Elab#1 Elab#2 Con1 Con3 Con3 Tran#1 Tran#2

Iteraţii

CONCLUZII - Sistemul informaţional este un ansamblu tehnico-organizatoric de proceduri de constatare,

consemnare, culegere, verificare, transmitere, stocare şi prelucrare a datelor, în scopul

satisfacerii cerinţelor informaţionale necesare conducerii procesului fundamentării şi

elaborării deciziilor;

- Sistemul informatic constă din partea automatizată a sistemului informaţional (utilizatorii

implicaţi în automatizare şi cadrul organizatoric aferent) căreia i se adaugă şi alte elemente

necesare pentru automatizarea obţinerii informaţiilor necesare conducerii în procesul de

fundamentare şi elaborare a deciziilor şi anume : echipamente (hardware), programe

(software), comunicaţii, o bază ştiinţifică şi metodologică precum şi baza informaţională;

- În afara sistemelor informatice tradiţionale există şi sisteme informatice dedicate cum ar fi

sistemele suport de decizie şi sistemele expert, dar şi unele sisteme informatice de tip nou ca

cele pentru proiectare asistată de calculator, sistemele multimedia, sistemele pentru comerţul

elctronic şi sistemele deschise;

- Sistemul informatic se elaborează pe baza unei metodologii. Există un ciclu de dezvoltare a

sistemului informatic, iar metodologia de elaborare a sistemului informatic trebuie să

prevadă printre altele şi etapele ciclului de dezvoltare a sistemului informatic;

- Metodologia elaborării sistemelor informatice este un ansamblu de principii şi indicaţii,

tehnici şi metode grupate şi ordonate ca să ducă la realizarea sistemului informatic. Există

metodologii structurate şi metodologii cu abordare orientată obiect;

- În conformitate cu abordarea funcţională, sistemele informatice sunt organizate pe

subsisteme, aplicaţii şi unităţi funcţionale sau proceduri logice. Pentru programatori mai sunt

13

relevante încă două nivele, inferioare unităţii funcţionale şi anume, unitatea de prelucrare sau

procedura automată şi modulul program;

- Pentru automatizarea elaborării sistemelor informatice se folosesc softuri de tip CASE, cum

ar fi AMC Designer (MERISE) şi Easy Case (SSADM) pentru metodologii structurate sau

Oracle Designer (mediu CASE integrat), Rational Rose (RUP) şi Visual Modeler (Visual

Basic) pentru metodologii orientate obiect .

STUDIU APROFUNDAT AL METODOLOGIILOR

DE ELABORARE A SISTEMELOR INFORMATICE

1. Metodologia MERISE - un exemplu de corelare a

ciclului de dezvoltare cu nivelul şi cu viziunea

asupra sistemului

În cursul precedent am văzut ce este ciclul de dezvoltare de sisteme şi am amintit despre

modelare şi modelul informaţional. Acum trebuie să remarcăm că nivelul de la care privim

sistemul informaţional diferă de la o etapă la alta a ciclului de dezvoltare de sisteme, iar

modelul sistemului informaţional evoluează de la o etapă la alta reflectând nivelul de la care

privim sistemul informaţional. Astfel, dacă ar fi să ne referim la etapele metodei Merise, ar

trebui să distingem un nivel global (asociat studiului de evaluare) şi apoi nivelele conceptual,

organizaţional, logic şi fizic, cărora le vor corespunde modelele global, conceptual,

organizaţional, logic şi respectiv modelul fizic. Această evoluţie a modelulului sistemului

informaţional spre un model de sistem informatic este continuă şi logică, în sensul că fiecare

din modelele de mai sus, n-ar putea fi construit dacă nu avem definitivat modelul etapei

precedente.

A şti să proiectăm sisteme informatice îndeamnă să ştim CE şi CUM trebuie făcut în cadrul

fiecărei etape a ciclului de dezvoltare de sisteme pentru ca să obţinem modelul specific acelei

etape, iar răspunsul la aceste întrebări îl oferă metodologiile.

Pentru a realiza o modelare eficientă a sistemului informaţional, agenţii (persoanele care

joacă un rol oarecare într-un proces ce trebuie modelat) ca şi entităţile care operează în sistem

( de exemplu documentele de intrare), trebuie implicate în model împreună cu funcţiiile pe

care le îndeplinesc, cu comportamentul lor şi cu datele referitoare la ele.

Prin comportament în cazul agenţilor se înţelege ceea ce fac ei în anumite împrejurări în

contextul funcţiilor lor, iar în cazul documentelor de intrare – se înţelege ce efecte au ele (în

contextul fluxului în care sunt implicate) asupra datelor.

În ce priveşte datele, există date care determină starea agenţilor sau entităţilor, date de care au

nevoie pentru a-şi îndeplini funcţiile (respectiv procesul în care sunt implicate) şi date pe care

le modifică sau le produc prin activitatea lor.

Diversitatea metodelor de abordare a sistemelor informaţionale are de a face şi cu nevoia de a

surprinde funcţiile, comportamentul şi datele implicate în sistem, în sensul că unele metode

surprind mai uşor funcţiile, altele redau mai uşor comportamentul, iar altele evidenţiază mai

bine datele. Dacă am imagina un spaţiu cu cele trei dimensiuni ce caracterizează o entitate

(funcţia, comportamentul sau datele de care este legată), atunci poziţia oricărei entităţi în

acest spaţiu va depinde de ponderea pe care o au în existenţa acelei entităţi, funcţia,

comportamentul şi datele de care este legată.

Când analiştii încep să studieze un sistem informational, în vederea trecerii acestuia pe

calculator, ei trebuie să identifice care este trăsătura dominantă a sistemului (coordonata cu

14

valoarea cea mai mare) şi să aleagă metoda de abordare, respectiv metodologia cea mai

potrivită.

Odată aleasă metoda de abordare a sistemului informaţional, ar trebui identificat ciclul de

viaţă al dezvoltării sistemului (ciclul asociat metodologiei respective), aşa cum apare el în

literatura de specialitate şi ar trebui să efectuăm operaţiile specificate în cadrul metodologiei,

pentru fiecare etapă.

Am precizat mai sus că de fapt în cadrul fiecărei etape, metodologia precizează CE şi CUM

trebuie făcut. Pentru a preciza CE trebuie făcut, în metodologie sunt enumerate obiectivele

urmărite în cadrul fiecărei etape, iar pentru a preciza CUM trebuie făcut, este precizată forma

sub care se consideră că se poate prezenta fiecare din aceste obiective, în cadrul

documentaţiei de fază. Uneori această formă de prezentare poate fi una grafică, dar nu una

oarecare ci respectând forme şi înscrisuri tipizate, prevăzute în metodologie. O astfel de

formă tipizată se formalism.

Formalism, în sensul de mai sus, înseamnă un set de definiţii şi reguli, combinat cu un set de

tipuri de diagrame şi/sau de tabele. Cele mai sofisticate formalisme le conţine metoda Merise,

dar şi diagramele de flux ale datelor (DFD) sau cele de tip entitate_relatie (DER) sunt tot

nişte formalisme.

Numai după ce proiectantul aplică situaţiei concrete, oferită de sistemul analizat, formalismul

specific etapei, el poate îndeplini cerinţele de proiectare privind documentaţia de fază.

Documentaţia de fază are pe de o parte rolul de a valorifica constatările etapei curente pentru

a putea fi folosite ca punct de plecare pentru etapa următoare, iar pe de altă parte ea are şi un

rol comunicativ în relaţia cu beneficiarul pentru că prin consensul dintre proiectant şi

beneficiar, proiectantul are garanţia că a înţeles cerinţele beneficiarului şi va realiza un

sistem care să satisfacă aceste cerinţe. Legat de acest aspect, documentaţia de fază mai are şi

o utilitate juridică, în sensul că poate constitui baza legală pentru plata muncii efectuate de

proiectant, iar în caz de litigii ulterioare între proiectant şi beneficiar, documentaţia de fază

poate constitui un factor care înclină balanţa în favoarea uneia sau alteia din părţi, după cum

situaţia din teren corespunde sau nu cu ceea ce s-a aprobat de către beneficiar prin avizarea

documentaţiei de fază.

Avizarea documentaţiei de fază are loc înainte de a se trece la faza următoare.

Revenind la ideea de a realiza sistemul informatic numai prin simpla traducere în viaţă a

specificaţiilor privind CE şi CUM trebuie făcut în fiecare etapă a CVDS, trebuie spus că din

nefericire, lucrurile nu sunt atât de simple şi aceasta pentru că foarte rar ciclul de viaţă al

dezvoltării sistemului informatic se derulează secvenţial şi o singură dată. De cele mai multe

ori ciclurile se reiau din diferite puncte şi uneori chiar de mai multe ori şi din puncte diferite,

ducînd la apariţia unor modele ale ciclurilor de viaţă. Cu alte cuvinte ciclurile de viaţă

diferă odată de la un mod de abordare la altul, ceea ce se concretizează printr-o anumită

structură a etapelor ciclului de dezvoltare (structură materializată printr-un anume număr de

etape şi succesiune), dar apoi ele diferă şi de la un model la altul al ciclului de dezvoltare,

prin modul cum vor fi reluate şi repetate anumite faze. Motivul pentru care se complică

lucrurile în acest fel este acela că de cele mai multe ori, prima variantă a softului produs

iniţial nu este satisfăcătoare.

Cauzele acestei situaţii sunt multiple. Iată doar câteva dintre ele:

- pe timpul elaborării unei variante, în sistemul analizat pot să intervină schimbări de

structură sau de funcţionare;

- este mai greu să perfecţionezi o aplicaţie care încă nu funcţionează, aflată doar pe hârtie,

decât una care a început să funcţioneze; ca urmare începem cu ceva care urmează a fi

perfecţionat;

15

- când am dat primul program în funcţiune, începem să comunicăm mai bine cu beneficiarul;

s-ar putea ca el să constate că n-a fost bine înţeles, sau ceea ce a cerut nu era ceea ce dorea.

Cele mai reprezentative modele ale ciclurilor de viaţă sunt următoarele: modelul cascadă,

modelul V, modelul incremental, modelul spirală, modelul evolutiv, modelul piramidă

(specific ingineriei informaţiei orientate-obiect).

În secţiunea 2 sunt prezentate în detaliu cele mai reprezentative modele ale ciclurilor de viaţă.

Presupunând că am identificat elementul care va fi supus analizei (funcţie, proces, date,

obiecte, etc.), adică am ales orientarea şi am ales şi modelul ciclului de dezvoltare, deci

avem o secvenţă clară de faze ce trebuie parcurse pentru a realiza sistemul informatic, am

putea trece la îndeplinirea activităţilor prevăzute pentru fiecare etapă, numai că înainte de

aceasta urmează să mai luăm în calcul încă un element: viziunea (view) sau aspectul pe care-l

analizăm la un moment dat pentru a realiza abstractizarea impusă de modelare, adică pentru a

elabora modelul informaţional. Inainte de a explica ce este viziunea, merită să remarcăm că

spre deosebire de alte entităţi cu care operăm în viaţa cotidiană sistemele informatice implică

mai multe puncte de vedere (views). Aşa de exemplu un motor poate fi privit din punct de

vedere al principiului de funcţionare, al componentelor sale majore, deci a subansamblelor

sale şi cam atât, în timp ce sistemul informatic implică şi forme abstracte şi mai ales forme

abstracte şi aceasta pentru că el nu este realitatea pură ci este o abstractizare a realităţii.

Viziunea este legată de faptul că sistemul informaţional se va materializa sub forma a cel

puţin patru aspecte diferite la care va trebui să facem referire în fiecare din etapele CVDS. Cu

alte cuvinte o etapă se consideră parcursă dacă pe timpul său am făcut referirile ce se impun

la următoarele aspecte:

- descrierea şi definirea elementelor adiţionale şi auxiliare specifice etapei;

- comunicaţii implicate în sistem;

- datele ce se vehiculează în sistem;

- prelucrările specifice fiecărei etape;

Cu etapele ciclului de dezvoltare dispuse pe verticală şi cu aspectele sau viziunile enumerate

mai sus, dispuse pe orizontală (sub forma unui cap de tabel), am putea obţine o matrice pe

care s-o completăm cu activităţi sau obiective ce trebuie atinse în fiecare etapă CVDS, pentru

fiecare aspect sau viziune. De regulă matricea (un rezultat al interferenţei dintre etapele

CVDS şi viziuni) este completată de către cei care au elaborat metoda cu obiective (mai exact

cu CE trebuie făcut în cadrul fiecărei etape). Partea privitoare la CUM trebuie făcut, este una

descriptivă şi prea voluminoasă pentru a fi inclusă în matrice. Un exemplu de astfel de model

tabelar este matricea oferită de metoda Merise. Cât priveşte nivelul de la care privim această

matrice, acesta ar putea constitui o a treia dimensiune, ceea ce ar însemna apariţia unui cub!

Un asemenea exemplu se întâlneşte la modelul propus de CIMOSA – un cunoscut concept de

arhitectură de referinţă. De fapt şi autorii metodei Merise au introdus un CVDS pe trei

dimensiuni, dar a treia dimensiune este nivelul decizional cu privire la mersul proiectului

(ceea ce nu a prins la specialişti!)

În ce priveşte nivelul de la care se face analiza sistemului, în cadrul metodei Merise, acesta

poate fi reprezentat de-a lungul axei etapelor CVDS, în sensul că un nivel va cuprinde cel

puţin una din etapele CVDS, astfel că pe latura verticală a matricii putem materializa atât

etapele CVDS cât şi nivelul la care trebuie văzut sistemul.

Pentru ilustrarea interferenţei dintre metodă, CVDS, nivel şi viziune prezentăm mai jos

matricea Merise completată nu cu obiective de studiat, ci cu conceptele specifice fiecărei

etape, la nivelul corespunzător, pentru fiecare viziune sau aspect. Aceste tabele sunt utile

numai pentru a surprinde mai uşor interferenţa tuturor aspectelor ce trebuie avute în vedere pe

16

timpul proiectării sistemelor informatice, dar indicaţiile metodologice concrete sunt prea

voluminoase pentru a fi stocate într-o matrice.

În practică, activităţile dintr-un astfel de tabel ar trebui detaliate şi comentate pe parcursul a

câtorva capitole. De regulă fiecare etapă CVDS este tratată pe câte un capitol.

Cu privire la diversitatea modelelor ciclurilor de viaţă, trebuie să tragem următoarele

concluzii:

- modelele sunt diferite, în funcţie de tehnologiile folosite în procesul de realizare a

sistemelor; un salt considerabil se observă în mediile orientate-obiect;

- modelele depind de mărimea proiectelor dar şi de domeniile de care aparţin sistemele;

- la alegerea unui model trebuie să ţinem seamă nu numai de ordinea în care se derulează

etapele de elaborare a sistemului, ci şi de proportia în care modelul presupune abordarea

sistemului, adică pe părţi sau global. Unele modele cum ar fi cel în cascadă, presupune

parcurgerea tuturor etapelor la nivelul întregului sistem, în timp ce modelul evolutiv de

exemplu, permite derularea marii majorităţi a etapelor pe părţi/componente ale sistemului;

- alegerea modelului va depinde şi de experienţa echipei ce efectuiază proiectarea sistemului;

Viziuni

Nivele Etape

Descrieri şi

definiţii auxiliare

Comunicaţie

Date

Prelucrări

Nivel

global

Studiu

de evaluare

DDG - obiectivele sistemului

informaţional

(SI) - funcţiile

specifice

- atributele conducerii

MGC - aspecte şi principii

generale ale

comunicaţiei asociate special

pentru SIO, SII

şi SIG

MGD -soluţii previzibile - date

- cunoştinţe

- organizarea posibilă - BD, BT, BC

- combinaţii

MGP - tip - topologie

- amplasare pentru:

- prelucrări locale; -

teletransmisie

- reţele de calculatoare

Nivel

con-

cep- tual

Proiectare

concep-

tuală

DDC - domeniile

activităţii - documente de

intrare

- situaţii de ieşire

- indici sintetici

- grafice - algoritmi

-sisteme de

comunicare

MCC

-servicii

funcţionale (actori)

-fluxuri

informaţionale documente,

situaţii folosite

MCD - entitate/tip

entitate - relaţie/tip

relaţie

-proprietate/tip proprietate

- cardinalitate

(maximă, minimă)

MCP - proces

- operaţie - eveniment

- sincronizare

- reguli de gestiune

Nivel

organi-

zaţio-nal

Proiectare

organiza-

ţională

DDO

- corelaţia date

– prelucrări –

comunicări

- grila de coerenţă

globală: MCD–

MOD MCD –MOP

-reguli de

prelucrare -algoritm de

validare

MOC -comunicaţii

manuale/auto-mate/mixte

comunicaţii

între: -

compartimente

- compartimente-

conducere

- unitate- alte unit.

MOD

- tipul proprietăţilor

- număr de înregis-trări pentru entităţi şi relaţii

- cardinalitate (maximă, maximă la

95%, modală, medie) - tip de acces

(creare, adăugare, modificare,

ştergere)

MOP - repartiţia

organizatorică a proceselor de

prelucr. pe:

compartimente posturi de lucru

sarcini/faze

grad de auto- matizare (manual,

automat, mixt)

- mod de funcţionare

Nivel logic

Proiectare logică

DDL - dicţionarul

datelor

MLC -lista serviciilor

implicate

MLD MLP - listă de reguli

- listă module model

relaţional

spread

sheet

17

- descrierea

BD/BD/BC

- ordinea de

prelucrare a

Bd/BT

- corelaţia

servicii - docu-

mente - situaţii

- organizarea

generală a co-municaţiei de

date şi

prelucrări

- entitate

- dependenţă

funcţională

- cheie primară

externă

- tabelă

- celulă

- zonă de celulă

- depen-

denţă funcţională

- cheie primară

secundară

- listă comparti-

mente;

- listă sarcini;

- listă evenimente;

- listă tabele

Nivel

fizic

Proiectare

fizică

Implemen-tare

DDF

- SO, SGBD,

SGBT, GSE - meniuri de

prelucrare

- videoformate de I/E

-tranzacţii de: I,

E, I/E

MFC

- listă

echipamente - rolul şi

funcţiile FS şi

WS - protocoale de

comunicaţie

- parole de acces

-drepturi de

prelucr.

MFD MFP - procedură

- subprocedură - model

- aspect:

- funcţional - semantic

- timp real/diferit

BD BT

- tabelă

- atribut - tuplu

- cardinalitate - dimens.

- cheie

indexar

- tabelă

- celulă - tuplu

- cardinalitate - dimensiune

Exploa-

tare

Exploatare

crt.

Întreţinere Dezvoltare

de noi

versiuni

DDE

definiţii

asociate RC şi RD

- elemente

adiţionale pentru RC

RC/RD - topologie RC

- topologie RD

BD BT BD BT

- volume alocate (C:, ………..Z:)

- cataloage folosite

- identificatori (*.dbf, *.xls)

- volume alocate (C:, …….Z:)

- cataloage folosite

- identificatori (*.prg, *.exe, *.xlm

- cerinţele funcţionale îşi pun de asemenea, amprenta pe tipul de model; sistemul poate fi

abordat în întregime sau pe componente funcţionale;

- complexitatea sistemului se va reflecta în mare măsură în tipul modelului selectat.

În afară de aspectele a căror interferenţă în cadrul procesului de analiză şi proiectare a

sistemelor informatice a fost analizată mai sus, mai există şi alte aspecte a căror interferenţă

nu poate fi formalizată, dar trebuie luată în calcul de proiectanţii de sisteme informatice. Este

vorba de noutăţile care s-au înregistrat în informatică pe planul tehnicilor de programare, a

reţelelor de calculatoare şi mai ales în domeniul CASE.

In cursul precedent au fost enumerate căteva instrumente CASE asociate principalelor

metodologii de elaborare a sistemelor informatice. Este bine ca atunci când ne hotărâm să

aprofundăm o metodologie de elaborare a sistemelor informatice, să ne informăm dacă

dispune de instrumente CASE şi dacă acestea sunt accesibile. Bineînţeles că orice

metodologie poate fi aplicată şi fără a dispune de instrumentele CASE asociate acelei

metodologii, dar dacă se poate să folosim şi instrumentele CASE ritmul de muncă va fi mult

mai mare.

2. Modele reprezentative ale ciclurilor de viaţă ale dezvoltării de sisteme Modelul cascadă. Asigură trecerea de la o etapă la alta, în ordine secvenţială.

Definirea cerinţelor

Analiza

Proiectarea

Implementarea

18

Testarea

Utilizarea şi

întreţinerea

Fazele sunt structurate pe activităţi şi subactivităţi. Punctul său slab este că se aplică la nivel

sistem şi nu se poate trece la etapa următoare până ce nu au fost aduse la zi toate aplicaţiile;

în practică se solicită decalaje între aplicaţii.

Modelul V. Latura din stânga este cea de la modelul cascadă, iar pe cea din dreapta se

realizează verificările şi validările. Ea se parcurge ascendent.

Definirea cerinţelor

Proiectare Testare

sistem sistem

Proiectare Testare

subsistem subsistem (componentă) (componentă)

Codificare asamblare

componente

Modelul incremental. Permite livrarea sistemului pe componente, dar şi global. Definirea

cerinţelor şi analiza se execută totuşi la nivelul întregului sistem.

Este o metodă de tip top-down, ceea ce implică cunoaşterea şi formularea cerinţelor pentru

întregul sistem încă din faza encipientă de abordare a sistemului, chiar dacă ulterior se vor

rezolva doar părţi din el. De regulă adăugarea unei părţi presupune testarea a tot ce este

realizat până în acel moment, ceea ce poate duce la modificări multiple ale componentelor

realizate printre primele.

Definirea Proiectare Instalare cerinţelor componenta-1 componenta-1

Analiză Implementare Întreţinere

componenta-1 componenta-1

Arhitectura --- --- sistemului

Proiectare Instalare

componenta-n componenta-n

Implementare Întreţinere

componenta-n componenta-n

Valida

re

19

Modelul spirală. Este modelul cel mai des folosit în toate domeniile proiectării, acolo unde

este vorba de obiective complexe.

Prototip-1

Prototip-2

Prototip-3

Prototip-4

Modelul evolutiv. Necesită efectuarea unei investigaţii iniţiale pe baza căreia să se poată

elabora o strategie de descompunere a proiectului în părţi/segmente, fiecare cu o valoare

deosebită pentru client.

Acestea sunt sunt realizate şi livrate în mod iterativ şi contribuie la sporirea

treptată a performanţelor sistemului. Se are în vedere posibilitatea aplicării unor

adaptări sau modificări ulterioare. Studiul iniţial Integrare

Descompunere segmente

în segmente

Segment-1 Segment-2

Definire cerinţe Implementare Definire cerinţe Implementare

Analiză Testare Analiză Testare

Proiectare Utilizare Proiectare Utilizare

Metoda are succes deoarece se bazează pe o arhitectură deschisă, flexibilă, elaborată prin

participarea tuturor părţilor interesate, inclusiv a utilizatorilor şi a unor specialişti

profesionişti.

Modelul X. În partea de sus a X-ului este aplicat modelul cascadă şi V, iar în partea de jos

sunt

avute în vedere acţiuni de valorificare a softului creat anterior. Această preocupare este din

ce în ce mai extinsă pe plan mondial şi pare foarte raţională deoarece softul prezintă o mare

supleţe în ce priveşte adaptarea de la o problemă la alta. De fapt nu contează decât

asemănarea structurilor, semnificaţia variabilelor fiind la libera alegere a celui care foloseşte

softul.

Modelul realizează validarea cât mai devreme

posibil, de cât mai multe ori, prin construirea

prototipurilor, ca în figura din stânga.

Ţine seamă de natura iterativă a dezvoltării şi ia în

consideraţie nevoia de planificare şi evaluare a

riscurilor fiecărei iteraţii.

Necesită profesionalism, flexibilitate în acţiune, în

alocarea de fonduri şi în definirea activităţilor de

intreprins.

20

În partea de sus, modelul ia în consideraţie utilizarea unor specificaţii de sistem, a proiectului

arhitectural şi de detaliu , codificarea, testarea pe componente, integrarea şi testarea

sistemului. Parte inferioară a X-ului este un V întors, pentru a sugera noţiunea de gestiune

patrimonială a depozitelor reutilizabile la nivel componentă, structură, domeniu şi chiar

aplicaţie.

Având în vedere că partea inferioară a modelului se aplică practic doar în fazele de

proiectare fizică, modelul - ca şi modelul tridimensional al autorilor metodei Merise, nu este

prea popular. Dealtfel metoda Merise mai prezintă un model în două dimensiuni în care pe

abscisă este trecut sistemul actual şi cel viitor, iar pe ordonată sunt trecute nivelele global,

conceptual, organi-zaţional, logic, fizic şi de exploatare, dar după cum s-a putut vedea, din

cele prezentate în secţiu-nea 1 a acestui capitol, metoda Merise este aplicată de fapt pe un

model în două dimensiuni, sub formă de matrice care este foarte riguros şi se pretează la

exigenţele ingineriei softului.

3. Automatizarea dezvoltării sistemelor prin instrumente CASE Acronimul CASE vine de la de la Computer Aided System Engineering şi are ca obiectiv

punerea în practică a produselor- program de proiectare şi realizare a softului cu ajutorul

calculatorului. Instrumentele oferite de CASE (ca de exemplu EXCELERATOR, apărut pe la

mijlocul anilor '80), sunt utilizabile din faza de definire a cerinţelor până la întreţinerea fizică

a sistemului informatic, dar prioritate au analiza şi proiectarea bazate pe conceptele şi

metodele structurate. În ultimii ani, acestora li s-au adăugat analiza, proiectarea şi

programarea orientată pe obiecte. Instrumentele CASE implică utilizarea calculatorului ca

mijloc de susţinere a activităţilor de planificare, definire, proiectare şi realizare a softului. Ele

se bazează pe logica structurată, pe descompunerea funcţională şi reprezentarea prin

diagrame a fluxurilor de date ale aplicaţiilor.

Mijloacele CASE realizează proceduri şi metode ce prezintă diferenţe majore faţă de

metodele clasice şi care se constituie în performaţe ale acestor produse, cum ar fi:

- prezentarea logicii de proiectare a sistemului;

- posibilităţi de vizualizare a datelor;

- sprijin în definirea obiectivelor;

- definirea şi utilizarea unor termeni de referinţă;

- folosirea unui depozit partajat de date;

- uşurinţa efectuării unor schimbări;

- realizarea unei documentaţii flexibile şi dinamice;

- aplicarea unor reguli de verificare a consistenţei;

- folosirea reprezentărilor grafice simple;

- construirea de pseudocoduri structurate;

- sprijinirea modularizării;

- folosirea pe scară largă a prototipurilor;

- constituirea unei interfeţe pentru generatoarele de coduri;

- construirea bibliotecilor de module şi documente.

Pe măsura evoluţiei lor, sistemele CASE au devenit mai complexe, permiţând ca procesele de

proiectare şi realizare a aplicaţiilor să se desfăşoare într-un mediu informatic interactiv,

oferind utilizatorilor un întreg arsenal de instrumente şi proceduri, prin care pot proiecta,

realiza, testa, documenta, întreţine/actualiza şi exploata sistemul.

Utilizarea sistemelor CASE a început cu introducerea diagramelor fluxurilor de date, care fac

posibilă realizarea unui model al derulării proceselor sistemului/aplicaţiei care se proiectează.

A urmat folosirea dicţionarului de date ca un depozit al tuturor datelor privind sistemul sau

aplicaţia Au apărut ecranele predefinite pentru a prezenta ce poate să obţină utilizatorul prin

21

exploatarea sistemului. S-a apelat la facilităţi grafice, care pot folosi simbolurile logicii

structurate şi care permit proiectantului să realizeze o diagramă coerentă a fluxurilor de date.

Primele sisteme CASE erau un set de aplicaţi neintegrate, cu funcţii distincte, fără a fi

interconectate. Aceste limite au fost eliminate, în cea mai mare parte, prin generaţiile actuale,

care încearcă să realizeze o integrare completă şi uşoară a tuturor elementelor, integrarea

reprezentând de fapt, factorul cel mai imoprtant al metodologiei CASE.

CASE se bazează pe două funcţii fundamentale:

- prima este bazată pe posibilitatea descompunerii de sus în jos (top-down) a sistemului

informatic în procese şi module distincte, fiecare având definite responsabilităţile funcţionale

şi/sau operaţionale; odată cu orientarea spre obiecte, funcţiile se înlocuiesc cu obiectele care

îndeplinesc funcţia, ceea ce uşurează controlul procesului;

- a doua se referă la faptul că sistemele informaţionale pot fi reprezentate într-o formă

grafică concisă, folosind câteva simboluri de bază

Importanţa acestor funcţii rezidă în posibilitatea utilizării modularităţii aplicaţiilor, a

diagramelor, obţinerea unei documentaţii privind realizarea, evaluarea arhitecturii şi utilizarea

sistemului.

Pentru definirea şi construirea sistemelor, produsele CASE presupun stabilirea şi respectarea

unei anumite discipline. Metodologia oferă o interfaţă între crearea şi verificarea/validarea

proiectului logic, dezvoltarea unei biblioteci cu documentaţii, care include şi integrează

caracteristicile proceselor şi paşii de parcurs, pentru descrierea modului de lucru; oferă un

model al produsului final, ce poate fi folosit în realizarea operaţiilor de exploatare şi

întreţinere a sistemului/aplicaţiei şi oferă o interfaţă pentru păstrarea evoluţiei proiectului.

Folosirea reprezentărilor grafice în logica CASE oferă posibilitatea descompunerii aplicaţiei

în mai multe componente logice.

Prin ataşarea unei baze de date la elementele grafice, se va obţine un depozit ce va conţine

paşii şi funcţiile reprezentate în diagramele construite. Dacă aceste elemente sunt corect

stabilite, ele vor sta la baza descrierii proceselor, ce vor constitui procedurile de prelucrare a

sistemului /aplicaţiei.

Modelarea grafică în sistemele CASE prezintă o interactivitate ridicată, permitând construirea

diagramelor, deplasarea de la o diagramă la alta , modificarea, extinderea, copierea, evaluarea

şi descrierea elementelor unei aplicaţii. Modelele grafice permit conectarea fluxurilor logice

între activităţile şi funcţiile specifice aplicaţiei, relaţii care pot fi testate şi validate în mod

automat.

Din punct de vedere al momentului în care a avut loc automatizarea fazelor din ciclul de viaţă

al sistemelor, se consideră că analiza şi proiectarea reprezintă faze superioare, adică au fost

automatizate mai recent. Instrumentele CASE referitoare la aceste faze se numesc Upper

CASE sau Front End, iar cele referitoare la fazele care au fost automatizate primele se

numesc Lower CASE sau Back End.

Pentru că există instrumente CASE care nu pot fi legate de fazele ciclului de viaţă a

dezvoltării de sisteme, cele din categoria Upper şi Lower CASE sunt denumite CASE

Vertical, iar celelalte se numesc CASE Orizontal

Clasificarea instrumentelor CASE este dată în tabelul de pe pagina următoare.

Caracteristicile mediilor moderne de tip CASE:

- reprezintă un set de instrumente specifice pentru realizarea sistemelor;

- diversitatea modurilor de interacţiune;

- semnificaţia reprezentărilor grafice;

- elemente de tip verificare şi validare (V & V);

- natura bidirecţională, deplasări pe verticală în structura sistemului;

22

- deschiderea pentru interconectarea instrumentelor CASE;

- sprijin pentru lucru cu utilizatori multipli;

- descompunerea;

- performanţe de deplasare, pe orizontală, de la un instrument la altul;

- grade diferite de automatizare;

- integrare.

C

A

S

E

V

E

R

T

I

C

A

L

U

P

P

E

R

C

A

S

E

- analiza cerinţelor sistemului/programului;

- descrierea sistemului;

- proiectarea şi modelarea funcţională şi procedurală;

- modelarea datelor şi proiectarea bazei de date;

- generarea de coduri.

F

R

O

N

T

E

N

D

C

A

S

E

P

R

O

P

R

I

U

-

Z

I

S

L

O

W

E

R

C

A

S

E

- editoare, de regulă folosite de limbaje de programare;

- instrumente de folosire a codurilor şi modulelor;

- instrumente de referinţă încrucişată;

- mijloace de testare;

- instrumente de analiză a rezultatelor;

- depanare coduri.

B

A

C

K

E

N

D

O

C R

I

A Z

O

S N

T

E A

L

- instrumente pentru managementul proiectelor;

- mijloace de documentare;

- mijloace de gestionare a configuraţiei;

- instrumente de revizuire a cerinţelor.

Clasificarea instrumentelor CASE

23

4. Rolul sistemelor informatice în conducerea

organizaţiilor economice Remarcăm faptul că în condiţiile create de Internet, sistemul informatic se detaşează de

intreprindere şi chiar iese din cadrul ei făcând legătura directă cu băncile, cu furnizorii şi

oferă conducerii date despre mişcările pe care le execută concurenţa. Conducerea

intreprinderii moderne nu se mai mulţumeşte cu o informare operativă ci doreşte prognoze,

doreşte să prevadă viitoarele mişcări ale concurenţei şi viitoarea evoluţie a pieţei ţinând cont

de ceea ce se petrece în prezent. Deaceea chiar dacă nu proiectăm sisteme suport de decizie

sistemele informatice moderne trebuie să iasă din perimetrul intreprinderii.

În [1] Dumitru Oprea vede relaţia sistemului informatic cu intreprinderea ca în figura de pe

pagina următoare.

5. Câteva provocări ale tehnologiei informatice actuale

5.1 Programarea orientată pe obiecte. În cursul precedent este prezentat un scurt istoric al

evoluţiei analizei şi proiectării sistemelor prin metodologii orientate obiect, dar se cuvine o

precizare: sintagma "orientare-obiect" are accepţiuni diferite în diverse discipline: una în

modelarea informaţiilor, alta în programare şi alta în analiza şi proiectarea sistemelor. Pentru

a proiecta şi implementa soft orientat spre obiecte trebuie cunoscută metoda de abordare

specifică acestei paradigme şi bineînţeles un limbaj de programare adecvat.

Cât priveşte utilizarea acestei orientări în analiza şi proiectarea sistemelor, trebuie subliniat că

actualele SGBD de tip Visual, în speţă Visual Fox şi Access sunt foarte uşor de manevrat,

mai ales că bazele de date din aceste medii de programare se realizează sub formă de baze de

date relaţionale, iar utilizarea obiectelor se face foarte subtil, la nivel câmp. Obiectele intervin

vizibil numai în realizarea controalelor. Totuşi pentru cei care cunosc programarea pe obiecte

este păcat să nu ştie să folosească şi proiectarea obiectuală a sistemelor informatice, mai ales

că există şi instrumente CASE bine puse la punct şi pentru metodologiile orientate obiect

(Rational Rose, Visual Modeler, etc.)

5.2 Apariţia aplicaţiilor şi a bazelor de date multimedia, mai ales în legătură cu bazele de

date distribuite sau cu comunicaţiile pe WWW, este o chestiune care trebuie să ne pună în

stare de veghe şi dacă sistemul la care lucrăm o impune, trebuie să avem în vedere şi alte

aspecte cum ar fi reclamă pe Internet, utilizarea paginilor WEB, e-learning, punerea la

dispoziţia utilizatorilor a unui help profesionist, documentaţie online, ş. a.

5.3 Un element deloc lipsit de importanţă este softul pe care vom realiza şi pe care va fi

implemetat sistemul informatic (este vorba de interfaţa grafică/sistem de operare şi de

SGBD). Poate este util de ştiut că în ţările occidentale se lucrează mai mult sub UNIX şi

LYNUX şi mai rar sub Windows, iar ca SGBD se foloseşte foarte mult - ORACLE. Pentru o

aplicaţie care să reziste "afară", vom folosi dacă nu UNIX sau LYNUX cel puţin Windows

NT.

5.4 Apariţia inteligenţei artificiale. Aceasta, în ciuda vălului de "elită" în care este înfăşurată

nu trebuie să-i alerteze prea mult pe realizatorii de sisteme informatice obişnuite pentru că

acestea se pot realiza şi fără inteligenţă artificială, dar dacă se pune problema unor aplicaţii

menite să coordoneze procese, sau să ofere mijloace de învăţare cu ajutorul calculatorului,

sau să operăm activ pe Internet, atunci s-ar putea ca apelarea la inteligenţa artificială să fie

inevitabilă. De aceea, înainte de a începe detalierea etapelor de proiectare a sistemelor

24

informatice, vom dedica câte un curs sistemelor support de decizie şi respectiv sistemelor

expert.

26

Date

Decizii nestructurate

(neprogramate)

Decizii semistructurate

(semiprogramate)

Decizii structurate

(programate)

Informaţii diverse

SISTEM DE CONDUCERE (decizional) Nivel

strategic

Nivel

tactic

Nivel operativ

Marketing Personal Producţie Financiar Contabilitate

I

N

T

R

A

R

I

I

E

S

I

R

I

SISTEME EXTERNE Mediul

exterior

I

N

T

R

A

R

I

I

E

S

I

R

I

SISTEM CONDUS

I

E

S

I

R

I

Birotica+Sisteme ale grupurilor de lucru

Siste

me de

sprij

inire

a ex

perti

lor

SISTEM

INFORMATIONAL Sisteme de (inclusiv informatic) sprijinire a conducerii

strategice

Sisteme de sprijinire a procesului decizional

Sisteme de informare a conducerii operative

Sisteme de prelucrare a tranzacţiilor

Marketing Personal Producţie Financiar Contabilitate

INTRĂRI

Rolul sistemelor informaţionale în conducerea organizaţiilor economice

I

E

S

I

R

I

I

N

T

R

A

R

I

27

6. Concluzii 6.1 Indiferent de metodologia pe care o folosim, documentaţia de proiectare trebuie să

prezinte:

- obiectivele firmei, funcţiile specifice, atributele conducerii şi modul în care sunt derulate

activităţile ei; organigrama structurii organizatorice;

- domenii de activitate, definirea subsistemelor informatice şi/sau aplicaţiilor;

- informaţiile de care au nevoie persoanele din unitate pentru exercitarea sarcinilor ce le

revin;

- datele (tipologia, descrierea lor, volumul, mărimea, periodicitatea, amplasarea pentru

prelucrări locale, teletransmisie, reţele, etc.) vehiculate în unitate pentru fiecare loc de muncă;

- când, cum, de către cine şi ce date circulă, se transformă sau se înregistrează;

- ordinea de prelucrare şi dependenţa dintre datele trecute prin diverse activităţi desfăşurate;

- regulile prin care se specifică modul în care sunt transmise şi prelucrate datele;

- politicile şi orientările care descriu modul în care se desfăşoară activitatea unităţii, ţinându-

se cont de mediul şi piaţa în care funcţionează;

- evenimentele marcante şi momentele declanşării lor, prin care se schimbă valoarea datelor;

Aceste informaţii vor fi prezentate iniţial pentru sistemul existent şi apoi pentru cel nou

care va fi prezentat odată prin modelul său logic şi apoi prin modelul fizic. Forma de prezentare a acestor aspecte depinde de etapele

prevăzute în metodologia aleasă şi de formalismele asociate fiecărei etape, dar la

fiecare etapă va trebui să analizăm sau să specificăm detalii despre date, prelucrări şi

comunicaţii (în sensul suportului de informaţii dintre entităţile sau actorii implicaţi în fiecare

aplicaţie).

6.2 Conţinutul modelului logic şi fizic face obiectul cursurilor viitoare, dar să reţinem că

modelul sistemului informatic evoluează de la o etapă la alta pornind de la ceea ce vede

beneficiarul cu ochii celui care nu cunoaşte informatică, trece printr-un model abstract,

independent de specificul hardului care va fi folosit pentru exploatarea sistemului – modelul

logic şi se opreşte la modelul fizic unde, structura datelor, aspectul interfeţei cu utilizatorii şi

programele care vor pune sistemul în mişcare depind de platforma program, de mediul de

pro-gramare ales, de suporţii de informaţii, de arhitectura reţelei, care va deservi sistemul

informatic.

6.3 In cele mai multe metodologii elaborarea programelor nu apare ca o fază explicită ci este

inclusă în implementare, iar implementarea continuă apoi cu instruirea utilizatorilor pe baza

manualului de utilizare, instalarea softului, iniţializarea bazei de date cu nomenclatoare şi alte

date fixe sau semivariabile.

28

2.DECIZII ASISTATE

I. Sisteme suport de decizie

Utilizarea tot mai frecventă a sistemelor suport de decizie

este favorizată de apariţia de noi tehnologii în domeniul informatic şi este impusă de

volumul din ce în ce mai mare şi de diversitatea datelor ce trebuie prelucrate pentru a lua o

decizie eficientă.

Ele servesc la îmbunătăţirea eficacităţii procesului decizional (măsura în care decizia îşi

atinge obiectivele) prin faptul că oferă managerilor o informaţie de calitate şi moduri noi de

interpretare a informaţiilor.

Un sistem suport de decizie (SSD) este un sistem informatic interactiv, flexibil şi adaptabil

proiectat special pentru a oferi suport în soluţionarea unor probleme manageriale

nestructurate sau semistructurate, cu scopul de a îmbunătăţi procesul decizional. Sistemul

utilizează date interne şi externe şi modele, oferă o interfaţă simplă şi uşor de utilizat,

permite decidentului să controleze procesul decizional şi oferă suport pentru toate etapele

procesului decizional, care sunt următoarele:

- etapa de identificare şi formulare a problemei; - etapa de proiectare (identificare a alternativelor şi evaluarea lor) ; - etapa de alegere a soluţiei; - etapa de implementare a deciziei; - etapa de evaluare.

SSD-urile mai avansate pot oferi suport pentru decizii multiple independemte sau

interdependente, pentru un singur utilizator sau pentru un grup de utilizatori.

Etapele enumerate mai sus se derulează prin aplicarea diferitelor proceduri. Dacă toate

etapele unei probleme sunt structurate (procedurile prin care se desfăşoară sunt standardizate,

obiectivele fiecărei proceduri sunt clare, iar intrările şi ieşirile din procedură sunt clar

definite), avem de a face cu o problemă structurată. Într-o decizie structurată toate sau cele

mai multe dintre variabile sunt cunoscute şi pot fi complet programate.

Deciziile semistructurate pot fi programate doar parţial şi în plus necesită creativitate şi

intuiţie umană. În situaţiile decizionale nestructurate, obiectivele sunt greu de cuantificat iar

modelul situaţiei este aproape imposibil de proiectat.

SSD-urile oferă suport în soluţionarea părţilor structurabile ale deciziei. În ce priveşte părţile

nestructurate ale problemei, acestea urmează să fie rezolvate fără automatizare, direct de

decident, utilizând creativitatea sa. Cu toate acestea există o serie de factori care fac ca

utilizarea SSD să devină din ce în ce mai stringentă. Aceştia sunt legaţi de faptul că în prezent

pentru luarea deciziilor trebuie prelucrată o mare cantitate de informaţii care, de cele mai

multe ori se prezintă pe formate diferite, provin de pe platforme hardware diferite şi din

structuri de date diferite, ceea ce induce nevoia a numeroase aplicaţii folosite pentru

extragerea, pregătirea şi agregarea datelor necesare activităţii de analiză şi raportare. Mai

mult decât atât, cerinţele utilizatorilor se modifică într-o dinamică crescândă, ceea ce

determină modificarea programelor de extragere a datelor sau chiar crearea de noi programe.

La toate acestea se mai adaugă un alt aspect şi anume acela că pentru luarea deciziilor nu sunt

relevante tranzacţiile ce fac obiectul de activitate al unei firme sau organizaţie, ci datele

despre tranzacţii, adică date agregate. Pentru a se evita efectuarea tuturor prelucrărilor

enumerate mai sus de fiecare dată când se pune problema elaborării unei decizii, aceste

prelucrări se fac o singură dată, atunci când apar date noi, iar datele agregate în formă

utilizabilă pentru prelucrările necesare elaborării de decizii se depun în depozite de date.

Cu alte cuvinte, datele preluate din surse eterogene sunt curăţate de părţile inutile actului

decizional, filtrate şi transformate şi apoi stocate într-o structură ce este uşor de accesat şi

29

folosit de către utilizatorii finali pentru interogare, raportare şi analiză. Avantajele SSD nu se

limitează numai la utilizarea depozitului de date. SSD trebuie să acceseze şi să analizeze

rapid şi eficient sursele de date interne şi externe ale organizaţiei, să genereze alternative (mai

ales pentru problemele structurate) şi decizii despre criteriul de selecţie a alternativei ce va fi

propusă şi să poată face previziuni despre consecinţele aplicării acelei alternative (să facă

analize de tip what-if şi goal seeking, adică ce s-ar întâmpla dacă… şi respectiv ce obiective

aş putea atinge dacă…).

SSD-urilor nu li se poate pretinde să prezinte varianta optimă, dar folosind optimizarea sau

alte modele matematice se pot identifica soluţiile potenţiale şi se pot aranja alternativele în

concordanţă cu criteriile stabilite.

În fine SSD-urile pot fi folosite şi în etapa de implementare a deciziei, în activităţi de

comunicare a deciziei, explicare şi justificare şi chiar la evaluarea şi controlul soluţiei

implementate prin monitorizare şi raportare de excepţii.

SSD-urile sunt proiectate în general pentru anumite situaţii decizionale şi nu se pot

generaliza.

Ele îi ajută pe decidenţi, extind capacitatea lor de a lua decizii, dar nu îi înlocuiesc.

Problemele rezolvate au la bază modele care fac parte integrantă din sistem.

Un SSD poate fi definit ca un sistem informatic format din trei componente ce se interacţio-

nează: componenta de gestiune a datelor, componenta de gestiune a modelelor şi componenta

pentru asigurarea comunicaţiei. La acestea se adaugă interfaţa cu utilizatorul.

a) Componenta de gestiune a datelor. În procesul decizional din afaceri, bazat mai ales pe

cunoştinţe, datele sunt procesate în informaţii care sunt evaluate în raport de cunoştinţele

existente sau stimulează crearea de noi cunoştinţe. Putem spune că avem de aface cu o relaţie

Date-Cunoştinţe-Informaţii.

Unele sisteme de luare a deciziilor se pot baza pe relaţia Cunoştinţe-Informaţii-Date.

Aceasta presupune că există cunoştinţele necesare pentru a căuta informaţiile şi apoi datele.

Alte sisteme de luare a deciziilor se pot baza pe relaţia Informaţii-Date-Cunoştinţe.

În ultima fază a procesului decizional, informaţia este prelucrată şi se stabileşte decizia care

poate lua forma de date iar manifestarea ei conduce la noi cunoştinţe ce se vor adăuga la cele

existente.

În cele trei tipuri de relaţii de mai sus,

- datele pot fi sub formă de: date empirice, neprocesate (brute), date valabile din experienţele anterioare, date rezultate din procesul decizional curent;

- informaţiile pot fi: interne, valabile la începutul procesului decizional, obţinute din procesarea datelor sau din alte informaţii, externe, din afara organizaţiei;

- cunoştinţele pot fi: acumulate şi valabile la începutul procesului decizional, obţinute prin transformarea datelor brute în informaţii sau prin extragerea datelor finale din

informaţii, achiziţionate în timpul procesului decizional.

Datele din baza de date a SSD pot proveni din surse interne, externe şi private.

Datele interne se referă la resursele organizaţiei (umane, tehnice, financiare), la procesele,

evenimentele şi activităţile desfăşurate în acea organizaţie. Ele provin din sistemele

tranzacţionale ale organizaţiei, în funcţie de nevoile SSD ca de exemplu: contabilitate,

financiar, marketing, producţie, personal, etc.

Datele provenite din surse externe se referă la mediul înconjurător (economic, natural,

social), în care organizaţia îşi desfăşoară activitatea şi pot proveni din mijloace de informare

în masă, opiniiale clienţilor şi partenerilor, firme de cercetare a pieţii şi previziune, Internet,

etc.

Datele provenite din surse private (aparţinând unor angajaţi ai firmei), reguli interne folosite

de decidenţi pentru evaluarea datelor sau activităţilor.

30

Datele se caracterizează prin: structură, orizont de timp, agregare, volatilitate, dimensiune şi

metadate.

- în ce p