Ramona VASILESCU [614721]
Ramona VASILESCU
SISTEME INFORMATICE DE
CONTABILITATE
ISBN 978-973-687-710-0
UNIVERSITATEA TIBISCUS TIMI ȘOARA
Facultatea de Științe Economice
Lect. drd. Ramona VASILESCU
SISTEME INFORMATICE DE
CONTABILITATE
Note de curs pentru uzul studen ților de la ÎFR
Editura Eurostampa
TIMIȘOARA
2008
5
CUPRINS
Cuprins …………………………………………………………………………………………….. 5
Tema 1. Sistemul informatic – instrument al contabilit ății………………………. 7
1.1 Date, informa ții, sistem informa țional…………………………………………..7
1.2 Locul și rolul sistemului inform atic de contabilitate……………………..11
1.3 Componentele sistemului info rmatic de contabilitate ……………………13
Tema 2. Caracteristicile program elor de contabilitate…………………………… 18
2.1 Caracteristici de calitate…………………………………………………………….18 2.2 Constrângeri ……………………………………………………………………………23
Tema 3. Realizarea sistemelor info rmatice de contabilitate …………………… 27
3.1. Metodologii de realizare a sistemel or informatice de contabilitate…27
3.2 Metoda Unified Modeling Language. Prezentare …………………………31
Tema 4. Modelarea sistemului informatic de contabilitate…………………….. 37
4.1 Specifica ții generale ale metodei Unified Modeling Language ………37
4.2 Diagrame utilizate de UML……………………………………………………….42
Tema 5. Analiza sistemului informatic de contabilitate existent…………….. 52
5.1 Obiectivele analizei ………………………………………………………………….52 5.2 Elaborarea modelului fizic al sistemului existent………………………….54 5.3 Elaborarea modelului logic al sistemului existent…………………………63 5.4 Alegerea unui nou sistem info rmatic de contabilitate ……………………65
Tema 6. Securitatea și controlul sistemelor info rmaticE de contabilitate … 72
6.1 Securitatea și valoarea informa ției ……………………………………………..72
6.2 Surse de riscuri ………………………………………………………………………..75 6.3 Auditul sistemelor inform atice de contabilitate…………………………….79
6
7
TEMA 1. SISTEMUL INFORMATIC – INSTRUMENT AL
CONTABILIT ĂȚII
CONȚINUT
1.1. Date, informa ții, sistem informa țional
1.2. Locul și rolul sistemului informatic de contabilitate
1.3. Componentele sistemului in formatic de contabilitate
REZUMAT
Orice analiz ă economic ă a unei unit ăți economice are la baz ă
informația, privită ca o resurs ă, și modul în care aceasta este vehiculat ă.
Culegerea, stocarea, prelucrarea, analiza și transmiterea informa țiilor sunt
activități care trebuie s ă foloseasc ă eficient și eficace resursele
informaționale și umane cu scopul ob ținerii succesului economic. În aceste
condiții contabilitatea necesit ă existența unui sistem informatic de
contabilitate performant, care s ă respecte anumite cerin țe organiza ționale și
legislative.
OBIECTIVE
Tema propus ă are ca scop:
• definirea sistemelor inform atice de contabilitate;
• stabilirea locului și rolului unui sistem informatic într-o unitate
economice.
1.1 DATE, INFORMA ȚII, SISTEM INFORMA ȚIONAL
Leg ăturile dintre diversele p ărți ale unei entit ăți economice trebuie
să satisfacă cerințe de calitate și promptitudine care pot proveni fie din
interiorul entit ății economice (cum ar fi cele provenite de la nivelele
ierarhice superioare) fie din exteriorul entit ății economice (de exemplu de la
clientul care vrea s ă știe starea în care se afl ă execuția unei comenzi lansate
în produc ție). Orice analiz ă economic ă a unei entit ăți economice are la baz ă
informația și modul în care aceasta este vehiculat ă, astfel încât degradarea ei
să fie minim ă și fără pierderi de semnifica ție. Defini țiile informa ției sunt
numeroase și presupun cunoa șterea semnifica ției noțiunilor prin care este
definită și, de multe ori, a contextului pentru care a fost definit ă. Astfel se
vorbește despre informa ție ca despre „comunicare, veste, știre care pune pe
cineva la curent cu o situa ție1”, „informa ție genetic ă”, „informa ție
contabilă” ș.a.m.d. Din punct de vedere economic, informa ția este privit ă ca
o resursă care poate îmbun ătăți raportul cost-eficien ță. Bine înțeles că era
informaticii în care tr ăim, aflată la debutul ei, și-a pus deja puternic
amprenta asupra modului în care acest ra port poate fi modificat, raport care
1 DEX. Dic ționarul explicativ al limbii române, Editura Univers Enciclopedic, Bucure ști,
1998
8
este influen țat continuu și de nivelul de dezvoltare a tehnologiei hardware și
software de la un moment dat. Ob ținerea informa țiilor și prelucrarea lor se
face prin intermediul unor sisteme informa ționale.
De obicei, oamenii presupun existen ța unui calculator când aud
pentru prima dat ă sintagma sistem informa țional . Totuși, un sistem
informațional nu este neap ărat un sistem computerizat și în fiecare zi vedem
exemple de astfel de sisteme informa ționale. De exemplu, sunte ți
beneficiarul unui sistem informa țional atunci când dori ți să călătoriți cu
autobuzul și pentru aceasta cump ărați un bilet. Atunci când prezenta ți biletul
unui controlor, biletul reprezent ă suportul informa ției pe care controlorul o
interpreteaz ă prin aceea c ă ați cumpărat dreptul de a c ălători cu acel mijloc
de transport. Un sistem informa țional este parte a unui sistem complet. Un sistem
este o entitate compus ă din părți organizate și care interac ționează pentru o
funcționare cât mai eficient ă. Subsistemele sunt părți componente ale
sistemului. De exemplu, Facultatea de Științe Economice este un subsistem
al sistemului Universitatea Tibiscus. Un sistem informa țional se compune dintr-o mul țime de
subsisteme intercorelate care lucreaz ă împreun ă pentru colectarea,
prelucrarea, stocarea, transformarea și distribuirea informa ției pentru
planificare, luarea deciziilor și control. Fiecare sistem informa țional se poate
descompune în trei componente principale: intr ările, prelucr ările și
rezultatele. Intrarea într-un sistem informatic poate fi format ă din date sau
din informații. Datele sunt fapte brute, neprel ucrate despre evenimente care
nu au semnifica ție în sistem și nu sunt organizate. Datele pot fi totu și
organizate într-o manier ă în care pot fi utile sau pot primi semnifica ție
pentru sistem. Când datele se organizeaz ă astfel încât s ă aibă semnifica ție
pentru sistem ele devin informa ție. Rafinarea datelor și informa țiilor de-a
lungul timpului formeaz ă un ansamblu numit cunoștințe. Sistemele
informaționale prelucreaz ă datele și/sau informa ț
iile (sortare, organizare,
calcule specifice) ob ținând informa ții care sunt structurate în func ție de
cerințele utilizatorilor informa ției. Aceste cerin țe pornesc în general de la
scopurile pentru care este folosit ă informația, de exemplu persoanele de la
nivelele de conducere folosesc informa ția pentru planificar e, luare de decizii
și controlul activit ăților organiza ționale (decizia cump ărării unui echipament
necesită informa ții despre alternative, costul alternativelor și cerințele
referitoare la echipamentul n ecesar pentru o entitate economic ă).
Informațiile și cunoștințele sunt folosite des în activit ăți de controlul.
Contabilii preg ătesc bugetele (aceasta este o func ție de planificare) astfel
încât managerii s ă poată compara performan țele actuale cu cele planificate
și să poată controla activit ățile lor pentru a preîntâmpina schimb ările
nedorite. Figura 1.1 reflect ă modul în care datele, informa țiile și
cunoștințele (care compun a șa numita piramid ă informațională) colaboreaz ă
într-un proces permanent, în care datele pot fi folosite pentru a ob ține
informații și cunoștințe, iar cuno ștințele, la rândul lor, pot fi folosite pentru a
obține informa ții și date. Preciz ăm că figura nu prezint ă subordonarea celor
trei concepte ci vrea s ă sugereze un raport cantitativ dintre acestea.
Fluxurile informa ționale reprezint ă totalitatea informa țiilor care se
vehiculeaz ă între emi țătorul de informa ție și receptor. Sistemul
informațional comunic ă cu mediul s ău extern prin fluxuri informa ționale (de
9
exemplu rapoartele pentru ac ționari), iar în interiorul s ău, subsistemele
comunică între ele prin alte fluxuri informa ționale.
Figura 1.1 Piramida informa țională
Sistemele informa ționale se studiaz ă în cadrul domeniului în care
funcționează, pentru a se eviden ția particularit ățile specifice, astfel se
vorbește de „sistemul informa țional de conducere”, „sistemul informa țional
de marketing”, „sistemul informa țional geografic1” etc. Contabilitatea este
în sine un sistem informa țional. Este un proc es care colecteaz ă, stocheaz ă,
prelucreaz ă și distribuie informa ții celor care au nevoie de ele. De exemplu,
contabilii unei entit ăți economice culeg date despre propria organiza ție, le
prelucreaz ă, obțin rezultate pe care le distribuie sub form ă de informa ții
financiare, sau alte tipuri de rapoarte. Una dintre cele mai cuprinz ătoare defini ții ale sistemului
informațional contabil este cea dat ă de autorii Gheorghe, Mirela, Ro șca, I.
Ioan în cartea „ Auditul informa ției contabile în condi țiile utiliz ării
sistemelor informatice ” (pagina 21): „Sistemul informa țional contabil este
format dintr-un ansamblu de elemente interdependente, orientat spre culegerea, stocarea, prelucrarea, analiza și transmiterea informa țiilor privind
starea și mișcarea patrimoniului”.
Conceptul de tehnologie a informa ției se refer ă la totalitatea
componentelor software și hardware folosite în sistemele informa ționale
computerizate. Tehnologia informa ției a modificat modul în care se lucreaz ă
în orice domeniu. În urm ă cu câțiva ani, nimeni nu î și putea imagina c ă
oamenii vor putea face cump ărăturile de la un magazi n virtual „localizat”
undeva și accesat prin intermed iul Internetului. Comer
țul electronic este
numai un exemplu din multele moduri în care tehnologia informa ției
influențează viața de zi cu zi dar și cea a afacerilor. Moscove2 remarcă
faptul că tehnologia informa ției a avut acela și impact asupra societ ății ca și
revoluția industrial ă. În era informa ției, câțiva muncitori produc și un
segment larg de popula ție angajat ă este implicat ă în produc ția, analiza și
distribuția informa ției, astfel c ă sistemele informatice au ajuns s ă joace un
rol vital atât în economie cât și în viața fiecăruia. Tehnologia informa ției
afectează orice tip de contabilitate (financiar ă, de gestiune, managerial ă). Un
sistem informatic de contabilitate este un tip special de sistem, care
furnizează informa ții despre procesele afacerilor și evenimentele care
intervin în func ționarea unei unit ăți economice.
1 www.acad.ro/pro_pri/doc/st_b08.doc
2 Moscove, S.A., Simkin, M. G., Bagranoff, Nancy A. – „Core Concepts of Accounting
Information Systems” Cunoștințe
Informații
Date
10
Dac ă la începuturile tehnologiei informa ției, dependen ța de sistemele
informatice nu se f ăcea simțită, în ziua de azi nici m ăcar nu se mai poate
imagina ca afacerile s ă nu foloseasc ă sisteme informatice. De la calculatoare
se așteaptă să îndeplineasc ă funcțiuni ca: planificar ea unei linii de produc ție,
păstrarea eviden ței dintr-un depozit, veri ficarea datelor unui conduc ător auto
etc. Sistemele informatice se folosesc nu numai de c ătre unitățile economice
mari care manipuleaz ă foarte multe date ci și de către cele mici. Chiar și în
țara noastr ă putem întâlni patroni de microîntreprinderi care țin o eviden ță
contabilă folosind un calculator acas ă.
Atunci când este folosit ă tehnologia informa ției, de obicei ne referim
la acest aspect ca fiind informatic. Defini ția din DEX pentru informatic este
„știință aplicată care studiaz ă prelucrarea informa țiilor cu ajutorul sistemelor
automate de calcul”. În cartea „ Bazele computerelor. Hard & soft” 1, autorii
au definit sistemul informatic drept „un sistem informa țional care are ca
element de culegere, stocare, transmitere și transformare un calculator
electronic”. Dac ă vom considera c ă sistemul informatic este acea parte a
sistemului informa țional prin care se execut ă prelucrări automate cu ajutorul
sistemelor de calcul, devine evident c ă sistemul informatic este parte a
sistemului informa țional. Ținând cont de faptul c ă prelucrarea datelor în
contabilitate se face preponderent automat, prin intermediul programelor specializate, vom considera c ă sistemele informatice de contabilitate
acoperă toate ariile unui sistem informa țional de contabilitate.
Sistemele informatice de contabilitate pot furniza o multitudine de tipuri de date și informa ții: date financiare, date non-financiare, analize
rezultate din managementul datelor, informa ții de căutare sau anticipare,
informații despre management, despre ac ționari, etc.
Sistemele contabile computerizate estompeaz ă demarcările dintre
sistemele contabilit ății financiare și ale contabilit ății manageriale. Multe
programe software contabile actuale pot prelua ambele tipuri de date
(financiare și non-financiare) și să le organizeze într-o manier ă prin care au
semnifica ție atât pentru utilizatorii interni cât și pentru cei externi.
Tehnologia informa ției de azi poate face posibil ă obținerea unor rezultate
care necesit ă operații complexe si peri odice la intervale scurte de timp (cum
ar fi actualizarea la fiecare minut vânz ărilor de produse și raportarea acestor
vânzări). Aceste rezultate se pot furn iza aproape instantaneu prin fax, e-
mail, sau pe Internet, pe o pagin ă specială sau pe propriul site.
Posibilitatea tehnologiei informa ției de a produce rapid mari cantit ăți
de informa ție poate crea o problem ă cunoscut ă ca supraîncărcarea
informației ([MOS03]). Prea mult ă informație și, în mod special, prea mult ă
informație banală, poate cople și utilizatorii informa ției, iar informa ția
relevantă pentru luarea deciziilor se poate pierde. Contabilii sunt cei care
decid natura și sincronizarea informa ției creată și distribuit ă printr-un sistem
informațional contabil. Influen ța tehnologiei informa ției asupra raport ărilor
financiare primare se face sim țită în furnizarea informa ției financiar-
contabile. Internetul poate aduce modific ări în modul de furnizare a
conținutul rapoartelor financ iare, sau a disponibilit ății informa ției referite în
expunerile financiare de baz ă.
1 Lupulescu, M. coordonator, D ănăiață, Doina, Muntean, Mihaela – Bazele computerelor.
Hard & soft, pagina 23
11
1.2 LOCUL ȘI ROLUL SISTEMULUI INFORMATIC DE
CONTABILITATE
Existen ța sistemelor informatice moderne, de mare vitez ă, a devenit
posibilă după ce calculatoarele s-au r ăspândit în lumea afacerilor. Istoric,
existența sistemelor informatice contabil e a început cu informatizarea
facturării și a unor opera ții contabile aferente. În cadrul oric ărei unități
economice culegerea datelor, prelucrarea lor și obținerea rezultatelor se fac
conform unor proceduri organizatori ce reglementate fie prin lege (de
exemplu componen ța și structura planului de cont uri) fie prin regulamente
de ordine intern ă (de exemplu, stabilirea persoanei și a timpului lans ării unei
operațiuni de arhivare a datelor).
În figura 1.2 intr ările se constituie din date sau informa ții (care se
preiau din documentele justific ative), care sunt procesate ob ținându-se
informații pentru planificare, luarea deciziilor și control.
Documentele contabile se clasific ă în funcție de rolul lor și de modul
de întocmire ([TEA00], pagina 97) în : documente justificative (de eviden ță
primară), registrele contabile (eviden ță contabil ă) și situațiile financiare
(documente de sintez ă și raportare). Înregistrarea în contabilitate se poate
face pentru fiecare document, sau din documentele centralizatoare care cuprind date de aceea și natură
dintr-o perioad ă oarecare.
Figura 1.2 Fazele distincte ale func ționării unui sistem
Sursa: [MOS03] pagina 6
Rezultatul prelucr ărilor contabile se poate folosi de c ătre nivelele de
conducere în cadrul unor procese decizionale, cu observa ția că „o aceea și
informație poate fi perceput ă cu valori diferite pentru persoane diferite.
Aceia care sunt specializa ți în contabilitate dau importan ță mai mare
rapoartelor financiare mai mult decât cei care nu au o asemenea preg ătire”1.
Informațiile contabile trebuie s ă îndeplineasc ă următoarele caracteristici2:
• inteligibilitatea (informațiile pot fi u șor de înțeles și de interpretat);
• relevanța (sublinierea aspectelor care pot influen ța luarea deciziilor);
• credibilitatea (informa țiile nu con țin erori semnificative, nu sunt
tendențioase, nici p ărtinitoare);
• comparabilitatea (informa țiile să poată fi comparate prin elemente
comune și de aceea și semnifica ție).
Existen ța erorilor poate crea incertitudine și luarea unor decizii
greșite.
Figura 1.3 reflect ă o parte a unui sistem informa țional a unei entit ăți
economice și scoate în eviden ță faptul c ă sistemul informa țional de
contabilitate este subsistem al sistemului informa țional al entit ății
1 Hawker, A. „ Security and Control in Information Systems: A Guide for Business and
accounting ”, Routledge 2000, pagina 14
2 Teaciuc, M. ș.a. – Bazele contabilit ății, Eurostampa 2000, paginile 7-8 Intrări Prelucrări Rezultate
Date/informa ții din surse
interne și/sau externe Sortare, organizare, calcul Date/informa ții pentru
decidenți interni și/sau
externi
12
economice. Sistemul informa țional de contabilitate acumuleaz ă informații
de la subsisteme diferite. Pentru ca interac țiunea dintre subsisteme s ă fie
efectivă, este necesar c ă fiecare subsistem s ă „înțeleagă” tipurile de
informații generate de subsistemele cu care interac ționează.
Figura 1.3 Subsisteme informa ționale organizate în func ție de activit ățile
din cadrul unei unități economice
Sursa: Lungu, I., Sab ău, G., Velicanu, M. ș.a. – „ Sisteme informatice.
Analiză, proiectare și implementare ” pagina 21
Un sistem informatic de contabilitate tradi țional se ocup ă în
principal de colectarea, prelucrarea și obținerea rezultatelor financiare care
se vor transmite c ătre externi (cum ar fi investitorii, creditorii și Ministerul
Finanțelor) și către interni (în genera l structurile de conducere). Un sistem
informatic de contabilitate modern se ocup ă atât de informa țiile non-
financiare cât și cu date și informații financiare.
Tradi țional, fiecare parte a unei entit ăți economice (Personal,
Producție) mențin un subsistem informatic separat și fiecare subsistem î și
prelucreaz ă propriile date. Aceast ă mod de lucru are dezavantajul apari ției
unor probleme cum ar fi dup licarea datelor pe spa ții de stocare distincte,
culegerea separat ă a unor acelea și date.
Ast ăzi entitățile economice consider ă că este necesar ă integrarea
funcțiilor lor într-o baz ă mare de date, sau într-un depozit de date. Aceast ă
integrare permite managerilor și, cu oarecare extensii, p ărților externe s ă
obțină informațiile necesare pentru planificare, luarea deciziilor și control,
fie că informa țiile sunt pentru marketing, c ontabilitate, sau alte arii
financiare ale entit ății economice1. Producătorii de produse software au
dezvoltat programe care leag ă toate subsistemele informatice într-o singur ă
aplicație. Produsele software pentru contab ilitate vor fi di scutate ulterior.
Rolul sistemului informatic de contabilitate este de a furniza informații importante referitoare la: venituri, urm ărirea clien ților (facturi
emise neîncasate), dinamica încas ărilor și plăților, contabilitatea costului
1 Moscove, S.A., Simkin, M. G., Bagranoff, Nancy A. – „ Core Concepts of Accounting
Information Systems ” Furnizori
Baze de date
sau fișier(e)
de furnizori și
clienți Gestionarea
comenzilor și
contractelor de
aprovizionare Aprovizionare
Magazii,
gestiune
stocuri
Producție Contabilitate Personal
Cheltuieli
materiale Magazie
produse
finite
Comenzi,
contracte de
desfacere Studii de pia ță Calcul cost-pre ț
13
(calculația costului), cheltuieli, etc. Informa țiile furnizate pot îmbr ăca forme
diverse atât electronic (documente elect ronice, foi de prezentare electronice,
notificări electronice (e-mail), imagini, imagini video, secven țe audio, etc.),
fie sub form ă „tradițională” (pe suport de hârtie sau folii pentru proiectoare,
etc.). Furnizarea informa țiilor trebuie s ă se facă în timp util, cât mai exact,
pentru toți destinatarii informa ției contabile (manageri, personal apar ținător
altor subsisteme). Un sistem informatic de contabilitate modern este capabil să preia automat datele furnizate de c ătre alte subsisteme.
1.3 COMPONENTELE SISTEMULUI INFORMATIC DE
CONTABILITATE
Opera țiile contabile care se realizeaz ă prin intermediul sistemelor
informatice de contabilitate trebuie s ă ajute la rezolv area unor probleme
specifice ca eviden ța contabil ă a opera țiilor pe conturi și calcularea
balanțelor contabile. Aceasta se face pr in preluarea datelor din documentele
de intrare și stocarea lor, prelucrarea datelor și obținerea rezultatelor (vezi
figura 1.4). Preluarea datelor se poat e face manual (când un operator uman
parcurge fiecare document justificativ, operându-l) și/sau automat (când
există echipamente periferice de intrare conectate la sistemul informatic).
Stocarea datelor presupune existen ța unui sistem de gestiune a fi șierelor
și/sau un sistem de gesti une a bazelor de date. Ob ținerea unui sistem
informatic se face urmând câteva etape: analiz ă, proiectare și implementare,
urmărindu-se activit ățile din cadrul sistemului informa țional aferent și toate
fluxurile informa ționale care apar, de intere s fiind cele care pot fi
automatizate prin intermediul calculatoarelor (vezi figura 1.4 care prezint ă
un exemplu cu activit ățile unui sistem informatic).
Figura 1.4 Activitățile unui sistem informatic
Se impun câteva observa ții referitoare la figura 1.4: Documente
justificative
Jurnale Note
contabile
Registrul
jurnal Planul
contabil
Închideri și
alte prelucr ări
periodice Subsisteme emi țătoare/primitoare
Bonuri de consum, facturi, NIR,
chitanțe, fișe de amortizare etc.
Balanțe,
rapoarte
(casă,
bancă),
bilanț,
jurnale de
TVA, etc. Operații
contabile
14
1. operațiile contabile cu documentele de intrare justificative înseamn ă
contarea documentelor: de la subsistemul Producție: bonuri de
consum, rapoarte de produc ție; de la Aprovizionare : facturi de
intrare, NIR (note de intrare-recep ție), de la Vânzări: facturi emise;
de la Casa, Banca : chitanțe, foi de v ărsământ, ordine de plat ă; foaie
de depunere; etc.;
2. operațiile contabile periodice: închideri lunare și/sau anuale.
Documentele care se pot ob ține pe baza opera țiilor contabile au ca
destinatari: nivelului de conducere (deci zional), nivelului de control intern și
audit. Componentele unui sistem informatic de contabilitate trebuie s ă
răspundă cerințelor de func ționare descrise pân ă acum și trebuie s ă fie
intercorelate func țional:
a. hardware;
b. software;
c. comunica ție;
d. baza științifică și metodologic ă (metodele, procedeele
și mijloacele
de prelucrare a datelor);
e. baza informa țională, fluxurile informa ționale și suporturile de
informații;
f. utilizatorii;
g. cadrul organizatoric.
Componenta hardware se constituie din totalitatea mijloacelor
tehnice de culegere, stocare, transmitere și prelucrare automat ă a datelor.
Acestea pot include calcul atoare, scannere, case de marcat, dispozitivele de
comunicare, dispozitivele de interconectare. Componenta software se constituie din to talitatea programelor și
aplicațiilor care realizeaz ă funcționarea sistemului informatic. Din aceast ă
categorie fac parte sistemele de operare utilizate, aplica țiile software de
comunica ție în rețea, programele de prelucrare în scopul ob ținerii unor
informații contabile, programele de editare de texte și de creare a
rapoartelor, etc. Componenta de comunica ție se constituie din toate echipamentele și
tehnologiile utilizate pentru comunica ția datelor între p ărțile componente ale
sistemului informatic. Baza științifică și metodologic ă se compune din modelele
matematice ale proceselor de contabilitate, din „metodologiile, metodele și
tehnicile de realizare a sistemelor informatice”
1.
Baza informa țională se constituie din totalitatea fluxurilor
informaționale și ale datelor de prelucrat. Un ii autori (Lungu I.) includ aici
sistemele și nomenclatoarele de coduri. Cum codificarea și utilizarea
codurilor este a ajuns un mecanism foarte utilizat chiar și în viața de zi cu zi
(de exemplu utilizarea codului CNP) consider ăm că acestea sunt de drept o
1 Lungu, I., Sab ău, G., Velicanu, M. ș.a. – „ Sisteme informatice. Analiz ă, proiectare și
implementare ”, pagina 23
15
parte important ă a fluxului informa țional, având în vedere urm ătoarele: un
produs și/sau serviciu se codific ă, de cele mai multe ori, printr-un mecanism
intern al unit ății economice; codurile folosite pot fi f ăcute vizibile (prin liste
de selecție, prin afi șare lângă preț ș.a), iar cu timpul codurile pot memorate
de către utilizatori și folosite cu u șurință într-o manir ă directă.
Utilizatorii sunt componenta format ă din totalitatea persoanelor
angajate în func ționarea sistemului info rmatic. Se disting dou ă categorii
mari de utilizatori: operatorii (de exemplu, cei de la casele de marcat) și
informaticienii (cum ar fi anali știi, inginerii de sistem, programatorii).
Cadrul organizatoric este dat de regulamentul de ordine interioar ă
și de actele legislative în vigoare, cum ar fi:
• legea nr. 82/1991 denumit ă Legea contabilit ății;
• planul de conturi;
• codul privind Conduita Etica si Profesional ă a exper ților
contabili și contabililor autoriza ți din România;
• legea nr. 15/1994 privind amortizarea capitalului imobilizat în
active corporale și necorporale;
• ordinul nr. 1826/2003 pent ru aprobarea preciz ă
rilor privind
unele m ăsuri referitoare la organizarea și conducerea
contabilit ății de gestiune;
• ordinul nr. 1040/2004 pentru apr obarea Normelor metodologice
privind organizarea și conducerea eviden ței contabile în partid ă
simplă de către persoanele fizice care au calitatea de
contribuabil;
• ordinul nr. 1753/2004 pentru ap robarea Normelor privind
organizarea și efectuarea inventarieri i elementelor de activ și de
pasiv;
• ordinul nr. 1752/2005 pentru aprobarea reglement ărilor
contabile conforme cu directivele europene.
În Anexa la Ordinul nr. 58/23 ianuarie 2003 se precizeaz ă: „În
condițiile utilizării sistemelor informatice financiar-contabile este necesar sa
fie respectate Criteriile minimale privind progr amele informatice utilizate în
domeniul financiar-contabil , prevăzute de Ordinul ministrului finan țelor nr.
425/1998, cu modific ările ulterioare” și “Contribuabilii pot edita
formularele cu regim special cu aj utorul tehnicii de calcul, în condi țiile
prevăzute la art. 2 din Or dinul ministrului finan țelor nr. 1.177/1998 privind
aplicarea prevederilor art. 1 alin. (4) și (10) paragraful 2 din Hot ărârea
Guvernului nr. 831/1997”. În general, sistemele informatice de contabilitate sunt organizate
astfel încât s ă corespund ă arhitecturii contabilit ății din România în care se
remarcă trei mari componente ([TEA00]):
1. contabilitatea general ă (aprovizionare ș
i furnizori; vânz ări și clienți;
cheltuieli; venituri; datoriilor; crean țelor; stocuri și obiecte de
inventar; mijloace fixe; capital; salarii; opera ții diverse, de
închidere);
2. contabilitatea financiar ă / de gestiune financiar ă: trezoreria,
investițiile financiare, finan țările – încas ăr i d e l a clien ți, plăți către
16
furnizori, eviden țierea plasamentelor, plata impozitelor și taxelor
etc.;
3. controlul prin bugete – elaborarea de bugete și urmărirea acestora
prin intermediul contabilit ății generale.
Din aspectele descrise pân ă acum putem trage concluzia c ă
majoritatea ac țiunilor desf ășurate în cadrul unei entit ăți economice necesit ă
utilizarea sistemului informatic de contabilitate.
BIBLIOGRAFIE
1. [HAW00] Hawker, A. „ Security and Control in Information Systems: A
Guide for Business and accounting ”, Routledge 2000
2. [LUN03] Lungu, I., Sab ău, G., Velicanu, M. ș.a. – „Sisteme
informatice. Analiz ă, proiectare și implementare”, Editura Economic ă,
București, 2003
3. [LUP99] Lupulescu, M. coordonator, D ănăiață, Doina, Muntean,
Mihaela – Bazele computerelor. Hard & soft , Editura Mirton, Timi șoara
1999 4. [MOS03] Moscove, S.A., Simkin, M. G., Bagranoff, Nancy A. – „Core
Concepts of Accounting Information Systems”, John Wiley & Sons Ltd, 2003 5. [TEA00] Teaciuc, M. ș.a. – Bazele contabilit ății, Editura Eurostampa,
Timișoara 2000
6. ***, http://www.cdep.ro, sec țiunea „Repertoriul legislativ”
17
TESTE DE EVALUARE
1. Definiți sistemul informa țional:
_____________________________________________________________
__________________________________________________________________________________________________________________________ 2. Componentele unui sistem informa tic de contabilitate sunt urm ătoarele:
_____________________________________________________________
_______________________________________________________________________________________________________________________________________________________________________________________ 3. Cadrul organizatoric este dat de:
_____________________________________________________________
_______________________________________________________________________________________________________________________________________________________________________________________ 4. Folosind Monitorul Oficial sau alte surse de informare (de exemple
revistele, site-urile și portalurile specializate în furnizarea de informa ții de
contabilitate și colaborare între contabili
1) încercați să găsiți reglement ări
legislative aplicabile sistemelor informatice de contabilitate, altele decât cele enumerate în cadrul subcapitolului 1.3.
_____________________________________________________________
_______________________________________________________________________________________________________________________________________________________________________________________ 5. Caracteristicile pe care trebuie s ă le îndeplineasc ă informațiile sunt:
_____________________________________________________________
_______________________________________________________________________________________________________________________________________________________________________________________
1 de exemplu: Revista ContaPlus , Revista Contabilitate și informatic ă de gestiune ,
http://contacafe.ro, http://w ww.contabilul.ro, http://www.e-contabilitate.ro
18
TEMA 2. CARACTERISTICILE PROGRAMELOR DE
CONTABILITATE
CONȚINUT
2.1. Caracteristici de calitate
2.2. Constrângeri
REZUMAT
Măsura în care un produs software de contabilitate îndepline ște
cerințele utilizatorilor depinde di rect de totalitatea însu șirilor sale pe care
acesta le-a dobândit în procesul de produc ție. Din acest motiv, cunoa șterea
și determinarea lor este un aspect important al realiz ării și utilizării
programelor de contabilitate.
OBIECTIVE
Tema propus ă are ca scop în țelegerea cerin țelor de calitate pentru
produsele software de contabilitate și ale particularit ăților acestora care
provin din constrângerile impuse.
2.1 CARACTERISTICI DE CALITATE
Informatizarea unit ăților economice a însemnat crearea unor
programe specializate care au trebuit s ă respecte constrângerile impuse de
legislație. Diferen țele dintre programe apar la nivelul interfe țelor,
document ării, asisten ței tehnice și al altor servicii. Programele trebuie s ă
respecte anumite principii cum ar fi
1: „prevenirea defectelor; asigurarea
faptului c ă defectele au fost detectate și corectate cât mai curând posibil;
stabilitatea și eliminarea cauzelor care produc anumite simptome; audit și
conformitate cu standarde și proceduri”.
Pre țul programelor de contabilitate difer ă în funcție anumite criterii
cum ar fi: produc ătorul, num ărul de calculatoare folosite, tehnologia
utilizată ș.a. Cele mai ieftine sunt cele care au pre țul de achizi ție zero lei
(Saga C, ContaSQL) iar pre țul celor mai scumpe se ridic ă la câteva mii de
lei (Ciel, EasyCont). La pre țul de achizi ție trebuie ad ăugat prețul instruirii,
asistenței tehnice și al abonamentului pentru actualiz ările în func ție de
modificările legislative. Entit ățile economice pot opta pentru achizi ționarea
unui program de contabilitate prin dou ă metode:
• selectarea unei produc ător de produse software și crearea unui
program de contabilitate special, în func ție de nevoile unit ății
economice;
• selectarea unui program de contabilitate existent.
1 Mihalca, Rodica, Fabian, C. – Realizarea produselor program aplicative , Editura ASE,
București 2003, pagina 4-2
19
Fiecare dintre aceste metode prezint ă avantaje și dezavantaje dar
produsul software achizi ționat trebuie s ă răspundă unor cerin țe de calitate.
Calitatea produselor software de contabilitatea
Măsura în care un produs software de contabilitate îndepline ște
cerințele utilizatorilor depinde di rect de totalitatea însu șirilor sale pe care
acesta le-a dobândit în procesul de produc ție. Cunoa șterea și determinarea
lor este dificil ă din cauza num ărului mare și divers al acestor însu șiri. De
aceea, în practic ă, se iau în considerare acele însu șiri, pe care le vom numi
caracteristici de calitate , care exprim ă direct sau influen țează într-un fel sau
altul utilizarea produsului .
C alitatea produselor software de contabilitate reprezint ă
„totalitatea însu șirilor tehnice, economice și sociale”1 și gradul în care
ansamblul însu șirilor satisfac: nevoia utiliz atorilor finali ai produselor,
gradul de utilitate și eficiența economic ă în exploatare. Gradul de utilitate al
produselor software de contabilitate are în vedere: calita tea proiect ării,
realizării și execuției; calitatea de conformitate (dintre cerin țele utilizatorilor
și însușirile actuale ale produs elor software); capaci tatea de utilizare în
rezolvarea problemelor pent ru care a fost dezvoltat și capacitatea de
mentenan ță (măsura în care disfunc ționalitățile pot fi reparate).
Caracteristicile de calitate ale produselor software de
contabilitate sunt: ergonomia, fiabilitatea, mentenabilitatea, corectitudinea,
eficacitatea, stabilitatea, adapta bilitatea, portabilitatea, siguran ța în utilizare
și claritatea.
Ergonomia este însu șirea care exprim ă relația directă dintre om și
produs prin urm ătoarele caracteristici:
• ușurința exploat ării produsului – aceasta se reflect ă în produsele
software de contabilitate la interfe țele care trebuie s ă fie prietenoase,
cu un design pl ăcut ochiului uman, f ără elemente suplimentare care
să încarce inutil suprafa ța de lucru afi șată pe ecran;
• securitatea exploat ării produsului – programele de contabilitate
trebuie s ă fie prev ăzute cu elemente de siguran ță cum ar fi:
protejarea fi șierelor de lucru, imposibilitatea cre ării unui cont de
două ori, imposibilitatea utiliz ării unui cont nedeclarat,
imposibilitatea modific ării datelor dintr-o perioad ă închisă etc.
• optimizarea solicit ărilor fizice și psihice – aplica țiile de contabilitate
trebuie să prevadă mecanisme cât mai simple de lucru: alegerea din
liste ale denumirilor lungi, completarea automat ă a informa țiilor
despre un ter ț, completarea unor date implicite (cum ar fi data
curentă, cota de TVA) etc.;
• consumul de timp pentru ob ținerea rezultatului – acest consum
trebuie să fie cât mai mic pentru oricare dintre opera ții.
Fiabilitatea reprezint ă capacitatea unui produs de a func ționa fără
defecțiuni în condi ții de lucru bine stabilite. Exprimarea fiabilit ății folosește
1 Mihalca, Rodica, Fabian, C. – Realizarea produselor program aplicative , Editura ASE,
București 2003, pagina 9-1
20
noțiunea de defecțiune care înseamn ă, în fapt, ie șirea din func țiune și constă
în pierderea total ă sau parțială, instantanee sau progresiv ă a capacit ății de
funcționare a produsului. Func ționarea fără defecțiuni const ă în menținerea
capacității de func ționare a produsului. Astfel dac ă se asigur ă alimentarea
continuă cu electricitate, un sistem de operare liber de viru și, o rețea stabilă
(dacă este necesar ă) programele contabile nu au „voie” s ă își întrerup ă
execuția sau să lucreze imprecis. Fiabilita tea a dobândit o importan ță foarte
mare odat ă cu dezvoltarea tehnologiei și a creșterii complexit ății produselor
de contabilitate. Mentenabilitatea reprezint ă capacitatea ca un produs s ă poată fi
întreț
inut și reparat într-o anumit ă perioadă de timp. Ca orice produs și
programele de contabilitate pot prezenta defec țiuni care se manifest ă în
diverse moduri, atât func țional cât și la nivelul interfe ței (o listă atașată unui
buton nu se mai deschide, calcular ea perioadelor de timp nu respect ă anul
bisect, ignorarea cifrel or zecimale etc.).
Cum aplica țiile software sunt produse de folosin ță îndelungat ă și de
importanță mare în cadrul unei unit ăți economice, ele trebuie s ă fie:
– ușor de men ținut în stare de bun ă funcționare – utilizatorii
trebuie să cunoasc ă toate acele condi ți i s u f i c i e n t e p e n t r u c a
această stare să se mențină;
– ușor de între ținut – dac ă programul este modular, utilizatorii
trebuie să poate ad ăuga cu u șurință părțile componente care
„repară” produsul f ără ca aceste componente noi s ă impieteze
asupra datelor existente; dac ă programul nu este modular,
producătorul trebuie s ă prevadă mecanisme simple cu ajutorul
cărora utilizatorii s ă poată înlocui versiunea defect ă cu versiunea
nouă;
– ușor de reparat – este una dintre cerin țele de baz ă a utilizatorilor,
făcând o analogie cu legile lui Murphy, putem spune c ă orice
component ă se defecteaz ă tocmai când este cea mai mare nevoie
de acea component ă. Producătorii trebuie s ă ofere modalit ăți
simple de contactare din partea utilizatorilor (telefon, e-mail,
mesagerie instantanee) și aibă capacitatea de a rezolva orice
defecțiune într-un interval de timp cât mai scurt.
Putem trage concluzia c ă mentenabilitatea unui produs software de
contabilitate depinde de urm ătoarele caracteristici:
– accesibilitatea lui – u șurința cu care produc ătorii pot accesa
orice modul constituent al sistemului informatic;
– existența modulelor și/sau versiunilor necesare repara ției;
– activitatea de asisten ță tehnică și întreținere (service) atât în
perioada de garan ție, cât pe toat ă durata de utilizare a
produsului.
Corectitudinea reprezint ă capacitatea unui produs software de
contabilitate de a prelucra datele și informațiile și de obține rezultate corecte
cantitativ și calitativ, respectând fluxurile transform ărilor specificate în
documenta ția ce stă la baza formul ării cerințelor utilizatorilor. Un program
de contabilitate nu este corect dac ă, de exemplu, lucreaz ă intern cu
aproximări zecimale de o cifr ă cunoscut fiind faptul c ă sunt permise
aproximări de cel pu țin două cifre.
21
Eficacitatea reprezint ă capacitatea produselor software de
contabilitate de a utiliza resursele disponibile cât mai optim oricât de complexă este problema supus ă rezolvării. Un program de contabilitate care,
astăzi, are prev ăzute mecanisme de arhivare nu mai pe suporturi de memorie
de tip dischet ă, nu este un program eficient pentru c ă nu utilizeaz ă și alte
echipamente periferice disponibile (memoriile de tip „flash”). Siguranța în utilizare reprezint ă capacitatea unui program de
contabilitate de a nu permite nici modificarea datelor și nici distrugerea
parțială sau total ă prin acces neautorizat. Un pr ogram de contabilitate care
permite ștergerea unui cont sintet ic pentru care exist ă înregistrări, nu este un
program care ofer ă siguranță în utilizare. De asemenea, nici dac ă permite ca
o persoan ă cu cunoștințe minime de baze de date s ă poată efectua comenzi
de ștergere masiv ă a datelor din baz ă. Atragem aten ția că distrugerea datelor
din cauze pur hardware (dis trugerea hard-disk-ului pe care sunt stocate
datele) este o caracteristic ă de calitate a întregului sistem informatic de
contabilitate. Adaptabilitatea reprezint ă capacitatea programelor de contabilitate
de a permite integrarea unor func ții și/sau componente noi care s ă m
ărească
performan țele de prelucrare dup ă ce acestea au fost date în func țiune. Dac ă
un program de contabilitate extrage o list ă a produselor vândute în ultimele
două luni, ordonate doar dup ă dată, în cinci secunde, un exemplu de
adaptabilitate este ad ăugarea unei func ții noi de extragere, în doar trei
secunde, a acelora și produse ordonate dup ă criterii compuse (cum ar fi: data
calendaristic ă, client și nume).
Portabilitatea reprezint ă capacitatea produselor software de
contabilitate de a fi func ționale pe mai multe tipuri de calculatoare și/sau
sisteme de operare. În practic ă, atingerea acestei carac teristici se face prin
eforturi considerabile de programare și, din acest motiv, referirea la
avantajele portabilit ății poate apare în orice de scriere a programelor de
contabilitate. De exempl u, dintre avantajele solu ției GITS se scoate în
evidență că „sistemul este conceput 100% în Java, conferind portabilitate pe
orice platform ă și sistem de operare. Aplica ția rulează pe sistemele de
operare Windows 98/ME/2000/XP și Linux având suport pentru baze de
date ORACLE, Microsoft SQL Server și MySQL”1.
Stabilitatea programelor de contabilitate poate fi exprimat ă:
• din punct de vedere prelucr ărilor – reprezint ă rezisten ța
programului la modificarea datelor ini țiale sau în secven țele ce
compun modulele sale; aceast ă caracteristic ă trebuie urm ărită
atât în timpul procesului de realizare a programelor/modulelor
de contabilitate în cadrul test ărilor cât și după punerea în
funcțiune prin auditul sistemului informatic de contabilitate;
• din punct de vedere software/hardware – reprezint ă capacitatea
produsului software de contabilitate de a p ăstra integritatea
datelor atunci când apare o întrerupere a disponibilit ății
sistemului. De exemplu, întreruperea brusc ă a aliment ării cu
1 http://www.attosoft.ro
22
electricitate nu trebuie s ă determine apari ția unor note contabile
incomplete.
Claritatea exprim ă măsura în care produsul software de
contabilitate este compus numai din instruc țiuni necesare prelucr ărilor
contabile. Tendin ța de a crea programe de contabilitate neclare este apanajul
producătorilor fără experien ța punerii în func țiune a programelor la mai
mulți utilizatori. Claritat ea produselor software se poate exprima din dou ă
puncte de vedere: al programatorilor și al utilizatorlor finali. Pentru
utilizatorul final, un program de contabilitate este neclar dac ă interfața este
încărcată (explicații inutile, „reclame” referito are la echipa de programare,
legături cu zone care nu sunt de interes, culori șterse sau prea puternice,
texte trunchiate, etc.).
Alte caracteristici ale produsel or software de contabilitate
Integrabilitatea programelor de c ontabilitate este o caracteristic ă
urmărită în contextul actual în care se face sim țită nevoia utilizatorilor de a
utiliza sistemele informatice existente într-un mod unitar. Integrabilitatea
reprezintă capacitatea produselor software de a fi incluse în sisteme
complexe de prelucrare a date lor ([MIH03], pagina 9-6).
În cadrul sistemului informa țional contabil putem delimita trei
domenii de activitate si anume:
• contabilitatea general ă – este acea parte care se ocup ă de intră
ri
(de la ter ți, în gestiune), ie șiri (spre ter ți, din gestiune), încas ări-
plăți, operații diverse (salarii, închideri periodice etc.);
• contabilitatea de gestiune – este partea care se ocup de ter ți,
gestiunea stocurilor, gestiunea lichidit ăților, inventare, bugete
etc.;
• analiza financiar ă – analiza pe bata bilan țului contabil.
Un sistem informatic de contabilitate poate fi folosit pentru toate
cele trei domenii sau numai pe ntru contabili tatea general ă. Flexibilitatea
este o caracteristic ă important ă a unui sistem informa tic de contabilitate
pentru că, în domeniu contabil, schimb ările sunt permanente, se pot produce
fără avertismente prealabile (conform unei politici guvernamentale cu care
contabilii înc ă nu s-au obi șnuit dar în fa ța căreia s-au resemnat). Cerin țele
de adaptare rapid ă a dus la clasificarea si stemelor informatice de
contabilitate în dou ă categorii: aplica ții dedicate și aplicații nededicate.
Aplicațiile dedicate sunt acele aplica ții care rezolv ă punctual o
problemă specifică. Dezavantajul acestor aplica ții este flexibilitatea sc ăzută
din cauz
ă că este nevoie de interven ția produc ătorului în cazul în care
intervine vreo modificare refe ritoare la problema aferent ă programului.
Acest mod de lucru este specific produc ătorilor de produs e software la
începuturile existen ței loc, programul de contabilitate ini țial cunoa ște o
dezvoltare care îl poate duce la o solu ție general ă.
Alte aplica ții dedicate sunt cele care rezolv ă problemele unei anume
categorii de probleme; cum ar fi contabilitatea institu țiilor publice. Aceste
tipuri de aplica ții pot avea o flexibilitat e medie provenind din chiar
specificul acestui tip de contabilitate.
23
Aplicațiile nededicate reprezint ă un cadru general de rezolvare a
unui tip de problem ă contabil ă, cu flexibilitate mare, orice modificare
apărută fie prin reglement ări noi legislative fie interne ale unit ății economice
se poate rezolva u șor chiar de c ătre utilizator (de exemplu modificarea
sensului unui cont). Aplica țiile informatice de contabilitate, prin adaptarea în permanen ță
la cerințele pieței, au cunoscut o dinamic ă pronunțată care s-a datorat atât
dezvoltării tehnologice ale componentelor hardware (de exemplu capacitate
de stocare, vitez ă de acces) cât și inovațiilor software (cum ar fi interfe țele
grafice).
2.2 CONSTRÂNGERI
Programele de contabilitate tr ebuie create respectând anumite
constrângeri care provin din constrângerile legislative (structura planului de
conturi, începutul și sfârșitul exerci țiului contabil) și constrângerile
unităților economice (num ărul de calculatoare folosite, num ărul de societ ăți
pentru care se face contabilitatea etc.). Constrângerile administrative provin din resursele necesare pentru
utilizarea programelor de contabilitate. Acestea includ: sistemul de operare,
necesarul minim de spa țiu de memorie extern ă, necesarul minim pentru
capacitatea memoriei interne, diferen țele dintre calculatorul server și cele
utilizator. Toate aceste aspect e se au în vedere în func ț
ie de dimensiunea
unității economice. Astfel o societate comercial ă cu un num ăr redus de
angajați își poate propune utili zarea unui singur calculator cu un sistem de
operare mai pu țin performant (cum ar fi Wi ndows 95), cu un hard-disk de
capacitate de 400MB. O unitate economic ă mare s-ar putea s ă aibă nevoie
de o rețea de calculatoare cu un server dedicat stoc ării datelor, de capacitate
mare, la nivelul zecilor de gi gabyte, cu programe care s ă asigure securitatea
în rețea și protejarea datelor în cazul unor incidente.
Constrângerile de uti lizare a calculatoarelor. Programele de
contabilitate se achizi ționează monopost (pentru un singur calculator) sau
multipost (pentru mai multe calculatoare, atunci când lucreaz ă mai mul ți
contabili la o unitate economic ă). Pentru programele de contabilitate
multipost se folosesc dou ă arhitecturi
1: partajată și arhitectur ă client-server.
În cazul arhitecturii partajate, programul de contabilitate și fișierele
se găsesc pe un singur calculator (de obicei acesta poart ă numele generic
„server”), iar cont abilii le acceseaz ă de la calculatoare conectate în re țea. În
cazul arhitecturii client-server, programu l de contabilitate este instalat pe
fiecare dintre calculatoarele din re țea iar fișierele sunt stocate pe calculatorul
numit server.
1 Boksenbaum, L. – „Informatic ă de gestiune”, pagina 229
24
Constrângeri prin num ărul de societ ăți. Contabilitatea se poate
ține pentru una sau mai multe unit ăți economice. În acest caz produc ătorii
programelor de contabilitate adopt ă două moduri de lucru:
• se permite deschiderea unui num ăr mare (de ordinul sutelor) f ără
nicio interven ție a produc ătorului și/sau fără plată suplimentar ă;
acest mod de lucru este preferat de unit ățile economice
specializate în furnizarea servicilor de eviden ță contabilă;
• se permite deschiderea unei noi societ ăți contra cost prin
intervenția unui angajat al produc ătorului; acest mod de lucru
poate să fie preferat de c ătre organiza țiile care administreaz ă una
sau mai multe unit ăți economice.
Constrângeri de identificare se folosesc atunc i când un utilizator
accesează programul de contabilitate sau a numite zone protejate ale acestuia
(cum ar fi raport ările profiturilor și/sau pierderilor) prin utilizarea unui nume
de utilizator și a unei parole. Parolele pot fi generice – caz în care controlul
accesului este slab – sau personalizate – caz în care controlul este puternic și
permite urm ărirea activit ății unui utilizator în interiorul sistemului
informatic.
Constrângerile planului de conturi provin din reglement ările
legislative care prev ăd ca un cont s ă poată fi creat o singur ă dată, să nu
poată fi șters (dacă a fost folosit cel pu țin o dată într-o opera ție). În mod
obișnuit programul de contabilitate este instalat cu un plan contabil
predefinit și cu posibilitatea gestion ării acestuia. Ad ăugarea unor conturi noi
trebuie să permită stabilirea parametrilor de lucru specifici cum ar fi:
codificarea (generic ă și/sau sintetic ă; numai numeric ă, de exemplu 5311,
sau și în combina ție cu alte caractere, de exemplu 5121.1, 5121.TRA),
sensul contului (credit, debit), taxa TVA etc.
Constrângerile de închiderea exerci țiului se referă la următoarele
aspecte:
– închiderea unui exerci țiu trebuie s ă se facă la începutul anului
care îl succede iar soldurile finale ale exerci țiului închis devin
soldurile ini țiale ale exerci țiului nou;
– atunci când un exerci țiu contabil este închis nu trebuie s ă se
poată efectua modific
ări;
– să existe posibilitatea deschiderii unui exerci țiu închis.
Constrângerile introducerii datelor se referă la modul în care se
prelucreaz ă intrările fie prin jurnale fie pr in înscrisuri contabile.
Jurnalele se folosesc pentru p ăstrarea tuturor opera țiunilor fie pe
categorii de opera țiuni (jurnal de vânz ări, jurnal de intr ări), fie de cont
(corelat direct cu un cont cum ar fi cel de cas ă sau cel de banc ă).
Un înscris contabil
1 se identific ă prin: data calendaristic ă, numărul
de cont, suma, sensul (debit sau credit) și o explica ție. Înscrisurile contabile
se folosesc cu scopul de a simplifica introducerea opera țiunilor curente fie
printr-un „abonament de înscrisuri” (pentru opera țiunile care se efectueaz ă
1 Boksenbaum, L. – „ Informatic ă de gestiune ”, Editura Economic ă, București 2002, pagina
230
25
periodic cu o aceea și sumă) fie prin completarea automat ă a datelor pentru
un cont (cum ar fi cont ul sintetic al unui ter ț). Acest mod de lucru necesit ă o
atenție special ă atunci când se stabilesc conturile cu prelucr ări automate.
Dacă nu se cunoa ște bine semnifica ția conturile și funcționarea lor, se pot
stabili parametri erona ți cur urmări nedorite în balan țele contabile.
Constrângerile opera țiilor periodice sunt urmarea faptului c ă
anumite opera ții trebuie s ă se desf ășoare periodic (obliga țiile fiscale,
închiderea de lun ă, închiderea exerci țiului etc.). De multe ori, o m ăsură de
siguranță pentru a preveni modific ările unei perioade despre care s-a
constatat c ă e validă, se procedeaz ă la blocarea perioadei adic ă nu se mai
permite modificarea datelor din perioada respectiv ă.
Constrângerile personalizate apar ca urmare a formul ării cererilor
speciale ale unei unit ăți economice și pot fi: modul în care se face
imprimarea a unui logo, utilizarea de coduri de bare pentru marcarea documentelor eliberate, comunicarea unor situa ții în alt mod sau la alte
perioade decât cele predefinite, importa rea unor date rezultate în urma unor
prelucrări externe sistemului informatic de contabilitate ș
i/sau chiar externe
unității economice, etc.
Toate constrângerile descrise mai sus au ca punct central informa ția
contabilă. Importan ța informa ției contabile este bine cunoscut ă și, la fel de
bine, este cunoscut faptul c ă reprezint ă peste 40% din informa ția existent ă /
utilizată într-o unitate economic ă. Lipsa informa ției contabile sau
inexactitatea ei poate determina un dezechilibru informa țional care s ă
influențeze negativ func ționarea unit ății economice.
BIBLIOGRAFIE
1. [BOK02] Boksenbaum, L. – „Informatic ă de gestiune”, Editura
Economic ă, București 2002
2. [MIH03] Mihalca, Rodica, Fabian, C. – Realizarea produselor program
aplicative , Editura ASE, Bucure ști 2003
26
TESTE DE EVALUARE
1. Enumerați constrângerile pentru prog ramele de contabilitate:
_____________________________________________________________
_______________________________________________________________________________________________________________________________________________________________________________________ 2. Pentru un sistem informatic de c ontabilitate, planul de conturi:
a) reprezintă este o constrângere a un ui sistem informatic de
contabilitate;
b) nu este înso țit de constrângeri;
c) este o component ă „închisă” care nu permite modific ări.
Care dintre enun țurile a), b) și c) este adev ărat. Justifica ți.
_____________________________________________________________
_______________________________________________________________________________________________________________________________________________________________________________________ 3. Controlul accesului se asigur ă prin:
a) constrângerile personalizate;
b) constrângerile de identificare;
c) constrângerile administrative.
4. Enumerați domeniile unui sistem informa țional de contabilitate:
_____________________________________________________________
__________________________________________________________________________________________________________________________ 5. Cerințele de calitate ale unui produs sunt:
_____________________________________________________________
_____________________________________________________________
6. Mentenabilitatea este:
_____________________________________________________________
_____________________________________________________________ 7. Ergonomia este:
_____________________________________________________________
____________________________________________________________
27
TEMA 3. REALIZAREA SISTEMELOR INFORMATICE
DE CONTABILITATE
CONȚINUT
3.1. Metodologii de realizare a sistemel or informatice de contabilitate
3.3. Metoda Unified Modeling Language. Prezentare
REZUMAT
Realizarea sistemelor informatice se desf ășoară în trei etape mari:
analiză, proiectare și implementare. Metodologiile de realizare pot fi de
ajutor în proiectarea și implementarea sistemelor informatice.
OBIECTIVE
Tema propus ă are ca scop în țelegerea modului în care se pot realiza
sistemele informatice de contabilitate.
3.1. METODOLOGII DE REALIZARE A SISTEMELOR
INFORMATICE DE CONTABILITATE
Sistemele informatice, la fel ca oricare alt produs, au o existen ță
limitată – înlocuirea total ă sau parțială fiind necesar ă din timp în timp.
Ciclul de via ță al sistemului informatic este definit de intervalul de timp
CV = [T1, T2] unde T1 reprezint ă momentul în care s-a decis elaborarea
sistemului iar T2 reprezint ă abandonarea sistemului. Acest interval este
abordat metodic în etape ca analiza, modelarea, dezvoltarea, testarea,
utilizarea, mentenan ța până la retragerea sistemului . Din punctul de vedere
al utilizatorului final cele mai im portante etape sunt utilizarea și mentenan ța.
Ciclu de realizare este dat de interval ul CR=[T1,T2], unde T1
reprezintă momentul lu ării deciziei de realizare iar T2 momentul punerii în
funcțiune. Acest interval este cel mai important din punctul de vedere al
realizatorilor. Realizarea sistemelor informatice se desf ășoară în etape pe baza
unor modele și strategii de implementare. Între etapele de realizare a
sistemelor informatice exist ă
o legătură directă și indestructibil ă, calitatea
unei etape fiind premisa calit ății unei etape succesoare. Metodologiile
aplicate trebuie s ă cuprindă toate aspectele referitoare la realizarea unui
sistem informatic:
• „etapele/procesele de realizar e a unui sistem informatic
structurate în subetape, activit ăți, sarcini și conținutul lor;
• fluxul realiz ării acestor etape/procese, subetape și activități;
• modalitatea de derulare a ciclului de via ță a sistemului
informatic;
• modul de abordare a sistemelor;
28
• strategiile de lucru/me todele de realizare;
• regulile de formalizare a componentelor sistemului informatic;
• tehnicile, procedurile, instrumentele, normele și standardele
utilizate;
• modalitățile de conducere a proiectulu i (planificare, programare,
urmărire) și modul de utilizare a resurselor financiare, umane și
materiale etc.”1
Cum fiecare teorie dezvoltat ă folosește proprii termeni, în condi țiile
în care se dore ște alegerea celei mai potrivite metodologii de realizare,
novicii pot întâmpina greut ăți în studiul tuturor metodologiilor.
Clasificarea metodologiilor de realizare a sistemelor informatice de
contabilitate
Multitudinea de metodologii se clasific ă după criterii diverse cum ar
fi: gradul de generalitate, modul de a bordare a sistemelor, modelul ciclului
de viață ([LUN03]).
Clasificarea metodologiilor de re alizare a sistemelor informatice
după gradul de generalitate :
1. metodologii generale – cu grad înalt de generalitate (SSDAM –
Structured System Analysis and Design Methodology, OMT –
Object Modeling Technique);
2. metodologii dedicate care se aplic ă fie numai unor categorii de
produse software fie numai unui singur produs software.
Clasificarea metodologiilor de re alizare a sistemelor informatice
după modul de abordare a sistemelor:
1. metodologii cu abordare structurat ă – sistemul se poate împ ărți în
subsisteme fie din punct de vedere func țional fie pe baza grup ării
logice a datelor (STRADIS – St ructured Analysis and Design
Information Systems, YSM – Yourdon Systems Methods);
2. metodologii cu abordare orientat ă obiect – folosesc conceptele
tehnologiei orientat ă obiect (UML – Unified Modeling Language,
OOD – Object Oriented Design, OOA – Object Oriented Analysis,
OOSD – Object Oriented Structured Design)
Clasificarea metodologiilor de re alizare a sistemelor informatice
după modelul ciclului de via ță:
1. metodologii cu model în cascad ă – etapele se parcurg succesiv, la
terminarea unei etape se poate reveni la o etap ă anterioar
ă (vezi
figura 3.1);
1 Lungu, I., Sab ău, G., Velicanu, M. – „ Sisteme informatice. Analiz ă, proiectare și
implementare ”, Editura Economic ă, București 2003, pagina 81
29
Figura 3.1. Etapele modelului în cascad ă
Sursa: Lungu, I., Sab ău, G., Velicanu, M. ș.a. – „ Sisteme informatice.
Analiză, proiectare și implementare ” pagina 87
2. metodologii care folosesc modelul prototipului – se elaboreaz ă o
primă versiune simplificat ă cu funcționare minim ă care este urmat ă
de versiuni succesive îmbun ătățite până se atinge func ționarea
completă conform cerin țelor beneficiarului (vezi figura 3.2);
Figura 3.2. Modelul prototipului
Sursa: Lungu, I., Sab ău, G., Velicanu, M. ș.a. –
„Sisteme informatice. Analiz ă, proiectare și
implementare ” pagina 87
3. metodologii incrementale – se folosesc când sistemele informatice se
pot pune în func țiune modular prin realizar ea subsistemelor. Etapele
acestor metodologii sunt cele ale modelului în cascad ă cu deosebirea
că proiectarea, implem entarea, testarea și utilizarea și întreținerea se
realizează separat, pentru fiecare subsistem în parte;
Prototip n
Prototip 2 …
Prototip 1 Definirea
cerințelor
Analiza
Proiectarea
Implementarea
Testarea
Utilizarea și
mentenața
30
4. metodologii evolutive – se folosesc în cazul realiz ării sistemelor
complexe; se face o descompunere în subsisteme de complexitate redusă și pentru fiecare subsistem se realizeaz ă un sistem informatic.
În finalul procesului toate subsistemele informatice se asambleaz ă.
Clasificarea metodologiilor de proi ectare a sistemelor informatice pe
baza metodelor folosite ([ORZ05, pagina 170):
• metodologii bazate pe metode de proiectare „pe m ăsură” sau la
comandă – sistemele informa țional se analizeaz ă pas cu pas, cu
reveniri la pa șii anteriori, abordarea problemelor f ăcându-se de
la general spre detaliat;
• metodologii bazate pe metode de proiectare „în serie” – întâi se
realizează sistemul informatic pentru o unitate economic ă pilot;
acest sistem se extinde în func ție de prin adaptare și integrare în
funcție de specificul și/sau domeniului unit ății economice;
• metodologii bazate pe metode de proiectare automat ă – sistemul
se realizeaz ă prin instrumente software de asistare cu ajutorul
calculatorului;
Un aspect comun pentru toate me todologiile descrise este acela c ă
trecerea de la o etap ă la alta se face numai dup ă o analiză a activităților, și,
pentru fiecare activitate, se stabilesc regulile, standardele de calitate și
instrumentele și tehnicilor utilizate.
Modelul în cascad ă
Fiecare etap ă
a modelului în cascad ă (vezi figura 3.1) are un scop
bine stabilit și se bazeaz ă pe rezultatele etapei precedente ([MIH03]):
– definirea cerin țelor – această etapă are ca scop faptul c ă trebuie s ă
identifice cerin țele de realizare;
– analiza – aceast ă etapă are ca scop descrierea cerin țele de
funcționare într-un document;
– proiectarea – are ca scop stabilirea arhitecturii sistemului
informatic și se face în dou ă sub-etape: proiectarea de ansamblu (se
rafinează cerințele de func ționare și restricțiile de func ționare, se
stabilește arhitectura produsului software etc.) și proiectarea de
detaliu (se specific ă algoritmii, modulele, interfe țele, fluxurile de
date, fluxurile de control etc.);
– implementarea – aceast ă etapă are ca scop realizarea produsului
software care poate fi compus din module, componente speciale, programe utilitare etc.;
– testarea – fiecare element constituent cât și întregul sistem
informatic de contabilitate trebuie testat; testarea este o activitate important ă care trebuie s ă se desfășoare înainte de punerea în
funcțiune la utilizatorul final;
– utilizarea și mentenan
ța – este etapa în care sistemul informatic
este instalat la utilizatorul final și pus în func țiune; de obicei,
aceasta se face modular împreun ă cu testarea fiec ărei componente
la locul de munc ă. Testarea se face atât la nivel func țional cât și la
nivelul interfe țelor – utilizatorul final poate avea obiec ții referitoare
la designul formularele de introduc ere a datelor, la listele afi șate, la
31
rapoartele generate.
În cadrul fiec ărei etape se elaboreaz ă documenta ția etapei care se
constituie ca un rezultat al etapei. Dintre aceste documente amintim: „Proiectul de ansamblu”, „Proiectul de detaliu”, „Specifica ția de testare”
(precizeaz ă planul de testate, me diul de test, cazurile și procedurile de
testare), „Raportul de testare”, „Manualul de utilizare” etc.
3.2 METODA UNIFIED MODELING LANGUAGE. PREZENTARE
Modelarea este activitatea prin care se descrie un sistem prin intermediul unui ansamblu e nota ții specifice. UML (acronim pentru
Unified Modeling Language) este un limbaj de modela re care dispune de un
sistem de nota ții, de principii și procedee care pot folosi în procesul de
abstractizare și, foarte important în dezvoltarea sistemelor informatice,
dispune de mecanisme prin care s ă poată fi extins pentru a putea fi folosit în
cazul unor sisteme informa ționale speciale. UML este un limbaj de
modelare care a fost standardizat de c ătre grupul OMG
1 pe baza unor
metode de modelare existente în momentul standardiz ării (OML – Open
Modeling Language, metoda Booch, OMT – Open Method Technique,
OOSE – Object Oriented So ftware Engineering).
Concepte utilizate
Câteva dintre aceste metode se folosesc în reprezent ări de: obiecte
(object ), clasa de obiecte (pe scurt clasă), abstractizare, încapsulare,
moștenire și polimorfism.
Obiectul poate fi considerat un model abstract al oric ărei entități
fizice sau ne-fizice. Un obiect se caracterizeaz ă prin: identitate, stare și
comportament. Identitatea este unic ă și se poate cuantifica printr-un
identificator unic (numeric și/sau text) prin care obiectele se diferen țiază
între ele. Factura num ăr 2254/22.09.2007 și Factura num ăr
2264/22.09.2007 sunt dou ă obiecte distincte care se identific ă în mod unic
în anul 2007 prin num ăr 2254 respectiv 2264. Pe o perioad ă de mai mul ți
ani, facturile se identific ă în mod unic prin ansamblul format din num ărul
facturii și din data calendaristic ă 2254/22.09.2007 respectiv
2264/22.09.2007. Unui obiect i se ata șează un set de propriet ăți (atribute) care con țin
informații despre acesta. De exemplu Beneficiar este o proprietate a unei
facturi care poate lua valori ca „SC Urania SRL”, „SA P ădurea de Aram
ă”,
„SC AmiciiContab SRL” etc. Valoarea total ă este o alt ă proprietate a unei
facturi care poate lua valori numerice. Starea unui obiect este reprezentat ă de toate valorile interne ale
proprietăților. În momentul în care se modific ă starea unui obiect,
identificatorul acestuia nu se modific ă. De exemplu, fie factura 2254 care
1 Object Management Group
32
are Valoarea total ă de 2345,56 lei pentru 3 produse, dac ă Valoarea total ă se
modifică la 3443,76 lei pentru N+1 produse, num ărul de factur ă rămâne
nemodificat. Comportamentul este dat de mul țimea opera țiilor care se
efectueaz ă de către obiect atunci când se ac ționează asupra lui; „clien ții”
obiectului (alte obiecte care îl utilizeaz ă) emit cerin țe către obiect iar
obiectul „r ăspunde” prin setul de opera ții care îi este ata șat; de exemplu,
obiectul factura 2254 are ata șată operația Calculeaz ăTVA care este folosit ă
în operația de contare a TVA. Mul țimea opera țiilor se compune din metode
care din punct de vedere programatic pot fi func ții și/sau proceduri.
Clasa de obiecte , pe scurt clasa, grupează obiectele cu aceea și
structură (adică aceleași propriet ăți) și același comportament. Clasa
Facturi
grupează toate obiectele factură c a r e s e i d e n t i f i c ă în mod unic printr-un
număr, au acelea și propriet ăți (beneficiar, valoare total ă etc.). Desigur, la o
analiză mai atent ă, descoperim c ă putem folosi dou ă clase FacturiIntrare și
FacturiEmise . Într-un sistem informa țional, clasa se identific ă în mod unic
printr-un nume pentru care se recomand ă să se foloseasc ă un grupaj de unu
sau mai multe cuvinte/prescurt ări care să aibă legătură directă cu obiectele
din lumea real ă pe care le modeleaz ă. Pentru o analiz ă serioasă, ar fi de-a
dreptul ciudat ca pentru facturile emise s ă se modeleze clasa „PiticiPla ți”
sau „HârtiiBicolore”. Cum o clas ă este o abstrac țiune, care descrie toate
caracteristicile comune ale unui grup de obiecte, clasa nu reprezint ă un
obiect . Un obiect se ob ține dintr-o clas ă prin instanțiere. Putem spune c ă o
instanță reprezint ă un obiect al clasei care se distinge de alte instan țe ale
clasei prin valorile diferi te ale atributelor/propriet ăților.
Abstractizarea este un proces pe care omul îl folose ște, conștient
sau nu, în permanen ță pentru a extrage ceea ce este esen țial din lumea
înconjurătoare. Fiind un proces subiectiv, care se face diferit de c ătre
oameni diferi ți (prin vârst ă, cultură, nivel de educa ție), abstractizarea devine
cel mai sensibil proces care se utilizeaz ă în informatic ă pentru modelarea
sistemelor tocmai pentru c ă experien ța și puterea personal ă de abstractizare
a fiecăruia dintre cei implica ți în modelare sunt de talii care pot provoca
succesul sau insuccesul unui sistem info rmatic de contabilitate. Cu toate c ă
în viața de zi cu zi fiecare se descurc ă în abstractizarea lu mii reale, a explica
unui neavizat ce este esen țial în contabilitate (ce este un cont, cum
funcționează, cum se face contarea unui docum ent justificativ) poate deveni
o muncă pe care pu țini sunt dispu și să o facă. Succesul unei echipe mixte
formată din contabili și inforrmaticieni vine și din modul în care fiecare
poate înțelege abstractiz ările făcute de cel ălalt. Aceasta impune g ăsirea unui
limbaj comun în care un obiect (cont, chitan ță, balanță
) să ajungă să aibă o
aceeași semnifica ție atât pentru contabil cât și pentru informatician.
Încapsularea este un proces prin car e se ascund detaliile de
implementare a comportamentului astfel încât interfa ța (adică partea public ă
a clasei) oferit ă de clasa de obiecte s ă fie clară, în concordan ță cu elementele
obținute în urma abstractiz ării. Încapsularea este proprie programatorilor și
se poate considera c ă este bine f ăcută atunci când diagramele de clase
stabilite pentru sistemul informatic nu sufer ă modificări profunde.
33
Moștenirea se manifest ă într-o ierarhie de clase. În acest caz,
ierarhia nu trebuie în țeleasă ca o subordonare. Mo ștenirea din cadrul
claselor de obiecte se refer ă la modul în care clasele de obiecte î ți partajeaz ă
proprietățile și comportamentul. Exemplul clas ic este cel al mamiferelor.
Mamifere este clasa care are propriet ățile cu valorile: membre:4; tip_sânge:
cald și comportamentul dat de: NaștePuiVii . O clasă aflată pe un nivel
inferior și care mo ștenește clasa Mamifere este Canide care mo ștenește
proprietățile și comportamentul clasei Mamifere dar care are suplimentar
proprietatea CuloareBlan ă iar comportamentul se îmbog ățește cu metoda
Latră. În lumea contabilit ății o clasă poate fi Document care are propriet ățile
Număr și Data iar o clas ă care moștenește clasa Document poate fi clasa
Chitanțe care are suplimentar propriet ățile Client și Suma . Despre clasele
care moștenesc se mai spune c ă sunt clase derivate iar despre clasele
moștenite se spune c ă sunt superclase sau clase p ărinți. Conceptul de
moștenire este important în proces ul de abstractizare pentru c ă permite ca
părțile comune (care se suprapun) s ă fie tratate în manier ă identică o singură
dată în clasa p ărinte dar fiind valabile în toate clasele derivate, p ărțile care
disting clasa derivat ă de clasa p ărinte se trateaz ă doar în clasa derivat ă fără
ca să fie influen țată clasa părinte.
Figura 3.3 Reprezentarea rela ției de moștenire dintre superclasa
MijlocTransport și clasele derivate Autobuz , Autoturism , Camion
Polimorfismul reprezint ă capacitatea unei metode de a fi func țională
în clase de obiecte distincte. De exemplu, pentru superclasa Documente se
poate defini metoda Procesare care va fi definit ă în fiecare dintre clase în
mod diferit. Alte concepte utilizate ([DAV03]):
• acțiunea – opera țiile instantanee, neîntrerupte, asociate
evenimentelor;
• activitatea – opera țiile care dureaz ă în timp, întreruptibile;
• agregarea – obiectele sunt reprezen tate de componente în cadrul
unui obiect privit ca întreg;
• asocierea – un ansamblu de leg ături; se identific ă prin nume unic
și poate avea ata șată o multiplicitate care exprim ă numărul de
asocieri în contextul dat;
• relația/legătura/asocierea dintre obiecte – o conexiune
logică/fizică dintre obiectele apar ținând unei clase; MijlocTransport
An fabrica ție
Capacitate motor
Model
Autobuz
NumărLocuri
Etajare Autoturism
NumărLocuri
NumarUși Camion
Tonaj
34
• mesajul – cerere adresat ă unuia sau mai multor obiecte prin care
se pot solicita date sau se modific ă starea obiectului (obiectelor);
• starea obiectului – se define ște prin valorile propriet ăților unui
obiect la un moment dat; starea se modific ă prin acțiunea unor
stimuli externi obiectului (evenimente);
• tranziția – trecerea obiectelor de la o stare la alta prin utilizarea
unor mesaje specifice.
Etapele UML
Utilizarea UML presupune parcurgerea urm ătoarelor etape
([LUN03]):
– definirea problemei – se stabil esc caracteristicile principale și
modul de func ționare a activit ății de implementat;
– structurarea solu ției – se determin ă și se detaliaz ă cerințele
utilizatorului final;
– analiza sistemului – se analizeaz ă cazurile de utilizare și se extrag
conceptele cele mai importante cu care lucreaz ă sistemul;
– construirea solu ției – se realizeaz ă o analiză detaliată a modelului
pentru a se ob ține o variant ă care să fie ușor de translatat în cod
scris într-unul sau mai multe limbaje de programare;
– proiectarea sistemului care pres upune proiectarea de ansamblu (se
definesc subsistemele și relațiile dintre acestea) și proiectarea de
detaliu (se detaliaz ă subsistemele și se rafineaz ă descrierea
relațiilor dintre acestea);
– implementarea sistemului – se efectueaz ă programarea și se
construiește diagrama componentelor software rezultate.
Structurarea solu ției este etapa care trebuie s ă elaboreze modelul
comunicării dintre echipa de analiz ă informatic ă și echipa care reprezint ă
utilizatorii finali (echipa care are cuno ștințe despre func ționarea sistemului
informațional contabil). Comuni carea dintre aceste dou ă echipe este foarte
important ă pentru că noțiunile folosite se deosebesc func țional; astfel echipa
informaticienilor pot în țelege prin „tabel” un obiect al unei baze de date care
are atașată o structur ă de câmpuri cu atribute limitate din punct de vedere
funcțional; un membru al echipei utilizatorilor poate în țelege „tabel” fie ca
un document de întrare care con ține un registru scris de mân ă al încasărilor
dintr-o zi, fie un rezultatul unei sort ări a denumirilor ter ților. Documentele
elaborate în cadrul acestei etape cuprind diagramele cazurilor de utilizare.
Analiza sistemului este etapa în care se studiaz ă diagramele cazurilor
de utilizare (create în cadrul etapei precedente) și se extrag elementele cu
care lucreaz ă sistemul. Pentru a se eviden ția relațiile dintre elemente,
atributele și comportamentul lor, se construiesc urm ătoarele diagrame:
• diagramele claselor;
• diagramele obiectelor;
• diagramele de stare și/sau diagramele de activitate;
• diagramele de secven ță;
• diagramele de colaborare.
Câteva dintre aceste diagrame vor fi studiate într-un capitol viitor.
Construirea solu ției este etapa în care se încearc ă obținerea unui
model îmbog ățit care s ă fie mai u șor de translatat într-un limbaj de
35
programare. Interven ția programatorilor poate determina crearea unor clase
noi, relații, diagrame noi care trebuie s ă reflecte gestionarea datelor (de
exemplu în prezen ța unei baze de date), comunicare cu exteriorul sistemului
(de exemplu pentru comunicarea prin e-mail etc.). Proiectarea de ansamblu definește arhitectura sistemului (prin
subsistemele și interacțiunile dintre ele) și, pentru fiecare subsistem, se
descriu printr-o proiectare de detaliu clasele, se rafineaz ă comportamentele
prin adăugarea și/sau modificarea metodelor claselor ob ținute în etapele
anteriore. Implementarea sistemului reprezint ă etapa de programare propriu-
zisă. În aceast ă etapă se folosesc diagramele create anterior și diagramele
componentelor software, se scrie codul surs ă și se obțin componentele
software.
BIBLIOGRAFIE
1. [DAV03] Davidescu, N. D. – Proiectarea sistemelor informatice prin
limbajul Unified Modeling Language , Editua All Beck, Bucure ști 2003
2. [LUN03] Lungu, I., Sab ău, G., Velicanu, M. ș.a. – „Sisteme
informatice. Analiz ă, proiectare și implementare”, Editura Economic ă,
București, 2003
3. [MIH03] Mihalca, Rodica, Fabian, C. – Realizarea produselor program
aplicative , Editura ASE, Bucure ști 2003
***
1. http://www.sparxsystems.com.au
TESTE DE EVALUARE
1. Ciclul de realizare a sistem ului informatic definit de:
_____________________________________________________________
______________________________________________________________________________________________________________________________________________________________________________________ 2. Ciclul de via ță a sistemului informatic definit de:
a) intervalul de timp CV = [T1, T2] unde T1 – reprezint ă
momentul în care s-a decis cump ărarea sistemului iar T2
reprezintă abandonarea sistemului;
b) intervalul de timp CV = [T1, T2] unde T1 – reprezint ă
momentul în care s-a decis el aborarea sistem ului iar T2
reprezintă abandonarea sistemului;
36
c) intervalul de timp CV = [T1, T2] unde T1 – reprezint ă
momentul în care s-a decis docu mentarea sistemului iar T2
reprezintă casarea sistemului.
3. Etapele realiz ării sistemelor informatice prin intermediul Unified
Modeling Language sunt:
_____________________________________________________________
_______________________________________________________________________________________________________________________________________________________________________________________ 4. Completa ți schema de mai jos astfel încât s ă reprezinte un model
incremental de realizare a sistemelor informatice:
5. Etapele modelului în cascad ă sunt:
_____________________________________________________________
_________________________________________________________________________________________________________________________ 6. Clasa grupeaz ă:
a) obiecte cu acela și nume și număr de identificare;
b) obiecte cu aceea și structură și stări diferite;
c) obiecte cu aceea și structură și același comportament. Definirea
cerințelor
Analiza
Proiectarea
subsistemului 1
Implementarea
subsistemului 1
Testarea
subsistemului 1
Utilizarea și
întreținerea
subsistemului 1 Proiectarea
subsistemului 2
Utilizarea și
întreținerea
subsistemului n …
…
…
…
37
TEMA 4. MODELAREA SISTEMULUI INFORMATIC DE
CONTABILITATE
CONȚINUT
4.1. Specificații generale ale metodei Unified Modeling Language
4.2. Diagrame utilizate de UML
REZUMAT
Unified Modeling Language (UML) este potrivit pentru modelarea
sistemelor informatice de contabilitate datorit ă unor caracteristi ci cum ar fi:
folosește abstractiz ări prin care structurile complexe contabile devin
accesibile pentru anali știi informaticieni și designeri nespeciali ști în
contabilitate; utilizeaz ă modelarea vizual ă și permite dezvoltarea unei
ierarhii de modele, vederi și diagrame.
OBIECTIVE
Tema propus ă are ca scop în țelegerea primar ă limbajului UML și a
modului în care se poate folosi în modelarea pentru realizarea sistemele
informatice de contabilitate.
4.1 SPECIFICA ȚII GENERALE ALE METODEI UNIFIED
MODELING LANGUAGE
Analiza și proiectarea sunt dou ă etape importante ale ciclului de
viață al unui sistem informatic de c ontabilitate. Scrierea programelor f ără
efectuarea acestor etape înseamn ă o decizie care, de cele mai multe ori, se
dovedește a fi o decizie gre șită cu repercusiuni în etapele de implementare,
testare și mentenan ță (întreținere) – timpul câ știgat aparent prin ignorarea
analizei și proiectării se r
ăzbună prin detectarea eror ilor logice de c ătre
utilizatorul final, prin nerespectarea cerin țelor de calitate și de funcționare
contabilă.
Ob ținerea unui model se face printr- un proces de modelare prin care
se definesc cerin țele individuale ale sistemului informatic de contabilitate.
Definirea acestor cerin țe poate lua forma unor modele de date, modele
funcționale, de proc es sau organiza ționale, fiecare înso țit de o documenta ție.
Rolul jucat de un model pent ru realizarea unui sistem informatic este similar
rolului jucat de un proiect de cas ă întocmit înainte de a începe construirea
casei. Sistemul modelat prin intermediul UML va fi descris prin următoarele aspecte ([DAV03], pagina 12):
• aspectele organiza ționale – specificul activit ății utilizatorului
final, definirea modulelor etc;
• aspectele non-func ționale – amplasament, coordonare, etc.;
38
• aspectele func țional – structura static ă, structura dinamic ă
(comportamental ă), interacțiunile etc.
UML prezint ă următoarele caracteristici car e îl face potrivit pentru
modelarea sistemelor informati ce de contabilitate ([DAV03]):
• este un limbaj universal care se poate folosi pentru realizarea
sistemelor informatice;
• folosește abstractiz ări prin care devin acc esibile structurile
complexe pentru anali știi informaticieni și designeri nespeciali ști
în domeniul pentru care se modeleaz ă sistemul informatic;
• abordează modelarea obiectual ă care asigur ă eficiență prin
reutilizarea componentelor care pot fi privite ca un ansamblu de
obiecte inter-cooperante și care se pot organiza într-o structur ă
ierarhică ([DAV03]);
• permite dezvoltarea unei ie rarhii de modele, vederi și diagrame
(vezi figura 4.1;
• utilizează modelarea vizual ă.
Vederile
Vederile prezintă, sub form ă de succesiune de diagrame, unele
aspecte ale sistemului modelat:
• vederea cazurilor de utilizare – descrie modul de func ționare a
sistemului și se caracterizeaz
ă prin:
o folosește cazurile de utilizare și actorii. Actorii pot fi:
interni (fac parte din sistem ) sau externi (sunt exteriori
sistemului – clien ți, furnizori, b ănci etc);
o conține diagrame ale cazurilor de utilizare și, opțional,
diagrame ale activit ăților;
o destinația lor este format ă din utilizatorul final al sistemului
informatic, designeri, dezvoltatori (anali ști, programatori,
testori);
• vederea logic ă descrie modul de func ționare al sistemului din
două perspective: static ă (prin intermediul diagramelor de obiecte,
diagramelor de clase) și dinamic ă (cu ajutorul diagramelor de
activitare, diagramelor de st ări-tranziții, diagramelor de
colaborări); destina ția este compus ă din designeri și dezvoltatorii
sistemului noi;
• vederea componentelor – descrie implementarea modulelor și
componentele prin detalii cum ar fi: structurile și tipurile de date,
resursele care trebuie alocate (memorie intern ă, hard-disk etc.);
• vederea concuren ță – este o vedere non-func țională prin care se
descrie structura sistemului prin structurare în procese și
procesoare (cu scopul aloc ării eficiente a resurselor); diagramele
sunt destinate dezvoltatorilor; diagramele utilizate diagramele dinamice și diagramele de implementare;
• vederea amplasamentului se folose ște pentru redarea în mod
grafic a locurilor în care vor fi amplasate echipamentele utilizate
în cadrul sistemului informatic (calculatoare, case de marcat, puncte în care apar tranzac ții bancare etc.), se pot folosi
39
instrumente de reprezentare ale re țelelor de calculatoare
(topologii); diagramele folosite sunt diagramele de amplasament.
Figura 4.1 Ierarhia de modele, vederi și diagrame utilizate de UML
Sursa: Davidescu, N. D. – Proiectarea sistemelor informatice
prin limbajul Unified Modeling Language , pagina 2
UML pune la dispozi ție o extensie pentru modelarea specific ă lumii
afacerilor ceea ce constituie un avantaj în realizarea sistemelor informatice
de contabilitate. Reprezentarea grafic ă a elementelor în modelele UML este
prezentată în tabelul 4.1.
Tabel 4.1
Elementele diagramelor UML
Element Reprezentare
(1) (2)
Elemente structurale
Clasă
Nume clasă
Proprietăți b) Nume clasă a) UML
Modele de
analiză Modele de
proiectare Modele de
proiectare
Vederea
cazurilor de
utilizare Vederea
logică Vederea
componen-
telorVederea
concurență
Diagrama
cazuri de
utilizare Diagrama
componen-
telorDiagrama
partajărilor
hardware Vedere
statică Vedere
dinamică
Cazuri
de test
Fișiere
de test Diagrama
subsiste-
melo r Diagrama
claselor Diagrama
obiectelor Diagrama
activitățilorDiagrama
stări+
tranzițiiDiagrama
colaboră-
rilor
40
Instanță
Interfață
Caz utilizare
Nod
Colaborare
(1) (2)
Component ă
Elemente comportamentale
Interacțiune
Stare
Relații Nod Nume caz
utilizare Identificator
Proprietate 1: valoare 1
Proprietate 2: valoare 2 …
Proprietate N: valoare N
Metoda 1
Metoda 2
…
Metoda M
Responsabilitate 1
Responsabilitate 2
….
Responsabilitate PNume clasă
Proprietăți
Operații
Responsabilit ăți d) Nume clasă
Proprietăți
Operații c)
Nume interfa ță
Nume colaborare
Nume component ă
Nume
Nume stare
41
Dependen ță
Asociere
Agregare
Alte elemente
Pachet
Notă
Eticheta
Clasa se poate reprezenta în patru variante: a) numai numele clasei;
b) numele clasei și proprietăți; c) numele clasei, propriet ăți și operațiile care
definesc comportamentul (metode le); d) complet: nume, propriet ăți, metode
și responsabilit ăți. Un tip special de clas ă este clasa activă care poate ini ția
control și se reprezint ă grafic împreun ă cu procesele sau firele de execu ție.
Componenta este o parte fizic ă înlocuibil ă a unui sistem. Nodul ,
element fizic, poate fi o resurs ă de calcul, poate de ține memorie și capacități
de procesare. Interfața unui obiect se constituie din mul țimea de opera ții prin care
clasa realizeaz ă un serviciu. Colaborarea reprezint ă u n a n s a m b l u d e
elemente care prin comportament cooperativ sunt mai eficiente decât dac ă ar
fi lucrat separat. Cazul de utilizare descrie sucesiunea de ac țiuni care sunt
executate pentru a ob ține un rezultat de a șteptat de c ătre un actor al
sistemului. Interacțiunea reprezint ă mesajele schimbate între obiecte pentru
atingerea unui scop.
Etichetele se folosesc atunci când se linia, care reprezint
ă trecerea de
la o activitate la alta: a) este întrerupt ă sau b) când mai multe linii trebuie
unite pentru a reprezenta o jonc țiune. Numele etichetelor trebuie ales în a șa
fel încât s ă nu se confunde cu nume altor el emente (clase, act ori); de obicei
Nume pachet Clasa 1
Clasa 2 1
*
A b) A A a) 0..1 *
rol rol
Nume not ă
42
se folosesc fie literele mari ale alfa betului fie cifre sistemului zecimal de
numerație.
Un pachet se folose ște pentru organizarea elementele în blocuri prin
care se simplific ă reprezentarea unor diagrame detaliate în alt ă secțiune a
modelului. Nota se folosește pentru ad ăugarea comentariilor referitoare la
un element sau un grup de elemente. O relație reprezint ă o conexiune între dou ă elemente; dup ă natura
acestei conexiuni rela țiile sunt:
– de dependen ță (când modificarea st ării unui element determin ă
modificarea st ării altui element cu care se afl ă în conexiune);
– de asociere (când fiecare dintre elementele implicate în conexiune
sunt independente, fiecare având rolul s ău în conexiune;
– de agregare (când o clas ă conține părți care se pot modela prin
alte clase; de exemplu o clas ă pentru clasa Factura poate fi
modelată ca fiind o agregare a claselor AntetFactura și
LiniiFactura .
Cardinalitatea unei rela ții reprezint ă numărul de instan țe care pot fi
implicate în rela ție la un moment dat. Ca rdinalitate de reprezint ă
prin limita
inferioară și limita superioar ă, cu observa ția că dacă nu se cunoa ște limita
superioară aceasta se indic ă prin caracterul *; de exemplu, în cazul agreg ării
de mai sus, cardinalitatea pentru clasa AntetFactura este 1 iar pentru
LiniiFactura 1..*.
4.2 DIAGRAME UTILIZATE DE UML
Diagramele „sunt prezent ări grafice ale unui set de elemente, cel mai
adesea exprimate ca un graf de noduri (elemente) și arce (rela țiile)”1. În
continuare se vor prezenta diagramele care se pot folosi pentru construirea
unui model utilizând UML.
Diagrama de clase
Diagramele de clase se folosesc pentru reprezentarea grafic ă a
claselor și a relațiilor dintre ele. Sunt cele mai folosite diagrame în
modelarea sistemelor și ilustreaz ă vederea static ă de proiectare a unui sistem
care
oferă suport în primul rând cerin țelor utilizatorilor finali func ționale ale
sistemului . Elementele con ținute într-o diagram ă de clase sunt:
• clasele de obiecte, interfe țe și colaborări;
• relații între clase;
• elemente de notare;
• mecanisme de extensie (constrângeri, valori etichetate);
• pachete sau subsisteme;
1 Mihalca, Rodica, Fabian, C. – Realizarea produselor program aplicative , pagina 5-93
43
Figura 4.2 Diagrama claselor
Adaptat dup ă: [DAV03], pagina 14
În figura 4.2 diagrama claselor prezint ă:
1. clasele implicate într-o opera țiune bancar ă (terț, operație bancar ă,
instrument de plat ă, ordin de plat ă, cambia, cec); în aceast ă figură,
pentru simplificare, nu s-au re prezentat atributele claselor;
2. relațiile dintre clase (reprezentate prin s ăgeți cu nume, de exemplu
conține): Operația bancar ă poate con ține un document de plat ă de
clasă ordin de plat ă, cambie sau cec;
3. cardinalitatea rela țiilor – în figura 4.2 semnifica țiile lor sunt:
a) 1..*, pentru clasa Terț, înseamn ă că unul sau mai multe
obiecte de clas ă Terț poate face mai multe opera ții bancare;
b) 1..*, pentru clasa Operație bancar ă, înseamn ă operațiile
bancare pot fi efectuate de unul sau mai mul ți terți;
c) 1..*, pentru clasa Instrument plat ă, înseamn ă unul sau mai
multe instrumente de plat ă compun o opera ție bancară;
d) 0..* înseamnă că un obiect de clas ă Operație bancar ă poate
folosi zero sau mai multe instrumente de plat ă de tipurile
ordin de plat ă, cambie sau cec.
4. rolurile claselor sunt:
a) efectuează pentru clasa Terț în relația cu clasa Operație
bancară;
b) efectuată pentru clasa Operație bancar ă în relația cu clasa
Terț;
c) conține pentru clasa Operație bancar ă în relația cu clasa
Instrument plat ă;
d) compune pentru clasa Instrument plat ă în relația cu clasa
Operație bancar ă.
Diagramele obiect
Diagramele obiect reprezint ă o variant ă a diagramelor claselor și
care reflect ă instanțele claselor con ținând pentru valorile atributelor, rela țiile
dintre instan țe și, pentru un model rafinat destinat și programatorilor, detalii
specifice pentru tipurile at ributelor (vezi figurile 4.5 și 4.6).
TERȚ OPERAȚIE
BANCAR Ă
INSTRUMENT
PLATĂ
CAMBIA CEC ORDIN DE
PLATĂ conține 0..*1..* 1.. *
efectueaz ă
1..*efectuată
compune
44
Figura 4.5 Diagrama claselor Terț și Factura
Figura 4.6 prezint ă o instanță a clasei Terț și două instanțe ale clasei
Factura .
Figura 4.6 Instanțe ale obiectelor Terț și Factura
Diagramele cazurilor de utilizare
Diagramele cazurilor de utilizare se utilizeaz ă pentru modelarea
aspectelor dinamice ale sistemului (comportamentului unui sistem,
subsistem sau al unei clase) și conține cazuri de utilizare, actori, rela ții de
dependen ță, de generalizare și de asociere, note și constrângeri și pachete.
Simbolurile folosite sunt prezentate în figura 4.3 (Sursa: [DAV03], pagina
33).
actor
Generalizare
Figura 4.3 Simboluri folosite în diagrama cazurilor de utilizare SC LUMIRA
J: 35/405/1999
CUI: 16257325
Sediul: Oravi ța
Judetul: Timi ș
Contul: RO56008978
Banca: BRLocal TM ABA
Numar: 22348
Data: 17.07.2007
Cota TVA: 19
Valoarea: 210,10
Valoarea TVA:39,90
Total de plata:250
Delegat: Neac șu Dan
TM ACD
Numar: 589632
Data: 25.01.2008
Cota TVA: 19
Valoarea: 917,60
Valoarea TVA:82,58
Total de plata:100,18
Delegat: Vesa Pavel TERȚ
J
CUI
Sediul
Judetul
Contul
Banca FACTURA
Numar
Data
Cota TVA
Valoarea
Valoarea TVA
Total de plata
Delegat
numele sistemului sau
a
subsistemului numele cazului
de utilizare
caz de
utilizareasociere caz de
utilizare
caz de
utilizare
45
Diagramele cazurilor de utilizar e se pot completa cu descrieri
textuale care con țin informa ții privind cerin țele și funcționalitatea
sistemului. Cum actorii (ter ț este un actor în figura 4.4) se poate reprezenta
prin clase, este evident c ă se pot modela și relațiile dintre ace știa dacă este
necesar. Figura 4.4 prezint ă cazul de utilizare pentru eliberarea unei facturi.
Figura 4.4 Diagrama cazurilor de utilizare în cazul cump ărării unor articole
și eliberării unei facturi
Facem precizarea ca dreptunghiu l în care sunt încadrate
„cumpărare”, „întocme ște bonul de cas ă”, întocme ște factura” și „contare
factură” este grani ța unui subsistem.
Diagramele de stare-tranzi ție
Diagramele de stare-tranzi ție completeaz ă descrierea obiectelor
prin:
• descrierea tuturor st ărilor posibile pe care le pot avea obiectele
unei clase;
• evidențierea evenimentelor care determin ă schimbarea st ărilor.
Diagramele de stare se întocm esc pentru clasele care au un num ăr
definit de st ări.
Figura 4.7 Diagrama simplificat ă a stărilor unei facturi
În figura 4.7, reprezint ă punctul ini țial, iar punctul final al
diagramei. Figura 4.8 prezint ă o diagram ă îmbogățită a stărilor unei facturi.
clien t cumpărare
vânzător
intocmește bonul
de casă
întocmește
factura ghișeu
facturare
serviciul
contabilitate contare factur ă
datele sunt
corecte s-a achitat
contravaloarea facturiiCiornă Emisă Închisă
46
Figura 4.8 Diagrama st ărilor unei facturi
Diagramele de stare pot con ține informa ții despre timpul consumat,
erori, condi ții pentru ca o stare s ă devină adevărată (cum e „datele sunt
corecte” din figura 4.7), e xpirarea timpilor de a șteptare etc. Aceste diagrame
sunt utile pentru a se iden tifica modul în care un obiect î ți poate modifica
starea sub influen ța unor stimuli. Diagramele de stare pot fi înso țite de
tabele în care se pot folosi formule de clacul (de exemplu, pentru a se indica
matematic ce înseamn ă o factură neachitat ă).
Figura 4.9 Diagrama st ărilor unei case de marcat
St ările „operare + în cas ă” și „operare – în cas ă” se pot detalia pentru
a se scoate în eviden ță operațiile contabile, documentele emise (de exemplu,
chitanța la încasare).
Mai multe diagrame de st ări se pot conecta – ma rcajul grafic este o
săgeată întreruptă (vezi figura 4.10).
Neincasat ă
Încasată Anulată Încasată
parțial Achitare Achitare
parțială Refuzată la
plată
Închisă Închidere Emitere
A
Arhivată Arhivare Operată Operare
Deschisă
operare + în
casă
Închisă inițializare
încasare
operare – în
casă ridicare numer
închidere
47
Figura 4.10 Comunicare între subsistemele reprezenta te de diagramele din figurile 4.8 și
4.9 în cazul pl ății unei facturi prin numerar
În figura 4.10 s ăgeata întrerupt ă este folosit ă pentru a indica mesajul
transmis din subsistemul diagramei st ărilor facturii în subsistemul casei de
marcat. Liniile ondulate reprezint ă granița dintre partea vizibil ă și partea
ascunsă a fiecărui subsistem.
Diagramele de activitate
Diagramele de activitate modeleaz ă aspectele dinamice ale
sistemului informatic și descriu activit ățile care se realizeaz ă prin opera ții
pentru care se pot prevedea condi ții și decizii reflectând astfel și rezultatele
aplicării acestora (vezi figura 4.11).
O diagram ă de activitate con ține ([MIH03], pagina 5-118):
• starea inițială – reprezentat ă grafic prin ;
• starea final ă – reprezentat ă grafic prin ;
• stări;
• tranziții;
• ramuri – în urma evalu ării unei expresii logice, fluxul de control
al activității trece de la o activitate la alta în func ție de valoarea
de adevăr a expresiei, punctul în care se evalueaz ă o expresie
logic
ă se reprezint ă grafic printr-un romb;
• bifurcații și îmbinări – apar atunci când exist ă activități care
continuă în paralel sau care se îmbin ă într-un punct;
reprezentarea grafic ă este o bar ă groasă, verticală sau orizontal ă;
• culoarele – se folosesc când st ările de activitate se pot împ ărți în
grupuri; culoarele se reprezint ă prin linii verticale;
• fluxul de obiecte – se folose ște atunci când în flu xul de control al
activității sunt implicate obiecte pe ntru care se poate specifica
rolul, atributele și starea.
Neîncasat ă
Încasată Achitare
Închidere A
Operată Operare Emitere Deschisă
operare + în
casă
Închisă inițializare
încasare
închidere
48
Figura 4.11 Diagrama activit ăților în cazul unei comenzi
Diagramele de activitate pot fi folosite pentru a reprezenta
([LUN03], pagina 411) ac țiunile care se realizeaz ă atunci când se execut ă o
operație și activitatea intern ă a unui obiect.
În figura 4.11 Factura reprezint ă o clasă. Dacă se face o detaliere mai
amănunțită, clasa se poate completa cu propriet ățile ei, metodele, rolul jucat
în diagrama prezentat ă în figură.
Figura 4.12 prezint ă diagrama de activitate pentru modulul de
raportări manageriale. „Utilizator”, „Modul raportare” și „Gestiune
rapoarte” sunt trei culoare ale diagramei cu ajutorul c ărora se grupeaz ă
activitățile. Refuzul cererii de listare se face pentru utilizat orii care nu au
dreptul de listare ale unor raporte confiden țiale. După ce s-a listat un raport
activitate, se poate continua pe una dintre ramurile prev ăzute: fie se închide
modulul pentru raportare fie se afi șează lista rapoartelor disponibile pentru a
se emite o nou ă cerere de listare. Pentru exemplul din figura 4.12
Lansare comand ă
Primire
comandă A [comandă
respinsă]
[comandă
acceptată]Realizeaz ă
comanda
Emite
factura Achită
comanda Acceptă
plata
Factura A
Închide
comanda
49
Figura 4.12 Exemplu de diagram ă a activităților pentru
listarea rapoartelor
Diagramele activit ăților ajută la identificarea ac țiunilor care se pot
realiza într-o ordine bine determinat ă. De asemenea, ele scot în eviden ță
modul în care ac țiunile influen țează obiectele cu care interac ționează.
UTILIZATOR MODUL RAPORTARE GESTIUNE
RAPOARTE
afișare fereastr ă
conectare
introduce nume
utilizator și parolă
validare utilizator
[utilizator valid]
afișare lista
rapoartelo r
cere listare raport construire lista
rapoartelo r
[utilizatorul are drepturi de listare a
raportului selectat]
listare raport A
A [utilizatorul nuare
drepturi de listare a raportului
selectat]
50
BIBLIOGRAFIE
1. [DAV03] Davidescu, N. D. – Proiectarea sistemelor informatice prin
limbajul Unified Modeling Language , Editua All Beck, Bucure ști 2003
2. [LUN03] Lungu, I., Sab ău, G., Velicanu, M. ș.a. – „Sisteme
informatice. Analiz ă, proiectare și implementare”, Editura Economic ă,
București, 2003
3. [MIH03] Mihalca, Rodica, Fabian, C. – Realizarea produselor program
aplicative , Editura ASE, Bucure ști 2003
TESTE DE EVALUARE
1. Precizați cel puțin trei caracteristici ale UM L care îl face potrivit pentru
modelarea sistemelor informatice de contabilitate:
_____________________________________________________________
_______________________________________________________________________________________________________________________________________________________________________________________ 2. Vederile utilizate de UML sunt:
_____________________________________________________________
__________________________________________________________________________________________________________________________
3. Diagrama din figura de mai jos reprezint ă:
a. două clase independente;
b. un element de agregare;
c. o asociere condi ționată.
4. După natura conexiunii dintre dou ă elemente, rela țiile sunt:
_____________________________________________________________
_______________________________________________________________________________________________________________________________________________________________________________________ 5. Precizați diagramele folosie de UML: Clasa 1
Clasa 2 1
*
51
_____________________________________________________________
__________________________________________________________________________________________________________________________ 6. Întocmiți diagrama st ărilor unui aviz de expedi ție.
7. Întocmiți diagrama activit ăților în cazul unei facturi încasate printr-un
ordin de plat ă.
8. Întocmiți diagrama activit ăților pentru modulul de introducere a
documentelor justificative cu contare automat ă al unui sistem informatic de
contabilitate. 9. Fie clasa STUDENT cu propriet ățile Nume, Prenume, Anul de studiu,
Nota și clasa FACULTATE cu propriet ățile Denumire, Specializare, An
acreditare. S ă se întocmeasc ă diagrama claselor și să se stabileasc ă rolul și
cardinalitatea fiec ărei clase.
10. Pentru clasele de la exerci țiul 9, să se întocmeasc ă diagrama obiectelor.
52
TEMA 5. ANALIZA SISTEM ULUI INFORMATIC DE
CONTABILITATE EXISTENT
CONȚINUT
5.1. Obiectivele analizei
5.2. Elaborarea modelului fizic al sistemului existent
5.3. Elaborarea modelului logic al sistemului existent
5.4. Alegerea unui nou sistem informatic de contabilitate
REZUMAT
Analiza sistemului informatic de contabilitate existent este o etap ă
important ă prin care sistemul devine accesib il în activitatea de reproiectare a
sistemului sau de formulare a unor cerin țe suplimentare.
OBIECTIVE
Tema propus ă are ca scop înv ățarea modului în care se poate studia un
sistem informatic de contabilitate existent.
5.1 OBIECTIVELE ANALIZEI
Analiza sistemului informatic de contabilitate existent este o etap ă
important ă prin care sistemul devine accesib il în activitatea de reproiectare a
sistemului sau de formulare a unor cerin țe suplimentare. Analiza sistemului
informațional existent este cea mai sensibil ă parte a proiect ării unui sistem
informatic și constă în descrierea sistemul ui deja existent dar și a celui care
urmează a fi introdus. Din cauz ă că „în economia româneasc ă nu există un
standard referitor la sistemele informa ționale” ([BOB03, pagina 31), analiza
sistemului informatic este o problem ă spinoasă care isc ă divergen țe
referitoare chiar și la timpul care trebuie aloc at acestei etape: un timp prea
scurt poate însemna insucces în cunoa șterea sistemului, neîn țelegerii
modului sau în țelegerea precar ă
a modului în care func ționează acesta și
nedetectarea locurilor și posibilelor situa ții în care pot apare erori. Un timp
prea lung dedicat acestei etape înseamn ă scurtarea timpilor celorlalte etape
ceea ce poate duce la rezultate incorecte și/sau solu ții incomplete. În ambele
situații rezultatul poate fi un produs care nu se ridic ă la nivelul de a șteptare
al utilizatorului final. Cunoa șterea mediului în care func ționează sistemul informatic de
contabilitate este prim ul pas care trebuie f ăcut etapa de analiz ă. Granița
dintre sistem și mediu se poate reprezenta prin modelul mediului . Modul în
care sistemul interac ționează cu mediul se poate reprezenta în diagrama
modelului mediului.
53
Mediul sistemului informatic de contabilitate
Studierea mediului în care va func ționa sau func ționează sistemul
informatic de contabilitate începe cu culegerea de informa ții despre unitatea
economic ă elaborându-se dou ă modele:
• modelul fizic : prezintă structura tehnic ă și operațională, modul de
funcționare într-o anumit ă implementare, cu anumite restric ții de
ordin tehnic;
• modelul logic : prezintă modul de func ționare independent de
implementare (acest model împreun ă cu cerin țele utilizatorului
este folosit pentru proiectarea sistemului informatic nou).
Studiul mediului intern al unit ății economice în care func ționează
sistemul informatic de contabilitate cuprinde urm ătoarele activit ăți
([LUN03]):
1. specificare cuno ștințelor generale despre organiza ție – denumirea,
sediul central, filiale, forma juridic ă, domeniul de activ itate, sfera de
activitate, oferta de produse, num ărul de angaja ți, punctele de lucru,
structura organizatoric ă (este de folos și alcătuirea unei
organigrame), informa ții despre clien ți, furnizori etc.
2. cunoașterea activit ăților organiza ției, a normativelor și a legisla ției
de reglementare a activit ății: regulamentul de func ționare,
regulamentul de ordine interioar ă, statutul de func ționare, informa ții
utile despre func ții, relații dintre compartimente, activit ățile de
interes și detalierea modului de orga nizare a acestora, resursele
folosite etc. Prezentarea activit ăților se poate face sub form ă de text
liber, cu organigrame, tabele, imag ini sau orice alte elemente prin
care se poate descrie mai bine;
3. prezentarea caracteristicilor de management : metodele și tehnicile
folosite în luare deciziilor, planif icarea, organizarea, controlul etc.;
4. identificarea mijloacelor tehnice folosite pentru pr elucrarea datelor,
modul de utilizare, personalul imp licat (nivelul de studii necesar,
instruirea continu ă), performan țele și punctele slabe.
În cazul în care analiza sistemul ui se face pentru identificarea
cauzelor unor deficien țe în funcționare sau pentru proi ectarea/reproiectarea
unei componente sau a unei p ărți a sistemului, echipa de analiz ă trebuie să ia
în considerare cerin țele utilizatorului și opiniile managerilor care se pot
prezenta sub form ă tabelară specificându-se informa ții referitoare la
persoana care a emis cerin ța și descrierea ei (ac
țiunea ata șată, limitele
calitative). C e r i n țele pot fi clasificate în dou ă grupe mari
1:
– cerințe funcționale – se refer ă la modul în care sistemul nou
trebuie s ă realizeze activit ățile: modul în care sistemul
interacționează cu alte sisteme, organizarea interfe țelor
grafice și obținerea rapoartelor, stocarea datelor, aceesarea și
prelucrarea lor etc.;
1 Lungu, I., Sab ău, G., Velicanu, M. – „ Sisteme informatice. Analiz ă, proiectare și
implementare ”, Editura Economic ă, București 2003, paginile 81-82
54
– cerințe nefuncționale – se refer ă la modul în care resursele
trebuie să aducă performan ță la nivel func țional: timpul de
acces a datelor, securitatea datelor, arhivarea și refacerea
datelor, audit și control, automatizarea unor opera ții etc.
Structurarea sistemului informa țional existent
Unit ățile economice sunt sisteme complexe în care se manifest ă o
multitudine de interac țiuni între elementele constituente și cu mediul
exterior. Sistemul se poate descompune dup ă mai multe criterii:
1. funcțiunile sistemului – sistemul se descompune din punct de vedere
funcțional în subsisteme: financiar- contabil, cercetare-dezvoltare,
resurse umane etc.;
2. activitățile sistemului – activitățile sunt grupate în func ție de specific
(gestiune, salarizare, eviden ța comenzilor, eviden ța producției etc.);
3. organizarea sistemului – fiecare compartiment sau departament este
considerat un element de descompunere: personal, administra ție,
producție, marketing, cont abilitate etc.;
4. natura componentelor – sistemul se descompune în func ție de tipul
componentelor: materii prime, produse finite, resurse umane etc. și
se identific ă activitățile asociate cu acestea (produc ție, desfacere
etc.);
5. conducere – se identific ă a) subsistemele de conducere strategic ă,
operativă și tactică sau b) subsistemul decizional, subsistemul
condus și subsistemul informa țional.
Pentru orice tip de descompunere, descrierea unui sistem se poate
face pe trei nivele de deta liere ale caracteristicilor:
– generic : când se folosesc caracteristici generice;
– parțial: când se detaliaz ă cel puțin o parte constituent ă a
sistemului prin specificarea complet ă a parametrilor care, prin
cuantificări, definesc caracteristicile;
– particular : când se detaliaz ă toate p ărțile constituente ale
sistemului prin specificarea tuturor parametrilor aferen ți
caracteristicilor.
Descrierea unui sistem va avea ca finalitatea realizarea unor
documente care cuprind specifica ții de proiectare și de implementare.
5.2 ELABORAREA MODELULUI FIZIC AL SISTEMULUI
EXISTENT
În timpul elabor ării modelului fizic al sistemului informatic de
contabilitate existent se vor construi:
– modelul mediului – prin real izarea diagramei de context;
– modelul comportamental – prin realizarea modelului fizic al
prelucrărilor și a modelului logic al datelor.
55
Modelul fizic al prelucr ărilor conține descrierea datelor de intrare și
a datelor de ie șire, diagramele de flux a documentelor, descrierea entit ăților
externe sistemului și/sau modelului și descrierea proceselor elementare.
Diagramele de flux a documentelor
Diagramele de flux a documentelor, pe scurt DFD, sunt folosite
pentru a reprezenta prelucr ările dintr-un sistem, parcursul documentelor de
la intrarea în sistem pân ă la obținerea rezultatelor, de la emiterea lor pân ă la
părăsirea sistemului. Aceste diagrame scot în eviden ță modul în care
documentele sunt distribuite, utilizate, ultimul loc în care sunt folosite, de
fapt cam tot ce se întâmpl ă cu documentele într-un sistem. Diagramele se
pot folosi pentru urm ărirea și stabilirea controlului intern asupra
documentelor, a responsabilit ăților, slăbiciunilor sau ineficien ța comunic ării
interne. Pentru a se elabora diagramele fluxului de documente trebuie executați următorii pași preliminari:
1. identificarea p ărților sistemului implicate în fluxul documentelor;
2. prin chestionarea oamen ilor din interiorul unit ății economice, luarea
notițelor manuale detaliate despre fiecare document folosind
simboluri distincte pentru fiecare document, tabele, liste, grafuri;
3. transpunerea în format electronic și folosind simboluri standardizate,
dacă există;
4. verificarea diagramelor luând în considerarea urm ătoarele aspecte:
a. o diagram ă trebuie s ă aibă un început și un sfâr șit în
desfășurarea evenimentelor;
b. utilizarea comentariilor acolo unde aspectele surprinse nu sunt
clare;
c. definirea clar ă a intrărilor, prelucr ărilor și ieșirilor;
d. documentele s ă nu fie conectate direct;
e. când se utilizeaz ă mai multe copii ale unui document, se
înscrie num ărul de copii;
5. verificarea diagramelor din punct de vedere func țional împreun ă cu
oamenii chestiona ți anterior și refacerea acelor diagrame care nu
corespund;
6. stabilirea datelor de identificare a diagramelor prin: numele
documentelor, data și creatorul.
Diagramele fluxurilor de documen te se pot construi în manier ă
simplificat ă (vezi figura 5.1) dar și în manier ă detaliată (vezi figura 5.2).
56
Figura 5.1 Diagramă de flux a documentelor
Diagramele simplificate ale fl uxurilor de documente se elaboreaz ă
rapid din arce direc ționale (care pot fi înso țite de explica ții scurte care
descriu ac țiuni și numărul de exemplare ale documentului) și din elipse (în
care se încriu numele entit ăților implicate). Acest tip de diagrame sunt utile
pentru a în țelege interac țiunile dintre p ărțile componente ale sistemului.
Figura 5.1 prezint ă diagrama de flux simplificat ă a documentelor în cazul
unei unități economice particulare. Aceast ă diagramă poate fi mai complex ă
în cazul unor unit ăți economice mai complexe, de exemplu în cazul unei
întreprinderi produc ătoare pot exista departamen te distincte pentru livr ări,
depozitare și livrare.
Diagramele detaliate de flux a documentelor con țin informa ții
referitoare la locurile și momentele în care apar evenimente sau se
desfășoară acțiuni ca:
• documentul apare (este emis sau recep ționat) sau se completeaz ă
pentru prima oar ă un document tipizat;
• se modific ă, prin ad ăugare sau ștergere, con ținutul unui
document;
• se manipuleaz ă și/sau se deplaseaz ă un document – de exemplu
este transmis între departamente f ără nicio modificare și fără nicio
reflectare în contabilitate,
• se execut ă verificarea cantitativ ă și/sau calitativ ă a unui
document;
• staționarea temporar ă a documentului;
• arhivarea sau distrugerea documentului;
• crearea sau generarea unui docum ent din mai multe exemplare.
Simbolurile folosite pentru elaborarea diagramelor de flux de documente sun prezentate în tabelul 5.1. Se observ ă că unele simboluri sunt
folosite pentru a specifica dou ă sau mai multe ac țiuni care se pot desf ășura
simultan, de exemplu simbolul
care se poate folosi a specifica locul în Contabilitate
Punct de vânzare Client
Oferta de produse Cumpărare Factură
(exemplarul 1) Document de plat ă
Lista prețurilor
Factură
(exemplarul 2)
Situația lunară a
vânzărilor
Situația zilnică a stocurilor
57
care se efectueaz ă deodată manipularea, modificarea și verificarea unui
document.
Tabel 5.1
Simboluri folosite în elaborarea diagramelor de fl ux a documentelor1
Simbol Utilizare
– 1 – – 2 –
Apariția unui document sau completarea pentru prima oar ă a
unui document tipizat
Modificarea con ținutului unui document
Manipularea unui document
Verificarea unui document
Deplasarea documentului
Staționare temporar ă
Arhivare sau distrugere
Crearea unui document având mai multe copii. Copiile se
numeroteaz ă sau eticheteaz ă pentru a se distinge mai u șor în
diagramă și în documenta ția aferentă
Manipulare și verificare a documentului
Manipulare, modificare și verificare a documentului
Linii de influen ță – generare de documente noi, modificarea
conținutului documentelor, manipularea documentelor
Bloc de simplificare care poate con ține oricare din simbolurile
de mai sus
1 Bob, C. A. – Sisteme informatice în comer ț, Editura ASE, Bucure ști 2002
58
Figura 5.2 prezint ă diagrama de flux a documentului factură în cazul
folosirii unui facturier.
Figura 5.2 Diagrama de flux a unei facturi
Factura se întocme ște în trei exemplare care se distribuie astfel:
primul exemplar la cump ărător, al doilea este transmis departamentului de
contabilitate iar al treilea r ămâne la cotor.
Diagramele de flux a datelor
Diagramele de flux a docu mentelor se pot folosi și pentru elaborarea
diagramelor de flux a datelor, pe scur t DFDs. Aceste diagrame se întocmesc
respectându-se urm ătoarele reguli ([LUN03]):
1. pentru a fi identificate mai u șor, procesele și stocurile de date sunt
numerotate secven țial;
2. entitățile externe se plaseaz ă în jurul stocurilor de date;
3. stocurile de date și entitățile externe se pot reprezenta multiplicat
atunci când întret ăierea liniilor din graf poate transforma diagrama în
una puțin lizibilă.
O diagram ă DFDs este constituit ă, de regul ă, din patru elemente de
bază (vezi tabelul 5.2):
1. sursele și destinațiile datelor – reprezint ă organiza ții sau persoane
care trimit sau recep ționează datele utilizate sau recep ționate de
către sistem;
2. fluxurile de date – reprezentate prin s ăgeți cu nume mono-
direcționate sau bidirec ționate;
3.
procesele de transformare;
4. stocurile de date.
1
3
2Cumpărător
Arhivare „la cotor”
Contabilitate
înregistrarea
documentului în jurnal Arhivare electronic ă
59
Tabel 5.2
Simboluri folosite în elaborarea diagramelor de flux a datelor1
Simbol Utilizare
Procese
Flux de date
Entitate
Entitate duplicat
Stoc de date
Stoc de date duplicat
Tabelul 5.2 prezint ă simbolurile folosite pentru întocmirea
diagramelor de flux a datelor. Procesele , localizate într-un compartiment
sau la o persoan ă, sunt etichetate cu texte care sugereaz ă modul în care se
transform ă datele.
Un flux apare între dou ă procese și este etichetat printr-un substantiv
(simplu sau compus) în corela ție cu datele sau pachetul de date transmis, de
exemplu „stoc final”, „situa ția vânzărilor”, „încas ări” etc. Entitățile sunt
emițătorii și/sau receptorii de date și pot fi interni sau externi sistemului.
Dup modul de prelucrare a datelor, fluxurile de date sunt de dou ă tipuri:
– de consultare – în acest caz un proces folose ște unu sau mai multe
stocuri de date (vezi figura 5.3);
– de actualizare – în acest caz un proces modific ă datele dintr-un
stoc de date (prin opera ții de adăugare, modificare, ștergere);
acest tip de fluxuri sunt reprezentate în unele lucr ări de
specialitate prin s ăgeți birecționale (vezi figura 5.4).
Stocurile de date sunt depozite temporare sau permanente de date și
pot de trei tipuri, etichetate în func ție de tipul stocului și însoțite de un
număr de identificare:
– M: manuale – registru, facturier, dosar, arhiv ă etc.;
– D: electronice – pe suport de memorie extern ă – hard-disk,
dischetă, bandă magnetic ă, CD etc.;
– T: temporar, de exemplu un fi șier care con ține o factur ă proforma
și se stocheaz ă temporar pân ă la întocmirea facturii finale.
În figura 5.3 se observ ă că sunt consultate dou ă stocuri de date
pentru a analiza o comand ă: stocurile de produse pentru a se verifica dac ă
1 Bob, C. A. – Sisteme informatice în comer ț, Editura ASE, Bucure ști 2002 et. stoc et. stoc entitate proces nr. localizare
flux
entitate
60
există cantitatea cerut ă și soldurile pentru a se verifica dac ă soldul acoper ă
plata pentru comand ă. Figura 5.4 prezint ă cazul actualiz ării conturilor
contabile pe baza unui document.
Figura 5.3 Flux de consultare
Sursa: [LUN03] pagina 195
Figura 5.4 Flux de actualizare
Elaborarea diagramelor DFDs se poate face etapizat: în prima faz ă se
vor elabora diagramele contextuale generale care se vor rafina pân ă la
nivelul de detaliere cerut. Valid area diagramelor se face de c ătre analiști și
de către utilizatori.
Investigarea și reprezentarea datelor
Aceast ă activitate este o activitate de importan ță mare pentru anali ști
având un impact mare în etapa de pr ogramare. Scopul principal al acestei
activități este elaborarea:
– modelului logic al datelor, pe scurt MLD care pune în eviden ța
datele și relațiilor dintre ele în interiorul sistemului;
– catalogul datelor pentru sistemul informatic de contabilitate
existent.
Construirea modelului ML D presupune executarea urm ătorilor
pași([LUN03], paginile 205-213):
1. identificarea entit ăților – se identific ă grupele de date pe care le
folosește sistemul, fiecare grup constituindu-se ca o entitate, de
exemplu: comand ă, produs, beneficiar etc.;
2. identificarea rela țiilor dintre entit ăți – se construie ște matricea
entităților în care se vor marca prin caracterul * influen țele dintre
entități (vezi tabelul 5.3), pe baza acestor influen țe se construiesc
relațiile (asocierile sau leg ăturile) dintre ele. Conturi contabile M5Încasare 5.1
Analiză document Stocuri produse M1 Sold plată M2
Livrare 1.1
Analiză comandă
61
Tabel 5.3
Matrice entitate – exemplu
Beneficiar
Comandă
Linie comand ă
Livrare
Linie livrare
Factură
Linie factur ă
Produs
Intrare
Linie intrare
Furnizor
Beneficiar *
Comandă * *
Linie
comandă
Livrare * *
Linie livrare
Factură *
Linie factur ă
Produs * * * *
I n t r a r e * *
Linie intrare
F u r n i z o r
Sursă: [LUN03], pagina 206
Tabelul 5.3 a fost construit folosindu-se urm ătoarele informa ții
culese în etapele anterioare:
– un beneficiar poate lansa una sau mai multe comenzi, în acest caz
asocierea este 1: N;
– pentru o comand ă se execut ă o singură livrare;
– o comand ă poate con ține una sau mai multe lin ii, câte o linie pentru
fiecare produs comandat;
– o livrare se încheie printr-o factur ă; o livrare poate con ține una sau
mai multe linii, una pentru fiecare produs livrat;
– o factură poate con ține una sau mai multe linii, una pentru fiecare
produs facturat;
– un produs poate apare în documentele de intrare cât și în
documentele de ie șire, mai corect spus în liniile acestora; în acest
caz, cu oricare dintre documentele de intrare și/sau ieșire produsul
se află în relație M:M (de exemplu o factur ă poate con ține mai
multe produse iar un produs poate apare în mai multe facturi);
– o intrare provine de la un furnizor și poate con ține una sau mai
multe linii, câte una pentru fiecare produs intrat.
3. elaborarea modelului entitate-asociere – acest model
integrează toate entit ățile și relațiile dintre ele determinate în pa șii
anteriori, rela țiile sunt etichetate prin tr-un verb care exprim ă
semnifica ția legăturii și prin cardinalitatea ei (vezi figura 5.5 unde
simbolul reprezint ă o cardinalitate mai mare decât unu);
62
Figura 5.5 Exemplu de model entitate-asociere
Sursă: [LUN03] pagina 209
4. elaborarea diagramei de coresponden ță între stocurile fizice și
entitățile logice – fiecare stoc de date este pus în coresponden ță cu
entitățile cu care au fluxuri de actualizare:
– directă – cum ar fi stocul de date pentru produse și
entitatea produse, vezi figura 5.6);
– indirectă și sau multipl ă – vezi figura 5.7;
Stocuri fizice Entit ăți
M1 Stocuri produse
M2 Sold de plat ă
Figura 5.6 Exemple de coresponden ță directă dintre un stoc fizic și o entitate
Sursă: [LUN03], pagina 209
În figura 5.6, stocurile fi zice de date, manuale, pot fi registre tabelate
care conțin:
– pentru „Stocuri produse”: denumirea produsului și cantitatea
existentă în stoc la un moment dat;
– pentru „Sold de plat ă”: denumirea beneficiarului și suma care se
constituie ca sold de plat ă.
Stocuri
fizice Entități
M1 Fișă
magazie
Figura 5.7 Exemplu de coresponden ță dintre un stoc fizic și mai multe entit ăți
Sursă: [LUN03], pagina 209
Beneficiar Produs Beneficia r
Comandă Linie
comandă emite
este emisă
conține
face parte din
Produs este pentru
este referit în
Linie
intrare conține
face parte dinIntrare
Produseste pentru
este referit de
63
În figura 5.7, stocul fizic de date este un stoc manual pentru care se
folosesc formulare tipizate. În elaborarea modelului logic, a cest stoc de date
poate fi dublat de un stoc electronic de date cu aceea și semnifica ție și
utilitate.
5. descrierea detaliat ă a entit ăților, atributelor acestora și a
relațiilor dintre acestea – aceast ă descriere se face prin
intermediul unor documente standardizate care con țin următoarele
informații:
– pentru descrierea entit ăților: numele, descrierea, lista
atributelor, lista rela țiilor și observații;
– pentru descrierea unui atribu t: numele, entitatea care îl
conține, tipul entit ății, descrierea, domeniul de valori pentru
care este considerat a fi valid (de exemplu „M”, „F” este domeniul de valori pent ru sex), valoarea implicit ă (de
exemplu 0,19 pentru cota TVA), observa ții suplimentare, și
informații necesare pentru etapa de transpunere în limbaj de
programare cum ar fi: formatul, și lista utilizatorilor cu
drepturile de acces și drepturile de acces, domeniul de grup
(care grupeaz ă atribute cu semnifica ții și mod de
funcționare asem ănător; domeniile de grup se pot descrie
detaliat, dac ă este necesar);
– pentru descrierea asocierilor: explica ții descriptive; numele
entităț
ii, tipul de leg ătură, cardinalitatea și alte observa ții.
6. validarea modelului logic al datelor – se face împreun ă cu
beneficiarul verificând toate aspect ele luate în considerare cum ar
fi: parcursul datelor, rela țiile dintre ele, valorile și domeniile de
validare, cardinalitatea.
Crearea catalogului datelor este o activitate complex ă care presupune
crearea unui dic ționar al datelor care con ține descrierea atributelor și
descrierea domeniilor de grup. Catalogul va deveni un depozit, cu o structură dinamică, de mari dimensiuni folosit în etapa de programare în mai
multe scopuri: pentru automatizarea fluxurile existente în cadrul aplica ției,
pentru construirea motoarele de integrare a aplica țiilor și pentru
determinarea fluxurilor de date.
5.3 ELABORAREA MODELULUI LOGIC AL SISTEMULUI
EXISTENT
Modelul logic a sistemului informatic de contabilitate existent scoate
în evidență următoarele aspecte:
– ce face sistemul;
– funcțiile de baz ă ale sistemului;
– problemele legate de redundan ța datelor
– problemele legate de duplicarea proceselor de prelucrare;
– procesele manuale care nu pot fi automatizate complet.
64
Se ob țin diagramele de flux logic pe baza diagramelor DFDs care se
descompun în nivele succesive, eliminându-se:
– toate procesele de natur ă fizică (cum ar fi cele de scriere pe
hard-disk care nu intereseaz ă în mod direct utilizatorul final
acesta presupunând c ă tehnologia folosit ă este perfect ă adică
poate ignora aspectele care țin de scrierea efectiv ă pe hard-disk);
– stocurile de date care se folosesc ca urmare a constrângerilor din
sistem (cele temporare, de sincronizare etc.).
Construirea modelului ML D presupune executarea urm ătorilor
pași([LUN03], paginile 214-222):
1. identificarea stocurilor logice de date – se realizeaz ă prin
gruparea datelor înrudite, care se utilizeaz ă împreună frecvent sau
care se utilizeaz ă des în acela și timp; gruparea trebuie s ă respecte
următoarea regul ă: un stoc logic con ține una sau mai multe
entități, dar o entitate poate s ă aparțină unui singur stoc logic de
date; în mod similar identific ării stocurilor fi zice de date se
stabilesc diagrama de coresponden ță între stocurile logice de date
și entitățile logice și diagrama de coresponden ță între stocurile
logice de date și cele fizice;
2. înlăturarea dependen țelor fizice ș
i temporale – se elimin ă din
diagramele modelului fizic informa țiile următoare: localizarea
proceselor, periodicitatea și momentele de timp ale execu ției
proceselor, caracteriz ările fizice ale documentelor (de exemplu,
faptul că o factură se va tipări pe o coal ă de dimensiune A4);
3. derivarea proceselor logice – acest pas trebuie s ă elimine
redundanțele care exist ă la nivel de procese și să înlocuiasc ă
stocurile fizice de date cu stocurile logice de date;
4. derivarea fluxurilor logice – acest pas trebuie s ă stabileasc ă
numai fluxurile de informa ții utilizate efectiv de fiecare proces;
5. gruparea proceselor elementare și construirea unei ierarhii
ale entităților;
6. verificarea diagramelor ;
7. elaborarea documenta ției – documenta ția se compune din toate
diagramele fluxurilor de da te ale modelului logic.
Odat ă încheiată această etapă se poate face evaluarea sistemului
informatic de contabilitate existent prin evaluarea urm ătoarelor:
1. performan țele și limitările sistemului:
a.
îndeplinirea obiectivelor, func țiilor, sarcinilor de baz ă și de
exercitare a conducerii;
b. oportunitatea, completitudinea și suficien ța informa țiilor
destinate conducerii;
c. timpul de r ăspuns al sistemului – intervalul de timp din
momentul transmiterii unei cereri din partea conducerii pân ă
la momentul primirii r ăspunsului trebuie s ă fie scurt;
d. calitatea și precizia informa țiilor obținute;
e. calitatea și siguranța fluxurilor informa ționale;
f. posibilitățile de control;
g. timpii optimi privind reac ția la apari ția unor erori și corecția
acestora;
65
h. gradul de integrare a sistemului informa țional în corela ție
directă cu gradul de automatizare a prelucr ărilor;
2. gradul de preg ătire a unit ății economice pentru implementarea
sistemului informatic de contabilitate nou:
a. existența cunoștințelor și disciplinei tehnologice;
b. posibilitățile de instruire și autoinstruire în ceea ce prive ște
utilizarea computerelor și a produselor informatice etc.
Nivelul de preg ătire al unei unit ăți economice pentru implementarea
unui sistem informatic de contabilitat e nou este greu de stabilit pentru c ă
intervin o multitudine de variabile: de la suma limitat ă în ceea ce prive ște
achiziționarea pân ă la intoleran ța personalului în fa ța schimbării modului de
lucru cu care s-au obi șnuit.
5.4 ALEGEREA UNUI NOU SI STEM INFORMATIC DE
CONTABILITATE
Decizia de schimbare a unui sistem informa țional existent poate
interveni ca urmare a etapei de analiz ă. În cazul existen ței unui sistem de
contabilitate care prezint ă deficiențe majore (dep ășire morală, insecuritate în
funcționare) care se pot repara cu costuri mari în timp și bani, conducerea
unității economice poate prefera achizi ționarea unui sistem de contabilitate
nou. Alegerea unui sistem de contabilit ate nou se înscrie în categoria
problemelor mutiatribut sau multicriteriale pentru c ă este o decizie care
trebuie să țină cont de o mul țime de atribute/criterii dintre care unele fiind
contradictorii:
– criterii obiective – cum ar fi: pre țul, costul abonamentului de
întreținere a modific ărilor în concordan ță cu legisla ția;
– criterii subiective, intangibile – cum ar fi: ergonomia, interfa ța
prietenoas ă;
– incertitudini – cum ar fi: securitatea garantat ă a datelor.
Problemele multiatribut se modeleaz ă sub form ă matriceal ă (vezi
tabelul 5.4) unde:
– Ci, i = 1, 2, …, n sunt criteriile utilizate în luarea deciziei, se
recomand ă ca n să nu fie mai mare de 10;
– Aj, j = .1, 2, …, m sunt acțiunile posibile, în cazul nostru produsele
software de contab ilitate analizate;
– aij, , i = 1, 2, …, n, j = .1, 2, …, m sunt consecin țele posibile.
Tabel 5.4
Matricea deciziilor pentru problemele multi atribut
C i
Aj C1 C2 … C n
A1 a11 a12 … a 1n
A2 a21 a22 … a 2n
… … … … …
Am am1 am2 … a mn
66
Aceast ă matrice se traduce în via ța reală astfel: conducerea implicat ă
în luarea unei decizii de achizi ționare, va constitui o echip ă care format ă din
m membri care va stabili criteriile care trebuie luate în considerare; de
exemplu: operatorul va stabili ergon omia, inginerul de sistem siguran ța în
funcționare, contabilul șef automatizarea prelucr ării contabile a
documentelor dar și prețul mic și costurile de între ținere cât mai sc ăzute
ș.a.m.d.
Criteriile neobiective vor primi valori pe o scal ă subunitar ă, de
exemplu pentru criteriul interfață se stabile ște următoarea scal ă:
¾ 0,75 – interfa ța este foarte prietenoas ă (nu este înc ărcată, culorile
sunt potrivite, but oanele de declan șare a unei opera ții sunt la
îndemână etc.);
¾ 0,5 – interfa ța este puțin prietenoas ă;
¾ 0,25 – interfa ța nu este prietenoas ă;
¾ 0 – interfa ța este greoaie.
Stabilirea criteriilor este urmat ă de ierarhizarea lor (stabilirea
importanței) folosindu-se o scal ă de la 1 la p, unde p este num ărul
persoanelor implicate în luarea deciziei, vezi tabelul 5.5 unde linia K este linia sumei valorilor de ierarhizare și conține indicii de dep ărtare iar n
ij sunt
notele de ierarhizare aco rdate de fiecare persoan ă fiecărui criteriu.
Ierarhizarea criter iilor devine astfel un proces în are este implicat ă toată
echipa. În func ție de valoarea urm ărită, criteriile sunt:
– de minim – atunci când se dore ște ca valoarea luat ă în discuție să fie
cât mai mic ă, de exemplu pre țul produsului software;
– de maxim – când se dore ște ca valoarea s ă fie cât mai mare, de
exemplu, interfa ța să fie cât mai prietenoas ă.
Pentru fiecare criteriu, se calculeaz ă indicele de dep ărtare
() maxj
j
jN
KN= unde ()maxjN reprezint ă nota maxim ă care se poate
acorda înmul țită cu numărul de persoane care acord ă note criteriilor.
Tabel 5.5
Ierarhizarea deciziilor
C i
Pj C1 C2 … C n
P1 n11 n12 … n 1n
P2 n21 n22 … n 2n
… … … … …
Pp np1 np2 … n pn
K K1=1
1p
i
in
=∑ K 2=2
1p
i
in
=∑ … Km=
1p
in
in
=∑
Urm ătorul pas este calcularea matricei de dep ărtare – aceste valori
sunt subunitare 1q− unde q se calculeaz ă în funcție de tipul criteriului (de
minim sau de maxim) astfel:
67
– pentru criteriile de minim – raportu l se face între valoarea criteriului
și cea mai mic ă valoare dintre toate valorile criteriului;
– de maxim – raportul se f ace între valoar ea criteriului și valoarea cea
mai mare dintre toate valorile criteriului.
În final se alc ătuiește matricea de apartenen ță folosindu-se linia K
din tabelul de ierarhizare a deciziilor, matricea de dep ărtare prin formula
ij jXK
ijZe−= unde ijZ sunt gradele de apartenen ță, ijX sunt valori din
matricea de dep ărtare iar jK sunt coeficien ții de depărtare. În matricea de
apartenen ță pe într-o coloan ă distinctă se însumeaz ă valorile pe toate liniile
și se alcătuiește clasamentul unde alternativa cu suma cea mai mare ocup ă
primul loc.
Exemplu: alegerea unui produs so ftware de contabilitate utilizând
criteriile multiatribut
Problemă
La firma LocalAuto SRL se dorește implementarea unui sistem
informatic de contabilitate în condi țiile în care contabilitatea s-a efectuat
manual.
Rezolvare
Admistratorul firmei a format echipa decizional ă formată din nouă
persoane: el însu și, contabilul- șef, doi operatori pe calculator și specialiști ai
firmei de consultan ță.
În urma analizei sistemului informa țional de contabilitate existent, s-
au elaborat urm ătoarelor cerin țe minimale pentru produsul software:
C1.
prețul să fie mai mic de 3500 de lei;
C2. abonament pentru actualizarea modific ărilor în concordan ță
cu schimb ările legisla ției să permită actualizarea prin
intermediul Internetului;
C3. să existe posibilitatea pl ății în rate a aplica ției și a
abonamentului pentru actualiz ările periodice;
C4. să se facă instruirea la instalare și o instruire permanent ă prin
intermediul telefonului și/sau Internetului;
C5. interfața grafică să fie prietenoas ă;
C6. să existe suport tehnic in zilele lucr ătoare până la ore târzii;
C7. utilizarea aplica ției să se poat ă face pe minim trei
calculatoare;
C8. utilizarea aplica ției să se facă sub inciden ța sistemului de
operare Windows XP;
C9. aplicația să fie modular ă și să conțină un modul special
pentru contabilitatea financiar ă.
Pentru criteriul
C3 – plata în rate – s-a stabilit urm ătoarea scalare:
• 0 – nu exist ă posibilitatea pl ății în rate;
• 0,25 – plata în rate se face anual;
68
• 0,5 – plata în rate se face trimestrial;
• 0,75 – plata în rate se face lunar;
• 0,9 plata în rate se poate face printr-o perioad ă specificat ă de client.
Pentru criteriul C4 – instruire – s-a stabilit urm ătoarea scalare:
• 0 – nu exist ă posibilitatea instruirii la instalare;
• 0,25 – instruirea se f ace doar la instalare sau ulterior prin plata unui
abonament de instruire;
• 0,5 – nu se face instruire la instalare dar exist ă posibilitatea instruirii
permanente;
• 0,75 – instruirea se face la instalare, prin ofert ă de documenta ție și
permanent (prin intermediul telefonului și/sau Internetului).
Pentru criteriul
C5 – interfa ța grafică – s-a stabilit urm ătoarea
scalare:
• 0 – neprietenoas ă;
• 0,25 – puțin prietenoas ă;
• 0,5 – mediu prietenoas ă;
• 0,75 – foarte prietenoas ă.
Ofertele luate în considerare sunt urm ătoarele aplica ții contabile:
SagaC. (http://www.sagasoft.ro), ContaSQL (www.cometa.ro), EasyCont
(http://www.sasory.ro), CielConta (http://www.ciel.ro)
Tabel 5.6
Exemplu. Matricea deciziilor
Ci
Aj C1
Preț achiziție +
prețul
abonamentului
(criteriu de
minim) C2
Plata în rate
(criteriu de
maxim)
C3
Instruire
(criteriu de
maxim) C4
Interfața
(criteriu de
maxim,
intangibil)
A1
(Saga) 350 0,25 0,5 0,5
A2
(ContabSQL) 156 0,75 0,75 0,25
A3
(EasyCont) 1350 0 0,5 0,75
A4
(CielConta) 2200 0 0,25 0,25
Dup ă studierea ofertelor disponibile s-a constat c ă următoarele
cerințe sunt respectate de c ătre toate aplica țiile studiate: C6, C7, C8 și C9
așa că nu vor apare în matricea deciziilor, vezi tabelul 5.6.
Determinarea coeficien ților de importan ță a criteriilor adic ă
ierarhizarea criteriilor este prezentat ă în tabelul 5.7.
69
Tabel 5.7
Exemplu. Ierarhizarea criteriilor
Pk \ C j C1 C2 C3 C4
P1 4 1 4 3
P2 4 2 4 3
P3 3 4 4 3
P4 4 4 4 4
P5 4 4 4 2
P6 3 4 1 4
P7 1 1 2 1
P8 2 4 1 1
P9 1 4 1 2
Kj 26 28 25 23
(d) () max 36 j
j
jjN
KNN== 1,385 1,286 1,440 1,565
Se calculeaz ă matricea de dep ărtare, prezentat ă în tabelul 5.8
Tabel 5.8
Exemplu. Matricea de dep ărtare
Ai \ C j C1 C2 C3 C4
A1 (Saga) 0,554 0,667 0,333 0,333
A2 (ContabSQL) 0,000 0,000 0,000 0,667
A3 (EasyCont) 0,884 1,000 0,333 0,000
A4 (CielConta) 0,929 1,000 0,667 0,667
111561 1 0, 446 0,554350X=− =− =
, 1215610156X=−=
,
131561 1 0,116 0,8841350X=− =− =
, 141561 1 0,071 0,9292200X=− =− =
210, 25 0,75 0, 25 0,501 0,6670, 75 0, 75 0, 75X−=− = = =
,
23 24011 0 10,75XX== − = − =
310,5 0, 75 0,5 0, 251 0,3330, 75 0, 75 0, 75X−=− = = =
Se calculeaz ă matricea de apartenen ță folosind (d) din tabelul 5.7 xe−
70
Tabel 5.8
Exemplu. Matricea de apartenen ță
Ai \ C j C1 C2 C3 C4 Suma Clasament
A1 (Saga) 0,464 0,424 0,619 0,593 2,101 III
A2 (ContabSQL) 1,000 1,000 1,000 0,352 3,352 I
A3 (EasyCont) 0,294 0,276 0,619 1,000 2,189 II
A4 (CielConta) 0,276 0,276 0,383 0,352 1,288 IV
Kj 1,385 1,286 1,440 1,565
În final alternativa candidat ă cea mai bun ă este produsul software de
contabilitate ContabSQL .
BIBLIOGRAFIE
1.
[LUN03] Lungu, I., Sab ău, G., Velicanu, M. ș.a. – Sisteme informatice.
Analiză, proiectare și implementare , Editura Economic ă, București, 2003
2. [BOB02] Bob, C. A. – Sisteme informatice în comer ț, Editura ASE,
București 2002
***
1.
[AUGxx] http://mis.aug.edu
71
TESTE DE EVALUARE
1. Ca urmare a studierii mediului în care func ționează un sistem informatic
de contabilitate se vor elabora dou ă modele:
a. modelul contextual și modelul logic;
b. modelul resurselor și modelul documentelor;
c. modelul fizic și modelul logic.
2. Pentru a fi analizat, un si stem se poate descompune dup ă mai multe
criterii cum ar fi:
_____________________________________________________________
__________________________________________________________________________________________________________________________ 3.
Întocmiți diagrama simplificat ă de flux a documentelor în cazul unui
punct de vânzare care elibereaz ă numai bonuri de cas ă.
4. Întocmiți diagrama detaliat ă de flux a documentului factur ă în cazul în
care facturile sunt emise prin intermediul unui calculator. 5.
Dați câteva exemple de stocuri de date manuale, altele decât cele
enumerate mai sus:
_____________________________________________________________
__________________________________________________________________________________________________________________________ 6.
Pentru construirea modelului MLD în cazul unei unit ăți de învățământ
public, determina ți entitățile de interes pentru contabilitate.
7. Schițați modelul entitate-asociere în cazul unui aviz de expedi ție.
8. Pașii elaborării modelului fizic al sistemul ui de contabilitate existent:
_____________________________________________________________
__________________________________________________________________________________________________________________________ 9.
Dați câteva exemple care pot fi folos ite pentru a stabili gradul de
pregătire a unei unit ăți economice pentru implementarea unui sistem
informatic de contabilitate nou.
_____________________________________________________________
_________________________________________________________________________________________________________________________
72
TEMA 6. SECURITATEA ȘI CONTROLUL SISTEMELOR
INFORMATICE DE CONTABILITATE
CONȚINUT
6.1. Securitatea și valoarea informa ției
6.2. Sursele de riscuri
6.3. Auditul sistemelor informatice de contabilitate
REZUMAT
Sistemele informatice de contabilitate func ționează într-un mediu în
care conține surse de riscuri care trebuie studiate cu aten ție pentru a se lua
măsurile de siguran ță și control care se impun astfel încât func ționarea
sistemului s ă se realizeze corect.
OBIECTIVE
Tema propus ă are ca scop asimilarea unor cuno ștințe referitoare la:
– problemele legate de securitatea;
– riscurile asociate mediului sistemului informatic de
contabilitate;
– auditul sistemului informatic de contabilitate.
6.1 SECURITATEA ȘI VALOAREA INFORMA ȚIEI
Valoarea unui produs software de contabilitate se poate exprima din două puncte de vedere:
•
al clientului ca suma maxim ă de bani pe care un client este dispus
să o plătească în schimbul produsului informatic, luând în
considerare caracteristicile sale calitative, conjunctura rela ției
cerere-ofert ă și prețurile produselor similare ale concuren ților;
• al producătorului ca suma minim ă a costurilor de produc ție.
Ca urmare putem spune c ă valoarea unui sistem informatic de
contabilitate este o caracteristic ă greu de cuantificat. A da valoare contabil ă
unui întreg sistem informatic este o problem ă dificilă chiar și pentru
contabili. De și bunurile intangibile s unt incluse în balan țele contabile, nu
există metode exacte de a le da o valoar e bunurilor bazate pe tehnologie atât
din motive subiective, intangibile, cât și obiective, cum ar fi:
• valoarea nu se suprapune exact peste pre țul de achizi ției sau
costurile de dezvoltare al e unui sistem informatic;
• percepția valorii unui aceluia și sistem informatic depinde și diferă
de la un utilizator la altul;
• valoarea depinde foarte des de crit erii cum ar fi: rapiditatea cu
care este ob ținută, oportunitate și relevanța ei;
• informațiile interne ale unei unit ăți economice nu se pot testa pe
piață.
73
Stabilirea unei valori a întregului sistem informa țional devine o
preocupare atunci când trebuie înlocuit sau extins. În practic ă, de obicei, nu
se face nici o analiz ă imediată după implementarea sistemului nou, pentru a
se verifica îmbun ătățirile aduse de c ătre acesta la nivelul valorii informa ției.
Exist ă multe activit ăți pentru care securitatea și controlul sunt foarte
importante1, de exemplu:
• serviciile bazate pe r ăspunsul imediat c ătre consumator (de
exemplu, dac ă un client al unei b ănci face o tranzac ție folosind un
terminal sau Internetul, va dori s ă vadă instantaneu modific ările
din cont chiar dac ă tranzacția se face de fapt a doua zi);
• utilizarea unei baze de date centralizat ă ( c u m a r f i u r m ărirea
traseului unui colet po ștal la nivel na țional);
• utilizarea sistemelor informatice în procese care pot afecta
siguranța și sănătatea popula ției (de exemplu monitorizarea din
centralele nucleare);
• lucrul într-un domeniu în care r ăspunsul trebuie dat în timp real
(de exemplu, monitorizarea bursei de c ătre broker-i);
• monitorizarea și controlul traficului (în aeroporturi, pe str ăzi etc.).
Afacerile se desf ășoară în condiții de risc, dar aceasta nu înseamn ă
că sunt binevenite alte risc urile noi. Tehnologia informa ției, implicat ă în
cam toate ariile unei afaceri, și-a demonstrat în timp fragilitatea: a introdus
incertitudini noi și riscuri noi, s-a dovedit a fi sensibil ă la erori, incidente,
fraude și alte tipuri de atacuri cu imp act negativ nu nu mai asupra activit ății
unei unități economice dar și, de multe ori, asupra succesului în afaceri a
acesteia. Și totuși, chiar și în aceste condi ții de nesiguran ță, afacerile au
devenit tot mai dependent e de tehnologia informa ției.
Securitatea calculatoarelor a fost gândit ă inițial pentru p ăstrarea
informațiilor secrete din domeniul militar. În lumea afacerilor securitatea
calculatoarelor a p ătruns ulterior, dup ă ce afaceri știi au ajuns la concluzia c ă
nu doreau ca, nici întâmpl ător nici cu inten ție, propriile sisteme s ă fie
„deschise” spre exterior și nici ca datele s ă fie distruse sau alterate din
interior. Modelul de securitate militar (vez i figura 6.1) este unul construit pe
patru nivele și răspunde unor exigen țe mari de securitate. Pornind de la acest
model, într-un sistem informa ț
ional mai pu țin rigid se pot implementa
diverse alte modele pe mai multe nivele , cu diverse grade de securitate, în
funcție de natura, dimensiunea și rigoarea stabilit ă de către conducere.
1 Hawker, A. – „ Security and Control in Information Systems: A Guide for Business and
accounting ”, pagina 17
74
Figura 6.1 Modelul militar al securit ății.
Sursa: [HAW00], pagina 4
„În mediul economic este foarte important ca modificarea datelor s ă
nu se facă în mod neautorizat și nici ca datele s ă ajungă la persoanele și/sau
companiile nepotrivite”1 (de exemplu, la posibilii concuren ți). Urmărirea
securității sistemului informatic de contabilitate (a posibilelor fraude, a
integrității și acurateței datelor) se poate face în dou ă moduri:
– prin jurnalul opera țiunilor: fiecare opera ție se salveaz ă într-un jurnal
al operațiilor care nu permite decât ad ăugarea unor date de genul:
utilizator, data calendaristic ă, ora, opera ția și toate datele despre
operația efectuat ă (de exemplu: suma, nume și număr al actului,
beneficiar). Acest jurnal se poate folosi în situa ții diverse cum ar fi
pierderea complet ă sau parțială a datelor. Jurnalul poate fi util și
pentru nivelul de conducere care poate ob ține informa ții non-
financiare cum ar fi: urm ărirea exact ă a activității fiecărui contabil,
calcularea timpii aloca ți operațiilor etc.;
– prin separarea sarcinilor: sarcinile se distribuie distinct contabililor
care se „specializeaz ă” în lucrul cu anumite opera ții, cum ar fi
încasările.
Obiectivele securit ății și controlului sistemelor informatice
enumerate de Andrew Hawker2 sunt: protejarea secretelor, acurate țea
datelor, prevenirea falsific ării, păstrarea „dovezilor” despre operator,
respingerea atacurilor, p ăstrarea cronologic ă a acces ării autentificate,
asigurarea „supravie țuirii” datelor, maximizarea posibilit ăților de audit.
Se presupune c ă toate unit ățile economice urm ăresc să aibă
îndeplinite obiectivele securit ății și controlului. Trebuie f ăcută observația că
1 Hawker, A. „ Security and Control in Information Systems: A Guide for Business and
accounting ”, pagina 4
2 Andrew Hawker „ Security and Control in Information Systems: A Guide for Business and
accounting ”, pagina 5 Securitate înalt ă
Securitate sc ăzută Top
secret
Secret
Confidențial
Neclasificat
75
atingerea acestor obiective este foarte important ă pentru organiza țiile care
manipuleaz ă date cu caracter persona l, date care trebuie s ă rămână
confidențiale pentru mediul extern al organiza ției.
Figura 6.2 Autorizarea accesului într-un sistem informatic
Sursa: [HAW00], pagina 6
Implementarea unui model de securitate în cadrul unui sistem
informatic de contabilita te presupune identif icarea locului/locu rilor în care
controalele se pot aplica în mod automat sau par țial automat. Aceasta
implică stabilirea unor grani țe virtuale în jurul unor componente și activități
ale sistemului informatic. Ideal este ca toate sistemele informatice ale unei unități economice s ă se găsească în interiorul acestor grani țe. În practic ă s-ar
putea să existe și în afara grani țelor așa că se impune verificarea acestora
atunci când se face accesarea zonelor cu control intern automat (vezi figura
6.2). Ca urmare a verific ării se poate ob ține autoriza ția de acces în sistemul
informatic de contabilitate. În interiorul sistemului se vor aplica procedee de control în func ție
de modul de urm ărire a securit ății (prin jurnal sau prin separarea sarcinilor).
Delimitarea prezentat ă în figura 6.2 asigur ă faptul că se poate determina de
unde provine o amenin țare, adică din interiorul sau exteriorul organiza ției.
Importan ța controlului și protejării informa ției pornește din faptul c ă
informația are valoare. Într-un mediu concuren țial, dacă informația este de
importanță mare pentru rivali, informa ția devine una care trebuie protejat
ă și
i se va aplica un nivel de securitate înalt ă. Dacă informația este de valoare
mică, cum ar fi copia unei chitan țe eliberată pentru o persoan ă fizică, i se va
aplica un nivel de securitate sc ăzută.
6.2 SURSE DE RISCURI
Toate unit ățile economice trebuie s ă facă evaluarea complet ă a
riscurilor și să implementeze controale inte rne adecvate pentru a putea
stabili programe de management al riscului. Tipurile și severitatea amenin țărilor cresc odat ă cu dependen ța
afacerilor de sistemele inform atice. Aceasta se întâmpl ă din motive cum ar
fi:
•
nivelul de operare – multe sisteme informatice func ționează la
nivel național sau interna țional. Astfel dac ă sistemul informatic control
automat controlul
accesului cereri de acces interne granițele organiza ției
cereri de acces externe
76
al unei bănci devine neopera țional, s-ar putea s ă apară probleme
la nivel na țional;
• viteza – viteza de lucru și cea transmitere au crescut astfel c ă
fișiere mari pot fi distruse, copiate sau transmise aproape
instantaneu;
• inovația tehnică – tehnologiile noi modific ă regulile de baz ă dar
multă lume nu le în țelege atât de bine încât s ă le foloseasc ă în
siguranță, putându-se efectua opera ții despre care nu se știe că
sunt riscante. Pe de alt ă parte, bunii cunosc ători ai tehnologiilor
informaționale își pot folosi talentele pe ntru a produce daune fie
direct la locul de munc ă fie prin p ătrunderea din exterior (de
exemplu, prin intermediul unei re țele);
• cauze ascunse – de multe ori e greu de descoperit cauza care a
stat la baza producerii unei daune (de exemplu efectuarea unei
tranzacții bancare duble în condi țiile plății unei sume cu ajutorul
unui card, blocarea unui card în tr-un terminal chiar dac ă s-au
introdus corect datele de identificare).
În continuare vom trata câteva dintre sursele de riscuri.
Sistemele de operare
Sistemele de operare sunt necesar e pentru a face toate componentele
sistemului de calcul s ă funcționeze corect și eficient. De obicei un calculator
se cumpără cu sistemul de operare gata instalat și care deja are facilit ăți sub
formă de programe utilitare, de asistare și de mentenan ță a echipamentelor
hardware. O aten ție deosebit ă trebuie acordat ă modului în care se realizeaz ă
protecția contra accesului neautorizat. Implicit sistemele de operare și
aplicațiile pun la dispozi ția utilizatorului drepturi depline de acces; aceste
drepturi trebuie modificate conform necesit ăților de securitate ale
utilizatorului. Un alt aspect care reclam ă atenție e acela al utilizatorilor
„uitați” adică un nume de utilizator cu o parol ă care se pot folosi de c ătre
producător sau de c ătre persoana care a pus în func țiune sistemul. Riscul
este de accesare neautorizat ă cu drepturi de acela și nivel ca și ale unui
administrator intern al unit ății economice, pe care beneficiarii sistemului
informatic de contabilitate nici nu îl iau în considerare în cazul unei audit ări
a sistemului.
Sistemele de gestiune a bazelor de date
Sistemele de gestiune a bazelor de date, pe scurt SGBD, se compun
dintr-o mul țime de programe care se folosesc pentru definirea, interogarea,
protejarea și manipularea unui volum mare de date. Bazele de date trebuie
să fie protejate contra amenin țărilor inten ționate sau neinten ționate,
„securitatea bazelor de date se refer ă la elemente de hardware și software,
persoane și date”
1. Connolly consider ă că securitatea bazelor de trebuie
asigurată corespunz ător pentru a preveni situa ții ca:
1 Connolly, T., Begg, Carolyn, Strachan, Anne – Baze de date. Proiectare. Implementare.
Gestionare , pagina 508
77
• furtul și frauda (frauda poate apare ca urmare a introducerii
intenționate de date eronate, de modificare a documentelor
justificative etc.);
• pierderea confiden țialității sau pierderea caract erului privat – este
foarte important ă, păstrarea secretului despre date, mai ales despre
acelea care intereseaz ă concuren ța;
• pierderea integrit ății sau pierderea disponibilit ății – pierderea
integrității datelor are ca rezultat apari ția unor date care nu
corespund documentelor justificat ive; pierderea disponibilit ății se
referă la faptul c ă datele devin inaccesibile (fie bazele date s-au
corupt din varii motive, fie a avut loc un eveniment hardware).
Daunele pot fi tangibile (cum ar fi deteriorarea unei componente
hardware) dar și intangibile (cum ar fi pierderea încrederii unui ter ț ca
urmare a furtului datelor).
Produsele software
Produsele software sunt folosi te pentru îndeplinirea func țiilor
afacerilor. Multe dintre acestea ( și care pot fi cump ărate pe loc cu o
funcționare complet ă) au fost concepute pentru a îndeplini sarcini generale.
Dintre acestea amintim editoarele de documente (Microsoft Word,
WordPerfect), programele de calcul tabelar (de exemplu Microsoft Excel,
Lotus 1-2-3), și de baze de date (Microsoft Access, SQL Server, Oracle).
Alte aplica ții au fost create pe ntru a îndeplini func ții specifice în domenii
variate (transferuri bancare online, aplica ții de design pe computer pentru
asistare în proiectare etc.). Contabi litatea se poate ajuta atât de programe
dedicate numai contabilit ății cît și de programe integrate într-un sistem
complex numit ERP
1. Un sistem ERP este o solu ție software ale c ărei
elemente sunt integrate într-o platforma comun ă. Sistemele ERP actuale
realizează integrarea tuturor func țiilor de conducere ale unei unit ăți
economice, (pornind de la planificare, la realizarea gestiunii financiar-
contabile, a resurselor umane și terminând cu gestiunea rela țiilor clien ții și
partenerii de afaceri). Un sistem ERP permite, prin simulare a activit ăților și
prin caracterul flexibil și dinamic al aplica țiilor, să se realizeze previziuni,
analize calitative și integrarea cu tehnologiil e noi de genul e-business și e-
comunicare. Exemple de sisteme ERP: Senior.ERP Suite , mySAP ERP , B-
Org.
Fiecare din aceste aplica ții poate sau nu s ă aibă elemente de
verificare concepute pe ntru a împiedica acces ările neautorizate. Pentru o
evaluare a unor verific ări competente ale acestor aplica ții este necesar ă
dobândirea unor cuno ștințe detaliate ale caracteris ticilor de verificare a
fiecărei aplicații folosite în mod cure nt într-o unitate economic ă.
Alte surse de riscuri
Multe sisteme informatice au prev ăzute mecanisme de control care
sunt propor ționale cu gradele riscurilor asociate cu func țiile îndeplinite de
către sisteme. De exemplu, tranzac țiilor financiare li se asociaz ă un grad de
1 Enterprise R esource P lanning – sistemele de planificare a resurselor unit ății economice
78
risc mare, un mecanism slab de control poate avea ca urm ări furtul datelor
celor implica ți în tranzac ție, alterarea datelor tranzac țiilor și altele.
Viru șii, în toatele formele lor, sunt un risc care apare în situa ții ca:
– un angajat lucreaz ă cu o dischet ă p e c a r e o f o l o s e ște și afara
unității economice;
– deschiderea e-mail-urilor cu ata șamente;
– vizitarea unor pagini de Internet și acceptarea execu ției unor
componente software (script, fi șiere executabile, ActiveX etc.)
despre originea c ăruia nu exist ă date care se pot verifica și care pot
avea un caracter distructiv și/sau de culegere a datelor
confidențiale.
Tabel 6.1
Riscurile asociate unor ac țiuni
Risc
Acțiune Furtul
și frauda Pierderea
confiden-
țialității Pierderea
caracterului
privat Pirederea
integrității Pierderea
disponi-
bilității
Utilizarea mijloacelor de
acces ale unei alte persoane * * *
Modificarea, copierea,
ștergerea neautorizat ă a
datelor * *
Alterarea programelor * * *
Politicile și procedurile
necorespunz ătoare care
permit ieșiri confiden țiale
pentru un nivel de securitate
înalt * * *
Interceptarea convorbirilor * * *
Accesul neautorizat sau
ilegal * * *
Crearea unei bre șe în sistem * * *
Furtul de date, programe și
echipament * * * *
Permiterea unui acces prea larg * * *
Conflictele de munc ă * *
Pregătirea
necorespunz ătoare a
personalului * * * *
Vizualizarea și divulgarea
neautorizat ă a datelor * * *
Alterarea datelor datorit ă
întreruperilor de energie sau
supratensiunii * *
Calamități * *
Introducerea de viru și * * *
Conectarea la Internet * * *
Criminalitatea informatic ă a cunoscut o cre ștere spectaculoas ă în
ultimii ani. Criminalitatea informatic ă face parte din crima organizat ă pentru
că: s-a extins la nivel interna țional, activit ățile ilicite se pot controla de la
79
distanță (prin intermediul Internetului) și grupările sunt bine structurate și
organizate. Persoanele implicate în criminalitatea informatic ă se
desemneaz ă ca fiind „infractori informatici” – sunt persoane care nu trebuie
să aibă cunoștințe solide de informatic ă, pot fi în slujba celor care au resurse
pentru construirea echipamentelor „ajut ătoare” (bancomatele false).
Infractorii informatici folosesc ceea ce este mai nou în domeniu (sisteme,
posibilități, modalit ăți de plată speciale) pentru a ob ține date personale cum
ar fi nume de utilizator și parole, numere de cont bancar, numere de carduri,
coduri PIN etc. Fraudele cu c ărțile de credit cresc ca pondere în
criminalitatea informa țională. O posibil ă explicație este aceea c ă banii se
obțin mai repede și mai ușor decât din alte tipuri de activit ăți ale crimei
organizate Nu este nevoie ca infractorul informatic s ă între în posesia fizic ă
a cardului. Prin compromiterea bancom atelor (prin folosirea camerelor de
luat vederi, fe țelor false de bancomat, tastaturi false, dispozitive pentru fanta
cardului etc.) se fur ă informația despre card și se scriu a șa numitele blank-
uri care se folosesc apoi ca și când ar fi cardurile originale.
Conectarea la Internet, pe lâng ă beneficii, a însemnat și expunerea în
fața unor riscuri ce țin de criminalitatea informatic ă. Furtul informa țiilor
despre clien ții unui magazin online, este o primejdie la care se expun to ți
vânzătorii și clienții care folosesc Internetul pentru tranzac ții.
Tabelul 6.1 prezint ă câteva dintre riscurile asociate unor ac țiuni
([CON01, paginile 510-511) care pot av ea loc pentru sursele de riscuri
descrise mai sus.
6.3 AUDITUL SISTEMELOR INFORMATICE DE
CONTABILITATE
Auditul este partea contabilit ății în care tehnologia informa ției își
găsește o aplicabilitate deplin ă. Rezultatele financiare tradi ționale ale
auditului au devenit o industrie matur ă și se bazeaz ă pe legisla ția de profil și
pe standarde elaborate la nivel global (ISA1), cum ar fi: ISA 401 „Auditul
într-un mediu cu sisteme informatice” (Auditing in a Computer Information Systems Environment), ISA 1008 „Evaluarea riscurilor si c ontrolul intern –
caracteristici și considerente ale sistemelor informatice” (Risk Assessments
and Internal Control – CIS Characteris tics and Considerations), ISA 1009 –
“Tehnici de audit asistate de calclator” (Computer-Assisted Audit
Techniques). Standardele stabilesc modul în care trebuie s ă se facă operații ca
preluarea și prelucrarea datelor, înregistra rea în conturi. înregistrarea
modificărilor ce se produc în bilan ț ca urmare a tranzac țiilor incheiate de
societate. Se stabile ște și verificarea urm ătoarelor aspecte:
•
absența documentelor de intrare, justificative;
• absența probelor materiale de derulare a tranzac țiilor;
• absența posibilit ăților de accesare și/sau vizualizare a rezultatelor
prelucrării.
Obiectivele generale si pr ocesul de audit al situa țiilor financiare nu
diferă structural de etapele și procedurile comune. Excep țiile apar când
1 International Standard on Auditing, http://www.ifac.org/iaasb/
80
auditorul dore ște cunoa șterea programelor de contabilitate, în țelegerea
profundă a funcționării acestora pas cu pas, precum și a modului în care
acestea răspund cerin țelor utilizatorului.
Intr ările de baz ă pentru contabilitate sunt tranzac țiile măsurate în
unități monetare. O urmă-audit a tranzac țiilor contabile p ăstrată într-un
sistem al unit ății economice permite utilizatorilor informa ției să urmărească
fluxul datei de-a lungul sistemului . Figura 6.3 este un exemplu de o
asemenea urm ă care prezint ă în paralel un ciclu contabil al unit ății
economice care începe cu datele tranzac ției reflectate din documentele de
intrare justificative și se termin ă cu producerea, ca ie șire, a extraselor de
cont sau al altor rezultate financiare. Contabilitatea preia da tele relevante de
intrare din documentele justificative și arhiveaz ă documentele pentru o
utilizare ulterioar ă în scopuri de control și auto-control (de exemplu,
verificarea cursului valutar pentru o anumit ă intrare în jurnal).
Un sistem informatic contabil care are o urm ă-audit bun ă permite, de
exemplu, unui manager s ă urmărească datele oric ărui document justificativ,
prin prelucrare pân ă la locul în care s-a ob ținut raportul de ie șire. De
asemenea sistemul poate s ă permită unui contabil urm ărirea datelor
financiare pornind de la balan țele contabile înapoi spre documentele de
intrare originale care au determinat tranzac țiile care au influen țat balanțele.
Ca exemplu, o factur ă de intrare trebuie s ă poată fi urmărită prin intermediul
urmei-audit de la cont urile clientului pân ă la contul debitor și contul
creditor. Similar, un cont abil poate verifica balan țele pentru conturile
creditoare și debitoare prin examinarea tranzac țiilor și a documentelor de
intrare originale. Printr-o urm ă-audit dezvoltat ă eficient, un contabil poate
urmări datele de-a lungul întregului sistem; aceast ă urmărire fiind posibil ă
dacă oamenii dintr-un sistem pot în țelege pe de-a întregul metodele și
procedurile pentru acumularea și prelucrarea datelor. Un rezultat este c ă se
poate reconstrui de c ătre contabili modul în care sistemul manevreaz ă
datele. Un sistem computeri zat bine proiectat poate îmbun ătăți urma-audit
prin furnizarea unei liste, a mul țimii tranzac țiilor și a balanțelor conturilor
înainte și după ce tranzac țiile au modificat c onturile. Pentru unit ățile
economice care vor s ă-și dezvolte un sistem de control intern eficient,
urmele-audit sunt elemente importante ale acestui control.
Figura 6.3 Exemplu de urm ă-audit financiar ă
Sursa: [MOS03], pagina 10
Auditorii interni trebuie s ă examineze componentele unui sistem
informatic (hardware, software), mentenan ța acestora și alte caracteristici Intrări Prelucrarea
tranzacțiilor Ieșiri
Documente de
intrare Jurnal
Registru
Balanța
provizorie Fișiere ale
documentelor
sursă Extrase de cont
sau
rapoarte externe
81
prin care s ă se poată determina care dintre asemen ea costuri s-au înregistrat
corespunz ător în balan țele contabile. De exemplu, componentele hardware
și cele software trebuie capitalizate și amortizate în perioade de timp care
depășesc cu mult durata de func ționare, perioada de via ță în care sunt utile
funcționării sistemului informatic de contabilitate iar costurile prepl ătite
pentru între ținere pot fi clas ificate ca bunuri și cheltuite numai în perioada
pentru care s-au f ăcut plățile.
Dac ă o unitate economic ă este mic ă și are numai unul sau doi
auditori, aceste persoane trebuie s ă aibă cunoștințe despre contabilitate,
finanțe și altele. Acest tip de auditor este unul care auditeaz ă tratarea
contabilă a costurilor asociate cu calculatoarele și nu va fi un auditor
specializat în auditul si stemelor informatice ([CHA03], pagina 126). Dac ă
unitatea economic ă este mare și are un departament de audit intern, auditul
se poate face de c ătre unul sau mai mul ți auditori cu studii în diverse
domenii. În acest caz, pentru un audit profund, se vor examina întregul proces, auditul costului echipamentelor hardware și/sau software fiind doar
o parte a auditului. Oricare ar fi modul de control intern, costurile asociate
cu echipamentele hardware și cu cele software trebuie s ă se conformeze
normelor legislative. Investitorii și creditorii care folosesc rezultatele financiare se pot
folosi ș
i de alte surse decât auditul pentru informa ții care să îi ajute în luarea
deciziilor. Aceasta se întâmpl ă din cauza c ă rezultatele financiare de audit
deseori nu devin disponibile într-un timp oportun.
BIBLIOGRAFIE
1.
[CHA03] Champlain, J. – Auditing information systems , John Wiley &
Sons, 2003 2.
[CON01] Connolly, T., Begg, Carolyn, Strachan, Anne – Baze de date.
Proiectare. Implementare. Gestionare , Editura Teora, Bucure ști 2001
3. [HAW00] Hawker, A. „ Security and Control in Information Systems: A
Guide for Business and accounting ”, Routledge 2000
4. [ION07] Ionescu, Gh. – Nore de curs pentru uzul cursan ților de la
școala doctoral ă, Timișoara 2007
5. [MOS03] Moscove, S.A., Simkin, M. G., Bagranoff, Nancy A. – „Core
Concepts of Accounting Information Systems”, John Wiley & Sons Ltd, 2003
***
1.
http://www.ifac.org/iaasb
82
TESTE DE EVALUARE
1.
Valoarea unui produs software de c ontabilitate se poate exprima din
punctul de vedere al clientului ca:
_____________________________________________________________
__________________________________________________________________________________________________________________________ 2.
Specificați câteva aspecte care nu se pot cuatifica pentru a da o valoare
exactă bunurilor bazate pe tehnologie:
_____________________________________________________________
__________________________________________________________________________________________________________________________ 3.
Securitatea și controlul sunt impor tante pentru activit ăți ca:
_____________________________________________________________
__________________________________________________________________________________________________________________________ 4.
Obiectivele securit ății și controlului sistemelor informatice sunt:
_____________________________________________________________
__________________________________________________________________________________________________________________________
5.
Specificați câteva surse de riscuri:
_____________________________________________________________
__________________________________________________________________________________________________________________________ 6.
Specificați caracteristicile urmei-audit în tr-un sistem informatic de
contabilitate:
_____________________________________________________________
__________________________________________________________________________________________________________________________
http://www.conta -conta.ro/
http://www.conta -conta.ro/index.php?page=tarife
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Ramona VASILESCU [614721] (ID: 614721)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.