Wymiarowanie projektów informatycznych Metoda punktów funkcyjnych.

Transkrypt

1 Nr indeksu: Wymiarowanie projektów informatycznych Metoda punktów funkcyjnych. 1. Wstęp Statystyki wyraźnie pokazują, że obecnie większość projektów informatycznych kończy się porażką. Niemal 31% z nich jest przerywane, a 53% przekracza przewidywany czas trwania i budżet. Oznacza to, że tylko około 16% projektów realizowane jest zgodnie z przyjętym planem i budżetem. Najczęstszą przyczyną niepowodzenia jest błędne oszacowanie wielkości tworzonego projektu a w związku z tym przyjęcie nierealnych terminów wykonania oraz ustalenie zbyt małego budżetu. Tezę tę potwierdzają badania, mówiące, że tylko 1% realizowanych projektów poddaje się szacowaniu przy użyciu jakiejkolwiek metody. Wniosek jest jeden: szacowanie wielkości wykonywanego systemu informatycznego znacznie zwiększa szanse powodzenia. Powstaje zatem pytanie: w jaki sposób szacować? W 1979 roku Alan Albrecht opracował metodę punktów funkcyjnych (PF). Metoda punktów funkcyjnych służy do szacowania oprogramowania. Może być ona stosowana zarówno przy budowie nowych projektów informatycznych jak i modernizacji oraz rozbudowy istniejących systemów. Metoda ta od 1984 roku jest propagowana i aktywnie rozwijana przez międzynarodową grupę The International Function Point Users Group (IFPUG). Ideą tej metody jest określenie rozmiaru oprogramowania z punktu widzenia użytkownika niezależnie od technologii użytej do jego implementacji. Metoda została opracowana z myślą o aplikacjach transakcyjnych. Jej wadą jest to, że słabo nadaje się do szacowania systemów czasu rzeczywistego czy systemów opartych na komunikacji. Potrzeba szacowania rozmiaru funkcjonalnego tych systemów spowodowała powstanie niezależnych od twórców metody punktów funkcyjnych jej rozszerzeń pozwalających na szacowanie tych systemów. strona 1 z 13

2 2. Opis metody Licząc złożoność aplikacji w punktach funkcyjnych (PF) należy spojrzeć na aplikację w sposób przedstawiony na rys. 1. Aplikacja posiada dane wewnętrzne, którymi w całości zarządza. Są to tzw. wewnętrzne pliki logiczne Internal Logic File (ILF), reprezentowane w systemie przez płaskie pliki lub relacyjną bazę danych. Na zewnątrz aplikacji znajdują się jej użytkownicy oraz współpracujące z nią inne aplikacje. Aplikacje te także posiadają własne dane. Część spośród tych danych zwana jest zewnętrznymi plikami interfejsowymi - External Interface File (EIF). Z użytkownikami oraz zewnętrznymi aplikacjami mierzona aplikacja współpracuje poprzez trzy rodzaje operacji: wejścia (EI - External Input) zapytania (EQ - External Inquire) wyjścia (EO - External Output) Rysunek 1 strona 2 z 13

3 Zewnętrzne wejście jest przepływem informacji z zewnątrz do aplikacji, modyfikuje jej pliki ILF. Przykładem EI mogą być formularze. Zewnętrzne wyjście to przepływ informacji od aplikacji poza jej granice (do użytkownika lub innej aplikacji). Operacja ta może modyfikować pliki ILF aplikacji. Przykładem tego rodzaju operacji mogą być raporty. Zewnętrzne zapytania do jednoczesny przepływ danych do i z aplikacji. Jest to zapytanie do aplikacji pochodzące z zewnątrz. Dane zwracane przez aplikację nie mogę być danymi przetworzonymi, a operacja ta nie może zmieniać plików ILF. Przykładem może być operacja wyszukiwania danych. 3. Schemat liczenia punktów funkcyjnych Istnieją trzy metody liczenia punktów funkcyjnych w zależności od tego, jaka aplikacja jest mierzona. Metody obejmują liczenia punktów funkcyjnych dla: nowopowstających aplikacji, modyfikowanych aplikacji, istniejących aplikacji. Dla nowopowstającej aplikacji, liczenie punktów funkcyjnych składa się z dwóch podstawowych faz: szacowanie rozmiaru funkcjonalnego aplikacji nieostateczna liczba punktów funkcyjnych, czynnik korygujący wynikający z tzw. parametrów wpływu. Rozmiar funkcjonalny aplikacji jest sumą punktów funkcyjnych dla danych i dla transakcji, wynika z funkcjonalności jakiej oczekuje użytkownik. Z kolei czynnik korygujący wynika z charakterystyk systemu, które mogą wpłynąć na jego złożoność. Suma nieostatecznych (nieskorygowanych) punktów funkcyjnych i czynnika korygującego daje ostateczną liczbę punktów funkcyjnych. strona 3 z 13

4 Rysunek 2 4. Szacowanie rozmiaru funkcjonalnego Pierwszym krokiem do szacowanie rozmiaru funkcjonalnego aplikacji, jest identyfikacja zakresu analizy i określenie granic aplikacji. Granice te wynikają z punktu widzenia użytkownika. Relacyjna baza danych składa się z tabel. Tabele przechowywane w bazie danych traktuje się jak elementy typu rekord (RET). Tabele składają się z pól, które traktuje się jako elementy typu dane (DET). Aby określić, czy występuje wewnętrzny pliki logiczny czy zewnętrzny plik interfejsu należy sprawdzić, czy aplikacja dokonuje modyfikacji zawartości pliku. Jeżeli aplikacja modyfikuje zawartość pliku (dodaje, zmienia, usuwa rekordy) jest to plik wewnętrzny, w przeciwnym wypadku jest to plik zewnętrzny. Znając liczbę DET i RET można odczytać stopień złożoności pliku z odpowiednich tabel dla plików wewnętrznych lub zewnętrznych. 5. Szacowanie punktów funkcyjnych dla danych Aby policzyć złożoność funkcjonalną dla danych należy zidentyfikować wszystkie pliki ILF, EIF oraz RET i DET w ramach tych plików. Następnie na podstawie liczby RET i DET poszczególnych plików ILF szacuje się ich złożoność. strona 4 z 13

5 Tabela 1 Następnie na podstawie złożoności i rodzaju pliku szacuje się liczbę punktów funkcyjnych przypadających na jeden plik. Suma punktów funkcyjnych dla wszystkich plików ILF stanowi nieostateczne punkty funkcyjne dla funkcjonalnego rozmiaru danych. 6. Szacowanie punktów funkcyjnych dla transakcji Dla transakcji należy zidentyfikować wszystkie transakcje, jakie będą miały miejsce w systemie. Następnie na podstawie liczby DET, FTR (pliki ILF lub EIF) które uczestniczą w transakcji oraz typu transakcji (EI, EO, EQ) określa się złożoność oraz liczbę punktów funkcyjnych dla każdej transakcji na podstawie tabel nr 2 i 3. Tabela 2 Liczba PF dla EI Tabela 3 Liczba PF dla EO i EQ Do szacowania złożoności transakcji wlicza się DET będące jednostkami danych oraz elementy interfejsu, np. przyciski, paski przewijania. Następnie w zależności od złożoności i rodzaju komunikacji odczytuje się liczbę punktów funkcyjnych przypadającą na transakcję według tabeli nr 4. strona 5 z 13

6 Tabela 4 Na koniec sumuje się punkty funkcyjne uzyskane dla wszystkich transakcji w systemie. 7. Obliczenie rozmiaru funkcjonalnego - nieostatecznych punktów funkcyjnych (NPF) Suma punktów funkcyjnych dla danych i dla transakcji stanowi rozmiar funkcjonalny systemu, czyli nieostateczną liczbę punktów funkcyjnych. 8. Czynnik korygujący (VAF) IFPUG wyodrębnił 14 czynników - składających się na jeden czynnik korygujących (Value Adjustment Factor - VAF). Pozwalają one na określenie ogólnej charakterystyki systemu. Każdemu z nich można przypisać wagę od 0 (brak wpływu) do 5 (silny wpływ). Wagi te wykorzystuje się do obliczenia współczynnika skorygowania. 1. przesyłanie danych 2. przetwarzanie rozproszone 3. wydajność 4. obciążenie platformy sprzętowej 5. stopa transakcji 6. wprowadzanie danych on-line 7. wydajność użytkownika końcowego 8. aktualizacja on-line 9. przetwarzanie złożone 10. wielokrotna używalność 11. łatwość instalacji 12. łatwość obsługi 13. wielokrotna lokalizacja 14. łatwość wprowadzania zmian strona 6 z 13

7 Poniżej przedstawiam w tabeli opis 14 czynników korygujących z opisem ich wag. Komunikacja Charakterystyka określa wykorzystanie przez aplikację różnych protokołów komunikacyjnych. 0 Aplikacja jest czysto wsadowa albo działa na jednym komputerze. 1 Aplikacja jest wsadowa, ale wykorzystuje zdalne wprowadzanie danych lub zdalne drukowanie. 2 Aplikacja jest wsadowa, ale wykorzystuje zdalne wprowadzanie danych i zdalne drukowanie. 3 Aplikacja posiada front-end do przetwarzania wsadowego oraz wprowadzania danych on-line. 4 Aplikacja jest więcej niż front-endem i wykorzystuje tylko jeden protokół komunikacyjny. 5 Aplikacja jest więcej niż front-endem i wykorzystuje wiele protokołów komunikacyjnych. Przetwarzanie rozproszone Charakterystyka określa w jakim stopniu następuje wymiana danych pomiędzy komponentami systemu. 0 Aplikacja jest monolityczna. 1 2 Aplikacja przygotowuje dane dla przetwarzania przez użytkownika w innych komponentach systemu, np. bazie danych albo arkuszu kalkulacyjnym. Dane są przygotowywane do transferu, a następnie przesyłane pod kontrolą aplikacji do innego systemu (nie dla użytkownika końcowego). 3 Występuje przetwarzanie rozproszone on-line jednokierunkowe. 4 Występuje przetwarzanie rozproszone on-line dwukierunkowe. 5 Funkcje przetwarzania dynamicznie wykorzystują najodpowiedniejsze rozproszone komponenty systemu. Wydajność Charakterystyka określa wpływ czasu odpowiedzi systemu i przepustowości na proces tworzenia aplikacji. 0 Nie ma specjalnych wymagań odnośnie wydajności Wymagania odnośnie wydajności zostały postawione, lecz nie były potrzebne dodatkowe działania w trakcie tworzenia aplikacji. Czas odpowiedzi i przepustowość są krytyczne jedynie w godzinach szczytu. Nieprzekraczalny termin zakończenia przetwarzania przypada na następny dzień roboczy. Czas odpowiedzi i przepustowość są krytyczne w codziennych godzinach pracy. Projekt musi jednak wziąć pod uwagę uwarunkowane czasowo interfejsy. Dodatkowo wymagania wydajnościowe użytkownika są dostatecznie wysokie, by spowodować konieczność wykonania analizy wydajności systemu w fazie projektowej. 5 Dodatkowo proces tworzenia aplikacji wymaga użycia specjalnych narzędzi do projektowania i implementacji systemu o dużej wydajności. Specjalne wymagania odnośnie konfiguracji Charakterystyka określa wpływ ograniczeń dotyczących zasobów sprzętowych na tworzenie aplikacji. 0 Nie ma jawnych lub niejawnych ograniczeń odnośnie konfiguracji. 1 Istnieją ograniczenia operacyjne, lecz są mniej restrykcyjne niż dla typowych aplikacji. Spełnienie strona 7 z 13

8 wymagań nie wymaga dodatkowych działań. 2 Aplikacja wymaga uwzględnienia czynników czasowych lub dotyczących bezpieczeństwa. 3 Istnieją specyficzne lub nadzwyczajne wymagania odnośnie procesora dla części aplikacji. 4 Wymagane są specjalne ograniczenia dla aplikacji działającej na głównym procesorze. 5 Dodatkowo istnieją dodatkowe ograniczenia dla aplikacji w rozproszonych komponentach. Tempo transakcji Określa wpływ tempa transakcji biznesowych na tworzenie aplikacji. 0 Nie przewiduje się spiętrzenia liczby transakcji. 1 Przewiduje się spiętrzenie liczby transakcji występujące okresowo. 2 Przewiduje się spiętrzenie tygodniowe. 3 Przewiduje się spiętrzenie dzienne. 4 Wysokie tempo transakcji jest jednym z wymagań. Niezbędna jest analiza wydajnościowa w fazie projektowania. 5 Jak wyżej i dodatkowo niezbędne są narzędzia do analizy wydajności w fazie projektowania, produkcji i/lub instalacji. Wprowadzanie danych on-line Określa wpływ ilości interaktywnych transakcji wprowadzania danych na tworzenie aplikacji. 0 Wszystkie transakcje są przetwarzane wsadowo. 1 1%-7% transakcji odbywa się w trybie interaktywnego wprowadzania danych. 2 8%-15% transakcji odbywa się w trybie interaktywnego wprowadzania danych. 3 16%-23% transakcji odbywa się w trybie interaktywnego wprowadzania danych. 4 24%-30% transakcji odbywa się w trybie interaktywnego wprowadzania danych. 5 Ponad 30% transakcji odbywa się w trybie interaktywnego wprowadzania danych. Specjalne ułatwienia dla Użytkownika Określa wpływ czynników ludzkich i wymagań dotyczących wygody użytkownika na tworzenie aplikacji. Pod uwagę bierze się: a. Ułatwienia nawigacji b. Menu c. Pomoc i dokumentację on-line d. Przewijanie ekranu e. Zdalne drukowanie (obsługa drukarki sieciowej) f. Klawisze skrótu g. Wywoływanie przetwarzania wsadowego z transakcji on-line h. Wybieranie pól danych przez ustawianie kursora (niesekwencyjne wprowadzanie danych) strona 8 z 13

9 i. Duże użycie wideo, podświetlania, kolorów itp. j. Drukowanie elektronicznej dokumentacji użytkownika k. Mysz l. Wyskakujące okna m. Optymalizacja liczby otwartych okien n. Wspomaganie dwu języków (liczyć jako 4) o. Wspomaganie wielu języków (liczyć jako 6) p. Automatyczne przenoszenie kursora Stopień wpływu 0 Żadna z powyższych cech. 1 1 do 3 cech. 2 4 do 5 cech. 3 6 lub więcej, nie ma jednak specyficznych wymagań co do ułatwień. 4 Jak wyżej oraz podane są wymagania odnośnie interfejsu użytkownika, wymuszające projektowanie pod tym kątem. 5 Jak wyżej i ponadto potrzebne są specjalne narzędzia oraz procesy, które pokażą, że osiągnięto cel. Modyfikacje on-line Określa wpływ modyfikacji wewnętrznych zbiorów danych na tworzenie aplikacji. 0 Brak. 1 2 Aktualizacja on-line jest dokonywana dla jednego do trzech zbiorów. Obszar aktualizacji nie jest duży, a odtworzenie poprzedniego stanu jest łatwe. Aktualizacja on-line jest dokonywana dla czterech lub więcej zbiorów. Obszar aktualizacji nie jest duży, a odtworzenie poprzedniego stanu jest łatwe. 3 Aplikacja umożliwia aktualizację on-line wszystkich podstawowych zbiorów. 4 5 Dodatkowo niezbędne jest zabezpieczenie przed utratą danych, które musi być specjalnie zaprojektowane i oprogramowane w systemie. Dodatkowo duże i rozległe aktualizacje powodują, że w projekcie aplikacji rozważa się koszty odtwarzania stanu poprzedniego po skasowanej aktualizacji. Niezbędny jest proces odtwarzania w pełni zautomatyzowany i wymagający minimalnej inwencji operatora. Złożone przetwarzanie Określa wpływ logiki przetwarzania na tworzenie aplikacji. Rozważane są: a. Specjalne procedury bezpieczeństwa. b. Złożone logiczne przetwarzanie. c. Złożone przetwarzanie matematyczne. d. Rozbudowana obsługa wyjątków, związana z ponownym przetwarzaniem niekompletnych transakcji. strona 9 z 13

10 e. Złożone przetwarzanie do obsługi wielu wariantów wejścia/wyjścia (np. multimedia, niezależność od urządzeń wejściowych). Stopień wpływu 0 Żaden element złożoności nie występuje. 1 Jeden z wymienionych. 2 Dwa z wymienionych. 3 Trzy z wymienionych. 4 Cztery z wymienionych. 5 Wszystkie wymienione elementy. Wielokrotne wykorzystywanie Określa w jakim stopniu aplikacja została zaprojektowana i oprogramowana w celu ponownego użycia jej fragmentów w innym oprogramowaniu. 0 Kod nie jest przeznaczony do wielokrotnego użycia. 1 Wielokrotnie wykorzystywany kod jest częścią aplikacji. 2 Mniej niż 10% aplikacji jest zbudowane z kodu wielokrotnego użycia. 3 10% lub więcej aplikacji jest zbudowane z kodu wielokrotnego użycia. 4 Aplikacja została specjalnie zaprojektowana jako aplikacja wielokrotnego użycia i dokonuje się jej dostosowania dla każdego indywidualnego klienta. 5 Jak powyżej, dostosowania może dokonać użytkownik poprzez parametryzację. Łatwość instalacji Określa czy i w jakim stopniu konwersja z poprzedniego środowiska wpływa na tworzenie aplikacji. 0 Nie ma żadnych wymagań użytkownika i nie są konieczne żadne ułatwienia instalacyjne Użytkownik nie stawiał wymagań odnośnie łatwości instalacji, jednakże procedura instalacyjna jest potrzebna. Wymagania odnośnie instalacji zostały przedstawione i w związku z tym powstały odpowiednie procedury instalacyjne wraz z dokumentacją, testami i podręcznikiem. Wpływ tych procedur na projekt aplikacji nie jest istotny. Wymagania odnośnie instalacji zostały przedstawione i w związku z tym powstały odpowiednie procedury instalacyjne wraz z dokumentacją, testami i podręcznikiem. Wpływ tych procedur na projekt aplikacji jest znaczący. 4 Jak wyżej dla punktu 2 i ponadto dostarcza się automatyczne narzędzia instalacyjne wraz z testami. 5 Jak wyżej dla punktu 3 i ponadto dostarcza się automatyczne narzędzia instalacyjne wraz z testami. Łatwość operowania Określa wpływ na tworzenie aplikacji takich aspektów jak kopie zapasowe, odtwarzanie systemu. 0 Nie ma wymagań oprócz standardowego backupu. strona 10 z 13

11 1-4 Jedna lub kilka następujących cech zostały zaimplementowane w aplikacji. Wybieramy wszystkie zaimplementowane. Każda cecha to jeden punkt (chyba, że zaznaczono inaczej): Sprawny i szybki rozruch aplikacji, backup i odtwarzanie po awarii są implementowane, ale wymagają interwencji administratora (operatora). Sprawny i szybki rozruch aplikacji, backup i odtwarzanie po awarii są implementowane i nie wymagają interwencji administratora (liczyć jako 2). Aplikacja minimalizuje konieczność zastosowania taśm, dysków itp. Aplikacja minimalizuje konieczność użycia papieru. 5 Aplikacja została zaprojektowana do pracy bez specjalnego nadzoru operatora. Istnieją procedury automatycznego odtwarzania po awarii. Wiele miejsc przetwarzania Określa, w jakim stopniu aplikacja została zaprojektowana do działania na wielu stanowiskach. 0 1 Wymagania użytkownika nie zawierają informacji o konieczności instalacji więcej niż jednego stanowiska aplikacji. Uwzględniono w projekcie potrzebę instalacji w wielu miejscach, jednakże wszystkich instalacji dokonuje się na identycznym sprzęcie i środowisku operacyjnym Uwzględniono w projekcie potrzebę instalacji w wielu miejscach, jednakże wszystkich instalacji dokonuje się na podobnym sprzęcie i podobnym środowisku operacyjnym. Uwzględniono w projekcie potrzebę instalacji w wielu miejscach, aplikacja jest zaprojektowana do działania na różnym sprzęcie i/lub różnych środowiskach operacyjnych. Aplikacja jest taka jak opisano dla 1 lub 2 i ponadto opracowana jest specjalna dokumentacja instalacyjna oraz dostarcza się z aplikacją testy sprawdzające poprawność instalacji w wielu miejscach. 5 Aplikacja jest taka jak opisano dla 3 i ponadto opracowana jest specjalna dokumentacja instalacyjna oraz dostarcza się z aplikacją testy sprawdzające poprawność instalacji w wielu miejscach. Ułatwienia dla zmienności i elastyczności Określa możliwość łatwej modyfikacji logiki przetwarzania lub struktury danych aplikacji. Pod uwagę brane są następujące elementy: a. b. c. d. e. Elastyczne zapytania i raporty umożliwiają użytkownikowi tworzenie prostych kwerend (np. możliwość użycia operatora i/lub do pojedynczego wewnętrznego zbioru logicznego). Elastyczne zapytania i raporty umożliwiają użytkownikowi tworzenie kwerend o średniej złożoności (np. możliwość użycia operatora i/lub w zapytaniach kierowanych do kilku wewnętrznych plików logicznych) (liczone jako 2). Elastyczne zapytania i raporty umożliwiają użytkownikowi tworzenie kwerend o dużej złożoności (np. możliwość użycia kombinacji operatorów i/lub w zapytaniach kierowanych do jednego lub kilku wewnętrznych zbiorów logicznych) (liczone jako 3). Biznesowe informacje sterujące są przechowywane w tabelach dostępnych użytkownikowi. Użytkownik może zmieniać te parametry, jednakże zmiany wpływają na działanie systemu od następnego dnia. Biznesowe informacje sterujące są przechowywane w tabelach dostępnych użytkownikowi. Użytkownik może zmieniać te parametry, efekt tych zmian nastąpi dynamicznie natychmiast po ich wprowadzeniu. (liczone jako 2) Stopień wpływu strona 11 z 13

12 0 Aplikacja nie posiada żadnej z wymienionych charakterystyk. 1 Jedna z wymienionych. 2 Dwie z wymienionych. 3 Trzy z wymienionych. 4 Cztery z wymienionych. 5 Wszystkie. Umiejętność oszacowania rozmiaru aplikacji daje wiele korzyści: pozwala na określenie czasu realizacji projektu, liczby osób potrzebnych do ukończenia go w określonym terminie oraz kosztów realizacji systemu. Mimo, że metoda punktów funkcyjnych nie była opracowana z myślą o systemach opartych na interfejsach graficznych, po modyfikacjach można ją zastosować do ich szacowania. Źródło: W projekcie informatycznym dotyczącym mojej pracy dyplomowej wyliczenia metodą punktów funkcyjnych prezentują się następująco: Prosty Średni Złożony RAZEM Wejścia EI 4*3 2*4 1*6 26 Wyjścia EO 3*4 3*5 1*7 34 Zapytania EQ 2*3 1*4 3*6 28 Pliki wewnętrzne 2*7 1*10 0*15 24 ILF Plik zewnętrzne 3*5 1*7 0*10 22 EIF SUMA= 134 Tabela 5 Ocena punktów funkcyjnych NPF=88+46=134 strona 12 z 13

13 WSPÓŁCZYNNIK WAGA przesyłanie danych 1 przetwarzanie rozproszone 0 Wydajność 1 obciążenie platformy sprzętowej 1 stopa transakcji 0 wprowadzanie danych on-line 0 wydajność użytkownika końcowego 2 aktualizacja on-line 0 przetwarzanie złożone 0 wielokrotna używalność 0 łatwość instalacji 2 łatwość obsługi 1 wielokrotna lokalizacja 0 łatwość wprowadzania zmian 2 SUMA = 10 Tabela 6 Ocena czynnika korygującego VAF = 0,65+(0,01*10)=0,66 PF=VAF*NPF=0,66*134=89 Dla mierzonego projektu szacowana liczba linii kodu oraz nakład pracy w osobomiesiącach przedstawia się następująco: Język Poziom LZK/PF Linie kodu PF/MM Osobomiesiące języka C * /15=5,9 strona 13 z 13