concepţia logică de principiu a sistemului informatic
TRANSCRIPT
-
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 INFORMAIONALE
1. Noiuni de baz i definiii Informatica: activitate pluridisciplinar orientat spre proiectarea i exploatarea sistemelor
de prelucrare a informaiilor, n scopul eficientizrii i rentabilizrii activitii umane. Dup
dicionarul explicativ DEX, informatica este tiina care se ocup cu studiul prelucrrii
informaiei cu ajutorul calculatoarelor.
Sistemul: o seciune a realitii n care se identific un ansamblu de elemente, interconectate
printr-o mulime de relaii reciproce, precum i cu mediul nconjurtor i care acioneaz n
comun n vederea realizrii unor obiective bine definite. Fiecare sistem are un comportament
specific, determinat de natura elementelor din care este compus i de relaiile dintre ele. Un
exemplu de sistem (mecanic) este cutia de vitez din compunerea automobilelor.
Sistemul informaional: o definiie sumar care ine aproape de definiia sistemului, ar
putea prezenta sistemul informaional drept ansamblul elementelor de structur
organizatoric din compunerea unei seciuni a societii umane, mpreun cu legturile
funcional-informaionale dintre ele i cu mediul social exterior, care acioneaz n comun
pentru ndeplinirea scopului i obiectivelor stabilite.
O definiie mai riguroas [3] consider sistemul informaional ca fiind un ansamblu tehnico-
organizatoric de proceduri de constatare, consemnare, culegere, verificare, transmitere,
stocare i prelucrare a datelor, n scopul satisfacerii cerinelor informaionale necesare
conducerii procesului fundamentrii i elaborrii deciziilor.
Sistemul informatic se interpune ntre sistemul condus i sistemul de management, ca n
figura de mai jos [3].
Obiectivul sistemului informaional este satisfacerea cerinelor informaionale necesare
conducerii n procesul de elaborare a deciziilor.
Activitile care se deruleaz n cadrul sistemului informaional sunt urmtoarele:
- culegerea i consemnarea datelor primare de la locurile unde au loc procesele i fenomenele economice, precum i din spaiul economic extern;
- verificarea, transmiterea i stocarea datelor pe diferii purttori tehnici de informaii; - prelucrarea manual sau automat a datelor n concordan cu cerinele conducerii; - selectarea informaiilor necesare conducerii conform principiului seleciei i
informrii prin excepie.
Sistemul informatic const din partea automatizat a sistemului informaional (utilizatorii
implicai n automatizare i cadrul organizatoric aferent) creia i se adaug i alte elemente
necesare pentru automatizarea obinerii informaiilor necesare conducerii n procesul de
SISTEMUL CONDUS
SISTEMUL DE MANAGEMENT
Resurse
- materiale
- umane
- energetice
Produse finite
Servicii prestate
Informaii din
afara sistemului
X Y
Informaii n
afara sistemului
Sistemul
informaional Informaii Decizii
-
3
fundamentare i elaborare a deciziilor i anume : echipamente (hardware), programe
(software), comunicaii, o baz tiinific i metodologic precum i baza informaional.
Baza tiinific i metodologic const din modele matematice ale proceselor i fenomenelor
economice, metode i tehnici de realizare a sistemelor informatice.
Baza informaional se refer la datele supuse prelucrrii, fluxurile informaionale, sistemele
i nomenclatoarele de coduri.
Odat cu dezvoltarea cercetrii operaionale, a teoriei deciziei, a Internetului i a
performanelor calculatoarelor, au aprut 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 comerul
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 elaborrii deciziilor, dar bineneles 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 comunicaiei i interfaa cu utilizatorii.
Sistemele expert trebuie s dispun de o baz de cunotine, o baz de fapte, un spaiu de
lucru, mecanisme rezolutive (de raionament i de inferen) mecanisme explicative i
interfaa utilizator.
n general cei care produc soft aplicativ nu prea au de ales n ce privete tipurile de sisteme
enumerate mai sus, pentru c tipul de sistem depinde de natura datelor i prelucrrilor 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 formulri mai mult calitative dect 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 cunotine.
Sistemele informatice tradiionale folosesc baze de date relaionale, dar n prezent se afirm
tot mai mult sistemele orientate obiect.
Baza de date este un sistem de colecii de date ntre care exist o interdependen logic
multipl, potrivit unor relaii prestabilite cu ocazia definirii structurii datelor, destinat
satisfacerii operative a celor mai diverse solicitri provenite din partea unor grupuri diferite
de utilizatori. Utilizatorii bazelor de date sunt: administratorul, programatorii de aplicaii 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 aplicaii nc mai folosesc fiiere.
Fiierul este o colecie de date omogene din punct de vedere al naturii, coninutului
informativ i a criteriilor de prelucrare, conservat pe o memorie extern, n concordan cu
restriciile impuse de procesul de prelucrare automat a datelor, pentru satisfacerea cerinelor
de informare a unuia sau mai muli 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 proprietilor obiectului, comportamentul poate fi
definit ca ansamblul de operaii pe care le poate executa obiectul, setul de responsabiliti
asumate sau de servicii oferite altor obiecte, iar identitatea se refer la modul de reprezentare
i de conservare a individualitii fiecrui obiect, indiferent de transformrile sau sau
schimbrile de stare prin care va trece.
Practic pentru a genera un obiect trebuie s avem definit clasa de care aparine obiectul.
-
4
Clasa seamn foarte bine cu tabelul din bazele de date, adic putem s o descriem i apoi s
generm exemplare (instane) din acea clas de obiecte numai c ea nu are numai atribute ci
are i operaii, adic comportament. O operaie este implementat printr-o metod.
Obiectele se interacioneaz prin mesaje.
In programarea cu obiecte se disting aspecte ca motenirea, polimorfismul, abstractizarea,
ncapsularea, reeutilizarea i persistena.
Analistul de sisteme informatice este specialistul care concepe i realizeaz sisteme
informatice. Aceast funcie poate fi ocupat de specialiti provenii din rndul absolvenilor
de facultate avnd specializarea matematic-informatic, cibernetic economic,
contabilitate i informatic de gestiune sau alte specializri asemntoare, dar i de ali
specialiti cu studii superioare cum ar fi ingineri, fizicieni, economisti, etc. care au fcut
ulterior cursuri de analiti-programatori.
Se impune s remarcm c elaborarea sistemelor informatice este un act de mare rspundere.
Aceast afirmaie este justificat de investiia relativ mare care trebuie fcut pentru a
informatiza o intreprindere/instituie, 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 activitii pe calculator. Ca urmare, ntre proiectant (unitatea/societatea de informa-
tic, unde sunt angajai analitii) i beneficiar, adic intreprinderea sau instituia care va folosi
sistemul informatic, se ncheie un contract avnd ca obiect realizarea sistemului informatic.
Este de la sine neles c analitii ar trebui s cunoasc specificul intreprinderii/instituiei n
care va funciona sistemul informatic, intreprindere care n raport cu unitatea de informatic
la care lucreaz analistul, este o unitate beneficiar. Cum analitii nu pot, s cunoasc
specificul tuturor unitilor beneficiare cu care ar putea veni n contact n decursul timpului,
n echipa de realizare a sistemului informatic se coopteaz i specialiti din partea unitii
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 aplicaie, pe lng faptul c rezolv problema pentru care a fost
conceput, trebuie s respecte i legislaia n domeniu, astfel nct rezultatele obinute 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, competena celor care avizeaz i
semneaz astfel de documente, termenele de elaborare, numrul de exemplare, durata lor de
pstrare, sigurana datelor, pstrarea secretului (dac este cazul), etc., pe considerentul c
problema a fost rezolvat pe calculator, nu absolv pe cel n cauz, de rspundere pentru
nclcarea legislaiei!
2. Structura sistemelor informatice n conformitate cu abordarea funcional, sistemele informatice sunt organizate pe
subsisteme, aplicaii i uniti funcionale sau proceduri logice. Pentru programatori mai sunt
relevante nc dou nivele, inferioare unitii funcionale i anume, unitatea de prelucrare sau
procedura automat i modulul program . n general, subsistemul vizeaz o funcie a unitii
beneficiare sau un domeniu de activitate din unitatea n care este conceput sistemul. Aplicaia
vizeaz o activitate, iar unitatea funcional o subactivitate sau sarcin.
Aplicaia este un pachet de programe ce servete la automatizarea prelucrrii datelor aferente
unei activiti distincte din cadrul unui domeniu de activitate (de exemplu poate exista o
aplicaie pentru elaborarea statelor de plat, denumit pe scurt aplicaia salarii). ntr-o
aplicaie 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 aplicaie complic schema funcional a aplicaiei, dar de cele mai multe
ori, prezena mai multor elemente este inevitabil.
De regul aplicaiile se deruleaz ciclic i pentru a fi mai uor trecute pe calculator, ciclul lor
de via se descompune n subactiviti cum ar fi preluarea datelor i actualizarea bazei de
date, sau cea de elaborare liste de ieire sau rapoarte, sau etapa de elaborare informaii pentru
alte aplicaii, etc.
Procedura logic sau unitatea funcional este corespondentul subactivitii din cadrul unei
aplicaii din domeniul informatizrii. Numai la acest nivel se poate face uor, trecerea direct
de la structura logic a aplicaiei la programe, ceea ce nseamn c unei uniti funcionale i
se pot asocia din softul aplicaiei, una sau mai multe uniti de prelucrare sau proceduri
automate. Ultima situaie este necesar mai ales atunci cnd i n cadrul unei uniti de
prelucrare, sunt implicate mai multe elemente de structur organizatoric.
n contextul unitilor funcionale, elementele de structur organizatoric folosesc
calculatorul n sesiuni de lucru la calculator cnd, 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 execuie, se ruleaz dup o schem logic, fr ntrerupere, pn la sfrit. De
exemplu preluarea pe calculator, validarea i stocarea fielor de pontaj pentru salarii poate
constitui o procedur n cadrul aplicaiei numit salarii. Faptul c procedura se ruleaz
ntotdeauna pn la sfrsit, 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 funcie de parametrii introdui de utilizator i de felul cum decurge rularea,
care program s se ruleze i care s fie srit, astfel nct procedura s nfptuiasc un act
coerent, raional, s permit utilizatorului s controleze situaia, mai precis s nfptuiasc o
etap sau mcar acea parte dintr-o etap din ciclul de via al unei aplicaii, care-i revine
biroului sau seciei din care face parte utilizatorul respectiv.
Exist i proceduri manuale care dei nu fac obiectul programrii, ele pregtesc prelucrarea
automat a datelor, sau dup caz, finalizeaz aceast aciune. 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 ct mai puin dependent de structura
organizatoric a intreprinderii/instituiei pentru care s-a conceput sistemul. Acest lucru
asigur sistemelor informatice o via mai lung, fcndu-le s nu depind de frecventele
schimbri de structur organizatoric, care au loc de obicei n seciunile 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. Concepia logic de principiu a sistemului informatic n seciunea 2 s-a specificat c sistemele informatice sunt structurate pe subsisteme, aplicaii,
uniti funcionale, uniti de prelucrare sau proceduri i module program. Merit remarcat
c, indiferent de nivelul su, orice component a sistemului informatic presupune intrri,
prelucrri i ieiri, iar relaiile dintre componente se realizeaz prin intermediul unei baze
informaio-nale, care exist i n sistemul informaional, dar n condiiile informatizrii, va fi
-
6
reflectat n colecii omogene de date ce pot fi organizate n baze de fiiere sau date n funcie
de sistemul specific de gestiune a datelor (SGF sau SGBD).
Concepia 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 concepie logic de principiu a
sistemului informatic. Un asemenea model cuprinde:
a) Intrrile n sistemul informatic: sunt acele modificri ale sistemului informaional care
produc schimbri n coleciile de date, adic tranzaciile externe. Adeseori, modificrile pe
care tranzaciile externe le produc direct coleciilor de date induc i un al doilea val de
modificri ale acestora, sub forma tranzaciilor interne. Astfel o factur ce nsoete o tran
de materiale venite de la furnizor este o tranzacie extern, pentru c modific soldul
materialelor cuprinse n factur, dar ea induce i o modificare a soldului furnizorului
respectiv, ceea ce este o tranzacie intern.
-
7
DOCUMENTE DE INTRARE IN SISTEMUL INFORMATIC
BAZA INFORMAIONAL NUCLEU DE INFORMAII
PRELUCRRI
SGBD sau SGF COLECII DE DATE ORGANIZATE IN FI IERE SAU IE IRI
INTRRI BAZE DE DATE TRANZACII EXTERNE
LISTE SITUAII TRANZACII INTERNE DE IE IRE
OBINUTE DE SISTEMUL
PROCEDURI INFORMATIC CREARE EXPLOATARE
ACTUALIZARE LISTARE
MODIFICRI LISTE DE ERORI
REGLAREA FENOMENELOR I PROCESELOR ECONOMICE DIN UNITATEA BENEFICIAR.
Reprezentarea schematic a concepiei logice de
principiu a sistemului informatic
Tranzaciile externe provin din exteriorul sistemului electronic de calcul, n timp ce
tranzaciile interne sunt produse de procedurile de actualizare i exploatare a coleciilor de
date. Este de datoria analistului de sisteme informatice s identifice nc din etapa de
proiectare logic efectele secundare ale intrrilor n sistem i s consemneze necesitatea
procedurilor care vor materializa aceste efecte asupra coleciilor de date, adic vor efectua
tranzaciile interne ce se impun logic.
b) Prelucrrile sistemului informatic: sunt efectuate de procedurile sistemului informatic i
prin ele se urmrete s se realizeze actualizarea i exploatarea coleciilor de date. Dac baza
informaional este format din ansamblul entitilor informaionale i a atributelor pe care
-
8
acestea le au, coleciile de date preiau numai mulimea atributelor entitilor din baza
informaional, aa numitul nucleu de informaii. Legturile dintre entiti apar atunci cnd
ele au atribute comune. Mulimea entitilor informaionale din baza informaional trebuie s
fie unic i neredundant. Ea trebuie s asigure un fond centralizat de informaii care s
asigure obinerea ieirilor solicitate de beneficiarul sistemului informatic.
c) Ieirile sistemului informatic: sunt grupate n patru categorii:
- indicatori sintetici (ex. cifra de afaceri, profitul brut, fondul de rulment, capitalul
propriu, rata rentabilitii, etc.);
- liste sau situaii de ieire, care grupeaz indicatori sintetici sau analitici sub form
de tabel;
- grafice care redau dinamica indicatorilor sintetici sau analitici;
- indicatori sintetici i analitici stocai pe suporturi magnetice care urmeaz a fi transmii altor sisteme informatice;
Dat fiind complexitatea actului de elaborare a unui sistem informatic, de-a lungul timpului
n acest domeniu s-au aplicat diferite concepii/paradigme i metodologii.
4. Metode de abordare a sistemelor informatice Nu este greu de neles c realizarea unui sistem informatic, sau doar a unei aplicaii,
presupune modelarea situaiei reale i utilizarea modelului creat, n realitatea cu care
opereaz calculatorul.
Modelarea este reprezentarea ntr-un mediu controlat, a proprietilor i/sau fenomenelor i
proceselor care caracterizeaz un obiect sau un sistem real. Cu alte cuvinte n modelare nu
exist adevr absolut; modelarea presupune abstracie i aducerea n atenie numai a unor
aspecte ale realitii 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 informaionale.
Modelul informaional este o abstracie a unei entiti i aceast abstracie poate fi fcut 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 entiti 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 informaional
real, acela pe care vrea s-l modeleze, dar nu toate viziunile sau concepiile analitilor ajung
s fie considerate paradigme. La nceputurile existenei sistemelor informatice, atenia
analitilor a fost concentrat spre latura funcional a activitii umane studiate i cum o
funcie a unui birou sau secie nu putea fi analizat i nici prelucrat n bloc, ea a fost
descompus n activiti (rezultnd aplicaiile informatice), activitile au fost descompuse n
subactiviti (rezultnd procedurile), care la rndul lor au fost descompuse n operaii, crora
n calculator le corespondeau modulele program. S-a dezvoltat n aceste condiii o abordare
funcional a sistemelor informaionale.
n informatica industrial funciei i corespunde procesul, ceea ce a dus la abordarea
orientat spre proces.
Ulterior, locul fiierelor a fost luat de bazele de date i corespunztor, locul sistemelor de
gestiune a fiierelor a fost luat de sistemele de gestiune a bazelor de date (SGBD).
Pe parcursul perfecionrii SGBD-urilor, s-a trecut la baze de date relaionale, crendu-se
impresia c elementul principal pe baza cruia trebuie perfecionate SGBD-urile l reprezint
structura datelor. Avem astfel de a face cu o abordare orientat spre date.
-
9
Cnd s-a pus problema aplicaiilor n timp real, factorul cel mai important se prea a fi
evenimentul. A aprut 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 abordrii sistemelor
informatice. Preocuprile analitilor-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 aprut astfel orientarea pe obiecte, numai c spre deosebire de celelalte abordri, 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 obine dintr-odat i nici nu se
pot realiza dup cum crede fiecare programator. Desigur la nceput aa a fost, dar pe msur
ce s-a acumulat experien, ea a fost materializat n metodologii.
Metodologia elaborrii sistemelor informatice a fost conceput iniial ca un ansamblu de
principii i indicaii, tehnici i metode grupate i ordonate ca s duc la realizarea
sistemului informatic. Cuvntul metod folosit n aceast definiie nu are nimic de a face
cu metoda-program asociat evenimentelor unui obiect i nici cu metoda de abordare a
sistemelor informaionale. Aici prin metod se nelege un set de reguli aplicabile unui
domeniu restrns din cadrul unei metodologii.
In prezent metodologia este vzut 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 informaiei, dar o metodologie de realizare a
sistemelor informatice trebuie s cuprind:
- etapele/procesele de realizare a unui sistem informatic structurate n subetape , activiti
sarcini precum i coninutul lor;
- fluxul realizrii acestor etape sau procese, subetape i activiti;
- 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;
- modalitile de conducere a proiectului (planificare, programare, urmrire) i modul de
utilizare a resurselor financiare, umane i materiale.
n legtur cu sistemele informatice se mai folosesc dou noiuni i anume ciclul de
dezvoltare a sistemului informatic i ciclul de via al dezvoltrii sistemelor.
Ciclul de via al dezvoltrii 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 pn la momentul intrrii sistemului n exploatare.
Ciclul de dezvoltare a sistemului este inclus n ciclul de via al dezvoltrii 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
informaional i de modelul ales pentru CVDS ), trebuie respectate la o scar
corespunztoare i n cazul aplicaiilor.
-
10
De altfel, este recomandabil ca i atunci cnd ne propunem s realizm doar o aplicaie, s
facem mai nti o analiz a ntregului sistem informatic, (evident "spnd" doar att de adnc
ct este necesar pentru ca aplicaia noastr s fie compatibil cu aplicaiile existente i cu cele
care vor fi realizate n viitor) i apoi s continum doar cu aplicaia ce ne intereseaz. Metoda SSADM (1982) Metoda MERISE Metoda ICI din Romania - studiul de fezabilitate;
- analiza cerinelor;
- specificarea cerinelor;
- specificarea logic;
- proiectare fizic (inclusiv
programarea);
- studiul de evaluare;
- modelarea global;
- modelarea conceptual;
- modelarea organizaional;
- logic;
- fizic;
- implementarea (inclusiv programarea).
- elaborarea temei de realizare;
- proiectarea de ansamblu;
- proiectarea de detaliu;
- elaborarea programelor;
- implementarea sistemului.
Lista metodologiilor nu se oprete 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 pn n prezent.
Ceea ce ne intereseaz este s reinem 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 aprofundm pentru a le folosi n activitatea noastr de viitor.
In acest sens remarcm c dup modul de abordare a sistemelor informatice exist
metodologii cu abordare structurat i metodologii cu abordare orientat obiecte.
Metodologiile cu abordare structurat presupun mprirea sistemului n subsisteme pe baza
funciilor sistemului (cazul abordrii funcionale) sau n funcie 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 dezvoltrii 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
incompatibiliti, ceea ce a fcut ca n 1997 s apar un standard cu privire la simboluri,
notaii, 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
urmtoarele etape:
- definirea problemei; - structurarea soluiei cu subetapele:
- stabilirea actorilor; - stabilirea cazurlor de utilizare; - stabilirea relaiilor dintre cazurile de utilizare; - construirea diagramelor cazurilor de utilizare;
- analiza sistemului care cuprinde: - identificarea cazurilor de utilizare; - diagrama cu structura domeniului claselor; - iniializarea 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 soluiei; - 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 cruia i s-a asociat i un CASE (Computer Aided System Engineering)
foarte cunoscut astzi, numit Rational Rose.
Funcionaliti de modelare UML ca i round-trip engineering (combinarea generrii
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, ntrebri
crora n RUP le corespund conceptele de rol, document i activitate.
n cazul RUP etapele ciclului de dezvoltare au o configuraie mai stranie prin faptul c dei
ele vizeaz procese, n documentaie este specificat obiectul activitii (de aceea n original
este vorba de workflow, adic fluxul de lucru).
Aceste etape/procese sunt:
- modelarea activitii; - cerine; - analiz i proiectare; - implementare; - testare; - dezvoltare; - managementul schimbrii; - 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 fiecrei etape se pot parcurge patru
faze: iniiere, elaborare, construcie i tranziie.
Ca urmare fazele i procesele de parcurs atunci cnd folosim un process de tip RUP se
reprezint mai uor sub forma unei matrici coninnd 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 intersecia 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 rndului respectiv, ponderea
fazei n cadrul procesului respectiv ca n rndul Analiz i proiectare din tabelul de mai jos
(dac n cadrul unei intersecii/casete sunt mai multe iteraii linia se va diviza corespunztor):
-
12
FAZE
Procese de
lucru
Iniiere Elaborare Construcie Tranziie
Modelare
afacere
Cerine
Analiz i
proiectare
Implementare
Testare
Dezvoltare
Procese
suport
Managementul
schimbrii
Managementul
proiectului
Mediul
Iniial Elab#1 Elab#2 Con1 Con3 Con3 Tran#1 Tran#2
Iteraii
CONCLUZII - Sistemul informaional este un ansamblu tehnico-organizatoric de proceduri de constatare,
consemnare, culegere, verificare, transmitere, stocare i prelucrare a datelor, n scopul
satisfacerii cerinelor informaionale necesare conducerii procesului fundamentrii i
elaborrii deciziilor;
- Sistemul informatic const din partea automatizat a sistemului informaional (utilizatorii
implicai n automatizare i cadrul organizatoric aferent) creia i se adaug i alte elemente
necesare pentru automatizarea obinerii informaiilor necesare conducerii n procesul de
fundamentare i elaborare a deciziilor i anume : echipamente (hardware), programe
(software), comunicaii, o baz tiinific i metodologic precum i baza informaional;
- n afara sistemelor informatice tradiionale 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 comerul
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 elaborrii sistemelor informatice este un ansamblu de principii i indicaii,
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 funcional, sistemele informatice sunt organizate pe
subsisteme, aplicaii i uniti funcionale sau proceduri logice. Pentru programatori mai sunt
-
13
relevante nc dou nivele, inferioare unitii funcionale i anume, unitatea de prelucrare sau
procedura automat i modulul program;
- Pentru automatizarea elaborrii 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 vzut ce este ciclul de dezvoltare de sisteme i am amintit despre
modelare i modelul informaional. Acum trebuie s remarcm c nivelul de la care privim
sistemul informaional difer de la o etap la alta a ciclului de dezvoltare de sisteme, iar
modelul sistemului informaional evolueaz de la o etap la alta reflectnd nivelul de la care
privim sistemul informaional. 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,
organizaional, logic i fizic, crora le vor corespunde modelele global, conceptual,
organizaional, logic i respectiv modelul fizic. Aceast evoluie a modelulului sistemului
informaional 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 proiectm sisteme informatice ndeamn s tim CE i CUM trebuie fcut n cadrul
fiecrei etape a ciclului de dezvoltare de sisteme pentru ca s obinem modelul specific acelei
etape, iar rspunsul la aceste ntrebri l ofer metodologiile.
Pentru a realiza o modelare eficient a sistemului informaional, agenii (persoanele care
joac un rol oarecare ntr-un proces ce trebuie modelat) ca i entitile care opereaz n sistem
( de exemplu documentele de intrare), trebuie implicate n model mpreun cu funciiile pe
care le ndeplinesc, cu comportamentul lor i cu datele referitoare la ele.
Prin comportament n cazul agenilor se nelege ceea ce fac ei n anumite mprejurri n
contextul funciilor lor, iar n cazul documentelor de intrare se nelege ce efecte au ele (n
contextul fluxului n care sunt implicate) asupra datelor.
n ce privete datele, exist date care determin starea agenilor sau entitilor, date de care au
nevoie pentru a-i ndeplini funciile (respectiv procesul n care sunt implicate) i date pe care
le modific sau le produc prin activitatea lor.
Diversitatea metodelor de abordare a sistemelor informaionale are de a face i cu nevoia de a
surprinde funciile, comportamentul i datele implicate n sistem, n sensul c unele metode
surprind mai uor funciile, altele redau mai uor comportamentul, iar altele evideniaz mai
bine datele. Dac am imagina un spaiu cu cele trei dimensiuni ce caracterizeaz o entitate
(funcia, comportamentul sau datele de care este legat), atunci poziia oricrei entiti n
acest spaiu va depinde de ponderea pe care o au n existena acelei entiti, funcia,
comportamentul i datele de care este legat.
Cnd analitii ncep s studieze un sistem informational, n vederea trecerii acestuia pe
calculator, ei trebuie s identifice care este trstura 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 informaional, ar trebui identificat ciclul de
via al dezvoltrii sistemului (ciclul asociat metodologiei respective), aa cum apare el n
literatura de specialitate i ar trebui s efectum operaiile specificate n cadrul metodologiei,
pentru fiecare etap.
Am precizat mai sus c de fapt n cadrul fiecrei etape, metodologia precizeaz CE i CUM
trebuie fcut. Pentru a preciza CE trebuie fcut, n metodologie sunt enumerate obiectivele
urmrite n cadrul fiecrei etape, iar pentru a preciza CUM trebuie fcut, este precizat forma
sub care se consider c se poate prezenta fiecare din aceste obiective, n cadrul
documentaiei de faz. Uneori aceast form de prezentare poate fi una grafic, dar nu una
oarecare ci respectnd forme i nscrisuri tipizate, prevzute n metodologie. O astfel de
form tipizat se formalism.
Formalism, n sensul de mai sus, nseamn un set de definiii i reguli, combinat cu un set de
tipuri de diagrame i/sau de tabele. Cele mai sofisticate formalisme le conine metoda Merise,
dar i diagramele de flux ale datelor (DFD) sau cele de tip entitate_relatie (DER) sunt tot
nite formalisme.
Numai dup ce proiectantul aplic situaiei concrete, oferit de sistemul analizat, formalismul
specific etapei, el poate ndeplini cerinele de proiectare privind documentaia de faz.
Documentaia de faz are pe de o parte rolul de a valorifica constatrile etapei curente pentru
a putea fi folosite ca punct de plecare pentru etapa urmtoare, iar pe de alt parte ea are i un
rol comunicativ n relaia cu beneficiarul pentru c prin consensul dintre proiectant i
beneficiar, proiectantul are garania c a neles cerinele beneficiarului i va realiza un
sistem care s satisfac aceste cerine. Legat de acest aspect, documentaia 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, documentaia de faz
poate constitui un factor care nclin balana n favoarea uneia sau alteia din pri, dup cum
situaia din teren corespunde sau nu cu ceea ce s-a aprobat de ctre beneficiar prin avizarea
documentaiei de faz.
Avizarea documentaiei de faz are loc nainte de a se trece la faza urmtoare.
Revenind la ideea de a realiza sistemul informatic numai prin simpla traducere n via a
specificaiilor privind CE i CUM trebuie fcut n fiecare etap a CVDS, trebuie spus c din
nefericire, lucrurile nu sunt att de simple i aceasta pentru c foarte rar ciclul de via al
dezvoltrii sistemului informatic se deruleaz secvenial 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,
ducnd la apariia 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 numr 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
iniial nu este satisfctoare.
Cauzele acestei situaii sunt multiple. Iat doar cteva dintre ele:
- pe timpul elaborrii unei variante, n sistemul analizat pot s intervin schimbri de
structur sau de funcionare;
- este mai greu s perfecionezi o aplicaie care nc nu funcioneaz, aflat doar pe hrtie,
dect una care a nceput s funcioneze; ca urmare ncepem cu ceva care urmeaz a fi
perfecionat;
-
15
- cnd am dat primul program n funciune, ncepem s comunicm mai bine cu beneficiarul;
s-ar putea ca el s constate c n-a fost bine neles, sau ceea ce a cerut nu era ceea ce dorea.
Cele mai reprezentative modele ale ciclurilor de via sunt urmtoarele: modelul cascad,
modelul V, modelul incremental, modelul spiral, modelul evolutiv, modelul piramid
(specific ingineriei informaiei orientate-obiect).
n seciunea 2 sunt prezentate n detaliu cele mai reprezentative modele ale ciclurilor de via.
Presupunnd c am identificat elementul care va fi supus analizei (funcie, 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 activitilor prevzute pentru fiecare etap, numai c nainte de
aceasta urmeaz s mai lum n calcul nc un element: viziunea (view) sau aspectul pe care-l
analizm la un moment dat pentru a realiza abstractizarea impus de modelare, adic pentru a
elabora modelul informaional. Inainte de a explica ce este viziunea, merit s remarcm c
spre deosebire de alte entiti cu care operm n viaa cotidian sistemele informatice implic
mai multe puncte de vedere (views). Aa de exemplu un motor poate fi privit din punct de
vedere al principiului de funcionare, al componentelor sale majore, deci a subansamblelor
sale i cam att, 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 realitii.
Viziunea este legat de faptul c sistemul informaional se va materializa sub forma a cel
puin 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 su am fcut referirile ce se impun
la urmtoarele aspecte:
- descrierea i definirea elementelor adiionale i auxiliare specifice etapei;
- comunicaii implicate n sistem;
- datele ce se vehiculeaz n sistem;
- prelucrrile specifice fiecrei 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 obine o matrice pe
care s-o completm cu activiti sau obiective ce trebuie atinse n fiecare etap CVDS, pentru
fiecare aspect sau viziune. De regul matricea (un rezultat al interferenei dintre etapele
CVDS i viziuni) este completat de ctre cei care au elaborat metoda cu obiective (mai exact
cu CE trebuie fcut n cadrul fiecrei etape). Partea privitoare la CUM trebuie fcut, 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. Ct privete nivelul de la care privim aceast
matrice, acesta ar putea constitui o a treia dimensiune, ceea ce ar nsemna apariia unui cub!
Un asemenea exemplu se ntlnete 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 specialiti!)
n ce privete 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
puin una din etapele CVDS, astfel c pe latura vertical a matricii putem materializa att
etapele CVDS ct i nivelul la care trebuie vzut sistemul.
Pentru ilustrarea interferenei dintre metod, CVDS, nivel i viziune prezentm mai jos
matricea Merise completat nu cu obiective de studiat, ci cu conceptele specifice fiecrei
etape, la nivelul corespunztor, pentru fiecare viziune sau aspect. Aceste tabele sunt utile
numai pentru a surprinde mai uor interferena tuturor aspectelor ce trebuie avute n vedere pe
-
16
timpul proiectrii sistemelor informatice, dar indicaiile metodologice concrete sunt prea
voluminoase pentru a fi stocate ntr-o matrice.
n practic, activitile dintr-un astfel de tabel ar trebui detaliate i comentate pe parcursul a
ctorva capitole. De regul fiecare etap CVDS este tratat pe cte un capitol.
Cu privire la diversitatea modelelor ciclurilor de via, trebuie s tragem urmtoarele
concluzii:
- modelele sunt diferite, n funcie de tehnologiile folosite n procesul de realizare a
sistemelor; un salt considerabil se observ n mediile orientate-obiect;
- modelele depind de mrimea proiectelor dar i de domeniile de care aparin 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 pri 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 majoriti a etapelor pe pri/componente ale sistemului;
- alegerea modelului va depinde i de experiena echipei ce efectuiaz proiectarea sistemului;
Viziuni
Nivele Etape
Descrieri i
definiii auxiliare
Comunicaie
Date
Prelucrri
Nivel
global
Studiu
de evaluare
DDG - obiectivele sistemului
informaional
(SI) - funciile
specifice
- atributele conducerii
MGC - aspecte i principii
generale ale
comunicaiei asociate special
pentru SIO, SII
i SIG
MGD -soluii previzibile - date
- cunotine
- organizarea posibil - BD, BT, BC
- combinaii
MGP - tip - topologie
- amplasare pentru:
- prelucrri locale; -
teletransmisie
- reele de calculatoare
Nivel
con-
cep- tual
Proiectare
concep-
tual
DDC - domeniile
activitii - documente de
intrare
- situaii de ieire
- indici sintetici
- grafice - algoritmi
-sisteme de
comunicare
MCC
-servicii
funcionale (actori)
-fluxuri
informaionale documente,
situaii folosite
MCD - entitate/tip
entitate - relaie/tip
relaie
-proprietate/tip proprietate
- cardinalitate
(maxim, minim)
MCP - proces
- operaie - eveniment
- sincronizare
- reguli de gestiune
Nivel
organi-
zaio-nal
Proiectare
organiza-
ional
DDO
- corelaia date
prelucrri
comunicri
- grila de coeren
global: MCD
MOD MCD MOP
-reguli de
prelucrare -algoritm de
validare
MOC -comunicaii
manuale/auto-mate/mixte
comunicaii
ntre: -
compartimente
- compartimente-
conducere
- unitate- alte unit.
MOD
- tipul proprietilor
- numr de nregis-trri pentru entiti i relaii
- cardinalitate (maxim, maxim la
95%, modal, medie) - tip de acces
(creare, adugare, modificare,
tergere)
MOP - repartiia
organizatoric a proceselor de
prelucr. pe:
compartimente posturi de lucru
sarcini/faze
grad de auto- matizare (manual,
automat, mixt)
- mod de funcionare
Nivel logic
Proiectare logic
DDL - dicionarul
datelor
MLC -lista serviciilor
implicate
MLD MLP - list de reguli
- list module model
relaional
spread
sheet
-
17
- descrierea
BD/BD/BC
- ordinea de
prelucrare a
Bd/BT
- corelaia
servicii - docu-
mente - situaii
- organizarea
general a co-municaiei de
date i
prelucrri
- entitate
- dependen
funcional
- cheie primar
extern
- tabel
- celul
- zon de celul
- depen-
den funcional
- 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
-tranzacii de: I,
E, I/E
MFC
- list
echipamente - rolul i
funciile FS i
WS - protocoale de
comunicaie
- parole de acces
-drepturi de
prelucr.
MFD MFP - procedur
- subprocedur - model
- aspect:
- funcional - semantic
- timp real/diferit
BD BT
- tabel
- atribut - tuplu
- cardinalitate - dimens.
- cheie
indexar
- tabel
- celul - tuplu
- cardinalitate - dimensiune
Exploa-
tare
Exploatare
crt.
ntreinere Dezvoltare
de noi
versiuni
DDE
definiii
asociate RC i RD
- elemente
adiionale 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
- cerinele funcionale i pun de asemenea, amprenta pe tipul de model; sistemul poate fi
abordat n ntregime sau pe componente funcionale;
- complexitatea sistemului se va reflecta n mare msur n tipul modelului selectat.
n afar de aspectele a cror interferen n cadrul procesului de analiz i proiectare a
sistemelor informatice a fost analizat mai sus, mai exist i alte aspecte a cror interferen
nu poate fi formalizat, dar trebuie luat n calcul de proiectanii de sisteme informatice. Este
vorba de noutile care s-au nregistrat n informatic pe planul tehnicilor de programare, a
reelelor de calculatoare i mai ales n domeniul CASE.
In cursul precedent au fost enumerate cteva instrumente CASE asociate principalelor
metodologii de elaborare a sistemelor informatice. Este bine ca atunci cnd ne hotrm s
aprofundm o metodologie de elaborare a sistemelor informatice, s ne informm dac
dispune de instrumente CASE i dac acestea sunt accesibile. Bineneles c orice
metodologie poate fi aplicat i fr 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 dezvoltrii de sisteme Modelul cascad. Asigur trecerea de la o etap la alta, n ordine secvenial.
Definirea cerinelor
Analiza
Proiectarea
Implementarea
-
18
Testarea
Utilizarea i
ntreinerea
Fazele sunt structurate pe activiti i subactiviti. Punctul su slab este c se aplic la nivel
sistem i nu se poate trece la etapa urmtoare pn ce nu au fost aduse la zi toate aplicaiile;
n practic se solicit decalaje ntre aplicaii.
Modelul V. Latura din stnga este cea de la modelul cascad, iar pe cea din dreapta se
realizeaz verificrile i validrile. Ea se parcurge ascendent.
Definirea cerinelor
Proiectare Testare
sistem sistem
Proiectare Testare
subsistem subsistem (component) (component)
Codificare asamblare
componente
Modelul incremental. Permite livrarea sistemului pe componente, dar i global. Definirea
cerinelor i analiza se execut totui la nivelul ntregului sistem.
Este o metod de tip top-down, ceea ce implic cunoaterea i formularea cerinelor pentru
ntregul sistem nc din faza encipient de abordare a sistemului, chiar dac ulterior se vor
rezolva doar pri din el. De regul adugarea unei pri presupune testarea a tot ce este
realizat pn n acel moment, ceea ce poate duce la modificri multiple ale componentelor
realizate printre primele.
Definirea Proiectare Instalare cerinelor componenta-1 componenta-1
Analiz Implementare ntreinere
componenta-1 componenta-1
Arhitectura --- --- sistemului
Proiectare Instalare
componenta-n componenta-n
Implementare ntreinere
componenta-n componenta-n
Valida
re
-
19
Modelul spiral. Este modelul cel mai des folosit n toate domeniile proiectrii, acolo unde
este vorba de obiective complexe.
Prototip-1
Prototip-2
Prototip-3
Prototip-4
Modelul evolutiv. Necesit efectuarea unei investigaii iniiale pe baza creia s se poat
elabora o strategie de descompunere a proiectului n pri/segmente, fiecare cu o valoare
deosebit pentru client.
Acestea sunt sunt realizate i livrate n mod iterativ i contribuie la sporirea
treptat a performanelor sistemului. Se are n vedere posibilitatea aplicrii unor
adaptri sau modificri ulterioare. Studiul iniial Integrare
Descompunere segmente
n segmente
Segment-1 Segment-2
Definire cerine Implementare Definire cerine Implementare
Analiz Testare Analiz Testare
Proiectare Utilizare Proiectare Utilizare
Metoda are succes deoarece se bazeaz pe o arhitectur deschis, flexibil, elaborat prin
participarea tuturor prilor interesate, inclusiv a utilizatorilor i a unor specialiti
profesioniti.
Modelul X. n partea de sus a X-ului este aplicat modelul cascad i V, iar n partea de jos
sunt
avute n vedere aciuni de valorificare a softului creat anterior. Aceast preocupare este din
ce n ce mai extins pe plan mondial i pare foarte raional deoarece softul prezint o mare
suplee n ce privete adaptarea de la o problem la alta. De fapt nu conteaz dect
asemnarea structurilor, semnificaia variabilelor fiind la libera alegere a celui care folosete
softul.
Modelul realizeaz validarea ct mai devreme
posibil, de ct mai multe ori, prin construirea
prototipurilor, ca n figura din stnga.
ine seam de natura iterativ a dezvoltrii i ia n
consideraie nevoia de planificare i evaluare a
riscurilor fiecrei iteraii.
Necesit profesionalism, flexibilitate n aciune, n
alocarea de fonduri i n definirea activitilor de
intreprins.
-
20
n partea de sus, modelul ia n consideraie utilizarea unor specificaii 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 noiunea de gestiune
patrimonial a depozitelor reutilizabile la nivel component, structur, domeniu i chiar
aplicaie.
Avnd 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-zaional, logic, fizic i de exploatare, dar dup cum s-a putut vedea, din
cele prezentate n seciu-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
exigenele ingineriei softului.
3. Automatizarea dezvoltrii 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, aprut pe la
mijlocul anilor '80), sunt utilizabile din faza de definire a cerinelor pn la ntreinerea fizic
a sistemului informatic, dar prioritate au analiza i proiectarea bazate pe conceptele i
metodele structurate. n ultimii ani, acestora li s-au adugat analiza, proiectarea i
programarea orientat pe obiecte. Instrumentele CASE implic utilizarea calculatorului ca
mijloc de susinere a activitilor de planificare, definire, proiectare i realizare a softului. Ele
se bazeaz pe logica structurat, pe descompunerea funcional i reprezentarea prin
diagrame a fluxurilor de date ale aplicaiilor.
Mijloacele CASE realizeaz proceduri i metode ce prezint diferene majore fa de
metodele clasice i care se constituie n performae ale acestor produse, cum ar fi:
- prezentarea logicii de proiectare a sistemului;
- posibiliti de vizualizare a datelor;
- sprijin n definirea obiectivelor;
- definirea i utilizarea unor termeni de referin;
- folosirea unui depozit partajat de date;
- uurina efecturii unor schimbri;
- realizarea unei documentaii flexibile i dinamice;
- aplicarea unor reguli de verificare a consistenei;
- folosirea reprezentrilor grafice simple;
- construirea de pseudocoduri structurate;
- sprijinirea modularizrii;
- folosirea pe scar larg a prototipurilor;
- constituirea unei interfee pentru generatoarele de coduri;
- construirea bibliotecilor de module i documente.
Pe msura evoluiei lor, sistemele CASE au devenit mai complexe, permind ca procesele de
proiectare i realizare a aplicaiilor s se desfoare ntr-un mediu informatic interactiv,
oferind utilizatorilor un ntreg arsenal de instrumente i proceduri, prin care pot proiecta,
realiza, testa, documenta, ntreine/actualiza i exploata sistemul.
Utilizarea sistemelor CASE a nceput cu introducerea diagramelor fluxurilor de date, care fac
posibil realizarea unui model al derulrii proceselor sistemului/aplicaiei care se proiecteaz.
A urmat folosirea dicionarului de date ca un depozit al tuturor datelor privind sistemul sau
aplicaia Au aprut ecranele predefinite pentru a prezenta ce poate s obin utilizatorul prin
-
21
exploatarea sistemului. S-a apelat la faciliti 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 aplicai neintegrate, cu funcii distincte, fr a fi
interconectate. Aceste limite au fost eliminate, n cea mai mare parte, prin generaiile actuale,
care ncearc s realizeze o integrare complet i uoar a tuturor elementelor, integrarea
reprezentnd de fapt, factorul cel mai imoprtant al metodologiei CASE.
CASE se bazeaz pe dou funcii fundamentale:
- prima este bazat pe posibilitatea descompunerii de sus n jos (top-down) a sistemului
informatic n procese i module distincte, fiecare avnd definite responsabilitile funcionale
i/sau operaionale; odat cu orientarea spre obiecte, funciile se nlocuiesc cu obiectele care
ndeplinesc funcia, ceea ce uureaz controlul procesului;
- a doua se refer la faptul c sistemele informaionale pot fi reprezentate ntr-o form
grafic concis, folosind cteva simboluri de baz
Importana acestor funcii rezid n posibilitatea utilizrii modularitii aplicaiilor, a
diagramelor, obinerea unei documentaii 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 documentaii, care include i integreaz
caracteristicile proceselor i paii de parcurs, pentru descrierea modului de lucru; ofer un
model al produsului final, ce poate fi folosit n realizarea operaiilor de exploatare i
ntreinere a sistemului/aplicaiei i ofer o interfa pentru pstrarea evoluiei proiectului.
Folosirea reprezentrilor grafice n logica CASE ofer posibilitatea descompunerii aplicaiei
n mai multe componente logice.
Prin ataarea unei baze de date la elementele grafice, se va obine un depozit ce va conine
paii i funciile 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 /aplicaiei.
Modelarea grafic n sistemele CASE prezint o interactivitate ridicat, permitnd construirea
diagramelor, deplasarea de la o diagram la alta , modificarea, extinderea, copierea, evaluarea
i descrierea elementelor unei aplicaii. Modelele grafice permit conectarea fluxurilor logice
ntre activitile i funciile specifice aplicaiei, relaii 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
dezvoltrii 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 urmtoare.
Caracteristicile mediilor moderne de tip CASE:
- reprezint un set de instrumente specifice pentru realizarea sistemelor;
- diversitatea modurilor de interaciune;
- semnificaia reprezentrilor grafice;
- elemente de tip verificare i validare (V & V);
- natura bidirecional, deplasri pe vertical n structura sistemului;
-
22
- deschiderea pentru interconectarea instrumentelor CASE;
- sprijin pentru lucru cu utilizatori multipli;
- descompunerea;
- performane 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 cerinelor sistemului/programului;
- descrierea sistemului;
- proiectarea i modelarea funcional 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 ncruciat;
- 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 configuraiei;
- instrumente de revizuire a cerinelor.
Clasificarea instrumentelor CASE
-
23
4. Rolul sistemelor informatice n conducerea
organizaiilor economice Remarcm faptul c n condiiile create de Internet, sistemul informatic se detaeaz de
intreprindere i chiar iese din cadrul ei fcnd legtura direct cu bncile, cu furnizorii i
ofer conducerii date despre micrile pe care le execut concurena. Conducerea
intreprinderii moderne nu se mai mulumete cu o informare operativ ci dorete prognoze,
dorete s prevad viitoarele micri ale concurenei i viitoarea evoluie a pieei innd cont
de ceea ce se petrece n prezent. Deaceea chiar dac nu proiectm sisteme suport de decizie
sistemele informatice moderne trebuie s ias din perimetrul intreprinderii.
n [1] Dumitru Oprea vede relaia sistemului informatic cu intreprinderea ca n figura de pe
pagina urmtoare.
5. Cteva provocri ale tehnologiei informatice actuale
5.1 Programarea orientat pe obiecte. n cursul precedent este prezentat un scurt istoric al
evoluiei analizei i proiectrii sistemelor prin metodologii orientate obiect, dar se cuvine o
precizare: sintagma "orientare-obiect" are accepiuni diferite n diverse discipline: una n
modelarea informaiilor, 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 bineneles un limbaj de programare adecvat.
Ct privete utilizarea acestei orientri n analiza i proiectarea sistemelor, trebuie subliniat c
actualele SGBD de tip Visual, n spe Visual Fox i Access sunt foarte uor de manevrat,
mai ales c bazele de date din aceste medii de programare se realizeaz sub form de baze de
date relaionale, iar utilizarea obiectelor se face foarte subtil, la nivel cmp. Obiectele intervin
vizibil numai n realizarea controalelor. Totui pentru cei care cunosc programarea pe obiecte
este pcat 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 Apariia aplicaiilor i a bazelor de date multimedia, mai ales n legtur cu bazele de
date distribuite sau cu comunicaiile pe WWW, este o chestiune care trebuie s ne pun n
stare de veghe i dac sistemul la care lucrm o impune, trebuie s avem n vedere i alte
aspecte cum ar fi reclam pe Internet, utilizarea paginilor WEB, e-learning, punerea la
dispoziia utilizatorilor a unui help profesionist, documentaie 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 interfaa 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 folosete foarte mult - ORACLE. Pentru o
aplicaie care s reziste "afar", vom folosi dac nu UNIX sau LYNUX cel puin Windows
NT.
5.4 Apariia inteligenei artificiale. Aceasta, n ciuda vlului de "elit" n care este nfurat
nu trebuie s-i alerteze prea mult pe realizatorii de sisteme informatice obinuite pentru c
acestea se pot realiza i fr inteligen artificial, dar dac se pune problema unor aplicaii
menite s coordoneze procese, sau s ofere mijloace de nvare cu ajutorul calculatorului,
sau s operm activ pe Internet, atunci s-ar putea ca apelarea la inteligena artificial s fie
inevitabil. De aceea, nainte de a ncepe detalierea etapelor de proiectare a sistemelor
-
24
informatice, vom dedica cte un curs sistemelor support de decizie i respectiv sistemelor
expert.
-
26
Date
Decizii nestructurate
(neprogramate)
Decizii semistructurate
(semiprogramate)
Decizii structurate
(programate)
Informaii diverse
SISTEM DE CONDUCERE (decizional) Nivel
strategic
Nivel
tactic
Nivel operativ
Marketing Personal Producie 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 tranzaciilor
Marketing Personal Producie Financiar Contabilitate
INTRRI
Rolul sistemelor informaionale n conducerea organizaiilor 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, documentaia de proiectare trebuie s
prezinte:
- obiectivele firmei, funciile specifice, atributele conducerii i modul n care sunt derulate
activitile ei; organigrama structurii organizatorice;
- domenii de activitate, definirea subsistemelor informatice i/sau aplicaiilor;
- informaiile de care au nevoie persoanele din unitate pentru exercitarea sarcinilor ce le
revin;
- datele (tipologia, descrierea lor, volumul, mrimea, periodicitatea, amplasarea pentru
prelucrri locale, teletransmisie, reele, etc.) vehiculate n unitate pentru fiecare loc de munc;
- cnd, cum, de ctre cine i ce date circul, se transform sau se nregistreaz;
- ordinea de prelucrare i dependena dintre datele trecute prin diverse activiti desfurate;
- regulile prin care se specific modul n care sunt transmise i prelucrate datele;
- politicile i orientrile care descriu modul n care se desfoar activitatea unitii, inndu-
se cont de mediul i piaa n care funcioneaz;
- evenimentele marcante i momentele declanrii lor, prin care se schimb valoarea datelor;
Aceste informaii vor fi prezentate iniial pentru sistemul existent i apoi pentru cel nou
care va fi prezentat odat prin modelul su logic i apoi prin modelul fizic. Forma de prezentare a acestor aspecte depinde de etapele
prevzute n metodologia aleas i de formalismele asociate fiecrei etape, dar la
fiecare etap va trebui s analizm sau s specificm detalii despre date, prelucrri i
comunicaii (n sensul suportului de informaii dintre entitile sau actorii implicai n fiecare
aplicaie).
6.2 Coninutul modelului logic i fizic face obiectul cursurilor viitoare, dar s reinem c
modelul sistemului informatic evolueaz de la o etap la alta pornind de la ceea ce vede
beneficiarul cu ochii celui care nu cunoate informatic, trece printr-un model abstract,
independent de specificul hardului care va fi folosit pentru exploatarea sistemului modelul
logic i se oprete la modelul fizic unde, structura datelor, aspectul interfeei cu utilizatorii i
programele care vor pune sistemul n micare depind de platforma program, de mediul de
pro-gramare ales, de suporii de informaii, de arhitectura reelei, 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, iniializarea 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 apariia 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 mbuntirea eficacitii procesului decizional (msura n care decizia i
atinge obiectivele) prin faptul c ofer managerilor o informaie de calitate i moduri noi de
interpretare a informaiilor.
Un sistem suport de decizie (SSD) este un sistem informatic interactiv, flexibil i adaptabil
proiectat special pentru a oferi suport n soluionarea unor probleme manageriale
nestructurate sau semistructurate, cu scopul de a mbunti procesul decizional. Sistemul
utilizeaz date interne i externe i modele, ofer o interfa simpl i uor de utilizat,
permite decidentului s controleze procesul decizional i ofer suport pentru toate etapele
procesului decizional, care sunt urmtoarele:
- etapa de identificare i formulare a problemei; - etapa de proiectare (identificare a alternativelor i evaluarea lor) ; - etapa de alegere a soluiei; - 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 desfoar sunt standardizate,
obiectivele fiecrei proceduri sunt clare, iar intrrile i ieirile 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 parial i n plus necesit creativitate i
intuiie uman. n situaiile decizionale nestructurate, obiectivele sunt greu de cuantificat iar
modelul situaiei este aproape imposibil de proiectat.
SSD-urile ofer suport n soluionarea prilor structurabile ale deciziei. n ce privete prile
nestructurate ale problemei, acestea urmeaz s fie rezolvate fr automatizare, direct de
decident, utiliznd creativitatea sa. Cu toate acestea exist o serie de factori care fac ca
utilizarea SSD s devin din ce n ce mai stringent. Acetia sunt legai de faptul c n prezent
pentru luarea deciziilor trebuie prelucrat o mare cantitate de informaii 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 aplicaii folosite pentru
extragerea, pregtirea i agregarea datelor necesare activitii de analiz i raportare. Mai
mult dect att, cerinele utilizatorilor se modific ntr-o dinamic crescnd, 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 tranzaciile ce fac obiectul de activitate al unei firme sau organizaie, ci datele
despre tranzacii, adic date agregate. Pentru a se evita efectuarea tuturor prelucrrilor
enumerate mai sus de fiecare dat cnd se pune problema elaborrii unei decizii, aceste
prelucrri se fac o singur dat, atunci cnd apar date noi, iar datele agregate n form
utilizabil pentru prelucrrile necesare elaborrii de decizii se depun n depozite de date.
Cu alte cuvinte, datele preluate din surse eterogene sunt curate de prile inutile actului
decizional, filtrate i transformate i apoi stocate ntr-o structur ce este uor de accesat i
-
29
folosit de ctre 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 organizaiei, s genereze alternative (mai
ales pentru problemele structurate) i decizii despre criteriul de selecie a alternativei ce va fi
propus i s poat face previziuni despre consecinele aplicrii acelei alternative (s fac
analize de tip what-if i goal seeking, adic ce s-ar ntmpla 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 soluiile poteniale 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 activiti de
comunicare a deciziei, explicare i justificare i chiar la evaluarea i controlul soluiei
implementate prin monitorizare i raportare de excepii.
SSD-urile sunt proiectate n general pentru anumite situaii decizionale i nu se pot
generaliza.
Ele i ajut pe decideni, 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 interacio-
neaz: componenta de gestiune a datelor, componenta de gestiune a modelelor i componenta
pentru asigurarea comunicaiei. La acestea se adaug interfaa cu utilizatorul.
a) Componenta de gestiune a datelor. n procesul decizional din afaceri, bazat mai ales pe
cunotine, datele sunt procesate n informaii care sunt evaluate n raport de cunotinele
existente sau stimuleaz crearea de noi cunotine. Putem spune c avem de aface cu o relaie
Date-Cunotine-Informaii.
Unele sisteme de luare a deciziilor se pot baza pe relaia Cunotine-Informaii-Date.
Aceasta presupune c exist cunotinele necesare pentru a cuta informaiile i apoi datele.
Alte sisteme de luare a deciziilor se pot baza pe relaia Informaii-Date-Cunotine.
n ultima faz a procesului decizional, informaia este prelucrat i se stabilete decizia care
poate lua forma de date iar manifestarea ei conduce la noi cunotine ce se vor aduga la cele
existente.
n cele trei tipuri de relaii de mai sus,
- datele pot fi sub form de: date empirice, neprocesate (brute), date valabile din experienele anterioare, date rezultate din procesul decizional curent;
- informaiile pot fi: interne, valabile la nceputul procesului decizional, obinute din procesarea datelor sau din alte informaii, externe, din afara organizaiei;
- cunotinele pot fi: acumulate i valabile la nceputul procesului decizional, obinute prin transformarea datelor brute n informaii sau prin extragerea datelor finale din
informaii, achiziionate 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 organizaiei (umane, tehnice, financiare), la procesele,
evenimentele i activitile desfurate n acea organizaie. Ele provin din sistemele
tranzacionale ale organizaiei, n funcie de nevoile SSD ca de exemplu: contabilitate,
financiar, marketing, producie, personal, etc.
Datele provenite din surse externe se refer la mediul nconjurtor (economic, natural,
social), n care organizaia i desfoar activitatea i pot proveni din mijloace de informare
n mas, opiniiale clienilor i partenerilor, firme de cercetare a pieii i previziune, Internet,
etc.
Datele provenite din surse private (aparinnd unor angajai ai firmei), reguli interne folosite
de decideni pentru evaluarea datelor sau activitilor.
-
30
Datele se caracterizeaz prin: structur, orizont de timp, agregare, volatilitate, dimensiune i
metadate.
- n ce privete structura datelor, ele pot fi stocate n baze de date relaionale (eventual n relaii normalizate), dar cel mai adesea n depozite de date (repozitory), sub form
de agregri ale datelor operaionale, care au format i structur diferit de cea a
datelor din sistemele operaionale;
- orizontul de timp se reflect n faptul c datele din baza de date SSD sunt fotografii ale datelor operaionale la anumite momente de timp, deci sunt serii de timp ale
datelor operaionale;
- agregatele faciliteaz efectuarea analizelor complexe; - datele operaionale fiind date curente se volatilizeaz; datele din baza de date a SSD
nu sunt volatile, adic nu se mai modific, dar lor li se adaug alte fotografii.
- datele operaionale au o singur dimensiune, n timp ce datele din baza de date a SSD pot fi corelate n diferite moduri (de ex. Cte produse s-au primit n trimestrul I al
anului curent, de la furnizorul X?) ;
- metadatele sunt date referitoare la date: dicionar de date, descrieri ale tipurilor de date din baza de date, tipul surselor de date, formate de date, lungimi ale cmpurilor.
Datele operaionale pot dispune i ele de un dicionar al datelor dar mult mai subire,
adic conine mai puine elemente. Deoarece datele din baza de date a SSD provin din
surse diferite i fiecare surs poate avea metadatele sale specifice, mai poate fi folosit
i un catalog al metadatelor.
b) Componenta de gestiune a modelelor execut ncrcarea, stocare i organizarea
diferitelor modele cantitative ce ofer faciliti analitice sistemului suport de decizie. Ea
este format din: baza de modele, sistemul de gestiune a bazei de modele, catalogul de
modele, procesorul de execuie, integrare i comandare a modelului.
- Baza de modele conine diferite modele statistice, financiare matematice i alte modele
can-titative utilizate pentru executarea diferitelor analize. Baza de modele este ceea ce
difereniaz un SSD de alte sisteme informatice. SSD trebuie s poat executa, modifica
i controla modelele.
Dup nivelul de conducere la care sunt folosite, modelele se clasific n modele
strategice, tactice i operaionale.
Modelele strategice sunt n general foarte complexe, cu multe variabile, cu un orizont larg
de timp (de regul n ani), au tendina de a fi descriptive i mai puin de optimizare,
folosesc mai mult date externe dect interne.
Modele tactice sunt folosite n activitatea de alocare i control a resurselor, fiecare fiind
dedicat unei activiti, orizontul de timp se ntinde dela o lun la doi ani, folosesc foarte
multe date interne i mai puin externe, pot fi att optimizate ct i descriptive.
Modelele operaionale sunt folosite n activitile zilnice (controlul calitii, planificarea
produciei), orizontul de timp este mic (o lun) i folosesc foarte multe date interne.
Dup aria funcional modelele se clasific n: financiare, modele de contabilitate, modele
de control a produciei, etc.
- Sistemul de gestiune a bazei de modele este folosit pentru a gestiona baza de modele i
are urmtoarele funcii:
- posed un limbaj de modelare necesar pentru crearea modelelor decizionale n
concordan cu cerinele utilizatorilor;
- permite integrarea modelelor prin controlul odinii de execuie a modelelor;
- permite utilizatorului s modifice modelele pentru a reflecta cerinele sale;
- permite utilizatorului s manipuleze modelele pentru a realiza scenarii i analize
complexe;
-
31
- ofer un catalog al modelelor stocate, cu o descriere a funciilor lor i a aplicaiilor la
care sunt folosite.
- Catalogul de modele conine definiiile modelelor, descrierea funciilor i a aplicaiilor
la care sunt folosite. Deoarece selecia unui model implic experien din partea
sistemului, la un SSD aceasta trebuie fcut de utilizator.
Numai Sistemele Expert pot face selecia de model.
c) Componenta pentru asigurarea comunicaiei vizeaz arhitectura SSD, problemele de
securitate i de reea.
O arhitectur SSD poate fi reprezentat pe patru nivele:
- diagrama proceselor care arat fluxul proceselor din activitatea analizat;
- arhitectura sistemului care se refer la componentele software;
- arhitectura tehnic care se refer la hardware, protocoale i tipul de reea;
- arhitectura de livrare a SSD-ului care pune accent pe ieirile sistemului.
O arhitectur bine definit i ajut pe decideni s lucreze mpreun i crete capacitatea
echipei de a comunica cu managerii. Reelele de calculatoare sunt elementul critic al
infrastructurii informatice.
Cu privire la planul de securitate, administratorii de sistem i managerii trebuie s in
cont de factorii urmtori: importana sistemului, valabilitatea lui i a datelor stocate,
volumul de effort cerut pentru a asigura securitatea sistemului i modul n care planul de
securitate stabilit afecteaz utilizatorii sistemului.
d) Interfaa cu utilizatorul conine urmtoarele componente:
- limbajul de comunicare care permite intreraciunea cu SSD, ofer suport pentru comunicare
ntre utilizatorii sistemului;
- limbajul de prezentare care permite prezentarea datelor ntr-o varietate de formate; de el in
i imprimantele, plotterele, monitoarele video i audio i sintetizorul de voci; servete pentru
transmiterea informaiilor i comenzilor la SSD;
La proiectarea interfeei trebuie s avem n vedere factori asociai cu interaciunea uman
cum ar fi accesibilitatea, uurina de utilizare, nivelul de ndemnare, capturarea erorilor i
raportarea lor.
e) Utilizatorul Proiectarea, implementarea i utilizarea SSD pot fi complete numai dac se
are n vedere rolul utilizatorului, care se manifest prin ndemnarea acestuia, motivaia sa,
domeniul su de cunotine, tiparele de utilizare i rolul su n cadrul organizaiei.
Utilizatorul este definit ca persoana sau persoanele responsabile pentru furnizarea unei soluii
la problema analizat sau pentru luarea unei decizii, n contextul n care a fost construit SSD