Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

Transkrypt

1 Projektowanie oprogramowania Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

2 Agenda Weryfikacja i zatwierdzanie Testowanie oprogramowania Zarządzanie Zarządzanie personelem Szacowanie kosztu oprogramowania Zarządzanie jakością Ulepszanie procesu Ewolucja...

3 Agenda Ewolucja Systemy odziedziczone Modyfikacja oprogramowania Restrukturyzacja oprogramowania Zarządzanie konfiguracjami

4

5 Weryfikacja i zatwierdzanie Co to jest weryfikacja? Czym się różni od zatwierdzania? Z czego wynika przewaga kontroli nad testowaniem? Jak wykrywać defekty w programie podczas kontroli? Jaka jest wzajemna relacja kontroli i testowania? Co to jest analiza statyczna jak jej używać jako istotnego elementu weryfikacji? Jaka jest istota metodologii Cleanroom?

6 Weryfikacja a zatwierdzanie Zatwierdzanie: Czy budujemy odpowiedni produkt? (CO budujemy?) vs Weryfikacja: Czy budujemy produkt odpowiednio? (JAK to budujemy?)

7 Weryfikacja a zatwierdzanie Weryfikacja: Czy oprogramowanie zgodne ze specyfikacją? Zaczyna się od weryfikacji wymagań Trwa przez wszystkie czynności procesu tworzenia oprogramowania

8 Weryfikacja a zatwierdzanie Zatwierdzanie: Podobny okres trwania Bardziej ogólny proces Czy oprogramowanie spełnia oczekiwania klienta? (nie tylko czy spełnia formalne wymagania)

9 Weryfikacja i zatwierdzanie Metody sprawdzania i analizy systemu: Kontrole oprogramowania (inspekcje) Sprawdzanie dokumentacji, diagramów Analizy kodu Nie potrzeba działającego programu Testowanie oprogramowania Dotyczy wykonywalnej wersji systemu Oparte na uruchamianiu programu

10

11 Kontrola i testowanie Kontrola: Bada źródła systemu (model, kod) Jest tańsze niż testowanie Wykrywa więcej błędów Nieformalna kontrola ponad 60% Formalna (matematyczna) ponad 90% Wiele różnych defektów można wykryć w czasie jednej kontroli Uwzględniają wielokrotne użycie wiedzy dziedzinowej Pozwalają wykazać jakościowe cechy programu

12 Kontrola i testowanie Testowanie: Jest jedyną metodą możliwą do zastosowania na poziomie całego systemu Pozwala na zatwierdzenie dynamicznego stanu systemu Pozwala ocenić niezawodność systemu, analizę efektywności, zatwierdzenie interfejsu użytkownika. Pozwala zweryfikować zgodność z oczekiwaniami użytkownika

13 Proces kontroli Powinien być przeprowadzony przez zespół przynajmniej 4 osób. Role w zespole: Autor/właściciel odpowiada za usunięcie znalezionych defektów Kontroler znajduje błędy, pominięcia, niespójności Czytelnik interpretuje kod w trakcie spotkania kontrolnego Pisarz odnotowuje rezultaty spotkania kontrolnego Przewodniczący/moderator zarządza procesem i ułatwia kontrolę, informuje naczelnego moderatora o wynikach procesu. Naczelny moderator odpowiada za ulepszanie procesu kontroli, aktualizację list kontrolnych, standardy

14

15 Automatyczna analiza statyczna Wykorzystuje narzędzia programowe, które przeglądają kod źródłowy programu i wykrywają potencjalne usterki i anomalie. Analiza przepływu sterowania Analiza użycia danych Analiza interfejsu Analiza przepływu informacji Analiza ścieżek

16 Automatyczna analiza statyczna Analiza statyczna najlepiej sprawdza się w językach bez ścisłej kontroli typów C (w mniejszym stopniu C++) FORTRAN języki interpretowalne bez ścisłych typów Najbardziej znanym jest LINT (unix/linux, język C)

17 Metoda Cleanroom Podstawą jest unikanie defektów oprogramowania dzięki rygorystycznej kontroli 1) Specyfikacja formalna 2)Tworzenie przyrostowe 3)Programowanie strukturalne 4)Weryfikacja statyczna 5)Testowanie statystyczne systemu.

18 Zarządzanie Zarządzanie personelem Szacowanie kosztu oprogramowania Zarządzanie jakością Ulepszanie procesu

19 Zarządzanie personelem Personel to najważniejsze dobro firmy Złe zarządzanie personelem jest podstawową przyczyną niepowodzeń Menedżerowie muszą ludzi motywować planować i organizować pracę dbać by praca była wykonana rzetelnie

20 Szacowanie kosztu oprogramowania Różne metody: Metoda delficka wspólne oszacowanie niezleżnych ekspertów Model COCOMO II na podstawie rozmiaru oprogramowania Use Case Points w oparciu i specyfikacje wymagań Gra Planistyczna klient wybiera w oparciu o szacowanie dostawcy oprogramowania

21 Szacowanie kosztu oprogramowania Jakie są miary kosztu oprogramowania? SLOC (source lines of code) Czas (osobo-godziny) Pieniądze ($$)

22 Systematyczne podejście do planowania 1.Szacowanie rozmiaru (SLOC lub inne metryki) 2.Szacowanie pracochłonności Na podstawie metryki przy pomocy dostępnych modeli zamienia się rozmiar na pracochłonność. 3.Szacowanie harmonogramu Posiadając wymaganą pracochłonność oraz dostępne zasoby (ludzkie) można zaplanować harmonogram wykonania.

23 Metoda delficka Koniec lat 40-tych Kilku niezależnych ekspertów szacuje rozmiar według wspólnej metryki Następnie należy dojść do konsensusu

24 Metoda delficka 1. Indywidualna analiza dokumentacji 2. Dyskusja w grupie nt. Analizy 3. Głosowanie oszacowania (tajne) 4. Opracowanie raportów przez moderatora 5. Dyskusja ekspertów nt. wyników (bez podawania oszacowań) 6. Oszacowanie końcowe lub powtórzenie procedury Oszacowanie = (Pesymista + 4*Średnia + Optymista)/6

25 Ewolucja Systemy odziedziczone Modyfikacja oprogramowania Restrukturyzacja oprogramowani Zarządzanie konfiguracjami