Spis treści: 1Wstęp...3 2Metody szacowania...3 3Wady metod opartych na jednostkach programowych...3 4Metoda punktów funkcyjnych (MPF)...

Spis treści: 1Wstęp...3 2Metody szacowania...3 3Wady metod opartych na jednostkach programowych...3 4Metoda punktów funkcyjnych (MPF)...4 5Wstępne pojęcia dotyczące MPF...5 6Schemat liczenia punktów funkcyjnych...6 7Szacowanie rozmiaru funkcjonalnego...7 8Czynnik korygujący...11 9Całkowita liczba punktów funkcyjnych...12 10Przeliczanie punktów funkcyjnych na inne jednostki...13 11Zalety punktów funkcyjnych...14 12Wady punktów funkcyjnych...14 13Warianty metody punktów funkcyjnych...15 14Narzędzia...16 15Dalszy rozwój...16 16Literatura...17 17Słownik pojęć...17

1 Wstęp Statystyki jasno pokazują, że obecnie większość projektów informatycznych kończy się porażką. Aż 31% jest przerywane, a 53% przekracza przewidywany czas trwania i budżet. Oznacza to, że tylko 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 (SI) znacznie zwiększa szanse powodzenia. Powstaje zatem pytanie: w jaki sposób szacować, jaką przyjąć metodę, jakimi jednostkami się posługiwać? 2 Metody szacowania Rozróżnia się dwa rodzaje metod szacowania. Podział ten dokonany jest we względu na jednostki, jakimi się te metody posługują: a) Metody działające na jednostkach programowych b) Metody działające na jednostkach umownych Ad a Do jednostek programowych zalicza się linie kodu źródłowego oraz polecenia (instrukcje). Bez dokładnej analizy można zarzucić tej metodzie brak obiektywności i uniwersalności. Odmienny styl programowania przyjęty w wybranych firmach, a nawet różnice w umiejętnościach programistycznych poszczególnych osób, nie pozwalają na nazwanie tych metod jako godne zaufania. Pozwalają raczej na porównania bardzo szacunkowe albo na porównanie efektywności wykonania tej samej pracy przez różne zespoły projektowe. Przy założeniu, że owe zespoły pracowały w podobnych warunkach, tzn. na przykład wykonywały implementację w tych samych językach programowania. Ad b Najpopularniejszą jednostką umowną są punkty funkcyjne. Wyrażają one wielkość systemu w zależności od jego funkcjonalności. Inne popularne jednostki umowne to punkty charakterystyczne, punkty obiektowe oraz pełne punkty funkcyjne. Wszystkie one powstały na bazie punktów funkcyjnych i mają zastosowanie przy szczególnych typach projektów bądź zawierają inne, nieco zmodyfikowane metody liczenia wielkości systemu. 3 Wady metod opartych na jednostkach programowych Jak już zasugerowano w poprzednim punkcie, metody szacowania wielkości projektów informatycznych oparte na jednostkach takich jak linie kodu źródłowego (LKZ) są dość mało obiektywnym i uniwersalnym narzędziem do estymacji SI. Przedstawimy zatem największe wady tych metod. Wady te były właśnie przyczyną poszukiwań nowych, lepszych rozwiązań. Zaowocowały one opracowaniem metod działających w oparciu o jednostki umowne. Pierwszą dostrzegalną wadą jest dowolność definiowania jednostki. Określenie linia kodu jest bardzo subiektywnym spojrzeniem na wielkość projektu. Nie wiadomo na przykład czy przykładowy kod liczyć jako osiem czy jako dwie linie: 2

1: if(i>10) 2: { 3: do_sth_1(); 4: } 5: else 6: { 7: do_sth_2(); 8: } 1: if (i>10) { do_sth_1(); } 2: else { do_sth_2(); } Przedstawiony przykład jest oczywiście tak dobrany, by pokazać jak największą różnicę. Przy bardziej skomplikowanym kodzie programu sam zapis niektórych instrukcji nie ma aż tak duże wpływu na rozciągnięcie bądź skrócenie kodu (tu: czterokrotnie). Jednak badania statystyczne pokazują, że różnice w wielkości oszacowania tylko z powodu przyjęcia innej definicji jednostki mogą sięgać 100%. Dodatkowym utrudnieniem są zdolności programistyczne pracowników, ich znajomość dobrych algorytmów i rozwiązań klasycznych problemów. Jak już zostało wspomniane, metoda ta jest bardzo silnie uzależniona od stosowanego języka programowania. Uniemożliwi to wykonywanie porównań projektów, jeżeli ich realizacja dotyczyła innych języków. Dodatkowo uzależnienie to powoduje, iż nie można tutaj mówić o produktywności (zespołu projektowego) zgodnej z ekonomiczną definicją produktywności. Dochodzi bowiem do paradoksu, że realizując projekt w bardziej wydajnym języku programowania (czyli kodujemy w mniejszej liczbie linii) wzrasta koszt jednostkowy (czyli koszt całkowity przez liczbę jednostek, tzn. liczbę linii kodu). Dzieje się tak, pomimo, że koszt kodowania (czas pracy programistów) maleje, jednak koszty stałe, które dominują, pozostają bez zmian. [2] Bazowanie jednostek na kodzie źródłowym skutkuje także faktem, że oszacowanie wielkości projektu może być wykonane dopiero w fazie implementacji. Jest to poważna wada, ponieważ bardzo często informacja na temat wielkości SI, a co z tym się wiąże termin realizacji oraz potrzebny budżet, powinna być dostępna już w fazie analizy, gdy być może trzeba by podjąć decyzję o zaniechaniu wykonania projektu, ze względu na brak opłacalności przedsięwzięcia. Innym mankamentem jest to, że metody tego typu odzwierciedlają tylko koszt pracy potrzebny do zaimplementowania systemu, natomiast nie można na podstawie liczby linii kodu bądź instrukcji określić, ile prac trzeba włożyć w wykonanie pozostałych etapów całego procesu wytworzenia systemu. I ostatnią z najważniejszych wad jest brak udziału użytkownika w etapie określania rozmiaru systemu. Użytkownik oczywiście definiuje, jakie funkcje ma pełnić system, ale nie ma wspólnej płaszczyzny, na której mógłby razem z projektantem porozumiewać się w sprawie określania wielkości poszczególnych funkcjonalności, a w rezultacie całego systemu. Przykładowo osoba reprezentująca klienta może nie mieć wyczucia, które z żądanych funkcji są najkosztowniejsze i że być może można byłoby z nich zrezygnować. 4 Metoda punktów funkcyjnych (MPF) Dostrzegając wady metod opartych na jednostkach programowych, np. COCOMO, Allan Albrecht (pracownik firmy IBM) opracował pod koniec lat siedemdziesiątych nową metodą. Bazowała ona na nowych jednostkach na jednostkach umownych. Było to całkowicie nowatorskie podejście do określania rozmiaru systemu informatycznego. Jednostką jest punkt funkcyjny. Metoda ta wyraża wielkość SI uzależnioną od realizowanych funkcji przez 3

projektowany system. Jest dzięki temu niezależna od języka programowania, jest zrozumiała dla klienta i umożliwia porównywanie systemów. Jest to obecnie najczęściej stosowana metoda szacowania wielkości i złożoności SI. Składa się na to fakt ciągłego dopracowywania metody i rozwijanie jej dla różnych zastosowań. Od 1986 roku nadzór nad rozwijaniem i propagowaniem tej metody sprawuje amerykańska instytucja IFPUG (International Function Point Users Group). Obecnie obowiązuje już ósma wersja tej metody. Daty opracowania poszczególnych wersji pokazano w tabeli 1. Pierwszym wersjom zarzucona brak dostatecznej Tabela 1 obiektywności przy określaniu liczby punktów dla Wersja Autor i rok poszczególnych funkcji systemu. Właśnie na ten 1 Albrecht 1979 aspekt położono największy ciężar w kolejnych 2 Albrecht 1983 wersjach metody. Dzisiejsza skuteczność jest na 3 GUIDE 1984 tyle wysoka, że, przy umiejętnym korzystaniu i 4 IFPUG 1986 prawidłowym liczeniu liczby punktów, błąd 5 IFPUG 1988 estymacji może wynosić tylko 10%. Jest to wynik 6 IFPUG 1990 rewelacyjny, biorąc pod uwagę statystyki 7 (4.0) IFPUG 1994 dotyczące przekraczania czasu i budżetu podczas 8 (4.1) IFPUG 1999 wykonywania systemów informatycznych. Źródło: [3] 5 Wstępne pojęcia dotyczące MPF Licząc złożoność aplikacji w punktach funkcyjnych (PF), postrzegamy aplikację w specyficzny przedstawiony na schemacie 1 sposób. Mierzona aplikacja posiada dane wewnętrzne, którymi w całości zarządza. Są to tzw. wewnętrzne pliki logiczne (ang. Internal Logic File), zwane dalej ILF, reprezentowane w systemie przez płaskie pliki lub relacyjną bazę danych. Na zewnątrz mierzonej aplikacji (poza jej granicami) 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 wymieniana z mierzoną przez nas aplikacją (całkowicie rezydująca poza jej granicami) zwana jest zewnętrznymi plikami interfejsowymi (ang. External Interface File), zwane dalej EIF. 4

Użytkownik EQ EI Użytkownik Pliki logiczne ILF EI Pliki komunikacyjne EIF EO Mierzona aplikacja Inne aplikacje Schemat 1 według [3] Z użytkownikami oraz zewnętrznymi aplikacjami mierzona aplikacja współpracuje poprzez trzy rodzaje operacji. Są to: zewnętrzne wejście (ang. External Input), zwane dalej EI zewnętrzne wyjście (ang. External Output), zwane dalej EO zewnętrzne zapytanie (ang. External Inquiry), zwane dalej EQ Zewnętrzne wejście jest przepływem informacji z zewnątrz do mierzonej aplikacji, modyfikuje jej pliki ILF. Przykładek 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. 6 Schemat liczenia punktów funkcyjnych Istnieją trzy metody liczenia punktów funkcyjnych w zależności od tego, jaka aplikacja jest pomiarowana. Metody obejmują liczenia punktów funkcyjnych dla: - nowopowstających aplikacji - modyfikowanych aplikacji - istniejących aplikacji W tej pracy przedstawimy jedynie sposób liczenia punktów funkcyjnych dla nowopowstającej aplikacji. Liczenie punktów funkcyjnych składa się z dwóch, przedstawionych na schemacie 2, podstawowych faz: - szacowanie rozmiaru funkcjonalnego aplikacji nieostateczna liczba punktów funkcyjnych - czynnik korygujący wynikający z tzw. parametrów wpływu 5

Rozmiar funkcjonalny aplikacji jest sumą punktów funkcyjnych dla danych i dla transakcji, wynika z funkcjonalności jakiej domaga się użytkownik. Z kolei czynnik korygujący wynika z charakterystyk systemu, które mogą wpłynąć na jego złożoność. Rozmiar funkcjonalny nieostateczna liczba PF Czynnik korygujący + = parametry wpływu Ostateczna liczba punktów funkcyjnych Pomiar danych Pomiar transakcji schemat 2 według [3] Suma nieostatecznych (nieskorygowanych) punktów funkcyjnych i czynnika korygującego daje ostateczną liczbę punktów funkcyjnych. 7 Szacowanie rozmiaru funkcjonalnego Dla ustalonego wcześniej sposobu liczenia (co wynika z rodzaju mierzonej aplikacji), pierwszym krokiem do szacowanie rozmiaru funkcjonalnego aplikacji, jest identyfikacja zakresu analizy i określenie granic aplikacji. Granice te wynikają z punktu widzenia użytkownika. Powinny być spójne z rzeczywistymi granicami organizacyjnymi jednostki, dla której system jest projektowany (dział, departament). Poszczególne moduły aplikacji mogą odpowiadać funkcjom, jakich użytkownik oczekuje od systemu. 7.1 Pojęcia wstępne Do szacowania złożoności danych i transakcji stosuje się trzy pomocnicze wskaźniki: RET (ang. Record Element Type) unikalna, rozpoznawalna przez użytkownika podgrupa elementów danych w wewnętrznym pliku logicznym (ILF) lub zewnętrznym pliku interfejsowym (EIF); może być rozumiany jako rekord DET (ang. Data Element Type) unikalnie, możliwe do zidentyfikowania przez użytkownika, nierekurencyjne (bez powtórzeń) pole w wewnętrznym pliku logicznym (ILF) lub zewnętrzym pliku interfejsowym (EIF); może być rozumiany jako pojedyncze pole rekordu FTR (ang. File Type Referenced) - wewnętrzny plik logiczny (ILF) lub zewnętrzny plik interfejsowy (EIF) będący punktem odniesienia dla zewnętrznego wejścia 6

7.2 Szacowanie punktów funkcyjnych dla danych Aby policzyć złożoność funkcjonalną dla danych należy zidentyfikować wszystkie pliki ILF, EIF oraz RET-y i DET-y w ramach tych plików. Na projektowanego przez nas systemu zarządzania dla Oddziału Polskiego Towarzystwa Informatycznego mamy 4 pliki ILF, reprezentujące jednostki reprezentowane w systemie: Członka Oddziału, Koło Naukowe, Uczelnię oraz Instytucję. W ramach tych plików wyznaczono RET-y i DET-y. Przykładowo tabela 2 przedstawia RET-y i DET-y dla ILF-a Członek: Tabela 2 ILF: Członek RET dane osobowe adres zainteresowania członek wprowadzający DET - imię - nazwisko - numer członka - tytuł naukowy - data wstąpienia do PTI - ulica - numer domu - numer mieszkania - miejscowość - kod pocztowy - województwo - nazwa zainteresowania - czy w teorii - czy w praktyce - imię - nazwisko - tytuł naukowy - rok wstąpienia do PTI Liczba RET: 4 Liczba RET: 18 Następnie na podstawie liczby RET-ów i liczby DET-ów poszczególnych plików ILF szacuje się ich złożoność według tabel 3 i 4: Tabela 3 Liczba RET Liczba DET 1-19 20-50 >50 1 prosty prosty średni 2-5 prosty średni złożony >5 średni złożony złożony Następnie na podstawie złożoności i rodzaju pliku szacuje się liczbę punktów funkcyjnych przypadających na jeden plik. Tabela 4 Złożoność Wagi ILF ELF prosty 7 5 średni 10 7 złożony 15 10 Na przykład dla podanego wyżej ILF: Wewnętrzny plik logiczny DET RET Złożoność NPF Członek 18 4 Niska 7 Tabela 5 7

Należy pamiętać, że do liczenia rozmiaru funkcjonalnego dla danych należy też dołączyć pliki EIF. Suma punktów funkcyjnych dla wszystkich plików ILF stanowi nieostateczne punkty funkcyjne dla funkcjonalnego rozmiaru danych. 7.3 Szacowanie punktów funkcyjnych dla transakcji Podobnie jak dla szacowania liczby punków funkcyjnych określić trzeba wszystkie pliki ILF oraz EIF, dla transakcji należy zidentyfikować wszystkie transakcje, jakie będą miały miejsce w systemie. Następnie na podstawie liczby DET-ów, FTR-ów (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 6-8: Tabela 6 Dla zewnętrznego wejścia (EI): Tabela 7 Liczba FTR Liczba DET 1-4 5-15 >15 0-1 prosty prosty średni 2 prosty średni złożony 3 średni złożony złożony Dla zewnętrznego wyjścia (EO) i zewnętrznego zapytania (EQ): Tabela 8 Liczba FTR Liczba DET 1-5 6-19 >19 0-1 prosty prosty średni 2 prosty średni złożony 3 średni złożony złożony Do szacowania złożoności transakcji wlicza się nie tylko DET-y będące jednostkami danych, ale także 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 9: Tabela 9 Złożoność Wagi Wyjście Zapytanie Wejście prosty 4 3 3 średni 5 4 4 złożony 7 6 6 8

Dla przykładowych danych mogłoby to wyglądać następująco: Tabela 10 Transakcje Typ FTR DET - DANE DET - GUI Złożoność PF Dodanie nowego EI 3 34 1 Złożone 6 członka Edycja danych członka EI 3 34 1 Złożone 6 Wybranie członka do EQ 1 4 0 Proste 3 edycji lub usunięcia Usunięcie danych EI 3 34 1 Złożone 6 członka Dodanie nowego koła EI 1 4 1 Niska 3 naukowego Wybranie koła naukowego do edycji lub usunięcia EQ 1 1 0 Niska 3 Edycja danych koła naukowego EI 1 4 1 Niska 3 Wewnętrzny plik logiczny DET RET Złożoność NPF Członek 18 4 Niska 7 Koło naukowe 4 1 Niska 7 Uczelnia 10 2 Niska 7 Instytucja 7 2 Niska 7 SUMA 28 Następnie sumuje się punkty funkcyjne uzyskane dla wszystkich transakcji w systemie: SUMA 63 7.4 Obliczenie rozmiaru funkcjonalnego - nieostatecznych punktów funkcyjnych Suma punktów funkcyjnych dla danych i dla transakcji stanowi rozmiar funkcjonalny systemu, czyli nieostateczną liczbę punktów funkcyjnych. NPF = 28 + 63 = 91 9

8 Czynnik korygujący Czynnik korygujący (ang. Value Adjustment Factor - VAF) ma uwzględnić wewnętrzną złożoność systemu nie związaną z jego funkcjonalnością. Określenie współczynnika korekcji polega na podaniu wartości wpływu dla 14 czynników (tabela 11), które mogą wpłynąć na zwiększenie stopnia skomplikowania systemu. Szacunków tych dokonuje ekspert. Oszacowanie wpływu polega na podaniu dla każdej z 14 kategorii współczynnika wpływu o wartościach 0-5, gdzie poszczególne wartości reprezentują: 0 nie reprezentowane lub bez wpływu 1 nieznaczny wpływ 2 umiarkowany wpływ 3 średni wpływ 4 znaczny wpływ 5 silny wpływ Tabela 11 Numer Generalna charakterystyka systemu Krótki opis 1. Przesyłania danych Ile jest urządzeń komunikacyjnych pomagających w transferze lub wymianie informacji z aplikacją lub systemem? 2. Przetwarzanie rozproszone Jak traktuje się rozproszone dane i funkcje przetwarzania? 3. Wydajność Czy użytkownik wymaga określonego czasu odpowiedzi lub określonej szybkości przesyłania danych? 4. Obciążenie platformy sprzętowej Jak obciążona jest obecna platforma sprzętowa, o ile aplikacja będzie na niej wykorzystywana? 5. Stopa transakcji Jaka jest częstość realizacji transakcji na dzień, tydzień, miesiąc etc.? 6. Wprowadzanie danych on-line Jaki procent informacji wprowadza się on-line? 7. Wydajność użytkownika końcowego Czy aplikację należy projektować z punktu widzenia wydajności użytkownika końcowego? 8. Aktualizacja on-line Ile plików wewnętrznych aktualizuje się przy transakcji on-line? 9. Przetwarzanie złożone Cze w aplikacji występuje znaczące przetwarzania logiczne lub matematyczne? 10. Wielokrotna używalność Czy aplikację należy projektować dla zaspokojenia wymagań pojedynczego użytkownika, czy wielu użytkowników? 11. Łatwość instalacji Jak trudna jest konwersja danych z poprzedniego systemy i jego instalacja? 12. Łatwość obsługi Jak sprawne i/lub zautomatyzowane są procedury uruchomieniowe, tworzenia kopii zapasowych oraz odzyskiwania informacji? 13. Wielokrotna lokalizacja Czy aplikację należy projektować w celu jej instalacji w wielu miejscach dla wielu organizacji? 14. Łatwość wprowadzania zmian Czy aplikację należy projektować tak, aby łatwe było wprowadzanie zmian? źródło: [3] 10

Przykładowo dla projektu ekspert może oszacować wpływ poszczególnych czynników w następujący sposób: Tabela 12 Numer kategorii Stopień wpływu oszacowany przez eksperta 1. 0 2. 0 3. 3 4. 0 5. 1 6. 5 7. 4 8. 5 9. 0 10. 0 11. 0 12. 0 13. 0 14. 3 SUMA: 21 Czynnik korygujący oblicza się ze wzoru: VAF = 0,65 + (0,01 * ΣCi), gdzie Ci jest oszacowaniem wpływu dla poszczególnych kategorii. W naszym przykładzie: VAF = 0,65 + 0,21 = 0,86 9 Całkowita liczba punktów funkcyjnych Całkowita liczba punktów funkcyjnych to iloraz nieostatecznych punktów funkcyjnych oraz współczynnika korygującego. PF = VAF*NPF W naszym przykładzie: PF = 0,86 * 91 = 78 10 Przeliczanie punktów funkcyjnych na inne jednostki Na podstawie zmierzonych za pomocą punktów funkcyjnych projektów, twórcy metody opracowali tabelę języków, według której można wstępnie określić liczbę linii kod dla projektu. Jednak jak każdą wartość statystyczną, także tą należy traktować z dużą dozą ostrożności, gdyż linia kodu jest wartością trudną do określenia, wynika zarówno z przyjętej definicji, a w ramach przyjętej definicji od stylu i umiejętności programowania. Według szacunków, dla podanej tabeli (tabela 13), dla niektórych języków błędy oszacowania wahają się w granicach 30%, a dla innych w granicach 50%. 11

Tabela 13 Język programowania Poziom języka Średnia liczba LKZ na 1 PF Access 8,5 38 C 2,5 128 C++ Turbo 6,0 53 Java 6,0 53 Oracle 8,0 40 SQL 25,0 13 Pascal 3,5 91 źródło: [2] Dla danego poziomu języka programowania istnieje jednocześnie tabela (tabela 14) osobomiesięcy potrzebnych do zaimplementowania jednego punktu funkcyjnego. Jednak, podobnie jak dla poprzednich statystycznych wartości, także tutaj rzeczywisty czas implementacji systemu może odbiegać daleko od szacunków. Tabela 14 Poziom języka Średnia produktywność na osobomiesiąc (w PF) 1-3 5-10 4-8 10-20 9-15 16-23 16-23 15-30 24-55 30-50 powyżej 55 40-100 źródło: [2] Dla mierzonego projektu i przykładowych języków programowania szacowana liczba linii kodu oraz nakład pracy w osobomiesiącach przedstawia się następująco: Tabela 15 język poziom języka LKZ/PF linie kodu PF/MM Osobomiesiące c++ 6 53 78*53=4134 15 78/15=5,2 html 22 15 78*15=1170 30 78/30=2,6 Pascal 3,5 91 78*91=7098 10 78/10=7,8 Ze względu na możliwości błędnych oszacowań liczby linii kodu i nakładu pracy za pomocą powyższych tabel, zaleca się tworzenie historii projektów wykonywanych przez daną firmę, co pozwala na właściwsze ocenienie kosztów wykonania jednego punktu funkcyjnego. 11 Zalety punktów funkcyjnych Podstawową zaletą jest stosowanie jednostek umownych a nie jednostek programowych. Wielkość SI uzyskana w wyniku obliczeń MPF odzwierciedla funkcjonalność systemu, czyli element, który w większości przypadków najbardziej decyduje o wielkości SI. Metoda ta najlepiej sprawdza się podczas stosowania dla systemów bazodanowych, a ocenia się że 70% wszystkich wykonywanych systemów na świecie to właśnie takie systemy. Metoda ta umożliwia oszacowanie złożoności systemu już we wczesnych fazach projektowania, ponieważ już wtedy określa się funkcje systemu. Jeżeli dokładnie zostanie wykonany etap analizy, szczegółowo zostaną opisane przypadki użycia, wówczas projektant ma podstawy by z dużą dokładnością obliczyć wielość zadania, a w związku z tym określić czas i koszt realizacji. 12

Trzecią zaletą wynikającą z dokonywania obliczeń na podstawie funkcjonalności jest możliwość zaangażowania klienta w proces projektowania systemu. Jest to bardzo ważne z dwóch powodów. Po pierwsze klient jest współodpowiedzialny za podjęcie niektórych decyzji dotyczących realizacji systemu, posiada lepsze rozeznanie w problemach związanych z wykonaniem poszczególnych funkcji SI. Po drugie dochodzi do lepszego porozumienia pomiędzy klientem a firmą realizującą projekt, w związku z czym zwiększają się szanse na to, że klient otrzyma to, co naprawdę potrzebował. Obliczanie liczby punktów funkcyjnych nie wiąże się z określeniem środowiska implementacji. Jest to metoda niezależna od stosowanych technologii. Zwiększa to obszar stosowalności tej metody, ale co ważniejsze umożliwia porównywanie projektów i czasów ich realizacji wykonanych w różnych technologiach. Dodatkowo, jeżeli szacowanie wykonanie przy pomocy innej metody, to bardzo często można wynik sprowadzić do jednostek PF i wówczas już wg nich wykonywać porównanie. Punkty funkcyjne może wykorzystać nie tylko do szacowania wielkości projektów, wykonywania porównań z innymi projektami, ale można także użyć do określania produktywności zespołu projektowego. W odróżnieniu od metod opierających się na jednostkach programowych, jest to produktywność zgodna z definicją ekonomiczną. Jak już wspomniano w punkcie Schemat liczenia punktów funkcyjnych metoda ta może być wykorzystana zarówno do szacowania wielkości SI dopiero powstającego jak i już istniejącego. Jest to duża zaleta, gdyż, jeżeli w przeszłości wykonano jakiś projekt w terminie X, a obecnie firma ma do wykonania podobny projekt, to poprzez obliczenie punktów funkcyjnych dla poprzedniego projektu można wówczas poprzez analogię oszacować bieżący projekt. Firma zyskuje dodatkową informację, na temat jak szybko jest w stanie wykonań określoną liczbę punktów funkcyjnych. 12 Wady punktów funkcyjnych Metoda punktów funkcyjnych obok wielu zalet spotyka się z liczną krytyką. Podstawowym zarzutem jest trudność stosowania i brak obiektywności. Są to powiązane ze sobą aspekty, gdyż projektant musi zdecydować przy liczeniu współczynnika korekcji jak ważne są poszczególne elementy systemu i dobrać odpowiednią ocenę. Musi także poprawnie określić zbiory danych oraz transakcje. Nawet jeżeli projektant X konsekwentnie we wszystkich swoich projektach będzie stosował swój sposób oceny, to prawdopodobnie projektant Y z innego zespołu projektowego będzie to robić inaczej. Wówczas porównanie ich projektów może nie do końca wyjść bezbłędnie. Dlatego, aby umiejętnie skorzystać z metody PF, należy posiadać duże doświadczenie, wiedzę i wyczucie. IFPUG prowadzi specjalistyczne szkolenia w tym zakresie, jednak są one bardzo kosztowne i wiele firm nie stać na wykształcenie swoich pracowników w tym zakresie. Innym, dość poważnym, zarzutem jest brak dostatecznego odzwierciedlenia złożoności wewnętrznej systemu. Metoda ta nie bierze pod uwagę złożoności implementowanych algorytmów, stosowania wyszukanych struktur danych. Dlatego nie nadaje się do stosowania w zastosowaniach naukowych, w których ten element bardzo często jest najważniejszy. Projektant co prawda wśród 14 pytań zadawanych podczas obliczania współczynnika korekcji uwzględnia złożoność wewnętrzną, jednak udział jednego pytania jest znikomy na ostateczną liczbę punktów funkcyjnych. Metoda ta nie powinna być też stosowana dla SI, w których użytkownik może sam definiować nowe własne polecenia. Najlepiej sprawdza się w systemach, w których użytkownik ma z góry określoną funkcjonalność i tylko wykonuje operacje na danych. Dlatego nie używa się tej metody dla szacowania takich systemów jak systemy operacyjne. Także dla systemów czasu rzeczywistego nie stosuje się tej metody. Metoda ta nie uwzględnia także innych działań związanych z wytworzeniem systemu takich jak konieczność zapewnienia bezpieczeństwa danych, potrzeba przeszkolenia użytkownika, stworzenie dokumentacji, czy konieczność takiej implementacji, aby tworzony 13

system współdziałał z innym systemem. Są to wszystko działania zdecydowanie wpływające na wydłużenie czasu wytworzenie SI oraz podnoszące jego koszt. 13 Warianty metody punktów funkcyjnych Z powodu licznych wad wymienionych w poprzednim punkcie powstało wiele odmian metody punktów funkcyjnych. Uwzględniają one specyficzne cechy niektórych typów systemów i dlatego lepiej się nadają do szacowania. W tabeli 16 zebrano ich krótkie zestawienie: Tabela 16 NAZWA UWAGI Metoda PF A. Albrechta i IFPUG głównie do systemów zarządzania, 5 typów funkcji, 14 parametrów wpływu SPQR/20 T.C. Jones systemy informatyczne zarządzania, 5 typów funkcji, 2 parametry wpływu Punkty charakterystyczne (1987) MARK II C.R. Symonsa (1989) systemy operacyjne, SCR, sterujące, telekomunikacyjne, symulacyjne, naukowe, automatyki przemysłowej 6 typów funkcji + algorytmy 3 parametry wpływu współczynniki przeliczeniowe dla typów systemu (np. syst. teleksom. 1,2) głównie w USA, ale już zaprzestano rozwoju systemy informatyczne zarządzania oraz SCR 3 typy funkcji, 19 parametrów wpływu, zmniejszony nacisk na dane 50% rynku Wlk. Bryt. Punkty obiektowe (1994) programowanie zorientowe obiektowo, CASE y, narzędzia GUI obiekty: ekrany, raporty, moduły w językach 3GL, podobieństwo do metody Albrechta 3D Function Points (Boeing Company 1994) Pełne punkty funkcyjne (1997) systemy naukowe, SCR, 3 wymiary: dane, funkcje, sterowanie. pomiar przejść między stanami i transformacji danych tylko Boeing SCR, wspomagające oprogramowanie infrastrukturalne 11 typów funkcji + 2 funkcje typu dane + 4 funkcje transakcyjne, 14 parametrów wpływu COSMIC FFP (2000) łączy IFPUG, MARK II, NESMA, pełne punkty, ISO, nowe idee stosowana dla większości rodzajów systemów informatycznych dopiero rozwijana pozytywna ocena korporacji telekomunikacyjnych źródło: [2] 14 Narzędzia Istnieje kilka narzędzi wspierających obliczanie punktów funkcyjnych dla SI. Dwa z nich są szczególnie interesujące, dlatego zostaną krótko przedstawione. 14

Function Point Workbench australijskiej firmy Charismatek Software Metrics to program dla środowiska MS Windows, posiadający certyfikację IFPUG. Szacowanie wykonuje na podstawie danych wprowadzanych prze użytkownika na temat tworzonego SI. Posiada algorytmy sztucznej inteligencji i jest systemem ekspertowym. Baza wiedzy zbudowana jest z sześciu tysięcy wykonanych projektów. Posiada wiele udogodnień dla użytkownika, dane prezentowane są w postaci graficznej, istnieje możliwość generowania różnorodnych raportów. SPR KnowledgePLAN firmy Software Productivity Research jest innym bardzo dobrym narzędziem wspierającym szacowanie wielkości SI w oparciu o metodę punktów funkcyjnych. Baza projektów w oparciu o którą program działa zawiera osiem tysięcy projektów i jest corocznie uaktualniana. Istnieje możliwość utworzenia własnej bazy wiedzy, dzięki czemu wyniki mogą odzwierciedlać lokalne warunki panujące w firmie. Jest bardzo prosty w obsłudze, przeznaczony dla początkujących projektantów. Praca z programem odbywa się na zasadzie udzielania odpowiedzi na pytania zadawane projektantowi przez program. Atrakcyjną cechą jest dwukierunkowa współpraca z wieloma programami, m.in. z Function Point Workbench, co umożliwia na importowanie i eksportowania danych. Program posiada zaimplementowanych wiele metod szacowania projektów, oprócz PF są to m.in. metody szacowania poprzez analogię. Jego skuteczność może dochodzić nawet do 95%. Stosowanie narzędzi przy liczeniu punktów funkcyjnych wydaje się być koniecznością, zwłaszcza przy dużych SI. Ręczne wykonanie wielu obliczeń na kartce papieru byłoby bardzo kłopotliwe. Jest więc to wymaganie, które można by dopisać do wad metody jest trudna w stosowaniu, a w przypadku stosowania narzędzi wspomagających kosztowna. Jednak dla dużych firm programistycznych nie jest koszt, którego nie warto ponieść, by ochronić się przed olbrzymimi kosztami wynikającymi z konsekwencji nie wykonania projektu na czas, bądź jego przerwaniu. 15 Dalszy rozwój Do tej pory metoda punktów funkcyjnych była silnie rozwijana i przez najbliższe lata nadal tak będzie. Kierunki badań zastosowań MPF skierują się ku systemom opartych na Internecie i Intranecie. Próbuje się też stosować PF do wyrażania złożoności przedsięwzięcia, jakim jest informatyzacja całej firmy bądź jakiejś jednostki. Położony zostanie także nacisk dla zastosowań metody dla systemów typu hurtownie danych, gdzie duża liczba danych uniemożliwia stosowanie MPF w obecnej postaci, ze względu na nieadekwatność sposobu przeliczania punktów. Nadal podejmowane są kroki mające na celu zwiększenie obiektywności wykonywanych ocen. Ma to na celu nie tylko zapewnienie małego błędu uzyskiwanych wyników, ale również uproszczenie stosowania metody. Przyszłość MPF to także badania nad zastosowaniem jej do oceny i minimalizacji ryzyka towarzyszącemu tworzonemu SI. I bardzo ważny cel, jaki sobie stawia IFPUG to popularyzacja metody. Obecnie statystyki wskazują, ze tylko 1% wszystkich projektów informatycznych podlega jakiemukolwiek szacowaniu. 16 Literatura 1. Czarnecka-Chrobot Beata Błędy w zarządzaniu projektem informatycznym skala problemu i aspekty metodologiczne 2. Czarnecka-Chrobot Beata Porównanie metod pomiaru i szacowania projektów informatycznych jednostki programowe a jednostki umowne 3. Czarnecka-Chrobot Beata Metoda punktów funkcyjnych bieżące standardy 4. Czarnecka-Chrobot Beata Narzędzia wspomagające pomiar i szacowanie projektów informatycznych 15

5. Frączkowski Kazimierz Zarządzanie Projektem Informatycznym, s. 24-32 6. Magiera Ewa Szacowanie oprogramowania metodą punktów funkcyjnych 7. http://www.ifpug.org 17 Słownik pojęć COCOMO czynnik korygujący czynnik korygujący Data Element Type DET EI EIF EO EQ External Input External Inquiry External Interface File External Output File Type Referenced FTR ILF Internal Logic File jednostki programowe jednostki umowne LKZ MPF nieostateczna liczba punktów funkcyjnych nieskorygowana liczba punktów funkcyjnych PF punkty funkcyjne skrót od COnstructive COst MOdel jest to metoda oparta na liczbie poleceń zbiór charakterystyk systemu (14 cech), na podstawie których określa się jego złożoność (inaczej współczynnik korekcji) wartość liczbowa uwzględniająca wewnętrzną złożoność systemu nie związaną z jego funkcjonalnością. Określenie współczynnika korekcji polega na podaniu wartości wpływu dla 14 czynników, które mogą wpłynąć na zwiększenie stopnia skomplikowania systemu unikalnie, możliwe do zidentyfikowania przez użytkownika, nierekurencyjne (bez powtórzeń) pole w wewnętrznym pliku logicznym (ILF) lub zewnętrzym pliku interfejsowym (EIF); może być rozumiany jako pojedyncze pole rekordu skrót od Data Element Type skrót od External Input skrót od External Interface File skrót od External Output skrót od External Inquiry patrz: zewnętrzne wejście patrz: zewnętrzne zapytanie patrz: zewnętrzny plik interfejsowy patrz: zewnętrzne wyjście wewnętrzny plik logiczny (ILF) lub zewnętrzny plik interfejsowy (EIF) będący punktem odniesienia dla zewnętrznego wejścia File Type Referenced skrót od Internal Logic File patrz: wewnętrzny plik logiczny linie kodu źródłowego oraz polecenia (instrukcje), stosowane do szacowania wielkości i złożoności projektu informatycznego punkty funkcyjne, punkty charakterystyczne, punkty obiektowe oraz pełne punkty funkcyjne, będące uniwersalnymi jednostkami pomiaru złożoności i wielkość projektu informatycznego skrót od liczba kodu źródłowego skrót od metoda punktów funkcyjnych liczba punktów funkcyjnych dla rozmiaru funkcjonalnego (danych i transakcji), bez uwzględnienia czynnika korygującego patrz: nieostateczna liczba punktów funkcyjnych skrót od: punkty funkcyjne jednostki umowne, stosowane w metodzie punktów funkcyjnych, wyrażające funkcjonalność systemu 16

Record Element Type RET SI SLIM unikalna, rozpoznawalna przez użytkownika podgrupa elementów danych w wewnętrznym pliku logicznym (ILF) lub zewnętrznym pliku interfejsowym (EIF); może być rozumiany jako rekord skrót od Record Element Type system informatyczny skrót od Software Lifecycle Management jest to metoda oparta na LKZ skrót do Value Adjustment Factor VAF Value Adjustment Factor patrz: czynnik korygujący wewnętrzny plik logiczny grupa logicznie powiązanych danych całkowicie rezydujące w mierzonej aplikacji i przez nią zarządzane, reprezentowane przez płaski plik lub relacyjną bazę danych współczynnik korekcji zewnętrzne wejście zewnętrzne wyjście zewnętrzne zapytanie zewnętrzny plik interfejsowy patrz: czynnik korygujący przepływ informacji z zewnątrz do mierzonej aplikacji, modyfikuje jej pliki ILF przepływ informacji od aplikacji poza jej granice (do użytkownika lub innej aplikacji), może modyfikować jej pliki ILF jednoczesny przepływ danych do i z aplikacji, jest to zapytanie do aplikacji pochodzące z zewnątrz, nie może modyfikować jej plików ILF grupa logicznie powiązanych danych całkowicie rezydujących poza mierzoną aplikacją i przez nią zarządzane, reprezentowane przez płaski plik lub relacyjną bazę danych 17