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

Weryfikacja i zatwierdzanie

Przedstawienie weryfikacji i
zatwierdzania oprogramowania
ze szczególnym
uwzględnieniem metod
weryfikacji statycznej.
©Ian Sommerville 2000
Inżynieria oprogramowania, Rozdział 19
Slide 1
Cele



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ść




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




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





Weryfikacja i zatwierdzanie nie 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


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


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



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


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



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
Plany testów
integracji
podsystemów
Test integracji
systemu
Kod i testy
modułów
i jednostek
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





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ść



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


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



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:



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
Uzupełnienia
Planowanie
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



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




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
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ądzaniaWskaźniki, którym nie przypisano wartości
pamięcią
Arytmetyka wskaźników
Usterki danych
Sprawdzania
automatycznej analizy
statycznej
Kroki analizy statycznej





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

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



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
Poprawianie błędów
Zdefiniuj
przyrosty
oprogramowania
Wyspecyfikuj
system
formalnie
©Ian Sommerville 2000
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





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



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




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.
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



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