Weryfikacja i walidacja (oprogramowanie)

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacja, szukaj
Ujednoznacznienie Ten artykuł dotyczy inżynierii oprogramowania. Zobacz też: inne znaczenia hasła weryfikacja.

Weryfikacja i walidacja oprogramowania również kontrola jakości oprogramowania lub testy oprogramowania.. Do kryterium weryfikacji należy zakwalifikowanie produktu oraz określenie, czy spełnia on lub pasuje do właściwego jego wykorzystania (wysoki poziom kontroli) – czy jest on wbudowany w odpowiedni produkt.

Analiza programu pod kątem jego formalnej poprawności pozwala znaleźć błędy zarówno na poziomie koncepcji, jak i detali implementacyjnych. Jednak proces dowodzenia zgodności programu z wymaganiami nie sprowadza się wyłącznie do stwierdzenia, że system jest bądź nie jest poprawny.

Walidacja jest to proces wyznaczania stopnia, w jakim model jest wiernym odzwierciedleniem rzeczywistego systemu z przyjętego punktu widzenia[1]. Ma na celu określenie, czy symulacja daje wiarygodne wyniki, w założonym stopniu zgodne z odpowiedziami rzeczywistego systemu na takie same dane wejściowe. O ile dzięki weryfikacji projektant uzyskuje informacje o zgodności systemu symulacyjnego z jego założeniami, o tyle walidacja weryfikuje zgodność jego wizji z realnym światem. Obie te fazy wzajemnie się uzupełniają i jako takie czasami przedstawiane są wspólnie jako faza oceny adekwatności modelu[2].

Błędy walidacji i weryfikacji oprogramowania[edytuj | edytuj kod]

Każdy model jest tylko reprezentacją systemu rzeczywistego i jego zachowania są w najlepszym wypadku aproksymacją rzeczywistego działania. Posługując się przykładem, nie można powiedzieć, że model domu wykonany w pewnej skali, nawet 1:1, posiada wszelkie cechy budynku rzeczywistego. Przeciwnie, prezentuje on jedynie pewne aspekty budynku w przybliżeniu, na jakie godzi się projektant modelu i jego użytkownik. Jak powiedział znany statystyk George Box: „Wszystkie modele są błędne. Niektóre są użyteczne”[3]. Pamiętając o pierwszym, należy starać się spełnić warunek drugi. Nie jest to zadanie łatwe. Nie można bowiem ostatecznie stwierdzić, kiedy model osiągnął odpowiedni stopień adekwatności, jest stabilny i pozbawiony błędów logicznych, kiedy można zakończyć pracę. Przez model, który przeszedł weryfikację i walidację rozumieć należy model poddany serii operacji mających na celu uszczegółowienie go do poziomu, na jaki będzie mógł sprostać postawionym przed nim zadaniom. Wiarygodność modelu zależy od zaufania, jakie ma do niego użytkownik. Proces weryfikacji i walidacji ma na celu doprowadzić do tego poziomu wiarygodności. Błędy popełniane w czasie prac nad systemem symulacyjnym można podzielić na kilka grup. Wiedząc, gdzie zazwyczaj zdarzają się usterki, łatwiej można je znaleźć i poprawić[4].

Do najczęściej popełnianych należą następujące błędy:

  • funkcjonalny – zła lub brakująca funkcja;
  • systemowy – pomylone interfejsy, nieprawidłowe zarządzanie zasobami;
  • przetwarzania – niewłaściwe przetwarzanie danych;
  • danych – błędna specyfikacja, projekt, rozmieszczenie;
  • kodowania – niewłaściwe użycie języka oprogramowania;
  • dokumentacyjny – niepełna lub błędna treść dokumentu.

Niezależna weryfikacja i walidacja[edytuj | edytuj kod]

Inną metodą kontroli jakości jest tzw. niezależna weryfikacja i walidacja (ang. Independent Verification And Validation IV&V)[5]. Zgodnie z nią wykorzystuje się trzecią niezależną grupę ludzi, niezwiązaną ani z projektantami, ani z użytkownikami systemu. To ta grupa ma za zadanie zdecydować, czy model jest adekwatny do systemu rzeczywistego. Podejście to często stosuje się w przypadku systemów bardzo obszernych, nad których stworzeniem pracowała duża grupa ludzi, lub gdy poniesiono znaczne nakłady na ich opracowanie. Sposób ten podnosi wiarygodność modelu. Niezbędne jest jednak, aby zespół walidacyjny posiadał zarówno wiedzę o systemie, jak i o celach którym ma służyć symulacja. To od jego oceny będzie zależało, czy system zostanie uznany za narzędzie odpowiednie do rozwiązania problemu.

Istnieją dwa podejścia do procesu walidacji. Pierwsze opiera się na równoległej pracy zespołu walidacyjnego z projektantami systemu i bieżącej ocenie adekwatności modelu. Drugie zakłada walidację i weryfikację systemu symulacyjnego po zakończeniu nad nim prac. To podejście jest jednak droższe i bardziej czasochłonne od pierwszego[5]. Dlatego zalecane jest podejście równoległej walidacji podczas całego procesu powstawania modelu symulacyjnego.

Jeżeli istnieje możliwość, walidacja systemu powinna być wsparta przez rozmowy z użytkownikiem systemu. Mając przez długi czas styczność z systemem rzeczywistym, ekspert często potrafi odpowiedzieć na pytania dotyczące całości systemu lub wskazać rażące błędy, których podstawą jest niezrozumienie rzeczywistego systemu, które są przyczyną generowania przez symulację złych wyników. Nie należy traktować tego jako błędu, lecz jako często pracy nad modelem[5]. Poza tym bardzo istotną kwestią jest osobiste zaangażowanie użytkownika w proces tworzenia systemu[5]. Jeżeli będzie miał on wrażenie współtworzenia modelu, będzie chętniej współpracował z projektantem, co na pewno korzystnie wpłynie na jakość i wiarygodność symulacji.

Poszczególne etapy testowania powinny być podzielone na następujące osoby:

  • programista – testy jednostkowe (ma naturalną tendencję „chronienia” swojego wytworu);
  • specjalista tester – testy systemowe, integracyjne, alfa testy;
  • użytkownik systemu – beta testy, testy akceptacyjne systemu (osobiście lub nadzorując je).

Weryfikacja i walidacja produktu[edytuj | edytuj kod]

W testowaniu oprogramowania ważne są pojęcia – weryfikacja i walidacja. Weryfikacja, czyli postrzeganie, czyli odpowiedź na pytanie: „Czy produkt tworzony jest prawidłowo?”, a z kolei walidacja to pytanie: „Czy tworzony produkt jest prawidłowy?”. Prawidłowo – to znaczy zgodnie z wytycznymi programowania, z zastosowaniem odpowiednich metod, języka programowania i algorytmów. Weryfikacja dokonywana jest podczas testów systemowych pojedynczego produktu, oraz testów integracyjnych, po wprowadzeniu produktu do istniejącego już i działającego środowiska informatycznego[6]. Weryfikację można wykonywać na dwa sposoby – statyczny i dynamiczny. Weryfikacja dynamiczna przeprowadzana jest już po uruchomieniu programu, z użyciem danych testowych, i kontroluje zachowanie systemu widoczne dla użytkownika.

Testowanie i walidacja oprogramowania[edytuj | edytuj kod]

Aplikacje software'owe są specyficznym produktem, a ich sprawdzenie dotyczy oceny następujących cech:

  • czy produkt wytwarzany jest prawidłowo (zgodnie ze sztuką tworzenia oprogramowania – tak zwana weryfikacja);
  • czy spełnia wymagania postawione przez klienta (walidacja);
  • czy produkt działa poprawne i niezawodnie.

Efektywny proces sprawdzania produktów umożliwiający wykrywanie błędów na najwcześniejszym etapie wytwarzania produktów wymaga zaprojektowania właściwych metod przeprowadzania testów oraz zastosowania do tego odpowiednich narzędzi. Walidacja środowiska testowego oraz przyjętych metod testowania to procedura oceny, czy przyjęty sposób kontroli produktów (przeprowadzania testów), jest skuteczny i umożliwia wykrywanie błędów.

Podsumowanie[edytuj | edytuj kod]

Weryfikacja i walidacja – to wada czy zaleta w inżynierii oprogramowania. Podsumowując warto zwrócić uwagę na to, jakim celom mogą one służyć. Nie da się za jej pomocą rozwiązać wszystkich problemów. Uwagę należy zwrócić na potencjalne koszty tworzenia modelu symulacyjnego. Ale czy metoda weryfikacji i walidacji będzie skuteczna w całości? Należy to rozważać w oparciu o indywidualne potrzeby użytkownika.

Przypisy

  1. Dean S. Hartley III: „Verification & Validation In Military Simulations” Proceedings of the 1997 Winter Simulation Conference (WSC).
  2. Jerzy Tyszer: Symulacja cyfrowa. WNT, 1990.
  3. John S. Carson II: „Model Verification And Validation” Proceedings of the 2002 Winter Simulation Conference (WSC).
  4. Ian Sommerville: Inżynieria oprogramowania. Warszawa: WNT, 2003.
  5. 5,0 5,1 5,2 5,3 Robert G. Sargent: „Some Approaches And Paradigms For Verifying And Validating Simulation Models” Proceedings of the 2001 Winter Simulation Conference (WSC).
  6. Janusz Górski: Inżynieria oprogramowania w projekcie informatycznym. Warszawa: Mikom, 1999.