Cuprins

Introducere ......................................................................................................... 3

1. Sisteme informatice – complexitate şi costuri ....................................... 7

2. Construirea de modele şi stabilirea de limite ......................................... 13

3. Realizarea şi măsurarea concordanţei ...................................................... 16

4. Obiectul auditului pentru sisteme informatice ...................................... 22

5. Construirea de liste ....................................................................................... 43

6. Auditul specificaţiilor ................................................................................... 55

7. Auditul proiectului de sistem informatic ................................................. 66

8. Auditul textelor sursă .................................................................................. 77

9. Auditul datelor ............................................................................................... 103

10. Raportul de auditare ................................................................................... 120

11. Concluzii .......................................................................................................... 124

Anexa 1 – Lista de variabile ....................................................................................................... 129

Anexa 2 – Lista de figuri ............................................................................................................ 132

Anexa 3 – Lista de tabele ........................................................................................................... 133

Anexa 4 – Lista de verificare (Checklist) pentru specificaţiile funcţionale ................. 133

Anexa 5 – Programul de audit .................................................................................................... 136

Anexa 6 – Nota de neconformitate .......................................................................................... 137

Anexa 7 – Raport de audit .......................................................................................................... 137

Anexa 8 – Raport de audit intern ............................................................................................. 139

Anexa 9 – Organisme, regulamente şi standarde referitoare la auditul sistemelor

informatice ........................................................................................................... 143

Bibliografie .......................................................................................................... 144

INTRODUCERE

Societatea informaţională determină o creştere dramatică a dependenţei tuturor domeniilor vieţii economico-sociale de tehnnologiile informaţionale. Sistemele informatice sunt construcţii complexe care vizează mai multe probleme diferite ale unei companii. Având în vedere consumul de resurse umane şi financiare la dezvoltarea unui sistem informatic, este necesar să se desfăşoare anumite activităţi care să conducă la atingerea obiectivului propus, la timp, cu nivelul de calitate stabilit şi în limita bugetului alocat. Una dintre aceste activităţi, deosebit de importantă, atât pentru realizatori, cât, mai ales, pentru utilizatori, este auditul sistemelor informatice (SI). Auditul SI este o ramură a auditului general care se ocupă cu controlul tehnologiilor informaţiilor şi comunicaţiilor. Auditul SI studiază, în primul rând, sistemele şi reţelele de calcul din punct de vedere al examinării eficienţei controlului tehnic şi procedural pentru a minimiza riscurile. Auditarea SI presupune discuţii cu personalul care stabileşte specificaţiile, dezvoltă, testează, conduce, administrează şi utilizează sistemele de calcul [HINS05]

Obiectivul lucrării îl constituie stabilirea unor modalităţi de realizare a auditului sistemelor informatice.

Pentru atingerea acestui deziderat, lucrarea este structurată pe douăsprezece capitole.

În capitolul Sisteme informatice. Complexitate şi costuri, sunt prezentate condiţiile în care se dezvoltă un sistem informatic şi influenţa acestora atât asupra procesului de dezvoltare, cât şi asupra produsului final. Se analizează, sumar, structura unui sistem informatic şi relaţiile dintre subsistemele acestuia şi se face referire la necesitatea auditului informatic.

Construirea de modele şi stabilirea de limite se tratează în cel de-al doilea capitol. Construirea de modele şi stabilirea de limite sunt activităţi importante care sunt avute în vedere atât de către realizatorii sistemului informatic, cât şi de către auditori. Stabilirea limitelor între care

3

trebuie să se încadreze rezultatele unui sistem informatic conduce la eliminarea unor situaţii nedorite, care, în anumite domenii, au urmări imprevizibile.

În capitolul al treilea, Realizarea şi măsurarea concordanţei, sunt prezentate, succint, sistemele care compun o companie, indiferent de mărimea acesteia, sunt relevate interacţiunile dintre sisteme şi sunt scoase în evidenţă caracteristicile sistemului informatic comparativ cu celelalte sisteme. Între toate sistemele care compun o companie este necesar să existe concordanţă deplină pentru îndeplinirea obiectivelor asumate.

Obiectul auditului pentru sistemele informatice este tratat în capitolul al patrulea. Auditul informatic este o activitate complexă diferită de alte activităţi. Se prezintă, comparativ, auditul informatic şi alte activităţi precum controlul şi expertiza. Se descrie rolul auditului informatic şi efectul acestuia asupra utilizatorului sistemului informatic auditat.

Capitolul al cincilea Construirea de liste descrie necesitatea construirii listelor pentru desfăşurarea procesului de auditare. Sunt analizate tipurile de liste şi rolul acestora în desfăşurarea procesului de auditare. Se prezintă cerinţele impuse unei liste pentru a obţine rezultatele scontate. Construirea listelor reprezintă latura esenţială a procesului de auditare – planificare. Fără un plan bine elaborat, articulat şi fără o viziune unitară, rezultatul final este afectat de factori perturbatori.

Auditul specificaţiilor este analizat în capitolul al şaselea. Realizarea unui sistem informatic care să răspundă cerinţelor utilizatorilor depinde , în mod esenţial, de stabilirea specificaţiilor. Specificaţiile constituie baza proiectării şi dezvoltării oricărui sistem. Din acest considerent, se impune ca procesul de auditare a unui sistem informatic să înceapă cu auditul specificaţiilor. În acest capitol sunt analizate modalităţile de realizare a auditului specificaţiilor.

Auditul proiectului este analizat în capitolul al şaptelea, având în vedere că un sistem informatic, cu un nivel de calitate cerut, se realizează având la bază un proiect cu un grad corespunzător al calităţii. Se urmăreşte cuprinderea specificaţiilor, regăsirea acestora în rezultatele finale. Se propun modalităţi de auditare a cheilor de acces şi a parolelor. Sunt descrise criterii de apreciere şi indicatori de evaluare a calităţii proiectului. Auditul

4

proiectului sistemului informatic trece, prin utilizarea unor indicatori, din zona aprecierilor strict calitative, în zona analizei, având o fundamentare riguroasă. Elementele incluse în liste şi diferenţele devin vizibile şi sunt cuantificate, asigurând un grad ridicat de rigurozitate procesului de realizare a sistemului informatic.

Auditul textelor sursă este descris în capitolul al optulea. Se face o descriere succintă a necesităţii auditului textelor sursă. Se prezintă modalităţi de evaluare a diferenţelor dintre ce s-a proiectat şi rezultatele practice obţinute. Se propun măsuri de remediere a deficienţelor în cazul în care se constată. Se subliniază importanţa, din punctul de vedere al auditorului, a rezultatelor şi a fluxurilor pe care le generează.

Capitolul al nouălea, Auditul datelor, se referă la un proces complex întrucât vizează acele componente ale sistemului informatic care au ca obiectiv crearea şi actualizarea fişierelor sau bazelor de date. Sunt prezentate criterii de validare a datelor. Se analizează modalităţi de iniţializare a variabilelor şi se propun măsuri de prevenire a erorilor.

În cel de-al zecelea capitol este descris modul de redactare al unui Raport de audit.

Lucrarea se încheie cu concluzii în care sunt date şi o serie de direcţii de urmat.

Bibliografia conţine: ⇒ tratate fundamentale de audit; ⇒ cărţi privind metrici software şi tehnici şi metode de programare; ⇒ lucrări elaborate de autori sub formă de cărţi, articole şi comunicări

la manifestări ştiinţifice din ţară şi din străinătate; ⇒ articole din reviste de specialitate; ⇒ site-uri care tratează problemele de maximă actualitate, forumuri de

discuţii pe probleme de managementul calităţii software şi calitatea datelor.

Autorii lucrării au procupări în domeniul dezvoltării aplicaţiilor informatice, analizei metricilor utilizate în dezvoltarea software, calităţii şi costurilor calităţii datelor şi produselor program. Aceste preocupări s-au materializat prin participarea la manifestări ştiinţifice cu caracter

5

internaţional, prin articole publicate atât în ţară, cât şi în străinătate, precum şi prin cărţi apărute în diferite edituri.

Referirea bibliografiei se efectuează folosind mnemonici construite din primele patru litere ale numelui primului autor urmate de ultimele două cifre ale anului apariţiei, incluse în paranteze drepte. Diferenţierile în cadrul lucrărilor aceluiaşi autor, apărute în acelaşi an, se fac prin adăugarea, la cifrele anului, a uneia din primele litere mici ale alfabetului.

În anexe se află: - lista variabilelor folosite în definirea de indicatori; - lista figurilor; - lista tabelelor; - lista de verificare – un exemplu; - program de audit - model; - nota de neconformitate - model; - raport de audit – model; - raport de audit intern – exemplu; - organizaţii, reglementări şi standarde referitoare la auditul SI.

Datorită faptului că o serie de concepte şi termeni nu au o traducere unanim acceptată în comunitatea specialiştilor din ţara noastră, pentru a nu introduce confuzii prin folosirea corespondenţilor locali ai acestor concepte şi termene, s-a preferat utilizarea denumirilor originale în limba engleză.

Lucrarea se adresează atât specialiştilor care dezvoltă şi implementează sisteme informatice, cât şi utilizatorilor acestor sisteme.

În lucrare sunt îmbinate concepte, definiţii, modele, tehnici şi metode care se regăsesc în literatura de specialitate, cu unele rezultate originale obţinute de autori de-a lungul mai multor ani de cercetare.

Autorii sunt recunoscători tuturor celor care, prin observaţii şi sugestii, contribuie la îmbunătăţirea unei viitoare ediţii a acestei lucrări.

6

1. SISTEME INFORMATICE COMPLEXITATE ŞI COSTURI

Sistemul informatic are menirea de a acoperi toate problemele agentului economic, de a crea interdependenţe între componente, astfel încât structurii fizice din sistemul ataşat agentului economic i se suprapune o structură în plan informaţional. Fluxurilor de producţie le corespund fluxuri informatice. Actorilor implicaţi în procese li se asociază emiţători şi receptori de informaţii cu niveluri diferite de prelucrare. Dezvoltarea directă de sisteme informatice se dovedeşte o întreprindere riscantă dacă nu este precedată de activităţi care au menirea de a impune o echipă, o tehnologie unitară de analiză, design, dezvoltare, implementare, exploatare şi mentenanţă, aspecte care trebuie luate în considerare la efectuarea unui audit de sistem informatic.

Sistemele informatice sunt construcţii complexe, realizate pe parcursul mai multor ani, necesitând:

fonduri foarte mari, uriaşe în anumite cazuri; echipe complexe şi stabile de analişti, designeri, programatori şi

personal care se ocupă de testare, implementare şi mentenanţă; stabilirea obiectivelor; definirea unei strategii de dezvoltare, exploatare şi mentenanţă; achiziţionarea de echipamente, instrumente necesare realizării de

prelucrări, de conexiuni şi dezvoltării fluxurilor cu exteriorul; -calificarea personalului pentru utilizarea corectă şi eficientă a

sistemului. Complexitatea sistemelor informatice şi durata, relativ mare, de

realizare a acestora generează o serie de probleme care trebuie luate în considerare şi soluţionate astfel încât, în final, să se obţină rezultatele scontate.

În primul rând, pe durata ciclului de dezvoltare a unui sistem informatic au loc schimbări în echipa managerială a beneficiarului. În cazul în care o nouă echipă managerială are o altă viziune asupra indicatorilor

7

agregaţi pe care îşi fundamentează deciziile, se produc modificări în specificaţii, care atrag modificări ale structurii sistemului informatic.

În al doilea rând, noile tehnologii informatice care apar impun adaptarea din mers a echipei de dezvoltare a sistemului informatic. Se produc schimbări în abordarea instrumentelor de asistare, în utilizarea de opţiuni. În final, o serie de componente se construiesc utilizând noile resurse. Sistemul informatic devine neomogen din punctul de vedere al tehnologiilor de dezvoltare.

În al treilea rând, dezvoltarea companiei prin achiziţionarea de noi echipamente, reorganizarea fluxului de producţie, trecerea la realizarea de noi produse, introducerea elementelor de management total al calităţii vin să influenţeze calitativ şi cantitativ structura şi funcţiunile sistemului informatic. Problema achiziţiilor de date capătă o altă dimensiune în cazul utilajelor cu comandă program sau în cazul liniilor de producţie robotizate.

În al patrulea rând, pe durata mai multor ani, însăşi echipa de programatori, webdesigneri, testeri şi implementatori suferă modificări. Diferiţi specialişti reîntregesc echipa. Toate aceste fluctuaţii se reflectă în sistemul de lucru, în calitatea componentelor sau stadiilor sistemului informatic.

În al cincilea rând, mediul economic, legislaţia şi dinamica proceselor din societatea informaţională conduc la evoluţii care trebuie reflectate în sistemul informatic.

Modificările unor algoritmi de calcul, necesitatea de a utiliza noi coeficienţi, apariţia unor schimburi de informaţii între companie şi instituţiile publice ale statului trebuie reflectate, de asemenea, din mers în sistemul informatic aflat în construcţie.

Toate aceste procese se derulează concomitent, producând efecte conjugate, în timp ce obiectivul stabilit iniţial, acela de a realiza un sistem informatic pentru managementul companiei, rămâne nemodificat. Sunt situaţii în care chiar condiţiile privind termenele de predare rămân neschimbate. În cazul în care noile cerinţe conduc la creşterea semnificativă a complexităţii produsului final – sistemul informatic pentru management - se impune creşterea volumului investiţiei pentru a suplimenta resursele necesare dezvoltării unui volum mai mare de activităţi. Creşterea volumului de activităţi care se derulează în paralel impune noi abordări la nivelul concepţiei sistemului informatic.

8

Un sistem informatic are în structura sa modulele de prelucrare MO1, MO2, .., MOn şi structurile de date Str1, Str2, ..., Strm. Forma fizică a acestora este foarte variată depinzând de tehnica de dezvoltare utilizată.

Se construieşte matricea de corespondenţă Ann pentru module. Elementul aij = 1 dacă modulul MOi este apelat de modulul MOj, iar în caz contrar aij = 0.

Se construieşte matricea Bmn pentru a stabili relaţia modul – date. Elementul bij = 1 dacă modulul MOj foloseşte structura de date Stri, iar în caz contrar bij = 0. Matricea Ann evidenţiază referirile între module. Matricea Bmn evidenţiază referirile de date de către module.

Se evidenţiază indicatorul Nrm – numărul total al referirilor de module, prin relaţia:

∑∑= =

=n

i

n

jijrm aN

1 1

Se calculează indicatorul Nrd – numărul total al referirilor de date de

către module prin relaţia:

∑∑= =

=m

i

n

jijrd bN

1 1

Complexitatea sistemului informatic CSI, în sens Halstead, este dată

de relaţia:

CSI = Nrm log2 Nrm + Nrd log2 Nrd

În cazul în care sunt luate în considerare modificările ce apar pe durata ciclului de dezvoltare, procesul de realizare a sistemului capătă un caracter iterativ convergent. O iteraţie k include toate procesele care se produc între două modificări.

Caracterul convergent vizează atingerea scopului iniţial, simultan cu reducerea efortului de includere a modificărilor, pe măsură ce procesul de realizare a sistemului informatic se apropie de final.

9

Pentru fiecare iteraţie k se definesc krmN , k

rdN , respectiv CSIk. Dacă se calculează:

∆k= CSIk – CSIk-1,

caracterul iterativ convergent vizează ca :

- şirul ∆1, ∆2, ... ∆L să fie un şir cu număr finit de termeni; - ∆1 > ∆2> … >∆L = 0.

În [BARO88] este stabilită o relaţie între costul CO al sistemului informatic şi complexitatea acestuia, de forma:

γβα += CSIO eC ,

unde α, β şi γ sunt coeficienţii estimaţi ai modelului.

Între productivitatea W a celor care elaborează un sistem informatic şi complexitatea acestuia există relaţia:

W= f(CSI) În [BARO88] relaţia dintre complexitate şi productivitate este de forma:

γα β +⋅= − CSIeW , unde α, β şi γ sunt coeficienţii estimaţi.

Durata de realizare D a sistemului informatic în funcţie de complexitate şi numărul salariaţilor, ns, este dată de relaţia:

D = h(CSI, ns) Numărul de salariaţi ns, funcţie de complexitatea sistemului şi de durata de realizare este dat de relaţia:

ns = g(CSI1, D)

10

Dacă se iau în considerare iteraţiile 1 şi L ale procesului de elaborare a sistemului informatic, pentru a menţine acelaşi termen de predare la cheie, sunt estimate nivelurile:

( )DCSIgns ,11 =

( )DCSLgn LLs ,= ,

iar diferenţa:

11 s

LsL nn −=∆

reprezintă sporul de salariaţi necesar asigurării încadrării elaborării sistemului informatic în termenul stabilit, chiar dacă apar modificări în toate direcţiile care privesc sistemul informatic respectiv.

Realizarea unui sistem informatic are menirea de a sprijini actul decizional la toate nivelurile. Sporul de informaţie, calitatea acesteia, promptitudinea cu care se obţine sunt argumente puternice pentru a determina saltul calitativ pe care îl presupune societatea bazată pe cunoaştere.

Din aceste considerente, implementarea unui sistem informatic trebuie să genereze efecte pozitive atât pentru utilizatorii săi, cât mai ales, pentru beneficiarii direcţi ai informaţiei prelucrate.

Pentru a se obţine acest deziderat, în procesul de elaborare este necesară aplicarea tuturor cerinţelor privind managementul calităţii sistemului informatic. De asemenea, este necesar să se realizeze auditul sistemului informatic pentru a se obţine garanţia că acesta realizează corect şi complet prelucrările pentru care a fost proiectat, iar orice combinaţie de date, alta decât cea corectă şi completă, este semnalată şi nu este generatoare de efecte colaterale pe termen mediu şi lung.

În realizarea proceselor de auditarea dezvoltării SI este necesar să se ia în considerare caracteristicile organizaţiei pentru care se proiectează sistemul şi, în primul rând, stabilitatea organiţzaţiei. Dezvoltarea SI se face în contextul evoluţiei mediului economico-social. Dinamismul schimbărilor în cadrul organizaţiilor, indiferent de dimensiunea acestora, impune adaptarea metodelor de dezvoltare a SI la noile condiţii sau apariţia unor concepte şi metode noi de dezvoltare a SI.

11

Organizaţiile în dezvoltare, denumite în limba engleză, organizaţii emergente, sunt organizaţiile a căror constantă o constituie încercarea continuă de adaptare la mediile în schimbare, dar care nu ating niciodată stabilitatea pentru care acţionează.

Acest tip de organizaţii este foarte diferit de cele stabile. Din cauza ipotezelor fundamental diferite privind realitatea şi dezvoltarea SI, procesele de proiectare a SI pentru organizaţii stabile, respectiv emergente, sunt diferite. De fapt obiectivele celor două procese sunt contradictorii [ALAT03]. Dezvoltarea SI pentru organizaţii stabile are în vedere următoarele obiective [ALAT03]:

- avantajele economice ale unei analize amănunţite; - satisfacţia utilizatorilor; - cerinţe abstracte; - specificaţii complete şi lipsite de ambiguităţi. Obiectivele propuse pentru dezvoltarea SI destinate organizaţiilor

emergente sunt următoarele: - analiza dinamică; - negocierea cerinţelor dinamice; - specificaţii utile ambigue şi incomplete; - redezvoltare continuă. Printre metodele utilizate în dezvoltarea SI pentru organizaţiile

emergente se numără: modelarea conceptuală şi evaluarea utilităţii şi utilizabilităţii. Modelarea conceptuală la reproiectarea schimbărilor sistemului, iar evaluările utilizabilităţii pot fi văzute ca o formă de analiză referitor la analiza permanentă care necesită a fi aplicată organizaţiilor emergente. Analizele publicate în literatura de specialitate şi unele cercetări ale autorilor demonstrează că în cadrul SI sunt întotdeauna necesare schimbări, aspect care se ia în considerare la auditarea SI.

12

2. CONSTRUIREA DE MODELE ŞI STABILIREA DE LIMITE

Sistemele informatice complexe presupun stocarea de informaţii privind un număr r de entităţi E1, E2, ..., Er. Pentru fiecare element al entităţii este definit un set de câmpuri de descriere. Experienţa designerilor conduce la descrieri complete care nu mai trebuie îmbunătăţite ulterior. Numărul de entităţi depinde de profunzimea procesului de analiză în a identifica grade de omogenitate şi criterii de alcătuire a colectivităţilor.

Construirea modelelor reprezintă o etapă deosebit de importantă. Stabilirea variabilelor precum:

Ni – numărul de componente ale entităţii Ei; NCi – numărul de câmpuri cu care se identifică factorii care definesc

elementele entităţii Ei; xijk – nivelul câmpului cu poziţia j pentru şablonul de descriere

aparţinând elementului k din entitatea Ei. şi identificarea condiţiilor pe care trebuie să le îndeplinească datele culese pentru a iniţializa câmpul xijk reprezintă o etapă esenţială în înţelegerea particularităţilor companiei pentru care se proiectează sistemul informatic.

Pentru datele care sunt introduse în bazele de date se defineşte limita inferioară, LINF, respectiv limita superioară, LSUP. Astfel, pentru toate câmpurile se construiesc inegalităţile duble.

LINFijk ≤ xijk ≤ LSUPijk

Pentru stabilirea celor două tipuri de limite sunt definite ipoteze de lucru unanim acceptate. De exemplu, pentru consumul casnic de gaze este luat în considerare debitul De pe oră, asociat conductei de intrare în locuinţă. Presiunea considerată este de nivel maxim, Pmax. Pentru un interval de timp TG exprimat în număr de ore, consumul maxim, Cmax, este dat de relaţia:

Cmax = TG*De 13

Consumul minim este zero. Rezultă că nivelul consumului de gaze CGgijk respectă inegalitatea dublă:

0 ≤ CGijk≤ TG*Deik.

Absenţa indicelui j se justifică prin nominalizarea câmpului cu identificator propriu CG. Absenţa acestor limite de intervale generează situaţii dintre cele mai bizare, care includ pentru efectuarea de calcule, unele valori aberante. Este cunoscut cazul unui cetăţean dintr-o comună vâlceană căruia i s-a montat invers un contor de apă, fiind pus să plătească pentru un consum astronomic. De asemenea, nu trebuie uitată nici posesoarea unui apartament de bloc care s-a trezit plătind un impozit cu mult mai mare decât al vecinilor de la celelalte etaje, întrucât apartamentul său, în mod eronat, a fost înscris cu o suprafaţă mai mare.

Tot astfel de consideraţii se fac şi pentru consumatorii de electricitate care primesc facturi cu o valoare de cel puţin 100 de ori mai mare. Chiar şi cazul calculului eronat al unor pensii, care a generat numeroase procese, şi a făcut istorie, fiind finalizat cu o scutire a plăţii unor datorii, trebuie dat ca exemplu ce nu trebuie urmat, privind neglijenţa cu care au fost stabilite limitele.

Un sistem informatic conduce la realizarea unui salt calitativ. Permite fundamentarea deciziilor în cunoştiinţă de cauză. El nu înlocuieşte ceva cu altceva. El este cu totul altceva, atât pentru executant, cât şi pentru decidenţi, indiferent de nivelul la care se află aceştia. Cu o condiţie, să fie construit ca instrument orientat spre management şi nu ca un auxiliar care dezvoltă aparatul birocratic.

Existenţa limitelor de variaţie are menirea de a filtra datele, iar la semnalizarea unor valori în afara intervalului se impune verificarea la faţa locului şi corectarea situaţiei de fapt, fie din punct de vedere tehnic, fie din punct de vedere scriptic sau informatic.

În dezvoltarea unui sistem informatic trebuie să se pornească de la experienţa acumulată.

În primul rând, compania pentru care se elaborează sistemul este de un profil, de o dimensiune şi de o complexitate asemănătoare cu alte companii. Înseamnă că ea nu trebuie tratată ca un caz special, asemenea unei opere de artă unicat, pentru care totul este nou în a crea un produs original. Încadrarea companiei într-o anumită grupă are drept consecinţă identificarea companiilor asemănătoare şi stabilirea elementelor de comparaţie pentru a obţine un cost estimat, durata de realizare şi, mai ales, eficienţa pe care o aduce proiectarea, realizarea şi implementarea unui sistem informatic pentru management.

14

În al doilea rând, unei companii obişnuite, aparţinând unei anumite clase, i se va realiza un sistem informatic adecvat, în concordanţă cu caracteristicile clasei. Complexitatea unui astfel de sistem nu depăşeşte semnificativ complexitatea medie a sistemelor informatice pentru companiile din aceeaşi categorie.

În al treilea rând, prin utilizarea de prototipuri, impuse de instrumentele de asistare pentru funcţiile de bază ale companiei, întregul proces de analiză – proiectare – programare – testare – implementare capătă o tentă industrială, de rutină.

În al patrulea rând, existenţa procedurilor pentru derularea activităţilor din companie defineşte fluxuri, stabileşte condiţii şi orientează dezvoltatorul de sisteme informatice spre care direcţie să orienteze demersul său pentru a obţine un sistem informatic modern, operaţional şi eficient.

În al cincilea rând, existenţa unei game largi de modele, de tehnici de construire şi de metode de măsurare conduc la a stabili care este modelul cel mai potrivit.

În al şaselea rând, regulile de asigurare a unui management al calităţii sistemului informatic, odată cunoscute, trebuie aplicate în acelaşi fel. Înseamnă că noul sistem este tratat din punct de vedere al managementului calităţii ca oricare alt produs din aceeaşi clasă de complexitate.

În al şaptelea rând, toate riscurile asociate procesului de dezvoltare a sistemului informatic au niveluri care nu diferă semnificativ de nivelurile riscurilor corespunzătoare sistemelor similare. Echipa care dezvoltă un sistem informatic urmăreşte cel mult să scadă nivelurile de risc, ceea ce conduce la creşterea volumului de resurse, prin introducerea de noi proceduri. Ca în orice meserie şi în cazul dezvoltării de sisteme informatice se aplică reţete sigure pentru reducerea diferitelor categorii de riscuri.

În al optulea rând, sistemul informatic, în integritatea lui, trebuie să fie un automat finit. Alfabetul de intrare, matricea de transfer şi outputurile se definesc riguros. Orice ambiguitate are menirea de a determina punerea în corespondenţă a elementelor altfel decât o cer procesele care se derulează în companie. Mai rău, prin generarea de simboluri care nu aparţin alfabetului, sistemul informatic devine automat stochastic, cu toate consecinţele negative care se imaginează.

Concepţia sistemului informatic are caracter unitar, urmăreşte un obiectiv unic şi, prin modul de structurare, prin resursele alocate, se constituie ca un demers realist şi, mai ales, realizabil.

15

3. REALIZAREA ŞI MĂSURAREA CONCORDANŢEI

O companie, oricare ar fi ea, este o suprapunere de sisteme. Primul sistem este cel al echipamentelor dispuse într-o anumită

ordine pentru a dezvolta operaţiile de prelucrare specifice unei tehnologii. Al doilea sistem este cel al materiilor prime care fac obiectul

prelucrărilor prin trecerea de la un echipament la altul. Asupra lor se execută operaţiile de prelucrare, rezultând transformări.

Al treilea sistem este acela de comandă a execuţiei, care include persoane calificate şi, într-o măsură mai mică sau mai mare, roboţi cu grade diferite de flexibilitate în acţiune şi decizie.

Al patrulea sistem este sistemul energetic care are menirea de a pune în mişcare utilajele şi de a crea condiţii optime persoanelor pentru a executa operaţii.

Al cincilea sistem este sistemul informaţional. Rolul său este determinant, întrucât fluxurile informaţionale au menirea de a declanşa funcţionarea utilajelor, generarea fluxurilor materiale, crează comunicarea dintre persoane. Împreună cu sistemul energetic controlează toate etapele unui ciclu de producţie. Între cele cinci sisteme care alcătuiesc compania trebuie să existe oricând o concordanţă perfectă. Primele patru sisteme, în mod obiectiv, sunt realizate şi există având o concordanţă reală între scop şi mijloacele de atingere a scopului. Orice neconcordanţă produce efecte negative şi, din acest considerent, din procesul de proiectare sistemele sunt concepute astfel încât să se minimizeze neconcordanţele. Aşa se explică dimensionarea echipamentelor pentru a efectua operaţii de prelucrare în condiţii de siguranţă. Proiectarea unui echipament presupune dispozitiv de tăiere, de măsurare, de dirijare, de control. Sunt create sisteme de pornire, de oprire, de protecţie şi de supraveghere. Toate acestea există, au formă materială caracterizată prin dimensiune, volum, poziţionare spaţială. Acţionarea produce efecte vizibile direct, precum: măsurare, tăiere, lipire,

16

ajustare, asamblare, vopsire, amestecare, coacere etc. Pentru utilaj sunt definite operaţii a căror caracterizare este precisă.

Sistemul materiilor prime, de asemenea, este compus din stocuri, din fluxuri în care componentele sunt descrise prin calitate, cantitate, formă, dimensiune. Interacţiunea sistemului materiilor prime cu utilajele determină transformări asupra materialelor. Astfel, o bară devine şuruburi, piuliţe sau şaibe.

Sistemul energetic are menirea de a pune în mişcare echipamentele care prelucrează materiile prime. Interacţiunea dintre echipamente, materii prime şi energie defineşte o tehnologie.

Persoanele au menirea de a interacţiona cu echipamentele, cu materiile prime şi realizează conectarea echipamentelor la energie, determinând, astfel, derularea de procese pe bază de tehnologii.

Sistemul informaţional este singurul care nu are formă vizibilă, care nu are fluxuri impuse, iar efectele vizibile sunt cele negative, efectele pozitive fiind asociate în mod natural echipei care dezvoltă managementul companiei. Dacă obiectul companiei este de a realiza încălţăminte, toate echipamentele care alcătuiesc liniile de producţie efectuează operaţii specifice tehnologiilor de realizare a încălţămintei.

Sistemul materiilor prime este şi el realizat în concordanţă cu obiectivul şi cu cerinţele sistemului de echipamente. Dacă echipamentele sunt destinate prelucrării pielei naturale, stocurile vor conţine piele naturală şi niciodată înlocuitori.

Calificarea persoanelor care alcătuiesc sistemul forţei de muncă se realizează pentru a mânui materiile prime şi pentru a executa operaţii pe echipamentele din cele două sisteme existente în companie, concordanţa fiind necesară pentru exploatarea corectă a echipamentelor şi pentru a nu produce rebuturi.

În cazul sistemului energetic, concordanţa se realizează de la proiectare, cunoscută fiind acţiunea devastatoare a existenţei neconcordanţei dintre caracteristicile sistemului la intrarea în echipamente şi caracteristicile cu care echipamentele au fost înzestrate.

Şi în cazul sistemului informaţional este necesară existenţa unei concordanţe. În mod firesc, o tehnologie se conectează printr-o linie de echipamente care este însoţită de software pentru sistemul informatic la cheie.

17

Caracterul local, particular al oricărui sistem informatic este dat de: - legislaţia ţării unde se implementează tehnologia; - structurile documentelor; - stadiul informatizării sistemului financiar-bancar; - diferenţele prin care se dezvoltă comunicarea între agenţii

economici, fiecare având sistemul lui informatic original; - nivelul de dezvoltare a managemetului companiei; - resursele financiare de care dispune compania pentru a investi în

informatică; - strategia companiei de a acorda informaţiei rolul de motor spre

progresul ei însăşi. Sistemul informaţional trebuie să fie şi el în concordanţă cu

obiectivul companiei, cu sistemul echipamentelor, cu sistemul materiilor prime, cu sistemul energetic şi, mai ales, cu sistemul forţei de muncă. Neconcordanţele dintre sistemul informaţional şi celelalte sisteme crează probleme în principal prin neutilizarea resurselor la nivelurile pentru care au fost proiectate. Acest mod de a realiza concordanţa explică de ce aceleaşi echipamente, aceleaşi materii prime, aceleaşi consumuri energetice, aceleaşi persoane au performanţe diferite, în funcţie de context. Conceptul de context include însăşi sistemul informaţional ca expresie a cerinţelor managementului distribuit pe nivelurile de structurare a companiei.

Dezvoltarea unui mod dinamic de a derula procese şi de a fundamenta decizii, depinde de numeroşi factori, dintre care cei care definesc persoanele, calităţile şi defectele acestora, au o pondere însemnată.

În primul rând, concordanţa dintre sistemul informaţional şi celelalte sisteme, între care există deja concordanţă de natură obiectivă, se realizează prin definirea de fluxuri de informaţie, concretizate prin mesaje comensurate direct sau prin documente care urmăresc fluxurile de producţie, specifice echipamentelor şi materiilor prime care prin transformări devin repere, subansambluri şi, în final, produse finite.

În al doilea rând, concordanţa se realizează prin stabilirea de puncte de preluare a mesajelor care reflectă activităţi efectuate, operaţii executate, stadii, stări ale echipamentelor. Trebuie realizat un echilibru între numărul emiţătorilor potenţiali şi capacitatea de preluare a mesajelor în vederea prelucrării.

În al treilea rând trebuie stabilite procedurile de prelucrare a mesajelor. Aceste proceduri trebuie să fie complete, în sensul luării în considerare a tuturor tipologiilor de mesaje care se constituie ca intrări pentru algoritmii de prelucrare. Procedurile de prelucrare au un nivel de

18

complexitate deosebit de ridicat, limitând elementele care introduc riscuri în derularea proceselor decizionale.

În al patrulea rând, concordanţa sistemului informaţional este obţinută din modul în care abaterile din procesul tehnologic sunt corectate prin decizii luate rapid. Este vorba de viteza de reacţie pe care o asigură managementul prin canalele informaţionale.

În al cincilea rând, concordanţa dintre sistemul informaţional şi celelalte sisteme este dezvoltată odată cu definirea unor modalităţi de culegere automată a datelor şi prin utilizarea unor algoritmi bazaţi pe eşantionarea datelor din volume foarte mari de date. Trecerea de la sistemele în care sunt înregistrate cantităţi, valori, durate, la sistemele care preiau momente de start şi de încheiere a unor activităţi sau de definire a stărilor, asigură saltul calitativ de la tratarea calitativă a comportamentului de producţie care este compania.

În al şaselea rând, concordanţa se asigură eliminând elementele subiective, dictate de tradiţionalismul, de rutina specifică unui mod învechit de tratare a informaţiei, nici ca materie primă, nici ca produs finit, nici ca purtător de valoare, ci pur şi simplu ca mesaj auxiliar, opţional în derularea proceselor, care oricum se derulează şi fără schimb de mesaje, ci numai prin schimburi de semne sau numai prin schimburi de simboluri. Abordarea modernă impune o schimbare profundă la nivelul transferului de mesaje. Mesajul ca orice fel de produs este generat într-un interval de timp, urmează o traiectorie precisă şi generează, la momente de timp date, acţiuni şi noi mesaje. Sistemul informaţional devine o componentă de sine stătătoare a companiei care se defineşte prin toate dimensiunile pe care le au toate celelalte sisteme care compun compania.

În al şaptelea rând, sistemului informaţional i se asociază costuri. Sunt costurile de definire, costurile de funcţionare. La rândul său, prin efectele pe care le generează mesajele definite în sistem generează costuri. Diferenţele de costuri dau ponderea eficienţei circulaţiei informaţiilor în companie. Apar situaţii în care costul informaţiei se stabileşte direct, o dată cu el se obţine fie nivelul de profit, fie nivelul pierderilor. Informaţia din companie are natură economică asemenea celorlalte sisteme care prin consumuri generează, pe de o parte, cheltuieli şi pe de altă parte, prin modul de valorificare a produselor sau serviciilor, generează profit, dacă piaţa recunoaşte aceste rezultate sau pierderi. A privi sistemul informaţional într-o

19

altă abordare, înseamnă a crea o componentă la nivelul companiei care frânează evoluţia acestuia, distrugând-o.

În al optulea rând, concordanţa sistemului informaţional este o problemă de timp. Concordanţa se dobândeşte, se menţine, dar se şi pierde cu mare uşurinţă atunci când apare un decalaj între dinamica proceselor de producţie şi dinamica mesajelor care circulă în companie. Noilor moduri de organizare a producţiei trebuie să le corespundă modalităţi adecvate de culegere, prelucrare şi transmitere a informaţiei.

Concordanţa are un caracter global şi include în aceeaşi măsură şi cu aceeaşi intensitate toate cele cinci sisteme ale companiei. Ea este o caracteristică pentru a asigura normalitatea derulării tuturor proceselor din companie, începând cu planificarea, continuând cu aprovizionarea, producţia, desfacerea şi încheind cu reflectarea în plan financiar - contabil a tuturor transformărilor şi transferului, respectiv, cu toate deciziile echipei manageriale. Absenţa concordanţei, mai ales în plan informaţional, creează decalaje care presupun luarea de decizii bazate pe un minus de informaţie. În plus, scăderea acurateţei informaţiei transformă seturile de mesaje în mesaje incomplete, cu efecte directe asupra creşterii ponderii deciziilor bazate pe incertitudine. Devin frecvente situaţiile în care decizii de rutină se transformă în decizii luate la nivelurile superioare ale echipei manageriale, în concordanţă cu capacitatea de asumare a riscurilor generate de incompletitudinea informaţiei furnizate de un sistem informaţional neconcordant.

Din aceste considerent, auditarea unui sistem informatic dezvoltat pentru o organizaţie va avea în vedere existenţa concordanţei între subsisteme. În final, pentru certificarea sistemului informatic, trebuie ca nivelurile planificate ale caracteristicilor de calitate să fie mai mari sau egale decât nivelurile reale. În activitatea de informatică aplicată trebuie parcurse pe lângă etapele ciclului de dezvoltare, o serie de activităţi care au menirea de a stabili că produsul program, baza de date, interfaţa web sau oricare alte componente, este exact ceea ce trebuie.

Aceste activităţi au menirea de a stabili că există concordanţă între ceea ce s-a planificat şi produsul finit existent.

Faptul că activităţile sunt derulate de persoane aparţinând unor organisme independente, reprezintă garanţia că rapoartele consemnează diferenţele reale dintre proiect şi produs.

20

Auditarea reprezintă o activitate deosebit de importantă pentru companiile care realizează sisteme informatice, întrucât rezultatele procesului de auditare se constituie în bază pentru fundamentarea deciziilor pe termen lung privind politicile companiei.

Certificarea echipelor, companiilor, persoanelor, produselor informatice, evidenţiază capacitatea de a derula procese, tranzacţii, capacitate care trebuie să se manifeste ori de câte ori se dezvoltă un produs, prin respectarea standardelor, prin utilizarea tehnicilor, modelelor şi instrumentelor adecvate.

Toate elementele converg spre obţinerea de produse şi servicii de calitate.

Există o importantă deosebire între ceea ce se doreşte şi ceea ce se efectuează, se obţine şi se utilizează în activitatea economică de zi cu zi.

Garantarea calităţii este un concept de mare importanţă, complexitate şi dinamică. Existenţa unei mărci este fundamentată pe existenţa unei conduite, pe definirea de proceduri restrictive, calificarea continuă a persoanelor pe existenţa unui management suficient al calităţii şi pe formarea conştiinţei orientate spre calitate.

Indiferent de contextul în care o companie ce dezvoltă sisteme informatice îşi desfăşoară activitatea, societatea informaţională, în stadiul arătat, impune ca dezvoltarea de sisteme informatice să genereze un efect de antrenare multiplă, în direcţia pozitivă, a evoluţiei gradului de satisfacţie înregistrat de utilizatorul final.

21

4. OBIECTUL AUDITULUI PENTRU SISTEME INFORMATICE

Auditul sistemelor informatice reprezintă activitatea de colectare şi evaluare a unor probe pentru a determina dacă sistemul informatic este securizat, menţine integritatea datelor prelucrate şi stocate, permite atingerea obiectivelor strategice ale întreprinderii şi utilizează eficient resursele informaţionale.

În cadrul unei misiuni de audit a sistemului informatic cele mai frecvente operaţii sunt verificările, evaluările şi testările mijloacelor informaţionale, astfel[BRÂN04]:

- identificarea şi evaluarea riscurilor din sistem; - evaluarea şi testarea controlului din sistem; - verificarea şi evaluarea fizică a mediului informaţional; - verificarea şi evaluarea administrării sistemului informatic; - verificarea şi evaluarea aplicaţilor informatice; - verificarea şi evaluarea securităţii reţelelor de calculatoare; - verificarea şi evaluarea planurilor şi procedurilor de recuperare în

caz de dezastre şi continuare a activităţii; - testarea integrităţii datelor.

Auditul informatic reprezintă o formă esenţială prin care se verifică dacă un SI îşi atinge obiectivul pentru care a fost elaborată. Standardele definesc clar domeniul, activităţile, etapele, conţinutul auditării şi formele de finalizare. Respectând cerinţele standardelor, rezultatul procesului de auditare informatică este eliberat de riscurile contestării. Auditul informatic reprezintă un domeniu cuprinzător în care sunt incluse toate activităţile de auditare pentru : specificaţii, proiecte, software, baze de date, procesele specifice ciclului de viaţă ale unui program, ale unei aplicaţii informatice, ale unui sistem informatic pentru management şi ale unui portal de maximă complexitate, asociat unei organizaţii virtuale.

În domeniul informatic există mai multe direcţii de dezvoltare a auditului.

22

Auditarea software constă în activităţi prin care se evidenţiază gradul de concordanţă dintre specificaţii şi programul elaborat. Auditul software dă măsura siguranţei pe care trebuie să o aibă utilizatorul de programe atunci când obţine rezultate. Siguranţa se referă la corectitudinea şi completitudinea rezultatelor finale atunci când datele de intrare sunt, de asemenea, corecte şi complete.

Auditul bazelor de date, este un domeniu de maximă complexitate având în vedere că, de regulă, lucrul cu bazele de date presupune atât datele ca atare însoţite de relaţiile create între ele, cât şi programele cu care datele se gestionează. De aceea se impune efectuarea unei reparări.

Auditul datelor vizează definirea acelor elemente prin care se stabileşte măsura în care datele stocate îndeplinesc cerinţele de calitate: corectitudine, completitudine, omogenitate, comprehensibilitate, temporalitate, reproductibilitate. Pentru fiecare caracteristică există o metrică elaborată, iar auditorul de date trebuie să evalueze nivelul atins de caracteristică, pentru setul de date supus auditării. În final, auditorul de date certifică faptul că datele stocate în baze de date constituie intrări valabile pentru a obţine rezultate corecte.

În cazul auditării riscului de gestiune a datelor stocate în baze de date se verifică dacă:

- programele referă corect câmpurile cu date stocate; - operaţiile de prelucrare sunt cele din specificaţii; - agregările, sortările, evaluările de expresii de extragere a

subseturilor de date sunt în concordanţă cu specificaţiile de obţinere a rezultatelor ca structură, dimensiune şi conţinut.

Auditul sistemelor informatice evaluează riscurile unui mediu informatic sau ale unei aplicaţii informatice, ca de exemplu calculul salariilor sau facturarea. Aceste misiuni se realizează alegând, împreună cu clientul, procesul de evaluare.

Auditul informatic se poate referi la evaluarea riscurilor informatice ale securităţii fizice, securitatea logică, managementul schimbărilor, planul de asistenţă etc. În cazul general, auditul informatic se referă la un ansamblu de procese informatice pentru a răspunde la o cerere precisă a clientului. De exemplu, aprecierea disponibilităţii informaţiilor şi a sistemului. În acest caz se controlează care dintre procesele informatice răspund cel mai eficient la o asemenea cerere. În cazul disponibilităţii, de exemplu, securitatea fizică şi planul de continuitate.

23

Auditul informatic poate, de asemenea, să evalueze aspecte strategice sau referitoare la calitatea sistemelor informatice. De exemplu, să verifice dacă sistemul informatic al întreprinderii răspunde în mod eficient la nevoile funcţiilor serviciului.

Auditul mediului informatic se execută pentru a evalua riscurile sistemelor informatice necesare funcţionării aplicaţiilor. De exemplu: securitatea fizică, securitatea logică, securitatea reţelelor, plan de salvare. În urma auditării, se întocmeşte un raport în care sunt prezentate punctele slabe, nivelul de risc al acestora şi măsurile corective propuse.

Analistul informatic are la dispoziţie numeroase tehnici şi metode pe care le adaptează contextului. Într-un fel este auditat un program de calcul statistic sau de optimizare şi altfel este auditată o aplicaţie care utilizează o bază de date. Pentru un sistem informatic complex există metode adecvate de auditare, iar pentru aplicaţiile web accentul auditării este pus pe gradul de satisfacţie a grupului ţintă. Aplicaţiile mobile au fundamente de auditare în care accentul este pus pe asigurarea continuităţii, compatibilităţii, accesibilităţii rapide la resurse şi, mai ales, asupra nivelului atins de asigurarea securităţii fluxurilor din întregul sistem.

De aceea, în cadrul procesului de audit informatic, planificarea şi definirea metodei de audit este esenţială. Alegerea unei metode neadecvate conduce la utilizarea de instrumente neadecvate, iar rezultatele auditului au caracter speculativ.

Alegerea metodei presupune obţinerea unor informaţii privind contextul în care se derulează procesele legate de produsul software, de aplicaţia informatică sau de sistemul informatic, obiecte ale auditării.

Auditul este, prin complexitatea sa, o activitate în care sunt luate în analiză legăturile, implicaţiile pe care le generează produsul software, aplicaţia informatică sau sistemul informatic între dezvoltator - compania de software şi utilizator. Raporturile trebuie privite din punct de vedere tehnic, financiar şi juridic. Aspectul tehnic priveşte date de interior, algoritmi, rezultate, resurse folosite. Aspectul financiar vizează costul estimat al produsului software, aplicaţie, sistem informatic şi costul efectiv, modul în care s-au efectuat plăţile. Caracterul juridic al abordării vizează obligaţiile contractuale şi legislaţia din domeniul informatic.

Toate aceste elemente conduc la stabilirea unor proceduri preliminare prin care sunt definite direcţiile de analiză, gradul de semnificaţie pe care procesul de audit informatic îl oferă şi riscurile ca unele

24

concluzii să fie infirmate de practica derulării proceselor de utilizare curentă a produsului software, a aplicaţiei informatice sau a sistemului informatic în integralitatea lui.

Pentru a realiza auditul informatic se defineşte planul de audit general şi programul de audit. Structura planului şi definirea programului sunt standard, presupunând parcurgerea unor paşi obligatorii. Specificitatea produsului software, a aplicaţiei informatice sau a sistemului informatic şi complexitatea acestora, determină efectuarea unor detalieri care diferă de la un plan general la altul, respectiv de la un program de audit informatic la altul. Sarcinile care se includ în plan, eşalonarea etapelor din program au elemente de variabilitate legate strict de structura şi de diversitatea produselor informatice analizate.

Standardele de auditare includ suficiente elemente astfel încât planul general şi programul de audit să fie riguroase, fără ambiguităţi şi, mai ales, operaţionale. Înainte de a se trece la auditul informatic propriu-zis, datorită eforturilor ridicate de derulare şi, mai ales, datorită riscurilor ca reproductibilitatea procesului de audit să fie afectată chiar de schimbările care au loc în produsele informatice auditate, trebuie efectuate teste asupra mecanismelor de control şi a mecanismelor de testare pe teste sursă, pe specificaţii, pe diagrame, pe documentaţii, pe structuri de rezultate. Pentru a obţine o reducere a nivelului estimat pentru riscul erorilor de analiză/control a produsului informatic în procesul de audit, printr-un proces iterativ se procedează la efectuarea de corecţii asupra modalităţilor în care se includ procedee tehnice, metode, modele de analiză/control a produselor informatice. Procesul iterativ se întrerupe atunci când estimarea probabilităţii ca rezultatele auditării informatice să fie afectate de erori a atins un prag acceptabil.

Auditul propriu-zis include proceduri analitice, teste, prin care se evidenţiază diferenţele dintre ceea ce s-a planificat a se realiza şi ceea ce s-a realizat.

Procedurile analitice au la bază contractele încheiate între părţi, minutele care detaliază obiective, sarcinile ce revin partenerilor, specificaţiile. Auditorul tehnic trebuie să ierarhizeze informaţiile astfel încât să identifice punctele cheie care definesc procesul de analiză, proiectare, dezvoltare, testare, implementare a produsului informatic, fie că este vorba de un simplu program, fie că este vorba de o aplicaţie informatică desktop sau în reţea, fie că este vorba de un sistem informatic care vizează întreaga activitate a unei organizaţii.

25

Toate procedurile analitice şi textele de detaliere aplicate modulelor, programelor şi sistemelor de programe, au menirea de a evidenţia comportamentul, pas cu pas, a secvenţelor de program. În cazul în care auditorul informatic are la bază pregătire de programator, ştie să aleagă din multitudinea de proceduri şi texte cu caracter analitic, pe acelea care oferă informaţia reprezentativă privind produsul software auditat, fie că este vorba de un modul, fie că este vorba de un sistem complex. Efortul de auditare este ridicat indiferent de complexitatea produsului auditat.

Auditul se încheie cu raport care are la bază o serie de verificări ale intercondiţionărilor dintre module, dintre programe, respectiv dintre subsistemele sistemului informatic, pentru momentul t, considerat bază.

Se verifică modul de producere a evenimentelor care sunt concretizate prin succesiuni de prelucrări, corespunzătoare momentului t + 1. În acest fel, produsul informatic, proiectat pentru derularea unor seturi de prelucrări, este analizat ţinând cont tocmai de succesiunea prelucrărilor.

Auditul informatic are la bază înregistrări privind structura software, structura bazei de date, înregistrări ale lungimilor, volumului, complexităţii şi înregistrări complete asupra comportamentului în timpul execuţiei.

În cazul în care există seturi de date cu care au fost testate produse informatice din aceeaşi clasă cu produsul auditat acum, se colectează serii de date privind comportamentul produsului pentru a fi comparat cu produsele deja existente. Când nu există date, sunt generate şi testarea produsului se realizează simultan cu produse din aceeaşi clasă, tocmai pentru a efectua analize şi pentru a compara produsele informatice. Seriile de date se constituie în baze de redactare a raportului de auditare.

De cele mai multe ori, auditul informatic este cerut ca soluţie finală, imparţială, pentru a justifica ipotezele unei părţi contractante, fie că este vorba de cumpărător de software, fie că este vorba de beneficiar, când aceştia cred în dreptatea lor absolută.

În general, auditul este descris ca Examinarea independentă a înregistrărilor şi a altor informaţii în scopul formării unei opinii referitoare la integritatea sistemului controalelor şi îmbunătăţirea controalelor recomandate pentru limitarea riscurilor. Definiţia conţine termeni semnificativi ca [HINS05]:

- examinare; auditiarea implică culegerea şi evaluarea informaţiilor factuale din surse variate; este important ca rezultatele procesului de auditare (raportul primar de audit care conţine recomandări pentru

26

îmbunătăţirea controalelor) să fie urmărit până la sursele de informaţii valide;

- independent; auditorii nu sunt implicaţi direct în operaţii sau în managementul funcţiei care se auditează; subordonarea lor trebuie să le asigure exprimarea liberă a opiniilor;

- înregistrări şi alte informaţii; termenii includ ceea ce adeseori sunt numite “inregistrări de audit”; auditorii trebuie să se refere la informaţii privind procesul afacerii şi sistemele aflate în revizii aşa cum sunt formele complete de intrări de date, rapoarte generate de sistem şi, bineînţeles, personalul implicat în desfăşurarea sau conducerea proceselor afacerii auditate;

- opinie; auditorii furnizează atât fapte obiective cât şi opinii subiective pe o situaţie dată; deşi subiective, opiniile lor sunt bazate pe interpretarea faptelor şi sunt deschise discuţiilor; se poate să nu se fie de accord cu aceste opinii, dar trebuie purtată o discuţie completă şi sinceră;

- integritate; termenul integritate include completitudine, acurateţe şi credibilitate; un control al unui sistem care este numai parţial efectiv poate fi mai bun decât nimic, sau poate da un sens fals de securitate; auditorul va lua în considerare ambele căi;

- recomandare; auditorii generează recomandări, dar nu au autoritatea nici să implementeze schimbările sugerate, nici să impună managementului să facă schimbări; îmbunătăţirile se obţin numai printr-un proces de explicare, justificare şi persuasiune, explicând riscurile reprezentate de punctele slabe constatate în SI în urma auditării, justificând nevoia de schimbare în cadrul procesului şi/sau sistemului şi sugerând managementului necesitatea alocării unor resurse şi luarea de măsuri pentru gestionarea riscurilor;

- îmbunătăţirea controalelor; îmbunătăţirea sistemului de control înseamnă, în general, adăugarea controalelor care lipsesc; sunt foarte rare cazurile în care auditorii pot recomanda eliminarea unor controale, în general, din cauză că ele sunt ineficiente, distrugătoare sau costisitoare;

- limite; ricurile şi erorile pot fi reduse, dar nu pot fi complet eliminate; o bună activitate implică minimizarea riscurilor cu cheltuieli eficiente şi pregătirea pentru acţiune în cel mai rău caz posibil care s-ar putea produce (planificare pentru acţiuni în caz de dezastre);

- risc; posibilitatea ca ceva să se desfăşoare într-o direcţie nefavorabilă; formal, riscul este posibilitatea combinării ameninţărilor

27

cauzate fie de cineva cu intenţii rele, fie din neglijenţă sau incompetenţă, acţionând asupra vulnerabilităţilor sistemului; vulnerabilităţile sunt punctele slabe ale sistemului care apar, în general, din cauza lipsei controalelor în sisteme de calcul şi în proceduri de operare; manifestarea riscurilor poate genera, în anumite SI, rezultate catastrofale.

Din alt punct de vedere auditul informatic este mecanismul de examinare a eficienţei organizaţiilor, sistemelor, proceselor riscurilor şi controalelor. Auditurile dau posibilitatea managementului să:

- descopere ceea ce se întâmplă în realitate la un moment dat; - depisteze problemee potenţiale înainte de a fi prea târziu pentru

remediere; - evalueze în mod obiectiv situaţia afacerii; - accepte realitatea şi să ia, în cunoştiinţă de cauză, decizii chiar

dacă sunt dificile; - implementeze acţiuni corective, schimbări şi îmbunătăţiri acolo

unde este necesar. Auditul nu se referă numai la conformitate. Multe audituri includ un

element de control privind conformitatea cu politica/standardele/procedurile interne ale companiei sau cu legi, reguli şi termeni contractuali externi, dar conformitatea este activitatea zilnică a managementului. Auditorii experimentaţi controlează dacă procesele de management pentru realizarea şi evaluarea conformităţii sunt eficiente, care reguli sunt potrivite şi suficiente pentru SI auditat. Auditorii sesizează mai mult absenţa conformităţii şi nu atât de mult căutarea simptomelor problemelor în adâncime.

Organizaţiile de audit în SI au căi diferite de desfăşurare a auditărilor, iar auditorii au metodele lor preferate de lucru.

Amploarea unui audit informatic presupune realizarea în mod normal, a unei balanţe între cantitate, referitor la numărul subsistemelor din compunerea unui SI care se auditează şi calitate, însemnând nivelul de detaliere la care se auditează subsistemele selectate.

Resursele auditului SI sunt direcţionate, în primul rând, către zonele cu grad ridicat de risc. Aplicaţiile utilizate în zonele critice ale afacerii se recomandă să fie revizuite anual. Zonele cu nivel de risc mai scăzut pot fi auditate la intervale mai mari, în general odată la trei ani, imediat după un incident sau când se consideră necesar de către echipa managerială.

28

Principalele tipuri de audit informatic sunt [HINS05]: - auditul sistemului operaţional de calcul; revizia controalelor

sistemelor operaţionale de calcul şi reţelelor, la diferite niveluri; de exemplu, reţea, sistem de operare, software de aplicaţie, baze de date, controale logice/procedurale, controale preventive/detective/corective etc;

- auditul instalaţiilor IT; include aspecte cum sunt securitatea fizică, controalele mediului de lucru, sistemele de management şi echipamentele IT;

- auditul sistemelor aflate în dezvoltare; acoperă unul sau ambele aspecte: (1) controalele managementului proiectului şi (2) specificaţiile, dezvoltarea, testarea, implementarea şi operarea controalelor tehnice şi procedurale, incluzând controalele securităţii tehnice şi controalele referitoare la procesul afacerii;

- auditul managementului IT; include: revizia organizaţiei, structurii, strategiei, planificării muncii, planificării resurselor, stabilirii bugetului, controlul costurilor etc.; în unele cazuri, aceste aspecte pot fi auditate de către auditorii financiari şi operaţionali, lăsând auditorilor informaticieni mai mult aspectele tehnologice;

- auditul procesului IT; revederea proceselor care au loc în cadrul IT cum sunt dezvoltarea aplicaţiei, testarea, implementarea, operaţiile, mentenanţa, gestionarea incidentelor;

- auditul managementului schimbărilor; revizia planificării şi controlului schimbărilor la sisteme, reţele, aplicaţii, procese, facilitaţi etc., incluzând managementul configuraţiei, controlul codului de la dezvoltare, prin testare, la producţie şi managementul schimbărilor produse în organizaţie ca rezultat al ICT;

- auditul controlului şi securităţii informaţiilor; revizia controalelor referitoare la confidenţialitatea, integritatea şi disponibilitatea sistemelor şi datelor;

- auditul conformităţii cu legalitatea; copyright, conformitate cu legislaţia, protecţia datelor personale;

- auditul accidentelor dezastruoase/planificării continuităţii afacerii/refacerii după dezastre; reviziile măsurilor propuse pentru restaurarea după un dezastru care afectează sistemul şi evaluarea modului în care organizaţia abordează managementul riscurilor;

- auditul strategiei IT; revizia aspectelor variate ale strategiei IT, viziune şi planuri, inclusiv relaţiile cu alte strategii, viziuni şi planuri.

29

Auditarea sistemelor informatice aflate în dezvoltare este considerat cel mai dificil tip de audit informatic. În majoritatea cazurilor, proiectele auditate implică sume mari de bani, iar practica demonstrează că în domeniul IT, un management corespunzător al proiectelor este mai mult o excepţie decât o regulă [HINS05]. Un auditor experimentat în domeniul SI depistează simptomele unui dezastru iminent privind evoluţia unui proiect, dar nu poate să oprească un proiect aflat în dezvoltare.

Auditul sistemelor informatice nu este un audit financiar. Nu se testează date din punct de vedere al formularelor financiare pentru a determina completitudinea, drepturi şi obligaţii, evaluări sau alocări, prezentări sau divulgări.

Auditul sistemelor informatice implică: - executarea unei serii de teste pentru a se asigura că există un

control adecvat asupra sistemului informatic; - controale generale; - controalele aplicaţiilor.

Controale generale presupun: - controale care afectează mediul de procesare al calculatoarelor

incluzând: o managementul resurselor computerelor; o copii de salvare şi arhivare; o controlul schimbărilor în programul computerului; o controlul sistemului de operare.

Controale ale aplicaţiilor: - specific pentru o aplicaţie:

o acceptarea datelor autorizate; o procesarea este completă şi corectă; o output-urile sunt corecte şi credibile.

Controalele generale formează baza controalelor aplicaţiilor. Auditul informatic trebuie astfel planificat încât să se obţină

rezultatele pe care le urmăresc atât auditorul cât şi organizaţia auditată. În planificarea auditului, auditorul trebuie să înţeleagă sistemul şi să planifice auditul. Auditorul trebuie să înţeleagă complexitatea sistemului informatic şi, de asemenea, modul în care mediul în care evoluează sistemul informatic influenţează evaluarea şi controlul riscurilor.

Auditorul trebuie să înceapă cu intervievarea echipei manageriale şi a personalului din sistemul informatic pentru a culege informaţiile necesare

30

desfăşurării auditului. Auditorul trebuie să examineze activităţile care se desfăşoară în cadrul funcţional al sistemului informatic, să revadă documentele elaborate de auditările anterioare şi să revadă documentaţia sistemului informatic.

Este necesar ca auditorul să revadă informaţiile colectate astfel încât să capete o bună înţelegere a tuturor controalelor care există în cadrul organizaţiei.

Auditul este o activitate complexă, realizată de specialişti cu înaltă calificare şi experienţă în domeniu. Auditul nu este o activitate de control. Orice activitate de control presupune existenţa unui sistem în funcţiune. Controlul are menirea de a stabili dacă au fost respectate sau nu procedurile de desfăşurare a activităţilor, dacă s-au înregistrat plusuri sau minusuri. Se stabilesc diferenţele dintre nivelurile reale şi cele scriptice şi se propun măsuri de recuperare a pierderilor sau de valorificare a plusurilor. Activitatea de control are caracter repetat, se execută la anumite intervale. Se constată fie că sistemul funcţionează corect/normal, fie că există abateri în plus sau în minus şi apar sancţiuni şi măsuri de remediere, respectiv de valorificare.

Auditul nu este o activitate de expertizare. O expertiză presupune două părţi adverse, cel puţin, şi mai multe cauze care au generat un eveniment. Expertiza se execută de specialişti, numiţi experţi, cu vastă experienţă în domeniul evenimentelor. Expertiza are menirea de a stabili cauze, de a demonstra legătura dintre cauze şi efecte. Expertiza se concretizează printr-un raport care are menirea de a clarifica, fără a mai lăsa loc interpretărilor, toate aspectele definite de cei care au solicitat-o. Se fac expertize la accidente, la modul în care au fost realizate construcţii. Sunt expertize judiciare, sunt expertize contabile, sunt expertize tehnice. Expertizele se repetă. Există superexpertize aşa cum există şi supracontroale.

Ideea de bază este de a stabili un mod real în care s-a derulat un eveniment, care au fost cauzele care au favorizat o anumită direcţie. Se stabilesc vinovaţi atunci când controlul, respectiv expertiza, o cer.

Auditul presupune un produs nou care se lansează în uz curent. Specialiştii care asigură auditul sunt auditori. Activitatea de auditare are menirea de a analiza un produs înainte de a fi lansat în utilizare curentă. Auditarea se efectuează de către o echipă independentă care se bucură de credibilitate. Credibilitatea echipei de auditori este transferată, prin

31

intermediul raportului, asupra produsului auditat. La livrarea unui produs auditat, prin specificarea echipei de auditare, cumpărătorul/utilizatorul capătă încrederea că produsul achiziţionat are, în realitate, parametrii înscrişi în documentaţie, la nivelurile specificate. De asemenea, cumpărătorul/utilizatorul primeşte toate informaţiile legate de avantaje, performanţe, dar, în egală măsură, primeşte şi informaţiile privind riscuri şi efecte secundare, negative sau pozitive, rezultate din construcţia produsului.

Când este finalizat un sistem informatic există: - documentaţia privind contractul pe baza căruia se construieşte

sistemul, fondurile disponibile, duratele de timp rezervate; documentaţia cuprinde obiectivul sistemului informatic, sarcinile ce revin echipei de realizatori şi sarcinile care revin beneficiarilor;

- documentaţia tehnică în care este definită calitatea planificată, exigenţele exprimate de beneficiar şi modul în care se efectuează testarea întregului sistem;

- specificaţiile sistemului informatic şi minutele încheiate între realizator şi beneficiar care au reiterat acele aspecte necesare satisfacerii cerinţelor beneficiarilor pentru a atinge obiectivul propus la încheierea contractului; se are în vedere rolul activ al echipei de realizatori pentru a orienta pe beneficiar spre soluţii care au acoperire în plan informatic, platforme şi arhitecturi moderne;

- setul de date de test discutat şi avizat de beneficiarul sistemului informatic, inclusiv indicaţiile pentru generarea de extensii de date de test atât de către realizatorul sistemului, cât şi de către beneficiar, fără ca aceste extensii să depăşească structurile definite în contractul pe baza căruia se dezvoltă investiţia;

- setul de înregistrări privind comportamentul sistemului pe parcursul efectuării testelor; sunt incluse şi procedurile, algoritmii şi rezultatele intermediare ale indicatorilor de calitate aşa cum au rezultat pentru diferitele componente ale sistemului informatic;

- evidenţele de distribuire a sarcinilor pe membrii echipei de realizatori, rezultând cu claritate ce module a realizat un anumit programator, ce componente a testat un specialist în evaluarea subsistemelor, ce date au fost încărcate de fiecare operator în parte; aceste evidenţe conţin şi termenele şi consumurile de resurse pentru a stabili corelaţia dintre calitate şi cost, dintre consumurile de resurse şi complexitatea componentelor realizate;

32

- documentaţia completă de realizare a produsului, scheme, diagrame, descrieri ale modulelor, ale procedurilor, ale variabilelor, ale rezultatelor, ale fluxurilor, ale structurilor de date; sunt date mesajele oferite operatorilor şi semnificaţia fiecăruia; sunt indicate valorile implicite şi combinaţiile de opţiuni care pun în operă sistemul de programare; se definesc condiţiile minimale care trebuie asigurate pentru ca sistemul să fie operaţional;

- rapoartele de predare–primire pentru asamblarea componentelor; - rapoartele de testare ale subsistemelor de programe folosind

datele de test convenite cu beneficiarul şi încărcate în bazele de date de test; rapoartele de testare ale întregului sistem;

- rapoartele grupurilor de lucru pe parcursul derulării procesului de dezvoltare, urmărindu-se fiecare etapă a ciclului de realizare;

- fişierele cu variantele de module, de biblioteci de obiecte, însoţite de rapoartele de acceptare şi de unele comentarii privind trecerea de la o variantă la alta;

- documentaţia de prezentare şi de instalare precum şi totalitatea software şi baze de date pe suport pentru a fi preluate ca produse portabile, la beneficiar.

Obiectivul auditului pentru un sistem informatic ia în analiză totalitatea elementelor pentru a proba dacă produsul finit – sistemul informatic al companiei – răspunde cerinţelor formulate în contractul în baza căruia s-a efectuat investiţia.

Pentru a avea un audit de calitate trebuie îndeplinite următoarele condiţii:

- echipa de auditare trebuie să primească totalitatea informaţiilor care să constituie intrări ale procesului de auditare;

- tehnicile şi metodele de auditare trebuie să fie utilizate corect, folosind tot ceea ce este necesar pentru a obţine rezultate reale, neafectate de factorii perturbatori sau de abordări parţiale;

- să existe clar delimitat ceea ce trebuie să realizeze sistemul informatic şi ceea ce realizează efectiv; auditarea scoate în evidenţă diferenţele, efectuând şi unele cuantificări, pentru a reieşi mai precis pentru fiecare cerinţă în parte, ponderea a ceea ce lipseşte sau ponderea a ceea ce este în plus.

Pornind de la obiectivul auditării, de la importanţa pe care o prezintă rezultatul auditării, echipa de specialişti dimensionează efortul care trebuie

33

depus de la întocmirea planului de auditare, ca atare, şi până la elaborarea raportului de auditare.

La desfăşurarea obiectivului auditării trebuie să fie introduse acele elemente care subliniază încrederea pe care utilizatorul sistemului informatic trebuie să o aibă pe durata exploatării. Raportul de auditare trebuie să facă dovada în mod convingător că achiziţionând un produs sau utilizând un sistem informatic rezultat al unui proces investiţional, utilizatorul va beneficia de servicii de calitatea dorită.

La fel ca în cazul unei operaţii chirurgicale, în care viaţa pacientului este mai presus de orice, în auditul sistemelor informatice nu există o diferenţiere în profunzimea cu care este abordat procesul de auditare. Dacă obiectivul definit este cu un enunţ comun precum stabilirea concordanţei dintre produsul dorit şi cel real în vederea consolidării încrederii în utilizarea produsului real, el trebuie interpretat prin prisma rigurozităţii şi profesionalismului cu care sunt parcurse toate etapele. Este cunoscut faptul că auditarea unui produs, de complexitatea sistemelor informatice, reprezintă o investiţie morală, a cărei pierdere nu se mai recuperează niciodată. Companii renumite de audit au dispărut atunci când rezultatul auditului a fost unul, iar realitatea privind produsul auditat a fost alta. Auditul nu are menirea de a stabili încrederea într-un sistem informatic. De exemplu, un sistem este livrat, utilizatorul îşi exprimă nemulţumirea, iar după un timp doreşte să recupereze pe cale judiciară daune. Atunci producătorul cere auditarea sistemului informatic pentru a restabili că produsul e bun, altele fiind cauzele care generează nemulţumirea beneficiarului. Aceste aspecte revin expertizelor tehnice. Auditul transferă credibilitate unui produs nou. Obiectivul clar al auditului este de a se concentra întreaga activitate, prin analiză, pe aspecte calitative şi cantitative, din care rezultă concordanţa dintre produsul planificat a fi realizat şi produsul pe cale de a fi livrat. Auditul sistemului informatic este un proces extrem de complex, iar echipa care realizează un astfel de audit trebuie să aibă o diversitate de specialişti, iar aceştia, la rândul lor, trebuie să aibă o bogată experienţă profesională şi vaste cunoştiinţe teoretice. Un sistem informatic nu se auditează de persoane care nu stăpânesc domeniul afectat etapei din procesul de auditare. Aşa cum în dezvoltarea sistemului informatic există un ciclu de dezvoltare, divizat în etape, tot aşa există etape ale ciclului de auditare. Fiecare etapă reprezintă un sistem de diviziune a muncii, iar comunicarea este un factor esenţial. Este vorba de comunicarea între membrii echipei de auditare, respectiv, comunicarea între auditori. De

34

asemenea, auditorii trebuie să comunice, pentru a clarifica unele aspecte, cu echipa care a realizat sistemul informatic.

În domeniul sistemelor informatice, categoria importantă o constituie sistemele informatice de management, a căror auditare prezintă anumite paricularităţi.

Sistemele informatice pentru management sunt construcţii deosebit de complexe care au ca obiectiv ridicarea la cote maxime a procesului de informatizare la nivelul organizaţiilor.

Dacă o organizaţie este caracterizată prin funcţiile F1, F2,...Fk, structura sistemului informatic pentru management include k subsisteme, SS1, SS2,...SSk, pentru fiecare funcţie un subsistem. Întregul sistem informatic este proiectat sub forma unor subsisteme cu stabilirea legăturilor dintre ele.

Abordarea sistemelor pentru management presupune un fundament teoretic şi practic deosebit de solid şi acceptarea unui demers de anvergură pe o perioadă de doi-cinci ani. Tehnicile şi metodele de analiză şi proiectare au la bază o cunoaştere în detaliu a stadiului actual atins de procesul de informatizare la nivelul organizaţiei.

Există sisteme puternice de gestiune a bazelor de date, de soluţionare a problemelor definite în cadrul fiecărei funcţii din organizaţie. Trecerea la dezvoltarea unui sistem informatic pentru management trebuie să ia în considerare existenţa acestor componente. În acelaşi fel se pune problema şi în cazul în care se doreşte dezvoltarea de sisteme de gestiune a documentelor, din moment ce există deja astfel de sisteme livrate la cheie. A spune acum că o organizaţie are particularităţile ce impun definirea unei structuri proprii de sistem informatic înseamnă a considera că echipele care au proiectat sisteme care se aplică în foarte multe ţări nu sunt competente, iar organizaţia este atât de specială încât nu se încadrează în nici o categorie. Abordarea este nu numai absurdă prin simplismul ei, dar denotă un nivel de ignoranţă greu de acceptat din punctul de vedere al nivelului actual al informaticii.

Problemele de audit pentru un sistem informatic de management au o altă anvergură faţă de celelalte entităţi, produsul program sau aplicaţia informatică. Literatura de specialitate include numeroase lucrări care se adresează celor care elaborează sisteme informatice orientate pe gestiune financiar-contabilă.

35

Auditul acestor sisteme este o problemă extrem de actuală pentru că: - sistemele informatice de gestiune contabilă neauditate conduc la

efectuarea de operaţii neautorizate; - sunt situaţii în care nu există concordanţă între teoria contabilităţii

şi procedurile care se apelează pentru a efectua prelucrări; - în faza de analiză sunt definite incomplet cerinţele care corespund

laturilor calitative şi cantitative definite prin relaţia între conturi, prin restricţii privind efectuarea de operaţii şi prin proporţii impuse unor niveluri cu care se efectuează debitările sau creditările;

- priorităţilor de efectuare a operaţiilor existente în teoria contabilă trebuie să le corespundă secvenţe de testare care să asigure concordanţa între listele priorităţilor existente în teoria contabilă şi listele generate prin procesele de prelucrare prin programe;

- validările datelor capătă o altă semnificaţie, fiind legate nu numai de apartenenţa la un anumit domeniu de variaţie, ci fiind dependente de context, întrucât operaţiunile contabile sunt definite în cadrul unui anumit context;

- interfeţele acestor sisteme trebuie să fie orientate spre o abordare a proceselor în timp real, întrucât numeroase operaţii se derulează prin sistemul e-banking, e-commerce; operatorii trebuie să lucreze în regim responsabilizat cu înregistrarea operaţiei într-o structură impusă din care să nu lipsească momentul efectuării operaţiei şi elementele de identificare a operatorului;

- între sistemul de restricţii de acces la efectuarea de operaţii în baza de date şi cerinţele teoriei şi practicii contabile trebuie să existe o concordanţă perfectă; trebuie să existe persoane care au acces la consultarea întregii baze de date; trebuie să existe alte persoane care au acces la consultarea unor părţi din baza de date, sunt alte persoane din organizaţie care au drept de a consulta numai operaţiile care privesc activitatea lor; lista persoanelor care operează pe baza de date se defineşte aşa încât, pe măsura creşterii importanţei operaţiei în baza de date, numărul şi funcţia în organizaţie se definesc cu un nivel de exigenţă sporită, regulile impuse au menirea de a ţine sub control totalitatea operaţiilor pe câmpurile bazei de date;

- sistemul informatic de gestiune financiar-contabilă se proiectează incluzând numeroase chei de control care să evidenţieze frecvenţe ale unor operaţiuni, apropierile de limitele domeniilor de variaţie, astfel încât să se ia rapid deciziile adecvate;

- la proiectare şi la realizare se definesc situaţiile de blocare pentru a semnaliza tentativele de efectuare a operaţiilor interzise;

36

- aceste sisteme sunt organizate ca structuri ierarhice, cu intervenţii de asemenea, ierarhice, dacă s-a produs un eveniment la nivelul K+1, numai un administrator de la nivelul K al structurii arborescente intervine şi produce deblocarea sau efectuează operaţia care trebuie autorizată pentru a readuce sistemul la nivelul de operare normală; toate procesele de blocare/deblocare sunt înregistrate şi se tratează distinct.

Rezultă că un sistem informatic pentru management în general, iar un sistem informatic pentru managementul financiar contabil în special, trebuie înzestrat pe lângă funcţiile clasice de prelucrare, de extragere a rezultatelor şi de creare-actualizare a bazei de date, cu funcţii de management pentru calitatea şi protecţia sistemului informatic însuşi.

Marile probleme rezultate în activitatea curentă a implementării de software pentru contabilitate au impus dezvoltarea auditului spre această categorie de produse program.

Există o preocupare specială pentru auditul sistemelor informatice de gestiune financiar-contabilă. Şi celelalte sisteme informatice sunt auditate. Principiile auditului sistemelor informatice de gestiune sunt o particularizare a principiilor auditului pentru sistemele informatice pentru management.

Aşa cum în modul clasic de operare pe documente există riscul transferurilor de fonduri şi de mijloace care generează fraude împotriva companiei, fraude împotriva altor companii, fraude ale managerilor, fraude ale unor membri ai companiei, în cazul implementării unui sistem informatic de gestiune contabilă, toate aceste tipuri de fraude se reproduc dacă şi numai dacă sistemul nu conţine procedurile care să semnaleze efectuarea de operaţii neconsistente în raport cu criterii precis stabilite.

În primul rând, legile definesc situaţiile în care o persoană nu are drept să ia un credit.

Sunt date reguli extrem de precise în a defini un creditor ca fiind rău-platnic. Sistemul informatic dintr-o bancă trebuie să includă proceduri prin care se verifică statutul solicitantului şi încadrarea în categoria :

- rău platnicilor; - creditorilor al căror plafon de creditare a fost atins; - creditorilor care mai pot solicita un credit, nu mai mare decât o

valoare impusă; - creditorilor care au dreptul să solicite credit cu valoare care se

încadrează într-un interval definit de garanţii, de cifre de afaceri şi de istoricul lor în relaţia cu banca.

37

Evident, rolul auditului unui astfel de sistem este de a testa dacă respectivul sistem bancar include proceduri. Datele de text sunt date reale cu care se operează în banca unde sistemul informatic va fi operaţional.

Sistemul informatic bancar nu trebuie să valideze efectuarea unor operaţii interzise prin acte normative, dintre care operaţia de efectuare de plăţi ale ratelor unui credit cu banii obţinuţi dintr-un alt credit. Auditorii sistemelor informatice bancare au deja inclusă această operaţie în lista operaţiilor interzise, listă folosită cu prioritate în testarea comportamentului unui sistem informatic bancar.

Un sistem informatic de management financiar-contabil auditat devine credibil când echipa conchide în raportul de audit că sistemul răspunde tuturor cerinţelor din specificaţii, din legi şi regulamente, iar securitatea operaţiilor este asigurată, condiţiile de risc în utilizare fiind minime.

Auditul sistemelor de gestiune financiar-contabilă are menirea de a oferi încredere utilizatorului în produsul informatic.

De aceea trebuie supuse auditării toate componentele sistemului, intrările şi ieşirile acestora. Numai prin coborârea auditului la nivelul detaliilor se vor obţine informaţiile necesare fundamentării unei concluzii finalizate printr-o propoziţie simplă, fără echivoc, de calificare a sistemului.

Prin specificaţii este creată o imagine, un sistem informatic virtual. Dacă se adaugă noi cerinţe desprinse din legislaţie, din experienţa curentă, dacă se produce o ierarhizare a priorităţilor privind operaţii permise, respectiv, operaţii interzise, se creează proiecţia unui sistem informatic virtual şi ideal. Toate comparaţiile sistemului real sunt efectuate strict faţă de coordonatele pe care le oferă ca reper sistemul virtual ideal.

Auditul unui sistem informatic de gestiune financiar-contabil nu are rolul de a controla. Esenţa auditului nu este controlul. Auditorii sunt persoane cu înaltă calificare care nu se substituie controlorilor de calitate, controlorilor care stabilesc existenţa fizică a unui produs, exprimând-o prin cantitate, după măsurare.

Auditul este o activitate superioară de orientare, analiză şi de sinteză. Este o necesitate tocmai prin extensiile pe care le determină asupra întregii viziuni de abordare.

Planul de audit şi programul de audit presupun activităţi clare, nici una dintre acestea nefiind de control.

38

Specificaţiile reprezintă un text structurat. Sistemul informatic reprezintă o structură. Auditorul are menirea de a stabili existenţa corespondenţei dintre componentele textului structurat şi, respectiv componentele sistemului, identificând concordanţă perfectă, concordanţă parţială, concordanţă redusă sau absenţa concordanţei.

Componentele din structura textului care alcătuiesc specificaţiile includ:

- nivelul managementului; - ciclul de elaborarea a sistemului informatic de gestiune financiar-

contabilă; - securitatea sistemului prin: precizarea responsabilităţilor, separarea

funcţiilor incompatibile, ierarhizarea accesului la resursele sistemului, gestiunea copiilor;

- nivelul operaţional în modul de lucru, prin procedurile pe care operatorii le efectuează în ceea ce priveşte: introducerea de date, manipularea de documente, manipularea dischetelor cu date intermediare, înregistrarea evenimentelor, asistenţa tehnică;

- nivelul aplicaţiilor presupune parcurgerea de către auditor a tuturor etapelor astfel încât să se dezvolte convingerea că sistemul informatic de gestiune contabilă este chiar construcţia în care utilizatorul trebuie să aibă mare încredere; se reia un ciclu complet de prelucrare, de la iniţierea procesului, pregătirea datelor, procesarea acestora şi obţinerea rezultatelor: fişierele, bazele de date suferă o serie de modificări pe care analistul trebuie să le analizeze pentru a vedea dacă există sau nu şi alte efecte secundare;

- nivelul de acces presupune identificarea modului în care au fost soluţionate elementele fundamentale ale accesului la resursele sistemului informatic - proceduri, baze de date, modul în care se dezvoltă şi alte canale de transfer a informaţiilor şi cum se asigură robusteţea reţelei de calculatoare.

Echipa de audit colectează date proprii, dar preia şi rezultate oferite de sistemul informatic de gestiune financiar-contabilă. Pe măsură ce se traversează etapele ciclului de dezvoltare, echipa de realizare a sistemului informator elaborează părţi ale documentaţiei care însoţeşte sistemul.

Echipa de audit analizează şi această documentaţie pentru a urmări traseul parcurs de la specificaţii, până la obţinerea produsului finit în formă livrabilă către organizaţii.

39

Raportul de audit este un document sinteză care efectuează analiza comparată între un sistem virtual-ideal şi un sistem real. Toate datele înregistrate în procesul de auditare se coroborează cu specificaţiile, cu documentaţia. Se calculează o serie de indicatori. În final se spune că sistemul este sau nu credibil, asigură sau nu calitatea prelucrărilor, că există sau nu garanţia ca sistemul informatic să dea satisfacţie clientului în raport cu un obiectiv stabilit.

Auditul informatic este un demers deosebit de complex, motiv pentru care trebuie aşezat pe un fundament solid.

Obiectivul fundamental al activităţii de auditare informatică este stabilirea gradului de credibilitate a sistemului informatic de management. Fluxurile de informaţii specifice oricărui sistem informatic trebuie să asigure integritatea informaţiilor organizaţiei, completitudinea prelucrărilor, corectitudinea rezultatelor şi mai ales accesibilitatea beneficiarului la informaţia aşteptată, obţinând în acest fel un nivel maxim al satisfacerii cerinţelor proprii.

Din punct de vedere al echipelor de auditare auditul sistemelor informatice se clasifică astfel:

- audit intern, prin care se confirmă respectarea procedurilor de transformare a datelor de intrare în rezultate – urmărindu-se modul în care noul sistem în care se implementează este mai eficient, este însoţit de economisire de resurse;

- audit extern care include proceduri prin care se evidenţiază comportamentul sistemului informatic, prin testări cu ajutorul cărora se evidenţiază cât de stabile, cât de fiabile, mentenabile sunt procedurile de control care intră în componenţa sistemului şi care implementeză toate cerinţele exprese incluse în specificaţii, în legi, în regulamnete şi care restricţionează prin blocare orice tentativă de execuţie a operaţiilor interzise.

Pentru a dezvolta un proces de auditare a sistemului informatic de management sunt parcurşi următorii paşi:

- planificarea proceselor de auditare având la bază o serie de elemente prin care se stabileşte anvergura prin cunoaşterea unor elemente legate de complexitatea sistemului informatic şi mai ales prin stabilirea nivelului de credibilitate pe care trebuie să-l stabilească auditorii sistemului;

- evaluarea riscurilor legate de influenţele negative care se manifestă asupra componentelor sistemului informatic ce vor fi auditate, pe măsură ce se activează procedurile de control;

40

- elaborarea programului de audit ce include: definirea scopului, stabilirea obiectivelor, efectuarea planificării, derularea propriu-zisă, întocmirea de rapoarte;

- culegerea de date ce evidenţiază modul cum se execută prelucrările, care sunt neconcordanţele între specificaţii şi produsul real; datele apar sub forme extrem de variate, de la liste, fişiere de tranzacţii, liste de erori, chestionare care vizează obţinerea unor răspunsuri cu cheie, diagrame, texte sursă, seturi de date de text, documentaţia care se livrează o dată cu implementarea sistemului informatic, ghidurile de utilizare şi de administrare;

- elaborarea raportului de auditare care preia elemente definite în planul de audit a sistemului informatic la care sunt adăugate detalii asupra modului cum s-a derulat procesul de auditare, gradul de transparenţă asigurat.

Întrucât auditorii de sisteme informatice pentru management sunt specialişti de înaltă calificare în domeniu, enumeră în raport totalitatea diferenţelor care au fost întâlnite, între sistemul real şi sistemul virtual-ideal; nu sunt incluse soluţii, deşi auditorii prin competenţa lor deosebită au capacitatea de a le oferi; auditul sistemelor informatice pentru manangement consemnează numai diferenţele; caracterul sistematic al procesului de auditare oferă o grupare ascendentă în raport cu profunzimea efectelor de antrenare, a diferenţelor; în cazul în care sunt identificate erori, toate erorile sunt tratate distinct şi contribuţia lor în diminuarea nivelului de credibilitate a sistemului informatic pentru management este amplificată prin utilizarea de coeficienţi de importanţă cunoscuţi atât de auditori, cât mai ales de cei care au dezvoltat sistemul informatic.

Activitatea de audit pentru sisteme informatice se bazează pe agregarea unor indicatori şi pe obţinerea de valori care să fundamenteze apartenenţa sistemului informatic la clasa de sisteme credibile în care se garantează calitatea soluţiilor aşteptate de beneficiar sau, din contră, sistemul nu e credibil şi trebuie să fie supus unor corecţii şi din nou unui proces de auditare.

Dacă tehnica de auditare şi procedurile de măsurare a diferenţelor sunt clar definite, procesul de audit pentru sisteme informatice este reproductibil în proporţie de 100%.

Asociaţiile care au preocupări în a elabora tehnici şi metode de auditare sau de a certifica speculaţii în auditul sistemelor informatice pentru

41

management şi-au concentrat atenţia asupra algoritmizării proceselor de auditare, în viitor trebuind să definească metrici pentru a asigura caracter obiectiv auditului, prin transferul din zona interpretărilor, în zona certitudinilor.

Particularităţile auditării sistemelor informatice, comparative cu alte produse, şi necesitatea unei pregătiri corespunzătoare a auditorilor, necesită existenţa unor standarde corespunzătoare acestui. În anexa 9 sunt prezentate oganizaţii specializate care elaborează standarde destinate auditării sistemelor informatice, recomandări şi ghiduri necesare activitătii de audit pentru sistemele informatice. Obiectivele acestor standarde sunt de a informa:

- auditorii de sisteme informatice privind nivelul minim de pregătire; - managerii şi alte personae interesate privind aşteptările unei activităţi

de auditare. Standardele definesc cerinţele obligatorii pentru desfăşurarea

auditului şi pentru modul de întocmire a rapoartelor de audit.

42

5. CONSTRUIREA DE LISTE

O listă este o construcţie liniară, formată din elemente dispuse unul după altul. O listă presupune parcurgerea secvenţială, de la primul element, elementul din capul listei, până la ultimul element. Construirea unei liste se realizează pentru a obţine:

- enumerarea elementelor unei colectivităţi într-o ordine stabilită, ca de exemplu, în ordinea sosirii într-un fir de aşteptare, în ordinea servirii, în ordinea importanţei sau într-o ordine a preferinţelor;

- stabilirea etapelor unui proces, în ordinea derulării lor; - setul de documente necesar pentru a obţine calitatea de

eligibilitate în vederea acordării unor fonduri pe bază de proiect; - o ierarhizare a elementelor unei colectivităţi în funcţie de un

criteriu de performanţă stabilit şi acceptat de participanţi; - un inventar al componentelor care alcătuiesc un subansamblu sau

un produs finit; se specifică denumirea reperelor şi numărul de repere de acelaşi fel care intră în alcătuirea subansamblului;

- un şir de valori care corespund unor momente de timp; şirul include elemente omogene, care se supun aceloraşi prelucrări.

În procesul de auditare, rigurozitatea şi profesionalismul impun elaborarea de liste complete, structurate strict pe importanţă sau pe ordinea de execuţie.

Planul de auditare se constituie ca listă de activităţi care trebuie executate. Derularea activităţii în sine este descrisă ca o listă a activităţilor. Raportul de auditare este, de asemenea, o listă de calificative. Lungimea listelor depinde de complexitatea sistemului informatic. Procesul de auditare se derulează după reguli precise. El se constituie din etape fixe, s ca număr, date de tehnicile şi standardele de auditare, Et1, Et2, ..., Ets. Fiecărei etape Eti îi corespunde o componentă în lista de bază a auditului sistemului informatic, având asociat un text Ti care indică obiectivul etapei, inputurile etapei şi outputurile acesteia, aşa cum se arată în figura 5.1.

43

La rândul lor, etapele sunt detaliate prin construirea unor liste de activităţi. Asfel etapei Eti i se asociază o listă de activităţi Ai formată din elementele ai1 ai2 ... aiNi. Fiecare element este concretizat printr-un text Fij care conţine detalii privind modul cum se realizează fiecare dintre activităţile corespunzătoare etapei Ei, figura 5.2.

E1 Et2 Eti Ets

T1 T2 Ti Ts

Figura 5.1. Etapele ciclului de auditare a sistemului informatic

Ei

Ti

Tij

Tij

Tij

iiNT

Figura 5.2. Lista de activităţi Ai a etapei Eti.

Ai1

Ai1

Ai1

iiNA

44

Până în acest stadiu de detaliere, auditării îi corespunde o agregare de liste simple, pe două niveluri, obţinându-se o listă de liste. Este vorba de lista etapelor care conţine liste de activităţi.

Dacă detalierea este aprofundată, fiecărei activităţi îi corespund sarcini, rapoarte, persoane, pentru toate acestea definindu-se noi liste, care conduc la o nouă agregare. Auditarea este o agregare de nivel k a listelor. Cu cât nivelul k este mai mare, cu atât rigurozitatea demersului este mai ridicată. Faptul că fiecărei activităţi i se asociază inputuri, outputuri şi sarcini, înseamnă că procesul de auditare este constituit ca un mecanism care doar trebuie pornit pentru a merge perfect.

Şi auditul sistemelor informatice, ca orice activitate complexă, este o activitate de echipă. Consultingul în echipă presupune:

⇒ existenţa unui manager cu experienţă şi cu reale calităţi în domeniul lucrului cu oamenii, pentru a crea cadrul adecvat activităţilor de audit, pentru a menţine nivelul de exigenţă la cote ridicate, fără a face rabat de la sarcini şi, mai ales, pentru încadrarea în termene şi limite de calitate;

⇒ stabilirea unor criterii riguroase de selecţie a membrilor echipei; auditul unui sistem informatic este un proiect; ca orice proiect pentru care există un management, o atribuţie a managerului este formarea echipei; în cazul unor structuri birocratice, constituite pe criterii în cadrul cărora performanţa şi coeziunea nu sunt prioritare, este dificil să se deruleze un proces de audit de sistem informatic cu eficienţă; restricţiile auditului nu permit rabat, iar orice neconcordanţă în funcţionarea echipei, în special în planul comunicării şi în planul compensărilor în vederea echilibrării sarcinilor, conduce la dereglaje, mai ales în ce priveşte termenele asociate fiecărei etape a auditului; arta managerului constă în a-i cunoaşte pe oameni, a şti ce putere de muncă are fiecare, ce calităţi, cât de eficient este; poziţionarea unei persoane din echipă, din punct de vedere al sarcinilor, aparţine managerului de proiect de audit sistem informatic; o aceeaşi persoană pusă la un loc cu sarcini pe care le îndeplineşte, este omul potrivit, la locul potrivit, cum, desigur, prin plasarea la un loc de muncă neadecvat calităţilor şi pregătirii, este omul nepotrivit, la locul nepotrivit;

⇒ realizarea unei discipline a lucrului în echipă; este cunoscut faptul că în activitatea unei echipe există patru momente: primul moment corespunde definirii problemei de rezolvat, al doilea moment corespunde formulării de soluţii, al treilea moment este activitatea propriu-zisă, pentru a transpune soluţiile în practică, iar ultimul moment, al patrulea, corespunde

45

evaluării rezultatului muncii echipei; este important ca, la definirea problemei şi la elaborarea de soluţii, membrii echipei să comunice; părerile, dezbaterile, sunt esenţiale în a obţine cea mai bună definire a problemei, pentru a obţine cea mai bună soluţie; în zona auditului superlativele sunt necesare, pentru că altfel rezultatul auditului nu are acele elemente care să transfere sistemului informatic credibilitatea necesară; definirea incompletă a problemei de audit conduce la abordări parţiale având drept consecinţe revenirea la unele etape trecute şi modificarea costurilor legate de reluarea unor activităţi; disciplina impusă de managerul proiectului de audit sistem informatic vizează dialogul deschis în timpul definirii problemei şi prezentării de soluţii şi, respectiv, la alegerea soluţiei de auditare efective; disciplina trebuie astfel dirijată, încât, după luarea unei decizii, nici unul dintre participanţi să nu mai discute despre o soluţie foarte bună pe care el ar putea să o propună, dar care, ştie el exact, nu ar fi fost adoptată din considerente pe care nu le face cunoscute; aşa-zişii experţi în a da soluţii, prin regulile impuse de managerul de proiect, aveau dreptul să le facă cunoscute; din lipsă de idei, evident, se ascund în spatele unor ipotetice soluţii de sertar, inexistente în realitate, producând un soi de disidenţă neproductivă pentru procesul de auditare; un manager de proiect de audit, care continuă, la un alt proiect, să includă astfel de persoane în echipă, înseamnă că acceptă şi chiar cultivă un stil de lucru neproductiv; mai mult, dacă aceste soluţii sunt rediscutabile la nivelul echipei, etapa de alegere a soluţiei se prelungeşte; mai dificil este atunci când etapa de alegere a soluţiei este reluată după ce au fost parcurse deja alte etape ale procesului de auditare; în acest caz, se manifestă disfuncţionalităţi chiar la nivelul managementului de proiect de auditare, iar până la compromiterea procesului de auditare este numai un pas;

⇒ elaborarea de rapoarte în timp real; este cunoscută tentaţia de a scrie rapoarte după derularea fazelor; programatorii elaborează schemele logice sau alte tipuri de diagrame numai dacă acest lucru este cerut imperios, deşi standardele impun acest lucru; elaborarea documentaţiei se face mult mai târziu, ceea ce explică numeroasele lacune, aspectele extrem de ermetice pe care designerii le includ, crezând că toată lumea ştie despre sistemul informatic tot ceea ce ştiu şi ei; elaborarea rapoartelor în timp real înseamnă, în primul rând, efectuarea unor înregistrări ale constatărilor „la cald”, a ceea ce s-a văzut în cadrul realizării fiecărei activităţi pe care auditorul o bifează în lista primită; trebuie să existe o ordine în aceste notiţe

46

pentru a reconstitui paşii, pentru a opera pe seturile de date în vederea obţinerii, în final, a unor rezultate coerente; existenţa unei bune comunicări între membrii echipei care realizează aceleaşi activităţi conduce la construirea de structuri de tabele compatibile, la abordări uniforme, care, în final, dau unitate raportului de auditare; mai mult, pentru a obţine date comparabile, membrii echipei trebuie să comunice cu privire la procedurile pe care le adoptă şi să rămână constanţi în a le utiliza pe toată durata procesului de auditare; realizarea stadiilor din rapoarte, bazată pe proceduri unice, este şansa de a da consistenţă concluziilor raportului final;

⇒ adoptarea unui standard de auditare şi folosirea unei singure metode; într-un război este folosită o singură strategie, o singură tactică, iar armamentul este compatibil pentru a avea o comandă unică; în cazul procesului de auditare lucrurile stau în mod similar; se adoptă un standard pentru auditul sistemului informatic, se fixează o metodă de auditare; obţinerea calităţii de auditor de sisteme informatice presupune obţinerea de calificative de trecere la o serie de examene; înseamnă că auditorul cunoaşte standardele şi metodele de auditare; managerul de proiect fixează sau, într-un context mai democratic, supune atenţiei şi apoi adoptării cele două instrumente de lucru; odată stabilite, se trece la punerea în mişcare a întregului proces de auditare a sistemului informatic; auditarea este asemenea vizionării cu specialişti şi cu critici a unui spectacol, înaintea premierei de a doua zi; spectacolul e gata; el este văzut de specialişti; modificări nu se mai fac de pe o zi pe alta; există însă o tensiune specifică, tensiune care precede momentul vizionării, cu tendinţa de a face lucrurile cât mai bine, întrucât cei care vizionează spectacolul sunt deţinătorii efectului de ghilotină; tot în acelaşi mod trebuie privit şi procesul de auditare; când elaboratorii sistemului informatic ştiu că sistemul lor – produs finit – va fi auditat, ştiu şi standardele şi tehnicile de auditare care se folosesc; de aceea, pe întreg parcursul de realizare se face referire la acestea, cu consecinţe benefice asupra produsului final; deşi există tehnici de dezvoltare software, standarde şi instrumente, toate sunt puţin folosite, iar produsul finit realizat are abateri suficient de mari faţă de ceea ce s-a propus iniţial, dacă nu este prevăzut din start şi un proces de auditare; chestiunea auditării trebuie precizată încă de la încheierea contractului, ca o condiţie necesară de acceptare a produsului de către beneficiari; echipa care elaborează sistemul informatic trebuie să lucreze în cunoştiinţă de cauză, adică, din primul moment trebuie să ştie că produsul – sistemul informatic –

47

va fi auditat; mai mult, trebuie să fie cunoscuţi termenii auditării în detaliu; sistemul informatic nu se produce pentru a fi auditat, ci se produce pentru a satisface nişte nevoi în plan informaţional ale unui beneficiar; un sistem informatic se produce într-un fel dacă se ştie că va fi auditat şi cu totul în alt fel dacă nu este auditat. Dacă se realizează un experiment: două echipe sunt puse să dezvolte un acelaşi sistem informatic, una ştiind de la început că sistemul realizat va fi auditat, iar cealaltă aflând că sistemul informatic produs va fi auditat după ce l-a realizat în forma finală, livrabilă; deşi echipele sunt la fel de performante, rapoartele de auditare vor semnala diferenţe importante, numai raportul primei echipe fiind cu certitudine favorabil.

Toate aceste elemente creează un cadru favorabil începerii activităţii echipei de audit sisteme informatice.

Construirea listelor este o activitate complexă, deosebit de importantă. Listele trebuie să fie complete, să includă toate elementele unei colectivităţi. Este adevărat că, dacă lipsesc elemente, se adaugă sau se inserează. Sau dacă sunt incluse şi elemente ale altor colectivităţi, acestea sunt şterse pentru a obţine liste complete. Listele trebuie să fie, de asemenea, corecte, adică ordinea de dispunere trebuie să corespundă poziţiei sau importanţei elementului.

Conţinutul textului care descrie sau defineşte un element al listei trebuie să fie clar, concis, simplu, complet, să genereze acţiuni în succesiune logică, cu intrări şi ieşiri specificate. Toate acestea trebuie să impună eliminarea din texte a acelor elemente generatoare de ambiguităţi, de soluţii multiple, transformând în acest fel un act de execuţie în act de decizie urmat de execuţie în condiţii de incertitudine. Aceste liste, planuri de activitate, paşi ai unor proceduri, tabele cu caracteristici, nu sunt nişte dogme. Ele se constituie în seturi de reguli de urmat. Există şi abateri, dar abaterile nu se transformă în reguli.

Dacă, în final, dintr-un număr de N elemente ale unei liste enumerative, 5-10% diferă de forma iniţială, prin comunicare întregul eşafodaj se adaptează în aşa fel încât elementele nou introduse să-şi găsească corespondent în celelalte liste. O astfel de abordare evidenţiază caracterul dinamic, viu al procesului de auditare. Se produc ajustări din mers, toate având menirea de a îmbunătăţi procesul, iar transferul final de credibilitate să fie real, să aibă acoperire, validarea prin practică să încununeze o muncă tenace a echipei de auditare şi nu invers, să se constate

48

că auditarea e un eşec ireversibil. Listele trebuie să conţină elemente disjuncte pentru a reduce cât mai mult posibil suprapunerile care sunt generatoare de confuzii şi contradicţii.

În medicină există ghiduri care concentrează experienţa pozitivă, oferind dezvoltări de proceduri pas cu pas pe care trebuie să le urmărească un medic în ambulatoriu. În acelaşi fel trebuie procedat şi pentru audit. Existenţa standardelor şi a tehnicilor de auditare stau la baza construirii de liste. Este important ca listele să fie astfel elaborate încât să nu lase loc interpretărilor. Acumularea experienţei permite gestionarea metodelor şi standardelor de auditare.

Întrucât rezultatul auditării este un produs oficial cu care se demonstrează transferul de credibilitate, toate elementele trebuie să respecte strict standardele şi tehnicile de auditare, întrucât, în caz de forţă majoră, se face referire, rând pe rând, la articolele după care au fost executate activităţile de auditare. Nu se execută nici o activitate dacă nu figurează în procedurile standard de auditare. Dacă se execută evaluări, mai întâi sunt culese date şi se fac prelucrări pentru a calcula indicatorii din metodologiile recunoscute. În cazul în care se experimentează componente suplimentare sau se demonstrează că unele proceduri noi, neincluse în standarde, sunt superioare celor obligatorii, pe lângă cele obligatorii se execută şi noile proceduri. La rezultatele obligatorii se adaugă noi rezultate, care vin să întărească rezultatele obţinute prin proceduri oficiale. În listele enumerate se face distincţie între tot ceea ce este obligatoriu şi pentru care există proceduri rigide şi tot ceea ce este suplimentar. Nu este vorba de opţionalitate, ci de prelucrări necesare, dar neobligatorii din punctul de vedere al beneficiarului raportului de auditare. Aceşti paşi suplimentari sunt obligatorii numai pentru auditori, întrucât sunt în sprijinul procesului de auditare.

Există prototipuri de sisteme informatice cărora li s-au definit entităţi distincte. Experienţa acumulată a condus la elaborarea de liste în format extrem de cuprinzător. Ele se constituie ca punct de plecare în elaborarea de liste pentru sisteme informatice date, particulare în raport cu un context definit. Principiile care stau la baza adaptării listelor vizează elemente specifice customizării. Pornind de la un sistem informatic de bază foarte general, particularizarea ia în considerare outputurile sistemului care se doreşte a fi implementat. Din aproape în aproape, folosind matricile de corespondenţă ale sistemului derivat, prin reutilizare de componente,

49

pornind de la experienţa acumulată, se preiau din listele generale acele elemente care sunt specifice sistemului informatic ce face obiectul auditării.

Aceste liste permit efectuarea unui audit total, care include, pe lângă sistemul informatic - produs finit - şi alte elemente ce dau substanţă transferului de credibilitate. Caietul de sarcini reprezintă o componentă exterioară procesului de realizare a sistemului informatic. În cazul în care acesta conţine suficiente detalii tehnice, se constituie în specificaţiile de bază sau macrospecificaţiile sistemului informatic, figura 5.3.

Macrospecificaţiile sunt materia primă a construirii listelor enumerative, de derulare, de priorităţi, de caracteristici şi de evaluare ale sistemului informatic.

Listele enumerative conţin, dispuse unele după altele, componente

omogene, precum numele modulelor, numele fişierelor, numele entităţilor, numele parametrilor, codurile asociate mesajelor, numele asociate

Macrospecificaţii

nivel 1Specificaţii tehnice 1

Specificaţii tehnice 2

Specificaţii tehnice k

nivel w M1 M2 Mw

nivel 0

Figura 5.3. Dezvoltarea structurată pe etape a ciclului de realizare a sistemului

•••

50

rapoartelor, parole de acces şi rezultate ale evaluărilor. Listele enumerative se construiesc pe măsură ce se proiectează sistemul informatic şi se actualizează pe măsură ce se derulează etapele de realizare ale sistemului informatic. Dinamica de conţinut a listelor enumerative dă o imagine suficient de clară în legătură cu echipa de designeri, privind experienţa şi, mai ales, gradul de cuprindere şi de detaliere de care aceasta a dat dovadă.

Listele de derulare includ etape, activităţi, operaţii care trebuie parcurse într-o anumită ordine pentru a atinge un anumit obiectiv. La fel ca în cazul gamei de operaţii, sunt specificate precedenţele şi, mai ales, restricţiile de începere, de continuare şi de încheiere. Listele de derulare se dovedesc a fi corect elaborate când, pe măsură ce se execută etape ale ciclului de dezvoltare a sistemului informatic, nu sunt necesare interschimburi de poziţie şi nici inserări de noi elemente în liste. Listele de derulare concentrează multă experienţă şi sunt elemente de start în definirea de proceduri standard, asemănătoare celor din ghidurile de medicină pentru primul ajutor, care trebuie respectate cu stricteţe pentru ca pacientul să supravieţuiască.

Listele de priorităţi reprezintă o formă concretă de manifestare a viziunii managerului de proiect. Priorităţile vizează raportul dintre calitate şi cantitate, modalităţi de elaborare a criteriilor de selecţie a membrilor echipei de dezvoltare a sistemului informatic şi stabilirea poziţiei pe care o are managementul calităţii sistemului informatic. Priorităţile definite au caracter obligatoriu de aplicabilitate. Fluctuaţiile în timp sau pe compartimente în aplicarea priorităţilor au drept consecinţă determinată creşterea gradului de neomogenitate a componentelor sistemului informatic.

Listele de caracteristici vizează extragerea dintr-o multitudine de caracteristici a acelora pe care managerul proiectului le consideră esenţiale şi pe care le urmăreşte pe toată durata procesului de dezvoltare a sistemului informatic. Listele de caracteristici ţin seama de destinaţia sistemului informatic. Orientarea sistemului informatic spre cerinţele utilizatorului conduce la includerea cu prioritate a caracteristicilor care vizează obţinerea unui singur nivel maxim de satisfacţie la nivelul beneficiarului, pe măsură ce acesta exploatează sistemul informatic. Pentru gestionarea eficientă a resurselor companiei de informatică, lista include şi caracteristici tehnice, interne ale sistemului informatic. În cazul în care se schimbă raportul caracteristicilor, în favoarea celor care îl privesc exclusiv pe dezvoltator, creşte riscul de a obţine un sistem informatic pentru un beneficiar ipotetic,

51

altul decât cel care plăteşte această investiţie, cu toate consecinţele care vizează efectuarea de corecţii sau reluarea unor etape ale ciclului de elaborare, pe cheltuiala elaboratorului.

Listele de evaluare prezintă importanţă atât în procesul de elaborare, cât şi în procesul de auditare, întrucât creează premisele derulării mai întâi a procesului de autoevaluare şi după aceea a procesului de evaluare. În condiţii normale nu trebuie să existe diferenţe semnificative între autoevaluarea şi, respectiv, evaluarea sistemului informatic sau a componentelor acestuia.

Transparenţa construirii şi utilizării listelor are menirea de a crea unitate în echipa de auditare a sistemului informatic. Cunoaşterea completă a listelor este fundamentală pentru definirea sarcinilor membrilor echipei de auditare. În dreptul fiecărui element din listă va fi trecut numele unui membru din echipa de auditare. Se creează un nivel ridicat al responsabilizării, întrucât atât calitatea, cât mai ales noncalitatea, trebuie asumată. Auditul sistemului informatic, ca activitate ce se derulează după o schemă ierarhizată pe niveluri, are la bază liste care conexează elemente omogene detaliate cu rapoartele de sinteză, figura 5.4.

Raport detaliu R1

Raport detaliu Rv

• • ••

Listă de rapoarte de detaliu

Raport de sinteză

Figura 5.4. Sinteza rapoartelor de detaliu pe bază de listă

• • •Raport detaliu

R2

52

Este necesar ca în raportul de sinteză să se facă referire directă la rapoartele de detaliu R1, R2, ... , Rv şi să se efectueze prelucrarea datelor din aceste rapoarte pentru a obţine indicatori agregaţi, care privesc un ansamblu printr-o descriere sintetică. Construirea listelor de liste creează cadrul pe care se construiesc din aproape în aproape rapoartele, aşa cum se prezintă, schematic, în figura 5.5.

••• ••• •••

Lista Lk1 Lista Lk2 Lista Lkp

• • • • • •

Lista k-1, 1

• Lista k-2, 1

Figura 5.5. Schema de auditare, ca listă de liste

•••

• • •

53

Includerea de rapoarte pe niveluri crescătoare de agregare conduce la completarea documentaţiei din aproape, în aproape figura 5.6.

Procesul de auditare se defineşte ca mod de traversare a listelor de

liste prin completarea cu informaţii specifice rapoartelor. Procedurile de agregare sunt standard. Esenţial este ca baza privind procesul de auditare să fie solidă, bazată pe măsurători şi pe analize foarte riguroase.

Construirea listelor reprezintă latura esenţială a procesului de auditare – planificare. Fără un plan bine elaborat, articulat şi fără o viziune unitară, rezultatul final este afectat de factori perturbatori. Acesta este motivul pentru care, înainte de a începe auditarea propriu-zisă, se trece la clarificarea tuturor aspectelor.

• • •

Raport Rk1

• • •

Raport Rk-1, 1 Raport Rk-1, 2

Raport Rk-2

• • •

Figura 5.6. Rapoartele de auditare, ca informaţii utile ale listelor de liste

Raport Rk2 • • • Raport Rkv •••

54

6. AUDITUL SPECIFICAŢIILOR

Specificaţiile sistemului informatic, asemenea unei case, constituie temelia sistemului. De aceea auditul sistemului trebuie să înceapă cu auditul specificaţiilor. Specificaţiile au la bază surse precum:

- legi şi acte guvernamentale; - norme de aplicare a unor acte oficiale; - documentaţii tehnice privind echipamentele de producţie şi

auxiliare; - documentele de creare şi funcţionare a companiei; - monografii, referate şi prezentări; - documente contabile şi de patrimoniu; - documente programatice: strategii şi planuri pe termene diferite; - rapoarte privind dinamica evoluţiei; - rapoarte privind conexiunile cu mediul de afaceri; - documentaţii privind publicitatea şi definirea imaginii de piaţă; - documentaţia privind forţa de muncă; - documentaţia privind activităţile de cercetare, studiile de piaţă,

activităţile sociale. Auditul are menirea de a defini gradul de cuprindere al documentelor

necesare dezvoltării unor specificaţii complete, corecte şi în concordanţă cu obiectivul definit pentru sistemul informatic.

Se întocmesc mai multe liste şi tabele şi anume: - lista tipurilor de documente; - listele claselor de documente aparţinând fiecărui tip; - listele grupurilor de documente aparţinând fiecărei clase: - tabelele de descriere cantitativă a elementelor care alcătuiesc

grupurile; pentru fiecare grup se defineşte un tabel. Fiecare listă conţine elemente sub formă de texte structurate în triplete

< xi , yi , zi > , i = 1, 2, ...ne, unde: xi - denumirea tipului, clasei sau grupului de pe poziţia i a listei; yi - variabilă egală cu 1 în cazul în care în dezvoltarea specificaţiei au fost

incluse elementele ca tipul, clasa, grupul i; în caz contrar se atribuie valoarea blanc;

55

zi - variabilă egală cu 1 în cazul în care în dezvoltarea specificaţiei elementele specificate prin xi nu au fost folosite; în caz contrar se atribuie valoarea blanc;

ne – numărul elementelor din listă. Forma concretă de existenţă a listei este dată în tabelul 6.1.

Structura listei de descriere tip, clasă sau grup

Tabelul 6.1 Denumire element

xi Utilizat

yi Neutilizat

zi x1 y1 z1 x2 y2 z2 . . . . . . . . . xne yne zne

După completare, se calculează un indicator al utilizării surselor Ius,

dat de relaţia:

∑=

=ne

iiius PyI

1,

unde Pi reprezintă coeficienţii de importanţă acordaţi de auditori după o metodologie anume, care să asigure reprezentativitatea. Nivelurile indicatorului Ius plasează activitatea de documentare pentru realizarea specificaţiilor ca fiind foarte bună, bună, satisfăcătoare sau nesatisfăcătoare. Astfel:

( ]( ]( ]( ]⎪⎪⎩

⎪⎪⎨

⎧

∈

62,0;078,0;62,092,0;78,0

1;92,0

usI

Specificaţiile se elaborează pornind de la obiectivul O pentru care se construieşte sistemul informatic. Nu trebuie confundat obiectivul cu mijloacele de atingere a lui. Dacă apar astfel de confuzii, se produce o deplasare de atenţie spre o altă direcţie, iar investiţiile nu se dovedesc eficiente pentru companie. Obiectivul O generează subobiective. Asemenea programării dinamice, urmărirea din aproape în aproape a subobiectivelor conduce la atingerea obiectivului general pentru care se dezvoltă sistemul. Se definesc subobiectivele SO1, SO2, ..., SONSO, unde NSO reprezintă numărul de subobiective. Subobiectivele vizează o localizare fie pe componentele companiei, fie pe funcţiile pe care compania le realizează.

documentarea este considerată foarte bună

documentarea este considerată bună

documentarea este satisfăcătoare

documentarea este considerată nesatisfăcătoare

56

Astfel, dacă la nivelul companiei există submulţimile SS1, SS2, ..., SSNSS, unde NSS reprezintă numărul de subsisteme care fizic sunt secţii, ateliere, depozite, şantiere, puncte complexe de lucru, în procesul de auditare se verifică:

- diferenţele dintre numărul de subsisteme NSS şi numărul de subobiective NSO; dacă NSS = NSO, înseamnă că definirea de obiective este completă; dacă NSS > NSO, înseamnă că sunt subsisteme pentru care nu au fost definite subobiective; ideea de subobiective comune nu trebuie agreată, fiind creatoare de confuzii când se definesc structurile; numai în procesul de optimizare a sistemului informatic se procedează la gestionarea redundanţei, în sensul reducerii până la limita rezonabilă;

- concordanţa dintre nivelul pe care îl are subsistemul SSi şi conţinutul subobiectivului SOi.

În realitate, trebuie să existe concordanţă între subobiective şi componenţa structurală a companiei, aşa cum se prezintă în figura 6.1.

Figura 6.1. Concordanţa dintre stuctură şi subobiective

COMPANIA

SS1 SS2 SS3 SSNSS

SO1 SO2 SO3 SONSO

OBIECTIVUL O

• • •

• • •

57

În cazul în care sistemul informatic este orientat pe funcţii ale companiei, între subobiective şi funcţiile F1, F2 ..., FNFUN, trebuie să existe o perfectă concordanţă, figura 6.2.

Sunt situaţii în care, din motive de neclaritate, se combină funcţiile cu structurile companiei, rezultând modalităţi neomogene de agregare. Pentru a evita astfel de abordări, se construieşte matricea MFS de corespondenţă funcţii, subsisteme, având NFUN linii şi NSS coloane, tabelul 6.2, iar elementul mfsij arată că între funcţia Fi şi subsistemul SSj există o legătură dacă are valoare 1. În cazul în care se atribuie acestui element valoarea 0, rezultă că nu există o legătură directă între funcţia Fi şi subsistemul SSj.

Legătura funcţii/subsisteme Tabelul 6.2

Subsisteme Funcţii

SS1 SS2 . . . SSj . . . SSNS

F1 F2

.

.

.

COMPANIA

F1 F2 F3 FNFUN

SO1 SO2 SO3 SONSO

OBIECTIVUL O

Figura 6.2. Concordanţa dintre stuctură şi subobiective

• • •

• • •

58

Subsisteme Funcţii

SS1 SS2 . . . SSj . . . SSNS

Fi mfsij . . .

FNFUN

Se consideră eroare situaţia în care o linie din matrice sau o coloană are toate elementele nule.

Situaţia cea mai favorabilă este cea în care unei funcţii Fi îi corespunde doar un subsistem SSj. Înseamnă că în companie fiecare subsistem realizează o singură funcţie, sarcinile fiind foarte clar distribuite. Confuziile apar atunci când mai multe subsisteme au ca sarcină activităţi corespunzătoare aceleiaşi funcţii. Confuzii apar şi atunci când un subsistem realizează mai multe funcţii şi unele dintre funcţii sunt distribuite mai multor subsisteme. În tabelul 6.3 este dat un exemplu în care subsistemul SS3 realizează activităţile funcţiilor F1 şi F3 , iar funcţia F2 este distribuită subsistemelor SS1 şi SS2, ceea ce complică procesul de auditare şi de regăsire a datelor din liste atunci când nu se menţine un grad de redundanţă, pentru a plasa aceleaşi documente referitoare la o aceeaşi activitate de funcţie pentru toate sistemele în care aceasta este gestionată.

Legături multiple funcţii/subsisteme Tabelul 6.3

Subsistem Funcţii

SS1 SS2 SS3

F1 0 0 1 F2 1 1 0

F3 0 0 1

Printr-o reproiectare a legăturilor subsistem – funcţii se ameliorează distribuirea, încă înainte de a dezvolta sistemul informatic. Analistul are numai menirea de a consemna distribuirea difuză a sarcinilor pentru subsisteme. Se defineşte un algoritm pentru a analiza caracterul difuz sau bine definit al legăturilor funcţii – subsisteme. Se construieşte un indicator IDIF al difuziunii, care este 0 dacă matricea MSF are toate elementele egale cu 1 şi, respectiv, este egal cu 1 dacă fiecărei funcţii Fi îi corespunde unul şi

59

numai unul dintre subsisteme, respectiv subsistemul SSj. Se consideră mulţimea MFSnm a matricelor booleene cu cel puţin un element nenul pe o linie, pentru care este definită inegalitatea dublă

nmm

j

n

iij

n

i

m

jij mnaa +≤⎟

⎠

⎞⎜⎝

⎛+⎟⎟

⎠

⎞⎜⎜⎝

⎛≤ ∏ ∑∏ ∑

= == = 1 11 12

De la această inegalitate se porneşte pentru a construi indicatorul

IDIF. Auditul specificaţiilor presupune existenţa unor definiri riguroase, ortogonale şi coerente. După clarificarea aspectelor calitative şi cantitative legate de definirea obiectivului, subobiectivelor şi după stabilirea modului de grupare/regăsire a informaţiei în sistem, după structură sau după funcţii, se trece la analiza outputurilor, a indicatorilor şi a inputurilor, figura 6.3.

Fiecare indicator reprezintă un mod de reflectare a factorilor care acţionează în cadrul fiecărui subsistem. Dacă se consideră mulţimea factorilor FACT j1 FACT j2 ... FACT jNFj care influenţează activitatea subsistemului SSj, procesul de auditare realizează:

⇒ analiza listei factorilor pentru a vedea dacă este o listă completă; factorii sunt strict dependenţi de sistemul echipamentelor, de sistemul energetic, de sistemul materiilor prime şi de sistemul forţei de muncă; aceste sisteme sunt distribuite prin componente şi interdependenţe în subsistemul

OBIECTIV

Subobiectiv SS

INj1

INj2

IjNINI

Indicatori

ISSj1 ISSj1 ... ISSj1

OUj1

OUj2

OUSjNIND NIND

Figura 6.3. Derivarea indicatorilor din subobiective

60

SSj identificat; fiecare dintre sistemele de bază enumerate se caracterizează prin factori de evoluţie cărora li se asociază variabile; completitudinea listei factorilor este analizată cu luarea în consideraţie a listelor de variabile şi de factori ale celor patru sisteme; dacă lista iniţială ale factorilor, rezultată din specificaţii, are NFj componente, iar prin procesul de analiză rezultă că trebuie eliminate DNFj componente şi trebuie adăugate ANFj, se calculează indicatorul gradul de definire a listei factorilor GDFj.

jjj

jj ANFDNFNF

NFGDF

++=

care arată cât de diferită este lista iniţială definită în specificaţii faţă de lista factorilor care trebuie să stea la baza dezvoltării sistemului informatic. Şi în acest caz, dacă GDFj ∈ (0,92; 1], înseamnă că specificaţiile conţin o listă completă de factori de influenţă a evoluţiei subsistemului SSj. Lista de factori construită în procesul de analiză a specificaţiilor, având numărul de componente NFAj = NFj + ANFj - DNFj, este utilizată în a identifica diferenţele pe care le generează noncalitatea unor specificaţii. Folosind conţinutul specificaţiilor existente, se analizează modul de utilizare a imputurilor în vederea obţinerii outputurilor cu ajutorul indicatorilor. Auditorii construiesc tabele indicatori/outputuri, indicatori/inputuri şi, respectiv, output-uri/inpu-turi, aşa cum se arată în tabelele 6.4, 6.5 şi 6.6.

Utilizarea inputurilor în indicatori Tabelul 6.4

InputuriIndicatori

INj1 INj2 ... INjk ... INjNINI

ISSj1 ISSj2

.

.

.

ISSji jjkW

.

.

.

ISSjNIND

61

Utilizarea outputurilor în indicatori

Tabelul 6.5 Outputuri

Indicatori OUj1 OUj2 ... OUji ... OUjNINO

ISSj1 ISSj2

.

.

.

ISSjk jjkq

.

.

.

ISSjNIND

Utilizarea inputurilor pentru obţinerea outputurilor Tabelul 6.6

InputuriOutputuri INj1 INj2 ... INjk ... INjNINI

OUj1 OUj2

.

.

.

OUji jjkr

.

.

.

OUjNINO

Pentru construirea tabelelor se iau în considerare variabilele:

NINIj – numărul de variabile de intrare ale subsistemului SSj; NINOj – numărul de variabile rezultative ale subsistemului SSj;

jikw – element cu valoare 1, dacă indicatorul ISSji utilizează variabila de

intrare INkj definită pentru subsistemul SSj;

62

jikq – element din matricea output/indicatori pentru subsistemul SSj, care

are valoarea 1 dacă indicatorul ISSjk este utilizat pentru a se obţine outputul OUji;

jikr – element din matricea output/input-uri, care are valoarea 1 dacă

variabila INjk participă la obţinerea variabilei rezultative OUji.

În cazul în care între variabile sau între indicatori nu există legătură, elementele matricelor au valoarea zero.

După completarea celor trei seturi de matrice pentru toate subsistemele companiei,se trece la pasul următor care constă în :

⇒ analiza fiecărui set de trei tabele pentru a se vedea reprezentativitatea la nivelul fiecărui subsistem; se studiază pentru a vedea dacă există linii sau coloane în tabele care au valoarea O, ceea ce corespunde definirii unei componente inutilizabile; analiza tripletelor evidenţiază definiri multiple de indicatori, indicatori redundanţi, indicatori neconsistenţi; o analiză atentă a liniilor tabelelor evidenţiază modul concret în care variabilele contribuie la definirea fiecărui indicator; analiza coloanelor evidenţiază frecvenţa cu care apare un element în construirea altor elemente; în cazul în care sunt definite linii şi coloane ortogonale, sarcina procesului de auditare este uşurată, ceea ce dovedeşte o bună distribuire a cauzelor pe efecte; de exemplu, pentru subsistemul SS7 al unei companii se definesc tabelele 6.7, 6.8 şi 6.9;

Utilizarea inputurilor în indicatori Tabelul 6.7

InputuriIndicatori IN71 IN72 IN73 IN74 IN75

ISS71 1 1 0 0 0 ISS72 0 0 1 0 0 ISS73 0 0 0 1 1

Utilizarea outputurilor în indicatori

Tabelul 6.8 Inputuri

Indicatori ISS71 ISS72 ISSj73

OU71 1 0 0 OU72 0 0 1 OU73 0 1 0

63

Utilizarea inputurilor pentru obţinerea outputurilor Tabelul 6.9

InputuriIndicatori IN71 IN72 IN73 IN74 IN75

OU71 1 1 0 0 0 OU72 0 0 0 1 1 OU73 0 0 1 0 0

Pentru acest exemplu analiza evidenţiază că indicatorii sunt bine

definiţi, iar legătura dintre inputuri şi outputuri nu generează confuzii şi inconsistenţă.

⇒ analiza reuniunii de grupuri de tabele pentru a se vedea cum sunt realizate definirile la nivelul întregului sistem; sunt luaţi spre analiză indicatorii comuni subsistemelor pentru a se vedea dacă inputurile, respectiv output-urile, au acelaşi nivel de omogenitate; aceiaşi indicatori au aceleaşi formule de calcul, iar inputurile se exprimă pentru toate subsistemele cu aceleaşi unităţi de măsură; indicatorii care diferă de la un subsistem la altul sunt analizaţi pentru a vedea dacă diferenţele sunt sau nu reale; în cazul în care indicatorii noi au substanţă, sunt analizate componentele şi se face analiză dimensională; analiza la nivelul subsistemelor trebuie să evidenţieze care outputuri ale subsistemului SSj-1 devin input-uri pentru subsistemul SSj şi cum se distribuie celelalte outputuri pentru a deveni inputuri pentru subsisteme mai îndepărtate ca poziţie de subsistemul SSj sau subsisteme precedente subsistemului SSj-1, figura 6.10.

SSj-1

SSj

Figura 6.10. Transformarea outputurilor în inputuri

64

Sunt situaţii în care un output devine input multiplu, figura 6.11;

se produc pe durata analizei grupării de variabile şi se consideră erori de definire outputuri care nu devin inputuri pentru nici un subsistem al companiei; tot în categoria erorilor intră şi situaţia în care un output al subsistemului SSj-1 devine input pentru acelaşi subsistem; sunt şi alte definiri a căror interpretare conduce la neconcordanţe în interiorul specificaţiilor; regulile, care se definesc pentru interpretarea tabelelor şi diagramelor construite de auditori pe baza textului specificaţiei, reprezintă modul specific de auditare al fiecărei echipe de auditori.

Toate comparaţiile specificaţiilor cu ceea ce trebuia să conţină acestea, prin utilizarea listelor de factori actualizate, conduc la redactarea unui raport de auditare complet. În continuare, toate celelalte etape ale auditării vizează produsul dezvoltat pe specificaţiile existente. Referirile la necesarul impus de actualizarea specificaţiilor sunt necesare pentru a explica riscurile obţinerii unui sistem informatic pe o altă temelie decât cea pe care se cuvenea să se dezvolte o construcţie diferită din punct de vedere al utilizatorului şi al elaboratorului.

SSj-2 SSj-1 SSj SSj+1

Figura 6.11. Transformarea unui output în input multiplu

65

7. AUDITUL PROIECTULUI DE SISTEM INFORMATIC

Proiectul sistemului informatic este realizat pe baza specificaţiilor. Cele mai multe dintre proiecte sunt structurate pe subsisteme. Există numeroase produse informatice complexe care, printr-o bună parametrizare, generează un sistem informatic customizat, capabil să răspundă cerinţelor companiei. Aceste produse au fost proiectate pentru funcţiile întreprinderii. Se specializează persoane care să definească parametri pentru subsistemul de aprovizionare, pentru subsistemul de producţie, pentru subsistemul de desfacere, pentru subsistemul financiar-contabil etc. Indiferent de metoda folosită, indiferent de mediul de dezvoltare utilizat, numai un proiect bun are menirea de a dezvolta un sistem informatic operaţional. Metodele, tehnicile şi instrumentele au menirea de a uşura munca, de a sistematiza informaţii, de a minimiza inconsistenţele. Eforturile cele mai importante destinate definirii de entităţi, grupării acestora, realizarea modulelor, specificarea conexiunilor, aparţin designerilor sistemului informatic.

Pornind de la listele şi tabelele rezultate din analiza specificaţiilor se trece la studirea proiectului. Un proiect de sistem informatic este dezvoltat pe mai multe niveluri.

Primul nivel, cu gradul de agregare cel mai ridicat, identifică subsistemele care intră în componenţa sistemului.

Al doilea nivel, corespunde unei detalieri mai accentuate, în care se disting părţile ce alcătuiesc subsistemele şi fluxurile care au fost definite.

Al treilea nivel conţine detalii de organizare a operaţiilor şi a operatorilor. Diagramele diferă în funcţie de modul în care este abordată soluţionarea din punctul de vedere al tehnologiei abordate. Gruparea operanzilor şi operatorilor prezintă o importanţă specială întrucât influenţează definirile specifice implementării algoritmilor de regăsire a informaţiei după una sau mai multe chei.

Al patrulea nivel conţine reprezentări suficient de detaliate care se constituie în specificaţii de programare.

66

Activitatea de auditare a proiectului trebuie să traverseze toate cele patru niveluri de detaliere. Se stabileşte măsura în care nivelul următor este rezultatul direct al detalierii elementelor definite în nivelul precedent. În cazul în care pe nivelul precedent sunt elemente nedetaliate pe nivelul următor sau detalii de pe nivelul curent nu au corespondent pe nivelul precedent, se semnalează ca element de contradicţie în proiect.

Dacă specificaţiile au un nivel de detaliere ridicat, proiectul sistemului informatic urmăreşte cu mai mare precizie fiecare detaliu din specificaţii, creându-se premisa unei abordări cât mai fidele.

În dezvoltarea unui proiect trebuie respectate o serie de reguli, iar procesul de auditare are menirea de a analiza dacă aceste reguli au fost respectate.

În primul rând, variabila asociată unui factor este unică, pentru că factorul este unic.

În al doilea rând, un indicator are o singură expresie analitică. Două expresii analitice aparţin la doi indicatori diferiţi numai dacă expresiile sunt diferite.

În al treilea rând, un indicator este evaluat o singură dată pentru un set de date. El nu va apărea spre a fi evaluat cu acelaşi set de date şi într-o altă componentă a proiectului.

În al patrulea rând, pentru regruparea tuturor datelor operează un singur criteriu. Introducerea mai multor criterii de regrupare a datelor creează condiţii favorabile creşterii riscului în gestionare a redundanţei în sistemul informatic care se dezvoltă în etapele următoare. Criteriul colectivităţii presupune existenţa unor colectivităţi omogene. Datele se grupează pentru descrierea completă a elementelor din fiecare colectivitate. Criteriul evenimentelor prevede definirea de activităţi, resurse, momente şi durate, iar datele se grupează strict pentru a defini complet mulţimile de evenimente.

În al cincilea rând, proiectul include componente care vizează operaţii fundamentale precum iniţializări, sortări, reutilări, concatenări, adăugiri, calcule, extrageri, regăsiri, modificări, afişări, actualizări, reorganizări etc.

Experienţa în designul sistemului permite gruparea indicatorilor IS11, IS12, ..., ISNSS,INNSS şi a variabilelor pe o structură ierarhizată, astfel încât la baza arborescenţei se află indicatorii cu cel mai redus nivel de agregare, iar

67

la nivelul cel mai ridicat sunt indicatorii cei mai sintetici, profit, cifră de afaceri şi rentabilitate, figura 7.1.

Modul în care se realizează regruparea indicatorilor este rezultatul analizei interdependenţelor indicatori – factori (inputuri), indicatori – outputuri. Prezintă o importanţă specială asigurarea unui nivel ridicat de ortogonalitate în procesul de elaborare a structurii arborescente.

Oricare este tehnologia de dezvoltare a sistemului informatic, structura arbore cerinţe – rezultate al designerului de sistem crează baza de încapsulare separată a variabilelor şi încapsulare indicatori sau neîncapsulare a variabilelor cu indicatorii.

În primul caz se obţin două mulţimi diferite de componente omogene, rezultat al încapsulării.

În cel de al doilea caz se obţine o singură mulţime în care componentele sunt rezultatul încapsulării de variabile şi indicatori.

Analistul proiectului are menirea de a stabili dacă structura arborescentă este completă, are numărul de niveluri corect obţinut. Carenţele structurii sunt:

- interschimbul de niveluri, în sensul că un indicator agregat devine indicator simplu sau invers;

- interschimbul pe acelaşi nivel, ceea ce antrenează regruparea de variabile cu consecinţe directe asupra creşterii numărului de variabile comune mai multor regrupări de date;

- realizarea unor legături incorecte între nivelul inferior şi nivelul superior ale nodurilor arborescenţei; în acest fel indicatorii agregaţi au ca inputuri indicatori simpli nenecesari sau pentru calculul indicatorilor agregaţi lipsesc indicatori simpli.

Indicatori sintetici

Indicator agregat Indicator agregat

Indicator primar 1

Indicator primar 2

Indicator primar k-1

Indicator primar k

Figura 7.1. Structura ierarhizată a indicatorilor

• • •

68

Se observă că în auditul proiectului sunt preluate numeroase elemente din specificaţii. Elaboratorul sistemului informatic dispune de o echipă de designeri de sistem care, prin modalităţi eficiente de comunicare, dezvoltă proiectul, verifică de fiecare dată specificaţiile cu cerinţele reale ale utilizatorilor. În mod normal, între toate construcţiile existente în documentaţie şi ceea ce rezultă în procesul de auditare, diferenţele trebuie să fie nesemnificative. În realitate apar diferenţe care, dacă nu semnificative, sunt diferenţe numeroase, generând neconcordanţe, unele afectând semnificativ utilizabilitatea sistemului informatic. Documentaţia de auditare a proiectului de sistem informatic conţine liste care permit agregarea de indicatori, conducând în final la un singur indicator, care clasifică proiectul ca fiind foarte bun, bun, satisfăcător sau nesatisfăcător.

În faza de definire a proiectului apar o serie de detalii privind: - stabilirea domeniilor de variaţie a variabilelor de intrare şi

domeniile variabilelor rezultative; - dimensiunile seturilor de date; - cheile de regăsire a datelor; - funcţiile de prelucrare care se dispun pe o structură arborescentă

iniţială; - fluxurile de date; - amplasarea punctelor de colectare a datelor în locuri precizate

din companie; - stabilirea nivelurilor de securitate pentru fiecare punct de

colectare/extragere a datelor; - definirea formatelor de prezentare a rezultatelor; - stabilirea nivelului de validare a datelor de intrare; - stabilirea arhitecturii pe care se dezvoltă sistemul informatic; - definirea echilibrului dintre outputurile imprimate şi cele în

format electronic; - stabilirea modului de arhivare a informaţiilor referitoare la

perioade trecute de timp. Se creează o imagine completă a produsului finit care, în final, va

conţine software, baze de date, echipamente şi va fi conectat prin fluxuri de informaţii spre puncte de lucru prin accesare condiţionată.

Auditul acestui proiect ia în analiză toate aspectele. De exemplu, în cazul analizei sistemului de parole se inventariază punctele de acces care se amplasează la nivelul companiei. Amplasamentul fizic este corelat şi cu utilizarea. Posturile de lucru dedicate, restricţionate prin anumite tipologii de acces, permit o bună disciplinare a utilizatorilor sistemului. Fiecare utilizator are drept de acces la resursele sistemului numai în anumite puncte

69

de lucru. Se are în vedere apropierea de locul în care utilizatorul îşi desfăşoară activitatea.

În mod curent, în practică, există mai multe tipologii de parole de acces, în raport cu drepturile asupra resurselor sistemului şi anume:

- chei de acces total la dispoziţia administratorului sistemului; acest tip de acces permite lucrul pe componente, schimbarea drepturilor de acces pentru toţi ceilalţi utilizatori; administratorul este cel care realizează interfaţa sistemului, inclusiv cu cei care asigură întreţinerea sa curentă;

- chei de acces la operaţii de mare risc asupra bazei de date, precum operaţiile nestandard, corespunzătoare unor preluări accidentale, care presupun luarea unor decizii majore privind sistemul de producţie, operaţii financiare;

- chei de acces pentru efectuarea unei singure operaţii – adăugarea de informaţie; întrucât fiecare utilizator este specializat, prin introducerea parolei se produce şi asocierea operaţiei pentru câmpul de prelucrat; de exemplu, parola unui vânzător atrage după sine asocierea cu operaţia de scădere din stoc a produselor vândute;

- chei de acces consultare întreaga colecţie de informaţii, corespund unei categorii de utilizatori; este vorba de utilizatorii care fac parte din echipa managerială; ei au dreptul de a consulta numai baza de date; unele aspecte fac obiectul consultări în grup;

- chei de acces pentru consultare parţială a bazelor de date; corespund unei largi categorii de utilizatori;

- chei de acces la informaţii de interes general, privesc indicatori agregaţi ai companiei;

- chei de acces personale care permit accesul strict la datele personale ale individului; fiecare salariat are o astfel de cheie.

Accesul la informaţia publică este liber. Auditul parolelor stabileşte măsura în care persoanele din companie, în calitate de utilizatori, au o singură parolă. Modul de distribuire a parolelor şi de gestionare a acestora constituie, de asemenea, obiectul auditului. Este important să se definească un sistem de parolare şi gestiune a parolelor. În cazul în care se acordă o parolă şi utilizatorul îşi defineşte parola sa, se impune definirea unui alfabet propriu de construire a parolelor, astfel încât prin regulile definite să se asigure un nivel de securitate ridicat. Auditul sistemului de parole este important prin modul cum califică protecţia sistemului informatic faţă de operaţiile accidentale. Este important ca fiecărui utilizator să-i fie analizată activitatea prin consemnarea:

- numărului de operaţii efectuate zilnic; - calitatea operării de către utilizator; - numărul de incidente de prelucrare, diferenţiat pe tipuri.

70

Există necesitatea ca proprietarul sistemului să asigure un nivel de concordanţă şi o proporţie adecvată între structura sistemului informatic şi capacităţile de acces la acestea în punctele de lucru din companie. În cazul în care există dezechilibre, apar fie posturi de lucru neutilizate, fie fire de aşteptare, cu efecte negative asupra proceselor din companie.

Faza de design a sistemului acordă nivelul de modernitate a acestuia. Dacă echipa de designeri stăpâneşte tendinţele moderne de analiză şi proiectare, soluţia oferită este, de asemenea, modernă. În caz contrar, se obţine o soluţie veche, caracterizată printr-un mod rigid, hibrid şi neperformant de lucru.

Se stabilesc clasele de parole CPR1, CPR2, .., CPRNPR şi tipurile de utilizatori UZ1, UZ2, .., UZNUZ ai resurselor sistemului informatic. Se construieşte matricea de corespondenţe dintre utilizatori şi parole, tabelul 7.10.

Corespondenţa utilizatori/parole Tabelul 7.10

ParoleUtilizatori CPR1 . . . CPRi CPRNPR

UZ1 ...

UZj UCji ...

UZNUZ

Elementul UCji are valoarea 1 dacă utilizatorii clasei UZ dispun de parole de clasă CPRi. În caz contrar UCji = 0. Ideal este ca:

∏ ∑∏ ∑= == =

=⎟⎠

⎞⎜⎝

⎛=⎟⎟

⎠

⎞⎜⎜⎝

⎛ NUZ

j

NPR

iji

NPR

i

NUZ

jji UCUC

1 11 11,

adică unei clase de utilizatori să-i corespundă o singură clasă de parole.

Se consideră mulţimea operaţiilor care se efectuează de către utilizatori, avănd elementele OU1, OU2, .., OUNOU. Aceste operaţii sunt:

- numai consultare; - ordonări de n-tuple de date; - extrageri spre afişare sau copiere seturi de n-tuple de date; - adăugare de n-tuple; - adăugare de n-tuple cu efecte directe unice asupra seturilor de

bază; de exemplu, prin vânzarea unui produs este afectat numai stocul de

71

produse din depozit; adăugarea articolului ce corespunde operaţiei de vânzare are numai un efect direct asupra unui alt articol din setul de informaţii destinat produselor finite;

- adăugarea de n-tuple cu efecte directe în cascadă asupra unui şir de articole din setul de date de bază; de exemplu, adăugarea unui n-tuplu de date ce corespunde modificării sortimentului de produse care se realizează, afectează direct articolele din setul de date de bază privind aprovizionarea cu un număr de materiale, gradul de încărcare a utilajelor, utilizarea forţei de muncă, precum şi articole ce privesc stocurile planificate din depozitul de produse finite;

- efectuarea de calcule pentru o serie de indicatori; - managementul sistemului informatic însuşi.

Aceste operaţii sunt puse în corespondenţă cu clasele de parole, tabelul 7.10.

Corespondenţa operaţii/parole Tabelul 7.10

ParoleOperaţii CPR1 . . . CPRi CPRNPR

OU1 ...

OUj COji ...

OUNOU

Ca şi în cazul matricei precedente, elementul COji are valoarea 1 dacă pentru operaţia OUj este atribuită parola CPRi şi COji = 0 în caz contrar.

În procesul de auditare a proiectului se urmăreşte măsura în care designerii clarifică problematica definirii de clase distincte şi dezvoltă atribuiri de resurse care nu generează ambiguităţi.

Noile tehnici de proiectare includ numeroase instrumente care din start îi asistă pe designeri şi îi orientează spre a asigura această proprietate atunci când sunt construite perechi de clase, triplete de clase sau chiar în cazul în care se dezvoltă k-tuple de clase. Şi în cazul auditului proiectului, documentaţia este laborioasă şi vizează în primul rând laturile calitative ale soluţiei adoptate. Elementele cantitative sunt un suport real pentru calitatea proiectului, însă, există numeroase modalităţi de a compensa absenţa lor în etapele următoare de dezvoltare a sistemului informatic. Direcţia de dezvoltare o dă calitatea arhitecturii definită prin proiect. Clase clar definite,

72

operaţii de agregare a claselor dispuse într-o arborescenţă echilibrată, proceduri cu grad de generalitate ridicat, sunt numai câteva din obiectivele pe care designerii trebuie să le atingă. Auditul de proiect de sistem are menirea de a constata gradul în care aceste obiective au fost îndeplinite. Designerii construiesc matrice, liste, arbori. Aplicând aceleaşi principii, auditorii identifică elemente lipsă, interschimbări de poziţii, elemente suplimentare, obţinând matrice, liste şi arbori proprii care diferă mai mult sau mai puţin de construcţiile designerilor sistemului informatic. Se impune construirea unui indicator care să reflecte gradul de asemănare dintre două matrice.

Se consideră matricele:

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛=

987654321

A

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛=

987654321

B

Pentru matricele A şi B, gradul de asemănare GA(A,B) trebuie să fie

egal cu 1. Se consideră matricele:

⎟⎟⎠

⎞⎜⎜⎝

⎛=

4321

C , ⎟⎟⎠

⎞⎜⎜⎝

⎛=

8765

D

Pentru aceste matrice gradul de asemănare GA(C,D) = 0

Se consideră matricele:

⎟⎟⎠

⎞⎜⎜⎝

⎛=

4321

K şi ⎟⎟⎠

⎞⎜⎜⎝

⎛=

4351

L

În acest caz, gradul de asemănare trebuie să aparţină intervalului

(0;1).

73

Se construieşte o matrice booleană:

⎟⎟⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜⎜⎜

⎝

⎛

=

mnmjmm

iniji

n

nj

bbbb

bbbb

bbbbbbbb

BOO

.................................................

.................................................

............

21

211

2222121

111211

cu bij =1 dacă xij = yij şi bij = 0 dacă xij ≠ yij.

Dacă matricele X şi Y au fiecare m linii şi n coloane, gradul de asemănare a matricelor GA(X,Y) se defineşte prin relaţia:

( )nm

bYXGA

m

i

n

jij

∗=∑∑= =1 1,

În cazul în care numărul de linii şi de coloane diferă la matricele X şi

Y, gradul de asemănare se calculează astfel: - se consideră matricele Xmn şi Ysr ; - se calculează t = min{m, s} şi u= min {n, r}; - se construieşte matricea BOOtu prin comparare elementelor comune din matricele Xmn şi Ysr ; - se calculeză v = max{m, s} şi w= max {n, r}; - se calculează:

wv

bYXGA

t

i

u

jij

srmn ∗=∑∑= =1 1),(

Forma extinsă revine în a înlocui variabilele t, u, v şi w cu formele pe care acestea le au, adică:

},max{},max{),(

),min(

1

),min(

1

rnsm

bYXGA

sm

i

rn

jij

srmn ∗=

∑ ∑= =

74

Dacă se consideră matricele:

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛=

654321

A şi ⎟⎟⎠

⎞⎜⎜⎝

⎛=

69453821

B ,

unde m = 3, n = 2, s = 2, r = 4, rezultă t = 2, u = 2, v = 3 şi w = 4.

⎟⎟⎠

⎞⎜⎜⎝

⎛=

1001

22BOO .

( )61

4*32, 2432 ==BAGA

În procesul de auditare este preferabil ca pentru matrice să se obţină

grade de asemănare cât mai apropiate de 1. Pentru toate aspectele supuse auditării se construiesc tabele, matrice sau alte construcţii, care sunt analizate prin prisma asemănării cu definirile designerilor. Finalizarea procesului de auditare presupune obţinerea unui raport organizat pe niveluri de agregare, iar aprecierea este dată de plasarea unui indicator în zona asociată unui anumit calificativ.

Dacă se consideră indicatorii de asemănare calculaţi de auditori GA1, GA2, ..., GAKG, unde KG reprezintă numărul de aspecte din proiectul sistemului informatic care au fost supuse analizei, indicatorul agregat, GAA, are forma:

KAKA

iiGAGAA

/1

1⎟⎟⎠

⎞⎜⎜⎝

⎛= ∏

=

De exemplu, dacă procesul de auditare ia în considerare:

- modulele de prelucrare G1 = 0,7; - gruparea seturilor de date G2 = 0,9; - cheile de acces G3 = 0,8; - operaţii de gestiune a sistemului G4 = 0,9;

75

rezultă indicele agregat:

821,04536,09,08,09,07,0 4444321 ==∗∗∗== GGGGGAA

ceea ce plasează proiectul informatic în zona proiectelor bune.

Auditul proiectului sistemului informatic trece, prin utilizarea unor indicatori, din zona aprecierilor strict calitative, în zona analizei, având o fundamentare riguroasă. Elementele incluse în liste şi diferenţele devin vizibile şi sunt cuantificate. În acest mod se asigură un grad ridicat de rigurozitate unui proces care mult timp a fost considerat o artă, iar produsul rod al unei inspiraţii ale cărei rădăcini vin dintr-un alt mediu.

76

8. AUDITUL TEXTELOR SURSĂ

A audita un produs software, înseamnă a parcurge etapele codului de audit având ca obiect, mai întâi un text sursă care, dacă trece de etapele de analiză, după compilare şi editare de legături, este lansat în execuţie şi este auditat ca produs finit, validat pentru a obţine o anumită funcţie de prelucrare.

Textul sursă este analizat prin revizii, având ca rezultat o serie de comentarii, din partea membrilor echipei sau a clienţilor, asupra modului în care a fost conceput şi elaborat.

În cazul în care se caută disfuncţionalităţi, prin parcurgerea textului sursă sau prin discuţii asupra locului şi rolului unor instrucţiuni, se evidenţiază comportamnentul statistic al programului, privit ca automat nedeterminat, caracteristică datorată absenţei unor terţi, se obţine o orientare pe auditul bazat pe walk-through.

Un rol special îl are inspecţia textului sursă, care constă în parcurgerea textului pas cu pas, evidenţiind etapele algoritmului şi evaluând capacitatea de generare a erorilor.

Inspecţia are ca obiectiv creşterea calităţii software prin aplicarea unor reguli verificate şi neluate în considerare de către programatorii care au dezvoltat produsul analizat.

Pornind de la specificaţiile de programare unde se prezintă: - datele de intrare; - rezultatele; - modelele de calcul; - seturile de date de test şi rezultatele ce trebuie obţinute. Prin inspecţie, se pun faţă în faţă componentele specificaţiilor cu

secvenţele corespondente din program. Se identifică următoarele situaţii: - mulţimii secvenţelor de texte din specificaţii le corespund

secvenţe de instrucţiuni în programul de sursă; auditul consemnează că programul realizează cerinţele definite în specificaţii;

77

- în mulţimea secvenţelor, unora le corespund secvenţe de text sursă, iar altor secvenţe le corespund astfel de părţi de program sursă; înseamnă că programatorii nu au dezvoltat un produs care să realizeze toate funcţiile de prelucrare care sunt descrise prin specificaţii;

- pe coloana mulţimii secvenţelor de program sursă apar mai multe secvenţe care sunt cerute prin specificaţii; sunt situaţii în care programatorii intuiesc o serie de prelucrări necesare programului, neincluse în specificaţii datorită abordării de suprafaţă a problematicii în textele specificaţiilor.

Aceleaşi situaţii se întâlnesc şi în cazul proceselor de testare. Dacă în planul de testare sunt descrise seturi de date de test, nu înseamnă că testerii chiar urmează planul de testare.

Auditul pe textul sursă are menirea de a analiza modul în care au fost introduse datele de test, ce proceduri au activat şi mai ales de a stabili caracterul parţial sau caracterul complet al prelucrărilor.

Auditul pe textul sursă stabileşte care sunt minusurile din textul sursă sau care sunt definirile în plus, fără a da soluţii, adică fără a genera secvenţele lipsă, pentru a arăta cum trebuie rescris programul.

Textele sursă sunt formule concrete prin care se definesc sistemele de programe, alături de fişiere/baze de date sau alte construcţii care implică date şi relaţii dintre ele.

Textele sursă sunt entităţi bine definite care conţin: - o sublistă de parametri corespunzătoare datelor de intrare; - o sublistă de parametri care corespunde datelor de ieşire,

rezultatelor; - o sublistă care corespunde parametrilor de stare; - o secvenţă de instrucţiuni de iniţializare variabile locale; - o secvenţă de prelucrare, în care în membrul stâng apar elemente

ale sublistei de rezultate iar în partea dreaptă, în expresii apar elemente ale sublistei de variabile de intrare;

- o secvenţă de iniţializare a variabilelor de stare; - o secvenţă care conţine returnarea unei valori globale de stare. Secvenţele de prelucrare sunt astfel construite încât să activeze toate

componentele subsistemelor. Nivelul de complexitate a modulelor depinde de viziunea designerilor. Sunt diferite modalităţi de a concepe structura modulelor. Sunt situaţii în care se precizează că un modul conţine una sau mai multe proceduri. În continuare, se consideră că un modul este format dintr-o singură procedură.

78

Auditul se efectuează pe niveluri. La primul nivel, auditul presupune analiza unei proceduri ca entitate distinctă. Se procedează astfel:

- se constituie un tabel în care pe coloane se află cele trei subliste, iar pe linii se află instrucţiunile;

- se consemnează la intersecţia liniei i cu coloana j rolul pe îl are variabila cu poziţia i în interacţiunea cu poziţia j;

- se analizează tabelul rezultat, observând dacă există linii sau coloane care nu conţin nici un simbol; de asemenea, se verifică dacă sunt respectate regulile de bază privind utilizarea variabilelor din subliste numai cu semnificaţia pe care o au, iar în cazul în care apar inadvertenţe se marchează distinct;

- se construieşte un graf asociat textului sursă, identificându-se secvenţele repetate, absenţa unor operaţii şi dezechilibrele la nivelul proceselor prin numărul arborilor de înălţimi foarte diferite.

Pentru elaborarea unui modul există specificaţii clare, ce prezintă semnificaţia rubricii, algoritmul utilizat, inputurile şi outputurile. Se construieşte un tabel în care pe o coloană se află instrucţiunile, iar pe o altă coloană se află secvenţele de text din semnificaţii. Se identifică una din următoarele situaţii:

- tuturor grupurilor de secvenţe de instrucţiuni le corespund texte de specificaţii; epuizarea secvenţelor epuizează textul specificaţiei;

- secvenţelor de program le corespund texte de specificaţii, fără ca specificaţiile să fie epuizate; înseamnă că procedura nu conţine toate prelucrările; fie ele sunt căutate în alte proceduri, fie se consemnează absenţa prelucrărilor în proceduri; în funcţie de convenţiile de auditare şi de flexibilitatea ipotezelor adoptate;

- unele secvenţe de program au texte corespondente în specificaţii; altele nu au şi specificaţiile sunt incomplete, ori procedura dezvoltă prelucrări noi, în afara specificaţiilor în ideea de a compensa sau de a introduce facilităţi noi acceptate de o nouă viziune a programatorului asupra produsului realizat;

- secvenţe de program nu au texte de specificaţii, iar specificaţiile nu au fost epuizate; programul execută prelucrări noi, nesolicitate şi nu execută minimul de prelucrări cerute prin specificaţii;

- toate secvenţele program au texte de specificaţii şi au rămas secvenţe de program în plus, ceea ce înseamnă că procedura realizează nu numai cerinţele din specificaţii, ci şi lucruri în plus;

79

- unele secvenţe de program au texte de specificaţii, altele nu au, nu au fost epuizate nici specificaţiile, nici textele sursă, înseamnă că procedura efectuează prelucrări necerute, rămânând neefectuate prelucrări impuse prin specificaţii.

Se impune efectuarea unui calcul de distanţă dintre ceea ce conţine efectiv programul şi ceea ce trebuia să conţină. Un program PROGi are un nivel de complexitate Ci, iar un program PROGj are nivelul de complexitate Cj. Secvenţele comune celor două programe au complexitatea Cij = C(PROG1 ∩PROG2). Un indicator de asemănare se defineşte prin:

( )( )21

21

PROGPROGCPROGPROGCDA

∪∩

=

Rezultă că distanţa DA = 0, dacă cele două programe sunt identice,

iar distanţa DA =1, dacă cele două programe nu au instrucţiuni de prelucrare comune. În acest caz, complexitatea este văzută chiar ca număr de instrucţiuni. De exemplu, se consideră secvenţele de program:

a = 7; S1 : b = 8; c = 9;

S2 : if (a > b) c = 3; if (x - y) z = 8;

Număul de instrucţiuni rezultat din reuniunea secvenţelor S1 şi S2

este: C(S1 ∪ S2)= 5

Numărul de instrucţiuni comune celor două secvenţe C(S1 ∩ S2)= 0 Rezultă că asemănarea DA = 0. Pentru secvenţele:

a = 7;

S1 : b = 8; c = 9;

80

a = 7; S2 : if (x-4) i++;

for (i = 0; i< n; i++) x[i] = 1; c = 9; rezultă:

C(S1 ∩ S2)= 2 C(S1 ∪ S2)= 5

indicatorul de asemănare 52

=DA

Pentru modulele MO1, MO2, ..., MONMOD se calculează indicatorii de asemănare cu modulele MO’1, MO’2, ..., MO’NMOD , DA1, DA2, ..., DANMOD şi rezultă un indicator mediu:

NMODNMOD

iiMED DADA

/1

1⎟⎟⎠

⎞⎜⎜⎝

⎛= ∏

=

cu care se plasează întregul proces de analiză internă în zona modulelor reanalizate foarte bine, bine, satisfăcător, sau în zona modulelor nesatisfăcătoare.

Următorul pas care trebuie realizat constă în analiza modulelor în interdependenţa lor. Specificaţiile stabilesc legăturile dintre proceduri. Auditul textului sursă are menirea de a analiza traiectoriile fluxurilor dezvoltate de proceduri. Mai întâi sunt analizate modulele cu legături directe spre nivelul inferior, figura 8.1. După aceea se analizează modulele cu legătură directă spre nivelul superior, figura 8.2. În final se analizează simultan fluxurile de interacţiune ale modulului mijlociu, figura 8.3.

Figura 8.1. Analiză top down

Nivel mijlociu

Nivel inferior

81

Legăturile seriale dintre module, de forma dată în figura 8.3, impun ca modulul MO1 să asigure introducerea datelor, iar modulul MOn să determine afişarea de rezultate.

Apelarea, din aproape în aproape, a modulelor MO1, MO2, ..., MOn-1 prespune stocarea în memorie a tuturor datelor iniţializate în modulul MO1. Dacă modulele au o bună ortogonalitate transmiterea parametrilor se realizează în cascadă. De exemplu, pentru structura liniară de module din figura 8.4 se construieşte tabelul 8.12 de utilizare a variabilelor transmise.

Nivel mijlociu

Nivel inferior

Nivel superior

Figura 8.2. Analiză bottom - up

Nivel superior

Nivel inferior

Figura 8.3. Analiză fluxurilor de interacţine ale modulului mijlociu

82

Utilizarea variabilelor transmise Tabelul 8.12

Parametri

Modul VAR1 VAR2 VAR3 VAR4 VAR5 VAR6 VAR7 VAR8 VAR9

MO1

MO2

MO3

MO4

MO5

MO1

MO2

MO3

MOi

Figura 8.4. Structură liniară de module

MOn

83

Utilizarea variabilelor în module Tabelul 8.13

Parametri

Modul VAR1 VAR2 VAR3 VAR4 VAR5 VAR6 VAR7 VAR8 VAR9

MO1 Read Read Read Read Read Read - - - MO2 IN IN IN IN IN IN Out MO3 IN IN IN IN Out Out - MO4 IN IN Out Out Out MO5 Write Write Write Write Write Write Write Write Write Read – iniţializarea variabilei prin citire IN – utilizarea variabilei în sublista variabilelor de intrare care apar numai

în membrul drept al expresiilor Out – variabile returnate; apar numai în membrul drept al expresiilor Write – variabile care se afişează sau se scriu în fişiere

Analistul evidenţiează gradul de corectitudine în utilizarea variabilelor. Este important ca variabilele să aibă o singură utilizare în cadrul structurii. Ele se iniţializează (Read) o singură dată şi se scriu, de asemenea, o singură dată (Write). Fiind de acelaşi tip, numai IN sau numai Out, apar exclusiv ori numai în membrul drept al expresiilor aritmetice, ori numai în membrul stâng. În cazul în care specificaţiile nu includ reguli

MO1

MO2

MO3

MO5

Figura 8.5. Structură liniară cu cinci module

MO4

84

precise, programatorii dezvoltă, în structuri liniare, utilizări diferite pentru o aceeaşi variabilă, ceea ce conduce la riscuri crescute când modulele sunt realizate de programatori diferiţi, care nu ştiu că valorile unor parametri de intrare au fost alterate de modulele precedente.

Dacă modulele includ apeluri cărora li se creează structuri arborescente, procesul de auditare trebuie să evidenţieze ortogonalitatea prelucrărilor din modulele nivelului descendent, figura 8.6.

Modulul cu precizia j de pe nivelul k, notat MOkj are o listă de

parametri de intrare formată din elementele VARkj1, VARkj2, ..., VARkjx . În cazul cel mai bun de structurare a sistemului în procesul de design, această listă se divide într-un număr de subliste egal cu numărul modulelor descendente. De exemplu, pentru secvenţa de structură arborescentă din figura 8.7, modulul MO1 apelează MO2, şi MO4.

MO1

MO2

MO3 MO4

Figura 8.7.Secvenţă de structură arborescentă de module

MOkj

MOk+1,1

MOk+1,2 MOk+1,L

Figura 8.6. Secvenţă de structură arborescentă de module

• • •

85

Se construieşte tabelul 8.14 pentru analiza modulului în care variabilele sunt utilizate.

Transmiterea de parametri Tabelul 8.14

Parametri

Modul VAR1 VAR2 VAR3 VAR4 VAR5 VAR6 VAR7 VAR8 VAR9

MO1 IN IN IN IN IN IN IN Out Out MO2 IN IN IN MO3 IN IN IN IN MO4 IN IN

Definirile neortogonale utilizează aceleaşi variabile ca inputuri

pentru mai multe proceduri. Şi în cazul structurilor arborescente pe un lanţ de mai multe niveluri

se caută să nu se modifice tipul de utilizare a variabilelor. Sunt situaţii în care unele variabile output pentru modulul precedent devin intrări pentru modulele descendente.

După analiza parametrilor este important ca în procesul de auditare să se analizeze modul în care au fost iniţializate variabilele. Există software care evidenţiază dacă în program sunt utilizate variabile neiniţializate.

Auditarea prelucrărilor presupune stabilirea corespondenţei dintre formulele date în specificaţii şi secvenţele de program scrise. Astfel, pentru evaluarea expresiei:

∑=

=n

iixS

1

trebuie se existe o secvenţă de forma:

S = 0; for (i=0; i< n, i++) S+ = x[i];

Auditorii trebuie să stabilească dacă programele conţin toate condiţiile incluse în specificaţii.

86

Astfel, pentru evaluarea expresiei:

⎪⎪⎪

⎩

⎪⎪⎪

⎨

⎧

<+

=>

=

0107

0)(

2

2

xpentruxx

xpentruxpentrux

xe

în textul specificaţiilor se includ diagrame după care se elaborează scheme logice. Rezultă că programul trebuie să includă textele pentru a separa intervalele şi valorile necesare evaluării corecte a expresiilor, ceea ce conduce la a analiza secvenţa: if (x == 0) ex = 7; else if (x > 0) ex = x*x; else ex = 1/(x*x + x);

Programatorii au la dispoziţie numeroase modalităţi de a dezvolta secvenţe în care se doreşte derularea programelor de optimizare simultan cu procesul de elaborare. Se obţine o construcţie diferită de cea din specificaţii, pe care auditorul trebuie să o perceapă corect. De exemplu, pentru evaluarea expresiilor:

n

xx

n

ii∑

== 1

( )n

xxn

ii∑

=

−= 12σ

se construieşte secvenţa de program echidistantă optimizată: S1 = 0 S2 = 0 for (i = 0; i < n, i++) {S1 + = x[i] S2 + = x[i]*x[i];}

87

22 2 xxxx ii +−∑

2

2 2x

nxx

nxi +− ∑∑

XMED = S1/N SIGMA = S2/n – XMEX * XMED

Această secvenţă este diferită de secvenţa care rezultă direct din specificaţii. S1 = 0 for (i = 0; i< n; i++) S1+= x[i]; XMED = S1/n; S2 = 0; for (i = 0; i < n; i++) S2 += (x[i] – XMED)*(x[i] – XMED); SIGMA = S2/n;

Când se analizează secvenţele de program trebuie căutate sursele de erori care afectează fluxurile de prelucrare, dintre care se enumără:

- lucrul cu variabile neiniţializate; - traversarea unor structuri de date în afara limitelor pentru care au

fost definite; - neincluderea de teste care să evite împărţirea prin zero sau

blocarea unor funcţii care au restricţii asupra intervalelor parametrilor;

- construirea unor expresii care filtrează parţial sau incorect submulţimi de elemente;

88

- restructurarea expresiilor prin schimbarea ordinei de evaluare a unor subexpresii diferite de cele date de specificaţii;

- efectuarea de conversii intermediare deformează rezultatele finale; - construirea expresiilor de referire a elementelor unei structuri care

dezvoltă procese de căutare/regăsire neconcordante cu specificaţiile;

- absenţa manipulării variabilelor de stare a prelucrărilor; - atribuirea de coduri variabilelor de stare după alte reguli decât cele

date în specificaţiile de programe; - alocarea dinamică a unor variabile fără a exista şi procesul de

dealocare; - introducerea unor elemente de neomogenitate; precum citiri,

scrieri de date; - definirea de invarianţi în structuri repetitive, în principal, prin

inexistenţa incrementărilor sau decrementărilor; - neincluderea în secvenţe a unor instrucţiuni corespunzătoare

evaluării unui model sau filtrării, ceea ce conduce la o tratare parţială a problemei;

- atribuirea altei semnificaţii variabilelor cu consecinţe directe asupra rolului şi locului pe care acestea le au în program;

- introducerea de expresii de atribuire care anulează prelucrările precedente;

- compunerea unor construcţii fără a exista o echivalenţă între formulele finale şi cele iniţiale ale acestora.

În auditul software, la fel ca în cazul analizei unei opere literare, există riscul ca specialistul auditor să se transforme într-un fel de critic care analizează un roman în raport cu romanul pe care şi-l imaginează. Această abordare nu este corectă. Specialistul în audit software are în faţă un produs. Acest produs este supus analizei. Sunt câteva reguli pe care auditorul de software trebuie să le aplice pentru a califica o procedură supusă analizei.

Prima regulă este legată de preluarea şi predarea parametrilor. Se analizează corespondenţele dintre listele de parametri şi modul cum sunt folosiţi aceştia.

A doua regulă vizează omogenitatea secvenţelor de program existente. Această omogenitate se referă la gruparea în secvenţe compacte a instrucţiunilor dar şi la utilizarea unor modalităţi ca nume în întreg textul

89

sursă; de exemplu, dacă se preferă utilizarea operatorului de negare cu expresiile condiţionale din instrucţiunea: if (! ( expresie ) ) secvenţa – 1; else secvenţa – 2; atunci astfel de construcţii trebuie să fie folosite peste tot.

A treia regulă vizează stilul de programare. Există multe modalităţi de a ordona activitatea programatorilor. Una dintre acestea se referă la stilul de programare. Stilul de programare se constituie prin reguli definite şi pe care programatorii şi le autoimpun. În final, se obţin construcţii software care nu diferă semnificativ unele de altele, deşi au fost scrise de foarte mulţi programatori.

Auditul software nu are menirea de a analiza cât de mult sau cât de puţin au fost respectate regulile definite ca stil de programare. Se supun analizei secvenţe sau proceduri. Au importanţă din punctul de vedere al auditorului nu formule de realizare a prelucrărilor ci, elemente de esenţă, adică rezultatele, fluxurile pe care le generează. Un program este corect sau incorect prin ce prelucrări realizează. Stilul de programare are un rol, dar nu este esenţial în dezvoltarea de programe corecte.

Un program este bun sau nu este bun. Criteriul de apreciere este definit prin calitatea rezultatelor pe care le oferă atunci când la intrare, DIN, sunt furnizate datele corecte şi complete, figura 8.8.

Rezultatele, REZ, oferite de programul PROG sunt corecte şi complete în raport cu aprecierile făcute de utilizatori prin comparaţie.

DIN PROG

REZ

Figura 8.8. Structura globală a unei proceduri

90

În procesul de auditare sunt utilizate elemente, dintre care un rol aparte îl au rezultatele intermediare.

O problemă PROB se descompune în subproblemele SPROB1, SPROB2, ..., SPROBNSPR, iar fiecărei subprobleme îi corespunde cîte o procedură.

Din cărţi, din documentaţii oferite, din rezolvări manuale ale problemei PROB se obţin, pentru toţi paşii care alcătuiesc subproblemele, rezultate intermediare RINT. Aceste rezultate intermediare obţinute la pasul k sunt utilizate ca date de intrare pentru procedura corespunzătoare subproblemei SPROBk. Auditarea are menirea de a vedea dacă, folosind aceste date de intrare, se obţin rezultatele corespunzătoare pasului Ik, desigur rezultate intermediare, figura 8.9.

SPROBk

Audit comparare

Pasul k al algoritmului

Date intermediare de intrare

Rezultate obţinute de modul

Rezultate calculatre manual

Calificativ

Figura 8.9. Compararea rezultatelor intermediare

91

Fiecare procedură este analizată prin prisma rezultatelor intermediare pe care le furnizează.

Auditul software, dezvoltat ca input pe textul sursă identifică: - structura rezultatelor intermediare; un element, un şir omogn de

elemente, un şir de elemente diferite, un tablou de elemente omogene, un tablou de elemente diferite;

- numărul de elemente diferite care se calculează; - locul unde se calculează fiecare element diferit din structura de

rezultate intermediare; - modul în care sunt manipulate rezultatele obţinute, conversiile la

care se supun, unde sunt stocate şi, mai ales, cum sunt prelucrate de alte proceduri, în continuare.

De exemplu, o structură de rezultate intermediare conţine: α1 – o variabilă în care se stochează elementul minim dintr-o matrice; α2 – un tablou cu două linii şi două coloane ale căror elemente se calculează

după expresiile:

yxa +=11

22212 zyxa ++=

3

21 * zyxa +=

2222 11

1 zx

yxa

++

++

=

α3 – un şir de elemente omogene obţinute cu relaţia 32iii uuw += ;

α4 – un tablou cu trei linii şi trei coloane B obţinut cu relaţia:

32 CCCB ++= ,

unde C este, de asemenea, tot un tablou cu trei linii şi trei coloane. Acestei structuri de rezultate finale trebuie să-i corespundă secvenţe

de instrucţini în procedură, figura 8.10.

α1 bmin = bb[0][0]; for (i = 0; i < n; i++) for (j = 0; j < m; j++) if (bb[i][j] > bmin) bmin = a[i][j];

-------------------------------------------------------------------------------------- 92

α2 a [0] [0] = x + y; a [0] [1] = x*x + y*y + z*z a [1] [0] = x*y + z*z a [1] [1] = x/(1 + y*y) + (x+1)/(1 + z*z); -------------------------------------------------------------------------------------- α3 for (i = 0; i < n; i ++ ) w [i] = u [i]*u[i] + u[i]*u[i]*u[i]; -------------------------------------------------------------------------------------- α4

powmat (c, n, n, 1, B); powmat (c, n, n, 2, C2); powmat (c, n, n, 3, C3); admat (B, C2, n, n, B); admat (B, C3, n, n, B);

Figura 8.10. Secvenţe de instrucţini în procedură

În secvenţa α4 au fost utilizate procedurile de bibliotecă pentru rădăcina de putere a unei matrice şi pentru adunarea a două matrice.

În derularea auditului textului sursă, atunci când se compară structura rezultatelor cu secvenţele de prelucrare, apar următoarele situaţii:

- fiecărei componente din structura de rezultate îi corespunde o secvenţă de instrucţiuni în procedură; se auditează secvenţele pentru a vedea dacă procedurile sunt corecte;

- există componente în structura de rezultate care nu au secvenţe în procedură; înseamnă că procedura rezolvă parţial problema; trebuie căutate secvenţe în alte proceduri pentru a vedea dacă tratarea este completă.

Dacă procedura realizează în plus şi alte prelucrări, este o altă problemă. Ceea ce trebuie să evidenţieze procesul de auditare este strict legat de obiectivul propus.

93

În acelaşi fel se procedează şi cu structura datelor de intrare. Rezultatele intermediare se obţin cu date intermediare de intrare.

Acestea au forma: - unei variabile; - unui grup de variabile dat sub forma unui masiv unidimensional

sau multidimensional; - unei structuri de date dinamice; - unui fişier; - unei baze de date. Tuturor acestor elemente din structura datelor iniţiale trebuie să le

corespundă: - identificatori; - modalităţi de preluare în procedură; un mod din care să rezulte că

au făcut obiectul unei iniţializări. Raportul de auditare pentru software este construit pe niveluri. La nivelul de bază sunt componente care descriu structurile de date

definite pentru utilizare unitară. Analiza calitativă a definirilor vizează domenii şi, mai ales, nivelul de adecvare a structurilor în raport cu prelucrările care se produc în module.

La nivelul următor sunt descrise procedurile. Tablourile pentru auditarea procedurilor conţin indicatori care includ evaluări pentru cât mai multe aspecte legate de:

- modul în care au fost scrise procedurile prin prisma resurselor de limbaj utilizat;

- concordanţa dintre textul sursă şi textul proiectului realizat de designeri; setul de prelucrări pe care le declanşează procedura;

- setul de incidente pe care procedura trebuie să le gestioneze returnând mesaje proprii, fără întreruperea necontrolată a execuţiei secvenţelor.

Raportul de audit pentru o procedură include pe o coloană indicatorii după care s-a efectuat analiza şi pe coloana alăturată nivelul măsurat al fiecărui indicator. Auditorul este obligat să furnizeze un nivel agregat cu care să clarifice într-un mod unic şi fără echivoc procedura analizată.

Activitatea de programare este o activitate de echipă. Componentele care formează software al unui sistem informatic sunt analizate şi prin diversitatea membrilor echipei.

94

Există particularităţi privind: - instrumentele folosite; - limbajele de programare utilizate; - instrucţiuni, comenzi, operatori referiţi; - componente de biblioteci referite; - modalităţi de a dezvolta expresii compuse sau instrucţiuni

agregate; - predilecţia spre a defini anumite structuri de date; - modul de construire a identificatorilor; - concentrarea sau dispersarea instrucţiunilor omogene; - gestionarea transferului spre alte proceduri printr-un sistem

omogen folosind fie o structură secvenţială, fie o structură alternativă multiplă; în ambele cazuri se asigură caracter deschis aplicaţiilor;

- revenirea în procedura apelatoare printr-o singură instrucţiune return (C); atunci cînd sunt utilizate mai multe instrucţiuni, aspectul este stabilit de la început şi acceptat ca regulă nu ca excepţie;

- menţinerea mecanismului de transmitere a parametrilor spre procedurile apelate, în aşa fel încât pentru toate procedurile este păstrat acelaşi mecanism;

- modul de transmitere integrală a structurilor de date, care trebuie să fie în toate procedurile acelaşi pentru aceeaşi structură de date.

La dezvoltarea software un rol special îl are realizarea asamblării de componente şi testarea ansamblurilor rezultante, înainte de a se obţine produsul finit – sistemul informatic. Dacă sistemul informatic are asociată o structură arborescesntă, există două modalităţi distincte de a grupa procedurile şi anume prin:

- separarea procedurilor care asigură operaţiile de intrare, respectiv PROIN1, PROIN2, ... PROINNIN, de procedurile de calcul, respectiv PROCA1, PROCA2, ..., PROCANCA; procedurile de stocare sau de afişare a rezultatelor sunt grupate şi ele PROUT1, PROUT2, .., PROUTNOUT; se obţine o construcţie de forma celei date în figura 8.11; in procesul de mentenanţă o astfel de structură are un mod foarte clar de transformare;

- intercalarea procedurilor, astfel încât să se obţină triplete de forma (PROINi, PROCAj, PROUTk ), iar structura asociată corespunde figurii 8.12; prelucrările se constituie în cicluri complete asigurând o mai mare independenţă de la un rezultat final la altul; structura arborescentă grupează pe un nivel de sus al arborescenţei procedurile de intrare şi cele de ieşire,

95

urmând ca procedurile de calcul să-şi urmeze dezvoltările conform complexităţii specifice algoritmilor de prelucrare.

Este important ca după adoptarea uneia din reguli, toate subsistemele

software care alcătuiesc produsul final asociat sistemului informatic să fie urmată de toţi programatorii.

Software

Software 111 Software ijk Software NIN NCA NOUT

PROIN1 PROCA1 PROUT1

PROINi PROUTk

PROUTNIN

PROCANCA

PROUTNOUT

PROCAj

Figura 8.12. Structură software cu gruparea procedurilor spre finalităţi complete

•••

Software

Software 1 Software 2 Software 3

PROIN1 PROIN2 PROINNIN

PROCA1 PROCANCA

PROUT1 PROUT2 PROUTNOUT

PROCA2

Figura 8.11. Structură software cu proceduri grupate

96

Auditul procesului de asamblare prevede urmărirea pas cu pas a procesului de implozie pe structura arborescentă asociată sistemului informatic. Asamblarea de proceduri conduce la un text sursă compus a cărui analiză trebuie să evidenţieze:

- corespondenţa dintre proiect şi produsul software analizat; - inexistenţa neconcordanţelor generate de definirile diferite şi

utilizările diferite ale aceloraşi entităţi; într-o procedură acelaşi masiv are număr definit de linii şi număr definit de coloane, decât în altă procedură apelată;

- abordarea dinspre detaliu spre ansamblu, pentru a obţine output-urile în structura proiectată;

- coerenţa dezvolărilor bottom-up specifice realizării unui sistem prin proceduri al căror apel conduce la obţinerea unei construcţii cu grad de complexitate din ce în ce mai ridicat, pe măsură ce se avansează spre nivelurile superioare ale structurii arborescente;

- completitudinea fluxurilor de prelucrare; există structuri software în care unele proceduri sunt simetrice, iar alte proceduri au caracter complementar; operaţiile complementare vizează citirea, respectiv, scrierea, concatenarea, respectiv, deconcatenarea; operaţiile simetrice au aceeaşi semnificaţie, însă se execută cu alţi operanzi; auditul software compus analizează şi această latură.

Raportul de auditare software este unul pur tehnic, include liste de componente din proiect care trebuie să se regăsească şi la nivelul software. De asemenea, conţine indicatori de analiză a procedurilor şi a şirurilor de proceduri. În final, transferul de încredere a utilizatorilor în produs se obţine numai în măsura în care în procesul de auditare au fost identificate acele elemente care coincid cu obiectivele utilizatorilor. Produsul software a fost testat de specialiştii care fac parte din echipa care derulează etapele ciclului de elaborare a sistemului informatic.

Calificativul asupra software este dat de auditori după analize pe text sursă şi după ce s-au efectuat testări folosind date de test existente în specificaţii, dar şi cu date de test în structura cerută de auditori. Rezultatul privind calitatea software reprezintă efortul propriu al auditorilor. Analiza rezultatelor obţinute în testarea proprie a produsului conduce la concluzia care se înscrie în raportul de auditare. Concluzia este favorabilă sau nu este favorabilă transferului spre utilizatori a respectivului sistem informatic.

97

În această etapă de auditare, rezultatele fac obiectul unei analize comparate cu rezultatele testării efectuate de echipa de elaborare software.

Inspecţia software se dovedeşte a fi un proces extrem de complex, cu mulţi paşi intermediari, cu multe direcţii de abordare. Presupune un efort de sistematizare a datelor obţinute şi utilizarea unor instrumente de analiză pe măsura tehnicilor şi metodelor de programare întrebuinţate. Numai un proces de auditare software autentic, cu un plan bine întocmit, cu sarcini şi etape clare, conduce la obţinerea de concluzii realiste. Astfel, se dezvoltă riscul de a conchide că un produs software este corespunzător, când, în realitate el este generator de erori. Riscul ca un produs bun să fie respins este redus, întrucât raportul de auditare are numeroase chei de control care să plaseze un produs bun în zona de acceptare prin nivelurile măsurate ale indicatorilor.

Auditul testării şi auditul interfeţelor se tratează distinct, pentru că: - interfeţele reprezintă forme care au la bază proceduri; - interfeţele dau măsura capacităţii programatorilor de a transpune

exigenţele designerilor în programe, în vederea obţinerii efectelor dorite;

- testarea se execută pentru proceduri, pentru grupe de proceduri; - testarea evidenţiază măsura în care procedura execută funcţia de

prelucrare pentru care a fost creată; - testarea reprezintă calea prin care se culeg date privind

comportamentul produsului software. Analizarea interfeţelor presupune parcurgerea mai multor etape, şi

anume: - analiza structurii mesajelor iniţiale, oferite de produs

utilizatorului; - analiza structurii mesajelor pe care utilizatorul trebuie să le

introducă; - evaluarea riscului de întrerupere a interacţiunii om – calculator

datorită complexităţii schimbului de mesaje; - verificarea măsurii în care s-a obţinut o minimizare a efortului

utilizatorilor de a dezvolta interacţiuni prin găsirea unor modalităţi cât mai simple de selecţie a opţiunilor sau de introducere a textelor;

- respectarea regulilor privind amplasarea mesajelor pentru a menţine continuitatea în raport cu alte produse; de exemplu,

98

pentru accesarea resurselor unui produs sunt cerute username şi password după care apare butonul lansare fie begin fie go; o altă definire a accesului are menirea de a-l forţa pe utilizator să procedeze la o adoptare cu efecte fie de respingere, fie de reţinere, fie de risipă de resurse prin încercări eşuate;

- controlul mesajelor pentru a dezvolta aplicaţii ortogonale, fără ambiguităţi; se preferă folosirea de opţiuni pe care utilizatorul să le selecteze.

Auditul testării este un capitol special. În primul rând, se analizează modul cum s-a derulat testarea, ce

tehnici de testare au fost utilizate. Se ia lista de componente software şi se compară rezultatele testării

efectuate de echipe de realizatori ai produsului cu rezultatele testării efectuate de auditori care permit concluzii asupra:

- diferenţelor între calitatea identificată de auditori şi calitatea măsurată de testerii produsului software;

- completitudinei procesului de testare în raport cu volumul şi cu diversitatea testelor existente în specificaţii şi proiectul produsului;

- efectele pe care le-a avut testarea asupra reluării unor etape din ciclul de elaborare software pentru a obţine corecţiile sau îmbunătăţirile necesare.

Testarea este un proces de o importanţă specială pentru ciclul de elaborare software şi pentru managementul calităţii software. De aceea, în procesul de auditare software este dezvoltat un capitol distinct pentru testare, în care se includ analize privind:

- gradul de acoperire a componentelor prin testări pe secţiuni complete de date de test;

- diferenţele dintre testele efectuate şi cele care trebuiau efectuate; - rezultatul comparării datelor obţinute prin testarea echipei de

elaborare software cu datele obţinute de auditori; dacă rezultatele nu diferă semnificativ se acceptă nivelul de performanţă estimat de echipa care a elaborat software; dacă rezultatele diferă semnificativ, trebuie văzut care sunt cauzele care au generat diferenţe; concordanţa dintre rezultatele obţinute pe întreaga traiectorie a asamblării componentelor; unele rezultate devin date de intrare; concordanţa vizează atât testarea independentă pe care o asigură fiecare programator, cât, mai ales, procedurile asamblate; trebuie

99

văzut dacă între rezultatele de la pasul k şi datele de intrare de la pasul k+1 există concordanţă; datele de intrare DINTk+1 sunt datele utilizate de programator când şi-a testat procedura; rezultatele REZk reprezintă output-urile de la nivelul k, figura 8.13; sunt numeroase situaţiile când apar diferenţe între rezultatele de la nivelul k şi datele de intrare necesare la nivelul k+1; aceste diferenţe au cauze profunde şi dacă nu sunt depistate încă în fazele de design de sistem dificultăţile de remediere sunt foarte mari; iar costurile sunt, de asemenea, foarte mari;

- limitele pe care le conţine procesul de testare, prin durata de timp

alocată, prin nivelul de testare impus sau acceptat; testarea se realizează ca etapă distinctă clar cu reluări pe măsura remedierii defectelor de funcţionare a procedurilor; procesul trebuie să fie iterativ convergent; toate testele sunt convenite şi acceptate; dacă se urmăreşte dezvoltarea de produse cu respectarea cerinţelor impuse de normele de calitate specifice stadiului de zero defecte, cheltuielile, perioadele de testare, remediere şi, în general, de creştere a calităţii sunt mult mai importante ca pondere în durata ciclului de realizare software; limitele sunt date de la începutul abordării problemei, când sunt luate în discuţie performanţele sistemului informatic; nu există sistem informatic cu zero defecte, în condiţiile în care software care intră în componenţă nu a fost testat până s-a ajuns, de asemenea, tot la zero defecte;

- seriile de date obţinute de testeri în vederea stabilirii dacă sunt sau nu comparabile; comparabilitatea este dată de respectarea cerinţelor de testare; seturi de date identice, intervale, condiţii hardware similare, proceduri de măsurare a rezultatelor, identice; este important să se ştie dacă datele sunt sau nu comparabile şi se stabilesc coeficienţi de transformare şi se obţin date comparabile; datele comparabile sunt supuse unor prelucrări şi rezultă că sunt reprezentative sau nu; numai după aceea sunt reţinuţi

Procedura K

REZk

DINTk+1

Procedura k+1

Figura 8.13. Concordanţa datelor de test

100

indicatorii care dau nivelurile de calitate; testarea software este finalizată prin raportul de testare care trebuie să urmeze reguli precise de alcătuire, asemenea înregistrărilor privind evoluţia unor procese chimice sau asemenea derulării unui tratament într-un spital; datele din testare sunt esenţiale în tot ce urmează cu sistemul informatic pe durata exploatării.

Raportul de auditare a testării are ca finalitate să stabilească dacă testarea este sau nu reprezentativă pentru sistemul informatic. Se indică toate elementele necesare pentru a obţine o testare software la un nivel cerut de exigenţele impuse asupra sistemului informatic.

Raportul de audit al testării sistematizează prin concluzii datele care vizează întregul proces de testare. Este necesar ca acest raport să fie exigent, profesional, complet şi sistematic. Să nu rămână nici un element netestat. Se enumeră cauzele care stau la baza unor efecte care afectează calitatea produsului finit. Se observă că auditul software este mai mult decât o inspecţie pe codul sursă. Se ia în considerare şi comportamentul produsului în ipoteze apropiate de mediul efectiv de funcţionare.

Raportul de audit dă evaluări privind gradul de satisfacţie pe care îl obţine utilizatorul virtual, prin intermediul interfeţelor la utilizarea sistemului, prin lansarea în execuţie a variantelor de seturi de date asociate unei cazuistici reprezentative.

Auditorul care îşi propune să efectuaze o auditare a textului sursă trebuie să îndeplinească o serie de condiţii precum:

- cunoaşterea în detaliu a limbajului de programare în care este scris programul auditat;

- să se familiarizeze rapid cu stilul de programare adoptat pentru scrierea de către echipa de programatori care a realizat programul;

- să cunoască efectele de antrenare pe care le generează conturarea de secvenţe echivalente sau să stabilească efectele unor procese specifice introducerii recursivităţii sau compunerii de instrucţiuni;

- să fie gata să accepte o multitudine de atitudini din partea programatorilor de a le scrie programul ca produs integral nou sau să scrie programul prin reutilizarea la maximum a componentelor din biblioteci.

101

Auditorul are o listă de erori probabile însoţite de modul direct de producere.

Prin audit se analizează textul sursă pentru a vedea modele de program care includ construcţii generatoare de erori.

Experienţa în activitatea de programare conduce la conturarea listei de evenimente Ev1, Ev2,...Evm împreună cu frecvenţele de operare deduse prin analiza unui lot de N produse program. Evenimentele se ordonează după frecvenţele de apariţie fr1, fr2,... ,frm astfel încât fr1> fr2> ... frm. Pe durata inspecţiei, auditorul se orientează să identifice secvenţele care generează evenimentele Ev1, Ev2,... El nu neglijează nici evenimentul Evm

care are probabilitatea minimă de apariţie. Inspecţia software este asemenea investigaţiilor unui medic care porneşte în stabilirea diagnosticului de la cazurile cele mai probabile, lăsând spre finalul analizei cauzele neprecizate ale efectelor.

Introducerea de reguli verificate în a defini variabile şi în a construi secvenţe omogene, are rolul de a îmbunătăţi procesul de elaborare a codului sursă.

Introducerea regulilor conform cărora procedeele de calcul nu conţin apeluri de proceduri pentru citire de fişiere sau pentru scriere în fişiere, conduce la ameliorarea rapidă a procesului de scriere cod sursă.

Persoanele care execută auditul în texte sursă sunt specialişti recunoscuţi pentru ca inspecţia să fie tratată cu maximă seriozitate.

102

9. AUDITUL DATELOR

Datele care se stochează în mod sistematic în fişiere sau sunt gestionate prin sisteme de gestiune a bazelor de date, sunt supuse auditului ca orice altă componentă a sistemului informatic.

Auditul datelor este un proces complex întrucât vizează acele componente ale sistemului informatic care au ca obiectiv crearea şi actualizarea fişierelor sau bazelor de date.

Auditul acestor componente permite obţinere unei imagini complete în legătură cu capacitatea software de a contribui la realizarea unui nivel cât mai ridicat al calităţii datelor.

Se consideră caracteristicile de calitate CQD1, CQD2, CQD3, ..., CQDNCD ale datelor şi modulele MOD1, MOD2, ..., MODNMD program şi variabilele care sunt manipulate în sistemul informatic.

Orice variabilă este iniţializată prin: - atribuirea unei constante; de exemplu, se definesc variabilele:

int a; float b; ch c;

şi se iniţializează în secvenţa: a = 7; b = -25.81; c = ‘w’ ;

- atribuirea unui rezultat după evaluarea unei expresii; de exemplu în secvenţa:

int a= b, b = 5, c -------------------------------------------- c = a+ b*5;

variabilei c i se atribuie valoarea 33 după evaluarea expresiei;

103

- suprapunerea zonelor de memorie cu ajutorul operaţiei union; de exemplu în secvenţa:

int a, b, c; union {a,c}; b = 5; a = b;

rezultă că variabilele a şi c vor ocupa aceeaşi zonă de memorie; indirect se obţine iniţializarea variabilei c, iniţializată de variabila a;

- copierea variabilelor de tip articol tratate ca şiruri de caractere; - transfer cu conversie din buffere prin apariţii de citire a

fişierelor; - transmiterea prin valoare a parametrilor cu condiţia ca între lista

de parametri reali şi lista de parametri formali să existe o perfectă concordanţă.

Există numeroase cauze generatoare de erori atunci când este vorba de iniţializarea variabilelor. În cazul în care modulele au un grad ridicat de specializare se produce localizarea distinctă a iniţializării variabilelor prin citire din fişiere, indiferent care este tipul de fişier.

Se consideră criteriile de validare CV1, CV2, CV3, ..., CDNCV. Se construieşte un tablou standard de referire a criteriilor de valoare pentru tipurile fundamentale TFD1, TFD2, ..., TFDNTF de date, tabelul 9.15.

Criteriile standard de validare pentru tipurile fundamentale de date

Tabelul 9.15 Tipul fundamental

Criterii de validare TFD1 TFD2 ... TFDj ... TFDNFT

CV1 CV2 ... CVi xxij ... CVNCV

Variabila xxij are valoarea 1 dacă criteriul de validare CVi este asociat tipului fundamental de date TFj. De exemplu, dacă se definesc criteriile:

CV1 – data conţine simbolurilor 0, 1, 2, 3, 4, 5, 6, 7, 8, 9; CV2 - data aparţine intervalului [Linf , Lsup]; CV3 – data este unul dintre şirurile {a1 , a2, …, ak }

104

CV4 – data este mai mare ca zero; CV5 – data este diferită de zero; CV6 – data este mai mică decât zero; CV7 – suma cifrelor care alcătuiesc data aparţine unei mulţimi

{c1 , c2, …, cL }. Lista criteriilor de validare este o listă standard. Designerii o cunosc

tot atât de bine cum o cunosc şi auditorii. Auditorii analizează care dintre criteriile de validare au fost selectate pentru a asigura testele de filtrare care asigură corectitudinea datelor. Datele trebuie să fie complete.

Dacă există o colectivitate CVI pentru care se realizează înregistrarea datelor, având NeCVI componente, problema completitudinii are o dublă abordare.

Prima abordare se referă la iniţializarea tuturor câmpurilor care descriu un element din colectivitate.

A doua abordare se referă la numărul componentelor pentru care au fost introduse date. Dacă numărul componentelor pentru care au fost introduse date este XeCVI, trebuie ca NeCVI = XeCVI.

În cazul în care NeCVI > XeCVI înseamnă că au fost introduse date numai pentru anumite elemente din colectivitate, restul rămânând în afară. Dacă NeCVI < XeCVI, există următoarele surse ale diferenţelor:

- numărul elementelor colectivităţii NeCVI a fost incorect înregistrat şi numărul corect al datelor este XeCVI;

- unele înregistrări au fost realizate de mai multe ori, fiind vorba de înregistrări simple;

- au fost introduse date referitoare la elemente ale altor colectivităţi.

Auditorii trebuie să stabilească despre care dintre situaţii este vorba. Există situaţii în care programele generează numere de identificare a evenimentelor şi acestea devin şi chei de regăsire. Sunt create condiţii de a introduce datele despre un element din colectivitate de nenumărate ori cu asocierea unei alte chei de regăsire. Este important ca auditorii să dispună de software care analizează conţinutul datelor stocate pentru a identifica:

- articolele duble introduse; - concordanţele dintre evenimentele generate efectiv la un post de

operare date şi evenimentele planificate. Analiza datelor este una dintre cele mai dificile etape ale procesului

de auditare întrucât datele influenţează direct, fără condiţii, calitatea

105

rezultatelor finale care se obţin de către un sistem informatic. Din acest considerente, se prezintă, în continuare, aspecte privind particularităţi, catacteristici, metrici şi indicatori de calitate ai datelor.

Se consideră n colectivităţi CVI1 , CVI2 , ..., CVIn fiecare din ele fiind formată din NeCVI1, NeCVI2, ..., NeCVIn elemente. Fiecare colectivitate CVIi, i = 1, 2, ..., n include elemente de acelaşi tip care sunt descrise folosind caracteristicile de diferenţiere i

mii CdifCdifCdif ...,,, 21 .

MCdif1, MCdif2, ..., MCdifn reprezintă numărul caracteristicilor de diferenţiere a elementelor din cadrul colectivităţilor , respectiv CVI1 , CVI2, ...,respectiv CVIn.

Pentru înregistrarea datelor fiecărui element aij din colectivitatea CVIi, care este dispus pe poziţia j în şirul de elemente, se definesc proceduri care vizează:

- realizarea măsurătorilor pentru acele caracteristici de diferenţiere ale căror niveluri sunt de natură cantitativă;

- constatarea unor atribute pentru a defini acele caracteristici cărora li se asociază niveluri de ordin cantitativ;

- punerea în corespondenţă cu elemente ale unei mulţimi finite, atunci când, după efectuarea evaluărilor se produce o agregare a mai multor criterii.

Aceste proceduri trebuie astfel definite încât să asigure reproductibilitatea colectării datelor privind elementele oricărei colectivităţi. Pentru constituirea colectivităţii CVIi şi pentru definirea mulţimii caracteristicilor de diferenţiere i

mii CdifCdifCdif ...,,, 21 se iau în considerare

criterii de apartenenţă şi criterii de diferenţiere care au la bază obiectivul urmărit în colectarea şi în prelucrarea datelor.

Realitatea economico – socială oferă o mare varietate de aspecte şi interpretări, ceea ce impune definirea cu maximă precizie a obiectivului pe care un produs software, o aplicaţie informatică, sau un sistem informatic trebuie să-l aibă atunci când începe derularea codului de dezvoltare. Într-un fel, este constituită mulţimea caracteristicilor de diferenţiere a elementelor colectivităţii când prelucrarea datelor are ca obiectiv o optimizare din punct de vedere structural sau de performanţă şi cu totul altele sunt caracteristicile selectate atunci când obiectivul prelucrării vizează exclusiv latura financiar – contabilă a dinamicii aceloraşi elemente.

106

Pentru un obiectiv stabilit, O, se construieşte un plan care vizează datele problemei de rezolvat incluzând etapele: Etl – precizarea colectivităţilor prin enumerarea lor, CVI1 , CVI2, ...; din

această enumerare rezultă numărul de colectivităţi NCVI; - construirea listelor de caracteristici >< 11

21

1 ,...,, mlCdifCdifCdif ,

>< 222

21 ,..., mlCCC

, ..., >< nmn

nn CdifCdifCdif ,...,, 21 ; - enumerarea procedurilor utilizate pentru înregistrarea datelor. Experienţa designerilor de date este importantă în a realiza o

proiectare corectă, completă şi consistentă. Dacă obiectivul O este stabilirea impozitului pe imobile, în faza de

analiză sunt luate în considerare două colectivităţi (n = 2): CVI1 – colectivitatea persoanelor şi CVI2 colectivitatea imobilelor.

Pentru colectivitatea CVI1 se definesc caracteristicile de diferenţiere: 1

1Cdif - cod numeric personal; 2

1Cdif - nume şi prenume; 3

1Cdif - şir de caractere pentru localizarea în spaţiu; 4

1Cdif - venituri; 5

1Cdif - şir de identificare plăţi electronice. Pentru colectivitatea CVI2se definesc caracteristicile de identificare:

12Cdif - codul numeric personal al proprietarului; 2

2Cdif - suprafaţa construită; 3

2Cdif - suprafaţa locuibilă; 4

2Cdif - an de construire; 5

2Cdif - clasa de confort; 6

2Cdif - clasa de rezidenţă; 7

2Cdif - valoarea de piaţă. După construirea celor două liste de caracteristici rezultă MCdif1 = 5

şi MCdif2 = 7. Este deosebit de importantă stabilirea dimensiunilor celor două colectivităţi.

107

În cazul în care stabilirea cu exactitate este dificil de realizat se propun estimări acoperitoare care permit:

- efectuarea de calcule privind necesarul de memorie externă pentru stocarea datelor;

- stabilirea modalităţilor de înregistrare simultană a datelor din colectivităţi;

- precizarea tehnologiei de asigurare şi control a calităţii procesului de înregistrare şi a calităţii seturilor de date rezultate;

- estimarea costurilor pe care le implică atât constituirea seturilor de date asociate colectivităţilor, cât, mai ales, reluarea procesului de înregistrare dacă nu s-a obţinut nivelul de calitate impus odată cu definirea obiectivului O.

Pentru exemplul considerat, NCVI1 = 1000 şi NCVI2 = 400. Înregistrarea datelor trebuie efectuată pe formulare astfel proiectate,

încât caracteristicile colectivităţilor să fie prezentate cu maximă claritate prin:

- gruparea tuturor caracteristicilor de diferenţiere ale unei colectivităţi într-un singur formular; rezultă că pentru r colectivităţi distincte vor circula r formulare diferite, r seturi de proceduri pentru înregistrarea caracteristicilor specifice;

- regruparea pe un formular a caracteristicilor mai multor colectivităţi, mai ales atunci când datele de identificare a elementelor corespondente sunt comune; manipularea unui număr mai restrâns de documente comparativ cu numărul caracteristicilor este însoţită de reducerea efortului de înregistrare şi de creştere a gradului de concentratrare asupra calităţii procesului de înregistrare date.

Descrierea procedurilor de înregistrare are în vedere totalitatea situaţiilor de pe teren, astfel încât completarea documentelor să fie integrală şi reluarea înregistrărilor prin sondaj să conducă la rezultate identice, dând caracter de reproductibilitate procesului de constituire a seturilor de date asociate caracteristicilor.

Un set de date asociat unei colectivităţi CVIi se prezintă sub forma unui tablou Ti cu TCOLi coloane corespunzător caracteristicilor de diferenţiere i

miii CdifCdifCdif ...,,, 21 şi TLINi linii corespunzător elementelor

ai1, ai2, ..., aiNi care intră în alcătuirea colectivităţii CVIi. Diferenţierea elementelor unei colectivităţi se obţine prin

înregistrarea nivelurilor măsurate, constatate sau deduse la faţa locului pentru fiecare elemente în parte.

108

La constituirea listei elementelor de diferenţiere pentru o colectivitate CVIi se precizează natura fiecărei caracteristici i

jCdif : - element de codificare pentru care se descrie mecanismul de

generare şi mecanismul de verificare a corectitudinii structurii obţinute; - valoare numerică măsurată, indicând instrumentul cu care se

asigură o măsurătoare corectă; - setul complet de atribute din care se extrage unul singur în mod

neambiguu; - algoritmul de evaluare a însuşirilor, de cuantificare şi de punere în

corespondenţă cu un element dintr-o mulţime dată. Setul de date sub forma tabloului cu TLINi linii şi TCOLi coloane

asociate colectivităţii CVIi, pentru a face obiectul unei prelucrări care să satisfacă obiectivul O trebuie să fie de un nivel calitativ deosebit de ridicat. Pentru a stabili care este nivelul calitativ al setului de date se enumeră atributele, caracteristicile de calitate şi metricile de calitate a datelor.

Ortogonalitatea datelor este o caracteristică de calitate deosebit de importantă care arată măsura în care un element aij din colectivitate diferă de un alt element aik sau măsura în care elementul aij diferă de toate celelalte elemente care alcătuiesc colectivitatea CVIi. Datele despre elementul aij se află pe linia j a tabloului Tj corespunzător setului de date înregistrate. Datele înscrise pe linie fie că sunt valori măsurate, fie că sunt atribuite, fie că sunt niveluri puse în corespondenţă cu valori agregate într-un proces de evaluare, sunt considerate cuvinte şi sunt tratate ca şiruri de caractere indiferent de mecanismul de generare. Pe linia j a tabloului Ti se află Ncuvi cuvinte, alcătuind şirul de cuvinte i

jScuv , iar pe linia k a tabloului se află şirul de

cuvinte ikScuv .

Se defineşte funcţia Lg () pe mulţimea cuvintelor vocabularului cu care este construit tabloul Ti cu valori în mulţimea {1, 2, ..., Ncuvi } prin relaţia:

( ) ( )( )i

kijg

ik

ijg

ikij ScuvScuvLScuvScuvL

aaH∪

∩=,

Dacă elementele aij şi aik sunt total diferite H(aij, aik)= 0, iar dacă

elementele sunt identice H(aij, aik)=1.

109

Ortogonalitatea globală a elementului aij este definită ca medie aritmetică a ortogonalităţilor elementului respectiv în raport cu celelalte şi este dată de relaţia:

( )( )

1

,1

−=

∑≠=

i

N

jkk

ikij

ij N

aaH

aHG

i

Pentru prelucrări statistice este rezonabil ca datele să aibă un grad de

asemănare sporit, ceea ce se traduce printr-o ortogonalitate globală redusă. Pentru aplicaţiile economice diferite trebuie să corespundă şiruri de cuvinte diferite, iar ortogonalitatea trebuie să se apropie de valoarea maximă 1.

Consistenţa datelor vizează înregistrările care privesc un element din colectivitate. Proprietăţile elementelor se reflectă şi la nivelul înregistrărilor. Lipsa de consistenţă se manifestă când fie prin măsurători, fie printr-un alt procedeu este trecut în dreptul coloanei i

jCOL de descriere a caracteristicii un nivel în contradicţie cu proprietăţile specifice elementului. De exemplu, pentru elementul aij care reprezintă un material j aflat într-un depozit există pe o coloană descrisă cantitatea existentă în stoc, iar pe altă coloană cantitatea livrată, referirile făcându-se la acelaşi moment de timp. Datele îşi pierd consistenţa atunci când cantitatea livrată este mai mare decât cantitatea existentă în stoc. În acelaşi fel se pierde consistenţa datelor atunci când calificarea unei persoane este cu mult mai mare decât vârsta înscrisă pentru respectiva persoană.

Omogenitatea datelor pentru aceeaşi caracteristică de diferenţiere vizează tipul datei, modul de efectuare a măsurătorilor şi modul de înregistrare. Se stabileşte un domeniu de definiţie pentru fiecare caracteristică în parte, se stabileşte unitatea de măsură a caracteristicilor de diferenţiere. Se urmăreşte ca prin aplicarea aceleiaşi proceduri de măsurare, înregistrările să reflecte situaţia de la faţa locului. De exemplu, pentru caracteristica greutatea unei persoane se stabilesc condiţiile în care se efectuează măsurătorile, ce instrumente sunt folosite, procedurile pe care le urmează persoanele pentru ca rezultatele obţinute să dea cu o exactitate cât mai mare greutatea corporală. Se stabileşte dacă măsurătoarea se face cu rotunjire numai în plus sau numai în minus.

110

Completitudinea datelor vizează reiterarea setului de NrPRODi proceduri pentru cele MCdifi caracteristici de diferenţiere, pentru fiecare din cele Ni elemente ale colectivităţii. Completitudinea datelor conduce la obţinerea unui tablou care are toate şirurile de pe linii sau de pe coloane înregistrate în concordanţă cu domeniile fiecărei caracteristici de diferenţiere.

În cazul în care numărul de şiruri NrSi înscrise în tablou este definit prin NSi < MCdifi × NrPRODi rezultă că setul de date pentru descrierea colectivităţii Ai este incomplet.

Analize statistice se realizează şi pe seturi de date incomplete dacă acestea nu şi-au pierdut reprezentativitatea. În alte aplicaţii economice, toate prelucrările presupun seturi de date complete NSi = MCdifi × NrPRODi.

Accesibilitatea datelor presupune ca datele să fie disponibile uşor, repede, iar algoritmii de căutare şi regăsire să se încheie cu succes folosind criterii dintre cele mai variate, inclusiv definiri incomplete de chei de căutare.

Acurateţea vizează exactitatea, nivelul acceptabil al erorilor conţinute, încadrate în limite stabilite. Procedurile de înregistrare şi dispozitivele de măsurare sunt verificate, iar personalul este instruit să efectueze măsurătorile şi înregistrările conform cerinţelor impuse.

Credibilitatea are la bază acceptarea înregistrărilor ca reprezentând un rezultat real al înregistrărilor. Se consideră că ori de câte ori se reia procesul de măsurare-constatare folosind proceduri echivalente, înregistrările sunt aceleaşi.

Interpretabilitatea datelor presupune definirea unui alfabet, a unor reguli de producţie pentru construirea de şiruri consecutive de simboluri, iar punerea în corespondenţă a cuvintelor cu fapte, evenimente, obiecte din lumea reală aparţin unui limbaj unanim acceptat şi cunoscut.

Obiectivitatea vizează imparţialitatea, lipsa de prejudecăţi, nepărtinirea în a efectua măsurători, în a prelua rezultatul obţinut de la dispozitivele de măsurare şi din aplicarea procedurilor de efectuare a măsurătorilor. Existenţa unor principii etice, a unor argumente ştiinţifice determină eliminarea elementelor care generează subiectivism în constituirea seturilor de date şi, mai ales, în prelucrare pentru obţinerea de rezultate agregate, reprezentative.

Oportunitatea vizează neafectarea de uzura morală a datelor în raport cu un criteriu, cu un moment de timp, cu un nivel de cuprindere, toate

111

stabilite de la început, definitivându-se, în acest fel, un context şi un nivel de exigenţă sub care nu se coboară.

Relevanţa este stabilită în raport cu cerinţe ale utilizatorilor şi vizează corespondenţa dintre rezultatele agregate şi trendul de dezvoltare a colectivităţii de la care provine setul de date.

Alte caracteristici de calitate sunt dependente de reputaţia sursei, claritatea corespondenţei dintre cuvintele unui vocabular şi mulţimea de elemente desemnate din lumea reală.

Profitabilitatea datelor vizează valoarea adăugată care se obţine şi care justifică efortul de definire de proceduri, de achiziţionare instrumente, de angajare a personalului pentru a construi seturi de date organizate în tablourile T1, T2, ..., Tn şi pentru a dezvolta software care să le prelucreze. Pe baza rezultatelor astfel obţinute sunt fundamentate decizii care se deosebesc de deciziile luate empiric prin multiple avantaje. Optimizarea deciziilor dă măsura profitabilităţii.

Atributele calităţii sunt deosebit de numeroase, ele fiind incluse în tabelul 9.16 [IVAN99a].

Atribute ale calităţii datelor Tabelul 9.16

acceptabilitate accesibilitate actualitate acurateţe adaptabilitate agregabilitate alterabilitate amplitudine aspect estetic auditabilitate auto-corectabilitate autoritate bine documentate bine prezentate cantitate capacitate de descărcare

capacitate de identificare erori capacitate de încărcare

certificare claritate claritate surse compactivitate compatibilitate compatibilitatea cu date istorice competitivitate completitudine comportament compresabilitate comprihensivitate concizie conexiuni logice confidenţialitate conformitate consistenţă context continuitate conţinut corectitudine cost cost acurateţe cost colectare creativitate credibilitate criticabilitate curente customizabilitate definire exactă detaliere adecvată detaliere surse dimensiune dinamism dispersie disponibilitate domeniu eficacitate ergonomie expansibilitate extendabilitate extensibilitate fără erori fără greşeli fără pierderi

de informaţii fiabilitate

112

finalitate flexibilitate formă prezentare format generalitate ierarhizare imparţialitate importanţă independenţă de timp integrabilitate integritate interactivitate interesante interpretare semantică localizare manevrabilitate măsurabilitate mediu minimalitate modularitate neambiguitate nivel de abstractizare

nivel de standardizare normalizare

noutate obiectivitate oportunitate optimalitate organizare origine partiţionabilitate pedigree personalizate pertinente portabile posibilitate de urmărire precise prietenoase profunzime răspunde cerinţelor raţionalitate redundanţă regăsire regularitate format reiterare relevanţă reproductibilitate reputaţie responsabilitate rezistenţă rezoluţie grafică rigiditate robusteţe scop secrete securitate semnificaţie sincronizare specificitate stabilitate stocare supraîncărcare surse translatare transportabilitate unicitate uşurinţă acces uşurinţă actualizare uşurinţă comparaţii uşurinţă corelaţii uşurinţă folosire uşurinţă înţelegere uşurinţă interogare uşurinţă interschimb uşurinţă întreţinere uşurinţă modificare uşurinţă regăsire utilizabilitate validitate valoare variabilitate varietate vârstă verificabilitate viteză volatilitate volum adecvat

Dintre aceste atribute se extrag unele care sunt considerate de bază, se stabilesc interdependenţe şi rezultă priorităţi care trebuie urmărite când se planifică nivelurile de calitate a datelor.

Seturile de date diferă unele de altele prin caracteristici de ordin cantitativ şi prin caracteristici de ordin calitativ, ambele trebuind să fie puse în corespondenţă cu valori numerice care să conducă la efectuarea de comparaţii. Punerea în corespondenţă se realizează prin utilizarea metricilor.

Dimensiunea colectivităţii CVIi este dată de numărul componentelor NCVIi care o alcătuiesc. Dinamica proceselor economico-sociale impune o abordare mai largă a conceptului de dimensiune. Astfel, sunt analizate modalităţile de constituire a colectivităţii CVIi şi se stabileşte NCVIMAXi: numărul maxim de componente pe care le-a avut mulţimea CVIi într-un interval de timp [t0, t1], NCVIMINi – numărul minim de elemente, referitoare

113

la acelaşi interval şi NCVIMEDi – numărul mediu de elemante. Aceste mărimi creează o imagine referitoare la nivelul pe care îl va avea NCVIi într-un interval viitor [t1, t2].

Lungime listei caracteristicilor de calitate CQi asociată colectivităţii CVIi este invariabilă pe intervale lungi de timp.

Setul de date asociat colectivităţii este caracterizat prin volumul V(STi). Setul de date este privit ca un text format din cuvinte. Numărul de cuvinte depinde de numărul de coloane şi de numărul de linii ale tabloului Ti asociat colectivităţii CVIi.

V(STi) = NLINi × NCOLi, i = 1, 2, ..., n

În cazul în care setul de date este incomplet, lipsind datele unor coloane întregi în număr de COLi, sau număr de linii complete LINi, rezultă că volumul incomplet de date este dat de relaţia:

VI(STi) = (LINNi - LINi) × (NCOLi - COLi )

Se defineşte relaţia:

V(STi) > VI(STi)

În cazul în care lipsa de date este accidentală, numărul de date lipsă pe linii sau coloane este LCi, volumul afectat de aceste absenţe este dat de relaţia:

VA(STi) = NLINi × NCOLi - LCi

Indiferent de modul în care se constituie seturile de date, este necesar ca diferenţele dintre volumul de date complet şi volumul incomplet, D1, respectiv D2, să traverseze evoluţii astfel încât într-un număr finit de paşi să devină zero. Datele absente trebuie să fie completate înainte de a începe prelucrarea setului de date.

( ) ( )iii STVISTVD −=1

( ) ( )iii STVASTVD −=2

114

Gradul de acoperire a setulul de date Ga este dat de relaţia:

( ) ( ){ }( ) ( ){ }ii

iia STVASTV

STVASTVG,max,min

=

şi are valori cuprinse în intervalul [0;1].

La construirea unei metrici pentru calitatea datelor sunt luate în considerare ipotezele privind:

- caracterul normat al indicatorilor, toate definiţiile trebuind să conducă la obţinerea unor valori calculate, cuprinse în intervalul [0;1];

- senzitivitatea indicatorilor, în sensul că la variaţii mici ale variabilelor exogene, indicatorul calculat să aibă variaţii mici, iar la variaţii mari ale variabilelor exogene, indicatorul să aibă, de asemenea, variaţii mari;

- indicatorul să nu fie compensatoriu, astfel încât pentru diferite valori ale variabilelor exogene să se obţină valori diferite ale indicatorului; dacă indicatorul este compensatoriu, la valori diferite ale variabilelor exogene se obţin aceleaşi valori ale indicatorului;

- indicatorul nu trebuie să fie catastrofic, adică trebuie să fie construit în aşa fel încât să nu existe niveluri ale variabilelor exogene care pentru variaţii foarte mici să genereze variaţii foarte mari ale indicatorului;

- toţi indicatorii se calculează folosind datele din tabloul Ti construit pentru colectivitatea CVIi, i = 1, 2, ..., n;

- folosind datele indicatorilor asociaţi caracteristicilor de calitate CQ1, CQ2, ..., CQMi, respectiv IQ1, IQ2, ..., IQMi şi coeficienţii de importanţă p1, p2, ..., pMi, se obţine indicatorul global al calităţii pentru colectivitatea dat de relaţia:

( )jpMi

jj

iq IQG ∏

=

=1

, i = 1, 2, ..., n

Complexitatea datelor care privesc o colectivitate Ai este dată de: - operanzii care participă în elaborarea prelucrărilor; - operatorii utilizaţi.

115

Dacă se consideră datele din tabelul 9.17, pentru calculul valorii Via a produsului PRODi se foloseşte relaţia , i = 1, 2, ..., r.

Date privind producţia şi preţurile Tabelul 9.17

Produs Cantitate Preţ PRODi PROD2

-

-

- PRODr

Q1 Q2

-

-

- Qr

PR1 PR2

-

-

- PRr

Complexitatea operanzilor şi a operatorilor rezultă din secvenţa de

program asociată prelucrării:

(1) ( 2) 2 3 (4) 4 5 (5) for (i = 0; i < n; i ++) 1 (3 ) (8) ( 10)11 V[j] = Q[i]*PR[i]; 6 7 (7) 8 9 (9)10 C = 11log211 + 10log210

Diversitatea DIVi relativă a datelor colectivităţii Ai este dată de relaţia:

i

i MKDIV = ,

unde K reprezintă numărul tipurilor de date diferite:

Se consideră următoarele tipuri de date: - coduri date ca şiruri de caractere; - indicatori exprimaţi ca numere întregi; - indicatori exprimaţi ca şiruri de litere; - indicatori exprimaţi prin numere virgulă mobilă; - indicatori exprimaţi prin cuvinte dintr-o mulţime cunoscută.

116

Într-un tabel în care sunt consemnate pe coloane cantităţile livrate într-o lună, iar pe linii sunt date produse, tabelul va conţine 31 de coloane pentru cantităţi, toate date ca numere întregi, trei coloane pentru denumirea produsului, codul produsului şi pentru unitatea de măsură, diversitatea tipurilor de date este:

344

=DIV

Mi = 34, tabelul având 31 coloane pentru cantităţi şi 3 coloane pentru

identificare produs. K = 4, corespunzător tipului de date pentru cod produs, denumire produs,

unitate de măsură şi cantităţi; codurile sunt structuri de simboluri care ajută la identificarea produsului; denumirea produsului este un şir de litere; unitatea de măsură este un cuvânt din mulţimea {l, kg, t, m, m2, m3}.

Gradul de omogenitate GOij a datelor din setul asociat colectivităţii Ai, aparţinând caracteristicii de diferenţiere i

jC , se obţine prin relaţia:

{ } { }

∑

∑

=

=

−−=

i

i

N

k

ikj

iijk

ikjk

N

k

ikj

ij

a

aaaGO

1

1maxmin

Dacă se consideră caracteristica de diferenţiere i

jC , definită de un

domeniu definit prin nivelurile [ ]iBA jij ; cu i

jij BA < , având înregistrate

valorile iNij

ij

ij aaa ...,,, 21 , gradul de omogenitate se obţine prin relaţia:

{ } { }

jj

ikjk

ikjki

j AB

aaGO

−

−=

minmax

Obiectivul auditului datelor este de a stabili măsura în care datele de intrare ale unui produs software îndeplinesc cerinţele de calitate pentru a fi prelucrate.

117

Programul de audit date este o construcţie complexă care presupune sarcini precise şi care se finalizează cu un raport de audit.

Auditul datelor presupune: - analiza procedurilor utilizate la înregistrarea datelor şi validarea

acestor proceduri; - stabilirea dacă dispozitivele utilizate pentru efectuarea de

măsurători sunt calibrate şi îndeplinesc cerinţele impuse de standardele cu care se lucrează;

- stabilirea claselor de erori şi, în interiorul clasei, a erorilor specifice.

La înregistrarea datelor se înregistrează erori privind: - stabilirea erorilor legate de codurile de identificare a elementelor

colectivităţii prin neincluderea unui cod, prin interschimbul a două coduri;

- nivelurile unor caracteristici care sunt în afara domeniilor, ceea ce înseamnă afectarea grosolană a măsurătorilor; repetarea nivelurilor înregistrate pentru un element al mulţimii la alte elemente învecinate;

- înregistrarea nivelului caracteristicii ijC în dreptul caracteristicii

învecinate ijC 1− sau i

jC 1+ ;

- înregistrarea nivelului caracteristicii ijC a elementului i

ka fie

corespunzător elementului ika 1− , fie corespunzător elementului

ika 1+ ;

- interpretarea greşită a simbolurilor din alfabetul în care este scris şirul la intersecţia coloanei jCOL cu linia kLIN ;

- transformarea şirului de la intersecţia coloanei jCOL şi a liniei

kLIN prin inserarea unui simbol, prin eliminarea unui simbol sau prin înlocuirea unui simbol cu altul; şirul transformat rămâne în domeniul stabilit pentru caracteristica i

jC ; - transformarea şirului de la intersecţia liniei kLIN şi a coloanei

jCOL , astfel încât să aparţină unei alte clase sau unui alt domeniu;

118

- modificarea dimensiunilor tabloului Ti prin inserarea de noi caracteristici, prin eliminarea de caracteristici de diferenţiere sau prin modificarea numărului de componente oN ale colectivităţii

iA . Auditul datelor are menirea de a stabili: - conformitatea caracteristicilor de calitate ale setului de date STi

colectate, prin măsurători sau constatări la nivelul elementelor mulţimii iA , în raport cu cerinţele beneficiarului, specificate concret prin referirea la standarde, norme şi prin documentaţii special întocmite;

- eficacitatea măsurilor care asigură calităţi referitoare la datele colectate;

- identificarea măsurilor de asigurare a calităţii datelor. Auditul datelor include elemente practice. Se stabilesc regulile cu

care se calculează volumul datelor care este verificat pentru a stabili latura cantitativă globală a datelor. Latura cantitativă, volumul de date, se stabileşte diferenţiat, după importanţa dată documentelor.

119

10. RAPORTUL DE AUDITARE Procesul de auditare se finalizează cu întocmirea unui raport care

conţine propuneri de măsuri de reducere şi de menţinere sub control a riscurilor importante ale noii aplicaţii. Raportul de auditare este o lucrare de sinteză care are la bază o analiză a rezultatelor obţinute din parcurgerea textelor sursă, din lansarea în execuţie a programelor şi din interpretarea rezultatelor finale, mai ales prin interpretarea rezultatelor intermediare şi a celor de urmărire a programului.

Raportul de audit este o lucrare cuprinzătoare care oferă o imagine privind siguranţa pe care o dă produsul. Raportul de audit are un rol esenţial în angajamentele de audit şi asigurare, deoarece comunică verdictul auditorului. Utilizatorii sistemului informatic se aşteaptă ca raportul auditorului să ofere încredere în utilizarea sistemului informatic.

Raportul de audit este un element fundamental al auditării prin intermediul căruia se prezintă situaţia sistemului auditat aşa cum a fost evaluată de auditori. Prin raportul de audit sunt communicate, părţii auditate, aprecierile şi concluziile auditorilor. Obiectivele raportului de audit sunt [AVRA01]:

- redarea încrederii managerilor în sistemul informatic, imediat după terminarea misiunii de audit;

- să ofere redomandări utile referitor la perfecţionarea procedurilor de control şi eficienţa activităţii operative;

- să asigure o înregistrare oficială a activităţii de audit şi a răspunsului managerilor.

În practică, înainte de a prezenta un raport formal, în scris, auditorul are obligaţia de a prezenta un raport verbal celor care răspund de activitatea analizată. Cu excepţia cazurilor de fraudă, când este necesar uneori ca lucrurile să rămână secrete până la prezentarea raportului oficial, în majoritatea cazurilor auditorul discută, în prealabil, cu managerul conţinutul raportului de audit. În acest fel se reduce riscul ca rezultatele auditului să nu fie acceptate de către manager.

120

Raportul de auditare este un text structurat care conţine: - prezentarea contextului; - rezultatul procesului de auditare; - evaluările finale; - înregistrările din fiecare etapă a procesului de auditare. Raportul de auditare conţine detalii privind: - descrierea produsului; - stabilirea condiţiilor de utilizare normală; - operaţiile interzise a fi efectuate folosind produsul; - funcţiunile pe care le dezvoltă în condiţii normale, indicând

intrările, respectiv output-urile; - efectele secundare care apar atunci cînd intrările sunt complete şi

corecte; - riscurile care apar atunci când intrările sunt incomplete şi

incorecte; - modalităţi de reluare a procedurilor de utilizare. Raportul de auditare arată că produsul este utilizabil sau produsul

devine utilizabil dacă se execută o serie de îmbunătăţiri. Raportul de auditare trebuie astfel întocmit astfel încât să fie o

imagine fidelă a programului de auditare, a resurselor, a input-urilor, a output-urilor şi a metodelor utilizate.

Calitatea raportului este dată de modul în care se construiesc componentele. Textul structurat se alcătuieşte pas cu pas prin răspunsuri scurte şi clare la întrebările: cine? ce? cum? de ce? Este obligatoriu ca raporul să includă secţiuni care abordează gradat problematica de audit pentru un sistem informatic.

Prima secţiune include elemente de identificare pentru: - sistemul informatic ce face obiectul auditării; - baza în care se derulează procesul de auditare; - prezentarea echipei de auditori; - prezentarea elaboratorilor sistemului informatic; - prezentarea beneficiarului procesului de auditare. A doua secţiune include elemente pentru: - definirea obiectivului urmărit; - stabilirea metodelor şi tehnicilor stabilite şi acceptate; - structurarea procesului de auditare.

121

A treia secţiune defineşte planul de auditare şi conţţine descrieri pentru:

- etapele care trebuie parcurse; - resursele alocate fiecărei etape: - fluxurile care se generează; - nivelul de exigenţă şi moduri de menţinere constantă a nivelului; - comunicarea între membrii echipei de auditori, comunicarea

auditorilor cu realizatorii sistemului informatic, cumunicarea cu beneficiarii procesului de auditare.

A patra secţiune conţine detalierea tuturor surselor utilizate ca întrebări pentru procesul de auditare:

- contracte; - specificaţii; - proiectul sistemului informatic; - textele sursă; - bazele de date; - rezultatele testării efectuate de echipa care a elaborat sistemul informatic; - documentaţii de proces; - instrumente utilizate de către echipa care a dezvoltat sistemul

informatic. Sunt descrise listele elementelor utilizate cu comentarii privind

calitatea textelor întrebuinţate de auditori. Raportul de audit trebuie să fie clar, concis, constructiv şi întocmit la

timp. Raportul de auditare reprezintă o probă importantă în orice acţiune

declanşată de beneficiarul unui sistem informatic atunci când sunt înregistrate diferenţe semnificative între ceea ce trebuia să execute sistemul informatic şi ceea ce execută în realitate. Raportul de auditare trebuie să fie clar, concis, să nu lase loc la interpretări.

Când se utilizează sintagma <<toate variantele>> înseamnă că pentru cele n noduri terminale ale unei structuri arborescente au fost construite n seturi de date test, atingându-se cele n noduri terminale.

Pentru a nu lăsa loc interpretărilor, din enunţul raportului lipsesc sintagme precum <<în majoritatea cazurilor>>, <<în general>>, <<numai în unele cazuri>>, <<în celelalte situaţii>>, <<nu de puţine ori>>, <<este

122

probabil să>>, <<există posibilitatea ca>> şi toate celelalte construcţii care conduc la concluzii vagi.

Raportul de auditare: - enumeră toate componentele; - analizează toate variantele; - include toate rezultatele; - enumeră situaţiile pe categorii de stări, fără a lăsa unele situaţii

neclarificate; - tratează cu aceeaşi măsură toate componentele; - pentru fiecare situaţie creată se enumeră componentele

identificate; - utilizează pentru componentele aceluiaşi nivel, aceleaşi

instrumente; - este o construcţie consistentă; - include ipoteze, constatări, măsurători care, prin

profesionalismul cu care se realizează, nu au fundamente pentru a fi contestate.

Transparenţa procesului de auditare, rigurozitatea cu care sunt aplicate cerinţele standardelor şi claritatea cu care se prezintă rezultatul auditării dă o singură direcţie destinaţiei raportului şi anume acceptarea concluziilor, indiferent care sunt acestea, de către cel care a solicitat auditul sistemului informatic. Raportul de auditare trebuie să fie convingător pentru a nu face obiectul comentariilor. Trebuie să conţină descrierea unor aspecte evidente care nu fac obiectul comentariilor sau negocierilor. Structura anunţată trebuie respectată, iar textul trebuie să fie consistent. O afirmaţie făcută trebuie cel mult susţinută. Ea nu trebuie nici nuanţată, cu atât mai mult nu trebuie contrazisă.

Este determinant pentru un raport de auditare să fie calitativ peste nivelul documentaţiei, specificaţiilor sau oricărui alt text care provine de la elaboratorii sistemului informatic.

În anexele 5-8 sunt prezentate modele şi exemple de program şi raport de audit, model de notă de nonconformitate, model de listă de verificare.

123

11 . CONCLUZII

Auditul informatic reprezintă o ramură distinctă a auditului. Aici se includ tehnici şi metode de auditare a software, a aplicaţiilor informatice, a sistemelor informatice tradiţionale, a sistemelor informatice moderne, a aplicaţiilor mobile şi a tuturor aplicaţiilor informatice care utilizează resurse Internet. Pe măsura creşterii complexităţii proceselor din societatea informaţională, cerinţele sistemelor informatice impun un nivel de credibilitate deosebit de ridicat pe care numai auditul informatic îl susţine cu succes.

Pe timpul planificării auditului informatic există factori care se iau, în mod obligatoriu, în considerare; aceşti factori determină modul în care auditorul abordează procesul de auditare. Auditorul va lua în considerare nivelul riscurilor generate de utilizarea sistemului informatic.

Auditul sistemelor informatice devine un punct focal al auditului independent, auditul conformităţii şi auditul operaţional. Realizarea auditului sistemului informatic contribuie la:

- îmbunătăţirea sistemului şi controalelor procesului; - prevenirea şi detectarea erorilor şi a fraudelor; - reducerea riscurilor şi îmbunătăţirea securităţii sistemului; - planificarea pentru refacere în caz de accidente şi dezastre; - managementul informaţiilor şi dezvoltării sistemului; - evaluarea utilizării eficiente a resurselor. Auditorul sistemelor informatice trebuie să aibă capacitatea de a

asista echipa managerială în stabilirea mărimii sistemului informatic şi a numărului de personal necesar, domeniile de afaceri în care se utilizează eficient sistemele de calcul, natura afacerilor, pierderi potenţiale în cazul căderii sistemului informatic, extinderea controalelor manuale şi gradul de complexitate tehnică.

Auditul sistemelor informatice este o activitate complexă. Unei activităţi de echipă – realizarea sistemului informatic – îi corespunde, de

124

asemenea, tot o activitate de echipă – auditarea. Pentru a realiza un proces de auditare eficient este necesar să se parcurgă următorii paşi:

- definirea obiectului auditării sistemului informatic; - construirea planului de auditare; - atribuirea sarcinilor fiecărui membru din echipa de auditori; - preluarea structurilor de tabele pentru înregistrarea rezultatelor

auditării; - derularea, pas cu pas, a procesului de auditare folosind standarde,

tehnici şi metode stabilite; - înregistrarea rezultatelor şi evaluarea fiecărei etape parcurse; - regruparea documentaţiei provenite din diferite stadi ale

procesului de auditare şi construirea raportului final. Există două rezultate pentru un produs supus auditării. Primul caz, cel nefavorabil, corespunde situaţiei în care procesul de

auditare conduce la concluzia că există diferenţe esenţiale între sistemul informatic real şi sistemul informatic aşteptat de utilizator; sistemul informatic nu execută integral funcţiile de prelucrare stabilite; rapoartele obţinute sunt numai o parte din cele stabilite; auditorii recomandă completarea cu noi module care să dezvolte şi prelucrările planificate, dar nerealizate; diferenţele care apar sunt cauzate de rezultatele incomplete din raport; se recomandă completarea cu module care aduc rapoartele la nivelul de completitudine necesar; diferenţele se referă la modul de calcul al indicatorilor; se recomandă modificări în secvenţele de program care fie că includ toate elementele de prelucrare, fie că modifică criteriile de filtrare, fie modifică espresiile de evaluare; dacă sunt identificate cauze pe nivelurile superioare ale arborescenţei asociate sistemului informatic cerinţele de modificare cerute în raportul de auditare au o profunzime mai mare. În toate cazurile se precizează care sunt diferenţele şi se stabileşte necesitatea de a fi eliminate sau atenuate. Auditul nu dă soluţii. Raportul de auditare nu transferă credibilitate şi de fapt este raport de constatare. Nu este rezonabil să se întocmească în acest context un raport de audit pentru că elaboratorul are la dispoziţie un document prin care dacă prezintă trunchiat informaţia, lasă să se înţeleagă că sistemul informatic a fost auditat. Dacă se prezintă rezultatul negativ al auditării, se subînţelege că auditarea a fost pozitivă. Elaboratorul de sistem informatic nu va fi acuzat pentru că nu a detaliat dacă nu i s-a stabilit acest lucru. După efectuarea modificărilor, în software, în bazele de date, se reia procesul de auditare şi raportul de constatare se

125

transformă în raport de auditare şi se eliberează un certificat de către auditor, prin care se recunosc calităţile sistemului informatic, iar utilizatorii trebuie să aibă încredere în sistemul informatic auditat.

În cel de al doilea caz, favorabil, diferenţele dintre ceea ce s-a aşteptat de către utilizator şi ceea ce s-a realizat sunt nesemnificative sau sunt favorabile creşterii calităţii produsului. Raportul de auditare este o construcţie complexă, dezvoltată de membrii echipei de auditare. Asemenea unei cărţi organizate pe capitole, este o construcţie arborescentă. Fiecare nod al arborescenţei are o informaţie cu structură standard:

- obiectiv; - input-uri, output-uri; - conţinut, prelucrări; - înregistrare rezultat analiză; - evaluare proces; - concluzii, calificare. Agregarea se realizează de la bază spre rădăcina structurii

arborescente. Raportul de auditare este o construcţie de maximă detaliere. Modul de abordare expus arată clar care este diferenţa între alte activităţi şi audit. Se observă clar că auditul are ca rezultat o analiză, o serie de evaluări şi evidenţierea cu maximă rigurozitate a diferenţelor dintre sistemul informatic solicitat de utilizator şi descris în specificaţiile convenite, pe de o parte, şi sistemul informatic aflat în formă livrabilă, pe de altă parte.

Auditarea este solicitată de elaborator sau de beneficiar pentru a obţine acele informaţii care dau încredere în utilizare, certitudinea că rezultatele aşteptate sunt corecte, complete, exact în structura solicitată şi se obţin în timp real.

Auditarea are menirea de a transfera certitudine şi încredere în sistemul informatic prin rezultatul pozitiv stabilit de către o echipă de auditori, aparţinând unei firme de consultanţă cu autoritatea dată de auditări anterioare.

Managementul auditării are particularităţi specifice legate în principal de capacitatea auditorilor de a învăţa proceduri şi, mai ales, de a aplica aceste proceduri în mod unitar.

Orice manifestare spontană sau de orgoliu aduce diferenţieri de abordare care se concretizează prin discrepanţe în a alege modele, în a culege date. Se reduce în acest fel comparabilitatea datelor, iar agregarea

126

datelor se reduce până la imposibilitatea de a opera cu seturi de date care privesc componentele aparţinând aceleiaşi clase.

Auditul unui sistem informatic presupune un volum important de muncă întrucât se reface întregul traseu parcurs de echipa de realizatori a sistemului şi, chiar mai mult, întrucât intră în analiză însăşi specificaţiile cu sursele pe baza cărora au fost construite.

Efectul imediat al auditului sistemului informatic este folosirea lui cu încredere dacă rezultatul auditării oferă această încredere. Pentru echipa de dezvoltare a sistemului informatic, dacă a trecut de testul auditării, se creează condiţii favorabile dezvoltării de noi sisteme informatice, mult mai complexe.

În cazul în care sistemul informatic nu a trecut testul auditării, apar serioase semne de întrebare legate de managementul companiei de software care a dezvoltat un astfel de sistem. Trebuie să apară schimbări majore la nivelul managementului şi la nivelul echipelor de dezvoltare. Trebuie adoptate tehnici de analiză, proiectare, programe testare, implementare, mentenanţă, eficiente care să genereze fluxuri de dezvoltare compatibile.

Auditul presupune un mod activ de corectare a produsului, variante de lansare în uz curent dacă acest lucru se impune. Auditul este necesar pentru orice sistem informatic. Este normal ca un sistem informatic neauditat, când generează erori, compania care utilizează să plătească toate daunele. Lipsa auditului înseamnă riscuri asumate. Riscurile înseamnă costuri şi costurile trebuie suportate de către cel care şi-a asumat riscurile la un nivel care depăşeşte limite raţionale.

Auditul este un proces opţional până la un punct. În condiţiile software public, în care cetăţeanul dezvoltă procese de prelucrare în interes propriu, auditul devine o necesitate, devenind obligatoriu. Obligativitatea este o măsură de autoconservare a companiei care utilizează software public pentru a derula servicii spre cetăţeni cu resurse proprii pentru a satisface cerinţe ale cetăţenilor. O astfel de organizaţie nu trebuie să rişte. Auditul înseamnă transfer de încredere şi menţinerea riscurilor la niveluri suportabile cu asigurarea unui nivel bun al profitabilităţii.

În condiţiile societăţii informaţionale, conectarea la o arhitectură de sisteme informatice auditate a unui nou sistem este efectivă dacă şi numai dacă sistemul care se conectează este auditat, iar rezultatul auditării permite conectarea. În caz contrar, efectele de antrenare multiplă la nivelul riscurilor devin de necontrolat.

127

Societatea informaţională dezvoltă o nouă atitudine faţă de audit. Îl consideră un element esenţial pentru construirea de arhitecturi software complexe de utilitate publică în regim continuu şi fără asistenţă. Crearea civilizaţiei bazată pe informaţie obţinută interactiv pleacă de la ideea completitudinii şi corectitudinii obţinerii informaţiei. Pentru a avea costuri bune, sistemele informatice trebuie să utilizeze resursele la niveluri minime. Numai în procesul de auditare rezultă că a fost urmată calea spre minimizarea costurilor. Sunt argumente, sunt măsurători şi întregul demers trebuie susţinut cu calcule de eficienţă.

Auditul trebuie privit ca o investiţie suplimentară. Compania de software care dezvoltă un sistem informatic şi derulează procedee de audit creează premisele autoprotecţiei faţă de riscurile generatoare de cheltuieli ce depăşesc potenţialul companiei.

Se creează o nouă atitudine faţă de auditul sistemelor informatice, fiind considerat altceva decât o activitate impusă sau un rău necesar, transformându-se în singura modalitate prin care se obţin garanţii reale asupra calităţii sistemului informatic, pe care utilizatorii le percep în timp.

Odată implementat, un sistem informatic este obligatoriu să fie auditat periodic pentru a se asigura că îndeplineşte toate sarcinile cerute la cel mai ridicat grad posibil de eficienţă şi eficacitate. Creşterea organizaţiei, creşterea volumului afacerilor, schimbările în mediul afacerilor, schimbările tehnologice şi noile cerinţe de informaţii toate plasează o cerere crescândă asupra sistemului informatic existent şi adeseori impun modificarea sau extinderea acestuia pe baze ad-hoc.

Exemple ale unui audit de SI aflat în funcţiune: - reevaluarea cerinţelor de informaţii; - verificarea modificărilor propuse la proiectările de bază existente; - investigarea oportunităţii noilor tehnologii; - îmbunătăţirea procedurilor de operare. Din practică s-a constatat necesitatea auditarii unui sistem informatic

odată la trei ani sau ori de câte ori schimbările apărute o impun.

128

Anexa 1

Lista de variabile

Variabila Explicaţia Acti Activitatea i aij Element al matricei Ann Ann Matricea de corespondenţă pentru module bij Element al matricei Bnn Bmn Matricea relaţiei modul – date. Cdif Caracteristică de diferenţiere COji Element al matricei de corespondenţă operaţii-parole COji Element al matricei de corespondenţă operaţii – clase de parole COLi Coloana i CPRi Clasa i de parole CQ Caracteristică de calitate CQDi Caracteristica i de calitate a datelor CSI Complexitatea sistemului informatic, în sens Halstead CVi Criteriul i de validare CVI Colectivitate de elemente D Durata de realizare a unui sistem informatic DA Indicator de asemănare a două programe DA(Pi, Pj) Indicator de asemănare a programelor Pi şi Pj DINTk Date de intrare de la nivelul k Ei Entitatea i Eti Etapa i din cadrul unui proces Ev Eveniment FACT jj Factorul ij Fi Funcţia i fr Frecvenţă de apariţie Ga Gradul de acoperire a setulul de date GA(X,Y) Gradul de asemănare a matricelor X şi Z GAA Indicatorul grad de asemănare agregat GDFj Gradul de definire a listei i a factorilor H(aij) Ortogonalitatea globală a elementului aij în raport cu celelalte

elemente H(aij, aik) Ortogonalitatea elementelor aij şi aik ISS Ius Indicator al utilizării surselor KG Numărul de aspecte din proiectul sistemului informatic care au fost

supuse analizei 129

Variabila Explicaţia Li Lista i LINF Limită inferioară LINi Linia i LSUP Limită superioară MCdif Număr caracteristici de diferenţiere MFS Matricea corespondenţă funcţii-subsisteme mfsij Element al matricei MFS MOD Modul de date MODi, Modulul i de date MOi Componenta sau modulul i din structura unui sistem informatic NCA Număr proceduri de calcul Ncuv Număr de cuvinte NCV Numărul criteriilor de validare NCVI Număr de colectivităţi ne Numărul elementelor din listă NeCVI Număr de elemente al unei colectivităţi NF Numărul factorilor NFUN Numărul de funcţii NIN Număr de proceduri cae asigură operaţii de intrare NINIj Numărul de variabile de intrare ale subsistemului SSj NINOj Numărul de variabile rezultative ale subsistemului SSj NMAXi Numărul maxim de elemente din intervalul i NMD Numărul modulelor de date NMD Număr module de date NMEDi Numărul mediu de elemente din intervalul i NMINi Numărul minim de elemente din intervalul i NOU Număr operaţii utilizator NOU Număr de operaţii effectuate de utilizatori NOUT Număr de proceduri de stocare sau de afişare a rezultatelor NPR Număr de parole Nrd Numărul total al referirilor de date de către module Nrm Numărul total al referirilor de module NrPRODi Numărul de proceduri i NrSi Număr de şiruri ns Numărul salariaţilor NSi Numărul de şiruri i NSO Numărul de subobiective NSS Numărul de subsisteme NTF Numărul de tipuri fundamentale de date NUZ Număr de utilizatori O Obiectiv OUi Operaţia i efectuată de către utilizatori

130

Variabila Explicaţia OUi Operaţia i efectuată de utilizatori Pi Coeficientul i de importanţă Pi Programul i PROB Problemă PROCAi Procedura i de calculNCA PRODi Produsul i PROG Program PROINi Procedura care asigură operaţiile de intrare PROUTi Procedura i de stocare sau de afişare a rezultatelor

jikq Element din matricea output/indicatori pentru subsistemul SSj

REZk Rezultatele de la nivelul k Ri Raportul i RINT Rezultat intermediar

jikr Element din matricea output/inputuri

Scuv Şir de cuvinte Si Sevenţa i dintr-un program SOi Subobiectivul i SPROBi Subproblema i. SSi Subsistemul i Strj Structura j TFDi Tipul fundamental de date i TFDi Tipul fundamental de date i TFj Tipul fundamental de date j Ti Tabloul i cu TCOLi şi TLINi UCji Element al matricei de corespondenţă utilizatori – clasă de parole UZi Tipul i de utilizatori V(STi) Volumul setului de date asociat colectivităţii i VARI Variabila i W Productivitatea a celor care elaborează un sistem informatic XCVI Numărul componentelor pentru care au fost introduse date XeCVI Numărul componentelor colectivităţii CVI pentru care au fost

introduse date xijk Nivelul câmpului cu poziţia j pentru şablonul de descriere

aparţinând elementului k din entitatea Ei j

ikw Element din matricea de utilizare a input-urilor

131

Anexa 2

Lista de figuri

Număr figură

Denumirea

Figura 5.1 Etapele ciclului de auditare a sistemului informatic Figura 5.2 Lista de activităţi Ai a etapei Ei Figura 5.3 Dezvoltarea structurată pe etape a ciclului de realizare a sistemului Figura 5.4 Sinteza rapoartelor de detaliu pe bază de listă Figura 5.5 Schema de auditare, ca listă de liste Figura 5.6 Rapoartele de auditare, ca informaţii utile ale listelor de liste Figura 6.1 Concordanţa dintre stuctură şi subobiective Figura 6.2 Concordanţa dintre stuctură şi subobiective Figura 6.3 Derivarea indicatorilor din subobiective Figura 6.10 Transformarea output-urilor în input-uri Figura 6.11 Transformarea unui output în input multiplu Figura 7.1 Structura ierarhizată a indicatorilor Figura 8.1 Analiză top down Figura 8.2 Analiză bottom - up Figura 8.3 Analiză fluxurilor de interacţine ale modulului mijlociu Figura 8.4 Structură liniară de module Figura 8.5 Structură liniară cu cinci module Figura 8.6 Secvenţă de structură arborescentă de module Figura 8.7 Secvenţă de structură arborescentă de module Figura 8.8 Structura globală a unei proceduri Figura 8.9 Compararea rezultatelor intermediare Figura 8.10 Secvenţe de instrucţini în procedură Figura 8.11 Structură software cu proceduri grupate Figura 8.12 Structură software cu gruparea procedurilor spre finalităţi complete Figura 8.13 Concordanţa datelor de test

132

Anexa 3

Lista de tabele

Număr tabel Denumire tabel Tabelul 6.1 Structura listei de descriere tip, clasă sau grup Tabelul 6.2 Legătura funcţii/subsisteme Tabelul 6.3 Legături multiple funcţii/subsisteme Tabelul 6.4 Utilizarea input-urilor în indicatori Tabelul 6.5 Utilizarea output-urilor în indicatori Tabelul 6.6 Utilizarea input-urilor pentru obţinerea outputurilor Tabelul 6.7 Utilizarea input-urilor în indicatori Tabelul 6.8 Utilizarea output-urilor în indicatori Tabelul 6.9 Utilizarea input-urilor pentru obţinerea outputurilor

Tabelul 7.10 Corespondenţa utilizatori/parole Tabelul 7.11 Corespondenţa operaţii/parole Tabelul 8.12 Utilizarea variabilelor transmise Tabelul 8.13 Utilizarea variabilelor în module Tabelul 8.14 Transmiterea de parametri Tabelul 9.15 Criteriile standard de validare pentru tipurile fundamentale de

date Tabelul 9.16 Atribute ale calităţii datelor Tabelul 9.17 Date privind producţia şi preţurile

Anexa 4

Lista de verificare (Checklist) pentru specificaţiile funcţionale

Organizarea şi completitudinea proceselor

o Se verifică dacă sunt definite toate tabelele de corespondenţă cu

cerinţele funcţionale ale sistemului informatic. o Se analizează dacă sunt sapecificate toate cerinţele beneficiarilor

la nivel de detaliu cu aceeaşi consistenţă şi nivel de adecvare. o Se stabileşte măsura în care cerinţele definite furnizează

informaţiile necesare şi suficiente pentru derularea proceselor specifice etapei de proiectare.

133

o Se stabileşte concordanţa între priorităţile utilizatorului şi cele ale elaboratorului, în vederea unui proces corect şi complet de implementare.

o Se verifică dacă toate interfeţele hardware, software şi de comunicaţie au fost complet şi consistent definite şi dacă există elemente redundante.

o Se verifică dacă sunt definiţi toţi algoritmii intrinseci pentru cerinţele funcţionale ale fiecărei etape din ciclul de elaborare a sistemului informatic.

o Se analizează completitudinea listei de mesaje în raport cu variantele de date de intrare, pentru a vedea dacă este complet specificat comportamentul sistemului informatic la nivel de mesaje, pentru toate situaţiile care generează erori sau toleranţă la erori.

Corectitudinea derulării proceselor

o Se analizează dacă există o cerinţă în conflict sau este duplicată în raport cu o altă cerinţă.

o Se verifică dacă fiecare cerinţă este scrisă clar, concis, fară ambiguităţi şi urmează o abordare de la simplu către complex, urmând logica derulării proceselor specifice etapelor din ciclul de dezvoltare a sistemului informatic.

o Se stabileşte măsura în care fiecare cerinţă inclusă în specificaţiile sistemului informatic este verificabilă prin testare, revizie, prezentare sau analiză.

o Se analizează dacă fiecare cerinţă este descrisă concis, coerent, fără erori gramaticale şi pe înţeles, folosind construcţii simple, fără paranteze şi fără elemente de precauţiune care măresc ambiguitatea sensurilor.

o Se verifică măsura în care unele informaţii lipsesc sau dacă unele cerinţe se repetă sau sunt complementare. Toate situaţiile întalnite se clarifică şi se stabilesc efectele pe care le generează asupra procesului de dezvoltare a sistemului informatic.

o Se analizează măsura în care toate cerinţele sunt implementate prin constrângeri cunoscute şi modul în care sunt utilizate sisteme de codificare pentru a elabora specificaţii într-un mod cât mai formalizat.

134

o Se analizează ortogonalitatea sistemului de mesaje de eroare pentru a vedea măsura în care acestea sunt unice, uşor de înţeles şi au menirea de a declanşa acţiuni de corectare a datelor de intrare, fără a mai genera alte erori.

Caracteristici de calitate ale sistemului informatic

o Se verifică dacă sunt specificate toate obiectivele referitoare la performanţă privind modalitatea în care mai mulţi beneficiari, omogeni şi simultani, vor utiliza funcţionalitatea, timpul aşteptat pentru răspuns, informaţii despre volumul de date maxim care se stochează şi dependenţele de funcţionare pe care le determină dimensiunile şi complexitatea bazelor de date.

o Se analizează dacă sunt corect specificate toate cerinţele referitoare la securitate şi siguranţa în accesarea tuturor resurselor sistemului informatic, stabilindu-se limitele şi riscurile probabile.

o Se analizează măsura în care sunt corect specificate toate cerinţele de ştergere de date, arhivare, backup şi restaurare ale sistemului informatic, atunci când acesta aparţine unei generaţii mai vechi de concepţie. Dacă este luată în considerare ca unică operaţie adăugarea de informaţie, analiza vizează localizarea în timp, spaţiu şi la nivel de operatori a acţiunilor care definesc clase de tranzacţii în sistem.

Trasabilitate

o Se verifică dacă fiecare cerinţă este identificată unic şi corect pentru a nu crea situaţii ambigue, generatoare de soluţii care includ elemente de complexitate nejustificate.

o Se verifică dacă fiecare cerinţă funcţionala a sistemului informatic solicitat este trasabilă cu cerinţele de ansamblu ale sistemului informatic efectiv realizat, cu instrumentele CASE utilizate.

135

Alte condiţii care presupun verificari

o Se stabileşte măsura în care toate cerinţele descrise pentru elaborarea sistemului informatic se dovedesc a fi şi cerinţele luate în considerare de designeri fără a fi transpuse în structuri de date, structuri de module şi fără a le corespunde fluxuri de prelucrare în sistemul final.

o Se analizează dacă au fost identificate şi specificate corect toate criteriile de contorizare şi sincronizare pentru functionalităţile critice din punct de vedere timp, resurse hardware şi, mai ales, în raport cu completitudinea şi corectitudinea rezultatelor finale.

o Se verifică dacă au fost respectate cerinţele impuse prin standarde sau regulamente care au menirea de a face portabile specificaţiile, produsele informatice autodocumentate şi chiar rapoartele de auditare atât în forma finală cât şi în formele de detaliu.

Anexa 5

Programul de audit

Compania numele firmei Contract nr.

Domeniile auditate

lista de activităţi a firmei

Standard EAC/ NACE

EN ISO 9001::2000

Auditor şef

numele auditorului

Echipa de audit

numele auditorilor

Perioada Audit ID

Tipul auditului

Periodic

Locuri

numele firmei adresa firmei Programul Procesul Element standard Auditor

AŞ–Auditor Şef A - Auditor

orar Proces analizat Procesul descris in manualul calităţii

Cine a realizat auditul

136

Anexa 6

Nota de neconformitate

Compania Contract nr. Adresa Data Standard/Clauze Nota Nr. Dept/ Proiect Categoria notei 1. Descrierea neconformităţii Auditor Client Acţiuni de corectare luate semnătura semnătura termen limita 2. Măsuri de corectare Semnătura client: Documente ataşate: Data: 3. Revederea acţiunilor corective

Măsurile propuse sau executate sunt satisfăcătoare Da/Nu

Necesitatea verificării ulterioare Da/Nu

Auditor Şef semnătura Data

Comentarii 4. Încheiere notă de nonconformitate

Auditor şef semnătura

Data:

Anexa 7

Raport de audit Compania Client Nr. Nr de angajaţi Standard

EAC/ NACE ISO 9001:2001

Reprezentantul managementului

Data auditului

Auditor Şef Echipa de auditori Audit ID Data următorului

audit

137

Scopul vizitei Audit periodic

Rezultatele vizitei

- A din B neconformităţile existente la precedentul audit au fost verificate pe durata auditului actual;

- C neconformităţi majore au fost raportate la ultima şedinţă de încheiere;

- D neconformităţi minore au fost raportate la şedinţa de încheiere; - E observaţii noi au fost raportate la şedinţa de încheiere

.

Anexe

• Înregistrări • Observaţii • Divergente

Domeniul certificării Standarde de produs/ cerinţe statutare/ coduri de practică / Note de şedinţă

138

Anexa 8

Raport de audit intern 1. Departament auditat: Departamentul de dezvoltare software 2. Proiect software: Software 3. Perioada: zz.ll.aaaa-zz.ll.aaaa 4. Documente de referinţa:

• Manualul calităţii • Controlul documentelor • Controlul înregistrărilor calităţii • Auditul intern • Controlul produsului neconform • Acţiune corectivă iterativ convergentă • Acţiune preventivă cu încadrare în costuri • Analiza efectuată de management • Resurse umane cu calificare continuă • Managementul proiectului de sistem informatic evolutiv • Determinarea specificaţiilor sistemului • Proiectare arhitecturală sistem informatic, inclusiv prin

customizare • Proiectarea detaliată cu includerea sistemelor de protecţie

organizate pe niveluri de acces la resurse • Producţia codului, asamblarea de module • Proiectarea sistemelor de baze de date şi crearea premiselor

testării • Livrare şi instalare aplicaţii informatice independente,

asamblabile succesiv în vederea obţinerii, în final, a sistemului informatic integrat

• Mentenanţă software, baze de date şi arhitecturi în vederea optimizării procesului de înlocuire

• Cerinţe de reinginerie sistem informatic • Managementul configuraţiei • Proprietatea clientului asupra sistemului informatic privit ca

produs finit • Monitorizarea satisfacţiei clientului

139

• Metrici pentru produse, date şi servicii • Verificarea şi validarea sistemului software, baze de date şi

fluxuri • Elaborarea procedurilor şi instrucţiunilor de utilizare în siguranţă • Codificarea documentelor • Managementul documentelor • Controlul documentelor de dezvoltare software • Elaborarea planului calităţii ca instrument al dezvoltării

sistemului informatic Cerinţe de reglementare specifice :

- Legi - Hotărâri de Guvern - Norme şi metodologii de aplicare a legilor şi hotărârilor - Standarde de calitate - Documentaţii ale metodologiilor de dezvoltare asistată sisteme

informatice - Definiri de limbaje de proiectare şi realizare specificaţii, cod,

structuri de baze de date, fluxuri - Metrici de evaluare stadii, evoluţii şi produse finite - Regulamente de elaborare a documentaţiilor

5. Domeniul şi obiectivele auditului:

a. verificarea implementării prevederilor documentelor de referinţă şi conformotatea cu cerinţele legale şi de reglementare specifice

b. determinare oportunităţi de imbunătăţire a sistemului informatic în vederea operaţionalizării acestuia.

6. Echipa de audit:

auditor şef auditori auditori în formare experţi tehnici

7. Persoane contactate din departamentele auditate (nume şi funcţie): Director Departament Software

Şef proiect software Director Departament Baze de Date Şef proiect baze de date

140

8. Difuzare: Ex.1 –– Sef departament Calitate Ex.2 -– Director Software Ex.3 -– Director Baze de Date 9. Rezultatele verificarii 9.1 Privind activităţile de verificare şi validare a sistemului Situaţie cu numărul de erori găsite şi de către cine au fost introduse: Modulul AAAA1 Număr probleme introduse de testeri: SSS1 Număr probleme introduse de programatori: TTT1 Numar probleme introduse de consultanţi: YYY1 …………………………….. Modulul AAAAn Număr probleme introduse de testeri: SSSn Număr probleme introduse de programatori: TTTn Numar probleme introduse de consultanţi: YYYn

Analiza datelor conduce la o serie de decizii privind nivelul modificărilor care trebuie efectuate în fiecare modul pentru a fi adus la cerinţele formulate de beneficiari.

Erorile sunt contorizate diferenţiat şi calculul unor indicatori agregaţi dă o imagine suficient de clară asupra calităţii sistemului informatic privit ca un conglomerat de module, fiecare modul având nivelul său de calitate diferit de al celorlalte module.

În continuare se descriu pe larg rapoartele de îmbunătăţire a modulelor prin indicarea erorilor eliminate şi a efectelor pe care le generează îmbunătăţirea asupra întregului sistem informatic. Se specifică toate modificările efectuate pentru a ameliora calitatea modulului, respectiv calitatea modulelor adiacente, în final calitatea întregului sistem informatic.

Se efectuează analiza erorilor de către şeful de proiect/echipă de proiect, lucru foarte important din punctul de vedere al asigurarii calităţii prin prevenirea erorilor care se descoperă către etapele finale ale ciclului de dezvoltare, erori caracterizate prin costuri de corectare foarte ridicate.

141

9.2 Consideraţii privind documentaţia de dezvoltare software Trasabilitatea specificată din documentele sistemului informatic este

corect implementat. Documentaţia de dezvoltare a sistemului informatic este bine ţinută

sub control, cu specificarea tuturor persoanelor care au executat operaţii de verificare, control şi elaborare documentaătii privind dinamica testării. 9.3 Raportul de stadiu al configuraţiei

Reguliile pentru identificarea configuraţiei, specifice proiectului, cu stabilirea unor reguli precise de localizare a emitenţilor, a destinatarilor şi a conţinutului. 10. Concluzii

Activităţile în cadrul proiectului de sistem informatic se desfăşoară în conformitate cu documentele de referinţă şi standardele/cerinţele legale specifice care corespund modalităţilor uzuale de derulare a proceselor.

În cazul în care, numărul de erori este cu mult mai mare decât o limită stabilită, sunt identificate cauzele care generează situaţia respectivă. De regulă, astfel de situaţii sunt frecvente când procesul de testare este incomplet şi când asigurarea calităţii este deplasată spre partea finală a ciclului de dezvoltare a sistemului informatic.

11. Propuneri de imbunătăţire / Recomandări o O mai bună verificare de proiectare prin crearea şi utilizarea

listelor de verificare (checklist) după terminarea fiecărei faze din ciclul de dezvoltare a sistemului informatic.

o Introducerea inspecţiilor software şi a inspecţiilor în bazele de date.

o Crearea şi urmărirea în viitor a unor situaţii din care să reiasă: - comparaţia fazelor analiza+design+programare în raport cu

procesele de testare la nivel de modul, la nivel de subsistem şi în final la nivelul întregului sistem informatic;

- comparaţia atât ca durată resurse, costuri şi calitate a fiecarei faze din ciclul de dezvoltare;

- analiza efectelor si descoperirea cauzelor care generează erori sistematice în vederea găsirii celor mai bune căi de eliminare;

- impactul generat de modificările în structura prin module nou introduse asupra proceselor de testare, evidenţiindu-se situaţiile în

142

care sunt identificate module bine scrise, planificarea adecvată a resurselor, o corelaţie strâns între complexitatea modulului, calitatea acestuia şi resursele utilizate în vederea construirii lui.

Raportul este întocmit şi semnat de şeful echipei de auditori.

Anexa 9

Organisme, regulamente şi standarde referitoare la auditul sistemelor

informatice ISACA (Information Systems Audit and Control Association) Web site: http://www.isaca.org

Standarde: SISAS (Statement of Information Systems Auditing Standards)

Ghiduri: Guidelines and Procedures for Audit and Control Professionals

CobIT (Control Objectives for Information and related Technology)

Certificări: CISA (Certified Information Systems Auditor) IFAC (International Federation of Accountants) Web site: http://www.ifac.org

Standarde: ISA (International Standards of Auditing) IAPS (International Auditing Practice Statements) Ghiduri: IITG (International Information Technology Guidelines)

IIA (Institute of Internal Auditors) Web site: http://www.theiia.org

Standarde: SIAS (Statements on International Auditing Standards)

143

BIBLIOGRAFIE [ALAT03] Alatalo, T., Oinas-Kukkonen, H., Kurkela, V., Siponen, M.:

Information systems development in emergent organizations. Empirical findings, http://hytec.oulu.fi

[APRE95] Apreutesei P., Noşca Gh.: Optimising the Software Quality Cost,

International Conference Software Quality, University of Maribor, Slovenia, noiembrie 1995

[APRE00] Apreutesei, P.: Modele de estimare a costurilor software pentru

aplicaţii în reţea, Teza de doctorat, Bucureşti, ASE, 2000 [AREN03] Arens, A. A., Loebbecke, J. K., Elder, R. J., Beasley, M. S.:

Audit – o abordare integrală, Ediţia a 8-a, Bucureşti, Editura ARC, 2003

[ARHI00] Arhire, R.: Evaluarea complexităţii sistemelor de programe,

Teză de doctorat, Bucureşti, ASE, 2000. [AVRA97] Avram, G.: Auditul sistemelor informaţionale, Referat teză de

doctorat, Bucureşti, ASE, 1997 [AVRA01] Avram, G.: Instrumente de evaluare a sistemelor informaţionale

economice, Teză de doctorat, Bucureşti, ASE, 2001 [BACH02a] Bachmann, F., Bass, L., Klain, M.: Illuminating the Fundamental

Contributors to Software Architecture Quality, http://www.sei.cmu.edu

[BAIK00] Baik, J.: The Effects of Case Tools on Software Development

Effort, http://www.citeseer.nj.nec.com/baik00effects.html

144

[BAKE90] Baker Albert L., James M. Bieman, Norman Fenton, David A. Gustafson, Austin Melton, Robin Whitty: A Philosophy for Software Measurement, Journal Systems Software, No.12, 1990, p. 277-281

[BALO94] Balog, A.: Estimarea calităţii sistemelor de programe, Teza de

doctorat, Bucureşti, ASE, 1994 [BARO04] Baron, A. M.: Tehnici şi metode utilizate în auditul calităţii

software, Lucrare de disertaţie, Curs de master: Managementul informatizat al proiectelor, Bucureşti, ASE, Facultatea CSIE, 2004

[BĂLA99] Bălaşa, L.: Evaluarea sistemelor de asigurare a calităţii asistate

de calculator, Lucrare de licenţă, Bucureşti, ASE, Facultatea CSIE, 1999

[BRÂN04] Brândaş, C.: Auditul sistemelor informatice de gestiune, note de

curs, Timişoara, Facultatea de Ştiinţe Economice, Universitatea de Vest, 2004

[CAPI01a] Capisizu, S.: Caracteristicile de calitate a datelor, Referat

doctorat, Bucureşti, ASE, ianuarie 2001 [CAPI01b] Capisizu, S.: Cerinţele auditului informaţiei economice, Referat

doctorat, Bucureşti, ASE, octombrie 2001 [CAPI02] Capisizu, S.: Metode de structurare şi realizare a auditului de

date, Referat doctorat, Bucureşti, ASE, iulie 2002 [CAZA04] Cazan, D.: Metrici de calitate pentru sisteme informatice,

Referat doctorat, Bucureşti, ASE, Facultatea CSIE, 2004 [CAZA05] Cazan, D.: Validarea modelelor de evaluare a calităţii

sistemelor informatice, Referat doctorat, Bucureşti, ASE, Facultatea CSIE, 2004

[EBEN98] Eben, R. G., Strauss, S. H.: Software Inspection Process, Mc

Graw Hill Inc, New York, 1998

145

[GHIL04] Ghilic-Micu, B, Stoica, M.: Organizaţia virtuală, Bucureşti, Editura Economică, 2004, p.302

[HINS05] Hinson, G.: Frequently Avoided Questions about computer

auditing, http://www.isect.com/html/ca_faq.html [IVAN84] Ivan, I., Arhire, R.: Informatică Economică: Evaluarea

performanţei programelor COBOL, Bucureşti, lito ASE, 1984 [BARO88] Baron, T., Ivan, I., Goga, A.: Modelling the Cost of the Quality

of Programme Systems, Economic Computation and Economic Cybernetics Studies and Research, nr 2. (XXIII), Bucureşti, 1988, p. 21 – 31

[IVAN96b] Ivan, I., Noşca, Gh., Pârlog, A.: Asigurarea calităţii datelor,

Bucureşti, Revista Asigurarea calităţii, Numărul 8, 1996, p. 8-15

[IVAN97a] Ivan, I., Sinioros, P., Popescu, M., Simion, F.: Mertici Software,

Bucureşti, Editura INFOREC, 1997 [IVAN97b] Ivan, I, Capizisu, S., Noşca, Gh.: Influencing Factors to

Transaction on the Secondary Capital Assets Market, The "Capital Assets Markets in Romania" Symposium, The Academy of Economic Studies, The Economic Research Department, 2-3 april 1997

[IVAN98a] Ivan, I., Ivan, A.A., Noşca, Gh., Oprea, P., Pârlog, O.: Data

Metrics, Proceedins of The 1998 Conference on Information Quality, Cambridge, Massachusetts, USA, p. 215-231

[IVAN99a] Ivan, I., Noşca, Gh., Tcaciuc, S., Pârlog, O., Căciulă, R.:

Calitatea datelor, Bucureşti, Editura INFOREC, 1999 [IVAN99b] Ivan, I., Pocatilu, P.: Testarea software orientat obiect,

Bucureşti, Editura INFOREC, 1999 [IVAN00] Ivan, I., Pocatilu, P., Mihai, T., Stanca, C.: Data Certification,

Proceeding of the 2000 MIT Conference on Information Quality, Cambridge, Massachusetts, USA

146

[IVAN01] Ivan, I., Teodorescu, L.: Managementul calităţii software, Bucureşti, Editura INFOREC, 2001

[IVAN03a] Ivan, I., Toma, C.: Aplicaţii informatice orientate spre

utilizatorii finali, Informatica Economică, vol.7, nr.4, p.20– 24 [IVAN03b] Ivan, I., Apostol, C.: Certificarea produselor program prin

amprente, Revista Română de Informatică şi Automatică, vol. 13, nr. 1, 2003, p. 28 – 31

[IVAN03c] Ivan, I.: Managementul calităţii proiectelor software,

Proceedings of the International Conference „Trends in the Development of the Information and Communication Technologies in Education and Management”, Chişinău, 20 – 21 martie 2003, p. 25 – 30

[IVAN03d] Ivan, I., Apostol, C., Pocatilu, P., Popa, M.: Certificarea

aplicaţiilor Internet, Sesiunea de Comunicări Ştiinţifice a Cadrelor Didactice, Bucureşti, Universitatea Româno-Americană, 23 – 24 mai 2003

[IVAN03e] Ivan, I., Toma, C.: Testarea interfeţelor om-calculator, Revista

Română de Informatică şi Automatică, vol. 13, nr. 2, 2003, p. 22 – 29

IVAN03f] Ivan, I., Popa, M., Ungureanu, D., Apostol, C.: IT Projects

Carrying On Using Data Structures, Master of International Business Informatics Handbook, Bucureşti, Editura ASE, 2003, p. 11 – 40

[IVAN03g] Ivan, I., Pocatilu, P., Ivan, A. A., Toma, C.: Data and Control

Structures Oriented Software Testing, Master of International Business Informatics Handbook, Bucureşti, Editura ASE, 2003, p. 41 – 62

[IVAN03h] Ivan, I., Pocatilu, P., Popa, M., Apostol, C.: Supervising

Software Certification Process, Master of International Business Informatics Handbook, Editura ASE, Bucureşti, 2003, p. 223 – 235

147

[IVAN03i] Ivan, I., Pocatilu, P., Popa, M, Mihai, T., Ivan, L.: Data Orthogonality, Master of International Business Informatics Handbook, Bucureşti, Editura ASE, 2003, p. 235 – 249

[IVAN03j] Ivan, I., Toma, C.: Management of Tutorial Process Quality in

Business Informatics Programs, lucrare prezentată în workshop internaţional „Actual Problems of Business Informatics in BRIE Master Program”, 13-14 decembrie 2003, Giurgiu

[IVAN03k] Ivan, I., Rădulecu, I.: Caracteristici de calitate ale aplicaţiilor

software, Revista NET Report [IVAN03z] Ivan, I., Mijache, L.: Design Patterns – Cale de creştere a

fiabilităţii software, Revista NET Report [IVAN04a] Ivan, I., Boja, C.: Metode statistice în analiza software,

Bucureşti, Editura ASE, 2004 [IVAN04b] Ivan, I., Noşca, G., Teodorescu, L.: The Informatics Application

Quality Management, The Central and East European Conference in Business Information Systems 2004, Cluj – Napoca, 14 – 15 mai, 2004

[IVAN05a] Ivan, I., Noşca, Gh., Popa, M.: Reţele de cercetare privind

dezvoltarea sistemelor informatice de management bazat pe cunoştinţe destinate întreprinderilor mici şi mijlocii Studii şi Cercetari de Calcul Economic şi Cibernetică Economică, vol. 39, nr. 1, 2005.

[MUNT01] Munteanu, A.: Auditul sistemelor informaţionale contabile –

cadru general, Bucureşti, Editura POLIROM, 2001 [NOŞC98] Noşca, Gh., Pârlog, A.: Calitate şi cost în managementul

software, Revista Informatica Economică nr. 4, 1998, ASE, INFOREC

[NOŞC03] Noşca, Gh.: Optimizarea costurilor calităţii produselor

program, Teză de doctorat, Bucureşti, ASE, Facultatea CSIE, 2003

148

[POCA04] Pocatilu, P.: Costul testării software, Bucureşti, Editura ASE, 2004

[STOI03a] Stoica, M.: Proiectarea sistemului de management al calităţii în

organizaţiile virtuale, Revista Informatica Economică, nr. 1(25)/2003, Bucureşti, Editura Inforec, 2003, p. 34-38

[STOI03b] Stoica, M.: Proiectarea procedurilor de asigurare a calităţii pentru sistemul de management al calităţii în organizaţia virtuală, Revista

Informatica Economică, nr. 2(26)/2003, Bucureşti, Editura Inforec, 2003, p. 21-27

[STOI03c] Stoica, M.: Particularităţi ale sistemelor informaţionale

înorganizaţia virtuală, în volumul Simpozionului Naţional Tinerii economişti şi provocările viitorului, Craiova, 31 oct. – 1 nov. 2003, p. 313-318

[STOI04a] Stoica, M.: Măsuri propuse de Uniunea Europeană pentru

exploatarea sectorului public de informaţii, în Revista Tinerilor Economişti, an II, nr. 2/2004, Craiova, Editura Univ., p. 172 – 176

[STOI04b] Stoica, M.: The Information System for Virtual Organizations,

în The Proceedings of The Central and East European Conference in Business Information Systems, Cluj-Napoca, Editura Risoprint, mai 2004, p. 308 – 312

[STOI04c] Stoica, M.: Management Informational System in Virtual

Organization of Activities, în vol. Simpozionului Internaţional InfoBUSINESS’2004 – Innovative Applications of Information Technologies in Business and Management, Publishing House Iaşi, oct. 2004, p. 107 – 110

149

[STOI04d] Stoica, M.: Strategia de cercetare şi dezvoltare tehnologică în domeniul tehnologiilor informaţionale şi de comunicaţii în perspectiva integrării în Spaţiul de Cercetare European, în cadrul PNCDI CERES, Consorţiu de cercetare ICI-IFIN-ASE-UB-UPB, Bucureşti, 2004

[STOI05] Stoica, M.: Dezvoltarea sistemelor informaţionale economice.Concepte

şi aplicaţii, Bucureşti, Editura ASE, 2005 (în curs de apariţie) [THOM04] Thomas, G.: Using knowledge management tools to reduce risk

in professional service engagements, http:/www.tdan.com/edatt1_archive.htm

[VANN01] Vannan, E.: Quality Data An Improbable Dream? A process for

reviewing and improving data quality makes for reliable — and usable — results, EDUCAUSE QUARTERLY Number 1, 2001, p. 56 - 58

[WAND96] Wand, Y., Wang, R.: Anchoring Data Quality Dimensions in

Ontological Foundations, Communications of the ACM, November 1996, p. 86-95.

[WANG93] Wang, R. Y., Kon, H. B., Madnick, S. E.: Data Quality

Requirements Analysis and Modeling, Proceedings of the Ninth International Conference of Data Engineering, april 1993, p. 670-677.

[WANG95] Wang, R., Firth, C.: A Framework for Analysis of Data Quality

Research, IEEE Transactions on Knowledge and Data Engineering, august 1995, vol. 7, No. 4, p. 623-640.

[WANG98] Wang, R.Y.: A Product Perspective on Total Data Quality

Management, Communications of the ACM, february 1998, p. 58-65.

[WANG02] Pipino, L. L., Lee, Y. W., Wang, R. Y.: Data Quality

Assessment Communications of the ACM, april 2002, p. 211-218.

150

[WEIN93a] Weinberg, G. M: Quality Software Management - First Order Measurement, Dorset House Publishing, New York, USA, 1993

[WEIN93b] Weinberg, G. M.: Quality Software Management - System

Thinking, Dorset House Publishing, New York, USA, 1993 [WIEC01] Wieczorek, M., Meyerhoff, D.: Software Quality, Springer-

Verlag Berlin Heidelberg, New York, 2001 [WIEL99] van der Wiele, T., Dale, B., Williams, R.: The Evolution in

Quality Thinking, Quality Management, Assurance and Education, European Dimensions, Inforec, Bucureşti, ASE, 1999

[WILL00] Williams, J. D.: Raising Components, Application Development

Trends, vol. 7, no. 9, sep 2000, p.27--32. [WOOD88] Wood, B., Pethia, R., Gold, L. R., Firth, R.: A Guide to the

Assessment of Software Development Methods, http://www.sei.cmu.edu/publ/documents/08reports/pdf/88tr009.pdf

[YOGE00] Yogesh, M.: Knowledge Management for [E-]Business

Performance, Information Strategy: The Executives Journal,vol. 16(4), Summer 2000, p. 5-16

151