Redakcja
Rekomendacja D dotyczy zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach. Banki mają obowiązek wprowadzić ją do końca 2014 roku.
"Aktualizacji Rekomendacji wynika ze znacznego rozwoju technologicznego oraz systematycznego wzrostu znaczenia obszaru technologii informacyjnej dla działalności banków, jak również z pojawienia się nowych zagrożeń w tym zakresie."
http://www.knf.gov.pl/Images/Rekomendacja_D_8_01_13_uchwala_7_tcm75-33016.pdf
Dokument zawiera 22 rekomendacje, które podzielone zostały na następujące obszary:
- strategia i organizacja obszarów technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego,
- rozwój środowiska teleinformatycznego,
- utrzymanie i eksploatacja środowiska teleinformatycznego,
- zarządzanie bezpieczeństwem środowiska teleinformatycznego.
Cykl życia oprogramowania
Ważnym elementem Rekomendacji jest również opis cyklu życia oprogramowania. Składa się on z następujących elementów:
1. Strategia banku (7.1) - Zakłada się rozwój systemu zgodny ze strategią banku w zakresie obszarów technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego.
2. Szczegółowe wymagania (7.2) - Dokument wskazuje na ważny element zapewnienia jakości oprogramowania, zaczynający się od zapewnienia jakości wymagań. Szczególnie dla projektów wytwarzanych zewnętrznie, wykrywanie problemów wymagań (np. niejasności) na etapie (dopiero) testowania może być kosztowne dla całej organizacji. Rekomendacja nakazuje uwzględnić w wymaganiach:
- funkcjonalność
- pojemność
- połączenia z innymi systemami
- wydajność i dostępność
- środowisko działania
- bezpieczeństwo
- zgodność z przepisami i standardami
3. Projektowanie systemu (7.3) z uwzględnieniem modyfikacji w przyszłości (elastyczność), wynikających ze:
- Zmiany prawa,
- Strategii banku,
- Standardów w banku,
- Zmiany w otoczeniu i działania konkurencji banku.
4. Analiza ryzyk (7.4) - przeprowadzenie analizy ryzyka przed wdrożeniem nowego systemu jak i przy każdej znaczącej zmianie określa ocenę wpływu zmiany na:
- Środowisko teleinformatyczne
- Procesy biznesowe
- „… ze szczególnym uwzględnieniem aspektów bezpieczeństwa”
5. Rozwój oprogramowania - wewnętrzny (7.5). Rekomendowane jest posiadanie, jako dobra praktyka, metodyki rozwoju oprogramowania opisującej procesy:
- Zarządzanie zmianą w systemie informatycznym z uwzględnieniem wielkości danej zmiany (zmiana jako: cały projekt, zmiana w produkcie, poprawka)
- Zarządzanie incydentami (pochodzącymi z produkcji, pochodzącymi ze środowisk testowych)
- Zarządzanie środowiskami testowymi
- Zarządzanie dokumentacją testową
- Miary
- Standardy w rozwoju oprogramowania
- Architektura
- Narzędzia programistyczne
- Repozytoria
- Standardy kodowania (preferowane języki) w tym zapewnienie jakości poprzez dbałość o notację i komentowanie kodu
- Zasady wykonywania testów i przeglądów kodu
- Kryteria jakości kodu
- Standard tworzenia dokumentacji
- Zasady wersjonowania oprogramowania
Rekomendacja wskazuje na konieczność wykonywania bieżących testów i przeglądów kodu, zapewniających odpowiedni stopień niezależności w przypadku rozwoju oprogramowania realizowanego siłami własnymi.
6. Rozwój oprogramowania - zewnętrzny (7.6) - czyli korzystanie z usług wiarygodnych partnerów. Uwzględnienie w umowie stosowania przez dostawcę standardów i metodyk rozwoju oprogramowania przyjętych w banku. Wykonywanie testów przed wdrożeniem:
- Przez dostawcę
- Przeprowadzenie testów w banku (bez względu na testy dostawcy)
7. Testowanie (7.7) - gdzie rekomendacja D zakłada zdefiniowanie przez organizację metodologii testowania.
8. Wdrożenie (7.8) - zgodnie z rekomendacją D bank powinien zapewnić, aby procedury przenoszenia nowego systemu informatycznego lub zmiany już funkcjonującego systemu na środowisko produkcyjne minimalizowały ryzyko wystąpienia przestojów w działalności banku. Wskazana jest konieczność:
- zweryfikowania poprawności działania systemu i zgodności z wymaganiami,
- monitorowania systemu (przez odpowiedni czas ) w celu identyfikacji ewentualnych problemów.
Bank powinien podjąć decyzję dotyczącą zapewnienia mechanizmów umożliwiających powrót do stanu sprzed wdrożenia w przypadku wystąpienia sytuacji krytycznej. Np. tworzenie kopii awaryjnych odpowiedniego obszaru środowiska teleinformatycznego
9. Wycofanie (7.15). Rekomenduje się posiadanie sformalizowanych regulacji w zakresie wycofywania z eksploatacji rozwiązań informatycznych uwzględniających:
- podejmowanie decyzji,
- informowanie zainteresowanych stron,
- przeprowadzanie migracji danych,
- dokonywanie archiwizacji rozwiązań,
- aktualizację konfiguracji infrastruktury,
- bezpieczną eliminację wycofywanych z użytku komponentów
-
aktualizację dokumentacji środowiska teleinformatycznego banku.
Metodologia testowania oprogramowania zgodna z Rekomendacją D
Poprzez „metodologię testowania” rozumie się „metodologię testowania środowiska teleinformatycznego” czyli testowania systemu i infrastruktury. Metodologia uwzględnia wspomniane w rekomendacji „dobre praktyki” testowania, takie jak planowanie i testowanie atrybutów jakościowych oprogramowania. Rekomendacja D w punkcie 5.2 zwraca uwagę na odpowiednią separację obowiązków, w szczególności oddzielenie funkcji tworzenia lub modyfikowania systemów informatycznych od ich testowania (poza testami realizowanymi przez programistów w ramach wytwarzania oprogramowania), administracji i użytkowania. Sposób organizacji testów powinien zapewniać możliwie wysoki stopień niezależności weryfikacji spełnienia przyjętych założeń
Na metodologia testowania składają się nastęujące etapy [opcja - jest działaniem, które wynika z dobrych praktyk, ale nie jest pisane w Rekomendacji]
- [opcja] Planowanie
- Strategia testowania (dobór lub definicja)
- Zdefiniowanie miar jakości oprogramowania
- Kryterium odbioru oprogramowania
- Wytworzenie scenariuszy i danych w oparciu o wymagania. Wymagania dostępne – tworzenie scenariuszy z uwzględnieniem:
- Uruchomienie testów
- Raportowanie
Analizują rekomendacje możemy wyróżnić następujące poziomy testów
- [opcja] Testowanie jednostkowe
- [opcja] Testowanie integracji modułów
- Testowanie systemu
- Testowanie integracyjne z innymi systemami
- Rodzaje testów
- Testowanie regresywne
- [opcja] Testowanie potwierdzające
Całe opracowanie można znaleźć na profilu SlideShare
Opracowanie zostało przygotowane przez autorów związanych z Qualityin.IT
Radosław Smilgin, 21CN (testerzy.pl) - definiowanie metodologii (procesów) testowania
Radoslaw [dot] Smilgin [at] testerzy.pl
Wojciech Dworakowski, SecuRing - audyt i testowanie bezpieczeństwa systemów teleinformatycznych
Wojciech.Dworakowski@securing.pl
Tomasz Watras, PGS Software S.A., - outsourcing wytwarzania i testowania
TWatras@pgs-soft.com
