Podręcznik stosowania metody Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa

29/11/2011 28 Załącznik nr 1 do Załącznika nr 4C Podręcznik stosowania metody Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa v1.0

Spis treści Wstęp... 4 Zakres stosowania metody PF IFPUG... 5 Zasady stosowania metody PF IFPUG... 7 Wprowadzenie do punktów funkcyjnych... 7 Wstęp do metody PF IFPUG... 7 Metoda PF IFPUG w ARiMR... 9 Metoda PF IFPUG zasady... 10 Identyfikacja modelu danych IFPUG... 12 Identyfikacja modelu funkcjonalnego IFPUG... 12 Wyliczenie rozmiaru funkcjonalnego elementów modelu IFPUG... 15 Metoda PF IFPUG z rozszerzeniem opracowanym przez organizację NESMA... 15 Wyliczanie zmian modelu danych... 15 Wyliczanie zmian modelu funkcji... 16 Zasady stosowania współczynnika VAF... 17 Proces szacowania rozmiaru oprogramowania / zmiany oprogramowania... 21 Zasady wykorzystania metody PF IFPUG w danym projekcie... Błąd! Nie zdefiniowano zakładki. Zasady tworzenia i utrzymywania modelu artefaktów PF IFPUG... 21 Zasady prezentacji wyników szacowania PF IFPUG w dokumentacji ofertowej... 23 Proces weryfikacji szacowania... 25 Lista kontrola weryfikacji modelu danych IFPUG.... 25 Lista kontrola weryfikacji modelu funkcji IFPUG.... 25 Podział oprogramowania względem granic i współczynniki VAF... 28 System informatyczny - EBS... Błąd! Nie zdefiniowano zakładki. System informatyczny - ZSZiK... 28 System informatyczny - Platforma aplikacyjna... Błąd! Nie zdefiniowano zakładki. System informatyczny - System Informacji zarządczej... Błąd! Nie zdefiniowano zakładki. System informatyczny - OFSA... Błąd! Nie zdefiniowano zakładki. System informatyczny - SI-Agencja... Błąd! Nie zdefiniowano zakładki.

Zasady interpretacji metody PF IFPUG dla specyficznych typów funkcjonalności i zmian... 29 Stosowanie PF IFPUG... 29 Stosowanie PF IFPUG dla złożonych funkcjonalności... 33 Stosowanie PF IFPUG dla funkcjonalności sterowanych procesami... 34 Stosowanie PF IFPUG dla złożonych raportów... 35 Stosowanie PF IFPUG dla złożonego interfejsu użytkownika... 36 Stosowanie PF IFPUG dla złożonych procesów wsadowych... 36 Stosowanie PF IFPUG dla algorytmów... 37

WSTĘP Niniejszy Podręcznik ma na celu opisanie zakresu oraz zasad stosowania metody Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa. Niniejszy Podręcznik definiuje również zasady utrzymywania dokumentacji będącej podstawą do szacowania oraz zasady prezentacji wyników szacowania. Metoda Punktów Funkcyjnych IFPUG (PF IFPUG) jest metodą pomiaru rozmiaru funkcjonalnego oprogramowania z perspektywy wymagao użytkownika. Metoda ta jest utrzymywana i rozwijana przez organizację International Function Point Users Group (www.infpug.org). Zasady wykorzystania metody PF IFPUG w ARiMR są opisane w dokumencie Function Point Counting Practices Manual w wersji 4.3 publikowanym przez organizację IFPUG między innymi w języku angielskim. Dodatkowym dokumentem rozszerzającym zasady opisane w w/w dokumencie jest publikacja organizacji NESMA (Netherlands Software Metrics Association) Function Point Analysis for Software Enhancement (www.nesma.org, dokument dostępny w języku angielskim). Dodatkowe zasady opisane w dokumencie organizacji NESMA mają zastosowanie dla szacowania zmian oprogramowania. W/w dokumenty są dokumentami bazowymi dla niniejszego Podręcznika, co oznacza, iż w przypadku, gdy niniejszy Podręcznik nie zawiera jakiejś informacji odnośnie zastosowania metody PF IFPUG w danej sytuacji to należy odwoład się do tych dokumentów. Niniejszy Podręcznik nie jest dokumentem zastępującym w/w dokumenty oznacza to, iż osoby dokonujące szacowania rozmiaru oprogramowania zgodnie z zasadami metody PF IFPUG powinny byd również z nimi zapoznane. Załączniki do niniejszego dokumentu: przykład projektu Enterpise Architect "ARiMR_IFPUG.eap", szablon dokumentu "ARiMR_IFPUG_Wycena Zmiany". Źródła wykorzystane w opracowaniu: www.ifpug.org - Podręcznik Metody w wersji 4.3 i inne materiały dostępne dla członków organizacji, www.nesma.org materiały publiczne, M. A. Parthasarathy, Practical Software Estimation, Addison-Wesley & Infosys 2007, ISBN 0-321-43910-4 M. Mundschuh, C. Dekkers, The IT Measurement Compendium, Springer 2008, e-isbn 978-3-540-68188-5 Capers Jones, Estimating Software Costs, Bringing Realism To Estimating, Second Edition, The McGraw Hill Companies 2007, ISBN 13:978-0-07-148300-1, ISBN 10: 0-07-148300-4 S. McConnell, Software Estimation: Demystifying the Black Art, Microsoftpress 2006, ISBN-13 978-0735605350

ZAKRES STOSOWANIA METODY PF IFPUG Rozmiar funkcjonalny oprogramowania jest definiowany, jako rozmiar oprogramowania opracowanego w wyniku implementacji konkretnego zbioru wymagao funkcjonalnych użytkownika. Wymagania funkcjonalne użytkownika są podzbiorem wymagao użytkownika na dane oprogramowanie. Wymagania użytkownika dla oprogramowania są też podzbiorem wymagao dla projektu / modyfikacji w ramach, których to oprogramowanie jest realizowane. Oznacza to, iż nie wszystkie prace związane z realizacją oprogramowania, projektu / modyfikacji, mogą byd oszacowane metodą PF IFPUG. Uwzględniając powyższe, metoda PF IFPUG, pozwala oszacowad rozmiar funkcjonalny oprogramowania lub rozmiar funkcjonalny zmiany oprogramowania przy założeniu, iż definicja funkcjonalności nowej lub zmienianej wynika z wymagao funkcjonalnych użytkownika. Rozmiar funkcjonalny oprogramowania jest niezależny od wymagao niefunkcjonalnych, w tym od technologii, architektury i sposobu realizacji danego oprogramowania. Oznacza to również, iż wszystkie zadania projektu / modyfikacji mające na celu wprowadzenie / zmianę technologii, architektury czy sposobu dostarczania oprogramowania nie podlegają szacowaniu metodą PF IFPUG. Jednakże standardowe prace wynikające z uwzględniania wymagao niefunkcjonalnych w trakcie realizacji zmian funkcjonalnych traktuje się jako prace wliczone w cenę punktu funkcyjnego: Migracji danych niezbędnej dla uruchomienia nowej / zmodyfikowanej funkcjonalności, Utworzenia lub aktualizacji danych w bazie danych na potrzeby działania nowej / zmodyfikowanej funkcjonalności, Utworzenia lub aktualizacji parametrów definiujących działanie aplikacji (w kontekście technologicznym jak i biznesowym) niezbędnych dla działania nowej / zmodyfikowanej funkcjonalności, Utworzenia lub aktualizacji słowników wspierających działanie aplikacji (w kontekście technologicznym jak i biznesowym) niezbędnych dla działania nowej / zmodyfikowanej funkcjonalności, Optymalizacji oprogramowania / struktury bazy danych w zakresie obowiązującego SLA, Prac konfiguracyjnych dotyczących elementów architektury, infrastruktury i oprogramowania standardowego niezbędnych dla uruchomienia nowej / zmodyfikowanej funkcjonalności, Zmiana wyglądu, koloru, układu kontrolek i danych na interfejsie użytkownika wynikające z nowych / zmodyfikowanych funkcjonalności. Zadania, których głównym celem jest realizacja prac niefunkcjonalnych są szacowane w oparciu o ekspercką wycenę roboczogodzin. Zadania te dotyczą w szczególności: Wprowadzenia lub zmiany elementów technologii, Wprowadzenia lub zmiany elementów architektury, Wprowadzenia lub zmiany elementów infrastruktury Migracji danych o dużej skali wynikającej ze zmian infrastruktury, Optymalizacji oprogramowania / struktury bazy danych w ramach nowego SLA, Prac konfiguracyjnych dotyczących elementów architektury i oprogramowania standardowego wynikających ze zmian infrastrukturalnych oraz architektonicznych, Wygenerowania niestandardowych raportów ad-hoc w oparciu o istniejące w oprogramowaniu dane. Powyższe wykluczenie, nie oznacza jednakże, iż wyżej wymienione prace związane z opracowaniem oprogramowania nie są w założeniu umowy pomiędzy ARiMR a Wykonawcą wliczone w cenę punktu funkcyjnego jest to jednak zagadnienie odrębne od samego wyznaczania rozmiaru funkcjonalnego oprogramowania lub zmiany oprogramowania.

Przykład: W ramach modyfikacji oprogramowania zdefiniowano trzy wymagania funkcjonalne: (1) graficzny status on-line liczby decyzji o przyznaniu płatności w poszczególnych województwach ma prezentowad również liczbę odrzuconych decyzji, (2) dotychczasowa prezentacja liczby przyznanych decyzji ma byd prezentowana na zielono a odrzuconych na czerwono, (3) czas odświeżenia graficznego statusu ma byd obniżony do 2 sekund. W tym przykładzie jedynie wymaganie (1) ma wpływ na rozmiar funkcjonalny zmiany wyliczalny metodą PF IFPUG, realizacja wymagania (2) z założenia, może byd wliczona w cenę jednego punktu funkcyjnego rozmiaru funkcjonalnego, a wymaganie (3) wymaga osobnego oszacowania w innych jednostkach rozliczeniowych np. roboczogodzinach. W ramach funkcjonalności, dla której ma zastosowanie metoda IFPUG zakłada się, iż koszt punktu funkcyjnego określony w umowie pomiędzy ARiMR i Wykonawcą zawiera w sobie koszt całego cyklu wytwórczego związanego z wytworzeniem oprogramowania o złożoności jednego punktu funkcyjnego.

ZASADY STOSOWANIA METODY PF IFPUG WPROWADZENIE DO PUNKTÓW FUNKCYJNYCH Metody punktów funkcyjnych to zbiory reguł, których zastosowanie do danego zbioru wymagao funkcjonalnych użytkownika, pozwala wyznaczyd funkcjonalny rozmiar oprogramowania realizującego te wymagania. Oznacza to iż na wejściu danej metody jest podawany zbiór wymagao a na wyjściu oczekiwana jest liczba punktów funkcyjnych wyznaczona dla tego zbioru wymagao. Punkt funkcyjny jest abstrakcyjną miarą, definiowaną, jako jednostka funkcjonalności biznesowej dostarczana przez mierzone oprogramowanie. Oznacza to, iż oprogramowanie o rozmiarze 100 punktów funkcyjnych dostarcza użytkownikowi 100 jednostkowych funkcjonalności biznesowych. Zbiór wymagao funkcjonalnych Metoda PF Liczba PF Wyznaczona liczba punktów funkcyjnych dla danego zbioru wymagao może byd określona mianem nieskorygowanych punktów funkcyjnych lub skorygowanych punktów funkcyjnych. Nieskorygowane punkty funkcyjne to wartośd wynikająca wprost z zastosowania reguł metody dla danego zbioru wymagao funkcjonalnych. Skorygowane punkty funkcyjne uwzględniają dodatkowo reguły określające wpływ wymagao niefunkcjonalnych, środowiska projektu i procesu produkcji - jest to zazwyczaj odpowiednio przekształcona liczba nieskorygowanych punktów funkcyjnych. W dalszej części Podręcznika - o ile nie będzie to określone inaczej - przez określenie "liczba punktów funkcyjnych" należy rozumied nieskorygowaną liczbę punktów funkcyjnych. W przypadku zmian istniejącego oprogramowania, liczba punktów funkcyjnych może dotyczyd samej zmiany jak i rozmiaru oprogramowania po zmianie. W przypadku rozmiaru zmiany, liczba punktów funkcyjnych zmiany wynika wprost z wymagao definiujących zmianę. W przypadku rozmiaru oprogramowania po zmianie - liczba punktów funkcyjnych oprogramowania może pozostad taka sama jak przed zmianą, może się zmniejszyd lub zwiększyd. Przykład: W przypadku oprogramowania A o rozmiarze 100 PF zdefiniowano zmianę o wprowadzająca nowe funkcje o rozmiarze 25 PF. Rozmiar zmiany to 25 PF a rozmiar oprogramowania A po zmianie to 125 PF. W przypadku oprogramowania B o rozmiarze 200 PF zdefiniowano zmianę modyfikującą istniejące funkcje - bez wprowadzania nowych. Rozmiar zmiany określono na 40 PF. Rozmiar oprogramowania B po zmianie to w dalszym ciągu 200 PF. WSTĘP DO METODY PF IFPUG Metoda Punktów Funkcyjnych IFPUG zakłada, iż rozmiar oprogramowania (w postaci liczby nieskorygowanych punktów funkcyjnych) może byd wyznaczony w oparciu o analizę pięciu kluczowych parametrów: funkcji wejścia i wyjścia, zapytao oraz wewnętrznego modelu danych i interfejsów do systemów zewnętrznych. Wybór tych elementów przez twórców metody był podyktowany tym, iż są to parametry znane użytkownikowi funkcjonalnemu oprogramowania (niejako definiują one funkcjonalnośd oprogramowania z jego punktu widzenia). Użyte powyżej pojęcie użytkownik funkcjonalny oznacza zarówno użytkownika w postaci osoby korzystającej z oprogramowania jak i użytkownika w postaci innego oprogramowania / systemu / urządzenia.

Jako naczelną zasadę dla stosowania metody PF IFPUG należy podkreślid fakt, iż w/w pięd parametrów oprogramowania musi wynikad wprost z wymagao funkcjonalnych użytkownika oraz musi reprezentowad funkcjonalnośd oprogramowania (rozumianą tu, jako funkcje i dane) dostępną dla użytkownika funkcjonalnego bez odnoszenia się do sposobu implementacji (udostępniania) tej funkcjonalności. Powyższy rysunek przedstawia dwie aplikacje A i B. Aplikacja A udostępnia funkcje wyjścia / wejścia / zapytao użytkownikowi, posiada swoją własną logikę przetwarzania danych oraz wewnętrzne pliki dla przechowywania danych. Aplikacja ta korzysta również z Aplikacji B poprzez określony interfejs wymiany danych. Z punktu widzenia metody PF IFPUG logika biznesowa (logika przetwarzania) jest elementem aproksymowanym przez złożonośd funkcji wejścia / wyjścia / zapytao oraz wewnętrznego modelu danych. Nie podlega ona bezpośredniemu szacowaniu. To ograniczenie oznacza, iż jeśli złożonośd tej logiki wykracza poza zakres stosowalności metody to należy ją dodatkowo oszacowad. W szczególności poza zakres stosowalności metody wykraczają algorytmy związane z przetwarzaniem danych multimedialnych, prognoz pogody, obliczeo naukowych itp. W szczególnych przypadkach niektóre algorytmy stosowane w aplikacjach typowo biznesowych również mogą wykraczad poza zakres stosowalności metody. Zbiór w/w parametrów oprogramowania, czyli zbiór funkcji wejścia, wyjścia, zapytao, modelu danych wewnętrznych i zewnętrznych jest w dalszej części określany, jako model IFPUG, czyli sposób odzwierciedlenia wymagao funkcjonalnych użytkownika w postaci artefaktów definiowanych przez reguły metody PF IFPUG. Metoda PF IFPUG wprowadza również pojęcie granicy oprogramowania. Granica oprogramowania wyznacza zakres szacowanego oprogramowania jak i również służy do dookreślenia funkcji wejścia / wyjścia / zapytao, jako funkcji przenoszących dane z zewnątrz do wewnątrz granicy lub z wewnątrz na zewnątrz granicy. Wewnętrzny model danych jest również traktowany, jako mechanizm utrwalania danych wewnątrz granicy oprogramowania, podczas gdy interfejsy zewnętrzne są modelowane, jako zbiory danych dostępne dla oprogramowania poza jego granicami. Granica danego oprogramowania powinna byd zgodnie z założeniami metody wyznaczona w oparciu o perspektywę jego użytkownika a precyzyjniej jego potrzeb. Oznacza to, iż oprogramowanie objęte granicą powinno realizowad spójne określone cele użytkownika, powinno zawierad logicznie powiązane funkcje i dane zgodnie z potrzebami użytkownika. W żadnym wypadku granica ta nie powinna byd, zatem wyznacza przez ograniczenia technologiczne, infrastrukturalne czy architektoniczne. W przypadku szacowania zmian oprogramowania należy mied na uwadze fakt, iż granica oprogramowania jest czymś niezależnym od zmiany powinna byd zdefiniowana dla danego zmienianego oprogramowania, jako logicznej całości a nie, dla danego zmienianego fragmentu.

Ostatnim elementem metody PF IFPUG jest możliwośd skorygowania wyznaczonego rozmiaru oprogramowania za pomocą współczynnika VAF (Value Adjustment Factor). Współczynnik ten jest wyznaczany w oparciu o 14 cech oprogramowania mających odzwierciedlad wymagania niefunkcjonalne. Jest to element opcjonalny metody PF IFPUG. METODA PF IFPUG W ARIMR Procedura zastosowania metody PF IFPUG jest następująca: 1) Pozyskanie dostępnej dokumentacji dla szacowanego oprogramowania 2) Określenie celu i zakresu szacowania celem zdefiniowania granicy oprogramowania 3) Określenie współczynnika VAF w oparciu o przyjętą architekturę i wymagania niefunkcjonalne 4) Określenie w oparciu o dostępną dokumentację zbioru wymagao funkcjonalnych użytkownika 5) Zidentyfikowanie i oszacowanie funkcji wejścia / wyjścia / zapytao oraz modeli danych wewnętrznych i zewnętrznych celem wyliczenia liczby nieskorygowanych punktów funkcyjnych Z punktu widzenia szacowania projektów i modyfikacji w ARiMR kroki te są określane następująco: Ad1) Przez dostępną dokumentację rozumie się istniejąca dokumentację w postaci Analitycznych Opisów Produktów, Analitycznych Opisów Modyfikacji oraz dostępną dla danego projektu / modyfikacji dokumentację definiująca zakres projektu / modyfikacji. Ad2) Granice szacowanego oprogramowania opracowane są przez ARiMR i są zawarte w niniejszym Podręczniku. Ad3) Współczynniki VAF dla oprogramowania wytwarzanego / modyfikowanego w ramach projektu są ustalane przez ARiMR i są zawarte w niniejszym Podręczniku. Ad4) Wymagania funkcjonalne użytkownika, z których wynika identyfikacja elementów modelu IFPUG są łącznym zbiorem zawierającym: wymagao funkcjonalnych użytkownika, które służyły wcześniej, jako podstawa dla opracowania AOM/AOP dla istniejącego oprogramowania, wymagao funkcjonalnych użytkownika określających danych projekt / modyfikację. Ad5) Zasady identyfikacji oraz szacowania elementów modelu IFPUG to zasady oryginalnej metody wraz z interpretacjami jej stosowania zawartymi w niniejszym dokumencie. Należy podkreślid, iż wspomniana wyżej zasada dla kroku 4 procedury szacowania oznacza, iż zbiór wymagao funkcjonalnych dla danego oprogramowania jest nadrzędny zarówno dla modelu IFPUG jak i dla modelu AOM/AOP. Oznacza to również, iż nie istnieje bezpośrednie powiązanie elementów modelu IFPUG oraz modelu AOM/AOP. Łącznikiem tych dwóch modeli są wymagania gdyż zarówno elementy modelu IFPUG jak i modelu AOM/AOP realizują konkretne wymagania ze zbioru wymagao funkcjonalnych użytkownika. Wymagania funkcjonalne użytkownika Istniejące oprogramowanie Projekt / modyfikacja

Model AOM/AOP Model IFPUG Powyższe oznacza, iż elementów modelu IFPUG nie należy wyprowadzad z istniejących elementów modelu AOM/AOP, ale wprost z ze zbioru wymaganiach funkcjonalnych użytkownika. Odstępstwem od powyższej reguły może byd sytuacja, gdy dla danego projektu istniejące oprogramowanie jest opisane wyłącznie poprzez model AOM/AOP. W takiej sytuacji, w ramach każdej modyfikacji oprogramowania w tym projekcie, wymagane jest odtworzenie nadrzędnego zbioru wymagao funkcjonalnych użytkownika. Z punktu widzenia szacowania, zbiór wymagao funkcjonalnych użytkownika powinien zawierad wymagania na takim poziomie szczegółowości by było możliwe zidentyfikowanie elementów modelu, IFPUG czyli w szczególności, ale nie tylko: 1) Wymagania powinny opisywad konkretne cele, jakie użytkownik chce osiągnąd przy pomocy oprogramowania aczkolwiek nie jest niezbędne wskazywanie sekwencji kroków interakcji z oprogramowaniem, jakie muszą byd przeprowadzone oraz reguł przetwarzania danych w tych krokach. 2) Wymagania powinny określad zakres danych, jakie ma przechowywad oprogramowanie aczkolwiek nie jest niezbędne wskazywanie typów, formatów, zasad walidacji i wyliczeo tych danych. 3) Wymagania powinny określad zakres danych wprowadzanych do systemu oraz wyprowadzanych do systemu przy realizacji określonych celów użytkownika, przy czym nie jest konieczne wskazywanie typów, formatów, zasad walidacji i wyliczeo tych danych. Powyższy minimalny zakres wymagao funkcjonalnych użytkownika jest zakresem na potrzeby szacowania metodą IFPUG. Nie wyklucza to jednak oczywiście innych potrzeb, dla których te wymagania powinny byd rozszerzone o dodatkowe elementy. Powyższy minimalny zakres wymagao funkcjonalnych użytkownika można określid również, jako taki opis wymagao, który zawiera minimum: zidentyfikowane przypadki użycia celu użytkownika, zidentyfikowane klasy modelu dziedziny (lub zbiór klas reprezentujących ten model), zidentyfikowane atrybuty klasy modelu dziedziny. Pojęcie zidentyfikowane oznacza tu, iż te elementy są nazwane aczkolwiek nie jest opisany sposób ich realizacji, wyliczania, formatu i zasad walidacji. METODA PF IFPUG ZASADY Metoda IFPUG definiuje następujące artefakty, jako elementy modelu IFPUG: Elementarny proces (EP Elementary Process) minimalna funkcja oprogramowania mająca znaczenie dla użytkownika, mogąca byd wykonana niezależnie i której realizacja pozostawia oprogramowanie w stanie stabilnym. Funkcja wejścia (EI External Input) elementarny proces przetwarzający dane przychodzące z zewnątrz granicy oprogramowania do jej wnętrza.

Funkcja wyjścia (EO External Output) - elementarny proces przetwarzający i wysyłający dane z wewnątrz granicy oprogramowania na jej zewnątrz. Funkcja zapytania (EQ External Inquiry) elementarny proces wysyłający dane z wewnątrz granicy oprogramowania na jej zewnątrz. Plik danych (FTR File Type Referenced) rozpoznawalny przez użytkownika zbiór logicznie powiązanych danych odczytywany lub zarządzany przez elementarne procesy. Wewnętrzny plik danych (ILF Internal Logical File) - wewnętrzny plik danych przechowywujący dane wewnątrz granicy oprogramowania. Zewnętrzny plik danych (EIF External Interface File) - zewnętrzny plik danych, przechowywane poza granicami szacowanego oprogramowania, do którego odwołują się elementarne procesy tego oprogramowania. Przykład: W przypadku, gdy oprogramowanie umożliwia rejestrowanie dokumentów kancelaryjnych to funkcja rejestracji nowego dokumentu będzie elementarnym procesem typu EI, funkcja prezentująca raport z zarejestrowanych dokumentów będzie elementarnym procesem typu EQ, funkcja prezentująca statystykę tempa rejestracji dokumentów będzie elementarnym procesem typu EO gdyż wylicza dodatkowe dane, nieprzechowywane w aplikacji; zbiór danych przechowywujący dane zarejestrowanych dokumentów będzie plikiem danych typu ILF a zbiór danych przechowywujący dane klientów organizacji (zarządzanym w ramach innego oprogramowania) będzie plikiem danych typu EIF wykorzystywanym celem identyfikacji nadawcy dokumentu. W celu wyznaczenia rozmiaru funkcjonalnego oprogramowania konieczne jest określenie dla definiującego to oprogramowanie zbioru wymagao funkcjonalnych wszystkich wyżej zdefiniowanych elementów modelu IFPUG tj. elementarnych procesów EI, EO i EQ oraz plików danych ILF i EIF. W celu wyznaczenia rozmiaru funkcjonalnego zmiany oprogramowania konieczne jest zidentyfikowanie - w istniejącym modelu IFPUG oprogramowania przed zmianą - tych elementów modelu IFPUG, które ulegną zmianie.

IDENTYFIKACJA MODELU DANYCH IFPUG Celem określenia plików danych, należy zidentyfikowad grupy logicznie powiązanych danych rozpoznawalnych przez użytkownika, jako realizujących jego wymagania. Dane od siebie zależne należy łączyd w niezależne pliki danych. Dane zależne to dane powiązane ze sobą relacją kompozycji, czyli: dane zależne istnieją wyłączenie, jeśli istnieją dane nadrzędne, usunięcie danych nadrzędnych powoduje usunięcie danych zależnych. Nie należy, jako plików danych traktowad: 1) Metadanych mających znaczenie wyłącznie dla technicznego opisu danych biznesowych. 2) Pojedynczo występujących obiektów posiadających małe ilości rzadko zmiennych atrybutów. 3) Danych statycznych rzadko zmienianych. 4) Domyślnych danych dla obiektów tworzonych przez aplikację. 5) Enumeracji dla atrybutów innych danych. 6) Definicji zakresów poprawności i formatów atrybutów dla innych danych. 7) Danych złączeniowych zawierających jedynie klucze obce czy indeksy definiujące relacje pomiędzy innymi danymi. Przykład: Istniejący na modelu dziedziny związek wiele do wielu pomiędzy klasą A i klasą B wymaga utworzenia w modelu relacyjnym tablicy złączeniowej T. Z punktu widzenia modelu danych IFPUG istnieją jednak dwa pliki danych: A oraz B. Tablica T jest daną techniczną i nie jest uwzględniania w szacowaniu aczkolwiek atrybuty wskazujące związek pomiędzy klasami A i B są elementami każdego z tych plików danych. Zidentyfikowane pliki danych należy zaklasyfikowad, jako pliki ILF, jeśli są to dane wewnątrz granic szacowanego oprogramowania lub jako pliki EIF, jeśli są to dane referencyjne poza granicami szacowanego oprogramowania. Przykład: Aplikacja do rejestracji dokumentów wpływających do organizacji opcjonalnie korzysta z systemu CRM celem identyfikacji nadawców. Dane podmiotów nadawców z systemu CRM, z punktu widzenia szacowania aplikacji do rejestracji dokumentów, są modelowane, jako plik danych EIF. Dla każdego pliku danych należy określid jego unikalne atrybuty (DET Data Element Type). Atrybut pliku danych to każdy rozpoznawalny przez użytkownika, unikalny atrybut pliku danych, który jest zarządzany, zapisywany, aktualizowany lub odczytywany w ramach elementarnych procesów szacowanego oprogramowania. Atrybutami są również atrybuty związków danego pliku danych z innymi plików danych, przy czym w zależności od nawigowalności tego związku, atrybut związku jest określany w jednym lub w obu powiązanych plikach danych. Mając określone atrybuty poszczególnych plików danych należy zidentyfikowad w ramach plików danych rekordy (RET Record Element Type). Rekord grupuje w ramach pliku danych atrybuty które występują w liczności innej niż 1:1 do pliku danych (inaczej mówiąc są one w relacji kompozycji). Domyślnie każdy plik danych ma jeden rekord. Przykład: Zbiór danych faktura to dane faktury plus lista pozycji faktury. Pozycja faktury jest elementem pliku danych Faktura i jest modelowana, jako rekord w tym pliku danych. Pozycja faktury nie istnieje bez faktury, usunięcie faktury usuwa wszystkie powiązanie z nią pozycje faktury. IDENTYFIKACJA MODELU FUNKCJONALNEGO IFPUG

Celem określenia elementarnych procesów należy zidentyfikowad minimalne niezależne funkcje oprogramowania mające znaczenie dla użytkownika oraz które są transakcjami tj. pozostawiają oprogramowanie w stabilnym stanie. Zidentyfikowane minimalne niezależne funkcje oprogramowania należy powiązad w postaci unikalnych elementarnych procesów, jeśli: wymagają tych samych atrybutów, wymagają tych samych plików danych, wymagają tej samej logiki przetwarzania danych. Przy czym w ramach jednego elementarnego procesu łączy się różne minimalne funkcje, które są tylko wariantami realizacji określonego celu użytkownika ze względu na warianty logiki przetwarzania lub warianty wykorzystania atrybutów lub plików danych. Przykład: System umożliwia rejestracje danych podmiotów, przy czym rejestrowane są zarówno podmioty, jako osoby fizyczne jak i prawne. Elementarny proces EI Rejestracja podmiotu obsługuje oba te przypadki a zbiór atrybutów tego procesu jest łącznym zbiorem wszystkich atrybutów osób prawnych i fizycznych. Zidentyfikowane elementarne procesy należy sklasyfikowad przypisując im jeden z trzech określonych przez metodę typów tj. EI, EO lub EQ. Elementarny proces jest procesem typu EI, jeśli: 1) Zawiera logikę przetwarzania walidującą dane wprowadzane w ramach tego procesu do systemu, lub 2) Jego podstawowym zadaniem jest zarządzanie (dodawanie, usuwanie, modyfikacja) jednym lub więcej plikami danych w ramach procesu, lub 3) Jego podstawowym zdaniem jest modyfikacja zachowania oprogramowania po zakooczeniu realizacji procesu (poprzez modyfikację określonych plików danych). Przykład: Funkcja rejestracji dokumentu kancelaryjnego jest procesem EI gdyż umożliwia wprowadzenie do oprogramowania danych rejestrowanego dokumentu. Elementarny proces jest procesem typu EO, jeśli jego podstawowym zadaniem jest prezentacja danych użytkownikowi z wykorzystaniem przynajmniej jednego ze sposobów przetwarzania danych: 1) Obliczeo matematycznych. 2) Aktualizacji pliku lub plików ILF. 3) Utworzenia prezentowanych danych. 4) Modyfikacja zachowania oprogramowania po zakooczeniu realizacji procesu (poprzez modyfikację określonych plików danych). Przykład: Funkcja utworzenia raportu z zarejestrowanych dokumentów kancelaryjnych jest procesem typu EO gdyż zawiera informacje o liczbie zarejestrowanych dokumentów z podziałem na stanowiska rejestracji. Elementarny proces jest procesem typu EQ, jeśli jego zadaniem jest prezentacja informacji i nie zawiera przetwarzania danych wskazanego dla procesów typu EO. Przykład: Funkcja wyszukiwania dokumentów kancelaryjnych Est procesem typu EQ gdyż prezentuje wyłącznie dane dokumentów zapisane w bazie. Dla każdego zidentyfikowanego i sklasyfikowanego elementarnego procesu należy następnie określid, z jakich plików danych ten proces korzysta (odczyt lub zapis) oraz jakie atrybuty są w ramach procesu wykorzystywane. Jako atrybuty wykorzystywane przez elementarny proces należy traktowad:

unikalne i rozpoznawalnych przez użytkownika atrybuty danych przekracza granicę systemu podczas realizacji procesu, jeden atrybut, jeśli elementarny proces może prezentowad użytkownikowi komunikaty (prosty błędy / potwierdzenia) związane z realizacją procesu niezależnie od liczby tych komunikatów, jeden atrybut na każda akcję, jaka skutkuje uruchomieniem innego elementarnego procesu niezależnie od liczby sposobów na uruchomienie tych akcji. Nie należy traktowad, jako atrybutów elementarnych procesów: opisów na formatach, nagłówków kolumn, nazw pól, znaczników wersji, znaczników typów, znaczników czasowych nie mających znaczenia biznesowego (tj. wpływającego na procesy biznesowe użytkownika), numerowania stron, wierszy, liczb porządkowych w tabelach, elementów nawigacyjnych interfejsu użytkownika, elementów wspomagających wprowadzanie danych na interfejsie użytkownika, atrybutów generowanych w ramach realizacji procesu, ale nie przekraczających granicy oprogramowania, atrybutów odczytywanych z plików danych nieprzekraczających granicy oprogramowania. Przykład: Raport z liczby zarejestrowanych dokumentów kancelaryjnych jest tworzony na zadany dzieo i prezentuje liczbę dokumentów zarejestrowanych w poszczególnych stanowiskach rejestracyjnych. Na raporcie jest też prezentowana wersja formularza raportu oraz godzina wygenerowania. Z punktu widzenia użytkownika te dwa ostatnie parametry są nieistotne - są to parametry techniczne dostawcy oprogramowania kancelaryjnego. Tym samym, jako atrybuty procesu zalicza się atrybut dnia, na jaki jest tworzony raport, liczbę raportów i identyfikacje stanowiska. Dodatkowo mogą byd również zliczone przycisk wykonania raportu na zadane parametry (jako realizacja akcji tego procesu) oraz ew. 1 DET dla komunikatu o błędnych parametrach.

WYLICZENIE ROZMIARU FUNKCJONALNEGO ELEMENTÓW MODELU IFPUG Rozmiar funkcjonalny plików danych jest wypadkową liczby atrybutów i rekordów w danym pliku. Rozmiar funkcjonalny elementarnych procesów jest wypadkową liczby atrybutów procesu i liczby wykorzystywanych plików danych. Dla każdego z typów artefaktów modelu to jest zdefiniowana odpowiednia tabela wyliczeniowa. ILF DET 1-19 DET 20-50 DET > 50 RET 1 LOW (7) LOW (7) AVERAGE (10) RET 2 5 LOW (7) AVERAGE (10) HIGH (15) RET > 5 AVERAGE (10) HIGH (15) HIGH (15) EIF DET 1-19 DET 20-50 DET > 50 RET 1 LOW (5) LOW (5) AVERAGE (7) RET 2 5 LOW (5) AVERAGE (7) HIGH (10) RET > 5 AVERAGE (7) HIGH (10) HIGH (10) EI DET 1 4 DET 5 15 DET > 15 FTR < 2 LOW (3) LOW (3) AVERAGE (4) FTR 2 LOW (3) AVERAGE (4) HIGH (6) FTR > 2 AVERAGE (4) HIGH (6) HIGH (6) EQ DET 1 5 DET 6 19 DET > 19 FTR < 2 LOW (3) LOW (3) AVERAGE (4) FTR 2 LOW (3) AVERAGE (4) HIGH (6) FTR > 2 AVERAGE (4) HIGH (6) HIGH (6) EO DET 1-5 DET 6-19 DET > 19 FTR < 2 LOW (4) LOW (4) AVERAGE (5) FTR 2 3 LOW (4) AVERAGE (5) HIGH (7) FTR > 3 AVERAGE (5) HIGH (7) HIGH (7) Suma rozmiarów funkcjonalnych wszystkich elementów modelu IFPUG jest rozmiarem oprogramowania w punktach funkcyjnych. Przykład: Plik danych ILF o 25 atrybutach i dwóch rekordach ma złożonośd 10 punktów funkcyjnych. Elementarny proces EQ o 3 atrybutach i jednym wykorzystywanym pliku FTR ma złożonośd 3 punkty funkcyjne. METODA PF IFPUG Z ROZSZERZENIEM OPRACOWANYM PRZEZ ORGANIZACJĘ NESMA W przypadku zmiany oprogramowania możliwe są trzy różne rodzaje zmian: dodanie nowej funkcjonalności, usunięcie istniejącej funkcjonalności, modyfikacja istniejącej funkcjonalności. W przypadku dodawania i usuwania funkcjonalności rozmiar funkcjonalny tych zmian wyznacza się, jako rozmiar dodawanych lub usuwanych elementów modelu IFPUG, przy czym w przypadku usuwanych elementów stosuje współczynnik wpływu 0.40. Rozmiar funkcjonalny usuwanego elementu modelu jest iloczynem jego rozmiaru funkcjonalnego i podanego współczynnika wpływu. W przypadku modyfikacji istniejącej funkcjonalności stosuje się dodatkowe reguły opracowane przez organizację, NESMA we wspomnianym wcześniej dokumencie. WYLICZANIE ZMIAN MODELU DANYCH

Plik danych jest uznawany za zmieniony, jeśli są do niego dodane atrybuty, odjęte atrybuty, zmieniony jest typ atrybutu lub zmieniona jest struktura rekordów. Inną możliwą zmianą pliku danych jest zmiana jego typu (EIF / ILF). Celem wyliczenia rozmiaru zmiany pliku danych należy wyliczyd rozmiar funkcjonalny pliku danych po zmianie oraz wskazad liczbę zmienianych atrybutów. Mając te dane wylicza się procentowy wskaźnik zmiany. Ten wskaźnik służy do wyliczenia wskaźnika wpływu zmiany. Iloczyn wskaźnika wpływu zmiany oraz rozmiaru pliku po zmianie wyznacza rozmiar funkcjonalny zmiany pliku danych. Procentowy wskaźnik zmiany: ( liczba zmienionych atrybutów / liczba atrybutów przed zmianą) * 100% Wskaźnik wpływu wyznacza się w oparciu o poniższą tabelę: Procentowy wskaźnik zmiany p 30 % 30 % < p 60 % 60% < p 100% p >100% Wskaźnik wpływu 0.25 0.50 0.75 1.00 W przypadku, gdy zmianie ulegnie typ pliku danych to wskaźnik wpływu dla tej modyfikacji ma wartośd 0.40. W przypadku, gdy jednocześnie uległy zmianie atrybuty to, jako wskaźnik wpływu przyjmuje się wartośd większą spomiędzy wskaźnika wynikającego z modyfikacji typu oraz wskaźnika wynikającego ze zmian atrybutów. W przypadku, gdy dwa pliki danych są łączone w jeden to traktuje się to, jako usunięcie dwóch plików i dodanie jednego nowego. W przypadku, gdy istniejący plik jest dzielony to traktuje się to, jako usunięcie jednego pliku i dodanie dwóch nowych. Przykład: Plik danych ILF A posiada 15 atrybutów i jeden rekord. W ramach modyfikacji jest dodawanych kolejnych pięd a dodatkowo dla jednego istniejącego jest zmieniany typ danych. Złożonośd pliku przed modyfikacją to 7 PF. Procentowy wskaźnik zmiany to (6/15)*100% = 40%. Wskaźnik wpływu to 0.50. Złożonośd pliku po modyfikacji to 10 PF. Złożonośd zmiany to 10 PF * 50% = 5 PF. WYLICZANIE ZMIAN MODELU FUNKCJI Elementarny proces jest uznawany za zmieniony, jeśli zachodzi jeden z poniższych warunków: jest dodany, ujęty lub zmodyfikowany atrybut elementarnego procesu, jest zmodyfikowany plik danych wykorzystywany przez elementarny proces, jest zmodyfikowany interfejs użytkownika lub format raportu, zmieniona jest logika przetwarzania danych w ramach elementarnego procesu. Celem wyliczenia rozmiaru zmiany elementarnego procesu należy wyliczyd rozmiar funkcjonalny procesu po zmianie oraz wskazad liczbę zmienianych atrybutów i plików danych. Mając te dane wylicza się procentowy wskaźnik zmiany. Ten wskaźnik służy do wyliczenia wskaźnika wpływu zmiany. Iloczyn wskaźnika wpływu zmiany oraz rozmiaru procesu po zmianie wyznacza rozmiar funkcjonalny zmiany elementarnego procesu. Procentowy wskaźnik zmiany atrybutów: ( liczba zmienionych atrybutów / liczba atrybutów przed zmianą) * 100% Procentowy wskaźnik zmiany plików: ( liczba zmienionych plików / liczba plików przed zmianą) * 100% Wskaźnik wpływu wyznacza się w oparciu o poniższą tabelę: Procentowy wskaźnik zmiany pa 60 % 60 % < pa 100 % pa >100% atrybutu Procentowy wskaźnik zmiany plików pp 30 % 0.25 0.50 0.75

30% < pp 60 % 0.50 0.75 1.00 60% < pp 100% 0.75 1.00 1.25 pp >100% 1.00 1.25 1.50 W przypadku, gdy zmiana dotyczy zmiany interfejsu użytkownika to wskaźnik wpływu dla takiej zmiany wynosi 0.25. W przypadku, gdy zmiana dotyczy logiki przetwarzania to należy określid, które atrybuty i pliki danych są wykorzystywane w ramach zmianie logiki przetwarzania i liczba tych atrybutów / plików jest wykorzystywana do wyliczenia procentowego wskaźnika zmian. W przypadku podziałów / połączeo elementarnych procesów należy te zmiany traktowad, jako usuwanie starych i dodawanie nowych elementarnych procesów. Zmiana typu procesu wynika ze zmiany logiki / atrybutów i nie jest osobno wyliczana (jest to tylko klasyfikacja). Przykład: Elementarny proces E1 korzysta z pliku danych ILF1 i wykorzystuje 10 atrybutów. Ma złożonośd 3 PF. W wyniku zmiany, proces korzysta z dodatkowe pliku ILF2 oraz wykorzystuje kolejne dwa atrybuty. Procentowy wskaźnik zmiany atrybutów to 2/10 * 100% = 20%. Procentowy wskaźnik zmiany plików to ½ * 100% = 50%. Wskaźnik wpływu wynosi, zatem 0.5. Złożonośd procesu po zmianie to 4 PF. Złożonośd zmiany to 4 PF * 0.4 = 2PF. ZASADY STOSOWANIA WSPÓŁCZYNNIKA VAF Współczynnik VAF (Value Adjustment Factor) w założeniu twórców metody PF IFPUG ma odzwierciedlad złożonośd wymagao niefunkcjonalnych. Współczynnik ten jest konstruowany w oparci o 14 parametrów opisujących Globalną Charakterystykę Systemu (GSC, Global System Characteristic). Listę tych parametrów przedstawia poniższa tabela. Numer Nazwa Opis parametru GSC-1 Komunikacja Określa wagę wykorzystania przez aplikację różnych protokołów komunikacyjnych GSC-2 Przetwarzanie rozproszone Określa wagę wymiany danych pomiędzy różnymi komponentami aplikacji GSC-3 Wydajnośd Określa wagę wymagao dotyczących wydajności w projektowaniu aplikacji GSC-4 Infrastruktura Określa wagę wymagao dotyczących infrastruktury dla aplikacji GSC-5 Tempo transakcji Określa wagę tempa przetwarzania transakcji biznesowych GSC-6 Dane on-line Określa wagę on-line owego sposobu wprowadzania danych GSC-7 Ergonomia Określa wagę ergonomii interfejsu użytkownika GSC-8 Aktualizacje on-line Określa wagę wymagao odnośnie aktualizacji aplikacji i jej danych GSC-9 Złożone przetwarzanie Określa wagę złożoności algorytmów przetwarzania danych w aplikacji GSC-10 Ponowne użycie Określa wagę możliwości ponownego wykorzystania fragmentów aplikacji lub jej konfiguracji pod specyficzne zastosowania GSC-11 Instalacja Określa wagę złożoności procesu instalacji aplikacji GSC-12 Utrzymanie Określa wagę złożoności procesu utrzymania aplikacji GSC-13 Liczba lokalizacji Określa wagę dostępności aplikacji na różne platformy i liczbę potencjalnych instalacji GSC-14 Konfigurowalnośd Określa wagę wymagao odnośnie możliwości konfiguracji logiki przetwarzania aplikacji przez użytkownika

Dla każdego z powyższych parametrów określa się jego wartośd od 0 do 5 w oparciu o zasady opisane w oryginalnym podręczniku IFPUG. Wartośd VAF wyznacza się następująco: VAF = 0,65 + 0.01 x i=1..14 GSC-i. Skorygowana liczba punktów funkcyjnych IFPUG jest wyznaczana, jako iloczyn nieskorygowanej liczby punktów funkcyjnych i współczynnika VAF. W projektach ARiMR, o ile w danym projekcie jest wykorzystywany VAF, jest on wyznaczany w oparciu o normę ISO 9126 Quality of Service. Norma ta zakłada 6 kluczowych parametrów dotyczących skalowalnośd, dostępnośd i odtwarzalnośd systemu, czyli najistotniejsze elementy z punktu widzenia wymagao niefunkcjonalnych opisujących wydajnośd oraz jakośd funkcjonalności oprogramowania. Poniższa tabela zawiera opis parametrów normy ISO 9126 QoS: ID Kategoria Pod-kategoria Opis QoS-1A Funkcjonalnośd Interoperacyjnośd System IT współpracuje z innymi systemami IT QoS-1B Funkcjonalnośd Bezpieczeostwo System IT posiada mechanizmy ochrony funkcji i danych zarówno przed celowym jak i przypadkowym uszkodzeniem / utratą / udostępnieniem QoS-2A Niezawodnośd Dostępnośd System IT zapewnia dostępnośd przez określony poziom % czasu wykorzystywania. QoS-2B Niezawodnośd Odtwarzalnośd System IT zawiera mechanizmy odtworzenia po awarii. QoS-3A Wydajnośd Szybkośd działania System IT udostępnia funkcjonalnośd w określonych reżimach czasów reakcji i wykonywania. QoS-3B Wydajnośd Wykorzystanie zasobów System IT zawiera mechanizmy kontrolujące wykorzystanie zasobów infrastrukturalnych. QoS-4A Użytecznośd Zrozumiałośd System IT zawiera mechanizmy ułatwiające jego poznawanie i rozumienie przez użytkowników. QoS-5A Konserwowalnośd Zarządzalnośd System IT zawiera mechanizmy ułatwiające zarządzanie aplikacjami, funkcjami i danymi QoS-5B Konserwowalnośd Reużywalnośd Elementy Systemu IT mogą byd wykorzystane w innych systemach. QoS-6A Przenośnośd Zgodnośd System IT jest zgodny ze standardami technologicznymi i integracyjnymi QoS-6B Przenośnośd Instalowalnośd System IT zawiera mechanizmy ułatwiające jego instalowanie w określonych środowiskach. Poniższa tabela zawiera mapowanie GSC na QoS: GSC QoS GSC-1 Komunikacja QoS-1B Funkcjonalnośd : Bezpieczeostwo GSC-2 Przetwarzanie rozproszone QoS-1A Funkcjonalnośd : Interoperacyjnośd GSC-3 Wydajnośd QoS-3A Wydajnośd : Szybkośd działania GSC-4 Infrastruktura QoS-3B Wydajnośd : Wykorzystanie zasobów GSC-5 Tempo transakcji - Skalowalnośd (poza QoS)

System jest dostosowany do łatwego skalowania infrastruktury. GSC-6 Dane on-line QoS-2A Niezawodnośd : Dostępnośd GSC-7 Ergonomia QoS-4A Użytecznośd : Zrozumiałośd GSC-8 Aktualizacje on-line - Obsługa peak ów (poza QoS) System jest przystosowany do obsługi okresowych wzrostów obciążeo wynikających ze specyfiki obsługiwanych procesów biznesowych GSC-9 Złożone przetwarzanie - Algorytmy (poza QoS) Złożonośd algorytmów wynika z wymagao funickjonalnych GSC-10 Ponowne użycie QoS-5B Konserwowalnośd : Reużywalnośd GSC-11 Instalacja QoS-6B Przenośnośd : Instalowalnośd GSC-12 Utrzymanie QoS-2B Niezawodnośd : Odtwarzalnośd GSC-13 Liczba lokalizacji QoS-6A Przenośnośd : Zgodnośd GSC-14 Konfigurowalnośd QoS-5A Konserwowalnośd : Zarządzalnośd Tym samym dla systemów ARiMR wyznacza się najpierw parametry QoS a następnie, w oparciu o przedstawione powyżej mapowanie, wyznacza się współczynnik VAF. Należy podkreślid, iż powyższe mapowanie nie jest mapowaniem jedno odpowiada drugiemu, ale raczej jedno zastępuje drugie. Dla powyższej przedstawionych parametrów należy ekspercko określad ich wartośd w przedziale 0 5 gdzie 0 oznacza iż dany parametr nie ma znaczenia dla systemu (nie jest obsługiwany) a 5 oznacza iż dany parametr ma kluczowe znaczenie i jest w pełni obsługiwany. Przykład: System S1 zapewnia obywatelom dostęp read-only do danych i statusów spraw dla złożonych przez nich wniosków pomocowych. Dla systemu S1 VAF = 0.65 + 0.01 * (3+1+2+3+5+5+5+5+0+1+0+5+5+0) = 1.05 QoS System S1 Wartość GSC-1 QoS-1B Funkcjonalnośd : System S1 wymaga pełnego zabezpieczenia 3 Bezpieczeostwo autoryzacji, lecz nie wymaga pełnego zabezpieczenia utraty danych gdyż jest odtwarzany na podstawie systemu głównego. GSC-2 QoS-1A Funkcjonalnośd : System S1 współpracuje z systemem głównym 1 Interoperacyjnośd na zasadzie nocnych aktualizacji wsadowych. GSC-3 QoS-3A Wydajnośd : Szybkośd działania System S1 nie ma specjalnych wymogów wydajnościowych dane użytkownika powinny byd dla niego dostępne w czasie 10s od zgłoszenia potrzeby dostępu. 2 GSC-4 QoS-3B Wydajnośd : Wykorzystanie zasobów System S1 z racji ograniczeo infrastrukturalnych musi monitorowad liczbę otwartych sesji i kolejkowad zgłoszenia. System S1 nie musi monitorowad wykorzystania przestrzeni bazy danych. GSC-5 - Skalownośd (poza QoS) System S1 musi byd w pełni skalowalny. 5 GSC-6 QoS-2A Niezawodnośd : Dostępnośd System S1 musi byd dostępny 24/7 5 GSC-7 QoS-4A Użytecznośd : Zrozumiałośd System S1 musi byd łatwy do użycia dla 5 nieprzeszkolonych i niedoświadczonych użytkowników aplikacji internetowych GSC-8 - Obsługa peak ów (poza QoS) System S1 musi byd przygotowany pod kątem 5 większego zapotrzebowania na dostępnośd w okresie przygotowywania naliczeo. GSC-9 - Wymagania Funkcjonalne (poza Z wymagao funkcjonalnych nie wynika by 0 QoS) system S1 był złożony obliczeniowo GSC-10 QoS-5B Konserwowalnośd : System S1 nie ma wymagao związanych z re 1 Reużywalnośd używalnością jego elementów GSC-11 QoS-6B Przenośnośd : Instalowalnośd System S1 jest instalowany przez Wykonawcę 0 GSC-12 QoS-2B Niezawodnośd : Odtwarzalnośd System S1 ma mechanizmy automatycznego 5 odtworzenia po awarii GSC-13 QoS-6A Przenośnośd : Zgodnośd System S1 jest oparty o architekturę SOA i jest zgodny ze standardami interoperacyjności oraz 5 3

GSC-14 QoS-5A Konserwowalnośd : Zarządzalnośd pracy z przeglądarkami System S1 jest zarządzany przez Wykonawcę 0

PROCES SZACOWANIA ROZMIARU OPROGRAMOWANIA / ZMIANY OPROGRAMOWANIA ZASADY TWORZENIA I UTRZYMYWANIA MODELU ARTEFAKTÓW PF IFPUG Model IFPUG dla danego zbioru aplikacji zdefiniowanych dla danego projektu jest utrzymywany, jako jeden projekt EA. Każda aplikacja posiada własny model w ramach tego projektu. Struktura tego modelu powinna odzwierciedlad logiczny model funkcji i danych aplikacji. Pliku danych są modelowane, jako klasy ze stereotypem <<ILF>> lub <<EIF>>. Rekordy plików są modelowane, jako klasy w relacji kompozycji z klasą główną. Nazwa rekordu to <nazwa klas głównej>_<nazwa rekordu>. Relacje pomiędzy zbiorami danych są modelowane, jako asocjacje klas ze wskazaniem nawigowalności. Atrybuty plików są modelowane, jako atrybuty klas bez określania ich typów oraz opisów chyba, iż opis jest niezbędny by prawidłowo zidentyfikowad dany atrybut. Atrybuty związków pomiędzy plikami danych nie są modelowane dodatkowo są odzwierciedlone poprzez asocjacje klas reprezentujących pliki danych i ich rekordy. Jeśli plik danych EIF jest plikiem ILF w jednej z aplikacji to modeluje się go, jako klasę w relacji <<dependency>> do właściwego pliku, ILF, do którego interfejs dla aplikacji zewnętrznych symbolizuje dany plik EIF. Należy przy tym pamiętad, iż pliki EIF są zliczane, jako rozmiar funkcjonalny aplikacji, która z nich korzysta a nie tej, która je wystawia. Elementarne procesy są modelowane, jako przypadki użycia ze stereotypami <<EI>>,<< EQ>> oraz <<EO>>. Wykorzystanie plików danych przez elementarne procesy jest modelowane, jako relacja <<dependency>> do głównej klasy danego pliku danych. Liczbę atrybutów pliku danych (bez precyzowania, jakich) zapisuje się, jako licznośd związku po stronie pliku danych. Gdy dany elementarny proces wykorzystuje atrybuty inne niż w modelu plików danych to należy te atrybutu zdefiniowad w oddzielnej klasie ze stereotypem <<EP>> oraz nazwą odpowiadającą nazwie wykorzystującego ją procesu. Zasada powiązania i licznośd są analogiczne jak powyżej. W przypadku elementarnych procesów modelujących złożone procesy obliczeniowe dodatkowo oznacza się ich związek z elementarnymi procesami funkcjonalności w ramach, których są dostępne za pomocą relacji <<dependency>>. Dla tych procesów stosuje się też inne stereotyp: <<aeo>>. W przypadku elementarnych procesów modelujących niezależne funkcjonalności złożonych raportów dodatkowo oznacza się ich związek z elementarnymi procesami raportów w ramach, których są dostępne za pomocą relacji <<dependency>>. Dla tych procesów stosuje się też inny stereotyp: <<reo>>. W kontekście zmian: elementy modelu (EP/FTR) zmieniane mają status "Proposed", elementy modelu (EP/FTR) niezmieniane mają status "Implemented", element modelu (EP/FTR) ma oznaczoną liczbę zmienianych atrybutów jako "tagged value" o postaci: o IFPUG_ATT_D dla wskazania liczby dodawanych w zmianie atrybutów, o IFPUG_ATT_M dla wskazania liczby modyfikowanych w zmianie atrybutów, o IFPUG_ATT_U dla wskazania liczby usuwanych w zmianie atrybutów (atrybuty usunięte pozostają na modelu IFPUG dla danej zmiany). Dla modelu elementarnych procesów nie definiuje się aktorów. Na diagramach EP nie umieszcza się elementów FTR (tworzone są wyłącznie powiązania).

Każdy elementarny proces i plik danych posiada swój unikalny niezmienny identyfikator postaci xy-zzzz gdzie: x - kod Systemu Informatycznego ARiMR, y - kod podsystemu Systemu Informatycznego ARiMR, zzzz - unikalny numer elementu modelu.

Przykład: Rysunek 1 Model EP Rysunek 2 Model FTR ZASADY PREZENTACJI WYNIKÓW SZACOWANIA PF IFPUG W DOKUMENTACJI OFERTOWEJ W ramach przedstawienia wyników oszacowania w ofercie Wykonawca jest zobowiązany wskazad: dodawane elementy modelu IFPUG, usuwane elementy modelu IFPUG, modyfikowane elementy modelu IFPUG. Dla każdego wskazywanego elementu modelu musi byd podany jego numer, nazwa, wymaganie funkcjonalne, z którego wynika dany element, typ oraz ostateczny rozmiar funkcjonalny zmiany (w przypadku modyfikowanych elementów rozmiar po uwzględnieniu współczynników wpływu).

Na żądanie ARiMR Wykonawca jest zobowiązany przekazad model IFPUG w postaci projektów EA przed zmianą i po zmianie tj. z modelem IFPUG reprezentującym stan oprogramowania przed wprowadzeniem modyfikacji / ulepszenia oraz po modyfikacji / ulepszeniu.

PROCES WERYFIKACJI SZACOWANIA ARiMR weryfikuje oszacowanie IFPUG dostarczone przez Wykonawcę w oparciu wymagania, z których wynika oszacowanie oraz w oparciu o model IFPUG dostarczony przez Wykonawcę, jako projekt w narzędziu Enterprise Architect. Dostarczony model IFPUG musi spełniad wymagania formalne wskazane w niniejszym Podręczniku. Zarówno model plików danych jak i model elementarnych procesów muszą spełniad wszystkie reguły metody IFPUG wraz z rozszerzeniem NESMA oraz dodatkowe reguły zawarte w niniejszym Podręczniku. LISTA KONTROLA WERYFIKACJI MODELU DANYCH IFPUG. 1. Model spełnia wymogi formalne. 2. Pliki danych ILF zawierają dane wewnątrz granic oprogramowania. 3. Pliki danych EIF są poza granicami oprogramowania. 4. Istnieje przynajmniej jeden elementarny proces wykorzystujący dany plik danych. 5. Każdy plik danych zawiera logicznie spójny zbiór danych rozpoznawalny przez użytkownika i realizujący jego cele. 6. Każdy atrybut pliku danych jest unikalny i rozpoznawalny przez użytkownika. 7. Każdy rekord pliku danych poza podstawowym zawiera zbiór atrybutów w relacji 1:* w stosunku do podstawowych atrybutów pliku danych. 8. Wśród atrybutów pliku danych nie ma atrybutów technicznych oraz innych niespełniających reguł IFPUG. 9. Klucze obce są zamodelowane, jako ukierunkowane powiązania pomiędzy plikami danych. 10. Zidentyfikowany, jako zmieniony plik danych ma zmienione, dodane lub usunięte atrybuty lub zmieniony typ. 11. Zidentyfikowany, jako zmieniony atrybut ma zmieniony typ danych. 12. Zidentyfikowane, jako zmienione powiązanie ma zmienioną nawigowalnośd lub docelową klasę. LISTA KONTROLA WERYFIKACJI MODELU FUNKCJI IFPUG. 1. Model spełnia wymogi formalne. 2. Elementarne procesy są unikalne, znaczące dla użytkownika i realizują transakcje tj. pozostawiają oprogramowanie w stanie stabilnym. 3. Różne elementarne procesy nie są różnymi wariantami realizacji logiki, doboru danych, jednego procesu elementarnego realizującego określony cel użytkownika. 4. Każdy elementarny proces jest sklasyfikowany typem zgodny z głównym celem, jako realizacji wskazanym w tabeli poniżej. 5. Każdy elementarny proces zawiera przynajmniej jedną logikę przetwarzania wskazaną w tabeli poniżej. 6. Z każdego powiązanego pliku danych dany elementarny proces wykorzystuje przynajmniej jeden atrybut. 7. Dodatkowe atrybuty elementarnych procesów zamodelowane w klasach <<EP>> nie powielają atrybutów z plików danych, z którymi te procesy są powiązane. 8. Dodatkowe atrybuty elementarnych procesów są unikalne i znaczące dla użytkownika. 9. Dodatkowe atrybuty elementarnych procesów nie zawierają atrybutów związanych z nawigacją po interfejsie użytkownika, danymi statycznymi i opisami oraz innych niespełniających reguł IFPUG. 10. Zidentyfikowane, jako zmienione procesy mają zmienioną logikę przetwarzania, lub atrybuty lub zmienione są pliki danych, z których korzystają. 11. Zidentyfikowany, jako zmieniony atrybut elementarnego procesu ma zmieniony typ danych. Główne cele procesów w zależności od ich klasyfikacji: