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