Subiecte

1. Definiti arhitecturii afacerii.

Arhitectura afacerii presupune crearea unui set organizat de elemente, cu relaii bine definite ntre
ele, care alcatuiesc un grup unitar, definit de funcionaliti.
2. Definiti arhitecturii software.
Arhitectura software implica activitati si instructiuni corespunzatoare.
Activitatile au o evolutie specifica, care presupune ordonarea si sincronizarea in timp, concomitent
cu evaluarea rezultatelor si validarea fiecarei activitati.
3. Principii de realizare a arhitecturii de afacerii.
sa se identifice sistemul informational care indeplineste in cel mai inalt grad cerintele afacerii;
sa se determine cerintele functionale;
sa se determine cerintele non-functionale;
arhitectura business trebuie sa actioneze ca element de baza in realizarea etapelor de analiza si design
pentru modelarea software;
sa se identifice elementele/componentele potrivite.

4. Principii de realizare a arhitecturii software.

realizarea sistemului ca un grup compact de subsisteme bine definite, cu interfee clare i
explicite. Fiecare functionalitate trebuie s fie dezvoltata n interiorul unui sistem/subsistem;
realizarea dezvoltarii individuale a fiecarui sistem/subsistem;
crearea de dependene simple, unidirecionale ntre subsisteme i eliminarea dependenelor
reciproce;
crearea de mecanisme clare i simple pentru comunicatie ntre subsisteme;
sincronizarea efectuarii taskurilor paralele, n cadrul general definit de sistem i subsisteme;
alegerea soluiilor tehnice cu interfee corespunztoare, care permit actualizarea facila;
facilitarea vizualizarii i asimilarii produselor finale.
5. Tipuri de sisteme informationale.
Sistemele informationale tradiionale sunt sistemele deja existente i integrate n sistemele de afaceri. n
acelai timp, odat cu apariia unor noi cerine sau servicii, aceste sisteme trebuie s fie adaptate i
dezvoltate. Sisteme tradiionale reprezint investiii anterioare i, uneori, adaptarea unui sistem existent
poate determina apariia unor rezultate pozitive cu scderea semnificativ a costurilor financiare, de timp, de
resurse umane.
Sistemele informationale standard sunt sisteme vandute de diversi furnizori specializai. Aceste sisteme
sunt tipice n funcionare, avand avantajul unor costuri reduse de achiziie i de punere n aplicare, dar au
dezavantaje c, de regul, ele nu sunt optimizate in functie de tipul de activitate. Acestea sunt preferate de
firmele mici, la nceputul activitii sau de cele care au activitate redus.

Sistemele informationale noi sunt create i dezvoltate special pentru afaceri. Procesul este mai lung i
complex, cu costuri financiare i umane mai mari. Aceast alternativ este utilizata de firme cu activitate
solida, care au diverse i suficiente resurse.
6. Legatura dntre arhitectura afacerii i arhirtectura software.
Identificarea cerinelor funcionale reprezint punctul central al legturii dintre modelul de afacere i
modelul software. Prin intermediul cazurilor de utilizare se poate proiecta comportamentul diferi ilor actori
din sistem. Interaciunile pot aprea ntre actori, actori i cazuri de utilizare i ntre cazuri de utilizare.
Identificarea i reprezentarea corect a cazurilor de utilizare poate duce la o bun reprezentare a cerin elor
funcionale ale sistemului. Omiterea sau reprezentare greit poate determina nerealizarea funcionalitatilor,
n parte sau n totalitate i implicit funcionarea defectuoasa a sistemului.
Identificarea cerinelor non-funcionale nu este legat, de obicei, de funcionalitati sau de cazuri de
utilizare. Aceste cerine reprezint proprieti generale, ele nu sunt specifice pentru un anumit sistem sau
subsistem, dar sunt aplicabile la nivelul unei firme.
Aceasta se refer la urmtoarele aspecte: calitate, disponibilitate, securitate, folosirea resurselor,
elemente de eficien i randament.
Cerinele funcionale i non-funcionale sunt descrise la nivel de sistem i subsistem i sunt incluse n
specificaia cerinelor. Ele reprezint o proiecie ale opiunilor clienilor catre proiectant.
7. Rolul managerului n implementarea si designul sistemelor informationale.
Pentru a aplica eficient tehnologia informaiei, managerul trebuie:
sa inteleaga tehnologiile i s fie capabil sa vada aplicaiile lor, care au un rol important n rezolvarea
problemelor lor de afaceri;
s ia n considerare updatatea sistemului informational, la nivel de departament, cat si la nivel operational,
dar n acelasi timp, este important sa actualizeze/schimbe procesele fundamentale de lucru i rela iile cu
clienii i furnizorii firmei, in functie de evolutia pietii;
sa se asigure c tehnologia informaiei este privita mai ales din perspectiva de coordonare a planului de
afaceri strategic al firmei, decat punct de vedere al perspectivei tehnice.
8. Etape ale evoluiei sistemelor informatice n cadrul firmei - modelul Gibson-Nolan
1. Iniierea - Computerul este introdus n firm.
2. Erupie - O perioad de cretere rapid i necontrolat a numrului i tipurilor de aplicaii dezvoltate
pentru sistemele informatice.
3. Controlul - Top managementul cstig controlul asupra resurselor sistemului informatic prin
implementarea standardelor i proceselor de control formal care definesc limitele oricrui nou proiect n
cadrul sistemului informatic.
4. Integrarea - Utilizarea resurselor informatice crete rapid, oferind noi beneficii i susinnd strategia
global a firmei.
5. Administrarea datelor - Datele sunt recunoscute ca fiind o resurs important a firmei. n aceast faz se
depun eforturi pentru gestionarea datelor.
6. Maturitatea - Managerii de afaceri i managerii sistemelor informatice sunt n egal msur responsabili
pentru identificarea i capitalizarea oportunitilor de a utiliza tehnologia sistemelor informatice.
2

9. Cerinele instrumentelor CASE n viziunea unor autoriti n domeniu

Ed Yourdon consider c, pentru dezvoltarea unui produs CASE, trebuie urmrite urmtoarele
elemente:
flexibilitatea diagramelor
buna verificare a erorilor
pre sczut
animaie, care s permit crearea diagramelor i apoi simularea comportamentului sistemului prin simpla
executare a acestora.
Larry Constantine consider c un produs CASE se caracterizeaz prin:
design suficient de aprofundat pentru a surprinde toate detaliile
operaiile simple trebuie s fie uor de executat
deplasarea cu uurin n cadrul proiectului, ntre modele diferite
modelarea neliniar, iterativ, a procesului de explorare a unui sistem real i evoluia acestuia
Peter Coad consider urmtoarele elemente importante:
este susintorul C++
susine c modelul grafic trebuie reprezentat ntr-o fereastr iar codul C++ n cealalt
sincronizarea ntre ferestre trebuie realizat n mod continuu, chiar cnd se lucreaz ntr-o singur
fereastr
Grady Booch cosider c un instrument CASE trebuie s fie strns legat de instrumentele care genereaz
codul programului (back-end CASE), att n faza de concepie a sistemului informatic (forward
engineering), ct i n faza de izolare a componentelor unui sistem funcional (reverse engineering).
Totodata Booch pune accentul pe urmtoare elemente:
o strns legtur ntre semantic i notaie
cuplarea cu alte instrumente via API-uri, mecanisme de genul OLE, scripte
suport multiutilizator
James Rumbaugh susine c transparena este elementul cheie care trebuie s predomine la un instrument
CASE. Dintre caracteristicile obligatorii trebuie realizat un echilibru ntre facilitile oferite utilizatorului i
sarcinile de lucru ale acestuia. Prea multe optiuni de lucru sau un meniu stufos duc la ngreunarea procesului
de proiectare. Totodata nu trebuie realizat o automatizare completa, ci trebuie automatizate procesele mai
simple i furnizat o cale direct prin care s poat fi duse la ndeplinire i sarcinile mai dificile.
Stephen J Mellor i Rod Montrose, consider c un instrument CASE trebuie s se caracterizeze prin:
suport pentru grupuri de lucru (analiza este o activitate specific de grup)
controlul configuraiilor, cel puin la nivel de diagram;
flexibilitate n raportare i tiprire;
abilitatea de a vizualiza mai mult diagrame pe acelasi ecran;
integritatea bazei de date, prin auto-verificare i reparare, utilitare de administrare i securitate pe mai
multe nivele;
component specializat n verificarea critic a detaliilor modelelor de analiz;
suport pentru simularea i executia fiecrui grup de modele de analiz asociate domeniilor
3

10. Funciile produselor CASE

1. Realizarea automat a documetaiei sistemului. Documentaia i specificaiile sistemului se pot obine pe
baza repository.
2. Automatizarea parial sau total a fazelor de analiza i proiectare a sistemelor. Au ca rezultat creterea
calitii sistemelor, eliminarea erorilor, scurtarea ciclului de via a sistemelor.
3. Coordonarea i managementul proiectelor de dezvoltare a sistemelor. Membrii echipei de proiectare pot n
orice moment obine informaii cu privire la stadiul n care s-a ajuns i la etapele de proiectare, realizate sau
planificate.
4. Generarea automat a codului surs al aplicaiilor. Se folosesc generatoarele de coduri incluse n CASE i
limbaje din generaia a IV-a.
11. Componentele instrumentelor CASE
Componentele instrumentelor CASE care permit s se realizeze aceste funcionalitti sunt:
baze de informaii (repository);
editoare de diagrame;
analizoare de structur;
generatoare de cod;
instrumente pentru reverse engineering;
browsere specializate.
Dintre aceste componente, primele dou sunt obligatorii, celelalte opionale.

12. Definiti riscul IT.

n general, riscul se refer la acele elemente, att tehnice cat i manageriale, care sunt elemente ale
succesului sau o surs major de probleme pe/ale proiecte software. American Heritage Dictionary define te
riscul ca "posibilitatea de a suferi prejudicii sau pierdere".
13. Definiti management riscului si riscul software.
Managementul riscului este un proces care include identificarea, analiza , planificarea , urmarirea , controlul
i comunicarea de risc .
In viziunea Donald Reefer , de gestionare a riscurilor poate fi definit ca procesul de identificare a surselor de
probleme pentru proiect , a le analiza , cuantificarea efectelor acestora , precum i planuri care contracareaz
efectele negative ale acestora de punere n aplicare .
Barry Boehm definete manag riscului n doi termeni : evaluarea riscurilor i de controlul riscurilor .
Evaluarea riscurilor include :
- Identificarea risk - crearea unei liste a tuturor potenialelor pericole care pot afecta proiectul ;
- Analiza risk - evaluarea probabilitii de apariie i pierderea potenial a fiecrui element listate ;
- Prioritizare risk - , regizate de produsele din cele mai la cel mai puin periculos .
Controlul riscurilor include :
- Planificarea de management isk - stabilirea tehnicile i strategiile pentru a reduce riscurile cele mai mari
comandate ;
- Rezoluia risk - punerea n aplicare a strategiilor pentru a rezolva ordinea ridicat riscurile factori;
4

- Monitorizarea risk - monitorizarea eficienei strategiilor i nivelurile schimbare de risc pe parcursul

proiectului
14. Caracteristicile riscului IT.
Tipurile de riscuri it/caracteristicile utiliznd drept criterii de condiiile de operare de afaceri care le pot
produce sunt:
Riscuri pe termen lung - rezultat din mprejurri la nivel mondial i naional i transnaional
legislatie i reglementare.
riscuri medii - rezultat din schimbrile de pe pia i concurena.
riscuri scurte - rezult din interaciunile cu clienii, furnizorii i partenerii.
riscuri in curs de desfasurare - generate de utilizarea normal i funcionalitatea proceselor, sistemelor i
reelelor.
Perioada de timp asociate cu aceste tipuri de riscuri sunt: ani, luni, zile si ore sau minute, respectiv.
15. Controlul si responsabilitatea pentru riscul IT.
Problema de control al riscurilor IT este foarte important pentru o companie .
Controlul va fi tratat pe parcursul a trei viziuni : ameninri, vulnerabiliti i impact .
Acestea implic urmtoarele aspecte :
- Controls care va detecta ameninri i probleme n timp util i va anticipa sau prevenire a acestora
acolo unde este necesar i adecvat
- Controls care vor permite vulnerabilitile s fie stabilit i punctele slabe ale sistemului rezolvate
- Controls s gestioneze impactul orice probleme sau ameninri care au reuit n exploatarea
vulnerailitatilor sau punctelor slabe nerezolvate
Responsabilitatea pentru controlul riscurilor IT aparine tuturor departamentelor de companie , de la
departamentele de servicii IT pana la departamentele de organizare de afaceri .
Pentru departamentele IT , principalele activiti de gestionare a riscurilor sunt :
- detectare si prevenire
- Fixare vulnerabilitate i rspuns
- recuperare
Pentru departamentele de organizare a afacerilor , principalele activiti de gestionare a riscurilor
sunt :
detectare strategic
management de program
analiza de risc
16. Auditul obiectivelor informatice
Trebuie analizat n mod realist n ce masur informatizarea poate sau nu s susin activitile de control
i decizie n gestiune.
n acest scop, trebuie cunoscute cu precizie concepia, dezvoltarea, controlul, instalarea i exploatarea
sistemului, pe baza documentaiei elaborate i a discuiilor cu participanii.
Vor fi puse n eviden att avantajele i condiiile de realizare dar i constrngerile tehnice i
organizaionale, recunoscnd toate neajunsurile.

17. Auditul mijloacelor tehnice i al locaiilor

Mijloacele tehnice cuprind materialele, localizarea acestora, reelele i programele de baz.
Trebuie neles modul de evoluie al proceselor, materialele destinate prelucrrii informaiei, suportul
fizic al acestora, localizarea echipamentelor. Sistemele de prelucrare n timp real dispun de echipamente
electronice ca: interfee seriale/paralele, magistrale cu protocoale aferente, traductoare active/pasive, circuite
adaptive, amplificatoare, convertoare analogice/digitale. ntr-o reea trebuie definite liniile de transmisie cu
debit variabil (electrice, hertziene, radio, optice) cu protocoalele de care dispun, dar i localizarea
dispozitivelor ca routere, multiplexoare, concentratoare, modemuri.
Adaptarea locaiilor are la baz urmtoarele principii [THOR00]:
dispunerea logic a echipamentelor, a stocurilor de mobilier, a circuitelor, urmrind ergonomia posturilor
de lucru;
izolarea termic i fonic;
adoptarea unor msuri de climatizare i eliminare a condensului, prafului, fumului, meninerea cureniei.
n condiiile n care dimensiunea echipamentelor se diminueaz, numrul i complexitatea acestora
crete. Accesul n aceste locaii este permis numai persoanelor autorizate, fiind totodat restricionat
comunicarea cu exteriorul. Se vor avea n vedere riscurile unor cauze naturale: incendii, inundaii, pene de
curent, temperaturi extreme ale mediului, depozitarea unor substane chimice etc.
Echipamentele trebuie s fie fiabile, funciunile i rezultatele furnizate fiind exacte. Echipamentele
trebuie s fie protejate, fr pri separate i utilizate conform instruciunilor. Pentru echipamentele cu
funciuni critice, o soluie este crearea sau plasarea unor echipamente n paralel, care, la nevoie, s poat
prelua imediat sarcinile celor care prezint erori de funcionare. Serverul oglind are periodic (zilnic) sau
permanent actualizate conturile clienilor cu tranzaciile efectuate n ziua curent. Intr n funciune numai n
situaii critice, cnd apar blocaje pe reea, cderi ale reelei sau accidente. Totodat, pe serverul oglind sunt
permise teste cu privire la up-gradarea sistemului informatic, pe directoare/fiiere dedicate.
18. Auditul ntreinerii echipamentelor
ntreinerea echipamentelor este apreciat n funcie de gradul de utilizare a sistemelor n bune condiiuni
comparativ cu disponibilitatea lor. ntreinerea privete att partea fizic a sistemelor ct i partea logic.
Programele trebuie periodic testate, eliminate informaiile redundante sau arhivate informaiile care nu
mai au grad de actualitate.
ntreinerea fizic privete n primul rnd utilizarea echipamentelor n condiiile specificate de furnizor
(cu privire la sursa de alimentare, conexiuni, condiii climatice), curarea/ungerea pieselor mecanice
(hardware, imprimante).
19. Auditul reelelor de calculatoare
O reea este alctuit dintr-un ansamblu de computere, routere, servere, concentratoare i multiplexoare
care vor fi gestionate de un sistem de programe.
Se pun n eviden fluxurile informaionale ntre componente dar i n legatur cu mediul extern.
Trebuie avute n vedere erorile care pot apare la nivelul reelei privind prelucrarea sau transmisia datelor
(erori de conexiune), ns trebuie inut cont i de faptul c riscurile privind penetrarea neautorizat cresc
odat cu mrimea reelei. n acest sens, trebuie studiate i implementate metode i algoritmi de criptare care
vor aduce un plus de siguran mpotriva utilizrii neautorizate a unei informaii accesat ilegal.
6

20. Auditul programelor de baz

Programele de baz reprezint elementele eseniale ale sistemelor informatice i privesc gestionarea
proceselor i a echipamnetelor care sunt n concuren i n acelai timp n cooperare. Subsistemele sale
controleaz funcionarea procesorului i realizeaz gestionarea memoriei interne, a fiierelor i a bazelor de
date, intrrile/ieirile i reeaua.
Programele de baz trebuie alese n funcie de scopurile propuse.
Astfel, programele prea simple pot pune programatorii n imposibilitatea de a crea proceduri de
prelucrare i obinerea unor date cu suficiente atribute, pe cnd utilizarea unor programe prea complexe pot
determina apariia unor erori umane de programare. Mai mult, o parte din facilitile oferite de programele
complexe sunt prea puin utilizabile n realizarea scopului propus.
21. Auditul resurselor umane
Problematica resuselor umane este delicat.
Motivarea pentru o bun funcionare a sistemului este o clauz esenial.
Politica de salarizare determin creterea interesului lucrtorilor, asumarea de iniiative i
responsabiliti, crearea unui sentiment de ambiie. Trebuie analizate cauzele care pot produce prsirea
colectivului prin demisie, transfer, abandon.
Organigrama de personal stabilete fie ale posturilor, cu drepturi i obligaii riguros definite.
Se impune desemnarea unui director de proiect care i va nsui politica i obiectivele bncii, va stabili
mijloacele necesare, va coordona dezvoltarea i implementarea aplicaiilor, se va preocupa de ntreinerea i
evoluia sistemului. Se vor constitui echipe cu personal cu pregtire adecvat i responsabiliti bine
precizate. Ca regul, funciunile sistemului trebuie separate pe grupe de lucrtori, grupe dedicate activitilor
de proiectare, realizarea aplicaiilor, exploatarea aplicaiilor, arhivarea informaiilor procesate.
Auditul resurselor umane pune n corelaie grija privind condiiile de lucru i politica motivaional.
22. Auditul resurselor financiare
Resursele financiare privesc costurile determinate de:
achiziia echipamentelor, instalaiilor, locaiilor, elementelor de telecomunicaie, aparatelor de msur i
control, testelor, utilitarelor i documentaiilor aferente;
studiile i analizele ce au n vedere dezvoltarea sistemului;
crearea echipelor de informaticieni i organizarea privind viitorii utilizatori ai sistemului;
funcionarea i ntreinerea sistemului;
funcionarea n paralel a dou sisteme (vechi i nou) odat cu implementarea unui sistem evoluat.
23. Auditul metodelor de dezvoltare i exploatare
Fezabilitatea i evoluia metodelor este transpus n portabilitatea aplicaiei i a modului de exploatare
(reea, timpi reali de rspuns), formarea personalului.
Metodele trebuiesc apreciate pragmatic:
nici perfecioniste, cu proceduri rigide, dar nici cu o concepie haotic;
nici o mentenan excesiv, dar nici redus.
Elementele metodelor trebuiesc aplicate flexibil, cu costuri rezonabile.
7

Auditorul examineaz:
planificarea, folosind urmtoarele criterii: existen, precizie, actualizare;
calitatea produsului final, gestionarea acestuia, coreciile efectuate;
existena regulilor de aciune, concretizate prin proceduri de aplicare;
control, gestiunea etapelor, organizare i mentenan;
mijloacele de verificare a conformitii rezultatelor;
controlul integritii informaiei i a confidenialitii;
cerine de mentenan (cauze i soluii);
documentare i arhivare.
24. Auditul exploatrii sistemelor
La instalare, se face transferul responsabilitilor aplicaiei de la realizator la utilizator i trebuie depite
etapa de validare i criteriile de abandon a vechiului sistem.
Pe perioada exploatrii, vor fi urmrite:
timpii de rspuns.
timpii de rspuns;
numrul i repartiia erorilor.
Punctele critice sunt::
Evoluia este determinat de limitri:
memoria;
capacitatea de stocare;
debitul transmisiilor;
volumul transmisiilor de date;
numrul accesrilor la suport/resurse
25. Etape preliminare n audit
Auditul informatic reprezint o examinare a unui sistem informatic, n totalitate sau a unor componente,
pentru a emite o judecat de valoare. Auditul implic elemente materiale, logice, umane, financiare i
juridice.
Se execut rar asupra ntregului sistem, fiind efectuate de regul asupra unor pri.Fiecare obiect are o
parte automatizat i o parte manual, ns trebuie considerat n ansamblul su, sub toate aspectele, generate
de criteriile de calitate.
Strategii ale auditului sistemelor informatice [ALIE03]:
Auditarea cu ajutorul calculatorului - Auditorul prelucreaz un eantion de test format aleator, similar
tranzaciilor din sistem. Rezultatele obinute de auditor se compar cu rezultatele prelucrrii sistemului
auditat.
Auditarea n afara calculatorului - Similar celor prezentate anterior, cu precizarea c prelucrarea se
realizeaz manual. Dei este mai puin costisitoare i nu necesit resurse tehnice, aceast strategie este mai
greoaie i presupune un consum mare de timp. Totodat, ea depinde de subiectivitatea auditorului n alegerea
eantionului de test.
Auditarea prin calculator - Se stabilete apriori un eantion de date de test, similar tranzaciilor din sistem,
dar cu un domeniu de valori mult mai larg. Rezultatele obinute de auditor se compar cu rezultatele
previzionate. Avantajele acestei strategii rezult din faptul c se poate urmri funcionarea sistemului i
prelucrrile efectuate n condiii critice sau n cazuri cu frecven redus.

26. Metode de audit

8

Factori generatori ai procesului de auditului:

cadru legal revizie obligatorie;
definit de o direcie misiune contractual sau punctual;
o solicitare legal expertiza judiciar.
Scopul activitii de audit:
oportunitatea informatizrii unei funcii;

examinarea cauzelor erorilor;

decizia de nlocuire a unui material/modul;

analiza repartiiei costurilor;

verificarea fiabiliti unui modul;

examinarea condiiilor de lucru;

 verificarea suficienei documentaiei

Auditul urmrete fiabilitatea sistemului informatic n ansamblul su, de la politic i clasificarea
informaiilor, pn la faza de exploatare, dar i evoluia acestuia. Auditorul va propune metode de urmrire
privind evoluia n viitor a sistemului, va pune n eviden punctele forte i punctele slabe.
Auditul va permite s se determine:
contextul sistemului informatic (importan, loc, complexitate, schimbri anterioare);
calitatea utilizatorilor (pregtire, ncredere, implicaii personale);
control intern (riscuri, puncte de control, identificarea limitrilor, evaluarea impactului);
ecartul ntre obiective i proceduri de lucru.
27. Etapele derulrii procesului de audit
Scrisoarea de intenie (audit extern) sau planul previzional (auditul intern). Aceasta trebuie semnat de
ctre conducere. Auditul extern se poate face la cererea conducerii sau la solicitarea unui organism de
control.
Scrisoarea de misiune sau programul final
Obiectivele, mijloacele de aciune i termenele sunt elemente contractuale n aceste documente. Trebuie
precizate foarte clar numrul, calificarea i natura investigaiilor, timpul total alocat pentru realizarea
raportului de audit, resursele solicitate (materiale, documentaie, personal).
Resursele auditorului
Dei mijloacele de care dispune auditorul sunt numeroase (tehnice i umane), ele sunt limitate de bugetul
atribuit (exprimat, n ore de munc de regul). Consultarea raportului de audit anterior poate fi important,
prin corelarea evoluiei firmei n raport cu concluziile raportului.
Raportul de audit
Este de preferat s fie fcut n dou etape: proiectul de raport i raportul definitiv. Raportul trebuie s fac
referire la scrisoarea de intenie i scrisoarea de misiune, programul de lucru, lista de documente utilizate,
lista colaboratorilor, dificultile ntlnite. Corpul raportului trebuie s expun problemele clar, demersul
adoptat i opiniile asupra fiecrui punct. Fiecare dintre acestea trebuie argumentate i motivate: explicaii
clare, i n caz de erori/defeciuni, analize asupra cauzelor i soluiile de remediere.
Recomandrile trebuie s fie acceptabile economic i dirijate n termeni comprehensibili ctre destinatari.
Soluile se exprim schematic n sensul de aciune, iar detaliat pentru specialiti, prin elemente specifice.

Urmarea raportului de audit

Consecina fireasc este aplicarea recomandrilor raportului. Trebuie specificate responsabilitile aciunilor
corective, etapele, termenele i participanii. Este de dorit o asisten post-audit, intern sau extern.
Pe piaa serviciilor financiare, exist societi care au ca obiect de activitate contabilitatea, consultana i
auditul financiar. Este necesar ca aceeai societate s nu desfaoare activitate de consultan i audit
aceluiai client. Activitatea de audit trebuie privit ca o activitate critic, de eviden i nlturare a
anomaliilor unor sisteme (manageriale, financiare, informatice).