właściwego zarządzania

Transkrypt

1 Wykład 4 (1) Jakość w projekcie informatycznym - wstęp Jakość osiągana przez stosowanie: technik i metod: weryfikacji, walidacji, przeglądów, inspekcji, audytów, testowania, dowodzenia poprawności właściwego zarządzania 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 Walidacja proces oceny stopnia spełnienia przez produkt wymagań stawianych mu w specyfikacji Wykład 4 (3) Jakość w projekcie informatycznym - weryfikacja Faza cyklu Analiza wymagań Podstawowy cel weryfikacji Sensowność, niesprzeczność, realizowalność wymagań Zalecane techniki Inspekcje, przeglądy Specyfikacja zewnętrzna Projekt architektury Projekt szczegółowy Kodowanie Testowanie Dokumentowanie Zgodność z wymaganiami, kompletność, spójność, realizowalność techniczna, adekwatność kryteriów akceptacji Zgodność z wymaganiami i specyfikacją zewnętrzną, realizowalność techniczna, Poprawność techniczna, zgodność z PA, Spełnienie atrybutów formalnej poprawności kodu, poprawność pragmatyczna, zgodność z PS Kompletność i adekwatność projektu testów, rzetelność wykonania testów, udowodnienie wyeliminowania znalezionych błędów, wykazanie spełnienia wymagań dla ustalonych danych Czytelność i użyteczność dokumentacji, zgodność ze stanem faktycznym Inspekcje, przeglądy Inspekcje, przeglądy Inspekcje, przeglądy, dowody formalne Inspekcje, przeglądy, dowody formalne, analiza dynamiczna Eksperymenty z programem,, eksperymenty z programem 1

2 Wykład 4 (4) Jakość w projekcie informatycznym - wstęp 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 93% 99% 99% complete series Wykład 4 (2) Jakość w projekcie informatycznym - testowanie 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 Funkcjonalny Systemowy Przetwarzania Danych Kodowania Dokumentacyjny Inny Zła lub brakująca funkcja Źródło pochodzenia Błąd w interfejsach, błędne sterowanie Niewłaściwe przetwarzanie danych w modułach Błędna specyfikacja, projekt, rozmieszczenie lub inicjacja struktur danych Niewłaściwe użycie języka programowania Niepełna lub błędna treść dokumentu 2

3 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: Jakość w projekcie informatycznym - testowanie 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) objętości obsługi pamięci instalacji obsługi Test użyteczności zmęczeniowe poufności konfiguracji kompatybilnosci niezawodności podnoszenia z upadku dokumentacji Jakość w projekcie informatycznym - testowanie Kategorie testowania systemowego Sprawdzenie wymagań funkcjonalnych Sprawdzenie działania dla danych wejściowych dużych rozmiarów Sprawdzenie zachowania przy dużej intensywnosci strumienia danych wejściowych Sprawdzenie zgodności ze specyfikacją w zakresie interfejsu i ergonomii Sprawdzenie odporności na próby nieuprawnionego dostępu do danych Sprawdzenie zapotrzebowania na pamięć Próba pracy w różnych konfiguracjach (np. z różnymi wersjami SO) Sprawdzenie poprawności pracy po rozbudowie (np. współdziałanie z danymi o poprzednim formacie, sprawdzenie skuteczności rekonstrukcji danych itp) Sprawdzenie poprawności przebiegu instalacji Zebranie statystyk charakteryzujących niezawodność w określonym środowisku Sprawdzenie skuteczności odtwarzania po wymuszonym upadku (np. po awarii zasilania, zamknięciu przez SO itp.) Obserwacja sposobu eksploatacji przez przeszkolony personel Sprawdzenie przydatności dokumentcji Czynność 3

4 Wykład 4 (7) Strategie testów: Jakość w projekcie informatycznym - wstęp 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) Jakość w projekcie informatycznym - testowanie 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

5 Wykład 4 (9) ` Dokumentacja testów: Projekt testów: Wydzielenie obszarów testowania Specyfikacja przypadków testowych Zasady organizacji pracy przy testowaniu Harmonogram testów Specyfikacja przypadku testowego: Identyfikator testu i planu Dokumentacja przeprowadzenia testów: Identyfikator przypadku testowego Data wykonania i dane testera, Wersja testowanego oprogramowania, Status zaliczenia, 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 Dane o środowisku wykonania, Zauważone nieprawidłowości, Identyfikacja zgłoszonych błędów Wykład 4 (10) Jakość w projekcie informatycznym - wstęp 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

6 Wykład 4 (11) Jakość w projekcie informatycznym - wstęp 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ąd (w/g IEEE ) - 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

7 Wykład 4 (13) Cele przeglądu: Cele bezpośrednie: bezpośrednie - związane z projektem poddanym przeglądowi pośrednie - związane z doskonaleniem zespołu 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) 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

8 Wykład 4 (15) 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) 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

9 Wykład 4 (17) 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) 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

10 Wykład 4 (19) 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) 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

11 Wykład 4 (21) 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) 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

12 Wykład 4 (23) kodu przejścia (walkthroughs) 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 Wykład 4 (24) kodu - przejścia 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 lini/h szybkość przejścia linni/h poziom odrzucenia sesji - 5% linii kwestionowanych 12