INTRODUCERE

Societatea informaional determin o cretere dramatic a dependenei tuturor domeniilor vieii economico-sociale de tehnnologiile informaionale. Sistemele informatice sunt construcii complexe care vizeaz mai multe probleme diferite ale unei companii. Avnd n vedere consumul de resurse umane i financiare la dezvoltarea unui sistem informatic, este necesar s se desfoare anumite activiti care s conduc la atingerea obiectivului propus, la timp, cu nivelul de calitate stabilit i n limita bugetului alocat. Una dintre aceste activiti, deosebit de important, att pentru realizatori, ct, mai ales, pentru utilizatori, este auditul sistemelor informatice (SI). Auditul SI este o ramur a auditului general care se ocup cu controlul tehnologiilor informaiilor i comunicaiilor. Auditul SI studiaz, n primul rnd, sistemele i reelele de calcul din punct de vedere al examinrii eficienei controlului tehnic i procedural pentru a minimiza riscurile. Auditarea SI presupune discuii cu personalul care stabilete specificaiile, dezvolt, testeaz, conduce, administreaz i utilizeaz sistemele de calcul [HINS05] Obiectivul lucrrii l constituie stabilirea unor modaliti de realizare a auditului sistemelor informatice. Pentru atingerea acestui deziderat, lucrarea este structurat pe dousprezece capitole. n capitolul Sisteme informatice. Complexitate i costuri, sunt prezentate condiiile n care se dezvolt un sistem informatic i influena acestora att asupra procesului de dezvoltare, ct i asupra produsului final. Se analizeaz, sumar, structura unui sistem informatic i relaiile 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 activiti importante care sunt avute n vedere att de ctre realizatorii sistemului informatic, ct i de ctre auditori. Stabilirea limitelor ntre care

trebuie s se ncadreze rezultatele unui sistem informatic conduce la eliminarea unor situaii nedorite, care, n anumite domenii, au urmri imprevizibile. n capitolul al treilea, Realizarea i msurarea concordanei, sunt prezentate, succint, sistemele care compun o companie, indiferent de mrimea acesteia, sunt relevate interaciunile 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 activiti. Se prezint, comparativ, auditul informatic i alte activiti 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 desfurarea procesului de auditare. Sunt analizate tipurile de liste i rolul acestora n desfurarea procesului de auditare. Se prezint cerinele impuse unei liste pentru a obine rezultatele scontate. Construirea listelor reprezint latura esenial a procesului de auditare planificare. Fr un plan bine elaborat, articulat i fr o viziune unitar, rezultatul final este afectat de factori perturbatori. Auditul specificaiilor este analizat n capitolul al aselea. Realizarea unui sistem informatic care s rspund cerinelor utilizatorilor depinde , n mod esenial, de stabilirea specificaiilor. Specificaiile constituie baza proiectrii i dezvoltrii oricrui sistem. Din acest considerent, se impune ca procesul de auditare a unui sistem informatic s nceap cu auditul specificaiilor. n acest capitol sunt analizate modalitile de realizare a auditului specificaiilor. Auditul proiectului este analizat n capitolul al aptelea, avnd n vedere c un sistem informatic, cu un nivel de calitate cerut, se realizeaz avnd la baz un proiect cu un grad corespunztor al calitii. Se urmrete cuprinderea specificaiilor, regsirea acestora n rezultatele finale. Se propun modaliti de auditare a cheilor de acces i a parolelor. Sunt descrise criterii de apreciere i indicatori de evaluare a calitii proiectului. Auditul

proiectului sistemului informatic trece, prin utilizarea unor indicatori, din zona aprecierilor strict calitative, n zona analizei, avnd o fundamentare riguroas. Elementele incluse n liste i diferenele devin vizibile i sunt cuantificate, asigurnd 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 necesitii auditului textelor surs. Se prezint modaliti de evaluare a diferenelor dintre ce s-a proiectat i rezultatele practice obinute. Se propun msuri de remediere a deficienelor n cazul n care se constat. Se subliniaz importana, din punctul de vedere al auditorului, a rezultatelor i a fluxurilor pe care le genereaz. Capitolul al noulea, Auditul datelor, se refer la un proces complex ntruct vizeaz acele componente ale sistemului informatic care au ca obiectiv crearea i actualizarea fiierelor sau bazelor de date. Sunt prezentate criterii de validare a datelor. Se analizeaz modaliti de iniializare a variabilelor i se propun msuri 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 direcii de urmat. Bibliografia conine: tratate fundamentale de audit; cri privind metrici software i tehnici i metode de programare; lucrri elaborate de autori sub form de cri, articole i comunicri la manifestri tiinifice din ar i din strintate; articole din reviste de specialitate; site-uri care trateaz problemele de maxim actualitate, forumuri de discuii pe probleme de managementul calitii software i calitatea datelor. Autorii lucrrii au procupri n domeniul dezvoltrii aplicaiilor informatice, analizei metricilor utilizate n dezvoltarea software, calitii i costurilor calitii datelor i produselor program. Aceste preocupri s-au materializat prin participarea la manifestri tiinifice cu caracter

internaional, prin articole publicate att n ar, ct i n strintate, precum i prin cri aprute 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 apariiei, incluse n paranteze drepte. Diferenierile n cadrul lucrrilor aceluiai autor, aprute n acelai an, se fac prin adugarea, 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; - organizaii, reglementri i standarde referitoare la auditul SI. Datorit faptului c o serie de concepte i termeni nu au o traducere unanim acceptat n comunitatea specialitilor din ara noastr, pentru a nu introduce confuzii prin folosirea corespondenilor locali ai acestor concepte i termene, s-a preferat utilizarea denumirilor originale n limba englez. Lucrarea se adreseaz att specialitilor care dezvolt i implementeaz sisteme informatice, ct i utilizatorilor acestor sisteme. n lucrare sunt mbinate concepte, definiii, modele, tehnici i metode care se regsesc n literatura de specialitate, cu unele rezultate originale obinute de autori de-a lungul mai multor ani de cercetare. Autorii sunt recunosctori tuturor celor care, prin observaii i sugestii, contribuie la mbuntirea unei viitoare ediii a acestei lucrri.

1. SISTEME INFORMATICE COMPLEXITATE I COSTURI

Sistemul informatic are menirea de a acoperi toate problemele agentului economic, de a crea interdependene ntre componente, astfel nct structurii fizice din sistemul ataat agentului economic i se suprapune o structur n plan informaional. Fluxurilor de producie le corespund fluxuri informatice. Actorilor implicai n procese li se asociaz emitori i receptori de informaii cu niveluri diferite de prelucrare. Dezvoltarea direct de sisteme informatice se dovedete o ntreprindere riscant dac nu este precedat de activiti 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 construcii complexe, realizate pe parcursul mai multor ani, necesitnd: fonduri foarte mari, uriae n anumite cazuri; echipe complexe i stabile de analiti, designeri, programatori i personal care se ocup de testare, implementare i mentenan; stabilirea obiectivelor; definirea unei strategii de dezvoltare, exploatare i mentenan; achiziionarea de echipamente, instrumente necesare realizrii de prelucrri, de conexiuni i dezvoltrii 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 soluionate astfel nct, n final, s se obin rezultatele scontate. n primul rnd, pe durata ciclului de dezvoltare a unui sistem informatic au loc schimbri n echipa managerial a beneficiarului. n cazul n care o nou echip managerial are o alt viziune asupra indicatorilor

agregai pe care i fundamenteaz deciziile, se produc modificri n specificaii, care atrag modificri ale structurii sistemului informatic. n al doilea rnd, noile tehnologii informatice care apar impun adaptarea din mers a echipei de dezvoltare a sistemului informatic. Se produc schimbri n abordarea instrumentelor de asistare, n utilizarea de opiuni. n final, o serie de componente se construiesc utiliznd noile resurse. Sistemul informatic devine neomogen din punctul de vedere al tehnologiilor de dezvoltare. n al treilea rnd, dezvoltarea companiei prin achiziionarea de noi echipamente, reorganizarea fluxului de producie, trecerea la realizarea de noi produse, introducerea elementelor de management total al calitii vin s influeneze calitativ i cantitativ structura i funciunile sistemului informatic. Problema achiziiilor de date capt o alt dimensiune n cazul utilajelor cu comand program sau n cazul liniilor de producie robotizate. n al patrulea rnd, pe durata mai multor ani, nsi echipa de programatori, webdesigneri, testeri i implementatori sufer modificri. Diferii specialiti rentregesc echipa. Toate aceste fluctuaii se reflect n sistemul de lucru, n calitatea componentelor sau stadiilor sistemului informatic. n al cincilea rnd, mediul economic, legislaia i dinamica proceselor din societatea informaional conduc la evoluii care trebuie reflectate n sistemul informatic. Modificrile unor algoritmi de calcul, necesitatea de a utiliza noi coeficieni, apariia unor schimburi de informaii ntre companie i instituiile publice ale statului trebuie reflectate, de asemenea, din mers n sistemul informatic aflat n construcie. Toate aceste procese se deruleaz concomitent, producnd efecte conjugate, n timp ce obiectivul stabilit iniial, acela de a realiza un sistem informatic pentru managementul companiei, rmne nemodificat. Sunt situaii n care chiar condiiile privind termenele de predare rmn neschimbate. n cazul n care noile cerine conduc la creterea semnificativ a complexitii produsului final sistemul informatic pentru management se impune creterea volumului investiiei pentru a suplimenta resursele necesare dezvoltrii unui volum mai mare de activiti. Creterea volumului de activiti care se deruleaz n paralel impune noi abordri la nivelul concepiei sistemului informatic.

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 depinznd de tehnica de dezvoltare utilizat. Se construiete matricea de coresponden Ann pentru module. Elementul aij = 1 dac modulul MOi este apelat de modulul MOj, iar n caz contrar aij = 0. Se construiete matricea Bmn pentru a stabili relaia modul date. Elementul bij = 1 dac modulul MOj folosete structura de date Stri, iar n caz contrar bij = 0. Matricea Ann evideniaz referirile ntre module. Matricea Bmn evideniaz referirile de date de ctre module. Se evideniaz indicatorul Nrm numrul total al referirilor de module, prin relaia:
N rm = aij
i =1 j =1 n n

Se calculeaz indicatorul Nrd numrul total al referirilor de date de ctre module prin relaia:

N rd =

b
i =1 j =1

ij

Complexitatea sistemului informatic CSI, n sens Halstead, este dat de relaia: CSI = Nrm log2 Nrm + Nrd log2 Nrd n cazul n care sunt luate n considerare modificrile ce apar pe durata ciclului de dezvoltare, procesul de realizare a sistemului capt un caracter iterativ convergent. O iteraie k include toate procesele care se produc ntre dou modificri. Caracterul convergent vizeaz atingerea scopului iniial, simultan cu reducerea efortului de includere a modificrilor, pe msur ce procesul de realizare a sistemului informatic se apropie de final.

k k , N rd , respectiv CSIk. Pentru fiecare iteraie k se definesc N rm

Dac se calculeaz:

k= CSIk CSIk-1,
caracterul iterativ convergent vizeaz ca : irul 1, 2, ... L s fie un ir cu numr finit de termeni; 1 > 2> >L = 0.

n [BARO88] este stabilit o relaie ntre costul CO al sistemului informatic i complexitatea acestuia, de forma:
C O = e CSI + ,

unde , i sunt coeficienii estimai ai modelului. ntre productivitatea W a celor care elaboreaz un sistem informatic i complexitatea acestuia exist relaia:

W= f(CSI)
n [BARO88] relaia dintre complexitate i productivitate este de forma:

W = e CSI + ,
unde , i sunt coeficienii estimai. Durata de realizare D a sistemului informatic n funcie de complexitate i numrul salariailor, ns, este dat de relaia:

D = h(CSI, ns)
Numrul de salariai ns, funcie de complexitatea sistemului i de durata de realizare este dat de relaia:

ns = g(CSI1, D)

Dac se iau n considerare iteraiile 1 i L ale procesului de elaborare a sistemului informatic, pentru a menine acelai termen de predare la cheie, sunt estimate nivelurile:
1 n1 s = g CSI , D

n sL
iar diferena:

( ) = g (CSL , D ) ,
L

L1 = n sL n1 s reprezint sporul de salariai necesar asigurrii ncadrrii elaborrii sistemului informatic n termenul stabilit, chiar dac apar modificri n toate direciile care privesc sistemul informatic respectiv. Realizarea unui sistem informatic are menirea de a sprijini actul decizional la toate nivelurile. Sporul de informaie, calitatea acesteia, promptitudinea cu care se obine sunt argumente puternice pentru a determina saltul calitativ pe care l presupune societatea bazat pe cunoatere. Din aceste considerente, implementarea unui sistem informatic trebuie s genereze efecte pozitive att pentru utilizatorii si, ct mai ales, pentru beneficiarii direci ai informaiei prelucrate. Pentru a se obine acest deziderat, n procesul de elaborare este necesar aplicarea tuturor cerinelor privind managementul calitii sistemului informatic. De asemenea, este necesar s se realizeze auditul sistemului informatic pentru a se obine garania c acesta realizeaz corect i complet prelucrrile pentru care a fost proiectat, iar orice combinaie de date, alta dect cea corect i complet, este semnalat i nu este generatoare de efecte colaterale pe termen mediu i lung. n realizarea proceselor de auditarea dezvoltrii SI este necesar s se ia n considerare caracteristicile organizaiei pentru care se proiecteaz sistemul i, n primul rnd, stabilitatea organizaiei. Dezvoltarea SI se face n contextul evoluiei mediului economico-social. Dinamismul schimbrilor n cadrul organizaiilor, indiferent de dimensiunea acestora, impune adaptarea metodelor de dezvoltare a SI la noile condiii sau apariia unor concepte i metode noi de dezvoltare a SI.

Organizaiile n dezvoltare, denumite n limba englez, organizaii emergente, sunt organizaiile a cror constant o constituie ncercarea continu de adaptare la mediile n schimbare, dar care nu ating niciodat stabilitatea pentru care acioneaz. Acest tip de organizaii este foarte diferit de cele stabile. Din cauza ipotezelor fundamental diferite privind realitatea i dezvoltarea SI, procesele de proiectare a SI pentru organizaii stabile, respectiv emergente, sunt diferite. De fapt obiectivele celor dou procese sunt contradictorii [ALAT03]. Dezvoltarea SI pentru organizaii stabile are n vedere urmtoarele obiective [ALAT03]: - avantajele economice ale unei analize amnunite; - satisfacia utilizatorilor; - cerine abstracte; - specificaii complete i lipsite de ambiguiti. Obiectivele propuse pentru dezvoltarea SI destinate organizaiilor emergente sunt urmtoarele: - analiza dinamic; - negocierea cerinelor dinamice; - specificaii utile ambigue i incomplete; - redezvoltare continu. Printre metodele utilizate n dezvoltarea SI pentru organizaiile emergente se numr: modelarea conceptual i evaluarea utilitii i utilizabilitii. Modelarea conceptual la reproiectarea schimbrilor sistemului, iar evalurile utilizabilitii pot fi vzute ca o form de analiz referitor la analiza permanent care necesit a fi aplicat organizaiilor emergente. Analizele publicate n literatura de specialitate i unele cercetri ale autorilor demonstreaz c n cadrul SI sunt ntotdeauna necesare schimbri, aspect care se ia n considerare la auditarea SI.

2. CONSTRUIREA DE MODELE I STABILIREA DE LIMITE

Sistemele informatice complexe presupun stocarea de informaii privind un numr r de entiti E1, E2, ..., Er. Pentru fiecare element al entitii este definit un set de cmpuri de descriere. Experiena designerilor conduce la descrieri complete care nu mai trebuie mbuntite ulterior. Numrul de entiti depinde de profunzimea procesului de analiz n a identifica grade de omogenitate i criterii de alctuire a colectivitilor. Construirea modelelor reprezint o etap deosebit de important. Stabilirea variabilelor precum: Ni numrul de componente ale entitii Ei; NCi numrul de cmpuri cu care se identific factorii care definesc elementele entitii Ei; xijk nivelul cmpului cu poziia j pentru ablonul de descriere aparinnd elementului k din entitatea Ei. i identificarea condiiilor pe care trebuie s le ndeplineasc datele culese pentru a iniializa cmpul xijk reprezint o etap esenial n nelegerea particularitilor companiei pentru care se proiecteaz sistemul informatic. Pentru datele care sunt introduse n bazele de date se definete limita inferioar, LINF, respectiv limita superioar, LSUP. Astfel, pentru toate cmpurile se construiesc inegalitile 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 numr de ore, consumul maxim, Cmax, este dat de relaia: Cmax = TG*De

Consumul minim este zero. Rezult c nivelul consumului de gaze CGgijk respect inegalitatea dubl: 0 CGijk TG*Deik. Absena indicelui j se justific prin nominalizarea cmpului cu identificator propriu CG. Absena acestor limite de intervale genereaz situaii dintre cele mai bizare, care includ pentru efectuarea de calcule, unele valori aberante. Este cunoscut cazul unui cetean dintr-o comun vlcean cruia i s-a montat invers un contor de ap, fiind pus s plteasc pentru un consum astronomic. De asemenea, nu trebuie uitat nici posesoarea unui apartament de bloc care s-a trezit pltind un impozit cu mult mai mare dect al vecinilor de la celelalte etaje, ntruct apartamentul su, n mod eronat, a fost nscris cu o suprafa mai mare. Tot astfel de consideraii se fac i pentru consumatorii de electricitate care primesc facturi cu o valoare de cel puin 100 de ori mai mare. Chiar i cazul calculului eronat al unor pensii, care a generat numeroase procese, i a fcut istorie, fiind finalizat cu o scutire a plii unor datorii, trebuie dat ca exemplu ce nu trebuie urmat, privind neglijena cu care au fost stabilite limitele. Un sistem informatic conduce la realizarea unui salt calitativ. Permite fundamentarea deciziilor n cunotiin de cauz. El nu nlocuiete ceva cu altceva. El este cu totul altceva, att pentru executant, ct i pentru decideni, indiferent de nivelul la care se afl acetia. Cu o condiie, s fie construit ca instrument orientat spre management i nu ca un auxiliar care dezvolt aparatul birocratic. Existena limitelor de variaie are menirea de a filtra datele, iar la semnalizarea unor valori n afara intervalului se impune verificarea la faa locului i corectarea situaiei 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 experiena acumulat. n primul rnd, compania pentru care se elaboreaz sistemul este de un profil, de o dimensiune i de o complexitate asemntoare 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 asemntoare i stabilirea elementelor de comparaie pentru a obine un cost estimat, durata de realizare i, mai ales, eficiena pe care o aduce proiectarea, realizarea i implementarea unui sistem informatic pentru management.

n al doilea rnd, unei companii obinuite, aparinnd unei anumite clase, i se va realiza un sistem informatic adecvat, n concordan cu caracteristicile clasei. Complexitatea unui astfel de sistem nu depete semnificativ complexitatea medie a sistemelor informatice pentru companiile din aceeai categorie. n al treilea rnd, prin utilizarea de prototipuri, impuse de instrumentele de asistare pentru funciile de baz ale companiei, ntregul proces de analiz proiectare programare testare implementare capt o tent industrial, de rutin. n al patrulea rnd, existena procedurilor pentru derularea activitilor din companie definete fluxuri, stabilete condiii i orienteaz dezvoltatorul de sisteme informatice spre care direcie s orienteze demersul su pentru a obine un sistem informatic modern, operaional i eficient. n al cincilea rnd, existena unei game largi de modele, de tehnici de construire i de metode de msurare conduc la a stabili care este modelul cel mai potrivit. n al aselea rnd, regulile de asigurare a unui management al calitii sistemului informatic, odat cunoscute, trebuie aplicate n acelai fel. nseamn c noul sistem este tratat din punct de vedere al managementului calitii ca oricare alt produs din aceeai clas de complexitate. n al aptelea rnd, toate riscurile asociate procesului de dezvoltare a sistemului informatic au niveluri care nu difer semnificativ de nivelurile riscurilor corespunztoare sistemelor similare. Echipa care dezvolt un sistem informatic urmrete cel mult s scad nivelurile de risc, ceea ce conduce la creterea volumului de resurse, prin introducerea de noi proceduri. Ca n orice meserie i n cazul dezvoltrii de sisteme informatice se aplic reete sigure pentru reducerea diferitelor categorii de riscuri. n al optulea rnd, 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 dect o cer procesele care se deruleaz n companie. Mai ru, prin generarea de simboluri care nu aparin alfabetului, sistemul informatic devine automat stochastic, cu toate consecinele negative care se imagineaz. Concepia sistemului informatic are caracter unitar, urmrete un obiectiv unic i, prin modul de structurare, prin resursele alocate, se constituie ca un demers realist i, mai ales, realizabil.

3. REALIZAREA I MSURAREA CONCORDANEI

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 operaiile de prelucrare specifice unei tehnologii. Al doilea sistem este cel al materiilor prime care fac obiectul prelucrrilor prin trecerea de la un echipament la altul. Asupra lor se execut operaiile de prelucrare, rezultnd transformri. Al treilea sistem este acela de comand a execuiei, care include persoane calificate i, ntr-o msur mai mic sau mai mare, roboi cu grade diferite de flexibilitate n aciune i decizie. Al patrulea sistem este sistemul energetic care are menirea de a pune n micare utilajele i de a crea condiii optime persoanelor pentru a executa operaii. Al cincilea sistem este sistemul informaional. Rolul su este determinant, ntruct fluxurile informaionale au menirea de a declana funcionarea utilajelor, generarea fluxurilor materiale, creaz comunicarea dintre persoane. mpreun cu sistemul energetic controleaz toate etapele unui ciclu de producie. ntre cele cinci sisteme care alctuiesc compania trebuie s existe oricnd o concordan perfect. Primele patru sisteme, n mod obiectiv, sunt realizate i exist avnd 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 nct s se minimizeze neconcordanele. Aa se explic dimensionarea echipamentelor pentru a efectua operaii de prelucrare n condiii de siguran. Proiectarea unui echipament presupune dispozitiv de tiere, de msurare, de dirijare, de control. Sunt create sisteme de pornire, de oprire, de protecie i de supraveghere. Toate acestea exist, au form material caracterizat prin dimensiune, volum, poziionare spaial. Acionarea produce efecte vizibile direct, precum: msurare, tiere, lipire,

ajustare, asamblare, vopsire, amestecare, coacere etc. Pentru utilaj sunt definite operaii a cror caracterizare este precis. Sistemul materiilor prime, de asemenea, este compus din stocuri, din fluxuri n care componentele sunt descrise prin calitate, cantitate, form, dimensiune. Interaciunea sistemului materiilor prime cu utilajele determin transformri asupra materialelor. Astfel, o bar devine uruburi, piulie sau aibe. Sistemul energetic are menirea de a pune n micare echipamentele care prelucreaz materiile prime. Interaciunea dintre echipamente, materii prime i energie definete o tehnologie. Persoanele au menirea de a interaciona cu echipamentele, cu materiile prime i realizeaz conectarea echipamentelor la energie, determinnd, astfel, derularea de procese pe baz de tehnologii. Sistemul informaional 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 nclminte, toate echipamentele care alctuiesc liniile de producie efectueaz operaii specifice tehnologiilor de realizare a nclmintei. Sistemul materiilor prime este i el realizat n concordan cu obiectivul i cu cerinele sistemului de echipamente. Dac echipamentele sunt destinate prelucrrii pielei naturale, stocurile vor conine piele natural i niciodat nlocuitori. Calificarea persoanelor care alctuiesc sistemul forei de munc se realizeaz pentru a mnui materiile prime i pentru a executa operaii pe echipamentele din cele dou sisteme existente n companie, concordana fiind necesar pentru exploatarea corect a echipamentelor i pentru a nu produce rebuturi. n cazul sistemului energetic, concordana se realizeaz de la proiectare, cunoscut fiind aciunea devastatoare a existenei neconcordanei dintre caracteristicile sistemului la intrarea n echipamente i caracteristicile cu care echipamentele au fost nzestrate. i n cazul sistemului informaional este necesar existena unei concordane. n mod firesc, o tehnologie se conecteaz printr-o linie de echipamente care este nsoit de software pentru sistemul informatic la cheie.

Caracterul local, particular al oricrui sistem informatic este dat de: - legislaia rii unde se implementeaz tehnologia; - structurile documentelor; - stadiul informatizrii sistemului financiar-bancar; - diferenele prin care se dezvolt comunicarea ntre agenii economici, fiecare avnd 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 informaiei rolul de motor spre progresul ei nsi. Sistemul informaional 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 forei de munc. Neconcordanele dintre sistemul informaional i celelalte sisteme creaz probleme n principal prin neutilizarea resurselor la nivelurile pentru care au fost proiectate. Acest mod de a realiza concordana explic de ce aceleai echipamente, aceleai materii prime, aceleai consumuri energetice, aceleai persoane au performane diferite, n funcie de context. Conceptul de context include nsi sistemul informaional ca expresie a cerinelor managementului distribuit pe nivelurile de structurare a companiei. Dezvoltarea unui mod dinamic de a derula procese i de a fundamenta decizii, depinde de numeroi factori, dintre care cei care definesc persoanele, calitile i defectele acestora, au o pondere nsemnat. n primul rnd, concordana dintre sistemul informaional i celelalte sisteme, ntre care exist deja concordan de natur obiectiv, se realizeaz prin definirea de fluxuri de informaie, concretizate prin mesaje comensurate direct sau prin documente care urmresc fluxurile de producie, specifice echipamentelor i materiilor prime care prin transformri devin repere, subansambluri i, n final, produse finite. n al doilea rnd, concordana se realizeaz prin stabilirea de puncte de preluare a mesajelor care reflect activiti efectuate, operaii executate, stadii, stri ale echipamentelor. Trebuie realizat un echilibru ntre numrul emitorilor poteniali i capacitatea de preluare a mesajelor n vederea prelucrrii. n al treilea rnd trebuie stabilite procedurile de prelucrare a mesajelor. Aceste proceduri trebuie s fie complete, n sensul lurii n considerare a tuturor tipologiilor de mesaje care se constituie ca intrri pentru algoritmii de prelucrare. Procedurile de prelucrare au un nivel de

complexitate deosebit de ridicat, limitnd elementele care introduc riscuri n derularea proceselor decizionale. n al patrulea rnd, concordana sistemului informaional este obinut din modul n care abaterile din procesul tehnologic sunt corectate prin decizii luate rapid. Este vorba de viteza de reacie pe care o asigur managementul prin canalele informaionale. n al cincilea rnd, concordana dintre sistemul informaional i celelalte sisteme este dezvoltat odat cu definirea unor modaliti de culegere automat a datelor i prin utilizarea unor algoritmi bazai pe eantionarea datelor din volume foarte mari de date. Trecerea de la sistemele n care sunt nregistrate cantiti, valori, durate, la sistemele care preiau momente de start i de ncheiere a unor activiti sau de definire a strilor, asigur saltul calitativ de la tratarea calitativ a comportamentului de producie care este compania. n al aselea rnd, concordana se asigur eliminnd elementele subiective, dictate de tradiionalismul, de rutina specific unui mod nvechit de tratare a informaiei, nici ca materie prim, nici ca produs finit, nici ca purttor de valoare, ci pur i simplu ca mesaj auxiliar, opional n derularea proceselor, care oricum se deruleaz i fr 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, aciuni i noi mesaje. Sistemul informaional devine o component de sine stttoare a companiei care se definete prin toate dimensiunile pe care le au toate celelalte sisteme care compun compania. n al aptelea rnd, sistemului informaional i se asociaz costuri. Sunt costurile de definire, costurile de funcionare. La rndul su, prin efectele pe care le genereaz mesajele definite n sistem genereaz costuri. Diferenele de costuri dau ponderea eficienei circulaiei informaiilor n companie. Apar situaii n care costul informaiei se stabilete direct, o dat cu el se obine fie nivelul de profit, fie nivelul pierderilor. Informaia 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 piaa recunoate aceste rezultate sau pierderi. A privi sistemul informaional ntr-o

alt abordare, nseamn a crea o component la nivelul companiei care frneaz evoluia acestuia, distrugnd-o. n al optulea rnd, concordana sistemului informaional este o problem de timp. Concordana se dobndete, se menine, dar se i pierde cu mare uurin atunci cnd apare un decalaj ntre dinamica proceselor de producie i dinamica mesajelor care circul n companie. Noilor moduri de organizare a produciei trebuie s le corespund modaliti adecvate de culegere, prelucrare i transmitere a informaiei. Concordana are un caracter global i include n aceeai msur i cu aceeai intensitate toate cele cinci sisteme ale companiei. Ea este o caracteristic pentru a asigura normalitatea derulrii tuturor proceselor din companie, ncepnd cu planificarea, continund cu aprovizionarea, producia, desfacerea i ncheind cu reflectarea n plan financiar - contabil a tuturor transformrilor i transferului, respectiv, cu toate deciziile echipei manageriale. Absena concordanei, mai ales n plan informaional, creeaz decalaje care presupun luarea de decizii bazate pe un minus de informaie. n plus, scderea acurateei informaiei transform seturile de mesaje n mesaje incomplete, cu efecte directe asupra creterii ponderii deciziilor bazate pe incertitudine. Devin frecvente situaiile 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 informaiei furnizate de un sistem informaional neconcordant. Din aceste considerent, auditarea unui sistem informatic dezvoltat pentru o organizaie va avea n vedere existena concordanei ntre subsisteme. n final, pentru certificarea sistemului informatic, trebuie ca nivelurile planificate ale caracteristicilor de calitate s fie mai mari sau egale dect nivelurile reale. n activitatea de informatic aplicat trebuie parcurse pe lng etapele ciclului de dezvoltare, o serie de activiti care au menirea de a stabili c produsul program, baza de date, interfaa web sau oricare alte componente, este exact ceea ce trebuie. Aceste activiti au menirea de a stabili c exist concordan ntre ceea ce s-a planificat i produsul finit existent. Faptul c activitile sunt derulate de persoane aparinnd unor organisme independente, reprezint garania c rapoartele consemneaz diferenele reale dintre proiect i produs.

Auditarea reprezint o activitate deosebit de important pentru companiile care realizeaz sisteme informatice, ntruct rezultatele procesului de auditare se constituie n baz pentru fundamentarea deciziilor pe termen lung privind politicile companiei. Certificarea echipelor, companiilor, persoanelor, produselor informatice, evideniaz capacitatea de a derula procese, tranzacii, capacitate care trebuie s se manifeste ori de cte ori se dezvolt un produs, prin respectarea standardelor, prin utilizarea tehnicilor, modelelor i instrumentelor adecvate. Toate elementele converg spre obinerea de produse i servicii de calitate. Exist o important deosebire ntre ceea ce se dorete i ceea ce se efectueaz, se obine i se utilizeaz n activitatea economic de zi cu zi. Garantarea calitii este un concept de mare importan, complexitate i dinamic. Existena unei mrci este fundamentat pe existena unei conduite, pe definirea de proceduri restrictive, calificarea continu a persoanelor pe existena unui management suficient al calitii i pe formarea contiinei orientate spre calitate. Indiferent de contextul n care o companie ce dezvolt sisteme informatice i desfoar activitatea, societatea informaional, n stadiul artat, impune ca dezvoltarea de sisteme informatice s genereze un efect de antrenare multipl, n direcia pozitiv, a evoluiei gradului de satisfacie nregistrat de utilizatorul final.

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, menine integritatea datelor prelucrate i stocate, permite atingerea obiectivelor strategice ale ntreprinderii i utilizeaz eficient resursele informaionale. n cadrul unei misiuni de audit a sistemului informatic cele mai frecvente operaii sunt verificrile, evalurile i testrile mijloacelor informaionale, astfel[BRN04]: - identificarea i evaluarea riscurilor din sistem; - evaluarea i testarea controlului din sistem; - verificarea i evaluarea fizic a mediului informaional; - verificarea i evaluarea administrrii sistemului informatic; - verificarea i evaluarea aplicailor informatice; - verificarea i evaluarea securitii reelelor de calculatoare; - verificarea i evaluarea planurilor i procedurilor de recuperare n caz de dezastre i continuare a activitii; - testarea integritii datelor. Auditul informatic reprezint o form esenial prin care se verific dac un SI i atinge obiectivul pentru care a fost elaborat. Standardele definesc clar domeniul, activitile, etapele, coninutul auditrii i formele de finalizare. Respectnd cerinele standardelor, rezultatul procesului de auditare informatic este eliberat de riscurile contestrii. Auditul informatic reprezint un domeniu cuprinztor n care sunt incluse toate activitile de auditare pentru : specificaii, proiecte, software, baze de date, procesele specifice ciclului de via ale unui program, ale unei aplicaii informatice, ale unui sistem informatic pentru management i ale unui portal de maxim complexitate, asociat unei organizaii virtuale. n domeniul informatic exist mai multe direcii de dezvoltare a auditului.

Auditarea software const n activiti prin care se evideniaz gradul de concordan dintre specificaii i programul elaborat. Auditul software d msura siguranei pe care trebuie s o aib utilizatorul de programe atunci cnd obine rezultate. Sigurana se refer la corectitudinea i completitudinea rezultatelor finale atunci cnd datele de intrare sunt, de asemenea, corecte i complete. Auditul bazelor de date, este un domeniu de maxim complexitate avnd n vedere c, de regul, lucrul cu bazele de date presupune att datele ca atare nsoite de relaiile create ntre ele, ct i programele cu care datele se gestioneaz. De aceea se impune efectuarea unei reparri. Auditul datelor vizeaz definirea acelor elemente prin care se stabilete msura n care datele stocate ndeplinesc cerinele 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 auditrii. n final, auditorul de date certific faptul c datele stocate n baze de date constituie intrri valabile pentru a obine rezultate corecte. n cazul auditrii riscului de gestiune a datelor stocate n baze de date se verific dac: - programele refer corect cmpurile cu date stocate; - operaiile de prelucrare sunt cele din specificaii; - agregrile, sortrile, evalurile de expresii de extragere a subseturilor de date sunt n concordan cu specificaiile de obinere a rezultatelor ca structur, dimensiune i coninut. Auditul sistemelor informatice evalueaz riscurile unui mediu informatic sau ale unei aplicaii informatice, ca de exemplu calculul salariilor sau facturarea. Aceste misiuni se realizeaz alegnd, mpreun cu clientul, procesul de evaluare. Auditul informatic se poate referi la evaluarea riscurilor informatice ale securitii fizice, securitatea logic, managementul schimbrilor, planul de asisten etc. n cazul general, auditul informatic se refer la un ansamblu de procese informatice pentru a rspunde la o cerere precis a clientului. De exemplu, aprecierea disponibilitii informaiilor i a sistemului. n acest caz se controleaz care dintre procesele informatice rspund cel mai eficient la o asemenea cerere. n cazul disponibilitii, de exemplu, securitatea fizic i planul de continuitate.

Auditul informatic poate, de asemenea, s evalueze aspecte strategice sau referitoare la calitatea sistemelor informatice. De exemplu, s verifice dac sistemul informatic al ntreprinderii rspunde n mod eficient la nevoile funciilor serviciului. Auditul mediului informatic se execut pentru a evalua riscurile sistemelor informatice necesare funcionrii aplicaiilor. De exemplu: securitatea fizic, securitatea logic, securitatea reelelor, plan de salvare. n urma auditrii, se ntocmete un raport n care sunt prezentate punctele slabe, nivelul de risc al acestora i msurile corective propuse. Analistul informatic are la dispoziie 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 aplicaie care utilizeaz o baz de date. Pentru un sistem informatic complex exist metode adecvate de auditare, iar pentru aplicaiile web accentul auditrii este pus pe gradul de satisfacie a grupului int. Aplicaiile mobile au fundamente de auditare n care accentul este pus pe asigurarea continuitii, compatibilitii, accesibilitii rapide la resurse i, mai ales, asupra nivelului atins de asigurarea securitii fluxurilor din ntregul sistem. De aceea, n cadrul procesului de audit informatic, planificarea i definirea metodei de audit este esenial. Alegerea unei metode neadecvate conduce la utilizarea de instrumente neadecvate, iar rezultatele auditului au caracter speculativ. Alegerea metodei presupune obinerea unor informaii privind contextul n care se deruleaz procesele legate de produsul software, de aplicaia informatic sau de sistemul informatic, obiecte ale auditrii. Auditul este, prin complexitatea sa, o activitate n care sunt luate n analiz legturile, implicaiile pe care le genereaz produsul software, aplicaia informatic sau sistemul informatic ntre dezvoltator - compania de software i utilizator. Raporturile trebuie privite din punct de vedere tehnic, financiar i juridic. Aspectul tehnic privete date de interior, algoritmi, rezultate, resurse folosite. Aspectul financiar vizeaz costul estimat al produsului software, aplicaie, sistem informatic i costul efectiv, modul n care s-au efectuat plile. Caracterul juridic al abordrii vizeaz obligaiile contractuale i legislaia din domeniul informatic. Toate aceste elemente conduc la stabilirea unor proceduri preliminare prin care sunt definite direciile de analiz, gradul de semnificaie pe care procesul de audit informatic l ofer i riscurile ca unele

concluzii s fie infirmate de practica derulrii proceselor de utilizare curent a produsului software, a aplicaiei informatice sau a sistemului informatic n integralitatea lui. Pentru a realiza auditul informatic se definete planul de audit general i programul de audit. Structura planului i definirea programului sunt standard, presupunnd parcurgerea unor pai obligatorii. Specificitatea produsului software, a aplicaiei 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, ealonarea etapelor din program au elemente de variabilitate legate strict de structura i de diversitatea produselor informatice analizate. Standardele de auditare includ suficiente elemente astfel nct planul general i programul de audit s fie riguroase, fr ambiguiti i, mai ales, operaionale. 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 schimbrile care au loc n produsele informatice auditate, trebuie efectuate teste asupra mecanismelor de control i a mecanismelor de testare pe teste surs, pe specificaii, pe diagrame, pe documentaii, pe structuri de rezultate. Pentru a obine 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 corecii asupra modalitilor n care se includ procedee tehnice, metode, modele de analiz/control a produselor informatice. Procesul iterativ se ntrerupe atunci cnd estimarea probabilitii ca rezultatele auditrii informatice s fie afectate de erori a atins un prag acceptabil. Auditul propriu-zis include proceduri analitice, teste, prin care se evideniaz diferenele dintre ceea ce s-a planificat a se realiza i ceea ce s-a realizat. Procedurile analitice au la baz contractele ncheiate ntre pri, minutele care detaliaz obiective, sarcinile ce revin partenerilor, specificaiile. Auditorul tehnic trebuie s ierarhizeze informaiile astfel nct 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 aplicaie informatic desktop sau n reea, fie c este vorba de un sistem informatic care vizeaz ntreaga activitate a unei organizaii.

Toate procedurile analitice i textele de detaliere aplicate modulelor, programelor i sistemelor de programe, au menirea de a evidenia comportamentul, pas cu pas, a secvenelor de program. n cazul n care auditorul informatic are la baz pregtire de programator, tie s aleag din multitudinea de proceduri i texte cu caracter analitic, pe acelea care ofer informaia 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 verificri ale intercondiionrilor 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 prelucrri, corespunztoare momentului t + 1. n acest fel, produsul informatic, proiectat pentru derularea unor seturi de prelucrri, este analizat innd cont tocmai de succesiunea prelucrrilor. Auditul informatic are la baz nregistrri privind structura software, structura bazei de date, nregistrri ale lungimilor, volumului, complexitii i nregistrri complete asupra comportamentului n timpul execuiei. n cazul n care exist seturi de date cu care au fost testate produse informatice din aceeai clas cu produsul auditat acum, se colecteaz serii de date privind comportamentul produsului pentru a fi comparat cu produsele deja existente. Cnd nu exist date, sunt generate i testarea produsului se realizeaz simultan cu produse din aceeai 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 soluie final, imparial, pentru a justifica ipotezele unei pri contractante, fie c este vorba de cumprtor de software, fie c este vorba de beneficiar, cnd acetia cred n dreptatea lor absolut. n general, auditul este descris ca Examinarea independent a nregistrrilor i a altor informaii n scopul formrii unei opinii referitoare la integritatea sistemului controalelor i mbuntirea controalelor recomandate pentru limitarea riscurilor. Definiia conine termeni semnificativi ca [HINS05]: - examinare; auditiarea implic culegerea i evaluarea informaiilor factuale din surse variate; este important ca rezultatele procesului de auditare (raportul primar de audit care conine recomandri pentru

mbuntirea controalelor) s fie urmrit pn la sursele de informaii valide; - independent; auditorii nu sunt implicai direct n operaii sau n managementul funciei care se auditeaz; subordonarea lor trebuie s le asigure exprimarea liber a opiniilor; - nregistrri i alte informaii; termenii includ ceea ce adeseori sunt numite inregistrri de audit; auditorii trebuie s se refere la informaii privind procesul afacerii i sistemele aflate n revizii aa cum sunt formele complete de intrri de date, rapoarte generate de sistem i, bineneles, personalul implicat n desfurarea sau conducerea proceselor afacerii auditate; - opinie; auditorii furnizeaz att fapte obiective ct i opinii subiective pe o situaie dat; dei subiective, opiniile lor sunt bazate pe interpretarea faptelor i sunt deschise discuiilor; se poate s nu se fie de accord cu aceste opinii, dar trebuie purtat o discuie complet i sincer; - integritate; termenul integritate include completitudine, acuratee i credibilitate; un control al unui sistem care este numai parial efectiv poate fi mai bun dect nimic, sau poate da un sens fals de securitate; auditorul va lua n considerare ambele ci; - recomandare; auditorii genereaz recomandri, dar nu au autoritatea nici s implementeze schimbrile sugerate, nici s impun managementului s fac schimbri; mbuntirile se obin numai printr-un proces de explicare, justificare i persuasiune, explicnd riscurile reprezentate de punctele slabe constatate n SI n urma auditrii, justificnd nevoia de schimbare n cadrul procesului i/sau sistemului i sugernd managementului necesitatea alocrii unor resurse i luarea de msuri pentru gestionarea riscurilor; - mbuntirea controalelor; mbuntirea sistemului de control nseamn, n general, adugarea controalelor care lipsesc; sunt foarte rare cazurile n care auditorii pot recomanda eliminarea unor controale, n general, din cauz c ele sunt ineficiente, distrugtoare 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 pregtirea pentru aciune n cel mai ru caz posibil care s-ar putea produce (planificare pentru aciuni n caz de dezastre); - risc; posibilitatea ca ceva s se desfoare ntr-o direcie nefavorabil; formal, riscul este posibilitatea combinrii ameninrilor

cauzate fie de cineva cu intenii rele, fie din neglijen sau incompeten, acionnd asupra vulnerabilitilor sistemului; vulnerabilitile 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 eficienei organizaiilor, sistemelor, proceselor riscurilor i controalelor. Auditurile dau posibilitatea managementului s: - descopere ceea ce se ntmpl n realitate la un moment dat; - depisteze problemee poteniale nainte de a fi prea trziu pentru remediere; - evalueze n mod obiectiv situaia afacerii; - accepte realitatea i s ia, n cunotiin de cauz, decizii chiar dac sunt dificile; - implementeze aciuni corective, schimbri i mbuntiri 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 experimentai controleaz dac procesele de management pentru realizarea i evaluarea conformitii sunt eficiente, care reguli sunt potrivite i suficiente pentru SI auditat. Auditorii sesizeaz mai mult absena conformitii i nu att de mult cutarea simptomelor problemelor n adncime. Organizaiile de audit n SI au ci diferite de desfurare a auditrilor, iar auditorii au metodele lor preferate de lucru. Amploarea unui audit informatic presupune realizarea n mod normal, a unei balane ntre cantitate, referitor la numrul subsistemelor din compunerea unui SI care se auditeaz i calitate, nsemnnd nivelul de detaliere la care se auditeaz subsistemele selectate. Resursele auditului SI sunt direcionate, n primul rnd, ctre zonele cu grad ridicat de risc. Aplicaiile utilizate n zonele critice ale afacerii se recomand s fie revizuite anual. Zonele cu nivel de risc mai sczut pot fi auditate la intervale mai mari, n general odat la trei ani, imediat dup un incident sau cnd se consider necesar de ctre echipa managerial.

Principalele tipuri de audit informatic sunt [HINS05]: - auditul sistemului operaional de calcul; revizia controalelor sistemelor operaionale de calcul i reelelor, la diferite niveluri; de exemplu, reea, sistem de operare, software de aplicaie, baze de date, controale logice/procedurale, controale preventive/detective/corective etc; - auditul instalaiilor 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) specificaiile, dezvoltarea, testarea, implementarea i operarea controalelor tehnice i procedurale, incluznd controalele securitii tehnice i controalele referitoare la procesul afacerii; - auditul managementului IT; include: revizia organizaiei, structurii, strategiei, planificrii muncii, planificrii resurselor, stabilirii bugetului, controlul costurilor etc.; n unele cazuri, aceste aspecte pot fi auditate de ctre auditorii financiari i operaionali, lsnd auditorilor informaticieni mai mult aspectele tehnologice; - auditul procesului IT; revederea proceselor care au loc n cadrul IT cum sunt dezvoltarea aplicaiei, testarea, implementarea, operaiile, mentenana, gestionarea incidentelor; - auditul managementului schimbrilor; revizia planificrii i controlului schimbrilor la sisteme, reele, aplicaii, procese, facilitai etc., incluznd managementul configuraiei, controlul codului de la dezvoltare, prin testare, la producie i managementul schimbrilor produse n organizaie ca rezultat al ICT; - auditul controlului i securitii informaiilor; revizia controalelor referitoare la confidenialitatea, integritatea i disponibilitatea sistemelor i datelor; - auditul conformitii cu legalitatea; copyright, conformitate cu legislaia, protecia datelor personale; - auditul accidentelor dezastruoase/planificrii continuitii afacerii/refacerii dup dezastre; reviziile msurilor propuse pentru restaurarea dup un dezastru care afecteaz sistemul i evaluarea modului n care organizaia abordeaz managementul riscurilor; - auditul strategiei IT; revizia aspectelor variate ale strategiei IT, viziune i planuri, inclusiv relaiile cu alte strategii, viziuni i planuri.

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 corespunztor al proiectelor este mai mult o excepie dect o regul [HINS05]. Un auditor experimentat n domeniul SI depisteaz simptomele unui dezastru iminent privind evoluia 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 obligaii, evaluri sau alocri, prezentri sau divulgri. Auditul sistemelor informatice implic: - executarea unei serii de teste pentru a se asigura c exist un control adecvat asupra sistemului informatic; - controale generale; - controalele aplicaiilor. Controale generale presupun: - controale care afecteaz mediul de procesare al calculatoarelor incluznd: o managementul resurselor computerelor; o copii de salvare i arhivare; o controlul schimbrilor n programul computerului; o controlul sistemului de operare. Controale ale aplicaiilor: - specific pentru o aplicaie: o acceptarea datelor autorizate; o procesarea este complet i corect; o output-urile sunt corecte i credibile. Controalele generale formeaz baza controalelor aplicaiilor. Auditul informatic trebuie astfel planificat nct s se obin rezultatele pe care le urmresc att auditorul ct i organizaia auditat. n planificarea auditului, auditorul trebuie s neleag sistemul i s planifice auditul. Auditorul trebuie s neleag complexitatea sistemului informatic i, de asemenea, modul n care mediul n care evolueaz sistemul informatic influeneaz evaluarea i controlul riscurilor. Auditorul trebuie s nceap cu intervievarea echipei manageriale i a personalului din sistemul informatic pentru a culege informaiile necesare

desfurrii auditului. Auditorul trebuie s examineze activitile care se desfoar n cadrul funcional al sistemului informatic, s revad documentele elaborate de auditrile anterioare i s revad documentaia sistemului informatic. Este necesar ca auditorul s revad informaiile colectate astfel nct s capete o bun nelegere a tuturor controalelor care exist n cadrul organizaiei. Auditul este o activitate complex, realizat de specialiti cu nalt calificare i experien n domeniu. Auditul nu este o activitate de control. Orice activitate de control presupune existena unui sistem n funciune. Controlul are menirea de a stabili dac au fost respectate sau nu procedurile de desfurare a activitilor, dac s-au nregistrat plusuri sau minusuri. Se stabilesc diferenele dintre nivelurile reale i cele scriptice i se propun msuri 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 funcioneaz corect/normal, fie c exist abateri n plus sau n minus i apar sanciuni i msuri de remediere, respectiv de valorificare. Auditul nu este o activitate de expertizare. O expertiz presupune dou pri adverse, cel puin, i mai multe cauze care au generat un eveniment. Expertiza se execut de specialiti, numii experi, cu vast experien n domeniul evenimentelor. Expertiza are menirea de a stabili cauze, de a demonstra legtura dintre cauze i efecte. Expertiza se concretizeaz printr-un raport care are menirea de a clarifica, fr a mai lsa loc interpretrilor, toate aspectele definite de cei care au solicitat-o. Se fac expertize la accidente, la modul n care au fost realizate construcii. Sunt expertize judiciare, sunt expertize contabile, sunt expertize tehnice. Expertizele se repet. Exist superexpertize aa 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 direcie. Se stabilesc vinovai atunci cnd controlul, respectiv expertiza, o cer. Auditul presupune un produs nou care se lanseaz n uz curent. Specialitii 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 ctre o echip independent care se bucur de credibilitate. Credibilitatea echipei de auditori este transferat, prin

intermediul raportului, asupra produsului auditat. La livrarea unui produs auditat, prin specificarea echipei de auditare, cumprtorul/utilizatorul capt ncrederea c produsul achiziionat are, n realitate, parametrii nscrii n documentaie, la nivelurile specificate. De asemenea, cumprtorul/utilizatorul primete toate informaiile legate de avantaje, performane, dar, n egal msur, primete i informaiile privind riscuri i efecte secundare, negative sau pozitive, rezultate din construcia produsului. Cnd este finalizat un sistem informatic exist: - documentaia privind contractul pe baza cruia se construiete sistemul, fondurile disponibile, duratele de timp rezervate; documentaia cuprinde obiectivul sistemului informatic, sarcinile ce revin echipei de realizatori i sarcinile care revin beneficiarilor; - documentaia tehnic n care este definit calitatea planificat, exigenele exprimate de beneficiar i modul n care se efectueaz testarea ntregului sistem; - specificaiile sistemului informatic i minutele ncheiate ntre realizator i beneficiar care au reiterat acele aspecte necesare satisfacerii cerinelor 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 soluii care au acoperire n plan informatic, platforme i arhitecturi moderne; - setul de date de test discutat i avizat de beneficiarul sistemului informatic, inclusiv indicaiile pentru generarea de extensii de date de test att de ctre realizatorul sistemului, ct i de ctre beneficiar, fr ca aceste extensii s depeasc structurile definite n contractul pe baza cruia se dezvolt investiia; - setul de nregistrri privind comportamentul sistemului pe parcursul efecturii testelor; sunt incluse i procedurile, algoritmii i rezultatele intermediare ale indicatorilor de calitate aa cum au rezultat pentru diferitele componente ale sistemului informatic; - evidenele de distribuire a sarcinilor pe membrii echipei de realizatori, rezultnd cu claritate ce module a realizat un anumit programator, ce componente a testat un specialist n evaluarea subsistemelor, ce date au fost ncrcate de fiecare operator n parte; aceste evidene conin i termenele i consumurile de resurse pentru a stabili corelaia dintre calitate i cost, dintre consumurile de resurse i complexitatea componentelor realizate;

- documentaia 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 semnificaia fiecruia; sunt indicate valorile implicite i combinaiile de opiuni care pun n oper sistemul de programare; se definesc condiiile minimale care trebuie asigurate pentru ca sistemul s fie operaional; - rapoartele de predareprimire pentru asamblarea componentelor; - rapoartele de testare ale subsistemelor de programe folosind datele de test convenite cu beneficiarul i ncrcate n bazele de date de test; rapoartele de testare ale ntregului sistem; - rapoartele grupurilor de lucru pe parcursul derulrii procesului de dezvoltare, urmrindu-se fiecare etap a ciclului de realizare; - fiierele cu variantele de module, de biblioteci de obiecte, nsoite de rapoartele de acceptare i de unele comentarii privind trecerea de la o variant la alta; - documentaia 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 rspunde cerinelor formulate n contractul n baza cruia s-a efectuat investiia. Pentru a avea un audit de calitate trebuie ndeplinite urmtoarele condiii: - echipa de auditare trebuie s primeasc totalitatea informaiilor care s constituie intrri ale procesului de auditare; - tehnicile i metodele de auditare trebuie s fie utilizate corect, folosind tot ceea ce este necesar pentru a obine rezultate reale, neafectate de factorii perturbatori sau de abordri pariale; - s existe clar delimitat ceea ce trebuie s realizeze sistemul informatic i ceea ce realizeaz efectiv; auditarea scoate n eviden diferenele, efectund i unele cuantificri, pentru a reiei mai precis pentru fiecare cerin n parte, ponderea a ceea ce lipsete sau ponderea a ceea ce este n plus. Pornind de la obiectivul auditrii, de la importana pe care o prezint rezultatul auditrii, echipa de specialiti dimensioneaz efortul care trebuie

depus de la ntocmirea planului de auditare, ca atare, i pn la elaborarea raportului de auditare. La desfurarea obiectivului auditrii trebuie s fie introduse acele elemente care subliniaz ncrederea pe care utilizatorul sistemului informatic trebuie s o aib pe durata exploatrii. Raportul de auditare trebuie s fac dovada n mod convingtor c achiziionnd un produs sau utiliznd un sistem informatic rezultat al unui proces investiional, utilizatorul va beneficia de servicii de calitatea dorit. La fel ca n cazul unei operaii chirurgicale, n care viaa pacientului este mai presus de orice, n auditul sistemelor informatice nu exist o difereniere n profunzimea cu care este abordat procesul de auditare. Dac obiectivul definit este cu un enun comun precum stabilirea concordanei dintre produsul dorit i cel real n vederea consolidrii ncrederii n utilizarea produsului real, el trebuie interpretat prin prisma rigurozitii i profesionalismului cu care sunt parcurse toate etapele. Este cunoscut faptul c auditarea unui produs, de complexitatea sistemelor informatice, reprezint o investiie moral, a crei pierdere nu se mai recupereaz niciodat. Companii renumite de audit au disprut atunci cnd 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 nemulumirea, iar dup un timp dorete s recupereze pe cale judiciar daune. Atunci productorul cere auditarea sistemului informatic pentru a restabili c produsul e bun, altele fiind cauzele care genereaz nemulumirea 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 concordana 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 specialiti, iar acetia, la rndul lor, trebuie s aib o bogat experien profesional i vaste cunotiine teoretice. Un sistem informatic nu se auditeaz de persoane care nu stpnesc domeniul afectat etapei din procesul de auditare. Aa cum n dezvoltarea sistemului informatic exist un ciclu de dezvoltare, divizat n etape, tot aa exist etape ale ciclului de auditare. Fiecare etap reprezint un sistem de diviziune a muncii, iar comunicarea este un factor esenial. Este vorba de comunicarea ntre membrii echipei de auditare, respectiv, comunicarea ntre auditori. De

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 cror auditare prezint anumite pariculariti. Sistemele informatice pentru management sunt construcii deosebit de complexe care au ca obiectiv ridicarea la cote maxime a procesului de informatizare la nivelul organizaiilor. Dac o organizaie este caracterizat prin funciile F1, F2,...Fk, structura sistemului informatic pentru management include k subsisteme, SS1, SS2,...SSk, pentru fiecare funcie un subsistem. ntregul sistem informatic este proiectat sub forma unor subsisteme cu stabilirea legturilor 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 cunoatere n detaliu a stadiului actual atins de procesul de informatizare la nivelul organizaiei. Exist sisteme puternice de gestiune a bazelor de date, de soluionare a problemelor definite n cadrul fiecrei funcii din organizaie. Trecerea la dezvoltarea unui sistem informatic pentru management trebuie s ia n considerare existena acestor componente. n acelai fel se pune problema i n cazul n care se dorete dezvoltarea de sisteme de gestiune a documentelor, din moment ce exist deja astfel de sisteme livrate la cheie. A spune acum c o organizaie are particularitile 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 organizaia este att de special nct 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 entiti, produsul program sau aplicaia informatic. Literatura de specialitate include numeroase lucrri care se adreseaz celor care elaboreaz sisteme informatice orientate pe gestiune financiar-contabil.

Auditul acestor sisteme este o problem extrem de actual pentru c: - sistemele informatice de gestiune contabil neauditate conduc la efectuarea de operaii neautorizate; - sunt situaii n care nu exist concordan ntre teoria contabilitii i procedurile care se apeleaz pentru a efectua prelucrri; - n faza de analiz sunt definite incomplet cerinele care corespund laturilor calitative i cantitative definite prin relaia ntre conturi, prin restricii privind efectuarea de operaii i prin proporii impuse unor niveluri cu care se efectueaz debitrile sau creditrile; - prioritilor de efectuare a operaiilor existente n teoria contabil trebuie s le corespund secvene de testare care s asigure concordana ntre listele prioritilor existente n teoria contabil i listele generate prin procesele de prelucrare prin programe; - validrile datelor capt o alt semnificaie, fiind legate nu numai de apartenena la un anumit domeniu de variaie, ci fiind dependente de context, ntruct operaiunile contabile sunt definite n cadrul unui anumit context; - interfeele acestor sisteme trebuie s fie orientate spre o abordare a proceselor n timp real, ntruct numeroase operaii se deruleaz prin sistemul e-banking, e-commerce; operatorii trebuie s lucreze n regim responsabilizat cu nregistrarea operaiei ntr-o structur impus din care s nu lipseasc momentul efecturii operaiei i elementele de identificare a operatorului; - ntre sistemul de restricii de acces la efectuarea de operaii n baza de date i cerinele 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 pri din baza de date, sunt alte persoane din organizaie care au drept de a consulta numai operaiile care privesc activitatea lor; lista persoanelor care opereaz pe baza de date se definete aa nct, pe msura creterii importanei operaiei n baza de date, numrul i funcia n organizaie se definesc cu un nivel de exigen sporit, regulile impuse au menirea de a ine sub control totalitatea operaiilor pe cmpurile bazei de date; - sistemul informatic de gestiune financiar-contabil se proiecteaz incluznd numeroase chei de control care s evidenieze frecvene ale unor operaiuni, apropierile de limitele domeniilor de variaie, astfel nct s se ia rapid deciziile adecvate; - la proiectare i la realizare se definesc situaiile de blocare pentru a semnaliza tentativele de efectuare a operaiilor interzise;

- aceste sisteme sunt organizate ca structuri ierarhice, cu intervenii 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 operaia 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 lng funciile clasice de prelucrare, de extragere a rezultatelor i de creare-actualizare a bazei de date, cu funcii de management pentru calitatea i protecia sistemului informatic nsui. Marile probleme rezultate n activitatea curent a implementrii 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. Aa 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 implementrii unui sistem informatic de gestiune contabil, toate aceste tipuri de fraude se reproduc dac i numai dac sistemul nu conine procedurile care s semnaleze efectuarea de operaii neconsistente n raport cu criterii precis stabilite. n primul rnd, legile definesc situaiile n care o persoan nu are drept s ia un credit. Sunt date reguli extrem de precise n a defini un creditor ca fiind ru-platnic. Sistemul informatic dintr-o banc trebuie s includ proceduri prin care se verific statutul solicitantului i ncadrarea n categoria : - ru platnicilor; - creditorilor al cror plafon de creditare a fost atins; - creditorilor care mai pot solicita un credit, nu mai mare dect o valoare impus; - creditorilor care au dreptul s solicite credit cu valoare care se ncadreaz ntr-un interval definit de garanii, de cifre de afaceri i de istoricul lor n relaia cu banca.

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 operaional. Sistemul informatic bancar nu trebuie s valideze efectuarea unor operaii interzise prin acte normative, dintre care operaia de efectuare de pli ale ratelor unui credit cu banii obinui dintr-un alt credit. Auditorii sistemelor informatice bancare au deja inclus aceast operaie n lista operaiilor interzise, list folosit cu prioritate n testarea comportamentului unui sistem informatic bancar. Un sistem informatic de management financiar-contabil auditat devine credibil cnd echipa conchide n raportul de audit c sistemul rspunde tuturor cerinelor din specificaii, din legi i regulamente, iar securitatea operaiilor este asigurat, condiiile 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 auditrii toate componentele sistemului, intrrile i ieirile acestora. Numai prin coborrea auditului la nivelul detaliilor se vor obine informaiile necesare fundamentrii unei concluzii finalizate printr-o propoziie simpl, fr echivoc, de calificare a sistemului. Prin specificaii este creat o imagine, un sistem informatic virtual. Dac se adaug noi cerine desprinse din legislaie, din experiena curent, dac se produce o ierarhizare a prioritilor privind operaii permise, respectiv, operaii interzise, se creeaz proiecia unui sistem informatic virtual i ideal. Toate comparaiile 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. Esena auditului nu este controlul. Auditorii sunt persoane cu nalt calificare care nu se substituie controlorilor de calitate, controlorilor care stabilesc existena fizic a unui produs, exprimnd-o prin cantitate, dup msurare. 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 activiti clare, nici una dintre acestea nefiind de control.

Specificaiile reprezint un text structurat. Sistemul informatic reprezint o structur. Auditorul are menirea de a stabili existena corespondenei dintre componentele textului structurat i, respectiv componentele sistemului, identificnd concordan perfect, concordan parial, concordan redus sau absena concordanei. Componentele din structura textului care alctuiesc specificaiile includ: - nivelul managementului; - ciclul de elaborarea a sistemului informatic de gestiune financiarcontabil; - securitatea sistemului prin: precizarea responsabilitilor, separarea funciilor incompatibile, ierarhizarea accesului la resursele sistemului, gestiunea copiilor; - nivelul operaional n modul de lucru, prin procedurile pe care operatorii le efectueaz n ceea ce privete: introducerea de date, manipularea de documente, manipularea dischetelor cu date intermediare, nregistrarea evenimentelor, asistena tehnic; - nivelul aplicaiilor presupune parcurgerea de ctre auditor a tuturor etapelor astfel nct s se dezvolte convingerea c sistemul informatic de gestiune contabil este chiar construcia n care utilizatorul trebuie s aib mare ncredere; se reia un ciclu complet de prelucrare, de la iniierea procesului, pregtirea datelor, procesarea acestora i obinerea rezultatelor: fiierele, bazele de date sufer o serie de modificri 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 soluionate elementele fundamentale ale accesului la resursele sistemului informatic - proceduri, baze de date, modul n care se dezvolt i alte canale de transfer a informaiilor i cum se asigur robusteea reelei de calculatoare. Echipa de audit colecteaz date proprii, dar preia i rezultate oferite de sistemul informatic de gestiune financiar-contabil. Pe msur ce se traverseaz etapele ciclului de dezvoltare, echipa de realizare a sistemului informator elaboreaz pri ale documentaiei care nsoete sistemul. Echipa de audit analizeaz i aceast documentaie pentru a urmri traseul parcurs de la specificaii, pn la obinerea produsului finit n form livrabil ctre organizaii.

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 specificaiile, cu documentaia. Se calculeaz o serie de indicatori. n final se spune c sistemul este sau nu credibil, asigur sau nu calitatea prelucrrilor, c exist sau nu garania ca sistemul informatic s dea satisfacie clientului n raport cu un obiectiv stabilit. Auditul informatic este un demers deosebit de complex, motiv pentru care trebuie aezat pe un fundament solid. Obiectivul fundamental al activitii de auditare informatic este stabilirea gradului de credibilitate a sistemului informatic de management. Fluxurile de informaii specifice oricrui sistem informatic trebuie s asigure integritatea informaiilor organizaiei, completitudinea prelucrrilor, corectitudinea rezultatelor i mai ales accesibilitatea beneficiarului la informaia ateptat, obinnd n acest fel un nivel maxim al satisfacerii cerinelor 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 urmrindu-se modul n care noul sistem n care se implementeaz este mai eficient, este nsoit de economisire de resurse; - audit extern care include proceduri prin care se evideniaz comportamentul sistemului informatic, prin testri cu ajutorul crora se evideniaz ct de stabile, ct de fiabile, mentenabile sunt procedurile de control care intr n componena sistemului i care implementez toate cerinele exprese incluse n specificaii, n legi, n regulamnete i care restricioneaz prin blocare orice tentativ de execuie a operaiilor interzise. Pentru a dezvolta un proces de auditare a sistemului informatic de management sunt parcuri urmtorii pai: - planificarea proceselor de auditare avnd la baz o serie de elemente prin care se stabilete anvergura prin cunoaterea 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 influenele negative care se manifest asupra componentelor sistemului informatic ce vor fi auditate, pe msur ce se activeaz procedurile de control;

- elaborarea programului de audit ce include: definirea scopului, stabilirea obiectivelor, efectuarea planificrii, derularea propriu-zis, ntocmirea de rapoarte; - culegerea de date ce evideniaz modul cum se execut prelucrrile, care sunt neconcordanele ntre specificaii i produsul real; datele apar sub forme extrem de variate, de la liste, fiiere de tranzacii, liste de erori, chestionare care vizeaz obinerea unor rspunsuri cu cheie, diagrame, texte surs, seturi de date de text, documentaia 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 adugate detalii asupra modului cum s-a derulat procesul de auditare, gradul de transparen asigurat. ntruct auditorii de sisteme informatice pentru management sunt specialiti de nalt calificare n domeniu, enumer n raport totalitatea diferenelor care au fost ntlnite, ntre sistemul real i sistemul virtual-ideal; nu sunt incluse soluii, dei auditorii prin competena lor deosebit au capacitatea de a le oferi; auditul sistemelor informatice pentru manangement consemneaz numai diferenele; caracterul sistematic al procesului de auditare ofer o grupare ascendent n raport cu profunzimea efectelor de antrenare, a diferenelor; n cazul n care sunt identificate erori, toate erorile sunt tratate distinct i contribuia lor n diminuarea nivelului de credibilitate a sistemului informatic pentru management este amplificat prin utilizarea de coeficieni de importan cunoscui att de auditori, ct mai ales de cei care au dezvoltat sistemul informatic. Activitatea de audit pentru sisteme informatice se bazeaz pe agregarea unor indicatori i pe obinerea de valori care s fundamenteze apartenena sistemului informatic la clasa de sisteme credibile n care se garanteaz calitatea soluiilor ateptate de beneficiar sau, din contr, sistemul nu e credibil i trebuie s fie supus unor corecii i din nou unui proces de auditare. Dac tehnica de auditare i procedurile de msurare a diferenelor sunt clar definite, procesul de audit pentru sisteme informatice este reproductibil n proporie de 100%. Asociaiile care au preocupri n a elabora tehnici i metode de auditare sau de a certifica speculaii n auditul sistemelor informatice pentru

management i-au concentrat atenia asupra algoritmizrii proceselor de auditare, n viitor trebuind s defineasc metrici pentru a asigura caracter obiectiv auditului, prin transferul din zona interpretrilor, n zona certitudinilor. Particularitile auditrii sistemelor informatice, comparative cu alte produse, i necesitatea unei pregtiri corespunztoare a auditorilor, necesit existena unor standarde corespunztoare acestui. n anexa 9 sunt prezentate oganizaii specializate care elaboreaz standarde destinate auditrii sistemelor informatice, recomandri i ghiduri necesare activittii de audit pentru sistemele informatice. Obiectivele acestor standarde sunt de a informa: - auditorii de sisteme informatice privind nivelul minim de pregtire; - managerii i alte personae interesate privind ateptrile unei activiti de auditare. Standardele definesc cerinele obligatorii pentru desfurarea auditului i pentru modul de ntocmire a rapoartelor de audit.

5. CONSTRUIREA DE LISTE
O list este o construcie liniar, format din elemente dispuse unul dup altul. O list presupune parcurgerea secvenial, de la primul element, elementul din capul listei, pn la ultimul element. Construirea unei liste se realizeaz pentru a obine: - enumerarea elementelor unei colectiviti ntr-o ordine stabilit, ca de exemplu, n ordinea sosirii ntr-un fir de ateptare, n ordinea servirii, n ordinea importanei sau ntr-o ordine a preferinelor; - stabilirea etapelor unui proces, n ordinea derulrii lor; - setul de documente necesar pentru a obine calitatea de eligibilitate n vederea acordrii unor fonduri pe baz de proiect; - o ierarhizare a elementelor unei colectiviti n funcie de un criteriu de performan stabilit i acceptat de participani; - un inventar al componentelor care alctuiesc un subansamblu sau un produs finit; se specific denumirea reperelor i numrul de repere de acelai fel care intr n alctuirea subansamblului; - un ir de valori care corespund unor momente de timp; irul include elemente omogene, care se supun acelorai prelucrri. n procesul de auditare, rigurozitatea i profesionalismul impun elaborarea de liste complete, structurate strict pe importan sau pe ordinea de execuie. Planul de auditare se constituie ca list de activiti care trebuie executate. Derularea activitii n sine este descris ca o list a activitilor. 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 numr, date de tehnicile i standardele de auditare, Et1, Et2, ..., Ets. Fiecrei etape Eti i corespunde o component n lista de baz a auditului sistemului informatic, avnd asociat un text Ti care indic obiectivul etapei, inputurile etapei i outputurile acesteia, aa cum se arat n figura 5.1.

E1

Et2

Eti

Ets

T1

T2

Ti

Ts

Figura 5.1. Etapele ciclului de auditare a sistemului informatic

La rndul lor, etapele sunt detaliate prin construirea unor liste de activiti. Asfel etapei Eti i se asociaz o list de activiti Ai format din elementele ai1 ai2 ... aiNi. Fiecare element este concretizat printr-un text Fij care conine detalii privind modul cum se realizeaz fiecare dintre activitile corespunztoare etapei Ei, figura 5.2.

Ei
Ti

Ai1 Ai1

Tij Tij Tij

Ai1
AiNi

TiN i

Figura 5.2. Lista de activiti Ai a etapei Eti.

Pn n acest stadiu de detaliere, auditrii i corespunde o agregare de liste simple, pe dou niveluri, obinndu-se o list de liste. Este vorba de lista etapelor care conine liste de activiti. Dac detalierea este aprofundat, fiecrei activiti 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 ct nivelul k este mai mare, cu att rigurozitatea demersului este mai ridicat. Faptul c fiecrei activiti 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: existena unui manager cu experien i cu reale caliti n domeniul lucrului cu oamenii, pentru a crea cadrul adecvat activitilor de audit, pentru a menine nivelul de exigen la cote ridicate, fr a face rabat de la sarcini i, mai ales, pentru ncadrarea n termene i limite de calitate; stabilirea unor criterii riguroase de selecie a membrilor echipei; auditul unui sistem informatic este un proiect; ca orice proiect pentru care exist un management, o atribuie a managerului este formarea echipei; n cazul unor structuri birocratice, constituite pe criterii n cadrul crora performana i coeziunea nu sunt prioritare, este dificil s se deruleze un proces de audit de sistem informatic cu eficien; restriciile auditului nu permit rabat, iar orice neconcordan n funcionarea echipei, n special n planul comunicrii i n planul compensrilor n vederea echilibrrii sarcinilor, conduce la dereglaje, mai ales n ce privete termenele asociate fiecrei etape a auditului; arta managerului const n a-i cunoate pe oameni, a ti ce putere de munc are fiecare, ce caliti, ct de eficient este; poziionarea unei persoane din echip, din punct de vedere al sarcinilor, aparine managerului de proiect de audit sistem informatic; o aceeai persoan pus la un loc cu sarcini pe care le ndeplinete, este omul potrivit, la locul potrivit, cum, desigur, prin plasarea la un loc de munc neadecvat calitilor i pregtirii, 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 formulrii de soluii, al treilea moment este activitatea propriu-zis, pentru a transpune soluiile n practic, iar ultimul moment, al patrulea, corespunde

evalurii rezultatului muncii echipei; este important ca, la definirea problemei i la elaborarea de soluii, membrii echipei s comunice; prerile, dezbaterile, sunt eseniale n a obine cea mai bun definire a problemei, pentru a obine cea mai bun soluie; 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 abordri pariale avnd drept consecine revenirea la unele etape trecute i modificarea costurilor legate de reluarea unor activiti; disciplina impus de managerul proiectului de audit sistem informatic vizeaz dialogul deschis n timpul definirii problemei i prezentrii de soluii i, respectiv, la alegerea soluiei de auditare efective; disciplina trebuie astfel dirijat, nct, dup luarea unei decizii, nici unul dintre participani s nu mai discute despre o soluie 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; aa-ziii experi n a da soluii, prin regulile impuse de managerul de proiect, aveau dreptul s le fac cunoscute; din lips de idei, evident, se ascund n spatele unor ipotetice soluii de sertar, inexistente n realitate, producnd 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 soluii sunt rediscutabile la nivelul echipei, etapa de alegere a soluiei se prelungete; mai dificil este atunci cnd etapa de alegere a soluiei este reluat dup ce au fost parcurse deja alte etape ale procesului de auditare; n acest caz, se manifest disfuncionaliti chiar la nivelul managementului de proiect de auditare, iar pn la compromiterea procesului de auditare este numai un pas; elaborarea de rapoarte n timp real; este cunoscut tentaia de a scrie rapoarte dup derularea fazelor; programatorii elaboreaz schemele logice sau alte tipuri de diagrame numai dac acest lucru este cerut imperios, dei standardele impun acest lucru; elaborarea documentaiei se face mult mai trziu, ceea ce explic numeroasele lacune, aspectele extrem de ermetice pe care designerii le includ, creznd c toat lumea tie despre sistemul informatic tot ceea ce tiu i ei; elaborarea rapoartelor n timp real nseamn, n primul rnd, efectuarea unor nregistrri ale constatrilor la cald, a ceea ce s-a vzut n cadrul realizrii fiecrei activiti pe care auditorul o bifeaz n lista primit; trebuie s existe o ordine n aceste notie

pentru a reconstitui paii, pentru a opera pe seturile de date n vederea obinerii, n final, a unor rezultate coerente; existena unei bune comunicri ntre membrii echipei care realizeaz aceleai activiti conduce la construirea de structuri de tabele compatibile, la abordri uniforme, care, n final, dau unitate raportului de auditare; mai mult, pentru a obine date comparabile, membrii echipei trebuie s comunice cu privire la procedurile pe care le adopt i s rmn constani 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 rzboi 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; obinerea calitii de auditor de sisteme informatice presupune obinerea de calificative de trecere la o serie de examene; nseamn c auditorul cunoate standardele i metodele de auditare; managerul de proiect fixeaz sau, ntrun context mai democratic, supune ateniei i apoi adoptrii cele dou instrumente de lucru; odat stabilite, se trece la punerea n micare a ntregului proces de auditare a sistemului informatic; auditarea este asemenea vizionrii cu specialiti i cu critici a unui spectacol, naintea premierei de a doua zi; spectacolul e gata; el este vzut de specialiti; modificri nu se mai fac de pe o zi pe alta; exist ns o tensiune specific, tensiune care precede momentul vizionrii, cu tendina de a face lucrurile ct mai bine, ntruct cei care vizioneaz spectacolul sunt deintorii efectului de ghilotin; tot n acelai mod trebuie privit i procesul de auditare; cnd 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 consecine benefice asupra produsului final; dei exist tehnici de dezvoltare software, standarde i instrumente, toate sunt puin folosite, iar produsul finit realizat are abateri suficient de mari fa de ceea ce s-a propus iniial, dac nu este prevzut din start i un proces de auditare; chestiunea auditrii trebuie precizat nc de la ncheierea contractului, ca o condiie necesar de acceptare a produsului de ctre beneficiari; echipa care elaboreaz sistemul informatic trebuie s lucreze n cunotiin de cauz, adic, din primul moment trebuie s tie c produsul sistemul informatic

va fi auditat; mai mult, trebuie s fie cunoscui termenii auditrii n detaliu; sistemul informatic nu se produce pentru a fi auditat, ci se produce pentru a satisface nite nevoi n plan informaional 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 acelai sistem informatic, una tiind de la nceput c sistemul realizat va fi auditat, iar cealalt aflnd c sistemul informatic produs va fi auditat dup ce l-a realizat n forma final, livrabil; dei echipele sunt la fel de performante, rapoartele de auditare vor semnala diferene importante, numai raportul primei echipe fiind cu certitudine favorabil. Toate aceste elemente creeaz un cadru favorabil nceperii activitii echipei de audit sisteme informatice. Construirea listelor este o activitate complex, deosebit de important. Listele trebuie s fie complete, s includ toate elementele unei colectiviti. Este adevrat c, dac lipsesc elemente, se adaug sau se insereaz. Sau dac sunt incluse i elemente ale altor colectiviti, acestea sunt terse pentru a obine liste complete. Listele trebuie s fie, de asemenea, corecte, adic ordinea de dispunere trebuie s corespund poziiei sau importanei elementului. Coninutul textului care descrie sau definete un element al listei trebuie s fie clar, concis, simplu, complet, s genereze aciuni n succesiune logic, cu intrri i ieiri specificate. Toate acestea trebuie s impun eliminarea din texte a acelor elemente generatoare de ambiguiti, de soluii multiple, transformnd n acest fel un act de execuie n act de decizie urmat de execuie n condiii de incertitudine. Aceste liste, planuri de activitate, pai ai unor proceduri, tabele cu caracteristici, nu sunt nite 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 numr de N elemente ale unei liste enumerative, 5-10% difer de forma iniial, prin comunicare ntregul eafodaj se adapteaz n aa fel nct elementele nou introduse s-i gseasc corespondent n celelalte liste. O astfel de abordare evideniaz caracterul dinamic, viu al procesului de auditare. Se produc ajustri din mers, toate avnd menirea de a mbunti 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

c auditarea e un eec ireversibil. Listele trebuie s conin elemente disjuncte pentru a reduce ct mai mult posibil suprapunerile care sunt generatoare de confuzii i contradicii. n medicin exist ghiduri care concentreaz experiena pozitiv, oferind dezvoltri de proceduri pas cu pas pe care trebuie s le urmreasc un medic n ambulatoriu. n acelai fel trebuie procedat i pentru audit. Existena standardelor i a tehnicilor de auditare stau la baza construirii de liste. Este important ca listele s fie astfel elaborate nct s nu lase loc interpretrilor. Acumularea experienei permite gestionarea metodelor i standardelor de auditare. ntruct rezultatul auditrii este un produs oficial cu care se demonstreaz transferul de credibilitate, toate elementele trebuie s respecte strict standardele i tehnicile de auditare, ntruct, n caz de for major, se face referire, rnd pe rnd, la articolele dup care au fost executate activitile de auditare. Nu se execut nici o activitate dac nu figureaz n procedurile standard de auditare. Dac se execut evaluri, mai nti sunt culese date i se fac prelucrri 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 lng cele obligatorii se execut i noile proceduri. La rezultatele obligatorii se adaug noi rezultate, care vin s ntreasc rezultatele obinute prin proceduri oficiale. n listele enumerate se face distincie ntre tot ceea ce este obligatoriu i pentru care exist proceduri rigide i tot ceea ce este suplimentar. Nu este vorba de opionalitate, ci de prelucrri necesare, dar neobligatorii din punctul de vedere al beneficiarului raportului de auditare. Aceti pai suplimentari sunt obligatorii numai pentru auditori, ntruct sunt n sprijinul procesului de auditare. Exist prototipuri de sisteme informatice crora li s-au definit entiti distincte. Experiena acumulat a condus la elaborarea de liste n format extrem de cuprinztor. 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 adaptrii listelor vizeaz elemente specifice customizrii. Pornind de la un sistem informatic de baz foarte general, particularizarea ia n considerare outputurile sistemului care se dorete a fi implementat. Din aproape n aproape, folosind matricile de coresponden ale sistemului derivat, prin reutilizare de componente,

pornind de la experiena acumulat, se preiau din listele generale acele elemente care sunt specifice sistemului informatic ce face obiectul auditrii. Aceste liste permit efectuarea unui audit total, care include, pe lng 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 conine suficiente detalii tehnice, se constituie n specificaiile de baz sau macrospecificaiile sistemului informatic, figura 5.3. Macrospecificaiile sunt materia prim a construirii listelor enumerative, de derulare, de prioriti, de caracteristici i de evaluare ale sistemului informatic.

Macrospecificaii nivel 0

nivel 1

Specificaii tehnice 1

Specificaii tehnice 2

Specificaii tehnice k

nivel w

M1

M2

Mw

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

Listele enumerative conin, dispuse unele dup altele, componente omogene, precum numele modulelor, numele fiierelor, numele entitilor, numele parametrilor, codurile asociate mesajelor, numele asociate

rapoartelor, parole de acces i rezultate ale evalurilor. Listele enumerative se construiesc pe msur ce se proiecteaz sistemul informatic i se actualizeaz pe msur ce se deruleaz etapele de realizare ale sistemului informatic. Dinamica de coninut a listelor enumerative d o imagine suficient de clar n legtur cu echipa de designeri, privind experiena i, mai ales, gradul de cuprindere i de detaliere de care aceasta a dat dovad. Listele de derulare includ etape, activiti, operaii care trebuie parcurse ntr-o anumit ordine pentru a atinge un anumit obiectiv. La fel ca n cazul gamei de operaii, sunt specificate precedenele i, mai ales, restriciile de ncepere, de continuare i de ncheiere. Listele de derulare se dovedesc a fi corect elaborate cnd, pe msur ce se execut etape ale ciclului de dezvoltare a sistemului informatic, nu sunt necesare interschimburi de poziie i nici inserri de noi elemente n liste. Listele de derulare concentreaz mult experien i sunt elemente de start n definirea de proceduri standard, asemntoare celor din ghidurile de medicin pentru primul ajutor, care trebuie respectate cu strictee pentru ca pacientul s supravieuiasc. Listele de prioriti reprezint o form concret de manifestare a viziunii managerului de proiect. Prioritile vizeaz raportul dintre calitate i cantitate, modaliti de elaborare a criteriilor de selecie a membrilor echipei de dezvoltare a sistemului informatic i stabilirea poziiei pe care o are managementul calitii sistemului informatic. Prioritile definite au caracter obligatoriu de aplicabilitate. Fluctuaiile n timp sau pe compartimente n aplicarea prioritilor au drept consecin determinat creterea 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 eseniale i pe care le urmrete pe toat durata procesului de dezvoltare a sistemului informatic. Listele de caracteristici in seama de destinaia sistemului informatic. Orientarea sistemului informatic spre cerinele utilizatorului conduce la includerea cu prioritate a caracteristicilor care vizeaz obinerea unui singur nivel maxim de satisfacie la nivelul beneficiarului, pe msur 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, crete riscul de a obine un sistem informatic pentru un beneficiar ipotetic,

altul dect cel care pltete aceast investiie, cu toate consecinele care vizeaz efectuarea de corecii sau reluarea unor etape ale ciclului de elaborare, pe cheltuiala elaboratorului. Listele de evaluare prezint importan att n procesul de elaborare, ct i n procesul de auditare, ntruct creeaz premisele derulrii mai nti a procesului de autoevaluare i dup aceea a procesului de evaluare. n condiii normale nu trebuie s existe diferene semnificative ntre autoevaluarea i, respectiv, evaluarea sistemului informatic sau a componentelor acestuia. Transparena construirii i utilizrii listelor are menirea de a crea unitate n echipa de auditare a sistemului informatic. Cunoaterea complet a listelor este fundamental pentru definirea sarcinilor membrilor echipei de auditare. n dreptul fiecrui element din list va fi trecut numele unui membru din echipa de auditare. Se creeaz un nivel ridicat al responsabilizrii, ntruct att calitatea, ct 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 R2

Raport detaliu Rv

List de rapoarte de detaliu Raport de sintez

Figura 5.4. Sinteza rapoartelor de detaliu pe baz de list

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 obine indicatori agregai, care privesc un ansamblu printr-o descriere sintetic. Construirea listelor de liste creeaz cadrul pe care se construiesc din aproape n aproape rapoartele, aa 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

Includerea de rapoarte pe niveluri cresctoare de agregare conduce la completarea documentaiei din aproape, n aproape figura 5.6.

Raport Rk1

Raport Rk2

Raport Rkv

Raport Rk-1, 1

Raport Rk-1, 2

Raport Rk-2

Figura 5.6. Rapoartele de auditare, ca informaii utile ale listelor de liste

Procesul de auditare se definete ca mod de traversare a listelor de liste prin completarea cu informaii specifice rapoartelor. Procedurile de agregare sunt standard. Esenial este ca baza privind procesul de auditare s fie solid, bazat pe msurtori i pe analize foarte riguroase. Construirea listelor reprezint latura esenial a procesului de auditare planificare. Fr un plan bine elaborat, articulat i fr 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.

6. AUDITUL SPECIFICAIILOR
Specificaiile sistemului informatic, asemenea unei case, constituie temelia sistemului. De aceea auditul sistemului trebuie s nceap cu auditul specificaiilor. Specificaiile au la baz surse precum: - legi i acte guvernamentale; - norme de aplicare a unor acte oficiale; - documentaii tehnice privind echipamentele de producie i auxiliare; - documentele de creare i funcionare a companiei; - monografii, referate i prezentri; - documente contabile i de patrimoniu; - documente programatice: strategii i planuri pe termene diferite; - rapoarte privind dinamica evoluiei; - rapoarte privind conexiunile cu mediul de afaceri; - documentaii privind publicitatea i definirea imaginii de pia; - documentaia privind fora de munc; - documentaia privind activitile de cercetare, studiile de pia, activitile sociale. Auditul are menirea de a defini gradul de cuprindere al documentelor necesare dezvoltrii unor specificaii 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 aparinnd fiecrui tip; - listele grupurilor de documente aparinnd fiecrei clase: - tabelele de descriere cantitativ a elementelor care alctuiesc grupurile; pentru fiecare grup se definete un tabel. Fiecare list conine elemente sub form de texte structurate n triplete < xi , yi , zi > , i = 1, 2, ...ne, unde: xi - denumirea tipului, clasei sau grupului de pe poziia i a listei; yi - variabil egal cu 1 n cazul n care n dezvoltarea specificaiei au fost incluse elementele ca tipul, clasa, grupul i; n caz contrar se atribuie valoarea blanc;

zi - variabil egal cu 1 n cazul n care n dezvoltarea specificaiei elementele specificate prin xi nu au fost folosite; n caz contrar se atribuie valoarea blanc; ne numrul elementelor din list. Forma concret de existen a listei este dat n tabelul 6.1. Structura listei de descriere tip, clas sau grup
Denumire element xi x1 x2 ... xne Utilizat yi y1 y2 ... yne Tabelul 6.1 Neutilizat zi z1 z2 ... zne

Dup completare, se calculeaz un indicator al utilizrii surselor Ius, dat de relaia:

I us = y i Pi ,
i =1

ne

unde Pi reprezint coeficienii de importan acordai de auditori dup o metodologie anume, care s asigure reprezentativitatea. Nivelurile indicatorului Ius plaseaz activitatea de documentare pentru realizarea specificaiilor ca fiind foarte bun, bun, satisfctoare sau nesatisfctoare. Astfel:
(0,92; 1] documentarea este considerat foarte bun (0,78; 0,92]documentarea este considerat bun I us (0,62; 0,78]documentarea este satisfctoare (0; 0,62] documentarea este considerat nesatisfctoare

Specificaiile se elaboreaz pornind de la obiectivul O pentru care se construiete sistemul informatic. Nu trebuie confundat obiectivul cu mijloacele de atingere a lui. Dac apar astfel de confuzii, se produce o deplasare de atenie spre o alt direcie, iar investiiile nu se dovedesc eficiente pentru companie. Obiectivul O genereaz subobiective. Asemenea programrii dinamice, urmrirea 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 numrul de subobiective. Subobiectivele vizeaz o localizare fie pe componentele companiei, fie pe funciile pe care compania le realizeaz.

Astfel, dac la nivelul companiei exist submulimile SS1, SS2, ..., SSNSS, unde NSS reprezint numrul de subsisteme care fizic sunt secii, ateliere, depozite, antiere, puncte complexe de lucru, n procesul de auditare se verific: - diferenele dintre numrul de subsisteme NSS i numrul 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 cnd se definesc structurile; numai n procesul de optimizare a sistemului informatic se procedeaz la gestionarea redundanei, n sensul reducerii pn la limita rezonabil; - concordana dintre nivelul pe care l are subsistemul SSi i coninutul subobiectivului SOi. n realitate, trebuie s existe concordan ntre subobiective i componena structural a companiei, aa cum se prezint n figura 6.1.
COMPANIA

SS1

SS2

SS3

SSNSS

SO1

SO2

SO3

SONSO

OBIECTIVUL O Figura 6.1. Concordana dintre stuctur i subobiective

n cazul n care sistemul informatic este orientat pe funcii ale companiei, ntre subobiective i funciile F1, F2 ..., FNFUN, trebuie s existe o perfect concordan, figura 6.2. COMPANIA

F1

F2

F3

FNFUN

SO1

SO2

SO3

SONSO

OBIECTIVUL O
Figura 6.2. Concordana dintre stuctur i subobiective

Sunt situaii n care, din motive de neclaritate, se combin funciile cu structurile companiei, rezultnd modaliti neomogene de agregare. Pentru a evita astfel de abordri, se construiete matricea MFS de coresponden funcii, subsisteme, avnd NFUN linii i NSS coloane, tabelul 6.2, iar elementul mfsij arat c ntre funcia Fi i subsistemul SSj exist o legtur dac are valoare 1. n cazul n care se atribuie acestui element valoarea 0, rezult c nu exist o legtur direct ntre funcia Fi i subsistemul SSj. Legtura funcii/subsisteme
Tabelul 6.2 Subsisteme Funcii F1 F2 . . . SS1 SS2 ... SSj ... SSNS

Subsisteme Funcii Fi . . . FNFUN SS1 SS2 ... SSj mfsij ... SSNS

Se consider eroare situaia n care o linie din matrice sau o coloan are toate elementele nule. Situaia cea mai favorabil este cea n care unei funcii Fi i corespunde doar un subsistem SSj. nseamn c n companie fiecare subsistem realizeaz o singur funcie, sarcinile fiind foarte clar distribuite. Confuziile apar atunci cnd mai multe subsisteme au ca sarcin activiti corespunztoare aceleiai funcii. Confuzii apar i atunci cnd un subsistem realizeaz mai multe funcii i unele dintre funcii sunt distribuite mai multor subsisteme. n tabelul 6.3 este dat un exemplu n care subsistemul SS3 realizeaz activitile funciilor F1 i F3 , iar funcia F2 este distribuit subsistemelor SS1 i SS2, ceea ce complic procesul de auditare i de regsire a datelor din liste atunci cnd nu se menine un grad de redundan, pentru a plasa aceleai documente referitoare la o aceeai activitate de funcie pentru toate sistemele n care aceasta este gestionat. Legturi multiple funcii/subsisteme
Tabelul 6.3 Subsistem Funcii F1 F2 F3 SS1 0 1 0 SS2 0 1 0 SS3 1 0 1

Printr-o reproiectare a legturilor subsistem funcii se amelioreaz distribuirea, nc nainte de a dezvolta sistemul informatic. Analistul are numai menirea de a consemna distribuirea difuz a sarcinilor pentru subsisteme. Se definete un algoritm pentru a analiza caracterul difuz sau bine definit al legturilor funcii subsisteme. Se construiete un indicator IDIF al difuziunii, care este 0 dac matricea MSF are toate elementele egale cu 1 i, respectiv, este egal cu 1 dac fiecrei funcii Fi i corespunde unul i

numai unul dintre subsisteme, respectiv subsistemul SSj. Se consider mulimea MFSnm a matricelor booleene cu cel puin un element nenul pe o linie, pentru care este definit inegalitatea dubl
n m m n + a ij n m + m n 2 a ij i =1 j =1 j =1 i =1

De la aceast inegalitate se pornete pentru a construi indicatorul IDIF. Auditul specificaiilor presupune existena unor definiri riguroase, ortogonale i coerente. Dup clarificarea aspectelor calitative i cantitative legate de definirea obiectivului, subobiectivelor i dup stabilirea modului de grupare/regsire a informaiei n sistem, dup structur sau dup funcii, se trece la analiza outputurilor, a indicatorilor i a inputurilor, figura 6.3. OBIECTIV

Subobiectiv SS INj1 INj2 ISSj1 IjNINI ISSj1 ... ISSj1 NIND

Indicatori

OUj1 OUj2 OUSjNIND

Figura 6.3. Derivarea indicatorilor din subobiective

Fiecare indicator reprezint un mod de reflectare a factorilor care acioneaz n cadrul fiecrui subsistem. Dac se consider mulimea factorilor FACT j1 FACT j2 ... FACT jNFj care influeneaz activitatea subsistemului SSj, procesul de auditare realizeaz: analiza listei factorilor pentru a vedea dac este o list complet; factorii sunt strict dependeni de sistemul echipamentelor, de sistemul energetic, de sistemul materiilor prime i de sistemul forei de munc; aceste sisteme sunt distribuite prin componente i interdependene n subsistemul

SSj identificat; fiecare dintre sistemele de baz enumerate se caracterizeaz prin factori de evoluie crora li se asociaz variabile; completitudinea listei factorilor este analizat cu luarea n consideraie a listelor de variabile i de factori ale celor patru sisteme; dac lista iniial ale factorilor, rezultat din specificaii, are NFj componente, iar prin procesul de analiz rezult c trebuie eliminate DNFj componente i trebuie adugate ANFj, se calculeaz indicatorul gradul de definire a listei factorilor GDFj.
GDF j = NF j NF j + DNF j + ANF j

care arat ct de diferit este lista iniial definit n specificaii fa de lista factorilor care trebuie s stea la baza dezvoltrii sistemului informatic. i n acest caz, dac GDFj (0,92; 1], nseamn c specificaiile conin o list complet de factori de influen a evoluiei subsistemului SSj. Lista de factori construit n procesul de analiz a specificaiilor, avnd numrul de componente NFAj = NFj + ANFj - DNFj, este utilizat n a identifica diferenele pe care le genereaz noncalitatea unor specificaii. Folosind coninutul specificaiilor existente, se analizeaz modul de utilizare a imputurilor n vederea obinerii outputurilor cu ajutorul indicatorilor. Auditorii construiesc tabele indicatori/outputuri, indicatori/inputuri i, respectiv, output-uri/inpu-turi, aa cum se arat n tabelele 6.4, 6.5 i 6.6. Utilizarea inputurilor n indicatori
Tabelul 6.4 Inputuri Indicatori ISSj1 ISSj2 . . . ISSji . . . ISSjNIND INj1 INj2 ... INjk ... INjNINI

j W jk

Utilizarea outputurilor n indicatori

Tabelul 6.5 Outputuri Indicatori ISSj1 ISSj2 . . . ISSjk . . . ISSjNIND OUj1 OUj2 ... OUji ... OUjNINO

j q jk

Utilizarea inputurilor pentru obinerea outputurilor

Tabelul 6.6 Inputuri Outputuri OUj1 OUj2 . . . OUji . . . OUjNINO INj1 INj2 ... INjk ... INjNINI

j r jk

Pentru construirea tabelelor se iau n considerare variabilele:

NINIj numrul de variabile de intrare ale subsistemului SSj; NINOj numrul de variabile rezultative ale subsistemului SSj; j wik element cu valoare 1, dac indicatorul ISSji utilizeaz variabila de
intrare INkj definit pentru subsistemul SSj;

j qik

element din matricea output/indicatori pentru subsistemul SSj, care are valoarea 1 dac indicatorul ISSjk este utilizat pentru a se obine outputul OUji; element din matricea output/input-uri, care are valoarea 1 dac variabila INjk particip la obinerea variabilei rezultative OUji.

rikj

n cazul n care ntre variabile sau ntre indicatori nu exist legtur, elementele matricelor au valoarea zero. Dup completarea celor trei seturi de matrice pentru toate subsistemele companiei,se trece la pasul urmtor care const n : analiza fiecrui set de trei tabele pentru a se vedea reprezentativitatea la nivelul fiecrui 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 evideniaz definiri multiple de indicatori, indicatori redundani, indicatori neconsisteni; o analiz atent a liniilor tabelelor evideniaz modul concret n care variabilele contribuie la definirea fiecrui indicator; analiza coloanelor evideniaz frecvena cu care apare un element n construirea altor elemente; n cazul n care sunt definite linii i coloane ortogonale, sarcina procesului de auditare este uurat, ceea ce dovedete 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 Inputuri Indicatori ISS71 ISS72 ISS73 IN71 1 0 0 IN72 1 0 0 IN73 0 1 0 IN74 0 0 1 IN75 0 0 1

Utilizarea outputurilor n indicatori

Tabelul 6.8 Inputuri Indicatori OU71 OU72 OU73 ISS71 1 0 0 ISS72 0 0 1 ISSj73 0 1 0

Utilizarea inputurilor pentru obinerea outputurilor

Tabelul 6.9 Inputuri Indicatori OU71 OU72 OU73 IN71 1 0 0 IN72 1 0 0 IN73 0 0 1 IN74 0 1 0 IN75 0 1 0

Pentru acest exemplu analiza evideniaz c indicatorii sunt bine definii, iar legtura 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 luai spre analiz indicatorii comuni subsistemelor pentru a se vedea dac inputurile, respectiv output-urile, au acelai nivel de omogenitate; aceiai indicatori au aceleai formule de calcul, iar inputurile se exprim pentru toate subsistemele cu aceleai uniti de msur; indicatorii care difer de la un subsistem la altul sunt analizai pentru a vedea dac diferenele 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 evidenieze 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 ndeprtate ca poziie de subsistemul SSj sau subsisteme precedente subsistemului SSj-1, figura 6.10.

SSj-1

SSj

Figura 6.10. Transformarea outputurilor n inputuri

Sunt situaii n care un output devine input multiplu, figura 6.11;

SSj-2

SSj-1

SSj

SSj+1

Figura 6.11. Transformarea unui output n input multiplu

se produc pe durata analizei gruprii 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 situaia n care un output al subsistemului SSj-1 devine input pentru acelai subsistem; sunt i alte definiri a cror interpretare conduce la neconcordane n interiorul specificaiilor; regulile, care se definesc pentru interpretarea tabelelor i diagramelor construite de auditori pe baza textului specificaiei, reprezint modul specific de auditare al fiecrei echipe de auditori. Toate comparaiile specificaiilor cu ceea ce trebuia s conin acestea, prin utilizarea listelor de factori actualizate, conduc la redactarea unui raport de auditare complet. n continuare, toate celelalte etape ale auditrii vizeaz produsul dezvoltat pe specificaiile existente. Referirile la necesarul impus de actualizarea specificaiilor sunt necesare pentru a explica riscurile obinerii unui sistem informatic pe o alt temelie dect cea pe care se cuvenea s se dezvolte o construcie diferit din punct de vedere al utilizatorului i al elaboratorului.

7. AUDITUL PROIECTULUI DE SISTEM INFORMATIC

Proiectul sistemului informatic este realizat pe baza specificaiilor. 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 rspund cerinelor companiei. Aceste produse au fost proiectate pentru funciile ntreprinderii. Se specializeaz persoane care s defineasc parametri pentru subsistemul de aprovizionare, pentru subsistemul de producie, 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 operaional. Metodele, tehnicile i instrumentele au menirea de a uura munca, de a sistematiza informaii, de a minimiza inconsistenele. Eforturile cele mai importante destinate definirii de entiti, gruprii acestora, realizarea modulelor, specificarea conexiunilor, aparin designerilor sistemului informatic. Pornind de la listele i tabelele rezultate din analiza specificaiilor 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 componena sistemului. Al doilea nivel, corespunde unei detalieri mai accentuate, n care se disting prile ce alctuiesc subsistemele i fluxurile care au fost definite. Al treilea nivel conine detalii de organizare a operaiilor i a operatorilor. Diagramele difer n funcie de modul n care este abordat soluionarea din punctul de vedere al tehnologiei abordate. Gruparea operanzilor i operatorilor prezint o importan special ntruct influeneaz definirile specifice implementrii algoritmilor de regsire a informaiei dup una sau mai multe chei. Al patrulea nivel conine reprezentri suficient de detaliate care se constituie n specificaii de programare.

Activitatea de auditare a proiectului trebuie s traverseze toate cele patru niveluri de detaliere. Se stabilete msura n care nivelul urmtor este rezultatul direct al detalierii elementelor definite n nivelul precedent. n cazul n care pe nivelul precedent sunt elemente nedetaliate pe nivelul urmtor sau detalii de pe nivelul curent nu au corespondent pe nivelul precedent, se semnaleaz ca element de contradicie n proiect. Dac specificaiile au un nivel de detaliere ridicat, proiectul sistemului informatic urmrete cu mai mare precizie fiecare detaliu din specificaii, crendu-se premisa unei abordri ct 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 rnd, variabila asociat unui factor este unic, pentru c factorul este unic. n al doilea rnd, un indicator are o singur expresie analitic. Dou expresii analitice aparin la doi indicatori diferii numai dac expresiile sunt diferite. n al treilea rnd, un indicator este evaluat o singur dat pentru un set de date. El nu va aprea spre a fi evaluat cu acelai set de date i ntr-o alt component a proiectului. n al patrulea rnd, pentru regruparea tuturor datelor opereaz un singur criteriu. Introducerea mai multor criterii de regrupare a datelor creeaz condiii favorabile creterii riscului n gestionare a redundanei n sistemul informatic care se dezvolt n etapele urmtoare. Criteriul colectivitii presupune existena unor colectiviti omogene. Datele se grupeaz pentru descrierea complet a elementelor din fiecare colectivitate. Criteriul evenimentelor prevede definirea de activiti, resurse, momente i durate, iar datele se grupeaz strict pentru a defini complet mulimile de evenimente. n al cincilea rnd, proiectul include componente care vizeaz operaii fundamentale precum iniializri, sortri, reutilri, concatenri, adugiri, calcule, extrageri, regsiri, modificri, afiri, actualizri, reorganizri etc. Experiena n designul sistemului permite gruparea indicatorilor IS11, IS12, ..., ISNSS,INNSS i a variabilelor pe o structur ierarhizat, astfel nct la baza arborescenei se afl indicatorii cu cel mai redus nivel de agregare, iar

la nivelul cel mai ridicat sunt indicatorii cei mai sintetici, profit, cifr de afaceri i rentabilitate, figura 7.1. 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

Modul n care se realizeaz regruparea indicatorilor este rezultatul analizei interdependenelor 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 cerine rezultate al designerului de sistem creaz baza de ncapsulare separat a variabilelor i ncapsulare indicatori sau nencapsulare a variabilelor cu indicatorii. n primul caz se obin dou mulimi diferite de componente omogene, rezultat al ncapsulrii. n cel de al doilea caz se obine o singur mulime n care componentele sunt rezultatul ncapsulrii de variabile i indicatori. Analistul proiectului are menirea de a stabili dac structura arborescent este complet, are numrul de niveluri corect obinut. Carenele structurii sunt: - interschimbul de niveluri, n sensul c un indicator agregat devine indicator simplu sau invers; - interschimbul pe acelai nivel, ceea ce antreneaz regruparea de variabile cu consecine directe asupra creterii numrului de variabile comune mai multor regrupri de date; - realizarea unor legturi incorecte ntre nivelul inferior i nivelul superior ale nodurilor arborescenei; n acest fel indicatorii agregai au ca inputuri indicatori simpli nenecesari sau pentru calculul indicatorilor agregai lipsesc indicatori simpli.

Se observ c n auditul proiectului sunt preluate numeroase elemente din specificaii. Elaboratorul sistemului informatic dispune de o echip de designeri de sistem care, prin modaliti eficiente de comunicare, dezvolt proiectul, verific de fiecare dat specificaiile cu cerinele reale ale utilizatorilor. n mod normal, ntre toate construciile existente n documentaie i ceea ce rezult n procesul de auditare, diferenele trebuie s fie nesemnificative. n realitate apar diferene care, dac nu semnificative, sunt diferene numeroase, genernd neconcordane, unele afectnd semnificativ utilizabilitatea sistemului informatic. Documentaia de auditare a proiectului de sistem informatic conine liste care permit agregarea de indicatori, conducnd n final la un singur indicator, care clasific proiectul ca fiind foarte bun, bun, satisfctor sau nesatisfctor. n faza de definire a proiectului apar o serie de detalii privind: - stabilirea domeniilor de variaie a variabilelor de intrare i domeniile variabilelor rezultative; - dimensiunile seturilor de date; - cheile de regsire a datelor; - funciile de prelucrare care se dispun pe o structur arborescent iniial; - 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 informaiilor referitoare la perioade trecute de timp. Se creeaz o imagine complet a produsului finit care, n final, va conine software, baze de date, echipamente i va fi conectat prin fluxuri de informaii spre puncte de lucru prin accesare condiionat. 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, restricionate 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

de lucru. Se are n vedere apropierea de locul n care utilizatorul i desfoar 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 dispoziia administratorului sistemului; acest tip de acces permite lucrul pe componente, schimbarea drepturilor de acces pentru toi ceilali utilizatori; administratorul este cel care realizeaz interfaa sistemului, inclusiv cu cei care asigur ntreinerea sa curent; - chei de acces la operaii de mare risc asupra bazei de date, precum operaiile nestandard, corespunztoare unor preluri accidentale, care presupun luarea unor decizii majore privind sistemul de producie, operaii financiare; - chei de acces pentru efectuarea unei singure operaii adugarea de informaie; ntruct fiecare utilizator este specializat, prin introducerea parolei se produce i asocierea operaiei pentru cmpul de prelucrat; de exemplu, parola unui vnztor atrage dup sine asocierea cu operaia de scdere din stoc a produselor vndute; - chei de acces consultare ntreaga colecie de informaii, 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 consultri n grup; - chei de acces pentru consultare parial a bazelor de date; corespund unei largi categorii de utilizatori; - chei de acces la informaii de interes general, privesc indicatori agregai ai companiei; - chei de acces personale care permit accesul strict la datele personale ale individului; fiecare salariat are o astfel de cheie. Accesul la informaia public este liber. Auditul parolelor stabilete msura 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 definete parola sa, se impune definirea unui alfabet propriu de construire a parolelor, astfel nct prin regulile definite s se asigure un nivel de securitate ridicat. Auditul sistemului de parole este important prin modul cum calific protecia sistemului informatic fa de operaiile accidentale. Este important ca fiecrui utilizator s-i fie analizat activitatea prin consemnarea: - numrului de operaii efectuate zilnic; - calitatea operrii de ctre utilizator; - numrul de incidente de prelucrare, difereniat pe tipuri.

Exist necesitatea ca proprietarul sistemului s asigure un nivel de concordan i o proporie adecvat ntre structura sistemului informatic i capacitile 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 ateptare, cu efecte negative asupra proceselor din companie. Faza de design a sistemului acord nivelul de modernitate a acestuia. Dac echipa de designeri stpnete tendinele moderne de analiz i proiectare, soluia oferit este, de asemenea, modern. n caz contrar, se obine o soluie 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 construiete matricea de corespondene dintre utilizatori i parole, tabelul 7.10. Corespondena utilizatori/parole
Tabelul 7.10 Parole Utilizatori UZ1 ... UZj ... UZNUZ CPR1 ... CPRi CPRNPR

UCji

Elementul UCji are valoarea 1 dac utilizatorii clasei UZ dispun de parole de clas CPRi. n caz contrar UCji = 0. Ideal este ca:
NUZ NUZ NPR UC ji = UC ji = 1 , i =1 j =1 j =1 i =1
NPR

adic unei clase de utilizatori s-i corespund o singur clas de parole. Se consider mulimea operaiilor care se efectueaz de ctre utilizatori, avnd elementele OU1, OU2, .., OUNOU. Aceste operaii sunt: - numai consultare; - ordonri de n-tuple de date; - extrageri spre afiare sau copiere seturi de n-tuple de date; - adugare de n-tuple; - adugare de n-tuple cu efecte directe unice asupra seturilor de baz; de exemplu, prin vnzarea unui produs este afectat numai stocul de

produse din depozit; adugarea articolului ce corespunde operaiei de vnzare are numai un efect direct asupra unui alt articol din setul de informaii destinat produselor finite; - adugarea de n-tuple cu efecte directe n cascad asupra unui ir de articole din setul de date de baz; de exemplu, adugarea unui n-tuplu de date ce corespunde modificrii sortimentului de produse care se realizeaz, afecteaz direct articolele din setul de date de baz privind aprovizionarea cu un numr de materiale, gradul de ncrcare a utilajelor, utilizarea forei 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 nsui. Aceste operaii sunt puse n coresponden cu clasele de parole, tabelul 7.10. Corespondena operaii/parole
Tabelul 7.10 Parole Operaii OU1 ... OUj ... OUNOU CPR1 ... CPRi CPRNPR

COji

Ca i n cazul matricei precedente, elementul COji are valoarea 1 dac pentru operaia OUj este atribuit parola CPRi i COji = 0 n caz contrar. n procesul de auditare a proiectului se urmrete msura n care designerii clarific problematica definirii de clase distincte i dezvolt atribuiri de resurse care nu genereaz ambiguiti. Noile tehnici de proiectare includ numeroase instrumente care din start i asist pe designeri i i orienteaz spre a asigura aceast proprietate atunci cnd 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, documentaia este laborioas i vizeaz n primul rnd laturile calitative ale soluiei adoptate. Elementele cantitative sunt un suport real pentru calitatea proiectului, ns, exist numeroase modaliti de a compensa absena lor n etapele urmtoare de dezvoltare a sistemului informatic. Direcia de dezvoltare o d calitatea arhitecturii definit prin proiect. Clase clar definite,

operaii de agregare a claselor dispuse ntr-o arborescen echilibrat, proceduri cu grad de generalitate ridicat, sunt numai cteva 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. Aplicnd aceleai principii, auditorii identific elemente lips, interschimbri de poziii, elemente suplimentare, obinnd matrice, liste i arbori proprii care difer mai mult sau mai puin de construciile designerilor sistemului informatic. Se impune construirea unui indicator care s reflecte gradul de asemnare dintre dou matrice. Se consider matricele:
1 2 3 A = 4 5 6 7 8 9

1 2 3 B = 4 5 6 7 8 9

Pentru matricele A i B, gradul de asemnare GA(A,B) trebuie s fie egal cu 1. Se consider matricele: 1 2 C = 3 4 , 5 6 D= 7 8

Pentru aceste matrice gradul de asemnare GA(C,D) = 0 Se consider matricele: 1 2 1 5 K = 3 4 i L = 3 4 n acest caz, gradul de asemnare trebuie s aparin intervalului (0;1).

Se construiete o matrice boolean: b11 b12 ... b1 j ... b1n b21 b21 ... b22 ... b2 n ........................................... BOO = bi1 b21 ... bij ... bin ........................................... b m1 bm 2 ... bmj ... bmn 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 asemnare a matricelor GA(X,Y) se definete prin relaia:

GA( X , Y ) =

b
i =1 j =1

ij

mn

n cazul n care numrul de linii i de coloane difer la matricele X i Y, gradul de asemnare se calculeaz astfel: - se consider matricele Xmn i Ysr ; - se calculeaz t = min{m, s} i u= min {n, r}; - se construiete matricea BOOtu prin comparare elementelor comune din matricele Xmn i Ysr ; - se calculez v = max{m, s} i w= max {n, r}; - se calculeaz:

GA( X mn , Ysr ) =

b
i =1 j =1

ij

vw

Forma extins revine n a nlocui variabilele t, u, v i w cu formele pe care acestea le au, adic:
min( m , s ) min( n , r )

GA( X mn , Ysr ) =

b
i =1 j =1

ij

max{m, s} max{n, r}

Dac se consider matricele:

1 2 1 2 38 A = 3 4 i B = 5 4 69 , 5 6

unde m = 3, n = 2, s = 2, r = 4, rezult t = 2, u = 2, v = 3 i w = 4. 1 0 BOO22 = 0 1 .

GA( A32 , B24 ) =

2 1 = 3* 4 6

n procesul de auditare este preferabil ca pentru matrice s se obin grade de asemnare ct mai apropiate de 1. Pentru toate aspectele supuse auditrii se construiesc tabele, matrice sau alte construcii, care sunt analizate prin prisma asemnrii cu definirile designerilor. Finalizarea procesului de auditare presupune obinerea 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 asemnare calculai de auditori GA1, GA2, ..., GAKG, unde KG reprezint numrul de aspecte din proiectul sistemului informatic care au fost supuse analizei, indicatorul agregat, GAA, are forma: KA GAA = GAi i =1
1 / KA

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; - operaii de gestiune a sistemului G4 = 0,9;

rezult indicele agregat: GAA = 4 G1G2G3G4 = 4 0,7 0,9 0,8 0,9 = 4 0,4536 = 0,821 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, avnd o fundamentare riguroas. Elementele incluse n liste i diferenele 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 inspiraii ale crei rdcini vin dintr-un alt mediu.

8. AUDITUL TEXTELOR SURS

A audita un produs software, nseamn a parcurge etapele codului de audit avnd ca obiect, mai nti un text surs care, dac trece de etapele de analiz, dup compilare i editare de legturi, este lansat n execuie i este auditat ca produs finit, validat pentru a obine o anumit funcie de prelucrare. Textul surs este analizat prin revizii, avnd ca rezultat o serie de comentarii, din partea membrilor echipei sau a clienilor, asupra modului n care a fost conceput i elaborat. n cazul n care se caut disfuncionaliti, prin parcurgerea textului surs sau prin discuii asupra locului i rolului unor instruciuni, se evideniaz comportamnentul statistic al programului, privit ca automat nedeterminat, caracteristic datorat absenei unor teri, se obine o orientare pe auditul bazat pe walk-through. Un rol special l are inspecia textului surs, care const n parcurgerea textului pas cu pas, evideniind etapele algoritmului i evalund capacitatea de generare a erorilor. Inspecia are ca obiectiv creterea calitii software prin aplicarea unor reguli verificate i neluate n considerare de ctre programatorii care au dezvoltat produsul analizat. Pornind de la specificaiile de programare unde se prezint: - datele de intrare; - rezultatele; - modelele de calcul; - seturile de date de test i rezultatele ce trebuie obinute. Prin inspecie, se pun fa n fa componentele specificaiilor cu secvenele corespondente din program. Se identific urmtoarele situaii: - mulimii secvenelor de texte din specificaii le corespund secvene de instruciuni n programul de surs; auditul consemneaz c programul realizeaz cerinele definite n specificaii;

- n mulimea secvenelor, unora le corespund secvene de text surs, iar altor secvene le corespund astfel de pri de program surs; nseamn c programatorii nu au dezvoltat un produs care s realizeze toate funciile de prelucrare care sunt descrise prin specificaii; - pe coloana mulimii secvenelor de program surs apar mai multe secvene care sunt cerute prin specificaii; sunt situaii n care programatorii intuiesc o serie de prelucrri necesare programului, neincluse n specificaii datorit abordrii de suprafa a problematicii n textele specificaiilor. Aceleai situaii se ntlnesc 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 parial sau caracterul complet al prelucrrilor. Auditul pe textul surs stabilete care sunt minusurile din textul surs sau care sunt definirile n plus, fr a da soluii, adic fr a genera secvenele lips, pentru a arta cum trebuie rescris programul. Textele surs sunt formule concrete prin care se definesc sistemele de programe, alturi de fiiere/baze de date sau alte construcii care implic date i relaii dintre ele. Textele surs sunt entiti bine definite care conin: - o sublist de parametri corespunztoare datelor de intrare; - o sublist de parametri care corespunde datelor de ieire, rezultatelor; - o sublist care corespunde parametrilor de stare; - o secven de instruciuni de iniializare variabile locale; - o secven de prelucrare, n care n membrul stng apar elemente ale sublistei de rezultate iar n partea dreapt, n expresii apar elemente ale sublistei de variabile de intrare; - o secven de iniializare a variabilelor de stare; - o secven care conine returnarea unei valori globale de stare. Secvenele de prelucrare sunt astfel construite nct s activeze toate componentele subsistemelor. Nivelul de complexitate a modulelor depinde de viziunea designerilor. Sunt diferite modaliti de a concepe structura modulelor. Sunt situaii n care se precizeaz c un modul conine una sau mai multe proceduri. n continuare, se consider c un modul este format dintr-o singur procedur.

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 instruciunile; - se consemneaz la intersecia liniei i cu coloana j rolul pe l are variabila cu poziia i n interaciunea cu poziia j; - se analizeaz tabelul rezultat, observnd dac exist linii sau coloane care nu conin nici un simbol; de asemenea, se verific dac sunt respectate regulile de baz privind utilizarea variabilelor din subliste numai cu semnificaia pe care o au, iar n cazul n care apar inadvertene se marcheaz distinct; - se construiete un graf asociat textului surs, identificndu-se secvenele repetate, absena unor operaii i dezechilibrele la nivelul proceselor prin numrul arborilor de nlimi foarte diferite. Pentru elaborarea unui modul exist specificaii clare, ce prezint semnificaia rubricii, algoritmul utilizat, inputurile i outputurile. Se construiete un tabel n care pe o coloan se afl instruciunile, iar pe o alt coloan se afl secvenele de text din semnificaii. Se identific una din urmtoarele situaii: - tuturor grupurilor de secvene de instruciuni le corespund texte de specificaii; epuizarea secvenelor epuizeaz textul specificaiei; - secvenelor de program le corespund texte de specificaii, fr ca specificaiile s fie epuizate; nseamn c procedura nu conine toate prelucrrile; fie ele sunt cutate n alte proceduri, fie se consemneaz absena prelucrrilor n proceduri; n funcie de conveniile de auditare i de flexibilitatea ipotezelor adoptate; - unele secvene de program au texte corespondente n specificaii; altele nu au i specificaiile sunt incomplete, ori procedura dezvolt prelucrri noi, n afara specificaiilor n ideea de a compensa sau de a introduce faciliti noi acceptate de o nou viziune a programatorului asupra produsului realizat; - secvene de program nu au texte de specificaii, iar specificaiile nu au fost epuizate; programul execut prelucrri noi, nesolicitate i nu execut minimul de prelucrri cerute prin specificaii; - toate secvenele program au texte de specificaii i au rmas secvene de program n plus, ceea ce nseamn c procedura realizeaz nu numai cerinele din specificaii, ci i lucruri n plus;

- unele secvene de program au texte de specificaii, altele nu au, nu au fost epuizate nici specificaiile, nici textele surs, nseamn c procedura efectueaz prelucrri necerute, rmnnd neefectuate prelucrri impuse prin specificaii. Se impune efectuarea unui calcul de distan dintre ceea ce conine efectiv programul i ceea ce trebuia s conin. Un program PROGi are un nivel de complexitate Ci, iar un program PROGj are nivelul de complexitate Cj. Secvenele comune celor dou programe au complexitatea Cij = C(PROG1 PROG2). Un indicator de asemnare se definete prin:
DA = C (PROG1 PROG2 ) C (PROG1 PROG2 )

Rezult c distana DA = 0, dac cele dou programe sunt identice, iar distana DA =1, dac cele dou programe nu au instruciuni de prelucrare comune. n acest caz, complexitatea este vzut chiar ca numr de instruciuni. De exemplu, se consider secvenele de program: S1 : a = 7; b = 8; c = 9; if (a > b) c = 3; if (x - y) z = 8;

S2 :

este:

Numul de instruciuni rezultat din reuniunea secvenelor S1 i S2 C(S1 S2)= 5 Numrul de instruciuni comune celor dou secvene C(S1 S2)= 0 Rezult c asemnarea DA = 0. Pentru secvenele: S1 : a = 7; b = 8; c = 9;

S2 :

a = 7; if (x-4) i++; for (i = 0; i< n; i++) x[i] = 1; c = 9;

rezult: C(S1 S2)= 2 C(S1 S2)= 5 2 indicatorul de asemnare DA = 5 Pentru modulele MO1, MO2, ..., MONMOD se calculeaz indicatorii de asemnare cu modulele MO1, MO2, ..., MONMOD , DA1, DA2, ..., DANMOD i rezult un indicator mediu:

DAMED

NMOD = DAi i =1

1 / NMOD

cu care se plaseaz ntregul proces de analiz intern n zona modulelor reanalizate foarte bine, bine, satisfctor, sau n zona modulelor nesatisfctoare. Urmtorul pas care trebuie realizat const n analiza modulelor n interdependena lor. Specificaiile stabilesc legturile dintre proceduri. Auditul textului surs are menirea de a analiza traiectoriile fluxurilor dezvoltate de proceduri. Mai nti sunt analizate modulele cu legturi directe spre nivelul inferior, figura 8.1. Dup aceea se analizeaz modulele cu legtur direct spre nivelul superior, figura 8.2. n final se analizeaz simultan fluxurile de interaciune ale modulului mijlociu, figura 8.3.

Nivel mijlociu

Nivel inferior
Figura 8.1. Analiz top down

Nivel superior

Nivel inferior

Figura 8.2. Analiz bottom - up

Nivel superior

Nivel mijlociu

Nivel inferior

Figura 8.3. Analiz fluxurilor de interacine ale modulului mijlociu

Legturile seriale dintre module, de forma dat n figura 8.3, impun ca modulul MO1 s asigure introducerea datelor, iar modulul MOn s determine afiarea de rezultate. Apelarea, din aproape n aproape, a modulelor MO1, MO2, ..., MOn-1 prespune stocarea n memorie a tuturor datelor iniializate 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 construiete tabelul 8.12 de utilizare a variabilelor transmise.

MO1

MO2

MO3

MOi

MOn
Figura 8.4. Structur liniar de module

Utilizarea variabilelor transmise

Tabelul 8.12 Parametri Modul MO1 MO2 MO3 MO4 MO5 VAR1 VAR2 VAR3 VAR4 VAR5 VAR6 VAR7 VAR8 VAR9

MO1 MO2 MO3 MO4 MO5

Figura 8.5. Structur liniar cu cinci module

Utilizarea variabilelor n module

Tabelul 8.13 Parametri Modul MO1 MO2 MO3 MO4 MO5 VAR1 Read IN IN IN Write VAR2 Read IN IN IN Write VAR3 Read IN IN Write VAR4 Read IN IN Write VAR5 Read IN Write VAR6 Read IN Write VAR7 Out Out Out Write Out Out Write VAR8 Out Write VAR9

Read iniializarea 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 afieaz sau se scriu n fiiere Analistul evidenieaz gradul de corectitudine n utilizarea variabilelor. Este important ca variabilele s aib o singur utilizare n cadrul structurii. Ele se iniializeaz (Read) o singur dat i se scriu, de asemenea, o singur dat (Write). Fiind de acelai tip, numai IN sau numai Out, apar exclusiv ori numai n membrul drept al expresiilor aritmetice, ori numai n membrul stng. n cazul n care specificaiile nu includ reguli

precise, programatorii dezvolt, n structuri liniare, utilizri diferite pentru o aceeai variabil, ceea ce conduce la riscuri crescute cnd modulele sunt realizate de programatori diferii, care nu tiu c valorile unor parametri de intrare au fost alterate de modulele precedente. Dac modulele includ apeluri crora li se creeaz structuri arborescente, procesul de auditare trebuie s evidenieze ortogonalitatea prelucrrilor din modulele nivelului descendent, figura 8.6.

MOkj

MOk+1,1

MOk+1,2

MOk+1,L

Figura 8.6. Secven de structur arborescent de module

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 numr de subliste egal cu numrul modulelor descendente. De exemplu, pentru secvena 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

Se construiete tabelul 8.14 pentru analiza modulului n care variabilele sunt utilizate.
Transmiterea de parametri
Tabelul 8.14 Parametri Modul MO1 MO2 MO3 MO4 VAR1 IN IN VAR2 VAR3 VAR4 VAR5 VAR6 VAR7 VAR8 VAR9 IN IN IN IN IN IN IN IN IN IN IN IN Out IN Out IN

Definirile neortogonale utilizeaz aceleai 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 situaii n care unele variabile output pentru modulul precedent devin intrri pentru modulele descendente. Dup analiza parametrilor este important ca n procesul de auditare s se analizeze modul n care au fost iniializate variabilele. Exist software care evideniaz dac n program sunt utilizate variabile neiniializate. Auditarea prelucrrilor presupune stabilirea corespondenei dintre formulele date n specificaii i secvenele de program scrise. Astfel, pentru evaluarea expresiei:
S = xi
i =1 n

trebuie se existe o secven de forma:

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

Auditorii trebuie s stabileasc dac programele conin toate condiiile incluse n specificaii.

Astfel, pentru evaluarea expresiei: x 2 pentru x > 0 e( x) = 7 pentru x = 0 1 pentru x < 0 x2 + x

n textul specificaiilor se includ diagrame dup care se elaboreaz scheme logice. Rezult c programul trebuie s includ textele pentru a separa intervalele i valorile necesare evalurii corecte a expresiilor, ceea ce conduce la a analiza secvena: if (x == 0) ex = 7; else if (x > 0) ex = x*x; else ex = 1/(x*x + x); Programatorii au la dispoziie numeroase modaliti de a dezvolta secvene n care se dorete derularea programelor de optimizare simultan cu procesul de elaborare. Se obine o construcie diferit de cea din specificaii, pe care auditorul trebuie s o perceap corect. De exemplu, pentru evaluarea expresiilor:

x=

x
i =1

n
n i

=
2

(x
i =1

se construiete secvena de program echidistant optimizat: S1 = 0 S2 = 0 for (i = 0; i < n, i++) {S1 + = x[i] S2 + = x[i]*x[i];}

x
n

2 i

2 xi x + x

2 i

2 x x
n

+x

XMED = S1/N SIGMA = S2/n XMEX * XMED Aceast secven este diferit de secvena care rezult direct din specificaii. 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; Cnd se analizeaz secvenele de program trebuie cutate sursele de erori care afecteaz fluxurile de prelucrare, dintre care se enumr: - lucrul cu variabile neiniializate; - traversarea unor structuri de date n afara limitelor pentru care au fost definite; - neincluderea de teste care s evite mprirea prin zero sau blocarea unor funcii care au restricii asupra intervalelor parametrilor; - construirea unor expresii care filtreaz parial sau incorect submulimi de elemente;

- restructurarea expresiilor prin schimbarea ordinei de evaluare a unor subexpresii diferite de cele date de specificaii; - efectuarea de conversii intermediare deformeaz rezultatele finale; - construirea expresiilor de referire a elementelor unei structuri care dezvolt procese de cutare/regsire neconcordante cu specificaiile; - absena manipulrii variabilelor de stare a prelucrrilor; - atribuirea de coduri variabilelor de stare dup alte reguli dect cele date n specificaiile de programe; - alocarea dinamic a unor variabile fr a exista i procesul de dealocare; - introducerea unor elemente de neomogenitate; precum citiri, scrieri de date; - definirea de invariani n structuri repetitive, n principal, prin inexistena incrementrilor sau decrementrilor; - neincluderea n secvene a unor instruciuni corespunztoare evalurii unui model sau filtrrii, ceea ce conduce la o tratare parial a problemei; - atribuirea altei semnificaii variabilelor cu consecine directe asupra rolului i locului pe care acestea le au n program; - introducerea de expresii de atribuire care anuleaz prelucrrile precedente; - compunerea unor construcii fr a exista o echivalen ntre formulele finale i cele iniiale 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 cteva 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 corespondenele dintre listele de parametri i modul cum sunt folosii acetia. A doua regul vizeaz omogenitatea secvenelor de program existente. Aceast omogenitate se refer la gruparea n secvene compacte a instruciunilor dar i la utilizarea unor modaliti ca nume n ntreg textul

surs; de exemplu, dac se prefer utilizarea operatorului de negare cu expresiile condiionale din instruciunea: if (! ( expresie ) ) secvena 1; else secvena 2; atunci astfel de construcii trebuie s fie folosite peste tot. A treia regul vizeaz stilul de programare. Exist multe modaliti 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 obin construcii software care nu difer semnificativ unele de altele, dei au fost scrise de foarte muli programatori. Auditul software nu are menirea de a analiza ct de mult sau ct de puin au fost respectate regulile definite ca stil de programare. Se supun analizei secvene sau proceduri. Au importan din punctul de vedere al auditorului nu formule de realizare a prelucrrilor ci, elemente de esen, adic rezultatele, fluxurile pe care le genereaz. Un program este corect sau incorect prin ce prelucrri realizeaz. Stilul de programare are un rol, dar nu este esenial 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 cnd 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 fcute de utilizatori prin comparaie.

DIN PROG

REZ

Figura 8.8. Structura global a unei proceduri

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 fiecrei subprobleme i corespunde cte o procedur. Din cri, din documentaii oferite, din rezolvri manuale ale problemei PROB se obin, pentru toi paii care alctuiesc subproblemele, rezultate intermediare RINT. Aceste rezultate intermediare obinute la pasul k sunt utilizate ca date de intrare pentru procedura corespunztoare subproblemei SPROBk. Auditarea are menirea de a vedea dac, folosind aceste date de intrare, se obin rezultatele corespunztoare pasului Ik, desigur rezultate intermediare, figura 8.9.

Date intermediare de intrare

SPROBk

Pasul k al algoritmului

Rezultate obinute de modul

Rezultate calculatre manual

Audit comparare

Calificativ

Figura 8.9. Compararea rezultatelor intermediare

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; - numrul de elemente diferite care se calculeaz; - locul unde se calculeaz fiecare element diferit din structura de rezultate intermediare; - modul n care sunt manipulate rezultatele obinute, 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 conine: 1 o variabil n care se stocheaz elementul minim dintr-o matrice; 2 un tablou cu dou linii i dou coloane ale cror elemente se calculeaz dup expresiile:
a11 = x + y

a12 = x 2 + y 2 + z 2 a 21 = x * y + z 3 a 22 = x x +1 + 2 1+ y 1+ z2

3 un ir de elemente omogene obinute cu relaia wi = u i2 + u i3 ; 4 un tablou cu trei linii i trei coloane B obinut cu relaia:

B = C + C2 + C3 ,
unde C este, de asemenea, tot un tablou cu trei linii i trei coloane. Acestei structuri de rezultate finale trebuie s-i corespund secvene de instrucini 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];

--------------------------------------------------------------------------------------

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. Secvene de instrucini n procedur

n secvena 4 au fost utilizate procedurile de bibliotec pentru rdcina de putere a unei matrice i pentru adunarea a dou matrice. n derularea auditului textului surs, atunci cnd se compar structura rezultatelor cu secvenele de prelucrare, apar urmtoarele situaii: - fiecrei componente din structura de rezultate i corespunde o secven de instruciuni n procedur; se auditeaz secvenele pentru a vedea dac procedurile sunt corecte; - exist componente n structura de rezultate care nu au secvene n procedur; nseamn c procedura rezolv parial problema; trebuie cutate secvene n alte proceduri pentru a vedea dac tratarea este complet. Dac procedura realizeaz n plus i alte prelucrri, este o alt problem. Ceea ce trebuie s evidenieze procesul de auditare este strict legat de obiectivul propus.

n acelai fel se procedeaz i cu structura datelor de intrare. Rezultatele intermediare se obin 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 fiier; - unei baze de date. Tuturor acestor elemente din structura datelor iniiale trebuie s le corespund: - identificatori; - modaliti de preluare n procedur; un mod din care s rezulte c au fcut obiectul unei iniializri. 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 prelucrrile care se produc n module. La nivelul urmtor sunt descrise procedurile. Tablourile pentru auditarea procedurilor conin indicatori care includ evaluri pentru ct mai multe aspecte legate de: - modul n care au fost scrise procedurile prin prisma resurselor de limbaj utilizat; - concordana dintre textul surs i textul proiectului realizat de designeri; setul de prelucrri pe care le declaneaz procedura; - setul de incidente pe care procedura trebuie s le gestioneze returnnd mesaje proprii, fr ntreruperea necontrolat a execuiei secvenelor. Raportul de audit pentru o procedur include pe o coloan indicatorii dup care s-a efectuat analiza i pe coloana alturat nivelul msurat al fiecrui indicator. Auditorul este obligat s furnizeze un nivel agregat cu care s clarifice ntr-un mod unic i fr 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.

Exist particulariti privind: - instrumentele folosite; - limbajele de programare utilizate; - instruciuni, comenzi, operatori referii; - componente de biblioteci referite; - modaliti de a dezvolta expresii compuse sau instruciuni agregate; - predilecia spre a defini anumite structuri de date; - modul de construire a identificatorilor; - concentrarea sau dispersarea instruciunilor omogene; - gestionarea transferului spre alte proceduri printr-un sistem omogen folosind fie o structur secvenial, fie o structur alternativ multipl; n ambele cazuri se asigur caracter deschis aplicaiilor; - revenirea n procedura apelatoare printr-o singur instruciune return (C); atunci cnd sunt utilizate mai multe instruciuni, aspectul este stabilit de la nceput i acceptat ca regul nu ca excepie; - meninerea mecanismului de transmitere a parametrilor spre procedurile apelate, n aa fel nct pentru toate procedurile este pstrat acelai mecanism; - modul de transmitere integral a structurilor de date, care trebuie s fie n toate procedurile acelai pentru aceeai structur de date. La dezvoltarea software un rol special l are realizarea asamblrii de componente i testarea ansamblurilor rezultante, nainte de a se obine produsul finit sistemul informatic. Dac sistemul informatic are asociat o structur arborescesnt, exist dou modaliti distincte de a grupa procedurile i anume prin: - separarea procedurilor care asigur operaiile de intrare, respectiv PROIN1, PROIN2, ... PROINNIN, de procedurile de calcul, respectiv PROCA1, PROCA2, ..., PROCANCA; procedurile de stocare sau de afiare a rezultatelor sunt grupate i ele PROUT1, PROUT2, .., PROUTNOUT; se obine o construcie 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 nct s se obin triplete de forma (PROINi, PROCAj, PROUTk ), iar structura asociat corespunde figurii 8.12; prelucrrile se constituie n cicluri complete asigurnd o mai mare independen de la un rezultat final la altul; structura arborescent grupeaz pe un nivel de sus al arborescenei procedurile de intrare i cele de ieire,

urmnd ca procedurile de calcul s-i urmeze dezvoltrile conform complexitii specifice algoritmilor de prelucrare.

Software

Software 1

Software 2

Software 3

PROIN1

PROIN2

PROINNIN

PROUT1 PROUT2
PROCA2

PROUTNOUT

PROCA1

PROCANCA

Figura 8.11. Structur software cu proceduri grupate

Software

Software 111

Software ijk

Software NIN NCA NOUT

PROIN1

PROCA1

PROUT1 PROINi PROCAj

PROUTNIN
PROUTk

PROUTNOUT

PROCANCA

Figura 8.12. Structur software cu gruparea procedurilor spre finaliti complete

Este important ca dup adoptarea uneia din reguli, toate subsistemele software care alctuiesc produsul final asociat sistemului informatic s fie urmat de toi programatorii.

Auditul procesului de asamblare prevede urmrirea pas cu pas a procesului de implozie pe structura arborescent asociat sistemului informatic. Asamblarea de proceduri conduce la un text surs compus a crui analiz trebuie s evidenieze: - corespondena dintre proiect i produsul software analizat; - inexistena neconcordanelor generate de definirile diferite i utilizrile diferite ale acelorai entiti; ntr-o procedur acelai masiv are numr definit de linii i numr definit de coloane, dect n alt procedur apelat; - abordarea dinspre detaliu spre ansamblu, pentru a obine output-urile n structura proiectat; - coerena dezvolrilor bottom-up specifice realizrii unui sistem prin proceduri al cror apel conduce la obinerea unei construcii cu grad de complexitate din ce n ce mai ridicat, pe msur 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; operaiile complementare vizeaz citirea, respectiv, scrierea, concatenarea, respectiv, deconcatenarea; operaiile simetrice au aceeai semnificaie, ns se execut cu ali 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 regseasc i la nivelul software. De asemenea, conine indicatori de analiz a procedurilor i a irurilor de proceduri. n final, transferul de ncredere a utilizatorilor n produs se obine numai n msura n care n procesul de auditare au fost identificate acele elemente care coincid cu obiectivele utilizatorilor. Produsul software a fost testat de specialitii 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 testri folosind date de test existente n specificaii, dar i cu date de test n structura cerut de auditori. Rezultatul privind calitatea software reprezint efortul propriu al auditorilor. Analiza rezultatelor obinute 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.

n aceast etap de auditare, rezultatele fac obiectul unei analize comparate cu rezultatele testrii efectuate de echipa de elaborare software. Inspecia software se dovedete a fi un proces extrem de complex, cu muli pai intermediari, cu multe direcii de abordare. Presupune un efort de sistematizare a datelor obinute i utilizarea unor instrumente de analiz pe msura tehnicilor i metodelor de programare ntrebuinate. Numai un proces de auditare software autentic, cu un plan bine ntocmit, cu sarcini i etape clare, conduce la obinerea de concluzii realiste. Astfel, se dezvolt riscul de a conchide c un produs software este corespunztor, cnd, n realitate el este generator de erori. Riscul ca un produs bun s fie respins este redus, ntruct raportul de auditare are numeroase chei de control care s plaseze un produs bun n zona de acceptare prin nivelurile msurate ale indicatorilor. Auditul testrii i auditul interfeelor se trateaz distinct, pentru c: - interfeele reprezint forme care au la baz proceduri; - interfeele dau msura capacitii programatorilor de a transpune exigenele designerilor n programe, n vederea obinerii efectelor dorite; - testarea se execut pentru proceduri, pentru grupe de proceduri; - testarea evideniaz msura n care procedura execut funcia de prelucrare pentru care a fost creat; - testarea reprezint calea prin care se culeg date privind comportamentul produsului software. Analizarea interfeelor presupune parcurgerea mai multor etape, i anume: - analiza structurii mesajelor iniiale, oferite de produs utilizatorului; - analiza structurii mesajelor pe care utilizatorul trebuie s le introduc; - evaluarea riscului de ntrerupere a interaciunii om calculator datorit complexitii schimbului de mesaje; - verificarea msurii n care s-a obinut o minimizare a efortului utilizatorilor de a dezvolta interaciuni prin gsirea unor modaliti ct mai simple de selecie a opiunilor sau de introducere a textelor; - respectarea regulilor privind amplasarea mesajelor pentru a menine continuitatea n raport cu alte produse; de exemplu,

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 fora pe utilizator s procedeze la o adoptare cu efecte fie de respingere, fie de reinere, fie de risip de resurse prin ncercri euate; - controlul mesajelor pentru a dezvolta aplicaii ortogonale, fr ambiguiti; se prefer folosirea de opiuni pe care utilizatorul s le selecteze. Auditul testrii este un capitol special. n primul rnd, 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 testrii efectuate de echipe de realizatori ai produsului cu rezultatele testrii efectuate de auditori care permit concluzii asupra: - diferenelor ntre calitatea identificat de auditori i calitatea msurat de testerii produsului software; - completitudinei procesului de testare n raport cu volumul i cu diversitatea testelor existente n specificaii i proiectul produsului; - efectele pe care le-a avut testarea asupra relurii unor etape din ciclul de elaborare software pentru a obine coreciile sau mbuntirile necesare. Testarea este un proces de o importan special pentru ciclul de elaborare software i pentru managementul calitii 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 testri pe seciuni complete de date de test; - diferenele dintre testele efectuate i cele care trebuiau efectuate; - rezultatul comparrii datelor obinute prin testarea echipei de elaborare software cu datele obinute de auditori; dac rezultatele nu difer semnificativ se accept nivelul de performan estimat de echipa care a elaborat software; dac rezultatele difer semnificativ, trebuie vzut care sunt cauzele care au generat diferene; concordana dintre rezultatele obinute pe ntreaga traiectorie a asamblrii componentelor; unele rezultate devin date de intrare; concordana vizeaz att testarea independent pe care o asigur fiecare programator, ct, mai ales, procedurile asamblate; trebuie

vzut 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 cnd i-a testat procedura; rezultatele REZk reprezint outputurile de la nivelul k, figura 8.13; sunt numeroase situaiile cnd apar diferene ntre rezultatele de la nivelul k i datele de intrare necesare la nivelul k+1; aceste diferene au cauze profunde i dac nu sunt depistate nc n fazele de design de sistem dificultile de remediere sunt foarte mari; iar costurile sunt, de asemenea, foarte mari;

DINTk+1 REZk Procedura K Procedura k+1

Figura 8.13. Concordana datelor de test

- limitele pe care le conine procesul de testare, prin durata de timp alocat, prin nivelul de testare impus sau acceptat; testarea se realizeaz ca etap distinct clar cu reluri pe msura remedierii defectelor de funcionare a procedurilor; procesul trebuie s fie iterativ convergent; toate testele sunt convenite i acceptate; dac se urmrete dezvoltarea de produse cu respectarea cerinelor impuse de normele de calitate specifice stadiului de zero defecte, cheltuielile, perioadele de testare, remediere i, n general, de cretere a calitii sunt mult mai importante ca pondere n durata ciclului de realizare software; limitele sunt date de la nceputul abordrii problemei, cnd sunt luate n discuie performanele sistemului informatic; nu exist sistem informatic cu zero defecte, n condiiile n care software care intr n componen nu a fost testat pn s-a ajuns, de asemenea, tot la zero defecte; - seriile de date obinute de testeri n vederea stabilirii dac sunt sau nu comparabile; comparabilitatea este dat de respectarea cerinelor de testare; seturi de date identice, intervale, condiii hardware similare, proceduri de msurare a rezultatelor, identice; este important s se tie dac datele sunt sau nu comparabile i se stabilesc coeficieni de transformare i se obin date comparabile; datele comparabile sunt supuse unor prelucrri i rezult c sunt reprezentative sau nu; numai dup aceea sunt reinui

indicatorii care dau nivelurile de calitate; testarea software este finalizat prin raportul de testare care trebuie s urmeze reguli precise de alctuire, asemenea nregistrrilor privind evoluia unor procese chimice sau asemenea derulrii unui tratament ntr-un spital; datele din testare sunt eseniale n tot ce urmeaz cu sistemul informatic pe durata exploatrii. Raportul de auditare a testrii are ca finalitate s stabileasc dac testarea este sau nu reprezentativ pentru sistemul informatic. Se indic toate elementele necesare pentru a obine o testare software la un nivel cerut de exigenele impuse asupra sistemului informatic. Raportul de audit al testrii sistematizeaz prin concluzii datele care vizeaz ntregul proces de testare. Este necesar ca acest raport s fie exigent, profesional, complet i sistematic. S nu rmn 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 dect o inspecie pe codul surs. Se ia n considerare i comportamentul produsului n ipoteze apropiate de mediul efectiv de funcionare. Raportul de audit d evaluri privind gradul de satisfacie pe care l obine utilizatorul virtual, prin intermediul interfeelor la utilizarea sistemului, prin lansarea n execuie 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 condiii precum: - cunoaterea n detaliu a limbajului de programare n care este scris programul auditat; - s se familiarizeze rapid cu stilul de programare adoptat pentru scrierea de ctre echipa de programatori care a realizat programul; - s cunoasc efectele de antrenare pe care le genereaz conturarea de secvene echivalente sau s stabileasc efectele unor procese specifice introducerii recursivitii sau compunerii de instruciuni; - 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.

Auditorul are o list de erori probabile nsoite de modul direct de producere. Prin audit se analizeaz textul surs pentru a vedea modele de program care includ construcii generatoare de erori. Experiena n activitatea de programare conduce la conturarea listei de evenimente Ev1, Ev2,...Evm mpreun cu frecvenele de operare deduse prin analiza unui lot de N produse program. Evenimentele se ordoneaz dup frecvenele de apariie fr1, fr2,... ,frm astfel nct fr1> fr2> ... frm. Pe durata inspeciei, auditorul se orienteaz s identifice secvenele care genereaz evenimentele Ev1, Ev2,... El nu neglijeaz nici evenimentul Evm care are probabilitatea minim de apariie. Inspecia software este asemenea investigaiilor unui medic care pornete n stabilirea diagnosticului de la cazurile cele mai probabile, lsnd spre finalul analizei cauzele neprecizate ale efectelor. Introducerea de reguli verificate n a defini variabile i n a construi secvene omogene, are rolul de a mbunti procesul de elaborare a codului surs. Introducerea regulilor conform crora procedeele de calcul nu conin apeluri de proceduri pentru citire de fiiere sau pentru scriere n fiiere, conduce la ameliorarea rapid a procesului de scriere cod surs. Persoanele care execut auditul n texte surs sunt specialiti recunoscui pentru ca inspecia s fie tratat cu maxim seriozitate.

9. AUDITUL DATELOR
Datele care se stocheaz n mod sistematic n fiiere 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 ntruct vizeaz acele componente ale sistemului informatic care au ca obiectiv crearea i actualizarea fiierelor sau bazelor de date. Auditul acestor componente permite obinere unei imagini complete n legtur cu capacitatea software de a contribui la realizarea unui nivel ct mai ridicat al calitii 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 iniializat prin: - atribuirea unei constante; de exemplu, se definesc variabilele: int a; float b; ch c; i se iniializeaz n secvena: a = 7; b = -25.81; c = w ; atribuirea unui rezultat dup evaluarea unei expresii; de exemplu n secvena:

int a= b, b = 5, c -------------------------------------------c = a+ b*5; variabilei c i se atribuie valoarea 33 dup evaluarea expresiei;

suprapunerea zonelor de memorie cu ajutorul operaiei union; de exemplu n secvena: int a, b, c; union {a,c}; b = 5; a = b;

rezult c variabilele a i c vor ocupa aceeai zon de memorie; indirect se obine iniializarea variabilei c, iniializat de variabila a; - copierea variabilelor de tip articol tratate ca iruri de caractere; - transfer cu conversie din buffere prin apariii de citire a fiierelor; - transmiterea prin valoare a parametrilor cu condiia ca ntre lista de parametri reali i lista de parametri formali s existe o perfect concordan. Exist numeroase cauze generatoare de erori atunci cnd este vorba de iniializarea variabilelor. n cazul n care modulele au un grad ridicat de specializare se produce localizarea distinct a iniializrii variabilelor prin citire din fiiere, indiferent care este tipul de fiier. Se consider criteriile de validare CV1, CV2, CV3, ..., CDNCV. Se construiete 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 CV1 CV2 ... CVi ... CVNCV TFD1 TFD2 ... TFDj ... TFDNFT

xxij

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 conine simbolurilor 0, 1, 2, 3, 4, 5, 6, 7, 8, 9; CV2 - data aparine intervalului [Linf , Lsup]; CV3 data este unul dintre irurile {a1 , a2, , ak }

CV4 data este mai mare ca zero; CV5 data este diferit de zero; CV6 data este mai mic dect zero; CV7 suma cifrelor care alctuiesc data aparine unei mulimi {c1 , c2, , cL }. Lista criteriilor de validare este o list standard. Designerii o cunosc tot att 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, avnd NeCVI componente, problema completitudinii are o dubl abordare. Prima abordare se refer la iniializarea tuturor cmpurilor care descriu un element din colectivitate. A doua abordare se refer la numrul componentelor pentru care au fost introduse date. Dac numrul 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 rmnnd n afar. Dac NeCVI < XeCVI, exist urmtoarele surse ale diferenelor: - numrul elementelor colectivitii NeCVI a fost incorect nregistrat i numrul corect al datelor este XeCVI; - unele nregistrri au fost realizate de mai multe ori, fiind vorba de nregistrri simple; - au fost introduse date referitoare la elemente ale altor colectiviti. Auditorii trebuie s stabileasc despre care dintre situaii este vorba. Exist situaii n care programele genereaz numere de identificare a evenimentelor i acestea devin i chei de regsire. Sunt create condiii de a introduce datele despre un element din colectivitate de nenumrate ori cu asocierea unei alte chei de regsire. Este important ca auditorii s dispun de software care analizeaz coninutul datelor stocate pentru a identifica: - articolele duble introduse; - concordanele 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 ntruct datele influeneaz direct, fr condiii, calitatea

rezultatelor finale care se obin de ctre un sistem informatic. Din acest considerente, se prezint, n continuare, aspecte privind particulariti, catacteristici, metrici i indicatori de calitate ai datelor. Se consider n colectiviti CVI1 , CVI2 , ..., CVIn fiecare din ele fiind format din NeCVI1, NeCVI2, ..., NeCVIn elemente. Fiecare colectivitate CVIi, i = 1, 2, ..., n include elemente de acelai tip care sunt i . descrise folosind caracteristicile de difereniere Cdif 1i , Cdif 2i , ..., Cdif m

MCdif1, MCdif2, ..., MCdifn reprezint numrul caracteristicilor de difereniere a elementelor din cadrul colectivitilor , respectiv CVI1 , CVI2, ...,respectiv CVIn. Pentru nregistrarea datelor fiecrui element aij din colectivitatea CVIi, care este dispus pe poziia j n irul de elemente, se definesc proceduri care vizeaz: - realizarea msurtorilor pentru acele caracteristici de difereniere ale cror niveluri sunt de natur cantitativ; - constatarea unor atribute pentru a defini acele caracteristici crora li se asociaz niveluri de ordin cantitativ; - punerea n coresponden cu elemente ale unei mulimi finite, atunci cnd, dup efectuarea evalurilor se produce o agregare a mai multor criterii. Aceste proceduri trebuie astfel definite nct s asigure reproductibilitatea colectrii datelor privind elementele oricrei colectiviti. Pentru constituirea colectivitii CVIi i pentru definirea mulimii i caracteristicilor de difereniere Cdif 1i , Cdif 2i , ..., Cdif m se iau n considerare criterii de apartenen i criterii de difereniere care au la baz obiectivul urmrit n colectarea i n prelucrarea datelor. Realitatea economico social ofer o mare varietate de aspecte i interpretri, ceea ce impune definirea cu maxim precizie a obiectivului pe care un produs software, o aplicaie informatic, sau un sistem informatic trebuie s-l aib atunci cnd ncepe derularea codului de dezvoltare. ntr-un fel, este constituit mulimea caracteristicilor de difereniere a elementelor colectivitii cnd prelucrarea datelor are ca obiectiv o optimizare din punct de vedere structural sau de performan i cu totul altele sunt caracteristicile selectate atunci cnd obiectivul prelucrrii vizeaz exclusiv latura financiar contabil a dinamicii acelorai elemente.

Pentru un obiectiv stabilit, O, se construiete un plan care vizeaz datele problemei de rezolvat incluznd etapele: Etl precizarea colectivitilor prin enumerarea lor, CVI1 , CVI2, ...; din aceast enumerare rezult numrul de colectiviti NCVI; 1 - construirea listelor de caracteristici < Cdif 11 , Cdif 21 ,..., Cdif ml >,
< C
2 1

2 2

,...

2 ml

>

n , ..., < Cdif1n , Cdif 2n ,..., Cdif mn >;

- enumerarea procedurilor utilizate pentru nregistrarea datelor. Experiena 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 colectiviti (n = 2): CVI1 colectivitatea persoanelor i CVI2 colectivitatea imobilelor. Pentru colectivitatea CVI1 se definesc caracteristicile de difereniere: 1 Cdif1 - cod numeric personal; Cdif12 - nume i prenume; Cdif13 - ir de caractere pentru localizarea n spaiu; Cdif14 - venituri; Cdif15 - ir de identificare pli electronice. Pentru colectivitatea CVI2se definesc caracteristicile de identificare: 1 Cdif 2 - codul numeric personal al proprietarului; Cdif 22 - suprafaa construit; Cdif 23 - suprafaa locuibil; Cdif 24 - an de construire; Cdif 25 - clasa de confort; Cdif 26 - clasa de reziden; Cdif 27 - valoarea de pia. Dup construirea celor dou liste de caracteristici rezult MCdif1 = 5 i MCdif2 = 7. Este deosebit de important stabilirea dimensiunilor celor dou colectiviti.

n cazul n care stabilirea cu exactitate este dificil de realizat se propun estimri acoperitoare care permit: - efectuarea de calcule privind necesarul de memorie extern pentru stocarea datelor; - stabilirea modalitilor de nregistrare simultan a datelor din colectiviti; - precizarea tehnologiei de asigurare i control a calitii procesului de nregistrare i a calitii seturilor de date rezultate; - estimarea costurilor pe care le implic att constituirea seturilor de date asociate colectivitilor, ct, mai ales, reluarea procesului de nregistrare dac nu s-a obinut 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, nct caracteristicile colectivitilor s fie prezentate cu maxim claritate prin: - gruparea tuturor caracteristicilor de difereniere ale unei colectiviti ntr-un singur formular; rezult c pentru r colectiviti distincte vor circula r formulare diferite, r seturi de proceduri pentru nregistrarea caracteristicilor specifice; - regruparea pe un formular a caracteristicilor mai multor colectiviti, mai ales atunci cnd datele de identificare a elementelor corespondente sunt comune; manipularea unui numr mai restrns de documente comparativ cu numrul caracteristicilor este nsoit de reducerea efortului de nregistrare i de cretere a gradului de concentratrare asupra calitii procesului de nregistrare date. Descrierea procedurilor de nregistrare are n vedere totalitatea situaiilor de pe teren, astfel nct completarea documentelor s fie integral i reluarea nregistrrilor prin sondaj s conduc la rezultate identice, dnd caracter de reproductibilitate procesului de constituire a seturilor de date asociate caracteristicilor. Un set de date asociat unei colectiviti CVIi se prezint sub forma unui tablou Ti cu TCOLi coloane corespunztor caracteristicilor de i i TLINi linii corespunztor elementelor difereniere Cdif1i , Cdif 2i , ..., Cdif mi ai1, ai2, ..., aiNi care intr n alctuirea colectivitii CVIi. Diferenierea elementelor unei colectiviti se obine prin nregistrarea nivelurilor msurate, constatate sau deduse la faa locului pentru fiecare elemente n parte.

La constituirea listei elementelor de difereniere pentru o colectivitate CVIi se precizeaz natura fiecrei caracteristici Cdif ji : - element de codificare pentru care se descrie mecanismul de generare i mecanismul de verificare a corectitudinii structurii obinute; - valoare numeric msurat, indicnd instrumentul cu care se asigur o msurtoare corect; - setul complet de atribute din care se extrage unul singur n mod neambiguu; - algoritmul de evaluare a nsuirilor, de cuantificare i de punere n coresponden cu un element dintr-o mulime dat. Setul de date sub forma tabloului cu TLINi linii i TCOLi coloane asociate colectivitii CVIi, pentru a face obiectul unei prelucrri 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 msura n care un element aij din colectivitate difer de un alt element aik sau msura n care elementul aij difer de toate celelalte elemente care alctuiesc colectivitatea CVIi. Datele despre elementul aij se afl pe linia j a tabloului Tj corespunztor setului de date nregistrate. Datele nscrise pe linie fie c sunt valori msurate, 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, alctuind irul de cuvinte Scuv ij , iar pe linia k a tabloului se afl irul de
i . cuvinte Scuvk

Se definete funcia Lg () pe mulimea cuvintelor vocabularului cu care este construit tabloul Ti cu valori n mulimea {1, 2, ..., Ncuvi } prin relaia:
H (aij , aik ) =
i Lg Scuv ij Scuvk

Lg

( (Scuv

i j

Scuv

i k

) )

Dac elementele aij i aik sunt total diferite H(aij, aik)= 0, iar dac elementele sunt identice H(aij, aik)=1.

Ortogonalitatea global a elementului aij este definit ca medie aritmetic a ortogonalitilor elementului respectiv n raport cu celelalte i este dat de relaia:

HG (aij ) =

H (a
k =1 k j

Ni

ij

, aik )

Ni 1

Pentru prelucrri statistice este rezonabil ca datele s aib un grad de asemnare sporit, ceea ce se traduce printr-o ortogonalitate global redus. Pentru aplicaiile economice diferite trebuie s corespund iruri de cuvinte diferite, iar ortogonalitatea trebuie s se apropie de valoarea maxim 1. Consistena datelor vizeaz nregistrrile care privesc un element din colectivitate. Proprietile elementelor se reflect i la nivelul nregistrrilor. Lipsa de consisten se manifest cnd fie prin msurtori, fie printr-un alt procedeu este trecut n dreptul coloanei COLij de descriere a caracteristicii un nivel n contradicie cu proprietile 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 fcndu-se la acelai moment de timp. Datele i pierd consistena atunci cnd cantitatea livrat este mai mare dect cantitatea existent n stoc. n acelai fel se pierde consistena datelor atunci cnd calificarea unei persoane este cu mult mai mare dect vrsta nscris pentru respectiva persoan. Omogenitatea datelor pentru aceeai caracteristic de difereniere vizeaz tipul datei, modul de efectuare a msurtorilor i modul de nregistrare. Se stabilete un domeniu de definiie pentru fiecare caracteristic n parte, se stabilete unitatea de msur a caracteristicilor de difereniere. Se urmrete ca prin aplicarea aceleiai proceduri de msurare, nregistrrile s reflecte situaia de la faa locului. De exemplu, pentru caracteristica greutatea unei persoane se stabilesc condiiile n care se efectueaz msurtorile, ce instrumente sunt folosite, procedurile pe care le urmeaz persoanele pentru ca rezultatele obinute s dea cu o exactitate ct mai mare greutatea corporal. Se stabilete dac msurtoarea se face cu rotunjire numai n plus sau numai n minus.

Completitudinea datelor vizeaz reiterarea setului de NrPRODi proceduri pentru cele MCdifi caracteristici de difereniere, pentru fiecare din cele Ni elemente ale colectivitii. Completitudinea datelor conduce la obinerea unui tablou care are toate irurile de pe linii sau de pe coloane nregistrate n concordan cu domeniile fiecrei caracteristici de difereniere. n cazul n care numrul de iruri NrSi nscrise n tablou este definit prin NSi < MCdifi NrPRODi rezult c setul de date pentru descrierea colectivitii Ai este incomplet. Analize statistice se realizeaz i pe seturi de date incomplete dac acestea nu i-au pierdut reprezentativitatea. n alte aplicaii economice, toate prelucrrile presupun seturi de date complete NSi = MCdifi NrPRODi. Accesibilitatea datelor presupune ca datele s fie disponibile uor, repede, iar algoritmii de cutare i regsire s se ncheie cu succes folosind criterii dintre cele mai variate, inclusiv definiri incomplete de chei de cutare. Acurateea vizeaz exactitatea, nivelul acceptabil al erorilor coninute, ncadrate n limite stabilite. Procedurile de nregistrare i dispozitivele de msurare sunt verificate, iar personalul este instruit s efectueze msurtorile i nregistrrile conform cerinelor impuse. Credibilitatea are la baz acceptarea nregistrrilor ca reprezentnd un rezultat real al nregistrrilor. Se consider c ori de cte ori se reia procesul de msurare-constatare folosind proceduri echivalente, nregistrrile sunt aceleai. Interpretabilitatea datelor presupune definirea unui alfabet, a unor reguli de producie pentru construirea de iruri consecutive de simboluri, iar punerea n coresponden a cuvintelor cu fapte, evenimente, obiecte din lumea real aparin unui limbaj unanim acceptat i cunoscut. Obiectivitatea vizeaz imparialitatea, lipsa de prejudeci, neprtinirea n a efectua msurtori, n a prelua rezultatul obinut de la dispozitivele de msurare i din aplicarea procedurilor de efectuare a msurtorilor. Existena unor principii etice, a unor argumente tiinifice determin eliminarea elementelor care genereaz subiectivism n constituirea seturilor de date i, mai ales, n prelucrare pentru obinerea 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

stabilite de la nceput, definitivndu-se, n acest fel, un context i un nivel de exigen sub care nu se coboar. Relevana este stabilit n raport cu cerine ale utilizatorilor i vizeaz corespondena dintre rezultatele agregate i trendul de dezvoltare a colectivitii de la care provine setul de date. Alte caracteristici de calitate sunt dependente de reputaia sursei, claritatea corespondenei dintre cuvintele unui vocabular i mulimea de elemente desemnate din lumea real. Profitabilitatea datelor vizeaz valoarea adugat care se obine i care justific efortul de definire de proceduri, de achiziionare 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 obinute sunt fundamentate decizii care se deosebesc de deciziile luate empiric prin multiple avantaje. Optimizarea deciziilor d msura profitabilitii. Atributele calitii sunt deosebit de numeroase, ele fiind incluse n tabelul 9.16 [IVAN99a]. Atribute ale calitii datelor
acceptabilitate acuratee alterabilitate auditabilitate bine documentate capacitate de descrcare certificare compactivitate competitivitate compresabilitate conexiuni logice consisten coninut cost acuratee credibilitate customizabilitate detaliere surse dispersie eficacitate extendabilitate fr greeli accesibilitate adaptabilitate amplitudine auto-corectabilitate bine prezentate capacitate de identificare erori claritate compatibilitate completitudine comprihensivitate confidenialitate context corectitudine cost colectare criticabilitate definire exact dimensiune disponibilitate ergonomie extensibilitate fr pierderi de informaii Tabelul 9.16 actualitate agregabilitate aspect estetic autoritate cantitate capacitate de ncrcare claritate surse compatibilitatea cu date istorice comportament concizie conformitate continuitate cost creativitate curente detaliere adecvat dinamism domeniu expansibilitate fr erori fiabilitate

finalitate format imparialitate integrabilitate interesante manevrabilitate minimalitate nivel de abstractizare noutate optimalitate partiionabilitate pertinente precise rspunde cerinelor regsire relevan responsabilitate rigiditate secrete sincronizare stocare translatare uurin acces uurin corelaii uurin interogare uurin modificare validitate varietate vitez

flexibilitate generalitate importan integritate interpretare semantic msurabilitate modularitate nivel de standardizare obiectivitate organizare pedigree portabile prietenoase raionalitate regularitate format reproductibilitate rezisten robustee securitate specificitate suprancrcare transportabilitate uurin actualizare uurin folosire uurin interschimb uurin regsire valoare vrst volatilitate

form prezentare ierarhizare independen de timp interactivitate localizare mediu neambiguitate normalizare oportunitate origine personalizate posibilitate de urmrire profunzime redundan reiterare reputaie rezoluie grafic scop semnificaie stabilitate surse unicitate uurin comparaii uurin nelegere uurin ntreinere utilizabilitate variabilitate verificabilitate volum adecvat

Dintre aceste atribute se extrag unele care sunt considerate de baz, se stabilesc interdependene i rezult prioriti care trebuie urmrite cnd 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 comparaii. Punerea n coresponden se realizeaz prin utilizarea metricilor. Dimensiunea colectivitii CVIi este dat de numrul componentelor NCVIi care o alctuiesc. Dinamica proceselor economico-sociale impune o abordare mai larg a conceptului de dimensiune. Astfel, sunt analizate modalitile de constituire a colectivitii CVIi i se stabilete NCVIMAXi: numrul maxim de componente pe care le-a avut mulimea CVIi ntr-un interval de timp [t0, t1], NCVIMINi numrul minim de elemente, referitoare

la acelai interval i NCVIMEDi numrul mediu de elemante. Aceste mrimi 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 colectivitii CVIi este invariabil pe intervale lungi de timp. Setul de date asociat colectivitii este caracterizat prin volumul V(STi). Setul de date este privit ca un text format din cuvinte. Numrul de cuvinte depinde de numrul de coloane i de numrul de linii ale tabloului Ti asociat colectivitii CVIi. V(STi) = NLINi NCOLi, i = 1, 2, ..., n n cazul n care setul de date este incomplet, lipsind datele unor coloane ntregi n numr de COLi, sau numr de linii complete LINi, rezult c volumul incomplet de date este dat de relaia: VI(STi) = (LINNi - LINi) (NCOLi - COLi ) Se definete relaia: V(STi) > VI(STi) n cazul n care lipsa de date este accidental, numrul de date lips pe linii sau coloane este LCi, volumul afectat de aceste absene este dat de relaia: VA(STi) = NLINi NCOLi - LCi Indiferent de modul n care se constituie seturile de date, este necesar ca diferenele dintre volumul de date complet i volumul incomplet, D1, respectiv D2, s traverseze evoluii astfel nct ntr-un numr finit de pai s devin zero. Datele absente trebuie s fie completate nainte de a ncepe prelucrarea setului de date. D1i = V (STi ) VI (STi )

i D2 = V (STi ) VA(STi )

Gradul de acoperire a setulul de date Ga este dat de relaia:

Ga = V (STi ), VA(STi )} min{ V (STi ), VA(STi )} max{

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 definiiile trebuind s conduc la obinerea unor valori calculate, cuprinse n intervalul [0;1]; - senzitivitatea indicatorilor, n sensul c la variaii mici ale variabilelor exogene, indicatorul calculat s aib variaii mici, iar la variaii mari ale variabilelor exogene, indicatorul s aib, de asemenea, variaii mari; - indicatorul s nu fie compensatoriu, astfel nct pentru diferite valori ale variabilelor exogene s se obin valori diferite ale indicatorului; dac indicatorul este compensatoriu, la valori diferite ale variabilelor exogene se obin aceleai valori ale indicatorului; - indicatorul nu trebuie s fie catastrofic, adic trebuie s fie construit n aa fel nct s nu existe niveluri ale variabilelor exogene care pentru variaii foarte mici s genereze variaii foarte mari ale indicatorului; - toi indicatorii se calculeaz folosind datele din tabloul Ti construit pentru colectivitatea CVIi, i = 1, 2, ..., n; - folosind datele indicatorilor asociai caracteristicilor de calitate CQ1, CQ2, ..., CQMi, respectiv IQ1, IQ2, ..., IQMi i coeficienii de importan p1, p2, ..., pMi, se obine indicatorul global al calitii pentru colectivitatea dat de relaia: G = (IQ j ) , i = 1, 2, ..., n
i q Mi j =1 pj

Complexitatea datelor care privesc o colectivitate Ai este dat de: - operanzii care particip n elaborarea prelucrrilor; - operatorii utilizai.

Dac se consider datele din tabelul 9.17, pentru calculul valorii Via a produsului PRODi se folosete relaia , i = 1, 2, ..., r.
Date privind producia i preurile
Produs PRODi PROD2
-

Cantitate Q1 Q2
-

Tabelul 9.17 Pre PR1 PR2

-

PRODr

Qr

PRr

Complexitatea operanzilor i a operatorilor rezult din secvena de program asociat prelucrrii: (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 colectivitii Ai este dat de relaia: K DIVi = , Mi unde K reprezint numrul tipurilor de date diferite: Se consider urmtoarele tipuri de date: - coduri date ca iruri de caractere; - indicatori exprimai ca numere ntregi; - indicatori exprimai ca iruri de litere; - indicatori exprimai prin numere virgul mobil; - indicatori exprimai prin cuvinte dintr-o mulime cunoscut.

ntr-un tabel n care sunt consemnate pe coloane cantitile livrate ntr-o lun, iar pe linii sunt date produse, tabelul va conine 31 de coloane pentru cantiti, toate date ca numere ntregi, trei coloane pentru denumirea produsului, codul produsului i pentru unitatea de msur, diversitatea tipurilor de date este:

DIV =

4 34

Mi = 34, tabelul avnd 31 coloane pentru cantiti i 3 coloane pentru identificare produs. K = 4, corespunztor tipului de date pentru cod produs, denumire produs, unitate de msur i cantiti; codurile sunt structuri de simboluri care ajut la identificarea produsului; denumirea produsului este un ir de litere; unitatea de msur este un cuvnt din mulimea {l, kg, t, m, m2, m3}. Gradul de omogenitate GOij a datelor din setul asociat colectivitii Ai, aparinnd caracteristicii de difereniere C ij , se obine prin relaia:

GOij =

a
k =1

Ni

i kj

i i min a kj max aij k k

{ }
i kj

{ }

a
k =1

Ni

Dac se consider caracteristica de difereniere C ij , definit de un domeniu definit prin nivelurile A ij ; B j i cu A ij < B ij , avnd nregistrate
i i valorile a1i j , a 2 j , ..., a Nij , gradul de omogenitate se obine prin relaia:

GO =
i j

i i max a kj min a kj k k

{ }

{ }

B j Aj

Obiectivul auditului datelor este de a stabili msura n care datele de intrare ale unui produs software ndeplinesc cerinele de calitate pentru a fi prelucrate.

Programul de audit date este o construcie 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 msurtori sunt calibrate i ndeplinesc cerinele 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 colectivitii prin neincluderea unui cod, prin interschimbul a dou coduri; - nivelurile unor caracteristici care sunt n afara domeniilor, ceea ce nseamn afectarea grosolan a msurtorilor; repetarea nivelurilor nregistrate pentru un element al mulimii la alte elemente nvecinate; - nregistrarea nivelului caracteristicii C ij n dreptul caracteristicii nvecinate C ij 1 sau C ij +1 ; i fie nregistrarea nivelului caracteristicii C ij a elementului a k
i corespunztor elementului a k 1 , fie corespunztor elementului

i ak +1 ; interpretarea greit a simbolurilor din alfabetul n care este scris irul la intersecia coloanei COL j cu linia LIN k ;

transformarea irului de la intersecia coloanei COL j i a liniei LIN k prin inserarea unui simbol, prin eliminarea unui simbol sau prin nlocuirea unui simbol cu altul; irul transformat rmne n domeniul stabilit pentru caracteristica C ij ;

transformarea irului de la intersecia liniei LIN k i a coloanei COL j , astfel nct s aparin unei alte clase sau unui alt domeniu;

modificarea dimensiunilor tabloului Ti prin inserarea de noi caracteristici, prin eliminarea de caracteristici de difereniere sau prin modificarea numrului de componente N o ale colectivitii Ai .

Auditul datelor are menirea de a stabili: - conformitatea caracteristicilor de calitate ale setului de date STi colectate, prin msurtori sau constatri la nivelul elementelor mulimii Ai , n raport cu cerinele beneficiarului, specificate concret prin referirea la standarde, norme i prin documentaii special ntocmite; - eficacitatea msurilor care asigur caliti referitoare la datele colectate; - identificarea msurilor de asigurare a calitii 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 stabilete difereniat, dup importana dat documentelor.

10. RAPORTUL DE AUDITARE

Procesul de auditare se finalizeaz cu ntocmirea unui raport care conine propuneri de msuri de reducere i de meninere sub control a riscurilor importante ale noii aplicaii. Raportul de auditare este o lucrare de sintez care are la baz o analiz a rezultatelor obinute din parcurgerea textelor surs, din lansarea n execuie a programelor i din interpretarea rezultatelor finale, mai ales prin interpretarea rezultatelor intermediare i a celor de urmrire a programului. Raportul de audit este o lucrare cuprinztoare care ofer o imagine privind sigurana pe care o d produsul. Raportul de audit are un rol esenial n angajamentele de audit i asigurare, deoarece comunic verdictul auditorului. Utilizatorii sistemului informatic se ateapt ca raportul auditorului s ofere ncredere n utilizarea sistemului informatic. Raportul de audit este un element fundamental al auditrii prin intermediul cruia se prezint situaia sistemului auditat aa cum a fost evaluat de auditori. Prin raportul de audit sunt communicate, prii 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 redomandri utile referitor la perfecionarea procedurilor de control i eficiena activitii operative; - s asigure o nregistrare oficial a activitii de audit i a rspunsului managerilor. n practic, nainte de a prezenta un raport formal, n scris, auditorul are obligaia de a prezenta un raport verbal celor care rspund de activitatea analizat. Cu excepia cazurilor de fraud, cnd este necesar uneori ca lucrurile s rmn secrete pn la prezentarea raportului oficial, n majoritatea cazurilor auditorul discut, n prealabil, cu managerul coninutul raportului de audit. n acest fel se reduce riscul ca rezultatele auditului s nu fie acceptate de ctre manager.

Raportul de auditare este un text structurat care conine: - prezentarea contextului; - rezultatul procesului de auditare; - evalurile finale; - nregistrrile din fiecare etap a procesului de auditare. Raportul de auditare conine detalii privind: - descrierea produsului; - stabilirea condiiilor de utilizare normal; - operaiile interzise a fi efectuate folosind produsul; - funciunile pe care le dezvolt n condiii normale, indicnd intrrile, respectiv output-urile; - efectele secundare care apar atunci cnd intrrile sunt complete i corecte; - riscurile care apar atunci cnd intrrile sunt incomplete i incorecte; - modaliti de reluare a procedurilor de utilizare. Raportul de auditare arat c produsul este utilizabil sau produsul devine utilizabil dac se execut o serie de mbuntiri. Raportul de auditare trebuie astfel ntocmit astfel nct 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 alctuiete pas cu pas prin rspunsuri scurte i clare la ntrebrile: cine? ce? cum? de ce? Este obligatoriu ca raporul s includ seciuni care abordeaz gradat problematica de audit pentru un sistem informatic. Prima seciune include elemente de identificare pentru: - sistemul informatic ce face obiectul auditrii; - baza n care se deruleaz procesul de auditare; - prezentarea echipei de auditori; - prezentarea elaboratorilor sistemului informatic; - prezentarea beneficiarului procesului de auditare. A doua seciune include elemente pentru: - definirea obiectivului urmrit; - stabilirea metodelor i tehnicilor stabilite i acceptate; - structurarea procesului de auditare.

A treia seciune definete planul de auditare i conine descrieri pentru: etapele care trebuie parcurse; resursele alocate fiecrei etape: fluxurile care se genereaz; nivelul de exigen i moduri de meninere constant a nivelului; comunicarea ntre membrii echipei de auditori, comunicarea auditorilor cu realizatorii sistemului informatic, cumunicarea cu beneficiarii procesului de auditare. A patra seciune conine detalierea tuturor surselor utilizate ca ntrebri pentru procesul de auditare: - contracte; - specificaii; - proiectul sistemului informatic; - textele surs; - bazele de date; - rezultatele testrii efectuate de echipa care a elaborat sistemul informatic; - documentaii de proces; - instrumente utilizate de ctre echipa care a dezvoltat sistemul informatic. Sunt descrise listele elementelor utilizate cu comentarii privind calitatea textelor ntrebuinate de auditori. Raportul de audit trebuie s fie clar, concis, constructiv i ntocmit la timp. Raportul de auditare reprezint o prob important n orice aciune declanat de beneficiarul unui sistem informatic atunci cnd sunt nregistrate diferene 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 interpretri. Cnd se utilizeaz sintagma <<toate variantele>> nseamn c pentru cele n noduri terminale ale unei structuri arborescente au fost construite n seturi de date test, atingndu-se cele n noduri terminale. Pentru a nu lsa loc interpretrilor, din enunul raportului lipsesc sintagme precum <<n majoritatea cazurilor>>, <<n general>>, <<numai n unele cazuri>>, <<n celelalte situaii>>, <<nu de puine ori>>, <<este -

probabil s>>, <<exist posibilitatea ca>> i toate celelalte construcii care conduc la concluzii vagi. Raportul de auditare: - enumer toate componentele; - analizeaz toate variantele; - include toate rezultatele; - enumer situaiile pe categorii de stri, fr a lsa unele situaii neclarificate; - trateaz cu aceeai msur toate componentele; - pentru fiecare situaie creat se enumer componentele identificate; - utilizeaz pentru componentele aceluiai nivel, aceleai instrumente; - este o construcie consistent; - include ipoteze, constatri, msurtori care, prin profesionalismul cu care se realizeaz, nu au fundamente pentru a fi contestate. Transparena procesului de auditare, rigurozitatea cu care sunt aplicate cerinele standardelor i claritatea cu care se prezint rezultatul auditrii d o singur direcie destinaiei raportului i anume acceptarea concluziilor, indiferent care sunt acestea, de ctre cel care a solicitat auditul sistemului informatic. Raportul de auditare trebuie s fie convingtor pentru a nu face obiectul comentariilor. Trebuie s conin descrierea unor aspecte evidente care nu fac obiectul comentariilor sau negocierilor. Structura anunat trebuie respectat, iar textul trebuie s fie consistent. O afirmaie fcut trebuie cel mult susinut. Ea nu trebuie nici nuanat, cu att mai mult nu trebuie contrazis. Este determinant pentru un raport de auditare s fie calitativ peste nivelul documentaiei, specificaiilor sau oricrui 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.

11. CONCLUZII
Auditul informatic reprezint o ramur distinct a auditului. Aici se includ tehnici i metode de auditare a software, a aplicaiilor informatice, a sistemelor informatice tradiionale, a sistemelor informatice moderne, a aplicaiilor mobile i a tuturor aplicaiilor informatice care utilizeaz resurse Internet. Pe msura creterii complexitii proceselor din societatea informaional, cerinele sistemelor informatice impun un nivel de credibilitate deosebit de ridicat pe care numai auditul informatic l susine cu succes. Pe timpul planificrii auditului informatic exist factori care se iau, n mod obligatoriu, n considerare; aceti 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 conformitii i auditul operaional. Realizarea auditului sistemului informatic contribuie la: - mbuntirea sistemului i controalelor procesului; - prevenirea i detectarea erorilor i a fraudelor; - reducerea riscurilor i mbuntirea securitii sistemului; - planificarea pentru refacere n caz de accidente i dezastre; - managementul informaiilor i dezvoltrii sistemului; - evaluarea utilizrii eficiente a resurselor. Auditorul sistemelor informatice trebuie s aib capacitatea de a asista echipa managerial n stabilirea mrimii sistemului informatic i a numrului de personal necesar, domeniile de afaceri n care se utilizeaz eficient sistemele de calcul, natura afacerilor, pierderi poteniale n cazul cderii sistemului informatic, extinderea controalelor manuale i gradul de complexitate tehnic. Auditul sistemelor informatice este o activitate complex. Unei activiti de echip realizarea sistemului informatic i corespunde, de

asemenea, tot o activitate de echip auditarea. Pentru a realiza un proces de auditare eficient este necesar s se parcurg urmtorii pai: - definirea obiectului auditrii sistemului informatic; - construirea planului de auditare; - atribuirea sarcinilor fiecrui membru din echipa de auditori; - preluarea structurilor de tabele pentru nregistrarea rezultatelor auditrii; - derularea, pas cu pas, a procesului de auditare folosind standarde, tehnici i metode stabilite; - nregistrarea rezultatelor i evaluarea fiecrei etape parcurse; - regruparea documentaiei provenite din diferite stadi ale procesului de auditare i construirea raportului final. Exist dou rezultate pentru un produs supus auditrii. Primul caz, cel nefavorabil, corespunde situaiei n care procesul de auditare conduce la concluzia c exist diferene eseniale ntre sistemul informatic real i sistemul informatic ateptat de utilizator; sistemul informatic nu execut integral funciile de prelucrare stabilite; rapoartele obinute sunt numai o parte din cele stabilite; auditorii recomand completarea cu noi module care s dezvolte i prelucrrile planificate, dar nerealizate; diferenele care apar sunt cauzate de rezultatele incomplete din raport; se recomand completarea cu module care aduc rapoartele la nivelul de completitudine necesar; diferenele se refer la modul de calcul al indicatorilor; se recomand modificri n secvenele 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 arborescenei asociate sistemului informatic cerinele de modificare cerute n raportul de auditare au o profunzime mai mare. n toate cazurile se precizeaz care sunt diferenele i se stabilete necesitatea de a fi eliminate sau atenuate. Auditul nu d soluii. 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 dispoziie un document prin care dac prezint trunchiat informaia, las s se neleag c sistemul informatic a fost auditat. Dac se prezint rezultatul negativ al auditrii, se subnelege 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 modificrilor, n software, n bazele de date, se reia procesul de auditare i raportul de constatare se

transform n raport de auditare i se elibereaz un certificat de ctre auditor, prin care se recunosc calitile sistemului informatic, iar utilizatorii trebuie s aib ncredere n sistemul informatic auditat. n cel de al doilea caz, favorabil, diferenele dintre ceea ce s-a ateptat de ctre utilizator i ceea ce s-a realizat sunt nesemnificative sau sunt favorabile creterii calitii produsului. Raportul de auditare este o construcie complex, dezvoltat de membrii echipei de auditare. Asemenea unei cri organizate pe capitole, este o construcie arborescent. Fiecare nod al arborescenei are o informaie cu structur standard: - obiectiv; - input-uri, output-uri; - coninut, prelucrri; - nregistrare rezultat analiz; - evaluare proces; - concluzii, calificare. Agregarea se realizeaz de la baz spre rdcina structurii arborescente. Raportul de auditare este o construcie de maxim detaliere. Modul de abordare expus arat clar care este diferena ntre alte activiti i audit. Se observ clar c auditul are ca rezultat o analiz, o serie de evaluri i evidenierea cu maxim rigurozitate a diferenelor dintre sistemul informatic solicitat de utilizator i descris n specificaiile 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 obine acele informaii care dau ncredere n utilizare, certitudinea c rezultatele ateptate sunt corecte, complete, exact n structura solicitat i se obin n timp real. Auditarea are menirea de a transfera certitudine i ncredere n sistemul informatic prin rezultatul pozitiv stabilit de ctre o echip de auditori, aparinnd unei firme de consultan cu autoritatea dat de auditri anterioare. Managementul auditrii are particulariti specifice legate n principal de capacitatea auditorilor de a nva proceduri i, mai ales, de a aplica aceste proceduri n mod unitar. Orice manifestare spontan sau de orgoliu aduce diferenieri de abordare care se concretizeaz prin discrepane n a alege modele, n a culege date. Se reduce n acest fel comparabilitatea datelor, iar agregarea

datelor se reduce pn la imposibilitatea de a opera cu seturi de date care privesc componentele aparinnd aceleiai clase. Auditul unui sistem informatic presupune un volum important de munc ntruct se reface ntregul traseu parcurs de echipa de realizatori a sistemului i, chiar mai mult, ntruct intr n analiz nsi specificaiile cu sursele pe baza crora au fost construite. Efectul imediat al auditului sistemului informatic este folosirea lui cu ncredere dac rezultatul auditrii ofer aceast ncredere. Pentru echipa de dezvoltare a sistemului informatic, dac a trecut de testul auditrii, se creeaz condiii favorabile dezvoltrii de noi sisteme informatice, mult mai complexe. n cazul n care sistemul informatic nu a trecut testul auditrii, apar serioase semne de ntrebare legate de managementul companiei de software care a dezvoltat un astfel de sistem. Trebuie s apar schimbri 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, cnd genereaz erori, compania care utilizeaz s plteasc toate daunele. Lipsa auditului nseamn riscuri asumate. Riscurile nseamn costuri i costurile trebuie suportate de ctre cel care i-a asumat riscurile la un nivel care depete limite raionale. Auditul este un proces opional pn la un punct. n condiiile software public, n care ceteanul dezvolt procese de prelucrare n interes propriu, auditul devine o necesitate, devenind obligatoriu. Obligativitatea este o msur de autoconservare a companiei care utilizeaz software public pentru a derula servicii spre ceteni cu resurse proprii pentru a satisface cerine ale cetenilor. O astfel de organizaie nu trebuie s rite. Auditul nseamn transfer de ncredere i meninerea riscurilor la niveluri suportabile cu asigurarea unui nivel bun al profitabilitii. n condiiile societii informaionale, 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 auditrii permite conectarea. n caz contrar, efectele de antrenare multipl la nivelul riscurilor devin de necontrolat.

Societatea informaional dezvolt o nou atitudine fa de audit. l consider un element esenial pentru construirea de arhitecturi software complexe de utilitate public n regim continuu i fr asisten. Crearea civilizaiei bazat pe informaie obinut interactiv pleac de la ideea completitudinii i corectitudinii obinerii informaiei. 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 msurtori i ntregul demers trebuie susinut cu calcule de eficien. Auditul trebuie privit ca o investiie suplimentar. Compania de software care dezvolt un sistem informatic i deruleaz procedee de audit creeaz premisele autoproteciei fa de riscurile generatoare de cheltuieli ce depesc potenialul companiei. Se creeaz o nou atitudine fa de auditul sistemelor informatice, fiind considerat altceva dect o activitate impus sau un ru necesar, transformndu-se n singura modalitate prin care se obin garanii reale asupra calitii 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 ndeplinete toate sarcinile cerute la cel mai ridicat grad posibil de eficien i eficacitate. Creterea organizaiei, creterea volumului afacerilor, schimbrile n mediul afacerilor, schimbrile tehnologice i noile cerine de informaii toate plaseaz o cerere crescnd asupra sistemului informatic existent i adeseori impun modificarea sau extinderea acestuia pe baze ad-hoc. Exemple ale unui audit de SI aflat n funciune: - reevaluarea cerinelor de informaii; - verificarea modificrilor propuse la proiectrile de baz existente; - investigarea oportunitii noilor tehnologii; - mbuntirea procedurilor de operare. Din practic s-a constatat necesitatea auditarii unui sistem informatic odat la trei ani sau ori de cte ori schimbrile aprute o impun.

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., Noca 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 aplicaii n reea, Teza de doctorat, Bucureti, ASE, 2000 [AREN03] Arens, A. A., Loebbecke, J. K., Elder, R. J., Beasley, M. S.: Audit o abordare integral, Ediia a 8-a, Bucureti, Editura ARC, 2003 [ARHI00] Arhire, R.: Evaluarea complexitii sistemelor de programe, Tez de doctorat, Bucureti, ASE, 2000. [AVRA97] Avram, G.: Auditul sistemelor informaionale, Referat tez de doctorat, Bucureti, ASE, 1997 [AVRA01] Avram, G.: Instrumente de evaluare a sistemelor informaionale economice, Tez de doctorat, Bucureti, 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

[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 calitii sistemelor de programe, Teza de doctorat, Bucureti, ASE, 1994 [BARO04] Baron, A. M.: Tehnici i metode utilizate n auditul calitii software, Lucrare de disertaie, Curs de master: Managementul informatizat al proiectelor, Bucureti, ASE, Facultatea CSIE, 2004 [BLA99] Blaa, L.: Evaluarea sistemelor de asigurare a calitii asistate de calculator, Lucrare de licen, Bucureti, ASE, Facultatea CSIE, 1999 [BRN04] Brnda, C.: Auditul sistemelor informatice de gestiune, note de curs, Timioara, Facultatea de tiine Economice, Universitatea de Vest, 2004 [CAPI01a] Capisizu, S.: Caracteristicile de calitate a datelor, Referat doctorat, Bucureti, ASE, ianuarie 2001 [CAPI01b] Capisizu, S.: Cerinele auditului informaiei economice, Referat doctorat, Bucureti, ASE, octombrie 2001 [CAPI02] Capisizu, S.: Metode de structurare i realizare a auditului de date, Referat doctorat, Bucureti, ASE, iulie 2002 [CAZA04] Cazan, D.: Metrici de calitate pentru sisteme informatice, Referat doctorat, Bucureti, ASE, Facultatea CSIE, 2004 [CAZA05] Cazan, D.: Validarea modelelor de evaluare a calitii sistemelor informatice, Referat doctorat, Bucureti, ASE, Facultatea CSIE, 2004 [EBEN98] Eben, R. G., Strauss, S. H.: Software Inspection Process, Mc Graw Hill Inc, New York, 1998

[GHIL04] Ghilic-Micu, B, Stoica, M.: Organizaia virtual, Bucureti, 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 performanei programelor COBOL, Bucureti, 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), Bucureti, 1988, p. 21 31 [IVAN96b] Ivan, I., Noca, Gh., Prlog, A.: Asigurarea calitii datelor, Bucureti, Revista Asigurarea calitii, Numrul 8, 1996, p. 8-15 [IVAN97a] Ivan, I., Sinioros, P., Popescu, M., Simion, F.: Mertici Software, Bucureti, Editura INFOREC, 1997 [IVAN97b] Ivan, I, Capizisu, S., Noca, 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., Noca, Gh., Oprea, P., Prlog, O.: Data Metrics, Proceedins of The 1998 Conference on Information Quality, Cambridge, Massachusetts, USA, p. 215-231 [IVAN99a] Ivan, I., Noca, Gh., Tcaciuc, S., Prlog, O., Cciul, R.: Calitatea datelor, Bucureti, Editura INFOREC, 1999 [IVAN99b] Ivan, I., Pocatilu, P.: Testarea software orientat obiect, Bucureti, 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

[IVAN01] Ivan, I., Teodorescu, L.: Managementul calitii software, Bucureti, Editura INFOREC, 2001 [IVAN03a] Ivan, I., Toma, C.: Aplicaii 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 Romn de Informatic i Automatic, vol. 13, nr. 1, 2003, p. 28 31 [IVAN03c] Ivan, I.: Managementul calitii proiectelor software, Proceedings of the International Conference Trends in the Development of the Information and Communication Technologies in Education and Management, Chiinu, 20 21 martie 2003, p. 25 30 [IVAN03d] Ivan, I., Apostol, C., Pocatilu, P., Popa, M.: Certificarea aplicaiilor Internet, Sesiunea de Comunicri tiinifice a Cadrelor Didactice, Bucureti, Universitatea RomnoAmerican, 23 24 mai 2003 [IVAN03e] Ivan, I., Toma, C.: Testarea interfeelor om-calculator, Revista Romn 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, Bucureti, 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, Bucureti, 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, Bucureti, 2003, p. 223 235

[IVAN03i] Ivan, I., Pocatilu, P., Popa, M, Mihai, T., Ivan, L.: Data Orthogonality, Master of International Business Informatics Handbook, Bucureti, Editura ASE, 2003, p. 235 249 [IVAN03j] Ivan, I., Toma, C.: Management of Tutorial Process Quality in Business Informatics Programs, lucrare prezentat n workshop internaional Actual Problems of Business Informatics in BRIE Master Program, 13-14 decembrie 2003, Giurgiu [IVAN03k] Ivan, I., Rdulecu, I.: Caracteristici de calitate ale aplicaiilor software, Revista NET Report [IVAN03z] Ivan, I., Mijache, L.: Design Patterns Cale de cretere a fiabilitii software, Revista NET Report [IVAN04a] Ivan, I., Boja, C.: Metode statistice n analiza software, Bucureti, Editura ASE, 2004 [IVAN04b] Ivan, I., Noca, 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., Noca, Gh., Popa, M.: Reele de cercetare privind dezvoltarea sistemelor informatice de management bazat pe cunotine destinate ntreprinderilor mici i mijlocii Studii i Cercetari de Calcul Economic i Cibernetic Economic, vol. 39, nr. 1, 2005. [MUNT01] Munteanu, A.: Auditul sistemelor informaionale contabile cadru general, Bucureti, Editura POLIROM, 2001 [NOC98] Noca, Gh., Prlog, A.: Calitate i cost n managementul software, Revista Informatica Economic nr. 4, 1998, ASE, INFOREC [NOC03] Noca, Gh.: Optimizarea costurilor calitii produselor program, Tez de doctorat, Bucureti, ASE, Facultatea CSIE, 2003

[POCA04] Pocatilu, P.: Costul testrii software, Bucureti, Editura ASE, 2004 [STOI03a] Stoica, M.: Proiectarea sistemului de management al calitii n organizaiile virtuale, Revista Informatica Economic, nr. 1(25)/2003, Bucureti, Editura Inforec, 2003, p. 34-38 [STOI03b] Stoica, M.: Proiectarea procedurilor de asigurare a calitii pentru sistemul de management al calitii n organizaia virtual, Revista Informatica Economic, nr. 2(26)/2003, Bucureti, Editura Inforec, 2003, p. 21-27 [STOI03c] Stoica, M.: Particulariti ale sistemelor informaionale norganizaia virtual, n volumul Simpozionului Naional Tinerii economiti i provocrile viitorului, Craiova, 31 oct. 1 nov. 2003, p. 313-318

[STOI04a] Stoica, M.: Msuri propuse de Uniunea European pentru exploatarea sectorului public de informaii, n Revista Tinerilor Economiti, 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 Internaional InfoBUSINESS2004 Innovative Applications of Information Technologies in Business and Management, Publishing House Iai, oct. 2004, p. 107 110

[STOI04d] Stoica, M.: Strategia de cercetare i dezvoltare tehnologic n domeniul tehnologiilor informaionale i de comunicaii n perspectiva integrrii n Spaiul de Cercetare European, n cadrul PNCDI CERES, Consoriu de cercetare ICI-IFIN-ASEUB-UPB, Bucureti, 2004 [STOI05] Stoica, M.: Dezvoltarea sistemelor informaionale economice.Concepte i aplicaii, Bucureti, Editura ASE, 2005 (n curs de apariie) [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.

[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, SpringerVerlag 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, Bucureti, 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

Anexa 1

Lista de variabile
Variabila Acti aij Ann bij Bmn Cdif COji COji COLi CPRi CQ CQDi CSI CVi CVI D DA DA(Pi, Pj) DINTk Ei Eti Ev FACT jj Fi fr Ga GA(X,Y) GAA GDFj H(aij) H(aij, aik) ISS Ius KG Explicaia Activitatea i Element al matricei Ann Matricea de coresponden pentru module Element al matricei Bnn Matricea relaiei modul date. Caracteristic de difereniere Element al matricei de coresponden operaii-parole Element al matricei de coresponden operaii clase de parole Coloana i Clasa i de parole Caracteristic de calitate Caracteristica i de calitate a datelor Complexitatea sistemului informatic, n sens Halstead Criteriul i de validare Colectivitate de elemente Durata de realizare a unui sistem informatic Indicator de asemnare a dou programe Indicator de asemnare a programelor Pi i Pj Date de intrare de la nivelul k Entitatea i Etapa i din cadrul unui proces Eveniment Factorul ij Funcia i Frecven de apariie Gradul de acoperire a setulul de date Gradul de asemnare a matricelor X i Z Indicatorul grad de asemnare agregat Gradul de definire a listei i a factorilor Ortogonalitatea global a elementului aij n raport cu celelalte elemente Ortogonalitatea elementelor aij i aik Indicator al utilizrii surselor Numrul de aspecte din proiectul sistemului informatic care au fost supuse analizei

Variabila Li LINF LINi LSUP MCdif MFS mfsij MOD MODi, MOi NCA Ncuv NCV NCVI ne NeCVI NF NFUN NIN NINIj NINOj NMAXi NMD NMD NMEDi NMINi NOU NOU NOUT NPR Nrd Nrm NrPRODi NrSi ns NSi NSO NSS NTF NUZ O OUi

Explicaia Lista i Limit inferioar Linia i Limit superioar Numr caracteristici de difereniere Matricea coresponden funcii-subsisteme Element al matricei MFS Modul de date Modulul i de date Componenta sau modulul i din structura unui sistem informatic Numr proceduri de calcul Numr de cuvinte Numrul criteriilor de validare Numr de colectiviti Numrul elementelor din list Numr de elemente al unei colectiviti Numrul factorilor Numrul de funcii Numr de proceduri cae asigur operaii de intrare Numrul de variabile de intrare ale subsistemului SSj Numrul de variabile rezultative ale subsistemului SSj Numrul maxim de elemente din intervalul i Numrul modulelor de date Numr module de date Numrul mediu de elemente din intervalul i Numrul minim de elemente din intervalul i Numr operaii utilizator Numr de operaii effectuate de utilizatori Numr de proceduri de stocare sau de afiare a rezultatelor Numr de parole Numrul total al referirilor de date de ctre module Numrul total al referirilor de module Numrul de proceduri i Numr de iruri Numrul salariailor Numrul de iruri i Numrul de subobiective Numrul de subsisteme Numrul de tipuri fundamentale de date Numr de utilizatori Obiectiv Operaia i efectuat de ctre utilizatori

Variabila OUi Pi Pi PROB PROCAi PRODi PROG PROINi PROUTi

j qik

Explicaia Operaia i efectuat de utilizatori Coeficientul i de importan Programul i Problem Procedura i de calculNCA Produsul i Program Procedura care asigur operaiile de intrare Procedura i de stocare sau de afiare a rezultatelor Element din matricea output/indicatori pentru subsistemul SSj Rezultatele de la nivelul k Raportul i Rezultat intermediar Element din matricea output/inputuri ir de cuvinte Sevena i dintr-un program Subobiectivul i Subproblema i. Subsistemul i Structura j Tipul fundamental de date i Tipul fundamental de date i Tipul fundamental de date j Tabloul i cu TCOLi i TLINi Element al matricei de coresponden utilizatori clas de parole Tipul i de utilizatori Volumul setului de date asociat colectivitii i Variabila i Productivitatea a celor care elaboreaz un sistem informatic Numrul componentelor pentru care au fost introduse date Numrul componentelor colectivitii CVI pentru care au fost introduse date Nivelul cmpului cu poziia j pentru ablonul de descriere aparinnd elementului k din entitatea Ei Element din matricea de utilizare a input-urilor

REZk Ri RINT

rikj
Scuv Si SOi SPROBi SSi Strj TFDi TFDi TFj Ti UCji UZi V(STi) VARI W XCVI XeCVI xijk
j wik

Anexa 2

Lista de figuri
Numr figur Figura 5.1 Figura 5.2 Figura 5.3 Figura 5.4 Figura 5.5 Figura 5.6 Figura 6.1 Figura 6.2 Figura 6.3 Figura 6.10 Figura 6.11 Figura 7.1 Figura 8.1 Figura 8.2 Figura 8.3 Figura 8.4 Figura 8.5 Figura 8.6 Figura 8.7 Figura 8.8 Figura 8.9 Figura 8.10 Figura 8.11 Figura 8.12 Figura 8.13 Denumirea Etapele ciclului de auditare a sistemului informatic Lista de activiti Ai a etapei Ei Dezvoltarea structurat pe etape a ciclului de realizare a sistemului Sinteza rapoartelor de detaliu pe baz de list Schema de auditare, ca list de liste Rapoartele de auditare, ca informaii utile ale listelor de liste Concordana dintre stuctur i subobiective Concordana dintre stuctur i subobiective Derivarea indicatorilor din subobiective Transformarea output-urilor n input-uri Transformarea unui output n input multiplu Structura ierarhizat a indicatorilor Analiz top down Analiz bottom - up Analiz fluxurilor de interacine ale modulului mijlociu Structur liniar de module Structur liniar cu cinci module Secven de structur arborescent de module Secven de structur arborescent de module Structura global a unei proceduri Compararea rezultatelor intermediare Secvene de instrucini n procedur Structur software cu proceduri grupate Structur software cu gruparea procedurilor spre finaliti complete Concordana datelor de test

Anexa 3

Lista de tabele
Numr tabel Tabelul 6.1 Tabelul 6.2 Tabelul 6.3 Tabelul 6.4 Tabelul 6.5 Tabelul 6.6 Tabelul 6.7 Tabelul 6.8 Tabelul 6.9 Tabelul 7.10 Tabelul 7.11 Tabelul 8.12 Tabelul 8.13 Tabelul 8.14 Tabelul 9.15 Tabelul 9.16 Tabelul 9.17 Denumire tabel Structura listei de descriere tip, clas sau grup Legtura funcii/subsisteme Legturi multiple funcii/subsisteme Utilizarea input-urilor n indicatori Utilizarea output-urilor n indicatori Utilizarea input-urilor pentru obinerea outputurilor Utilizarea input-urilor n indicatori Utilizarea output-urilor n indicatori Utilizarea input-urilor pentru obinerea outputurilor Corespondena utilizatori/parole Corespondena operaii/parole Utilizarea variabilelor transmise Utilizarea variabilelor n module Transmiterea de parametri Criteriile standard de validare pentru tipurile fundamentale de date Atribute ale calitii datelor Date privind producia i preurile

Anexa 4

Lista de verificare (Checklist) pentru specificaiile funcionale

Organizarea i completitudinea proceselor o Se verific dac sunt definite toate tabelele de coresponden cu cerinele funcionale ale sistemului informatic. o Se analizeaz dac sunt sapecificate toate cerinele beneficiarilor la nivel de detaliu cu aceeai consisten i nivel de adecvare. o Se stabilete msura n care cerinele definite furnizeaz informaiile necesare i suficiente pentru derularea proceselor specifice etapei de proiectare.

o Se stabilete concordana ntre prioritile utilizatorului i cele ale elaboratorului, n vederea unui proces corect i complet de implementare. o Se verific dac toate interfeele hardware, software i de comunicaie au fost complet i consistent definite i dac exist elemente redundante. o Se verific dac sunt definii toi algoritmii intrinseci pentru cerinele funcionale ale fiecrei 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 situaiile care genereaz erori sau toleran la erori. Corectitudinea derulrii 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 ambiguiti i urmeaz o abordare de la simplu ctre complex, urmnd logica derulrii proceselor specifice etapelor din ciclul de dezvoltare a sistemului informatic. o Se stabilete msura n care fiecare cerin inclus n specificaiile sistemului informatic este verificabil prin testare, revizie, prezentare sau analiz. o Se analizeaz dac fiecare cerin este descris concis, coerent, fr erori gramaticale i pe neles, folosind construcii simple, fr paranteze i fr elemente de precauiune care mresc ambiguitatea sensurilor. o Se verific msura n care unele informaii lipsesc sau dac unele cerine se repet sau sunt complementare. Toate situaiile ntalnite se clarific i se stabilesc efectele pe care le genereaz asupra procesului de dezvoltare a sistemului informatic. o Se analizeaz msura n care toate cerinele sunt implementate prin constrngeri cunoscute i modul n care sunt utilizate sisteme de codificare pentru a elabora specificaii ntr-un mod ct mai formalizat.

o Se analizeaz ortogonalitatea sistemului de mesaje de eroare pentru a vedea msura n care acestea sunt unice, uor de neles i au menirea de a declana aciuni de corectare a datelor de intrare, fr 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 muli beneficiari, omogeni i simultani, vor utiliza funcionalitatea, timpul ateptat pentru rspuns, informaii despre volumul de date maxim care se stocheaz i dependenele de funcionare pe care le determin dimensiunile i complexitatea bazelor de date. o Se analizeaz dac sunt corect specificate toate cerinele referitoare la securitate i sigurana n accesarea tuturor resurselor sistemului informatic, stabilindu-se limitele i riscurile probabile. o Se analizeaz msura n care sunt corect specificate toate cerinele de tergere de date, arhivare, backup i restaurare ale sistemului informatic, atunci cnd acesta aparine unei generaii mai vechi de concepie. Dac este luat n considerare ca unic operaie adugarea de informaie, analiza vizeaz localizarea n timp, spaiu i la nivel de operatori a aciunilor care definesc clase de tranzacii n sistem. Trasabilitate o Se verific dac fiecare cerin este identificat unic i corect pentru a nu crea situaii ambigue, generatoare de soluii care includ elemente de complexitate nejustificate. o Se verific dac fiecare cerin funcionala a sistemului informatic solicitat este trasabil cu cerinele de ansamblu ale sistemului informatic efectiv realizat, cu instrumentele CASE utilizate.

Alte condiii care presupun verificari o Se stabilete msura n care toate cerinele descrise pentru elaborarea sistemului informatic se dovedesc a fi i cerinele luate n considerare de designeri fr a fi transpuse n structuri de date, structuri de module i fr 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 functionalitile 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 cerinele impuse prin standarde sau regulamente care au menirea de a face portabile specificaiile, produsele informatice autodocumentate i chiar rapoartele de auditare att n forma final ct i n formele de detaliu.

Anexa 5

Programul de audit
Compania Domeniile auditate Auditor ef Perioada Tipul auditului Locuri numele firmei Programul orar Periodic numele firmei lista de activiti a firmei Contract nr. Standard EAC/ NACE EN ISO 9001::2000

numele auditorului

Echipa de audit numele auditorilor Audit ID

adresa firmei Procesul Proces analizat

Element standard

Auditor AAuditor ef A - Auditor Procesul descris in Cine a realizat manualul calitii auditul

Anexa 6

Nota de neconformitate
Compania Adresa Standard/Clauze Dept/ Proiect 1. Descrierea neconformitii Auditor Client semntura semntura 2. Msuri de corectare Semntura client: Documente ataate: 3. Revederea aciunilor corective Contract nr. Data Nota Nr. Categoria notei Aciuni de corectare luate termen limita Data:

Msurile propuse sau executate sunt satisfctoare Da/Nu Necesitatea verificrii ulterioare Da/Nu Auditor ef semntura Data

Comentarii 4. ncheiere not de nonconformitate Auditor ef semntura Data:

Anexa 7

Raport de audit
Compania Nr de angajai Reprezentantul managementului Auditor ef Audit ID Client Nr. Standard EAC/ NACE Data auditului Echipa de auditori Data urmtorului audit ISO 9001:2001

Scopul vizitei Audit periodic Rezultatele vizitei - A din B neconformitile existente la precedentul audit au fost verificate pe durata auditului actual; - C neconformiti majore au fost raportate la ultima edin de ncheiere; - D neconformiti minore au fost raportate la edina de ncheiere; - E observaii noi au fost raportate la edina de ncheiere . Anexe nregistrri Observaii Divergente

Domeniul certificrii Standarde de produs/ cerine statutare/ coduri de practic / Note de edin

Anexa 8

Raport de audit intern

1. Departament auditat: 2. Proiect software: 3. Perioada: 4. Documente de referina: Manualul calitii Controlul documentelor Controlul nregistrrilor calitii Auditul intern Controlul produsului neconform Aciune corectiv iterativ convergent Aciune preventiv cu ncadrare n costuri Analiza efectuat de management Resurse umane cu calificare continu Managementul proiectului de sistem informatic evolutiv Determinarea specificaiilor sistemului Proiectare arhitectural sistem informatic, inclusiv prin customizare Proiectarea detaliat cu includerea sistemelor de protecie organizate pe niveluri de acces la resurse Producia codului, asamblarea de module Proiectarea sistemelor de baze de date i crearea premiselor testrii Livrare i instalare aplicaii informatice independente, asamblabile succesiv n vederea obinerii, n final, a sistemului informatic integrat Mentenan software, baze de date i arhitecturi n vederea optimizrii procesului de nlocuire Cerine de reinginerie sistem informatic Managementul configuraiei Proprietatea clientului asupra sistemului informatic privit ca produs finit Monitorizarea satisfaciei clientului Departamentul de dezvoltare software Software zz.ll.aaaa-zz.ll.aaaa

 Metrici pentru produse, date i servicii Verificarea i validarea sistemului software, baze de date i fluxuri Elaborarea procedurilor i instruciunilor de utilizare n siguran Codificarea documentelor Managementul documentelor Controlul documentelor de dezvoltare software Elaborarea planului calitii ca instrument al dezvoltrii sistemului informatic Cerine de reglementare specifice : Legi Hotrri de Guvern Norme i metodologii de aplicare a legilor i hotrrilor Standarde de calitate Documentaii ale metodologiilor de dezvoltare asistat sisteme informatice - Definiri de limbaje de proiectare i realizare specificaii, cod, structuri de baze de date, fluxuri - Metrici de evaluare stadii, evoluii i produse finite - Regulamente de elaborare a documentaiilor

5. Domeniul i obiectivele auditului: a. verificarea implementrii prevederilor documentelor de referin i conformotatea cu cerinele legale i de reglementare specifice b. determinare oportuniti de imbuntire a sistemului informatic n vederea operaionalizrii acestuia. 6. Echipa de audit: auditor ef auditori auditori n formare experi tehnici 7. Persoane contactate din departamentele auditate (nume i funcie): Director Departament Software ef proiect software Director Departament Baze de Date ef proiect baze de date

8. Difuzare: Ex.1 Sef departament Calitate Ex.2 - Director Software Ex.3 - Director Baze de Date 9. Rezultatele verificarii 9.1 Privind activitile de verificare i validare a sistemului Situaie cu numrul de erori gsite i de ctre cine au fost introduse: Modulul AAAA1 Numr probleme introduse de testeri: Numr probleme introduse de programatori: Numar probleme introduse de consultani: .. Modulul AAAAn Numr probleme introduse de testeri: Numr probleme introduse de programatori: Numar probleme introduse de consultani: SSS1 TTT1 YYY1

SSSn TTTn YYYn

Analiza datelor conduce la o serie de decizii privind nivelul modificrilor care trebuie efectuate n fiecare modul pentru a fi adus la cerinele formulate de beneficiari. Erorile sunt contorizate difereniat i calculul unor indicatori agregai d o imagine suficient de clar asupra calitii sistemului informatic privit ca un conglomerat de module, fiecare modul avnd nivelul su de calitate diferit de al celorlalte module. n continuare se descriu pe larg rapoartele de mbuntire a modulelor prin indicarea erorilor eliminate i a efectelor pe care le genereaz mbuntirea asupra ntregului sistem informatic. Se specific toate modificrile efectuate pentru a ameliora calitatea modulului, respectiv calitatea modulelor adiacente, n final calitatea ntregului sistem informatic. Se efectueaz analiza erorilor de ctre eful de proiect/echip de proiect, lucru foarte important din punctul de vedere al asigurarii calitii prin prevenirea erorilor care se descoper ctre etapele finale ale ciclului de dezvoltare, erori caracterizate prin costuri de corectare foarte ridicate.

9.2 Consideraii privind documentaia de dezvoltare software

Trasabilitatea specificat din documentele sistemului informatic este corect implementat. Documentaia de dezvoltare a sistemului informatic este bine inut sub control, cu specificarea tuturor persoanelor care au executat operaii de verificare, control i elaborare documentatii privind dinamica testrii. 9.3 Raportul de stadiu al configuraiei Reguliile pentru identificarea configuraiei, specifice proiectului, cu stabilirea unor reguli precise de localizare a emitenilor, a destinatarilor i a coninutului. 10. Concluzii Activitile n cadrul proiectului de sistem informatic se desfoar n conformitate cu documentele de referin i standardele/cerinele legale specifice care corespund modalitilor uzuale de derulare a proceselor. n cazul n care, numrul de erori este cu mult mai mare dect o limit stabilit, sunt identificate cauzele care genereaz situaia respectiv. De regul, astfel de situaii sunt frecvente cnd procesul de testare este incomplet i cnd asigurarea calitii este deplasat spre partea final a ciclului de dezvoltare a sistemului informatic. 11. Propuneri de imbuntire / Recomandri o O mai bun verificare de proiectare prin crearea i utilizarea listelor de verificare (checklist) dup terminarea fiecrei faze din ciclul de dezvoltare a sistemului informatic. o Introducerea inspeciilor software i a inspeciilor n bazele de date. o Crearea i urmrirea n viitor a unor situaii din care s reias: - comparaia 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; - comparaia att ca durat resurse, costuri i calitate a fiecarei faze din ciclul de dezvoltare; - analiza efectelor si descoperirea cauzelor care genereaz erori sistematice n vederea gsirii celor mai bune ci de eliminare; - impactul generat de modificrile n structura prin module nou introduse asupra proceselor de testare, evideniindu-se situaiile n

care sunt identificate module bine scrise, planificarea adecvat a resurselor, o corelaie strns 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) Certificri: 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)