Jacek Rembikowski, E-QSM Informatyczne Systemy Zarządzania, Poznań 2014
Okazuje się, że niektóre tematy stanowią dość żywy organizm, który co jakiś czas przypomina o swoim istnieniu. Jednym z nich jest np. kwestia testowania oprogramowania, kto i dlaczego powinien się tym zajmować oraz w jakich warunkach powinno się testować oprogramowanie.
Generalnie problem z tym zagadnieniem ma swoje źródło w czymś, co można nazwać procesowym kołem zamachowym, które swój początek bierze w znajomości własnego środowiska (ocena kluczowości i krytyczności elementów składowych), a koniec w ocenie ryzyka. Po drodze nie bez znaczenia pojawia się trzeci składnik układanki, jakim jest proces zarządzania zmianami i/lub rozwój oprogramowania.
„Wprowadzenie nowego systemu informatycznego, jak również znacznej zmiany do już istniejącego systemu, powinno być poprzedzone przeprowadzeniem analizy ryzyka wynikającego z zastosowanych technologii informatycznych oraz dokonaniem oceny wpływu wprowadzanych zmian na środowisko teleinformatyczne i procesy biznesowe banku, ze szczególnym uwzględnieniem aspektów bezpieczeństwa. (…)
Zarówno nowe oprogramowanie, jak i zmiany wprowadzane do już funkcjonujących rozwiązań informatycznych, powinny być testowane adekwatnie do swojej złożoności oraz wpływu na pozostałe elementy środowiska teleinformatycznego banku. Bank powinien posiadać metodologię testowania oprogramowania (...)” tyle Rekomendacja D…
Przeprowadzenie analizy ryzyka z zastosowanych technologii, na pierwszy rzut oka wydaje się być dość proste. Jeżeli jednak rzucimy tym okiem dalej może okazać się, że niekoniecznie. Powodów jest kilka. Jednym z nich jest znajomość danej technologii, jej możliwości i ograniczeń. Drugim jest znajomość (dobra) własnej infrastruktury jej potrzeb i zagrożeń, przed którymi się bronimy.
Najbardziej obrazowym przykładem jest w tym miejscu np. dobór Smart Phone’ów – jeżeli nasza infrastruktura wymaga stosowania antywirusa, to nie możemy dobrać takich urządzeń, dla których systemów nikt nie napisał jeszcze stosownego oprogramowania, bo jest to sprzeczne z zasadami przyjętymi w organizacji PBI. Ale w zakresie sprzętu to w sumie nie jest trudne. Co natomiast z oprogramowaniem?
Tu w pierwszej kolejności pojawiają się na pozór banalne elementy, takie, jak wymagania stricte użytkowe z zakresu: „do czego będę tego używał”. Inne będą wymagania do przetwarzania danych osobowych, inne - do przetwarzania informacji poufnych. Czyli już na początku powinienem umieć określić czy dany element pozwala mi zachować ten zakres bezpieczeństwa, jaki nakłada na mnie prawo i zasady użytkowania.
Kolejna kwestia to technologia – są zwolennicy starych rozwiązań – bo pewne i przetestowane, są miłośnicy nowinek. Są też tacy, co lubią środek. Każdy z nich w określonych warunkach będzie miał rację, ale…
Znam firmę, która nagle postanowiła oszczędzić na drodze obrażenia się na Microsoft i przeszła na Linuksy, także dla użytkowników. Gdyby dokonali analizy ryzyka, to stwierdziliby co następuje:
Z wnioskiem na końcu – czy to nie będzie, że zamienił Stryjek siekierkę na kijek i czy nie wygeneruje to dodatkowego kosztu?
Inny przykład – firmie zaproponowano przejście z oprogramowania instalowanego na dzierżawione. W wyniku oceny działania (stabilności) łącza władze doszły do wniosku, że ryzyko braku dostępu do systemu jest zdecydowanie większe i groźniejsze niż w razie awarii czekanie na serwis.
Każdy z tych elementów pokazuje inny zakres ryzyk i inne spojrzenie wynikające wprost z potrzeb i środowiska, w jakim funkcjonują. Bez tej wiedzy naprawdę trudno o jednoznaczną odpowiedź. Dlatego też należałoby zacząć od rzetelnego opisania zbioru ryzyk i sposobu szacowania (oceniania) nowych lub rozwijanych elementów IT.
Ale co z testowaniem?... Pełna treść artykułu dostępna jest pod adresem: http://demo.eqsm.com.pl
