Wdrożenie a ryzyko awarii

Przeczytaj także: Niepowodzenie wdrożenia a wydajność aplikacji

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. Badaniem objęto 358 dyrektorów ds. informatycznych dużych firm w regionie Europy, Bliskiego Wschodu i Afryki.

"Wyniki tych badań są niepokojące" - powiedział Marek Dróżdż z polskiego oddziału Compuware. "Ryzyko powinno być mierzone i monitorowane w trakcie opracowywania aplikacji, tak aby przedsiębiorstwo mogło podjąć decyzję o wdrożeniu na podstawie ryzyka, jakie jest gotowe zaakceptować. Firmy powinny mieć gwarancję, że elementy aplikacji o najbardziej krytycznym znaczeniu zostały rygorystycznie przetestowane w celu zminimalizowania ryzyka awarii. Dla przykładu, w aplikacji handlu elektronicznego jest oczywiste, że nie można podjąć rozsądnej decyzji o jej wdrożeniu bez znajomości ryzyka awarii funkcji odpowiedzialnych za obsługę płatności. 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".

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. Potwierdzeniem tych wyników jest fakt, że 45% respondentów określiło zastosowane u siebie podejście do testowania nowych aplikacji jako usiłowanie przetestowania jak największej części danej aplikacji z zamiarem osiągnięcia stuprocentowej niezawodności.

"Mniemanie, że można przetestować całą aplikację i wyeliminować wszystkie czynniki ryzyka, jest nierealne" - mówi Dróżdż. "Ograniczenia czasowe oraz budżetowe powodują, że przetestowanie całej aplikacji jest niepraktyczne i w związku z tym przedsiębiorstwo powinno się skupić na obniżeniu ryzyka do akceptowalnego poziomu, a nie na usiłowaniu osiągnięcia czegoś niemożliwego. Przedsiębiorstwa muszą wyznaczyć priorytety zadań testowych, tak aby najstaranniej były testowane te części aplikacji, które wiążą się z największym ryzykiem. Przyjęcie podejścia opartego na ocenie ryzyka umożliwia zespołom testującym wskazanie części aplikacji mających mniejsze znaczenie, których usterka może być łatwiej zaakceptowana. Taka strategia jest korzystniejsza niż podejście nieukierunkowane, polegające na stwierdzeniu, iż pewna liczba usterek musi być tolerowana, mimo że nie wiadomo, które części aplikacji, a co ważniejsze, które procesy biznesowe, mogą zostać wskutek tego zakłócone".

Testy oparte na ocenie ryzyka umożliwiają 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.

"Dział informatyczny jest często obwiniany za złą jakość oprogramowania. Jednak zła jakość w wielu przypadkach jest spowodowana presją ze strony pionu biznesowego na oddanie aplikacji do eksploatacji. Główną zaletą podejścia do testowania opartego na ocenie ryzyka jest wyeliminowanie takiego jednostronnego obwiniania, gdyż kierownictwo ponosi część odpowiedzialności za sukces lub niepowodzenie nowej aplikacji. Jest to sytuacja całkiem inna niż wówczas, gdy kierownictwo przypisuje sobie wszystkie zasługi, a dział informatyczny jest obciążany całą winą" - zakończył Marek Dróżdż.