Metody pomiaru i szacowania oprogramowania

Transkrypt

1 Metody pomiaru i szacowania oprogramowania Metryki punktów funkcyjnych Przygotował: dr inż. Rafał Mrówka Wydział Elektrotechniki, Automatyki, Informatyki i Inżynierii Biomedycznej Katedra Informatyki

2 Analiza punktów funkcyjnych tło historyczne Oryginalnie wprowadzona przez Allana Albrechta w 1979 roku Wprowadza nową metrykę oprogramowania punkty funkcyjne Pierwsza publikacja metody 1981, następnie 1984 (rewizja) International Function Piont User Group IFPUG 1986 Obecna wersja podręcznika IFPUG Manual 4.1 2

3 Podobne metryki Feature points rozszerzenie prac Albrechta przez Caper Jones o modele naukowe Mark II brytyjskie rozszerzenie FP o bogatsze struktury danych wewnętrznych 3D function points metryka Holenderskiego Stowarzyszenia Metryk Oprogramowania (obecnie to samo co IFPUG) Full function points uzupełnienie FP o elementy systemów czasu rzeczywistego Evolved funtion points uproszczona metoda IFPUG (Galorath Inc.)

4 Standard ISO WG12 w 1994 zdefiniowało wymogi wobec FSM (Functional Size Measurement) W 1998 część członków WG12 powołali do życia COSMIC (Common Software Measurement International Consortium) W ramach COSMIC przedstawiono COSMIC-FFP (1999) ostatnia wersja 2.2 w roku 2003 ISO nie wskazało jednej metody (niech rynek zdecyduje)

5 Definicja metryki punktów funkcyjnych Zgodnie z IFPUG: Standardowa metoda (metryka) pomiaru wielkości oprogramowania z punktu widzenia użytkownika

6 Cele analizy punktów funkcyjnych Pomiar wielkości funkcjonalności, którą otrzymuje użytkownik Pomiar wielkości oprogramowanie niezależnej od wykorzystanej technologii Narzędzie, które minimalizuje koszty samego procesu pomiaru Dostarcza standardowej metryki oprogramowania do celów porównawczych

7 Cechy analizy punktów funkcyjnych Podstawowy termin użytkownik (definiuje wymagania, akceptuje testy) Metoda bazuje na wymaganiach abstrahuje od technologii W zależności od technologii zmienia się tylko przelicznik FP -> koszty, czas, LOC, itd. Analiza FP może być wykonywana na każdym etapie projektu Metoda polega na dekompozycji i zliczaniu Obejmuje także metody analizy i rozwiązywania problemów Analiza FP wykorzystuje architekturę LOGICZNĄ systemu 7

8 Rzeczywiste zalety FPA Metryka zrozumiała na nie-informatyków efektywna komunikacja Pozwala na zastosowanie metody na wcześniejszych etapach projektu Ułatwia zarządzanie zakresem projektu stanowi inwentaryzację funkcji systemu Zakłada możliwość dostosowania współczynników kosztowych do danej organizacji 8

9 Kiedy nie stosować FPA Do wyznaczenia kosztów utrzymania systemu Identyfikacji i rozwiązania problemu technicznego lub wdrożeniowego W przypadku braku lub małej wiarygodności danych o wydajności zespołu projektowego Jeżeli ilość dostępnych informacji pozwala na zastosowania bardziej dokładnych metod estymacji 9

10 Produktywność w FPA Produktywność jest kluczowym elementem metody punktów funkcyjnych Z teorii ekonomi wiemy, że: produktywność = wartość wyjściowa/wartość wejściowa W przypadku oprogramowania, przyjmujemy: produktywność = jednostka wielkości / koszt wytworzenia jednostki Dla FPA miarą produktywności jest FP/md 10

11 Przedmiot analizy System komputerowy traktujemy jako zbiór elementarnych procesów (logicznych, nie fizycznych) odpowiada scenariuszowi testowemu (akceptacyjnemu) Rozróżniamy dwa typy procesów podstawowych: transportujące dane przenoszą dane poprzez granicę systemu, wykorzystujące interfejsu zewnętrzne do komunikacji z otoczeniem stacjonarne lub bezdanowe realizujące logikę biznesową, wykorzystujące dane wewnętrzne 11

12 Proces estymacji w FPA 12

13 Krok 1 określenie rodzaju FP Implementacyjne punkty funkcyjne punkty funkcyjne obliczane w czasie trwania projektu i budowy systemu Punkty funkcyjne rozszerzeń punkty funkcyjne rozbudowy działającego, produkcyjnego systemu Punkty funkcyjne aplikacji punkty funkcyjne przeliczone dla gotowej aplikacji (base line), stosowane w celu wyznaczenia wydajności, skali porównawczej, itd. 13

14 Krok 2 zdefiniowanie zakresu systemu Granica systemu określa miejsce interakcji pomiędzy aplikacją a użytkownikiem lub innym systemem Poprawna definicja granicy systemu wymaga zrozumienia biznesowego punktu widzenia użytkownika (a nie technicznego)

15 Krok 3 identyfikacja kategorii funkcjonalnych Zewnętrzne dane wejściowe (EI) ekrany, formularze, okna dialogowe lub sygnały sterujące, za pomocą których użytkownika lub program zewnętrzny zarządza danymi programu Zewnętrzne dane wyjściowe (EO) ekrany, raporty, wykresy lub sygnały sterujące, które program generuje w celu ich wykorzystania przez użytkownika lub program zewnętrzny

16 Elementy logiczne modelu systemu - kwerendy Kwerendy zewnętrzne (EQ) kombinacje danych wejściowych oraz wyjściowych, które generowane są natychmiastowo na podstawie zadanych atrybutów. Określenie pochodzi z terminologii baz danych odpowiada wyszukiwaniu danych na podstawie jednego klucza. Obecnie kwerendy określa się jako dane pobierane z bazy danych w wyniku jednego zapytania.

17 Elementy logiczne modelu systemu - pliki Wewnętrzne pliki logiczne (ILF) duże grupy logiczne danych użytkownika lub informacji sterujących, kontrolowane całkowicie przez program. Plik logiczny może składać się z jednego pliku płaskiego lub pojedynczej tabeli relacyjnej baz danych Zewnętrzne pliki interfejsu (EIF) - pliki kontrolowane przez inne programy, które są wykorzystywane przez analizowany system

18 Zewnętrzne dane wyjściowe EI to jakakolwiek funkcja lub transakcja, która przesyła dane do aplikacji Szukamy wszystkich elementów interfejsu, które zmieniają wewnętrzne dane logiczne (ILF): Każdy unikalny format danych traktujemy jako osobny EI Liczymy jeden EI dla każdego procesu zmiany danych (dodawanie, zmiana, usunięcie)

19 Przykłady EI Dane klienta w pliku kont klienta Dane transakcji w historii konta Pozycja satelity w systemie GPS Dane na fakturze

20 Zduplikowane EI Jako osobny EI liczymy każde osobne wejście do tego samego procesu Przykład: System bankowy może otrzymać dyspozycję lokaty przez bankomat lub przez IVR dwa osobne EI

21 Przykłady negatywne Dane nie utrzymywane przez system (pobierane jako EIF) Dane selekcji z zewnętrznej kwerendy Menu nawigacyjne Ekran logowania, który umożliwia zalogowanie do systemu, ale nie utrzymuje ILF

22 Złożoność EI Każdy EI może należeć do jednej z trzech grup złożoności: Niska Średnia Wysoka Złożoność określamy na podstawie ilości typów plików referencyjnych (FTR) oraz typy składowych danych (DET)

23 Identyfikacja DET DET to unikalne, rozpoznawalne przez użytkownika, niepowtarzające się pole lub atrybut, także klucz obcy, który przekracza granicę systemu i jest utrzymywana przez ILF Wyjątki: Dane zduplikowane fizycznie jedno pole ILF, prezentowane jako dwie kontrolki Pola które są wykorzystywane do powiązania tabel relacyjnych liczmy tylko raz

24 DET jako elementy GUI Definicja element danych rozpoznawanych przez użytkownika, nie rekurencyjny Elementy DET w GUI: Radio buttons Check boxes Command buttons Wykres lub grafika (także ikona) Dzwięki (ciąg) Fotografie Komunikaty (błędy, notyfikacje, itd.)

25 Identyfikacja FTR FTR liczymy dla każdego elementu ILF lub plików, które są wykorzystywane podczas procesowania danego EI oraz dla wszystkich EIF lub plików wykorzystywanych podczas procesowania EI

26 Klasyfikacja EI (złożoności) FTR DET >15 <2 Niska(3) Niska(3) Średnia(4) 2 Niska(3) Średnia(4) Wysoka(6) >2 Średnia(4) Wysoka(6) Wysoka(6)

27 Zewnętrzne dane wyjściowe Zewnętrzne dane wyjściowe EO to funkcja lub transakcja, która przetwarza oraz prezentuje dane użytkownikowi Przykłady: Reporty (ten sam raport w dwóch formach prezentacji to dwa EO) Polecenie dla innego systemu wysłany przez system Dane prezentowane przez EO muszą być utrzymywane przez ILF

28 Przykłady negatywne Pomoc systemowa Komunikaty błędów lub systemowe (to jest DET) Takie same raporty ale prezentujące różne dane (np. za różny okres) Pola podsumowania Raporty ad hoc

29 Jak liczyć DET dla EO Wielokrotne pola widoczne dla użytkownika są liczone jako pojedynczy DET Każde unikalne polecenie lub parametr wykonania raportu liczymy jako DET Każdy typ znakowy (np. kolumna) lub typ numeryczny raportu traktujemy jako DET Nie liczymy etykiet statycznych Nie liczymy numerowania stron lub daty systemowej

30 Klasyfikacja EO (złożoności) FTR DET >19 <2 Niska(4) Niska(4) Średnia(5) 2-3 Niska(4) Średnia(5) Wysoka(7) >3 Średnia(5) Wysoka(7) Wysoka(7)

31 Kwerendy zewnętrzne EQ Kwerenda zewnętrzna to unikalne zapytanie, którego wynikiem są dane Żądanie EQ nie zmienia wartości ILF lub EIF dane są jedynie pobierane Procesy inne poza bezpośrednim pobraniem danych z ILF lub EIF nie są EQ

32 Przykłady EQ Wyszukiwanie danych na podstawie danych wejściowych (kryteriów) Ekran logowania do systemu liczymy jako EQ (zapytanie o login i hasło) Lista ostatnio otwarte w menu Dynamiczne pop-menu System pomocy kontekstowej (wyszukiwanie po słowach kluczowych)

33 Przykłady negatywne EQ Komunikaty błędów lub systemowe Wielokrotne wywołanie tej samej logiki EQ (rożne sposoby Menu tylko z możliwością wyboru wyświetlanego ekranu System testowy oraz wsparcie w nauczaniu (e-learning)

34 Klasyfikacja EQ (złożoności) FTR DET >19 <2 Niska(3) Niska(3) Średnia(4) 2-3 Niska(3) Średnia(4) Wysoka(6) >3 Średnia(4) Wysoka(6) Wysoka(6)

35 Zewnętrzne pliki interfejsu Zbiór powiązanych logicznie plików rozpoznawalnych przez użytkownika Informacje sterujące wykorzystywane przez aplikację i utrzymywane przez system zewnętrzny EIF mogą być używane przez EI lub EO EIF obejmuje: Dane przechowywane poza granicami aplikacji Dane nie zarządzane w aplikacji Identyfikowane jako wymaganie przez użytkownika

36 Przykłady negatywne EIF Dane otrzymane z innej aplikacji, które dodają, zmieniają lub usuwają dane w ILF Dane utrzymywane przez aplikację i udostępniane innej aplikacji Dane sformatowane i procesowane dla użytkownika przez inną aplikację (to jest EO)

37 Złożoność EIF Złożoność obliczamy na podstawie DET oraz RET (Record element type) Zliczanie DET: DET liczymy z perspektywy użytkownika Powtarzane wartości tego samego pola są liczone jako jeden DET (np. kolumna z ceną) Typ rekordu RET podgrupy danych identyfikowane przez użytkownika RET bazuje na relacji rodzic dziecko (jeden do wielu) i dotyczy plików danych (EIF, ILF)

38 Przykład RET Dwa ILF, dwa RET Jeden ILF, dwa RET

39 Klasyfikacja EIF (złożoności) RET DEF >50 1 Niska(5) Niska(5) Średnia(7) 2-5 Niska(5) Średnia(7) Wysoka(10) >5 Średnia(7) Wysoka(10) Wysoka(10)

40 Wewnętrzne pliki logiczne Zbiór danych identyfikowanych przez użytkownika logicznie powiązanych Informacje sterujące wykorzystywane i zarządzane przez aplikację ILF może być wykorzystywane przez EI, EO, EQ ILF zapisuje informację przetwarzane przez wewnętrzne funkcje aplikacji

41 Identyfikacja ILF Dane wewnętrzne aplikacji Zarządzane przez standardowe procesy aplikacji Zdefiniowane jako wymaganie funkcjonalne użytkownika Dane zgrupowane w logiczne obszary odnoszące się do konkretnych wymagań

42 Przykłady ILF Baza kont klientów w systemie bankowym Mapa węzłów mapy GPS Baza kontaktów XML z danymi studentów Kopia zapasowa jeżeli występuje w wymaganiach klienta

43 Klasyfikacja ILF (złożoności) RET DET >50 1 Niska(7) Niska(7) Średnia(10) 2-5 Niska(7) Średnia(10) Wysoka(15) >5 Średnia(10) Wysoka(15) Wysoka(15)

44 Powiązanie modułów i elementów Komponent RET FTR DET EI EO EQ

45 Krok 4 Zliczenie funkcji danych Zliczamy ILE oraz EIF zidentyfikowanych w kroku 3 w systemie Niekiedy warto wspomóc się diagramem encji (w przypadku istniejących systemów) Dla każdej encji (typu danych) należy podjąć decyzję w zakresie utrzymywania tej encji wewnątrz (ILE), na zewnątrz (EIF)

46 Krok 5 Zliczenie funkcji transakcyjnych Zliczenie EI, EO oraz EQ EI jest elementem funkcyjnym, a nie częścią fizycznego przepływu danych EO określa proces, który może obejmować: kalkulacje, wyznaczenie nowych danych, aktualizacja ILF lub bezpośrednie działanie aplikacji EQ zwrot danych na podstawie ILF oraz EIF

47 Najczęstsze problemy przy zliczaniu EI, EO, EQ Jeżeli została zidentyfikowana encja logiczna jako ILF, do której nie ma EI, to: wymagania są niekompletne należy uzupełnić EI została źle zakwalifikowana powinna być EIF jako dane referencyjne (read only) Jeżeli posiadamy EI bez ILF, które przechowywały dane to najprawdopodobniej wymagania są niekompletne należy uzupełnić ILF

48 Najczęstsze problemy przy zliczaniu EI, EO, EQ cd. Jeżeli zdefiniowaliśmy funkcję utrzymania danych, które zostały zakwalifikowane jako EIF, to najprawdopodobniej nastąpiła zła kwalifikacja ILF Jeżeli zidentyfikowaliśmy EQ bez źródła danych (EIF lub ILF) to najprawdopodobniej mamy niekompletny model Dane ILF najczęściej realizują funkcję AUDIO (add, update, delete, inquiry, output) warto sprawdzić odniesienie do tych funkcji wśród EI, EO, EQ

49 Przykład EI

50 Przykład EO 10 x DET

51 Przykład EQ

52 Krok 6 - Współczynnik modyfikujący VAF Wyrażenie określa współczynnik modyfikacji: C i wartości wynikające z charakterystyki systemu

53 Współczynniki C i Lp. Nawa Opis 1 Komunikacja Ile ośrodków należy połączyć w celu wymiany danych 2 Przetwarzanie rozproszone Ile danych rozproszonych i funkcji należy przetwarzać 3 Wydajność Czy użytkownik wymaga maksymalnych czasów odpowiedzi? 4 Obciążenie środowiska Jak bardzo wykorzystane jest obecne środowisko sprzętowe 5 Ilość transakcji Jak często transakcje są przetwarzane dziennie, tygodniowo, miesięcznie? 6 Dane on-line Jaki procent danych jest wprowadzanych on-line 7 Ergonomia Czy aplikacja została zaprojektowana z uwzględnieniem wydajności użytkownika?

54 Współczynniki C i cd. Lp. Nawa Opis 8 Aktualizacja on-line Ile ILF jest aktualizowanych w transakcji? 9 Złożone obliczenia Czy aplikacja przeprowadza złożone obliczenia? 10 Ponowne wykorzystanie Czy aplikacja została zaprojektowana do ponownego użycia? 11 Łatwość instalacji Jak trudna jest instalacja? 12 Łatwość użycia Jak łatwa jest procedura uruchomienia, backupu oraz odzyskania? 13 Ilość lokalizacji Cz aplikacja ma być instalowana w wielu lokalizacjach? 14 Zmienność Czy aplikacja została zaprojektowana z uwzględnieniem łatwości wprowadzania zmian?

55 Krok 7 - Obliczanie UFP Moduł Złożoność Niska Średnia Wysoka Suma EI _x3= x4= x6=_ EO _x4= x5= x7=_ EQ _x3= x4= x6=_ ILF _x7= x10= x15=_ ELF _x5= x7= x10=_ Całkowita wartość nieskorygowanych FP

56 Deweloperskie punkty funkcyjne Dla nowych projektów ilość skorygowanych punktów funkcyjnych wyznaczamy jako: FP = (UFP + CFP)*VAF CFP liczba skorygowanych punktów funkcyjnych dla aplikacji konwertującej

57 Punkty funkcyjne aplikacji Dla gotowych aplikacji ilość skorygowanych punktów funkcyjnych wyznaczamy jako: FP = UFP*VAF

58 Punkty funkcyjne rozszerzeń Dla rozszerzeń istniejących aplikacji ilość skorygowanych punktów funkcyjnych wyznaczamy jako: FP = (UFP+CHGA+CFA)*VAFA - (DEL*VAFB) CHGA liczba nieskorygowanych punktów funkcyjnych dla zmodyfikowanych metod CFP liczba punktów funkcyjnych dla aplikacji konwertującej VAFA współczynnik VAF dla aplikacji po zmianie DEL nieskorygowane punkty funkcyjne dla skasowanych funkcji VAFB współczynnik VAFA przed zmianą