Jakość osiągana przez stosowanie: technik i metod: właściwego

Transkrypt

INŻYNIERIA OPROGRAMOWANIA
Jakość w projekcie informatycznym - wstęp
Wykład 4 (1)
Jakość osiągana przez stosowanie:
technik i metod:
właściwego zarządzania
• weryfikacji,
• walidacji,
Weryfikacja – proces oceny produktu (lub jego składników)
w celu stwierdzenia czy spełnia on na zakończeniu fazy
rozwojowej założenia stawiane na jej początku
•
przeglądów,
•
inspekcji,
•
audytów,
•
testowania,
•
dowodzenia poprawności
Wykład 4 (3)
Walidacja – proces oceny stopnia spełnienia przez produkt
wymagań stawianych mu w specyfikacji
Jakość w projekcie informatycznym - weryfikacja
Faza cyklu
Podstawowy cel weryfikacji
Zalecane techniki
Analiza wymagań
Sensowność, niesprzeczność, realizowalność wymagań
Inspekcje, przeglądy
Specyfikacja zewnętrzna
Zgodność z wymaganiami, kompletność, spójność,
realizowalność techniczna, adekwatność kryteriów akceptacji
Projekt architektury
Zgodność z wymaganiami i specyfikacją zewnętrzną,
realizowalność techniczna,
Projekt szczegółowy
Poprawność techniczna, zgodność z PA,
Inspekcje, przeglądy,
dowody formalne
Kodowanie
Spełnienie atrybutów formalnej poprawności kodu,
poprawność pragmatyczna, zgodność z PS
Inspekcje, przeglądy,
dowody formalne,
analiza dynamiczna
Testowanie
Kompletność i adekwatność projektu testów, rzetelność
wykonania testów, udowodnienie wyeliminowania
znalezionych błędów, wykazanie spełnienia wymagań dla
ustalonych danych
Eksperymenty z
programem,
Dokumentowanie
Czytelność i użyteczność dokumentacji, zgodność ze stanem
faktycznym
Przeglądy,
eksperymenty z
programem
1
Wykład 4 (4)
Współczynniki eliminacji defektów w różnych technikach
Removal Step
Lowest Rate
Modal Rate
Highest Rate
------------------------------------------------------------------------------------------------------------Personal checking of
15%
35%
70%
design documents
Informal group design reviews
30%
40%
60%
Formal design inspections
35%
55%
75%
Formal code inspections
30%
60%
70%
Personal desk-checking of
code
20%
40%
60%
Unit testing (single routine)
10%
25%
50%
Integration testing (related routines)
20%
35%
55%
System testing
25%
45%
60%
(complete system)
Field testing (live data)
35%
50%
65%
------------------------------------------------------------------------------------------------------------Cumulative effect of
complete series
93%
99%
99%
Jakość w projekcie informatycznym - testowanie
Wykład 4 (2)
Błąd:
• Nieudokumentowana cecha systemu,
• Działanie niezgodne ze specyfikacją,
• Niespełnienie wymagań określonych w specyfikacji systemu
Klasyfikacja błędów w/g źródeł pochodzenia
Klasa błędu
Źródło pochodzenia
Funkcjonalny
Zła lub brakująca funkcja
Systemowy
Błąd w interfejsach, błędne sterowanie
Przetwarzania
Niewłaściwe przetwarzanie danych w modułach
Danych
Błędna specyfikacja, projekt, rozmieszczenie lub
inicjacja struktur danych
Kodowania
Niewłaściwe użycie języka programowania
Dokumentacyjny
Niepełna lub błędna treść dokumentu
Inny
2
Wykład 4 (5)
Znaczenie testowania jako:
•
Metody zwiększania zaufania do produktu,
•
Stymulatora analizy i weryfikacji projektu i kodu
•
Metody potwierdzania stabilności produktu
Rodzaje testów:
•
Jednostkowe – sprawdzenie poprawności działania wydzielonej jednostki
modularyzacji (funkcji, procedury, klasy, biblioteki) względem jej specyfikacji,
•
Integracyjne – sprawdzenie poprawności współpracy jednostek pod względem
współdziałania na poziomie interfejsu i poprawności realizacji funkcji złożonych
•
Systemowe – sprawdzenie poprawności realizacji funkcji całego systemu (wsparcie
walidacji)
•
Akceptacyjne – dowiedzenie poprawności realizacji funkcji dla danych określonych w
kryteriach akceptacji
•
Regresywne – wykazanie zachowania poprawności realizacji funkcji systemu w
kolejnych jego wersjach
Wykład 4 (6)
Kategorie testowania systemowego
Test
Czynność
użyteczności
Sprawdzenie wymagań funkcjonalnych
objętości
Sprawdzenie działania dla danych wejściowych dużych rozmiarów
zmęczeniowe
Sprawdzenie zachowania przy dużej intensywnosci strumienia danych
wejściowych
obsługi
Sprawdzenie zgodności ze specyfikacją w zakresie interfejsu i ergonomii
poufności
Sprawdzenie odporności na próby nieuprawnionego dostępu do danych
pamięci
Sprawdzenie zapotrzebowania na pamięć
konfiguracji
Próba pracy w różnych konfiguracjach (np. z różnymi wersjami SO)
kompatybilnosci
Sprawdzenie poprawności pracy po rozbudowie (np. współdziałanie z danymi o
poprzednim formacie, sprawdzenie skuteczności rekonstrukcji danych itp)
instalacji
Sprawdzenie poprawności przebiegu instalacji
niezawodności
Zebranie statystyk charakteryzujących niezawodność w określonym środowisku
podnoszenia z
upadku
Sprawdzenie skuteczności odtwarzania po wymuszonym upadku (np. po awarii
zasilania, zamknięciu przez SO itp.)
obsługi
Obserwacja sposobu eksploatacji przez przeszkolony personel
dokumentacji
Sprawdzenie przydatności dokumentcji
3
Wykład 4 (7)
Strategie testów:
•
Funkcjonalne (black box) – testowanie poprawności realizacji funkcji systemu bez
analizy sposobu ich wykonania,
•
Strukturalne (glass box) – testowanie działania konstrukcji składających się na system
Metody doboru danych testowych (projektowania testów):
a) Dla strategii funkcjonalnych:
• Metoda sprawdzenia wszystkich wymagań funkcjonalnych – wykonanie testów dla
wszystkich wyróżnionych w specyfikacji wymagań funkcjonalnych i przypadków użycia
• Metoda pokrycia punktów funkcyjnych – taki dobór danych/interakcji aby każdy
punkt funkcyjny (dana wejściowa, dana wyjściowa, element interfejsu, wydruk) był
użyty co najmniej raz
• Metoda z podziałem na klasy równoważności – podział dziedziny danych wejściowych
na obszary, w których podejrzewa się podobne lub identyczne działanie programu
• Metoda specjalnych wartości – sprawdzenie działania programu dla granicznych lub
niepoprawnych wartości danych (dane na granicy lub spoza zakresu, duże dane (np.
bardzo duże rozmiary tabel, bardzo długie napisy, b. wielkie lub b. małe liczby, b. duże
lub b. małe rozdzielczości obrazów itp.)
Wykład 4 (8)
Metody doboru danych testowych (projektowania testów) - cd:
•
Metoda Monte-Carlo – sprawdzenie działania programu dla danych generowanych
losowo, automatycznie w/g rozkładu równomiernego w dziedzinie danych
wejściowych
a) Dla strategii strukturalnych:
•
Metoda pokrycia elementów niekompilowanych – dobór danych zapewniających
wykonanie każdego elementu niekompilowanego co najmniej raz (np. wywołania
programów zewnętrznych, zapytania SQL itp.)
•
Metoda pokrycia jednostek modularyzacji – każda jednostka użyta co najmniej raz
•
Metoda pokrycia rozgałęzień – taki dobór danych, aby każde rozgałęzienie było
wykonane co najmniej raz
•
Metody oparte o analizę przepływu danych:
•
A) dla każdej pary a -> b gdzie a – miejsce obliczenia danej w, b – miejsce użycia
danej w wygenerować dane wymuszające przejście od a do b,
•
B) niech w1, w2, wn – dane używane w wyrażeniu w miejscu b a zi – miejsca
obliczania danej wi; wygenerować dane wymuszające przejście do b przez wszystkie
miejsca możliwego powstawania wartości używanych w wyrażeniu w b,
4
Wykład 4 (9)
`
Dokumentacja testów:
Dokumentacja przeprowadzenia testów:
Projekt testów:
• Identyfikator przypadku testowego
• Wydzielenie obszarów testowania
• Specyfikacja przypadków testowych
• Data wykonania i dane testera,
• Wersja testowanego oprogramowania,
• Status zaliczenia,
• Zasady organizacji pracy przy
testowaniu
• Dane o środowisku wykonania,
• Harmonogram testów
• Zauważone nieprawidłowości,
Specyfikacja przypadku testowego:
• Identyfikacja zgłoszonych błędów
• Identyfikator testu i planu
• Cel testu ze wskazaniem wymagania lub przypadku użycia
• Opis lub wskazanie środowiska wykonania (np. baza dancyh,
rodzaj SO)
• Opis danych wejściowych i/lub interakcji
• Opis spodziewanego rezultatu
Wykład 4 (10)
Elementy procesu testowania systemowego:
przygotowanie planu testów
określenie ogólnego celu testowania
określenie szczegółowych obszarów podlegających testowaniu
zaprojektowanie zbioru przypadków testowych:
określenie ważności testów i kolejności ich przeprowadzania
określenie składu zespołu testującego
zamrożenie kodu
iteracje przeprowadzania testu
kompilacja modułów wykonywalnych
przeprowadzenie testów
ocena błędów
poprawa
5
Wykład 4 (11)
Elementy procesu testowania systemowego – cd:
sporządzenie raportu końcowego:
lista błędów wykrytych,
lista błędów pozostałych,
oszacowanie czasochłonności procesu testowania
archiwizacja danych i opisu testów dla celów testowania regresywnego
Inne techniki wykrywania błędów w kodzie:
• Analiza statyczna (czytanie i autoanaliza kodu),
• Stosowanie analizatorów kodu (co najmniej wysokich poziomów ostrzeżeń
kompilatora)
• Śledzenie wykonania programu,
• Dowodzenie poprawności programów
Wykład 4 (25)
Przeglądy
Przegląd (w/g IEEE - 1990 ) - proces lub spotkanie w czasie
którego produkt pracy lub zbiór produktów jest przedstawiony
personelowi, kierownikom, użytkownikom lub innym
zainteresowanym w celu skomentowania lub akceptacji
Podstawowe metodologie przeglądów:
• formalne przeglądy projektu,
• inspekcje i przejścia
• opinie ekspertów
6
Wykład 4 (13)
Przeglądy
Cele przeglądu:
• bezpośrednie - związane z projektem poddanym przeglądowi
• pośrednie - związane z doskonaleniem zespołu
Cele bezpośrednie:
• wykrycie błędów analizy i projektu oraz wymaganych poprawek,
zmian i uzupełnień w kontekscie specyfikacji i zatwierdzonych
zmian
• wykrycie źródeł ryzyka mogących wpłynąć n aprzebieg
rezlizacji projektu,
• wykrycie odchyleń od wzorców, stylów, procedur i konwencji
• zaakceptowanie produktów analizy lub projektu
Wykład 4 (14)
Przeglądy
Cele pośrednie:
• motywowanie zespołu do stosowania ustalonych
procedur,wzorców i zasad
• dostarczenie platformy wymiany wiedzy zawodowej dotyczącej
metod, narzędzi i technik,
• odnotowanie błędów analizy i projektu dla celów doskonalenia
metod prowadzenie projektów i organizacji pracy
7
Wykład 4 (15)
Przeglądy
Przeglądy formalne - prowadzone w celu akceptacji produktów
danej fazy.
Uczestnicy przeglądu
•
prowadzący przegląd,
•
zespół przeglądający,
•
zespół projektowy.
Cechy prowadzącego przegląd:
•
wiedza i doświadczenie merytoryczne w zakresie obszaru projektu,
•
Staż co najmniej taki jak kierownika zespołu,
•
Dobre stosunki z kierownikiem zespołu i jego członkami
•
Stanowisko pracy niezwiązane z zespołem.
Wykład 4 (16)
Przeglądy
Dobrzy kandydaci na kierowników przeglądów to:
•
kierownik działu R&D,
•
kierownik innego projektu,
•
kierownik działu QA,
•
kierownik działu IT klienta.
Członkowie zespołu przeglądającego:
•
liczność: 3-5 osób,
•
uczestnicy - starsi stażem członkowie zespołów projektowych z innych
projektów
8
Wykład 4 (17)
Przeglądy
Przygotowanie do przeglądu:
prowadzący:
•
wyznaczenie spotkań i umówienie wszystkich uczestniczących stron,
•
przygotowanie agendy spotkań,
•
przydzielenie członkom zespołu poszczególnych dokumentów
projektowych do przeglądu
•
dostarczenie dokumentów projektowych do uczestników przeglądu
•
przygotowanie list kontrolnych zawierających elementy podlegające
sprawdzeniu w trakcie przeglądu
członkowie zespołu przeglądowego:
•
analiza dostarczonych dokumentów,
•
przygotowanie uwag
Wykład 4 (18)
Przeglądy
członkowie zespołu projektowego
•
przygotowanie krótkich prezentacji dokumentów podlegających przeglądowi,
Przebieg sesji przeglądu:
Obowiązkiem prowadzącego jest:
•
nadzorowanie przebiegu dyskusji,
•
zapobieganie dygresjom,
•
dbanie o zgodność z agendą.
•
prezentacje powinny koncentrować się na aspektach projektu wymagających
akceptacji,
•
unikać długich prezentacji wyczerpujących członków zespołu.
9
Wykład 4 (19)
Przeglądy
Plan przebiegu sesji:
•
krótka prezentacji dokumentu podlegającego przeglądowi,
•
komentarze i uwagi członków zespołu przeglądającego,
•
weryfikacja wszystkich uwag i określenie dla każdej z nich wymaganych
działań (poprawki, zmiany, rozszerzenia),
•
dyskusja o dokumencie mająca na celu określenie postępów projektu;
pełna akceptacja - umożliwia przejście do następnej fazy projektu. Niekiedy mogą jej
towarzyszyć wymagania drobnych zmian lub poprawek,
częściowa akceptacja - dotyczy niektórych części projektu, dla których jest możliwe
przejście do następnej fazy; pozostałe części projektu wymagają znacznych korekt; ich
kontynuacja będzie możliwa po wykonaniu zaleconych akcji korekcyjnych i po
przeprowadzeniu kolejnej sesji przeglądu,
całkowite odrzucenie - występuje w sytuacji licznych usterek i niemożności wydzielenie
częsci projektu, które moga być kontunuowane.Cała sesja przeglądu musi być w tej sytuacji
powtórzona.
Wykład 4 (20)
Przeglądy
Raport z przebiegu sesji
musi być przygotowany i przesłany uczestnikom sesji bezpośrednio po jej zakończeniu
zawartość raportu:
•
podsumowanie dyskusji,
•
decyzja o kontynuacji projektu,
•
pełna lista zaakceptowanych zastrzeżeń i uzgodnionych akcji korekcyjnych, dla
każdej akcji powinna być podana przewidywana data zakończenia
•
przewidywana data sesji uzupełniającej,
•
lista osób przydzielonych do przeprowadzenia sesji uzupełniającej.
Typowe błędy w raportach:
•
brak listy znalezionych usterek,
•
brak wyspecyfikowania akcji korekcyjnych,
10
Wykład 4 (21)
Przeglądy
Wskazówki dotyczące infrastruktury przeglądów:
•
przygotuj listy kontrolne dla typowych dokumentów podlegających przeglądowi,
•
prowadź doskonalenie prowadzących przeglądy,
•
prowadź analizę efektywności przeglądów i udoskonalaj metodykę prowadzenia
przeglądów,
•
uwzględniaj przeglądy w harmonogramach realizacji projektów, zarezerwuj
odpowiednie zasoby do ich przeprowadznia.
Wykład 4 (22)
Przeglądy
Wskazówki dotyczące przebiegu sesji przeglądu:
•
czas trwania sesji nie powinien przekraczać dwóch godzin,
•
dyskutuj tylko nad\ aspektami merytorycznymi, unikaj personalizacji;
•
zapewnij przyjacielską atmosferę dyskusji,
•
dbaj o zgodność przebiegu sesji z harmonogramem, unikaj przedłużania,
•
skupiaj się na wykrywaniu defektów a nie na szukaniu przyczyn i dyskutowaniu
możliwości ich poprawy
•
unikaj przeciągania dyskusji w kwestiach spornych przekładając ją na inne spotkania,
•
zapewnij przeprowadzenie sesji uzupełniających - jeśli projekt nie został w całości
zaakceptowany.
11
Przeglądy kodu – przejścia (walkthroughs)
Wykład 4 (23)
Przeglądy nieformalne – przejscia (walkthroughs)
Technika o najlepszej skuteczności (od 50% do 80%; średnia 60%; dla
testowania średnia 30%, max 50%)
Cechy przejścia:
•
charakter nieformalny,
•
krótkie przygotowanie obu stron,
•
koncentracja na ulepszeniu jakości dokumentu/kodu (nie procesu) a nie jego ocenie
•
ocena produktu a nie osób,
•
wyłączenie kierownictwa z procesu,
•
znalezione defekty i zastrzeżenia notowane
•
notatka z przeglądu umieszczana w dokumentacji przebiegu zadania
Przeglądy kodu - przejścia
Wykład 4 (24)
Wskaźniki liczbowe do przeprowadzenia przejścia:
•
limity czasu:
o
czas trwania sesji przejścia - 2h
o
czas dodatkowej dyskusji - 1h
•
maksymalnie jedna sesja dzienie:
•
szybkość przygotowywania recenzenta - 100 .. 500 lini/h
•
szybkość przejścia - 50..500 linni/h
•
poziom odrzucenia sesji - 5% linii kwestionowanych
12

Jakość osiągana przez stosowanie: technik i metod: właściwego

Transkrypt

Podobne dokumenty

Ogłasza konkurs na stanowiska naukowe

Klasyfikacja dziedzin nauki według Głównego Urzędu Statystycznego

STUDIA I STOPNIA - INŻYNIERIA ZARZĄDZANIA - 3,5

pobierz plik

Ogłasza konkurs na stanowiska naukowe

Kierownik Produkcji

IN YNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w

Pół roku działalności nowego hangaru