©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 1 Weryfikacja i zatwierdzanie l Przedstawienie weryfikacji i zatwierdzania oprogramowania.

Prezentacja na temat: "©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 1 Weryfikacja i zatwierdzanie l Przedstawienie weryfikacji i zatwierdzania oprogramowania."— Zapis prezentacji:

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

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

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

4 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 4 Weryfikacja i zatwierdzanie 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. l 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. l Czynności W i Z powinny występować w każdym kroku procesu tworzenia oprogramowania. l Czynności te mają na celu sprawdzenie, czy rezultaty czynności procesu są zgodne ze specyfikacją.

5 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 5 l Weryfikacja i zatwierdzanie nie są tym samym. Są jednak często mylone. Boehm (1979) zwięźle przedstawił różnicę między nimi: l „Zatwierdzanie: Czy budujemy odpowiedni produkt?” l „Weryfikacja: Czy budujemy produkt odpowiednio?” l 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. l Zatwierdzanie jest bardziej ogólnym procesem. Trzeba upewnić się, że oprogramowanie odpowiada oczekiwaniom klienta. Różnice

6 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 6 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. l Testowanie oprogramowania polega na uruchamianiu implementacji oprogramowania. Metody sprawdzania i analizy systemu

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

8 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 8 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. l 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. Rodzaje testów, które można wykonać w różnych fazach procesu tworzenia oprogramowania

9 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 9 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. l 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. l Ś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. Czynniki poziomu zaufania

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

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

12 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 12 l Weryfikacja i zatwierdzanie to kosztowne procesy. l 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. l Staranne planowanie jest niezbędne do panowania nad kosztami procesu weryfikacji i zatwierdzania. Planowanie weryfikacji i zatwierdzania

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

14 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 14 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. Struktura planu testów oprogramowania

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

16 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 16 Skuteczność 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. l Ponad 60% błędów w programach można wykryć za pomocą nieformalnych kontroli programów. l 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.

17 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 17 Przyczyny skuteczności kontroli oprogramowania 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. l 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.

18 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 18 Kontrole programów l Kontrole programów to przeglądy, których celem jest wykrycie defektów. l 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. l 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.

19 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 19 Role w procesie kontroli RolaOpis Autor lub Programista lub projektant odpowiedzialny za opracowanie programu właściciellub dokumentu odpowiada za usunięcie defektów wykrytych w trakcie procesu kontroli. KontrolerZnajduje 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. CzytelnikInterpretuje kod lub dokument w trakcie spotkania kontrolnego. PisarzOdnotowuje rezultaty spotkania kontrolnego. PrzewodniczącyZarządza procesem i ułatwia kontrolę. lub moderator NaczelnyOdpowiada z ulepszenie procesu kontroli, aktualizację list kontrolnych, moderatoropracowywanie standardów itd.

20 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 20 Zanim rozpocznie się kontrola progarmów, należy upewnić się, że: 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. l Członkowie zespołu kontrolującego znają standardy firmowe. l 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.

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

22 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 22 Sprawdzenie kontrolne Klasa usterekSprawdzenie kontrolne Usterki danychCzy 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? Usterki sterowaniaCzy 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ą? Usterki Czy wszystkie zmienne wejściowe są używane? wejścia-wyjściaCzy wszystkie zmienne wyjściowe mają przypisywaną wartość, zanim staną się daną wyjściową? Czy nieoczekiwane dane wejściowe mogą spowodować uszkodzenia?

23 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 23 Sprawdzenia kontrolne - c.d. Klasa usterekSprawdzenie kontrolne Usterki interfejsuCzy 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? Usterki zarządzaniaCzy po modyfikacji wskaźnikowej struktury danych wszystkie wiązania są pamięcią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? Usterki obsługiCzy wzięto pod uwagę wszystkie możliwe sytuacje błędne?

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

25 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 25 Automatyczna analiza statyczna l Analizatory statyczne programów to narzędzia programowe, które przeglądają kod źródłowy programu i wykrywają potencjalne usterki i anomalie. l Nie wymagają uruchomienia programu, ale analizują składniowo tekst programu i rozpoznają różne rodzaje instrukcji. l 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. l Stanowią uzupełnienie udogodnień do wykrywania błędów oferowanych przez kompilator języka.

26 Sprawdzania automatycznej analizy statycznej Klasa usterekSprawdzanie analizy statycznej Usterki danychZmienne 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 sterowaniaKod nieosiągalny Bezwarunkowe odgałęzienia w pętlach UsterkiZmienne wypisywane dwukrotnie bez przypisania im wartości między wejścia-wyjściawypisywaniem Usterki interfejsuNiezgodność typów parametrów Niezgodność liczby parametrów Niewykorzystane wyników funkcji Nie wywołane funkcje i procedury Usterki zarządzaniaWskaźniki, którym nie przypisano wartości pamięciąArytmetyka wskaźników

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

28 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 28 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.

29 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 29 Metoda Cleanroom tworzenia oprogramowania 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. l Celem tego podejścia do tworzenia oprogramowania jest oprogramowanie bez żadnych defektów. l Nazwa Cleanroom pochodziło od nazwy pomieszczenia fabryki półfabrykatów. W pomieszczeniu czystym (cleanroom) unika się defektów przez tworzenie w sterylnej atmosferze.

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

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

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

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

34 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 34 Główne tezy l Weryfikacja i zatwierdzanie to nie to samo. Celem weryfikacji jest wykazanie, że program spełnia specyfikację. Celem zatwierdzania jest wykazanie, że program robi to, czego wymaga użytkownik. l 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ć. l 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. l 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.

35 ©Ian Sommerville 2000Inżynieria oprogramowania, Rozdział 19Slide 35 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. l 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. l 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. Główne tezy