Auditul Informatic

Ion Ivan Alecu Felician Sergiu Capisizu

1. Orientarea spre calitate i spre garantarea calitii

Societatea informaional a atins acel stadiu cruia i corespunde orientarea spre cetean a aplicaiilor i spre divesitatea situaiilor n care acesta se afl la un moment dat. n acest context, aplicaiile informatice trebuie s ating un nivel calitativ superior. Ceteanul, principalul beneficiar al efectelor directe pe care le genereaz societatea informaional, trebuie s obin un nivel maxim a gradului de satisfacie. Pentru a dezvolta o aplicaie, inclusiv o aplicaie web, se parcurge un ciclu format din etape, definite riguros ca succesiune i sarcini. Calitatea aplicaiilor informatice se planific. n funcie de experiena acumulat, de exigenele care apar pentru perioade bine determinate, se enumera caracteristicile de calitate iar prin similitudine cu aplicaii aflate n exploatare se specific nivelul de calitate cu care va fi nzestrat produsul informatic sau baza de date, rezultatele interfeelor i fluxurile de selecie ale site-urilor. Pentru caracteristicile de calitate C1, C2, ...Cm se stabilesc nivelurile planificate pl1, pl2, ...plm. Pe parcursul analizrii unui produs informatic, a unei baze de date sau a unei interfee, se msoar nivelurile efective pentru caracteristicile de calitate realizate: pr1, pr2, ...prm. Prin comparare, rezult deciziile care trebuie luate: 1. n cazul n care nivelurile planificate sunt identice sau sunt mai mici dect nivelurile efective, pli pri, rezult c procesul de dezvoltare decurge conform cerinelor; 2. n cazul n care pli pri nseamn c trebuie adoptate msuri pentru creterea nivelului caracteristicii Ci a produsului informatic, a bazei de date sau a interfeei web. n final, pentru certificarea produsului, trebuie ca nivelurile planificate ale caracteristicilor de calitate s fie mai mici 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, reprezint 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 de software ntruct rezultatele procesului de auditare se constituie n baz pentru fundamentarea deciziilor pe termen lung privind politicile de management al calitii. Certificarea echipelor, sistemelor de management al calitii, 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. Exist dou probleme i anume:

1. crearea climatului, a educaiei i a mentalitii orientate spre calitatea proceselor, produselor, intrrilor i ieirilor acestora; 2. stabilirea concordanei dintre imaginea proiectat a produsului sau serviciului i caracteristicile produsului sau serviciului real. 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 de software i desfoar activitatea, societatea informaional, n stadiul artat, impune ca dezvoltarea de sisteme informatice prin adugarea de componente s genereze un efect de antrenare multipl n direcia pozitiv a evoluiei gradului de satisfacie nregistrat de utilizatorul final, ceteanul.

2. Concepte de baz
Auditul informatic reprezint un domeniu cuprinztor n care sunt incluse toate activitile de auditare pentru specificaii, proiecte, software, baze de date ct i procesele specifice ciclului de via asociate unui program, unei aplicaii informatice, unui sistem informatic pentru management sau unui portal de maxim complexitate aparinnd unei organizaii virtuale. Auditul reprezint o form esenial a serviciilor independente prin care se verific faptul c o aplicaie informatic, prin prelucrrile pe care le efectueaz, i atinge obiectivul pentru care a fost elaborat. Auditorul din domeniul informatic este acel specialist cu solide cunotine de informatic, atestate prin certificate i diplome, care stpnete cadrul legislativ conex cu informatica i care are certificri recunoscute n domeniul auditului informatic. Prin nscrisurile pe care le posed, auditorul informatic dovedete c n faa unor comisii recunoscute a artat c a studiat documentaia specific, o poate reda, poate face conexiunile necesare pentru a soluiona probleme, a elabora un raport i pentru a parcurge etapele ciclului de audit informatic. Nu nseamn, ns, c, automat, auditorul informatic certificat, atunci cnd trece la auditarea unei aplicaii informatice, presteaz un serviciu de excelent calitate. Aceste certificri evideniaz faptul c: - auditorul informatic a parcurs o literatur de specialitate fundamental minimal i o stpnete pe o scar de la 1 la 10 obinnd puncte de la 6 la 10; - auditorul informatic a fost supus unor teste de cunotine i a dovedit c i-a nsuit, dar mai ales c utilizeaz, atunci cnd este nevoie, aceste cunotine pentru a evidenia fie performana unui produs informatic, fie carenele produsului; - auditorul informatic a elaborat un numr de proiecte practice, avnd prilejul de a valorifica la faa locului, pe un produs software, pe o baz de date sau pe o component intermediar, cunotinele teoretice, s conchid c gradul de concordan ntre specificaie i produsul efectiv are un nivel pe care l-a determinat, iar valoarea aceastui indicator rezult prin aplicarea corect a unei formule; - auditorul informatic respect procedurile specifice fiecrei etape a ciclului de auditare. n acest fel asigur derularea procesului de auditare meninnd caracterul de imparialitate pe care nsi meseria de auditor informatic, prin titulatura de independen, o presupune.

Organismele de certificarea auditorilor din informatic sunt numeroase. Este important s fie certificate acele organizaii caracterizate prin notorietate, prin rigurozitatea procesului de examinare i mai ales prin standardele i manualele de auditare utilizate. Organizaiile de certificare a auditorilor au o activitate transparent definit prin: 1. prezentarea clar, fr echivoc, a condiiilor pe care trebuie s le ndeplineasc persoanele pentru a participa la o competiie de certificare n vederea obinerii calitii de auditor informatic; 2. cursurile pe care le organizeaz, specificnd duratele, coninutul, materialele didactice, forma de finalizare, perioadele, costurile i mai ales drepturile pe care le ofer, n ideea de stabilire a nivelului de certificare la care are acces o persoan dup finalizare; 3. costurile de certificare, forma de examen, nivelul de exigen i mai ales recunoaterile diplomelor; 4. enumerarea marilor companii de software, produse software i aplicaii complexe care au fost abilitate de specialiti ce au obinut certificarea organizaiei; 5. organizaiile internaionale de certificare n care organizaia este membru i care recunosc respectiva organizaie de certificare a auditorilor; 6. procedurile de certificare specifice probelor practice, proiectelor i a celorlalte documentaii aferente procesului. Standardele de auditare existente trebuie s stea la baza formrii auditorului informatic. 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. n domeniul informatic exist mai multe direcii de dezvoltare a auditului cum ar fi COSO, ITIL, COBIT. 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 scrise n limbajul C++ , Pascal, Java 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 faptul 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. 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. Auditorul riscului de gestiune a datelor stocate n baze de date, prin procedurile pe care le aplic, verific dac: 1. programele refer corect cmpurile cu date stocate; 2. operaiile de prelucrare sunt cele din specificaii; 3. 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. Dincolo de totalitatea procedurilor, standardelor, fluxurilor i rapoartelor pe care trebuie s le parcurg specialitii cu certificare n acest domeniu, auditul organizaiei presupune i stabilirea gradului de siguran pe care l ofer respectiva organizaie ca o

msur a faptului c, odat ce a primit o comand pentru a proiecta un produs software, o aplicaie informatic sau un sistem informatic, sunt lansate, pe msur ce se desfoar etapele specifice, componente corespunztoare calitativ i funcional. Prin asamblarea acestora, n final, se obine produsul software aplicativ sau sistemul informatic care rspunde obiectivului definit. Auditarea se caracterizeaz prin faptul cse bazeaz pe un numr de principii, cum ar fi: comportamentul etic (increderea, integritatea, confidentialitatea si discretia sunt eseniale pentru auditare), prezentarea corecta a rezultatelor (care trebuie s reflecte cu fidelitate i cu acuratee activitile de audit), responsabilitate profesional. Metodele de colectare a informaiilor necesare pentru audit includ interviul, observarea activitilor i analiza documentelor, a nregistrrilor i a altor surse de informare. Auditorii nu sunt nici prieteni, nici dusmani ci profesioniti care trebuie s identifice diferenele fat de procedurile implementate sau procesele operationale In cadrul unui audit, comunicarea este vital i elemente ale comunicrii, cum ar fi cuvintele (7%), timbrul vocii ( 38 %) dar mai ales mimica, inuta, gesturile, contactul cu privirea (55 %) sunt foarte importante. De asemenea, ascultarea activ este o tehnica pe care ar trebui s o invee si s o aplice in mod constant toi auditorii, aceasta fiind cheia comunicrii eficiente.

3. Codul auditului informatic

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 cade 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 asigurare a securitii fluxurilor din ntregul sistem. De aceea, n cadrul procesului de audit informatic, planificarea i definirea metodei de audit este esenial. Alegerea unei metode nepotrivite 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 obiectul auditrii cum ar fi produsul software, aplicaia informatic sau sistemul informatic. Auditul este, prin complexitatea sa, o activitate n care sunt luate n analiz legturile i 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, aplicaiei, sistemului 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, neambigue 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 codul surs, pe specificaii, pe diagrame, pe documentaii, pe structuri de rezultate. Pentru a obine o reducere a nivelului estimat pentru riscul erorilor de analiz i control asociate produsului informatic, se procedeaz la efectuarea, n manier iterativ, a unor corecii asupra procedeelor tehnice, metodelor i modelelor de analiz i control asociate procesului de audit. 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 prin care se evideniaz diferenele dintre ceeea 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 pas cu pas comportamentul secvenelor de program. n cazul n care auditorul informatic are la baz pregtire de programator, acesta 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 sau de un sistem complex. Efortul de auditare este ridicat, indiferent de complexitatea produsului auditat. Auditul se ncheie cu un raport care are la baz o serie de verificri ale intercondiionrilor dintre module, dintre programe, respectiv dintre subsistemele sistemului informatic, pentru momentul t, considerat ca 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, acestea sunt generate i testarea produsului se realizeaz simultan cu produse din aceeai clas, tocmai pentru a se efectua analize i pentru a compara produsele informatice. Seriile de date se constituie n baze de redactare a raportului de auditare. 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 tip depanare. Raportul de audit este o lucrare cuprinztoare care ofer o imagine privind sigurana pe care o ofer produsul. Este necesar ca raportul de audit s joace un rol activ n dezvoltarea ulterioar a companiei de software iar de cele mai multe ori acesta conine i propuneri de mbuntire. 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 cumprtorul sau beneficiarul de software.

4. Auditul software
Un produs software este de fapt un program principal care apeleaz proceduri. 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 a anumit funcie de prelucrare. Analiza bazat pe revizuirea textului surs are ca rezultat o serie de comentarii din partea membrilor echipei sau clienilor asupra modului n care a fost conceput i elaborat produsul informatic. Evidenierea comportamentului statistic al programului, privit ca automat nedeterminat, se realizeaz n cazul n care se caut disfuncionaliti prin parcurgerea textului surs sau prin discuii asupra locului i rolului unor instruciuni. Un rol special l are revizuirea textului surs, care const n parcurgerea textului pas cu pas, evideniind etapele algoritmului i evalund capacitatea de generare a erorilor. Inspectarea codului surs are ca obiectiv creterea calitii software prin aplicarea unor reguli verificate i neluate n considerare de ctre programatorii care au dezvoltat produsul analizat. Avantajele inspeciei sunt enumerate in continuare: - ndepartarea timpurie a defectelor majore; - evaluare imediata; - mai economic i eficient din punct de vedere al costurilor; - mbuntete calitatea produsului; - contribuie la dezvoltarea organizaiei spre realizarea unor produse mai performante; - mbuntete procesul; - instruiete personalul implicat la realizarea produsului. Pornind de la specificaiile de programare n care se prezint datele de intrare ale aplicaiei, rezultatele, modelele de calcul, seturile de date de test i rezultatele ce trebuie obinute, prin inspecia textului surs se pun fa n fa componentele specificaiilor cu secvenele corespondente din program i se identific urmtoarele tipuri de situaii: 1. tuturor secvenelor de texte din specificaii le corespund secvene de instruciuni n programul de surs. n acest caz auditul consemneaz c programul realizeaz cerinele definite n specificaii; 2. numai anumitor secvene de text din specificaii le corespund pri de program surs ceea ce nseamn c programatorii nu au dezvoltat un produs care s realizeze toate funciile de prelucrare care sunt descrise prin specificaii; 3. exist mai multe secvene de cod dect cele care sunt cerute prin specificaii. Un astfel de caz se explic prin existena unor 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, asta 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 puncteaz 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. Auditorul care i propune s efectuaze o inspecie a textului surs trebuie s ndeplineasc o serie de condiii precum: 1. cunoaterea n detaliu a limbajului de programare n care este scris programul auditat; 2. s se familiarizeze rapid cu stilul de programare adoptat pentru scrierea codului de ctre echipa de programatori care a realizat programul; 3. 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; 4. s fie gata s acepte o multitudine de atitudini din partea programatorilor pornind de la decizia de a rescrie programul ca produs integral nou i pn la reutilizarea la maximum a componentelor existente n biblioteci. Auditorul are o list de erori probabile nsoite de modul direct de reproducere. Prin inspecie se analizeaz textul surs pentru a evidenia modelele de program care includ construcii generatoare de erori. Experiena n activitatea de programare conduce la conturarea listei de evenimente (erori) E1, E2,...Em mpreun cu frecvenele de operare deduse prin analiza unui set de N produse program. Evenimentele se ordoneaz dup frecvenele f1, f2,...fm de apariie astfel nct f1> f2> ... > fm. Pe durata inspeciei, auditorul se orienteaz s identifice secvenele care genereaz evenimentele E1, E2,...El i nu neglijeaz nici evenimentul Em 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. Inspecia software presupune o vast experien i o cultur a textelor surs. Acumulrile au menirea de a crea un stil de programare. Activitatea de programare devine o activitate de aplicare a unor reete. Auditul pe text surs revine la a verifica dac la fiecare pas din algoritm a fost aplicat reeta cea mai potrivit. Auditul pe text surs reprezint un pas spre a stabili gradul de siguran pe care l ofer programul atunci cnd se ruleaz seturile de date. Inspecia are menirea de a localiza funciile de baz, de a construi tabele de dependen i de a identifica disfuncionalitile care apar dac n tabel apar linii sau coloane necompletate. Tabelele de dependen stabilesc modul n care instruciunile I1, I2,...In ale unui program utilizeaz variabilele V1, V2,...Vm (Tabelul 1). Elementul akj are valoarea 0 dac instruciunea Ik nu folosete variabila Vj, respectiv 1 n cazul n care instruciunea Ik refer variabila Vj. Atunci cnd o coloan r conine numai zerouri nsemn c variabila Vr este definit i nefolosit. Dac instruciunile nu folosesc variabile, auditorul trebuie s studieze atent semnificaia instruciunii sau rolul funciei apelate i mai ales s determine oportunitatea poziiei n program a unei astfel de linii surs.

Inspecia pe textul surs este profesional, are un caracter strict iar observaiile trebuie s fie clare i fr echivoc. V1 I1 I2 ... Ik ... In V2 ... Vj ... Vn

akj

Tabelul 1 Tabel de dependen ntre instruciuni i variabile Realizarea testului de birou prin simularea trecerii de la o instruciune la alta vine s evidenieze mai ales evalurile de expresii condiionale complexe, care, atunci cnd sunt construite eronat, genereaz traversri, de asemenea eronate, ale ramurilor structurii arborescente asociat programului. Testul de birou i analiza textului surs reprezint numai o component a procesului de auditare. Se consider un program P cruia i se asociaz o structur arborescent la baza creia se afl K module care afieaz K tipuri de rezultate finale. Pentru a testa complet programul P se construiesc K seturi de date de test DS1, DS2... DSk i se imprim urma programului mpreun cu rezultate scontate. Urma programului este dat de o serie mesaje care permit reperarea instruciunilor care au fost executate. Testarea acestui program folosind seturile de date de test DST1, DST2... DSTk conduce la obinerea urmei programului pe baza mesajelor care evideniaz executarea anumitor instruciuni. Pentru fiecare set de date de test se verific corectitudinea programului prin compararea irului de mesaje obinut n urma execuiei cu irul care a fost generat n specificaii. Prin compararea celor dou iruri se stabilete gradul de concordan al programului cu specificaiile. Dac are loc pe msur ce se elaboreaz modulele unui program, atunci inspecia pe textul surs impune efectuarea de corecii pentru eliminarea erorilor iar evaluarea efectelor este imediat. Inspecia este o activitate de grup, cu mai muli participani, ce conduce la perfecionarea programatorilor. Eliminarea erorilor sau obligativitatea de a folosi anumite construcii conduce la creterea calitii programului. De exemplu, dac naintea efecturii unei mpriri este testat numitorul, produsul program va genera continuitate n procesul de prelucrare, iar apariia unei astfel de situaii este controlat i este precedat de un mesaj. 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. Aplicarea regulilor conform crora procedurile de calcul nu pot conine apeluri de funcii pentru citire de fiiere sau pentru scriere n fiiere conduce la ameliorarea rapid a procesului de scriere cod surs. Inspecia pe codul surs scurteaz intervalul dintre momentul n care s-a produs eroarea i momentul corectrii. Este cunoscut faptul c, cu ct o eroare este nlturat mai trziu, cu att efectele ei sunt mai profunde asupra ntregului produs. Pentru ca inspecia s fie tratat cu maxim seriozitate trebuie ca persoanele care o efectueaz s fie specialiti recunoscui. Este foarte dificil ca un programator slab sau o persoan care nu vine din zona programrii s procedeze la inspecie de cod surs, ntruct carenele de pregtire conduc la interpretri eronate, ce ndeprteaz momentul depistrii erorilor de cel al efecturii de corecii. Procedurile verificate i perfecionate, care sunt cutate n programele supuse inspeciei, formeaz arsenalul unui programator foarte bun cu bogat experien.

i n cazul inspeciei exist o abordare pe etape ce trebuie parcurse: planificarea inspeciei, evaluarea general, pregtirea inspeciei i derularea procesului propriu-zis. Dintrun studiu Fagan reiese c aplicarea inspeciei software asupra unei componente de complexitate medie a unui sistem de operare a dus la creterea cu 23 % a productivitii si o mbuntire cu 38 % a calitii componentelor. Pentru ca o metod de inspectare a unui produs software s aib o productivitate mare, este necesar ca aceasta s ndeplineasc urmtoarele condiii: - s existe garantia c metoda de inspectare se poate aplica riguros, astfel ncat rezultatele s fie specifice fiecrui produs particular i, n acelai timp, repetabile la nivelul aceluiai produs; - s fie flexibil, s poat servi unor scopuri complexe, nu numai unei simple detectri a erorilor nainte de faza de testare; - s fie conceput astfel nct o mare parte a muncii s poat fi facut automat, resursele umane s fie utilizate numai atunci cand este imperios necesar; - s fie eficient, astfel nct, cu un anumit volum de resurse, s se poat obtine rezultate maximale. Pentru a decide ce componente software s fie inspectate i ce tip de metod s se utilizeze, se consider urmtoarele criterii referitoare la risc: - componente care utilizeaz tehnologii, tehnici i instrumente noi; - componentele arhitecturale de baz; - componente sau cerine critice (securitate, siguran) cu mare risc de defectare; - cod de tratare a excepiilor care nu poate fi usor testat; - componente care se intentioneaz a fi reutilizate; - componente care servesc ca model pentru alte componente; - componente care afecteaz multiple zone ale aplicaiei; - interfee utilizator complexe; - componente create de programatori mai putin experimentai; - module cu complexitate ciclomatic ridicat; - module care au avut multe defecte sau modificri de-a lungul timpului. Aplicatiile sau componentele care pot fi n una sau mai multe dintre categoriile mai sus menionate sunt considerate de risc ridicat. Un produs este considerat de risc sczut daca o eroare nedetectat nu va afecta abilitatea proiectului de a respecta graficul, calitatea, bugetul i funcionalitile planificate. Revizuirile au diferite forme i nume ca de exemplu revizuire formala, inspectii, audituri si walkthrougs. n fiecare dintre aceste categorii, termenii au diferite nelesuri i conotaii. Cele mai importante caracteristici care difereniaz tipurile de revizuiri sunt scopul utilizrii, domeniul de aplicare i metoda. n general, scopul i domeniul de aplicare al revizuirii vor determina metoda folosit i gradul de formalism aplicat, aa cum se prezint n Tabelul 2. Diferitele tipuri de revizii utilizate n dezvoltarea de software variaz de la simple revizii tehnice pn la cele oficiale, formale, cum este cel de configuraie fizic a sistemului. Toate aceste tipuri de revizii sunt puternic influenate de ctre mrimea si complexitatea proiectului. Pentru un proiect intern al companiei, reviziile tind s fie mai simple n comparaie cu cele pentru un proiect aflat sub contract. Dei sunt diferite motive pentru a conduce o revizie, principalul scop rmne acela de a evalua avansul i integritatea unui produs sau proces. Reviziile sunt folosite si pentru a obine date. Colectarea sistematic de date este esential pentru evaluarea viitoare a ntregului proces de dezvoltare.

Implementarea inspectiilor software ntr-o firm de dezvoltare software este o provocare. Aceast implementare cere nu numai o foarte bun nelegere a tehnologiilor de dezvoltare software dar i o foarte bun evaluare a comportamentului, motivrii i culturii organizaionale a personalului implicat Tipul Review Domeniu de aplicare Destul de vast Destul de vast Restrns Restrns ctre vast Utilizat Pentru evaluarea ndeplinirii obiectelor n cadrul evoluiei proiectului Pentru evaluarea proiectelor de dezvoltare Pentru evaluarea proiectelor de dezvoltare Verific procesele si produsele n timpul dezvoltrii Tabelul 2 Tipuri de revizii Metoda

Ad hoc Analiz statistic a produselor Neinteractiv, destul de procedural Formal si procedural

Walkthroughs Inspecii Audit

Desi inspectiile software sunt metode de gestiune i management al calittii orientate ctre produs, faptul c toi participanii la inspectii i mbuntesc, n timp, ntr-un mod sau altul, abilitile personale (profesionale, de comunicare, de conducere), efectul major al acestora se va reflecta, pe termen mai lung, asupra calitiii proceselor. Prin inspecia software se realizeaz: - mbuntirea semnificativ a calitii produsului; - micorarea fazei de dezvoltare a produsului; - mbuntirea productivitatii; - reducerea costurilor cu realizarea produsului n diferite etape, cum ar fi cele de analiz, proiectare, generare cod i testare; - implicarea unor persoane ntr-un stil de lucru foarte organizat. Pentru fiecare limbaj de programare utilizat se pot stabili reguli i convenii referitoare la cod, care s includ minim urmtoarele: 1. reguli i convenii pentru formatarea textului surs: indentare, spaiere, majuscule, ordinea informaiilor; 2. reguli i convenii pentru comentarii, cum ar fi numele i identificatorul modulului, identificatorul versiunii, istoricul modificrilor, scop, specificaii funcionale i decizii de proiectare implementate, note referitoare la programare (algoritmi utilizai, ipoteze, constrngeri, efecte colaterale), note referitoare la date (intrri, ieiri, variabile, structura datelor); 3. convenii pentru denumirea variabilelor, procedurilor, modulelor i fiierelor; 4. limitri, dac exist, n utilizarea anumitor faciliti ale uneltelor de programare utilizate; 5. limitri, dac exist, ale complexitii codului. Inpectia aplicatiei informatice va urmri dac aceste reguli i convenii referitoare la cod sunt respectate i dac cerinele considerate critice (performane, securitate, siguran, fiabilitate , confidenialitate sunt tratate. Dac firma are create standarde pentru proiectare, programare i testare, atunci respectarea acestora se va urmri tot n cadrul acestei etape.

10

Dup efectuarea inspeciei, programatorii procedeaz la corectarea erorilor. Pe parcursul fazelor de mai sus pot fi necesare mai multe cicluri de verificare, corectare i mbuntire pn la finalizarea documentelor propuse: specificaii funcionale, arhitectura sistemului, proiectarea detaliat. Reinspecia presupune ca volumul erorilor de la o inspecie la alta s fie cu tendin de amortizare adic s scad devenind aproape nul n final.

5. Verificarea i validarea aplicaiilor informatice

Aplicaiile informatice sunt construcii complexe care includ software i seturi de date organizate n fiiere, baze de date sau alte structuri a cror dinamic i coninut amelioreaz duratele tranzaciilor. Aplicaia informatic soluioneaz probleme ce aparin unei clase riguros definit. Exist aplicaii informatice pentru rezervarea de bilete, rezervarea de locuri la hoteluri, optimizare folosind programarea liniar, pentru implementarea unei metode de analiz statistic pentru accesarea anumitor date de pe internet, pentru efectuarea unor calcule privind salariaii, pentru managementul unei activiti bine delimitate din companiile orientate pe servicii sau producie. Elaborarea i implementarea de aplicaii informatice creeaz premisele reale pentru dezvoltarea de sisteme informatice pentru management deoarece: 1. prin agregarea de aplicaii informatice ale companiei se obin subsisteme informatice de management; prin agregarea de subsisteme de management se obine sistemul informatic n integralitatea sa; sistemul este integrat datorit faptului c abordeaz totalitatea aspectelor ce se manifest la nivelul companiei; 2. experiena acumulat prin analiza unei probleme, proiectarea soluiei i traversarea celorlalte etape ale codului de dezvoltare software fac s se obin acel nivel de experien care s deschid orizonturi noi pentru analiza i mai ales proiectarea unui sistem informatic; echipa care dezvolt o aplicaie informatic are ansa s dovedeasc unitate, capacitate de analiz i sintez i n special performan n a respecta standarde i a utiliza coerent tehnicile i metodele cele mai noi ale ingineriei software. n cadrul codului de dezvoltare a aplicaiilor informatice apar dou aspecte i anume: 1. atitudinea echipei implicate n dezvoltarea de procese care au ca obiectiv asigurarea calitii de concepie, de execuie, de conformitate, a capacitii de utilizare i de mentenan; se planific nivelurile caracteristicilor de calitate pentru a ale atinge pe durata proceselor de realizare a produsului; echipa de specialiti cunoate modalitile practice prin care s defineasc obiective, s asigure atingerea acestora i implicit s satisfac cerinele beneficiarului; prin respectarea fluxurilor specifice a procesului de dezvoltarea a aplicaiei informatice, a sarcinilor care decurg din fiecare etap prin definirea intrrilor i ieirilor etapelor i prin executarea strict a activitilor, prin respectarea procedurilor definite la nivelul companiei de software, se asigur condiia obinerii unui nivel corespunztor pentru calitatea de excuie; elaborarea specificaiilor impune o serie de restricii care orienteaz pe cel ce elaboreaz soluii, texte surs i de structuri ale seturilor de date, spre direcii clare privind resursele pe care le aloc pentru a obine att operaionalitatea, ct i mentanabilitatea produsului finit; 2. verificarea mai nti a respectrii de ctre membrii echipei a tuturor cerinelor strict din punct de vedere tehnic n ceea ce privete latura calitativ a abordrii ct i n ceea ce privete latura cantitativ a acesteia; a verifica nseamn a prelua ceea ce s-a executat sau informaia privind modul n care s-a produs execuia i a

11

compara cu proceduri, standarde sau norme descrise n manualele de implementare a unor tehnici de analiz-proiectare-codificare-testare; rezultatul verificrii este fie identificarea de diferene ntre ceea ce s-a fcut i cum trebuia fcut, fie confirmarea unei suprapuneri perfecte, ceea ce marcheaz faptul c echipa de dezvoltare a aplicaiei informatice a lucrat perfect; validarea aplicaiei informatice este consecina verificrilor i se produce atunci cnd diferenele dintre cum s-a lucrat i cum trebuia lucrat precum i diferenele dintre ceea ce s-a obinut, respectiv ceea ce trebuia obinut, nu sunt semnificative n raport cu criteriile de exigen stabilite i cunoscute att de auditori, ct mai ales de echipa care dezvolt aplicaiile informatice.

Verificarea are menirea de a analiza module, interaciuni, seturi de date i rezultate pariale pentru a putea stabili diferenele care apar n cazul componentelor ntre nivelurile efective i nivelurile planificate ale unor caracteristici de calitate. Verificarea stabilete compatibilitatea i precizia componentelor aplicaiei informatice, a datelor de intrare i a rezultatelor fa de standarde, norme i restricii impuse de tehnicile utizate de-a lungul etapelor proceselor. Validarea este un proces de evaluare, n care aplicaia informatic este tratat ca un produs finit. Dac sunt asigurate cerinele de conformitate cu condiiile specifice, procesul de validare conduce la acceptarea aplicaiei informaiei pentru utilizarea curent, ea asigurnd un bun grad de satisfacere a exigenelor utilizatorilor. Verificarea aplicaiei informatice se realizaez prin efectuarea de teste, prin analiza structurii, a modulelor, a interaciunilor dintre module i prin analiza procesului care st la baza ciclului de dezvoltare. Se verific nivelul concordanei dintre cerinele formulate de beneficiar i reflectarea acestora la nivelul specificaiilor. Se stabilete concordana dintre structura proiectului i structura sistemului aa cum rezult din specificaii. Este important s se defineasc fluxurile care se parcurg la nivelul aplicaiei informatice astfel nct testele s acopere totalitatea elementelor definite prin specificaii. Verificarea la nivelul aplicaiei informatice este un proces iterativ convergent, fiecare verificare fiind urmat de corectarea abaterilor nregistrate, dac aceste abateri reprezint de fapt minusurile modulelor sau structurilor seturilor de date n raport cu definirile incluse n specificaiile aplicaiei. Testele se efectueaz pentru a marca msura n care componentele aplicaiei informatice (date de intrare, module program, date de ieire) satisfac specificaiile i de a stabili care sunt diferenele ntre ceea ce se atepta s se obin prin utilizarea aplicaia i ceea ce s-a obinut n mod concret. Testele utilizeaz module program, structuri de date, exigenele de acceptare, seturi de date de test i documentaia care alctuiete ghidul utilizatorului. Procesul de testare are la baz un plan care include: definirea obiectivului testrii, etapele prin care se efectueaz testarea, intrrile i ieirile testrii. Planul include, de asemenea, modul de finalizare a analizei rezultatelor obinute. Planurile de testare trebuie s conina urmtoarele date : - obiectivele urmrite de fiecare tip de teste (teste unitare, teste de integrare, teste de sistem, teste de acceptare, alte tipuri de teste); - criteriile prin care se determin cnd se incheie o faz de testare; - graficul de lucru; - responsabiliti (cine rspunde de fiecare faz); - resursele necesare, cum ar fi o programele auxiliare, inclusiv instrumentele de testare;

12

o configuraiile hardware; o timpul disponibil; o personalul necesar; strategia de testare, inclusiv procedurile pentru o identificarea, generarea i documentarea cazurilor testate; o urmrirea rezultatelor; o testarea performanei la stress a programelor; o testarea regresiv; o riscurile asociate procesului de testare; producerea documentaiei; procedurile de testare.

Este posibil ca modificrile efectuate dup testarea unui program s submineze calitatea acestuia. Orice modificare, indiferent de ct de nensemnat, poate anula testarea componentei respective. Pentru a evita acest pericol, programul testat aflat n una din stadiile testarii (unitar, integrare, sistem, acceptare) trebuie considerat ca element supus managementului configuratiei. In aceasta situatie, programul este un proiect identificabil care nu mai poate fi modificat dect in urma unor proceduri clare. n planul de testare sunt evideniate distinct, ca teste de acceptare, procesele de la nivelul unitilor, de la nivelul ntregii aplicaii i de la nivelul interaciunii dintre aplicaia informatic i utilizator. Planului de testare pentru aplicaia informatic i corespunde un program de testare n care obiectivele i etapele iau forme concrete prin enumerarea de componente ale aplicaiei, prin persoane care deruleaz activitile de testare, prin precizarea obiectivelor urmrite n fiecare caz n parte. Testarea aplicaiei informatice se deruleaz conform planului. Rrezultatul testrii, ca form concret de verificare a aplicaiei informatice, este un set de date privind att comportamentul acesteia n execuie, pe seturi de date impuse, ct i structura i resursele utilizate la construirea sa. Aceste rezultate conduc, prin agregare, la obinerea unor indicatori. Pe baza nivelurilor indicatorilor se decide dac aplicaia informatic este acceptat sau nu, adic este livrabil clientului, existnd garania c se va obine un grad de satisfacere a cerinelor acestuia suficient de ridicat ca s justifice investiia respectiv. Riscurile de a obine rezultate eronate sunt prea mari, ele afectnd grav modul de satisfacere a acestor cerine. Auditul aplicaiei informatice traverseaz etapele oricrui proces de auditare. ntr-un fel este privit o aplicaie informatic n care utilizatorul este operatorul instruit printr-un curs de scurt durat pentru a ti exact cum se utilizeaz produsul, i n alt fel sunt analizate aplicaiile web care se adreseaz unui grup int neomogen, deoarece criteriile urmrite difer. Orice proces de audit este derulat dac i numai dac este fezabil. Fiecare aplicaie informatic este nsoit de o documentaie cadru care definete condiiile de elaborare, sarcinile elaboratorului i cele ale beneficiarului. De asemenea echipa de audit analizeaz i documentele relevante de ordin tehnic prin care se evideniaz modul n care au fost parcurse etapele ciclului de dezvoltare. Este cunoscut reticena echipelor de specialiti care proiecteaz, programeaz, testeaz i implementeaz aplicaii informatice n a da o form final documentaiei tehnice deoarece se consider c activitile i produsele finite sau stadiile pe care acestea le-au produs nu sunt suficiente pentru a crea o imagine complet a ntregului efort depus. Sunt necesare texte i reprezentri grafice complete, concise i consistente prin care s se prezinte, pas cu pas, tot ceea ce s-a efectuat, tot ceea ce s-a obinut i mai ales cum s-a procedat i cine a executat fiecare operaie. Auditul aplicaiei informatice se efectueaz la faa locului, pentru a se vedea exact pe ce echipamente s-a lucrat i ce medii de programare au fost folosite. Exist premise reale de a

13

obine informaiile necesare completrii tabelelor pe baza crora se elaboreaz raportul de audit. Efectuarea auditului presupune o transparen total a echipei de auditori fa de echipa care a realizat aplicaia informatic. Orice alt abordare conduce la obinerea de rezultate neconcludente, la redefinirea contextului i mai ales la elaborarea unor concluzii false, care nu vor juca un rol activ n dezvoltarea aplicaiei i n procesul de reinginerie. Etapele de derulare a auditului privesc interaciuni ale echipei de auditori cu cei care au dezvoltat aplicaia n aa fel nct, printr-o abordare gradat, s se obin toate datele necesare stabilirii concordanei dintre ceea ce se solicit prin specificaii i ceea ce exist n realitate: programe, fiiere, baze de date i structuri de rezultate finale. Raportul de audit trebuie s consemneze toate diferenele. El nu soluioneaz problemele, dar creeaz bazele corecte ale derulrii proceselor de eliminare a erorilor i de cretere a nivelurilor unor caracteristici de calitate. Raportul de audit se difuzeaz i constituie document care nsoete procedurile de predare a aplicaiei informatice spre client. Auditul aplicaiei informatice vine ca o apreciere efectuat de un organism independent asupra concordanei dintre calitatea planificat i calitatea efectiv a aplicaiei. Auditul reprezint o concluzie asupra siguranei la care trebuie s se atepte clientul n a obine rezultatele de calitatea i cantitatea pe care i-a dorit-o. Auditul calitii software are cte ceva de oferit fiecrui participant: utilizatorul este asigurat c produsul ndeplinete nevoile sale operaionale i de performan, cumprtorul este asigurat c produsul va fi livrat la timp i n limitele bugetului alocat, iar productorul este asigurat c produsul s-a dezvoltat ntr-o manier trasabil, fiind deci mentenabil, i va fi acceptat de utilizator i cumparator. Costul auditului este preul pe care utilizatorul, cumprtorul i productorul trebuie s-l plteasc pentru a-i reduce riscurile.

6. Auditul sistemelor informatice de management

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, SSI1, SSI2,...SSIk, cte un subsitem pentru fiecare funcie. ntregul sistem informatic este proiectat sub forma unor subsisteme cu legturi ntre 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. Dac n unele momente a fost necesar efectuarea unei analize critice, stadiul actual impune o cu totul alt abordare. 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 tehnic trebuie s ia n considerare existena acestor componente. Platformele SAP i ORACLE ofer soluii ERP, iar reluarea unor cicluri complete de creare de module n afara concepiei unitare pe care o ofer una din platformele menionate conduce la meninerea procesului de informatizare n aria meteugreasc, neadecvat stadiului atins acum n zona ingineriei sistemelor informatice. 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, care i ateapt cumprtorii. A spune acum c o organizaie are particulariti ce impun definirea unei structuri proprii de sistem informatic nseamn a considera c echipele care au proiectat sisteme suport de decizie care se aplic n peste 30 de ri nu sunt competente, iar organizaia este att de special nct nu se ncadreaz n nici o categorie. Abordarea este nu numai

14

absurd prin simplismul ei dar denot un nivel de ignoran greu de acceptat din punctul de vedere al informaticii anului 2005. 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: 1. sistemele informatice de gestiune contabil pot conduce la efectuarea de operaii neautorizate; 2. sunt situaii n care nu exist concordan ntre teoria contabilitii i procedurile care se apeleaz pentru a efectua prelucrri; 3. 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; 4. 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; 5. 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; 6. interfeele acestor sisteme trebuie s fie orientate spre o abordare a proceselor n timp real, ntruct numeroase operaii se deruleaz prin sistemele e-banking i ecommerce; 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; 7. 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 s existe alte persoane care au acces la consultarea numai a 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 atfel 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; 8. sistemul informatic de gestiune financiar-contabil se proiecteaz incluznd numeroase chei de control care s evidenieze frecvenele unor operaiuni, apropierile de limitele domeniilor de variaie, astfel nct s se ia rapid deciziile adecvate; 9. la proiectare i la realizare se definesc situaiile de blocare pentru a semnaliza tentativele de efectuare a operaiilor interzise; 10. aceste sisteme sunt organizate ca structuri ierarhice, cu intervenii de asemenea ierarhice. Astfel, dac s-a produs un eveniment la nivelul K+1, atunci 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.

15

Rezult c un sistem informatic, fie c este un sistem general pentru management sau unul special destinal managementului financiar contabil, 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 o serie de criterii precis stabilite. n primul rnd, legile definesc foarte clar 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 acestuia n una din categoriile urmtoare: 1. ru platnici; 2. creditori al cror plafon de creditare a fost atins; 3. creditori care mai pot solicita un credit dar nu mai mare dect o valoare impus; 4. creditori care au dreptul s solicite credit cu valoare care se situeaz ntr-un interval definit de garanii, de cifra de afaceri i de istoricul relaiei lor cu banca; 5. creditori falii. Evident, rolul auditului unui astfel de sistem este de a testa dac respectivul sistem bancar include astfel de proceduri. Datele de test 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, securitatea operaiilor este asigurat iar condiiile de risc n utilizare sunt 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.

16

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 iar sistemul informatic reprezint o structur. Auditorul are menirea de a stabili existena corespondenei dintre componentele textului structurat i, respectiv, componentele sistemului, identificnd o concordan perfect, parial, redus sau chiar absena total a concordanei. Componentele din structura textului care alctuiesc specificaiile includ: 1. nivelul managementului; 2. ciclul de elaborare a sistemului informatic de gestiune financiar-contabil; 3. securitatea sistemului: precizarea responsabilitilor, separarea funciilor incompatibile, ierarhizarea accesului la resursele sistemului; 4. nivelul operaional, prin procedurile pe care operatorii le efectueaz n ceea ce privete: introducerea de date, manipularea de documente, manipularea mediilor de stocare pentru datele intermediare, nregistrarea evenimentelor, asistena tehnic; 5. 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 i 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; 6. 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 informatic 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 i se calculeaz o serie de indicatori asupra garaniei sau asupra siguranei sau credibilitii produsului numit sistem informatic pentru gestiunea financiar-contabil. 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

17

accesibilitatea beneficiarului la informaia ateptat, obinnd n acest fel un nivel maxim al satisfacerii cerinelor proprii. Auditul sistemelor informatice inclide: 1. auditul intern, prin care se confirm respectarea procedurilor de transformare a datelor de intrare n rezultate urmrindu-se modul n care noul sistem care se implementeaz este mai eficient, este nsoit de o economisire a resurselor; 2. auditul extern, care include proceduri prin care se evideniaz comportamentul sistemului informatic, prin testri cu ajutorul crora se msoar ct de stabile, ct de fiabile i mentenabile sunt procedurile de control care intr n componena sistemului i care implementez toate cerinele exprese incluse n specificaii, n legi, n regulamente 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: 1. 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; 2. 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; 3. elaborarea programului de audit ce include: definirea scopului, stabilirea obiectivelor, efectuarea planificrii, derularea propriu-zis, ntocmirea de rapoarte; 4. 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 test, documentaia care se livreaz o dat cu implementarea sistemului informatic, ghidurile de utilizare i de administrare; 5. 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, acetia enumer n raportul de audit totalitatea diferenelor care au fost ntlnite ntre sistemul real i sistemul virtual ideal. Raportul nu include i 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 iar 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. Pe de3 alt parte ns, raportul de audit poate concluziona c sistemul nu este credibil i c acesta trebuie s fie supus unor corecii urmate de un nou proces de auditare. Dac tehnica de auditare i

18

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 specificaii n auditul sistemelor informatice pentru management i-au concentrat atenia asupra algoritmizrii proceselor de auditare, n viitor trebuind s se defineasc metrici necompensatorii, nediscriminatorii i necatastrofice, pentru a asigura un caracter obiectiv auditului, prin transferul din zona interpretrilor n zona certitudinilor.

7. Concluzii
Auditul informatic reprezint o ramur distinct a auditului ce include tehnici i metode de auditare a aplicaiilor informatice, a sistemelor informatice tradiionale, a sistemelor informatice distribuite, a aplicaiilor mobile i a tuturor aplicaiilor informatice care utilizeaz resurse internet. Pentru a realiza un audit informatic de calitate este necesar ca urmtoarele condiii s fie ndeplinite simultan: 1. s existe organisme recunoscute de certificare a auditorilor cu proceduri specializate de auditare pentru fiecare tipologie de component informatic; 2. auditorii s reprezinte persoane calificate n domeniul informatic deoarece acestea sunt cele mai potrivite pentru acest domeniu ntruct n procesul auditare sunt necesare elemente de teorie i practic n domeniu; 3. s existe instrumente pentru asistarea auditrii cu computerul. 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 poate susine cu succes.

19