Weryfikacja i zatwierdzanie l Przedstawienie weryfikacji i zatwierdzania

Weryfikacja i zatwierdzanie l Przedstawienie weryfikacji i zatwierdzania oprogramowania ze szczególnym uwzględnieniem metod weryfikacji statycznej. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 1

Cele l l l Znać różnice między weryfikacją a zatwierdzaniem oprogramowania; znać kontrolę programu jako metodę wykrywania defektów w programach. Wiedzieć, dlaczego analiza statyczna programów jest ważną metodą weryfikacji. Znać Cleanroom - metodę tworzenia programów i wiedzieć, dlaczego może być skuteczna. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 2

Zawartość l l Planowanie weryfikacji i zatwierdzania Kontrole oprogramowania Automatyczna analiza statyczna Metoda Cleanroom tworzenia oprogramowania ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 3

Weryfikacja i zatwierdzanie l l To nazwy nadane procesom sprawdzania i analizy, których celem jest upewnienie się, że oprogramowanie odpowiada swojej specyfikacji i spełnia oczekiwania klientów płacących za to oprogramowanie. Weryfikacja i zatwierdzanie to proces trwający w trakcie całego cyklu życia. Zaczyna się od przeglądów wymagań, trwa w czasie przeglądów projektów i kontroli kodu, a kończy się testowaniem produktu. Czynności W i Z powinny występować w każdym kroku procesu tworzenia oprogramowania. Czynności te mają na celu sprawdzenie, czy rezultaty czynności procesu są zgodne ze specyfikacją. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 4

Różnice l l l Weryfikacja i zatwierdzanie są tym samym. Są jednak często mylone. Boehm (1979) zwięźle przedstawił różnicę między nimi: „Zatwierdzanie: Czy budujemy odpowiedni produkt? ” „Weryfikacja: Czy budujemy produkt odpowiednio? ” Z tych definicji wynika, ze rolą weryfikacji jest sprawdzenie, czy oprogramowanie jest zgodne ze swoją specyfikacją. Trzeba sprawdzić, czy system spełnia określone dla niego wymagania funkcjonalne i niefunkcjonalne. Zatwierdzanie jest bardziej ogólnym procesem. Trzeba upewnić się, że oprogramowanie odpowiada oczekiwaniom klienta. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 5

Metody sprawdzania i analizy systemu l l Kontrole (inspekcje) oprogramowania polegają na analizie i sprawdzeniu przedstawień systemu, takich jak dokumentacja wymagań, diagramy projektowe i kod źródłowy programów. Można je wykonywać w każdym kroku procesu. Kontrole można uzupełnić automatyczną analizą kodu źródłowego systemu i innych dokumentów. Kontrole oprogramowania i automatyczne analizy to metody statyczne W i Z, ponieważ do ich wykonania nie trzeba działającego systemu. Testowanie oprogramowania polega na uruchamianiu implementacji oprogramowania. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 6

Weryfikacja i zatwierdzanie dynamiczne i statyczne Kontrole oprogramowania Specyfikacja wymagań Projekt wysokiego poziomu Specyfikacja formalna Projekt szczegółowy Testowanie programów Prototyp ©Ian Sommerville 2000 Program Inżynieria oprogramowania, Rozdział 19 Slide 7

Rodzaje testów, które można wykonać w różnych fazach procesu tworzenia oprogramowania l l Testowanie defektów. Jego celem jest znalezienie niezgodności między programem i jego specyfikacją. Te niezgodności są zwykle wynikiem defektów i usterek programu. Testy przygotowuje się w celu wykrycia obecności usterek systemu, a nie symulowania jego działania. Testowanie statyczne. Służy do zbadania efektywności i niezawodności programu oraz sprawdzenia, jak działa w warunkach normalnego użytkowania. Testy przygotowuje się tak, aby odzwierciedlały prawdziwe dane wejściowe użytkowników i ich częstotliwość. Po wykonaniu testów można oszacować niezawodność działania przez zliczenie zaobserwowanych awarii systemu. Efektywność programu można ocenić na podstawie pomiarów czasu działania i czasu reakcji systemu w czasie przetwarzania danych statystycznych. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 8

Czynniki poziomu zaufania l l l Funkcja oprogramowania. Poziom wymaganego zaufania zależy od tego, jak bardzo krytyczny dla firmy jest ten system. Poziom wymaganego zaufania wobec oprogramowania sterującego systemem krytycznym dla bezpieczeństwa jest znacznie wyższy niż wobec prototypowego systemu oprogramowanego, który opracowano w celu prezentacji nowych pomysłów. Oczekiwania użytkowników. To smutna obserwacja na temat przemysłu informatycznego- wielu użytkowników ma niewielkie oczekiwania wobec oprogramowania i nie jest zaskoczonych jego awariami w czasie użytkowania. Są w stanie zaakceptować te awarie systemu pod warunkiem, że korzyści są większe niż wady. Tolerancja użytkowników wobec awarii systemu ustawicznie maleje od lat dziewięćdziesiątych XX wieku. Obecnie dostarczenie zawodnego systemu spotyka się z mniejszą aprobatą, a zatem firmy budujące oprogramowanie muszą poświęcić więcej wysiłku na weryfikację i zatwierdzanie. Środowisko rynkowe. Gdy system jest sprzedawany na rynku, sprzedawcy muszą wziąć pod uwagę konkurencyjne programy, cenę, którą klienci są gotowi zapłacić, i wymagany harmonogram dostarczenia systemu. Jeśli firma ma kilku konkurentów, to może udostępnić program, zanim będzie dokładnie przetestowany i oczyszczony z błędów, ponieważ chce być pierwszą na rynku. Gdy klienci nie są gotowi do zaakceptowania wysokiej ceny oprogramowania, muszą zaaprobować tolerowanie większej liczby usterek. Wszystkie te czynniki należy rozważyć przy decydowaniu o ilości wysiłku w procesie W i Z. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 9

Testowanie i usuwanie błędów l l Testowanie lub ogólniej weryfikacja i zatwierdzanie to proces ustalania obecności defektów w systemie oprogramowania. Usuwanie błędów to proces lokalizacji i usuwania błędów. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 10

Proces usuwania błędów Wyniki testów Specyfikacja Zlokalizuj błąd Zaprojektuj sposób naprawy ©Ian Sommerville 2000 Przypadki testowe Napraw błąd Inżynieria oprogramowania, Rozdział 19 Ponownie przetestuj program Slide 11

Planowanie weryfikacji i zatwierdzania l l l Weryfikacja i zatwierdzanie to kosztowne procesy. W wypadku niektórych wielkich systemów, takich jak systemy czasu rzeczywistego ze złożonymi ograniczeniami niefunkcjonalnymi, pół budżetu na produkcję przeznacza się na W i Z. Staranne planowanie jest niezbędne do panowania nad kosztami procesu weryfikacji i zatwierdzania. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 12

Plany testowania jako pomost między tworzeniem a testowaniem Specyfikacja wymagań Specyfikacja systemu Plany testów akceptacyjnych Działanie ©Ian Sommerville 2000 Projekt systemu Plany testów integracji systemu Test akceptacyjny Projekt szczegółowy Kod i testy modułów i jednostek Plany testów integracji podsystemów Test integracji systemu Test integracji podsystemu Inżynieria oprogramowania, Rozdział 19 Slide 13

Struktura planu testów oprogramowania Proces testowania Opis zasadniczych faz procesu testowania. Może być taki, jak opisany wcześniej. Ślad wymagań Użytkownicy są najbardziej zainteresowanymi tym, aby system spełniał wymagania. Testowanie należy zaplanować tak, aby wszystkie wymagania sprawdzać oddzielnie. Testowane byty Należy wskazać produkty procesu tworzenia oprogramowania, które podlegają testowaniu. Harmonogram testów Ogólny harmonogram testowania i przydział zasobów do jego realizacji. Należy go odnieść do bardziej ogólnego harmonogramu przedsięwzięcia. Procedury zapisywania wyników testów Nie wystarczy po prostu przeprowadzić testy. Wyniki poszczególnych testów muszą być systematycznie zapisywane. Musi być też możliwość kontroli procesu tworzenia w celu sprawdzenia, czy jest odpowiednio prowadzony Wymagany sprzęt i oprogramowanie W tym punkcie należy wskazać niezbędne narzędzia programowe i oszacowanie użycia sprzętu Ograniczenia W tym punkcie należy określić przewidywane ograniczenia testowania, np. brak personelu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 14

Kontrole oprogramowania l l l Wykonanie kontroli oprogramowania nie wymaga uruchamiania programów, a zatem tę metodę weryfikacji można stosować, zanim powstanie implementacja programów. W trakcie implementacji bada się reprezentację źródłową systemu. Może to być model systemu, specyfikacja lub kod w języku wysokiego poziomu. Przy wykrywaniu błędów korzysta się z wiedzy o budowanym systemie i znaczeniu reprezentacji źródłowej. Każdy błąd można rozważyć oddzielenie bez brania pod uwagę jego wpływu na zachowanie systemu. Zależności między błędami nie są istotne. Cały komponent można zweryfikować w trakcie trwania jednej sesji. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 15

Skuteczność l l l Kontrole okazały się skuteczną metodą wykrywania błędów. Wykrywanie błędów za pomocą kontroli jest tańsze niż za pomocą intensywnych testów. Ponad 60% błędów w programach można wykryć za pomocą nieformalnych kontroli programów. Formalne podejście z uwzględnieniem matematycznej weryfikacji może doprowadzić do wykrycia ponad 90% błędów w programie. Tę metodę stosuje się w procesie Cleanroom. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 16

Przyczyny skuteczności kontroli oprogramowania l l Wiele rożnych defektów można wykryć w trakcie jednej sesji kontroli. Kłopot z testowaniem polega na tym, że często umożliwia wykrycie tylko jednego błędu w jednym teście, ponieważ defekty powodują katastrofę programu lub mieszają się z symptomami innych defektów programu. Kontrole uwzględniają użycie wielokrotne wiedzy dziedzinowej i dotyczącej języka programowania. W istocie, recenzenci prawdopodobnie znają już rodzaje błędów często występujących przy stosowaniu konkretnego języka programowania lub konkretnych rodzajach zastosowań. W trakcie analizy mogą się więc skoncentrować na takich rodzajach błędów. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 17

Kontrole programów l l l Kontrole programów to przeglądy, których celem jest wykrycie defektów. Zespół składający się z osób o różnej wiedzy powinien przeprowadzić staranny przegląd kodu źródłowego programu wiersz po wierszu. Zasadnicza różnica między kontrolami programów i innymi rodzajami przeglądów jakościowych polega na tym, że celem kontroli jest wykrycie defektów, a nie rozważanie szerszych zagadnień projektowych. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 18

Role w procesie kontroli Rola Autor lub właściciel Kontroler Czytelnik Pisarz Przewodniczący lub moderator Naczelny moderator Opis Programista lub projektant odpowiedzialny za opracowanie programu lub dokumentu odpowiada za usunięcie defektów wykrytych w trakcie procesu kontroli. Znajduje w programach i dokumentach błędy, pominięcia oraz niespójności. Może również rozpoznawać szersze zagadnienia spoza zakresu prac zespołu kontrolującego. Interpretuje kod lub dokument w trakcie spotkania kontrolnego. Odnotowuje rezultaty spotkania kontrolnego. Zarządza procesem i ułatwia kontrolę. Odpowiada z ulepszenie procesu kontroli, aktualizację list kontrolnych, opracowywanie standardów itd. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 19

Zanim rozpocznie się kontrola progarmów, należy upewnić się, że: l l l Istnieje precyzyjna specyfikacja kodu podlegającego kontroli. Bez pełnej specyfikacji nie uda się wykonać kontroli komponentu na poziomie szczegółowości wystarczającym do wykrywania defektów. Członkowie zespołu kontrolującego znają standardy firmowe. Jest dostępna aktualna, poprawna składniowo wersja kodu. Kontrola kodu “niemal ukończonego” nie ma sensu, nawet jeśli opóźnienie spowoduje niedotrzymanie harmonogramu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 20

Proces kontroli Planowanie Uzupełnienia Przegląd Indywidualne przygotowania ©Ian Sommerville 2000 Powtórne prace Spotkanie kontrolne Inżynieria oprogramowania, Rozdział 19 Slide 21

Sprawdzenie kontrolne Klasa usterek Sprawdzenie kontrolne Usterki danych Czy wszystkie zmienne programu zainicjowano przed użyciem ich wartości? Czy wszystkie stałe mają nazwy? Czy górna granica zakresu tablicy jest równa rozmiarowi tablicy, czy rozmiarowi minus jeden? Czy tam, gdzie użyto stałych napisowych, jawnie przypisano ogranicznik? Czy istnieje jakakolwiek możliwość przepełnienia buforów? Czy warunek każdej instrukcji warunkowej jest poprawny? Czy każda pętla na pewno się zakończy? Czy instrukcje złożone są poprawnie ujęte w nawiasy? Czy w instrukcjach wyboru uwzględniono wszystkie możliwości? Czy tam, gdzie jest konieczna instrukcja break w instrukcji wyboru, uwzględniono ją? Czy wszystkie zmienne wejściowe są używane? Czy wszystkie zmienne wyjściowe mają przypisywaną wartość, zanim staną się daną wyjściową? Czy nieoczekiwane dane wejściowe mogą spowodować uszkodzenia? Usterki sterowania Usterki wejścia-wyjścia ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 22

Sprawdzenia kontrolne - c. d. Klasa usterek Sprawdzenie kontrolne Usterki interfejsu Czy wszystkie wywołania funkcji i metod mają odpowiednią liczbę parametrów? Czy pasują do siebie typy parametrów formalnych i aktualnych? Czy parametry są podane w odpowiednim porządku? Czy komponenty korzystające z pamięci dzielonej zakładają ten sam model struktury pamięci dzielonej? Czy po modyfikacji wskaźnikowej struktury danych wszystkie wiązania są właściwie przełączane? Czy tam, gdzie korzysta się z dynamicznego przydziału pamięci, jest ona przydzielana poprawnie? Czy pamięć jest jawnie zwalniana, gdy już nie jest potrzebna? Czy wzięto pod uwagę wszystkie możliwe sytuacje błędne? Usterki zarządzania pamięcią Usterki obsługi ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 23

Przykładowy proces kontroli l l l W trakcie fazy przeglądu można rozważyć około 500 wierszy kodu źródłowego na godzinę. W trakcie indywidualnych przygotowań można zbadać 125 wierszy kodu źródłowego na godzinę. W trakcie spotkania można poddać kontroli od 90 do 125 wierszy kodu źródłowego na godzinę. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 24

Automatyczna analiza statyczna l l Analizatory statyczne programów to narzędzia programowe, które przeglądają kod źródłowy programu i wykrywają potencjalne usterki i anomalie. Nie wymagają uruchomienia programu, ale analizują składniowo tekst programu i rozpoznają różne rodzaje instrukcji. Mogą sprawdzić, czy instrukcje są poprawnie zbudowane, wnioskować o przepływie sterowania w programie i w wielu wypadkach wyznaczyć zbiór możliwych wartości danych programu. Stanowią uzupełnienie udogodnień do wykrywania błędów oferowanych przez kompilator języka. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 25

Klasa usterek Sprawdzanie analizy statycznej Usterki danych Zmienne używane przed inicjacją Zmienne zadeklarowane, ale nigdy nie użyte Zmienne, którym wartość przypisano dwukrotnie bez jej odczytu między przypisaniami Potencjalne przekroczenia zakresów tablic Nie zadeklarowane zmienne Usterki sterowania Kod nieosiągalny Bezwarunkowe odgałęzienia w pętlach Usterki Zmienne wypisywane dwukrotnie bez przypisania im wartości między wejścia-wyjścia wypisywaniem Usterki interfejsu Niezgodność typów parametrów Niezgodność liczby parametrów Niewykorzystane wyników funkcji Nie wywołane funkcje i procedury Usterki zarządzania. Wskaźniki, którym nie przypisano wartości pamięcią Arytmetyka wskaźników Sprawdzania automatycznej analizy statycznej

Kroki analizy statycznej l l l Analiza przepływu sterowania Analiza użycia danych Analiza interfejsu Analiza przepływu informacji Analiza ścieżek ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 27

Język C l Analizatory statyczne są szczególnie przydane, gdy korzysta się z języka programowania takiego jak C. Język C nie ma ścisłych reguł dotyczących typów, a zatem sprawdzenia, które może wykonać kompilator C, są bardzo ograniczone. Istnieje więc wiele możliwości błędów programistów, które można wykryć za pomocą automatycznego narzędzia analitycznego. Jest to szczególnie ważne, gdy język C (w mniejszym stopniu C++) jest używany do tworzenia systemów krytycznych. W takich wypadkach analiza statyczna może znacznie zmniejszyć koszty testowania. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 28

Metoda Cleanroom tworzenia oprogramowania l l l Tworzenie oprogramowania Cleanroom (Mills i inni, 1987; Cobb i Mills, 1990; Linger, 1994; Prowell i inni, 1999) to filozofia tworzenia oprogramowania, której podstawą jest unikanie defektów oprogramowania dzięki rygorystycznemu procesowi kontroli. Celem tego podejścia do tworzenia oprogramowania jest oprogramowanie bez żadnych defektów. Nazwa Cleanroom pochodziło od nazwy pomieszczenia fabryki półfabrykatów. W pomieszczeniu czystym (cleanroom) unika się defektów przez tworzenie w sterylnej atmosferze. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 29

Model procesu Cleanroom Wyspecyfikuj system formalnie Zdefiniuj przyrosty oprogramowania Wyspecyfikuj system formalnie ©Ian Sommerville 2000 Poprawianie błędów Utwórz program strukturalny Zweryfikuj kod formalnie Wyspecyfikuj system formalnie Inżynieria oprogramowania, Rozdział 19 Zintegruj przyrost Wyspecyfikuj system formalnie Slide 30

Główne cechy podejścia Cleanroom l l l Specyfikacja formalna Tworzenie przyrostowe Programowanie strukturalne Weryfikacja statyczna Testowanie statyczne systemu ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 31

Tworzenie przyrostowe Zamrożona specyfikacja Ustal wymagania ©Ian Sommerville 2000 Formalne specyfikowanie Opracuj przyrost oprogramowania Inżynieria oprogramowania, Rozdział 19 Dostarcz oprogramowanie Slide 32

Zespoły biorące udział w procesie Cleanroom l l l Zespół specyfikujący. Ta grupa odpowiada za opracowanie i pielęgnację specyfikacji systemu. Zespół wytwarzający. Ten zespół odpowiada za utworzenie i zweryfikowanie oprogramowania. Zespół certyfikujący. Ten zespół jest odpowiedzialny za opracowanie zbioru testów statystycznych, za pomocą, których bada się oprogramowanie po jego stworzeniu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 33

Główne tezy l l Weryfikacja i zatwierdzanie to samo. Celem weryfikacji jest wykazanie, że program spełnia specyfikację. Celem zatwierdzania jest wykazanie, że program robi to, czego wymaga użytkownik. Plany testowania powinny zawierać opis testowanych bytów, harmonogram testowania, procedury zarządzania procesem testowania, listę wymaganego sprzętu i oprogramowania oraz problemów, które mogą się pojawić. Metody weryfikacji statycznej obejmują badanie i analizę kodu źródłowego programu w celu wykrycia błędów. Należy stosować je razem z testowaniem programów jako części procesu W i Z. Kontrole programów są skutecznym sposobem wyszukiwania błędów w programach. Celem kontroli jest lokalizacja defektów. Proces kontroli powinien odbywać się na podstawie listy kontrolnej usterek. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 34

Główne tezy l l l Kod programu jest systematycznie sprawdzany przez niewielki zespół. Jego członkami są szef lub moderator, autor kodu, czytelnik prezentujący kod w trakcie kontroli i tester badający kod z punktu widzenia testowania. Analizatory statyczne to narzędzia programowe, które przetwarzają kod źródłowy programu i przyciągają uwagę do anomalii, takich jak nieużywane sekcje kodu i niezainicjowane zmienne. Takie anomalie mogą być wynikiem usterek w kodzie. Tworzenie oprogramowania Cleanroom to podejście do tworzenia oprogramowania, którego podstawą są metody weryfikacji statycznej programów i testy statystyczne do certyfikowania niezawodności. To podejście było z powodzeniem stosowane przy budowaniu systemów o wysokim poziomie niezawodności. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 19 Slide 35