Lepiej zapobiegać niż leczyć

Kierownictwa banków zdają sobie sprawę z tego, jakie koszty powodują nawet bardzo krótkie awarie wykorzystywanego oprogramowania. Zwykle są one tak duże, że pieniądze wydane na zapobieżenie takiej sytuacji są przysłowiowymi "groszowymi sprawami". Dodatkowo w wyniku takiej awarii pojawiają się trudne do wyliczenia straty wizerunkowe - tym większe, im większe zaufanie klientów, którzy powierzyli bankowi swoje oszczędności.

Obecne regulacje prawne sprawiły, że instytucje finansowe stały się coraz bardziej świadome potrzeby włączenia problemu zarządzania ryzykiem w swoich projektach informatycznych. Wraz z nadejściem regulacji bazylejskich (Basel II) oraz inicjatyw corporate governance, zarządzanie ryzykiem stało się standardem w procesie rozwoju aplikacji. Pytanie tylko, jak to wygląda w rzeczywistości?

Podejście firm do wdrażania nowych aplikacji nie wygląda najlepiej. Jak wynika z badań przeprowadzonych przez firmę Compuware, 64% przedsiębiorstw podczas wdrażania nowej aplikacji nie przeprowadza ilościowej oceny ryzyka jej awarii. Blisko 74% respondentów podaje, iż straty ich przedsiębiorstwa spowodowane złą jakością oprogramowania sięgają 500 tys. euro rocznie. Skutki te są jeszcze bardziej dotkliwe w przedsiębiorstwach zatrudniających ponad 5 tys. pracowników - w tej kategorii 15% respondentów ocenia straty na ponad 1 mln euro rocznie.

- Ryzyko powinno być mierzone i monitorowane w trakcie opracowywania aplikacji, tak aby przedsiębiorstwo mogło podjąć decyzję o wdrożeniu na podstawie analizy ryzyka, jakie jest gotowe zaakceptować. Instytucje finansowe powinny mieć gwarancję, że elementy aplikacji o najbardziej krytycznym znaczeniu zostały rygorystycznie przetestowane w celu zminimalizowania możliwości wystąpienia awarii. Dla przykładu, w aplikacjach transakcyjnych elektronicznych systemów bankowych jest oczywiste, że nie można podjąć rozsądnej decyzji o ich wdrożeniu bez znajomości ryzyka awarii jej poszczególnych funkcji. Jeśli przedsiębiorstwa nie podejmą działań na rzecz oceny ryzyka i ukierunkowania testów na taką ocenę, straty spowodowane złą jakością aplikacji będą stale rosły - mówi Marek Dróżdż z polskiego oddziału Compuware.

Zbyt często jednak zarządzanie ryzykiem ogranicza się jedynie do jego oceny w początkowej fazie rozwoju oprogramowania, kiedy zespoły projektowe identyfikują możliwe problemy i zastanawiają się nad drogami ich wyeliminowania. W późniejszych fazach projektowania oprogramowania problem zarządzania ryzykiem schodzi na dalszy plan, a w samym momencie rozpoczęcia testów oprogramowania o zarządzaniu ryzykiem już nikt nie pamięta. Zespoły testowe najczęściej koncentrują się na samym procesie testowania, przez co znika im z oczu szerszy aspekt przygotowania nowego oprogramowania do użytku. Uniknięcie tego problemu jest możliwe dzięki prowadzeniu testowania opartego na analizie ryzyka (risk based testing).

Najprościej rzecz ujmując, pomysł testowania opartego na analizie ryzyka polega na tym, że ryzyko ocenione na początku projektowania oprogramowania pozwala na ustawienie priorytetów w późniejszej fazie testów. Innymi słowy, sam proces testowania przebiega zgodnie z ustalonymi priorytetami biznesowymi- elementy krytyczne dla działania całego systemu są testowane na początku oraz bardziej szczegółowo.

Według Teresy Lanowitz z firmy analitycznej Gartner, jakość aplikacji jest przedmiotem powszechnego zainteresowania i kierownictwo firm zaczyna rozumieć, że efektywne zapewnienie jakości jest kluczem do zmniejszenia ryzyka, zapewnienia korzyści i podwyższenia poziomu obsługi informatycznej. Nowe metody mierzenia skuteczności testowania i zarządzanie nimi na podstawie analizy ryzyka biznesowego, rozumianego jako prawdopodobieństwo spełnienia lub niespełnienia przez aplikację jej celu biznesowego, będą najchętniej wybieranymi przez zespoły rozumiejące i doceniające znaczenie jakości w procesie tworzenia oprogramowania.

Przeprowadzenie testów opartych o ocenę ryzyka umożliwia działowi informatycznemu dokładną ocenę ryzyka awarii aplikacji oraz skutków takiej awarii dla działalności przedsiębiorstwa. Ocena taka może być następnie przedstawiona kierownictwu, które na jej podstawie może podjąć uzasadnioną decyzję, czy aplikacja powinna zostać oddana do eksploatacji w określonym czasie. Obecnie, jak wynika z przywoływanych już badań Compuware, ponad 55% ankietowanych dyrektorów ds. informatycznych podało, że przy testowaniu aplikacji kierownictwo biznesowe nie jest w stanie zaznaczyć, które części aplikacji mają znaczenie krytyczne dla działalności ich firmy.

- Mniemanie, że można przetestować całą aplikację i wyeliminować wszystkie czynniki ryzyka, jest nierealne - podkreśla Dróżdż. - Ograniczenia czasowe oraz budżetowe powodują, że przetestowanie całej aplikacji jest niepraktyczne i w związku z tym przedsiębiorstwo takie jak bank powinno skupić się na obniżeniu ryzyka do akceptowalnego poziomu - dodaje. Osiągnięcie tego akceptowalnego poziomu ryzyka jest możliwe, co oznacza, że wcale nie jest tak trudno zapobiec ponoszeniu dodatkowych kosztów, które z pewnością wystąpią w wypadku awarii systemu.