Artykuły, tutoriale, wsparcie dla programistów
March 18, 2014, 10:12 am

Audyt techniczny. Czyli jak sprawdzić jakość prac dostawcy IT?

Instytucja zlecająca realizację prac IT z definicji pragnie, by jakość tych prac była jak najlepsza, a wymagania dotyczące produkcji systemu oraz samego produktu spełnione na odpowiednim poziomie. Zapewnienia i deklaracje dostawcy to jedno – a uzyskanie konkretnych, obiektywnych dowodów spełnienia wymagań to co innego.

Autor: Karolina Zmitrowicz
Źródło: Software Developer’s Journal 03/2010 (183) http://sdjournal.org

Jak jednak klient może sprawdzić, czy prace projektowe i ich poszczególne produkty odpowiadają jego oczekiwaniom i wymaganiom? Nierzadko instytucja zlecająca realizację usług IT nie posiada odpowiednich zasobów, by móc zweryfikować jakość np. procesu wytwórczego czy zgodności architektury z ustaleniami kontraktowymi. Może nie mieć personelu o odpowiednich kompetencjach lub możliwości technicznych sprawdzenia pewnych kwestii – może też pragnąć (z różnych względów, w tym tzw. politycznych), by kontrola taka wykonywana była przez zespół całkowicie niezależny i obiektywny. Rozwiązaniem tego problemu jest audyt techniczny. Umożliwi on niezależną ocenę procesów, produktów i innych obszarów projektu realizowanego przez dostawcę IT – weryfikację zgodności z wymaganiami, identyfikację błędów i usterek oraz dostarczy rekomendacji czy zaleceń, które – wdrożone przez dostawcę – ulepszą jakość prac.

Rysunek 1. Plan audytu

Rysunek 1. Plan audytu

Audyt – ale co to jest?
Zgodnie z definicją audyt jest oceną i weryfikacją pewnych hipotez. W kontekście projektu IT hipotezą taką może być:
• zarządzanie projektem zgodnie z określonym standardem;
• stosowanie ustalonych procedur zarządczych (np. procedur zarządzania zmianami);
• stosowanie wytycznych określonych standardów IT (np. standardów dotyczących dokumentacji, testowania);
• wykorzystywanie odpowiednich narzędzi w pracach projektowych;
• kod źródłowy zgodny ze standardami (np. zgodny z wytycznymi kodowania w Java).

W jakim celu wykonuje się audyt? Powody mogą być następujące:
• by upewnić się, że rzeczywiste prace realizowane w ramach projektu odpowiadają zadeklarowanym w kontrakcie, a ich jakość spełnia wymagania klienta;
• by sprawdzić, czy jakość poszczególnych produktów odpowiada zapewnieniom dostawcy i oczekiwaniom klienta;
• by ujawnić problemy występujące w różnych obszarach projektu i móc je wyeliminować.

Audyt nie jest oceną ogólną – wykonywany jest na podstawie określonych danych wejściowych, wymagań, standardów etc. Przygotowanie audytu polega na opracowaniu testów, list kontrolnych czy metod obserwacji, które obejmują wszystkie wymagane aspekty kontroli – np. jeśli audyt dotyczy dokumentacji, audytor musi sprawdzić:
• czy dokumentacja utrzymywana przez dostawcę odpowiada zapisom umowy;
• czy dokumentacja przechowywana jest w sposób odpowiedni do udokumentowanych wymagań;
• czy narzędzia wykorzystywane do tworzenia i zarządzania dokumentacją to te, które były deklarowane w umowie/uzgodnieniach;
• czy format dokumentów jest zgodny z założeniami;
• czy jakość rozumiana jako kompletność, jednoznaczność, spójność, przejrzystość jest zachowana;
• czy obieg dokumentacji jest spójny z wymaganiami etc.

Tabela 1. Harmonogram audytu – dzień 1

Tabela 1. Harmonogram audytu – dzień 1

Pytania te muszą zostać zadane – niekoniecznie dosłownie: większość tzw. dowodów zbiera się podczas wywiadów i obserwacji – a odpowiedzi zanotowane celem dalszej analizy. Nieraz obserwacja dostarcza więcej informacji, niż słowa – ponieważ umożliwia obserwację rzeczywistych zachowań, wyników i praktyk, a nie teorii czy pobożnych życzeń.

Postawione powyżej przykładowe pytania kontrolne nie wydają się szczególnie skomplikowane. Czy zatem rzeczywiście konieczne jest zlecanie audytu instytucji zewnętrznej? Czy organizacja klienta nie jest w stanie samodzielnie wykonać oceny prac dostawcy?

Odpowiedź brzmi – może i nie może. Decyzja zależy w dużym stopniu od celu postawionego przed audytem, zależności pomiędzy klientem a dostawcą, zasad obowiązujących w instytucji klienta. W przypadku gdy klient ma uzasadnione wątpliwości co do jakości prac dostawcy i przestrzegania przez niego ustaleń umowy, wskazane jest zlecenie audytu zewnętrznego. Dlaczego? Ponieważ wyniki takiego audytu będą obiektywne i klient uniknie posądzeń o próbę manipulacji.

Wspomnieliśmy o audycie zewnętrznym – jest i wewnętrzny, czyli audyt przeprowadzany przez ludzi z organizacji klienta. Audyt taki ma sens, jeżeli zespół audytujący posiada kwalifikacje odpowiednie do postawionego celu i jest w stanie rzetelnie ocenić dany przedmiot. Często audyt wewnętrzny jest jedynie pierwszą fazą całościowej procedury audytu, mającą na celu zidentyfikowanie podstawowych zagrożeń, braków i usterek występujących w określonych procesach, infrastrukturze, produktach etc. Zazwyczaj zakończenie procedury audytu wewnętrznego wiąże się z podjęciem decyzji o zamówieniu całościowego audytu informatycznego u zewnętrznej wyspecjalizowanej firmy.

Audyt zewnętrzny przeprowadzany jest znacznie sprawniej niż wewnętrzny, jako że organizacje zajmujące się tym zawodowo mają doświadczenie i metodologię pozwalającą na znaczne skrócenie procedury audytu. Bardzo istotną cechą audytu zewnętrznego jest brak ryzyka stronniczości – gdyż dokonywany jest przez niezależną instytucję – dzięki czemu wyniki oceny lepiej i pełniej oddają stan rzeczywisty. Rekomendacje audytorów zewnętrznych są też z reguły trafniejsze (co wynika głównie z doświadczenia) i umożliwiają realne usprawnienie wadliwych obszarów.

Rodzaje audytów to nie tylko wewnętrzny i zewnętrzny – audytów w IT jest wiele (ramka), w zależności od postawionego celu i tego, co zlecający ocenę chce osiągnąć.

Wiemy już, czym jest audyt, przejdźmy teraz do tego, jak go przygotować i wykonać.

Tabela 2. Lista kontrolna dla procesu testowania

Tabela 2. Lista kontrolna dla procesu testowania

Procedura audytu

Przygotowanie i zakres audytu
Audyt, podobnie jak każde przedsięwzięcie, musi zostać odpowiednio zaplanowany i przygotowany. Etapy realizacji audytu można określić poprzez następujące punkty:

• Określenie celu i zakresu audytu.

Czynność ta należy do organizacji zlecającej audyt i polega na określeniu, co ma być przedmiotem oceny oraz na podstawie jakich kryteriów będzie ona wykonywana. Wskazane jest też sprecyzowanie produktów prac (np. raportów).

• Wybór jednostki audytującej.

Zlecający audyt dokonuje wyboru jednostki audytującej. Audytorzy powinni pochodzić z firmy specjalizującej się w danym typie audytu – lub posiadający odpowiednie kompetencje, by taką ocenę wykonać. Zdarza się, że audyt nie jest realizowany przez firmę konsultingową, zajmującą się tylko i wyłącznie wykonywaniem audytów. W przypadku np. opisywanego tu audytu technicznego projektu IT, klient może zlecić audyt innemu dostawcy IT – przy założeniu, że:

  • dostawca ów nie jest powiązany z dostawcą poddawanym audytowi;
  • pracownicy firmy, która będzie realizować audyt, posiadają kwalifikacje i niezbędne umiejętności w zakresie prowadzenia audytu;
  • sam dostawca dysponuje zasobami i mechanizmami umożliwiającymi poprawne wykonanie oceny;
  • klientowi nie zależy na uzyskaniu certyfikatu z wykonanego audytu i nie ma przymusu angażowania wyspecjalizowanej firmy audytującej.

• Dobór zespołu audytującego

Na audytorach spoczywa odpowiedzialność za proces obiektywny, niezależny i wiarygodny. Zgromadzenie dowodów obiektywnych, pomoc w wykryciu przyczyn źródłowych, informacja zwrotna, sugestie dotyczące doskonalenia procesów, zasugerowanie działań korygujących to podstawowe cele audytu. Zespół audytujący musi składać się z ludzi będących w stanie ocenić dany przedmiot – dlatego też zwykle audyt realizowany jest przez kilku audytorów, przy czym każdy zajmuje się inną specjalnością.

• Analiza informacji wejściowych

Polega na zebraniu przez zespół audytujący danych stanowiących podstawę do wykonywania oceny (kryteriów audytu) i opracowaniu ich w takiej postaci, by mogły służyć jako mechanizmy przeprowadzania audytu. Czyli – jeżeli audyt dotyczy oceny procesu testowania wewnętrznego (funkcjonalnego) dostawcy, danymi wejściowymi będą np.:

  • plan projektu – z uwzględnieniem czasu przeznaczonego na testy, by skonfrontować go następnie z rzeczywistym czasem trwania testów oraz zapisami planu testów;
  • plan testów (wraz z wybranym podejściem do testów np. black box, podejście oparte na wymaganiach; harmonogramem testów, składem zespołu testującego, kryteriami wejścia/wyjścia testów);
  • projekt testów (czyli zbiór przypadków i scenariuszy testowych – analizowany celem identyfikacji pokrycia funkcjonalności testami);
  • wykaz narzędzi stosowanych do zarządzania testami i wspierania raportowania (by określić, czy narzędzia owe są rzeczywiście wykorzystywane w procesie testowym i w jakim stopniu);
    dokumentacja procedur – np. obsługi zgłoszeń błędów, żądań zmian etc.

Informacje zawarte w danych wejściowych należy przetworzyć celem ustalenia punktów kontroli (tzn. istotnych elementów procesu, które będą poddawane audytowi), które w następnej kolejności umożliwią opracowanie formularzy, list kontrolnych przeznaczonych do dalszego wykorzystania już podczas przeprowadzania audytu.

• Opracowanie harmonogramu audytu

Audyt nie może odbywać się ad hoc, bez ładu i składu, audytorzy nie mogą biegać bezładnie po całej placówce, odpytując raz jedną osobę, raz drugą. Plan przeprowadzania poszczególnych działań audytowych powinien być jasno określony i zakomunikowany audytowanym przed rozpoczęciem oceny.

Harmonogram uwzględnia wykonanie wszystkich zaplanowanych działań audytowych, przez wszystkie osoby wykonujące ocenę i dla wszystkich obszarów/przedmiotów oceny. Każdy dzień audytu powinien rozpoczynać się spotkaniem otwierającym, które angażuje uczestników audytu (zarówno ze strony audytującego, audytowanego, jak i klienta) i polega głównie na przedstawieniu planu działań na dany dzień.

Podobnie – każdy dzień audytu kończy się spotkaniem zamykającym, na którym przedstawiane są wyniki dotychczasowej oceny, wynikłe problemy, uwagi, spostrzeżenia.

• Przygotowanie list kontrolnych

Na podstawie danych wejściowych – dokumentacji, informacji ustnych – audytor opracowuje listy kontrolne i formularze. Powinny one zawierać co najmniej:

  • pytanie kontrolne;
  • referencję do dokumentu związanego/punktu normy, który jest weryfikowany za pomocą danego pytania;
  • pole do odnotowania uwag i spostrzeżeń.

Przykładowe pytania kontrolne (dotyczy audytu procesu testowania):

  • jakie etapy testowania wykonuje się w ramach projektu;
  • na czym oparte są scenariusze i przypadki testowe;
  • w jaki sposób zapewnione jest wymagane pokrycie funkcjonalności testami;
  • w jaki sposób wykonywane są testy i raportowane ich wyniki.

Jak widać, pytania kontrolne są otwarte – czyli umożliwiają audytowanemu udzielenie swobodnej odpowiedzi, bez ograniczania możliwości wypowiedzi i narzucania czy sugerowania odpowiedzi właściwej. Pytanie typu: czy wykonujecie testy zgodnie z planem testów nie jest pytaniem właściwym, jako że sugeruje odpowiedź. Audytor powinien samodzielnie ocenić zgodność stanu rzeczy na podstawie udzielonych, pośrednich odpowiedzi i własnych obserwacji. Nie wystarcza więc tylko pytać – ustne deklaracje należy zweryfikować np. w przypadku pytania: jakie narzędzia służą do zarządzania testami, należy sprawdzić, czy rzeczywiście takie narzędzie jest wykorzystywane. Jak? Po prostu prosząc audytowanego o pokazanie owego narzędzia na stacji roboczej i wglądzie w jego zawartość (repozytorium testów).

• Przeprowadzenie audytu i zbieranie danych

Przeprowadzenie audytu musi opierać się na konkretnych podstawach, by uzyskane odpowiedzi pozwalały jednoznacznie i rzetelnie ocenić dany problem. Audytor przeprowadza wywiady i dokonuje obserwacji, posługując się opracowanymi przez siebie formularzami i listami kontrolnymi. Dokumenty te zawierają pytania kontrolne dotyczące każdego elementu istotnego dla dokonania oceny – audytor przeprowadza wywiad, opierając się na owych pytaniach, w razie konieczności już w trakcie dyskusji z audytowanym, dodając nowe pytania i uwagi oraz odnotowując uzyskane odpowiedzi. Wypełnione listy kontrolne służą następnie do opracowania wyników – czyli stwierdzenia, które z elementów przedmiotu audytu są zgodne z założeniami, a gdzie wystąpiły niezgodności.

• Analiza i opracowanie wyników

Zebrane w trakcie audytu informacje należy poddać analizie celem określenia, czy stan rzeczy odpowiada wymaganiom i założeniom przyjętym dla oceny. Przykładowo, jeśli kryterium oceny dla testów funkcjonalnych jest używanie narzędzia JIRA do zarządzania błędami, a w wyniku wywiadu okazało się, iż stosowane jest inne narzędzie, należy wykazać to jako niezgodność i umieścić w raporcie końcowym z audytu. Zalecenia dotyczące ustaleń z audytu opisane są szczegółowo w punkcie 6.5.5 normy ISO/DIS 19011 Opracowanie ustaleń z audytu. Ustalenia z audytu dotyczącego zgodności i niezgodności oraz wspierające je dowody powinny być zapisywane; każde spostrzeżenie, informacje zdobyte w oparciu o obserwację czy uzyskane w rozmowie z audytowanym powinny być zanotowane. Powód jest prosty – pamięć ludzka jest zawodna, i nawet jeżeli audytor doskonale pamięta przebieg wywiadu dziś, może nie być w stanie przypomnieć go sobie jutro. A informacje z wywiadów czy obserwacji są podstawą do opracowania raportu końcowego z wyników.

W przypadku wykrytych niezgodności audytor powinien określić ich priorytet, czyli stopień, w jakim wpływają na jakość danych prac. Priorytety mogą być określane następująco:
• niski – niezgodność mająca znikomy wpływ na jakość procesu/produktu;
• normalny – niezgodność wpływająca negatywnie na jakość procesu/produktu, lecz nie krytyczna;
• krytyczny – krytyczne uchybienie w założeniach polityki jakości, rażący błąd etc.

Niezgodności o priorytecie niskim niekoniecznie muszą być usuwane, lub przynajmniej nie w pierwszej kolejności. Niezgodności krytyczne powinny być wyeliminowane jak najszybciej – w ściśle określonym terminie. Usunięcie niezgodności jest komunikowane klientowi i może być potwierdzone kolejnym audytem (np. jeżeli wykryto znaczną liczbę niezgodności krytycznych).

Analiza wyników audytu to nie tylko wykazanie zgodności i niezgodności – to również określenie zaleceń i rekomendacji służących udoskonaleniu wadliwych procesów czy produktów. Rekomendacje nie są przymusem, a ich wdrożenie obligatoryjne dla organizacji zlecającej audyt – mogą jednak w znaczącym stopniu usprawnić działanie instytucji czy wybranego obszaru.

• Spotkanie zamykające i raport dla klienta

Spotkanie zamykające to ostatni punkt audytu. Może odbyć się dopiero po wykonaniu wszystkich zaplanowanych działań audytowych, przeanalizowaniu wyników i opracowaniu raportu końcowego.

Niezgodności wykryte podczas audytu są komunikowane osobom odpowiedzialnym za audytowany obszar oraz zapisywane przez audytora wiodącego (na podstawie informacji uzyskanych od pozostałych audytorów) w odpowiednim dokumencie np. Protokole niezgodności.

Spotkanie zamykające prowadzone jest przez audytora wiodącego. Podczas tego spotkania omawiane są ustalenia, wnioski z audytu oraz mocne i słabe strony przedmiotu oceny.

Problemem, który może wystąpić w trakcie spotkania zamykającego, jest tzw. czynnik ludzki i reakcje na krytykę. Podczas wywiadów i obserwacji audytorzy są neutralni, skupiają się na zadawaniu pytań i wysłuchiwaniu odpowiedzi bez oceniania czy wyrażania własnej opinii bądź krytycznych uwag – spotkanie zamykające zmienia ten stan rzeczy: polega na jasnym, dosłownym i popartym dowodami wykazaniu braków, niezgodności i usterek. Nie wszyscy potrafią przyjąć krytykę bez emocji i prób udowadniania swoich racji. Zdarza się, iż audytowany reaguje na wytknięte błędy agresją – dlatego szczególnie ważne jest zebranie i przedstawienie niepodważalnych dowodów, faktów wystąpienia niezgodności. Audytor nie stawia wniosków na podstawie swoich przeczuć czy insynuacji – lecz na postawie faktów, których audytowany nie podważy.

Audytor nie może obawiać się przekazania swojej informacji zwrotnej – audyt to nie kontrola, a proces z założenia mający na celu doskonalenie organizacji. Tu nie szuka się odpowiedzialnych, winnych i nie ocenia – celem jest wskazanie miejsc, które wymagają ulepszenia i dostarczenie obiektywnej informacji zwrotnej o skali i rodzaju niezgodności.

Spotkanie zamykające to również ustalenie koniecznych działań korygujących i określenie terminów ich wykonania. Niezgodności zidentyfikowane jako krytyczne lub ważne dla jakości procesu powinny zostać usunięte i poddane kontroli zespołu audytowego.

• Weryfikacja skuteczności działań korygujących

Spotkanie zamykające audyt skutkowało ustaleniem pewnych dalszych działań, które polegają na usunięciu zaistniałych niezgodności. Za wykonanie tych działań w ściśle określonym terminie odpowiedzialni są wyznaczeni pracownicy (w tym przypadku dostawcy IT). Wyniki prac korygujących powinny być zakomunikowane zespołowi audytującemu i klientowi – a ich poprawność i kompletność zweryfikowana.

Audyt może być uważany za zakończony po usunięciu i potwierdzeniu poprawności wszystkich niezgodności, które zostały przekazane do korekty.

Podsumowanie
Audyt to nie kontrola, a audytorzy nie stawiają sobie za cel numer jeden pognębienie odpytywanego i udowodnienie mu, że źle wykonuje swoją pracę. Dobrze rozumiany audyt, z wyraźnie postawionym celem i profesjonalnym przygotowaniem, pomoże udoskonalić organizację i wyeliminować błędy, których być może ktoś z wewnątrz danej organizacji nigdy by nie odkrył. Zaangażowanie zewnętrznej firmy audytowej daje pewność, że uzyskamy obiektywne i pozbawione pewnych uprzedzeń spojrzenie na funkcjonowanie naszej organizacji. Wyniki, które da audyt, będą pozbawione przekłamań i rzetelnie oddadzą rzeczywisty stan rzeczy oraz prawdziwe problemy i zagrożenia – a znając je, łatwiej nam będzie je usunąć.

Audyt zewnętrzny może być też początkiem wdrażania własnych mechanizmów doskonalenia w organizacji, która ów audyt zleciła – bazując na już zdobytych doświadczeniach i obserwacji działań zawodowych audytorów, firma może opracować i stosować podobne, w mniejszym zakresie lub mniej sformalizowane, działania celem oceny innych niż poddane audytowi procesy czy produkty. I stopniowo udoskonalać całość organizacji.

Audyt
Audyt – ocena danej osoby, organizacji, systemu, procesu, projektu lub produktu. Audyt jest przeprowadzany w celu upewnienia się co do prawdziwości i rzetelności informacji, a także oceny systemu kontroli wewnętrznej. Celem audytu jest wyrażenie opinii na temat osoby/organizacji/systemu itd. w ramach oceny w oparciu o przeprowadzone testy. Audyt polega na ocenie przez kompetentny i niezależny zespół audytujący, czy dany przedmiot audytu spełnia wymagania. Zespół audytujący składa się z jednego lub więcej audytorów. Celem audytu może być weryfikacja, czy cel wyznaczony przez organizację audytowaną został osiągnięty lub czy jej działania są zgodne z zaakceptowanymi standardami, statusem czy praktykami. Audyt ocenia także procedury kontrolne celem stwierdzenia, czy przedmiot audytu także w przyszłości będzie odpowiadał uzgodnionym do stosowania wymaganiom. Oprócz oceny wskazuje także zalecenia zmian w procedurach, w tym sprawdzających oraz w politykach.

Audytów jest wiele…
Oto wybrane rodzaje audytów związane z branżą IT.

• Audyt bezpieczeństwa danych (Technicznej infrastruktury) – ma za zadanie zdefiniowanie istniejących zagrożeń i słabych punktów systemu zarządzania bezpieczeństwem informacji firmy oraz oszacowanie ryzyka operacyjnego, na jakie narażona jest organizacja klienta. W wyniku audytu powinny zostać też przedstawione rekomendacje w zakresie bezpieczeństwa informacji oraz propozycje możliwych rozwiązań, które mogą się przyczynić do podniesienia bezpieczeństwa informacji firmy oraz do zagwarantowania płynności procesów biznesowych. Podstawą audytu jest zwykle norma PN-I-07799-2:2004.

• Audyt informatyczny – proces zbierania i oceniania dowodów w celu określenia, czy system informatyczny i związane z nim zasoby właściwie chronią majątek, utrzymują integralność danych i dostarczają odpowiednich i rzetelnych informacji, osiągają efektywnie cele organizacji, oszczędnie wykorzystują zasoby i stosują mechanizmy kontroli wewnętrznej, tak aby dostarczyć rozsądnego zapewnienia, że osiągane są cele operacyjne i kontrolne, oraz że chroni się przed niepożądanymi zdarzeniami lub są one na czas wykrywane, a ich skutki na czas korygowane. Normami często stosowanymi w audytach informatycznych są:

  • ISO 9001;
  • ITIL;
  • COBIT.

Normą wyspecjalizowaną w zakresie bezpieczeństwa informatycznego, według której często prowadzi się audyty, jest ISO/IEC 27001. Towarzyszącą normą służącą do budowania systemów zarządzania bezpieczeństwem informacji jest ISO/IEC 27002.

• Audyt techniczny – weryfikacja realizacji projektu zgodnie z umową (warunkami wskazanymi przez zlecających projekt lub innych udziałowców); może być wykonywany w każdym czasie podczas trwania projektu.

• Audyt technologiczny – ocena rzeczywistych możliwości wykorzystania technologii w firmie. Audyt technologiczny to rodzaj kontroli planów wdrożeniowych, kontroli niezależnej, udokumentowanej, opartej o określone kryteria. Audyt ten wiąże się z pytaniami:

  • jakie są inne technologie w danej dziedzinie?;
  • jaki jest poziom rozwoju ocenianych technologii?;
  • jaki stopień innowacyjności posiada technologia?.

Audyt technologiczny może być: opiniujący, oceniający lub kontrolny.

• Audyt oprogramowania – polega na analizie stanu oprogramowania zainstalowanego w firmie, uporządkowaniu i uzupełnieniu brakujących licencji oraz wdrożeniu procedur usprawniających zarządzanie oprogramowaniem.

Na czym się opierać…

• COBIT (Control Objectives for Information and related Technology) – standard opracowany przez ISACA oraz IT Governance Institute, zbiór dobrych praktyk z zakresu IT Governance, które mogą być wykorzystywane w szczególności przez audytorów systemów informatycznych. COBIT 4.1 opisuje 34 wysokopoziomowe procesy, które obejmują 210 celów kontrolnych pogrupowanych w czterech domenach:

  • planowanie i organizacja (Planning and Organization);
  • nabywanie i wdrażanie (Acquisition and Implementation);
  • dostarczanie i wsparcie (Delivery and Support);
  • monitorowanie i ocena (Monitoring and Evaluation).

• ITIL (Information Technology Infrastructure Library) –- kodeks postępowania dla działów informatyki. Zbiór zaleceń, jak efektywnie i skutecznie oferować usługi informatyczne. Podstawą koncepcji ITIL jest zdefiniowanie procesów, które powinny funkcjonować w ramach organizacji świadczącej usługi IT. ITIL pozwala na modelowanie procesów zarówno w organizacjach komercyjnych (np. firmy komputerowe, programistyczne), jak i niekomercyjnych (agencje rządowe itp.), niezależnie od wielkości firmy, typu organizacji czy też posiadanych narzędzi. Każdy proces powinien posiadać zdefiniowane role i odpowiedzialności.

Standardy audytu systemów informatycznych (IS Auditing Standards)

• 010 Prawa i powinności audytu
Obowiązki, uprawnienia i odpowiedzialność obszaru działania realizującego funkcję audytu systemów informatycznych mają być odpowiednio udokumentowane w dokumencie regulującym prawa i powinności audytu lub w umowie na jego przeprowadzenie.

• 020 Niezależność
We wszystkich sprawach związanych z audytowaniem audytor systemów informatycznych musi być niezależny od poddawanych audytowi, zarówno co do stanowiska, jak i postępowania.

• 020.020 Powiązania organizacyjne
Funkcja audytu systemów informatycznych musi być wystarczająco niezależna od audytowanego obszaru, aby umożliwić obiektywne prowadzenie audytu.

• 030 Standardy i etyka zawodowa
Audytor systemów informatycznych jest zobowiązany do stosowania się do Kodeksu Etyki Zawodowej Stowarzyszenia do spraw audytu i kontroli systemów informatycznych (ISACA – Information Systems Audit and Control Association).

• 030.020 Należyta staranność zawodowa
Wobec wszelkich aspektów pracy Audytora Systemów Informatycznych obowiązuje należyta zawodowa staranność i przestrzeganie odpowiednich standardów audytu.

• 040 Kompetencje
Audytor systemów informatycznych ma być kompetentny w zagadnieniach technicznych, posiadając umiejętności i wiedzę niezbędną do wykonywania pracy audytorskiej.

• 040.020 Ustawiczne szkolenie zawodowe
Audytor systemów informatycznych ma utrzymywać kompetencje dotyczące zagadnień technicznych poprzez właściwe i ustawiczne szkolenie zawodowe.

• 050 Planowanie
Audytor Systemów Informatycznych powinien planować prace związane z audytem systemów informatycznych pod kątem realizacji celów audytu oraz zgodnie z odpowiednimi standardami przeprowadzania audytów.

• 060 Wykonywanie prac audytowych
Personel zajmujący się audytem systemów informatycznych ma być odpowiednio nadzorowany, aby zapewnić, że cele audytu są spełnione oraz że są spełnione stosowne, zawodowe standardy audytu.

• 060.020 Dowody
Zadaniem Audytora Systemów Informatycznych podczas przeprowadzania audytu jest zgromadzenie wystarczających, wiarygodnych, odpowiednich (relewantnych) i użytecznych dowodów, tak by efektywnie zrealizować zadania audytu. Wyniki audytu oraz wnioski powinny być poparte odpowiednią analizą i interpretacją tychże dowodów.

• 070 Raportowanie
Zadaniem Audytora Systemów Informatycznych jest dostarczenie określonym odbiorcom odpowiednio sformowanego raportu dotyczącego wykonanych prac audytowych. Raport z audytu ma przedstawiać obszar, cele, okres oraz rodzaj i zakres wykonanych prac audytowych. Raport ma wskazywać organizację, planowanych odbiorców raportu oraz wszelkie zastrzeżenia co do jego obiegu. Raport ma przedstawiać wyniki, wnioski i rekomendacje oraz wszelkie zastrzeżenia lub uwarunkowania audytora wobec audytu.

• 080 Dalszy tok działań
Audytor systemów informatycznych ma domagać się i oceniać stosowne informacje o wcześniejszych wynikach, wnioskach i rekomendacjach, aby określić, czy zostały podjęte na czas właściwe działania.

Przykład – określenie celu i zakresu audytu dotyczącego procesu wytwórczego dostawcy
Cel:
Ocena zgodności procesu wytwórczego z ustaleniami umowy i deklarowanym w DIP podejściem do zarządzania projektem.

Zakres prac:
• identyfikacja etapów procesu wytwórczego;
• identyfikacja mechanizmów kontroli jakości w poszczególnych etapach procesu wytwórczego;
• weryfikacja kompetencji osób realizujących prace rozwojowe;
• weryfikacja podejścia do planowania prac przez dostawcę;
• analiza procesu dokumentacji realizacji prac przez dostawcę. Sposób dokumentowania prac i zarządzanie dokumentacją;
• określenie wymagań jakościowych i sposoby weryfikowania ich realizacji;
• analiza zagrożeń i potencjalnych ataków oraz uwzgl dnienie funkcjonalności zapewniających ochronę przed zidentyFIkowanymi zagrożeniami. Zapewnienie bezpieczeństwa w ramach implementacji funkcjonalności;
• analiza procesu testowania aplikacji;
• identyfikacja zabezpieczenia kodu przed utratą jego poufności;
• identyfikacja wymagań związanych z dostarczeniem produktu odbiorcy i utrzymaniem produktu;
• weryfikacja planu reagowania na zgłoszone problemy z funkcjonowaniem oprogramowania.

Oczekiwane wyniki prac:
• stwierdzone nieprawidłowości wraz ze wskazaniem ich potencjalnego wpływu na jakość i bezpieczeństwo oprogramowania;
• rekomendowane działania korekcyjne wraz z uzasadnieniem i wskazaniem priorytetu.

Rola audytora wiodącego
Zadaniem audytora wiodącego jest opracowanie planu audytu. Plan ten powinien uwzględniać informacje dotyczące celu audytu, dokumentów odniesienia, zakresu audytu, ram czasowych (przy czym audyt nie powinien wybiegać poza godziny pracy audytowanych).

Audytor wiodący dokonuje podziału pracy pomiędzy członków zespołu. Wszyscy audytorzy przed przystąpieniem do audytu są zobowiązani zapoznać się z dokumentacją dotyczącą obszarów poddawanych ocenie oraz opracować niezbędne formularze i listy kontrolne.

Trochę psychologii…
Perspektywa audytu może budzić w pracownikach dostawcy obawy i poczucie zagrożenia. Audyt nie jest kontrolą, nie polega na doszukiwaniu się błędów i niedociągnięć ze strony audytowanego – jednak uczestnicy audytu mogą odczuwać presję i stres, wynikające z poczucia, iż są oceniani. Często audyt odbierany jest jako próba podważenia kompetencji osób audytowanych lub brak zaufania do rzetelności audytowanego.

To, czy ten problem zostanie rozwiązany, a audytowany nabierze zaufania do oceniających i poczuje się w miarę komfortowo, w dużej mierze zależy od samego zespołu audytorów. Od ich umiejętności i doświadczenia będzie zależało, czy uda im się nawiązać odpowiednie relacje i zbudować dobry model współpracy z audytowanymi. Profesjonalny audytor nie stosuje technik, które polegają na przysłowiowym zapędzaniu przesłuchiwanego w kozi róg i łapaniu za słówka. Zadaniem audytora jest ocena stanu rzeczywistego, nie udowadnianie audytowanemu, że się myli. Wytyczne odnoszące się do kompetencji personelu przeprowadzającego audyt są przedmiotem punktu 7 normy ISO/DIS 19011 – Kompetencje audytorów.

Punkt ów mówi, że do prowadzenia audytów jakości należy zatrudniać personel umiejący je realizować nie tylko z merytorycznego punktu widzenia – tzn. posiadający odpowiednie kompetencje, znajomość branży, technik oceny dotyczących badania, sporządzania raportów, kierowania, planowania i organizowania. Równie istotne są cechy osobiste charakteryzujące audytora – umiejętność skutecznej komunikacji interpersonalnej, dyplomacji, pracy w zespole, asertywność i przede wszystkim etyczne postępowanie. Od predyspozycji i umiejętności interpersonalnych audytorów w znaczącym stopniu zależy, czy proces audytu będzie procesem interaktywnym i umożliwi osiągnięcie postawionych przed nim celów. Dlaczego? Ponieważ wystraszony i zestresowany audytowany nie jest skory do współpracy. Aby porozumiewać się skutecznie, należy używać jasnych sformułowań, aktywnie i uważnie słuchać, przejąć odpowiedzialność za prowadzenie rozmowy, jeśli jest taka potrzeba, porządkować wypowiedzi chaotyczne, podtrzymywać sprzyjający klimat komunikacji.

Bardzo ważną kwestią jest komunikacja – jasne poinformowanie audytowanych o celach i zakresie audytu może skutecznie wyeliminować negatywne reakcje – opór, kwestionowanie audytu, złośliwość i agresja.

W Sieci
www.audyty.pl – strona na temat audytów. Opisuje m.in. audyty informatyczne;
www.audyt.net – strona zawiera praktyczne informacje dla audytorów wewnętrznych, a także narzędzia i wzorce dokumentów audytowych;
www.isaca.org/cobit – oficjalna strona ISACA, informacje na temat COBIT;
www.itil-officialsite.com – oficjalna strona ITIL;
• http://www.ffiec.gov/ffiecinfobase/booklets/audit/audit_00a_roles_rRespons.html – role i odpowiedzialności w audycie IT.

KAROLINA ZMITROWICZ
Pracuje na stanowisku Analityka biznesowego w firmie Profi-Data. Karolina specjalizuje się obecnie w modelowaniu wymagań biznesowych dla ubezpieczeń. Wcześniej pracowała jako Manager Quality Assurance w projektach informatycznych w sektorze finansowo – bankowym. Profi-Data to producent oprogramowania specjalizujący się w budowie dedykowanych rozwiązań informatycznych dla ubezpieczeń, bankowości i administracji publicznej. Firma posiada certyfikat jakości ISO 9001:2000 w zakresie produkcji oprogramowania.
Kontakt z autorem: karolina_zmitrowicz@wp.pl

Zostaw odpowiedź

Musisz być zalogowany aby publikować komentarz.



Software Press Sp. z o.o. Sp. Komandytowa 02-682 Warszawa, ul. Bokserska 1, NIP 9512279582, REGON 141804060, KRS: 0000327578