Baza Wiedzy
Ocena wielkości oprogramowania na podstawie wymagań, czyli dlaczego warto stosować jednocześnie metodykę IFPUG oraz SNAP

Ocena wielkości oprogramowania na podstawie wymagań, czyli dlaczego warto stosować jednocześnie metodykę IFPUG oraz SNAP

Dlaczego warto wprowadzić w organizacji praktykę szacowania projektu oraz jakie konsekwencje możemy ponieść, jeśli tego nie zrobimy? Na te pytania odpowiedzi szukała Mirela Krzyżak, Project Manager w APN Promise.

Artykuł polecamy:

– dyrektorom IT;

– project managerom;

– analitykom;

Business case, czyli powszechny problem niedoszacowania

Firma X jest zainteresowana realizacją modyfikacji w swoim istniejącym systemie, zleca więc przygotowanie wyceny firmie Y. Firma Y ocenia wielkość zmiany jedynie na podstawie wymagań funkcjonalnych, uznając to za szacunek całościowy. Po akceptacji wyceny przez firmę X, rozpoczyna się realizacja, w trakcie której pojawiają się problemy. Jednym z nich jest niedotrzymanie terminów zawartych w harmonogramie, który powstał w oparciu o otrzymany wcześniej szacunek. W konsekwencji firma Y musi zapłacić firmie X kary za nieterminowe wykonanie zlecenia.  Ponadto po zakończeniu prac okazuje się, że wielkość zmiany została niedoszacowana o 40%, co oznacza, że firma Y zamiast zyskać – straciła. Przyczyną był brak wzięcia pod uwagę niezwykle problematycznej architektury systemu, w której wykonywano modyfikację oraz szereg niewycenionych procesów walidacji.

Rozwiązaniem problemów, które pojawiły się w powyższym business case, jest zastosowanie w procesie oceny wielkości modyfikacji dwóch metodyk jednocześnie. Uwzględniając wymagania niefunkcjonalne, tj. wspomniane problemy z architekturą, czy też walidacje danych firma Y osiągnęłaby faktyczny szacunek wielkości zmiany. W rezultacie uniknęłaby przekroczenia zarówno dat przewidzianych przez harmonogram, a tym samym zapłaty kar, jak również osiągnęłaby zaplanowany wynik finansowy.

Skoro wiemy na czym polegał problem, poznajmy zatem tajniki związane z jego rozwiązaniem, a w konsekwencji przyjrzyjmy się bliżej dwóm metodykom szacowania.

Ocena wielkości oprogramowania na podstawie wymagań, czyli dlaczego warto stosować jednocześnie metodykę IFPUG oraz SNAP

Temat szacowania, a tym samym przygotowywania wyceny w projektach informatycznych niejednokrotnie staje się trudny, a czasem wręcz kłopotliwy i to zarówno dla Wykonawcy, jak również Klienta zamawiającego dany system. Jednym z efektów błędnego oszacowania wielkości realizowanego projektu, jak wspomniano w przytoczonym business case, może być przekroczenie wcześniej przyjętych terminów oraz budżetu. W związku z tym warto zastanowić się nad wprowadzeniem powtarzalnej praktyki szacowania, którą dodatkowo można w czytelny sposób uargumentować. W konsekwencji, poza rzeczową oceną wielkości oprogramowania, uzyskamy jeden z fundamentalnych mechanizmów zarządzania finansami. Co więcej, taka ocena pozwoli na zaplanowanie ram czasowych, a tym samym opracowanie harmonogramu całego projektu. Ponadto będzie podstawą do określenia zasobów koniecznych do jego realizacji, a także ułatwi weryfikację postępów pracy.

Czym tak naprawdę jest metodyka IFPUG, a czym SNAP

Metoda analizy punktów funkcyjnych (FPA – Function Point Analysis) została opracowana przez A. J. Albrechta w 1979r., a obecnie jest promowana i stale rozwijana przez międzynarodową organizację użytkowników FPA – IFPUG (The International Function Point Users’ Group. Metodyka została potwierdzona standardem ISO/IEC 20926:2009, w skutek czego uznano ją za obiektywny mechanizm określania rozmiaru oprogramowania. Najogólniej mówiąc, punkty funkcyjne to jednostki miary przedstawiające zakres funkcjonalności biznesowej, zagwarantowane użytkownikowi przez oprogramowanie. Innymi słowy, wymagania funkcjonalne opisują operacje, czynności oraz usługi wykonywane przez system i to na ich podstawie wyliczane są punkty funkcyjne.

Z kolei metoda określania wielkości oprogramowania zwana metodą SNAP (Software Non-functional Assessment Process) – w przeciwieństwie do IFPUG – bazuje na wymaganiach niefunkcjonalnych. Wyjaśniając, są to wymagania opisujące ograniczenia, przy zachowaniu których system powinien realizować swe funkcje. Naturalnym jest, iż wykorzystując metodę SNAP nie jesteśmy w stanie przeanalizować wpływu wszystkich wymagań niefunkcjonalnych na złożoność oprogramowania, jednak zawiera ona najważniejsze z nich. Należy podkreślić, że metoda SNAP stała się standardem IEEE: IEEE 2430-2019 dopiero od października 2019r., zatem jest to dość nowa metoda.

Jednak niezależnie od tego, czy weźmiemy na warsztat i będziemy chcieli zastosować metodykę IFPUG, czy też SNAP, warunkiem koniecznym do rozpoczęcia prac jest znajomość wymagań, a w związku z tym dokładne zapoznanie się z dokumentacją szacowanego systemu.

Główne założenia metodyki IFPUG

Fundamentalnym założeniem metody punktów funkcyjnych jest podzielenie oprogramowania na pięć elementów, tj.:

  1. Zewnętrzne typy wejścia (EI) – czyli metody dokonywania zmian (przetwarzanie obiektów wejściowych) wpływające na dane w systemie;
  2. Zewnętrzne typy wyjścia (EO) – czyli metody reprezentacji danych przechowywanych przez system. Innymi słowy dane, które system generuje w celu ich wykorzystania przez użytkownika końcowego lub inny system;
  3. Logiczne wewnętrzne typy plików (ILF) – czyli pliki używane wewnętrznie przez system;
  4. Zewnętrzne typy interfejsów plików (EIF) – czyli metody wymiany danych między innymi systemami informatycznymi. Przykładem mogą być pliki współdzielone między różnymi aplikacjami;
  5. Zewnętrzne typy zapytań(EQ) – czyli metody odczytu danych z systemu nie powodujące ich modyfikacji. Przykładem jest zapytanie SELECT z języka SQL;
Główne założenia metodyki IFPUG

Źródło: Edusolution

Po wyszukaniu a następnie przydzieleniu wszystkich wymagań funkcjonalnych analizowanego systemu informatycznego do konkretnych składowych, każdemu z nich należy przypisać stopień złożoności. Aby to zrobić, warto zapoznać się z poniższymi pojęciami.

Złożoność funkcjonalna danych składowanych w plikach logicznych tj. ILF oraz EIF jest wyznaczana na podstawie dwóch parametrów:

  1. Liczby różnych struktur danych (RET – Record Element Type) występujących wewnątrz danego pliku;
  2. Liczby elementów danych – atrybutów (DET – Data Element Type) występujących w danym pliku danych;

Z kolei złożoność funkcjonalna wejść i wyjść danych oraz zapytań tj. EI, EO, EQ jest szacowana na podstawie:

  1. Liczby przetwarzanych plików danych (FTR – File Type Referenced). Przetwarzanie obejmuje odczyt, zapis, modyfikację i usuwanie danych w plikach logicznych;
  2. Liczby elementów danych – atrybutów (DET – Data Element Type) wpływających do systemu i z niego wypływających;

W celu uzyskania stopnia złożoności należy dla każdego elementu przypisać określoną liczbę  RET/FTR oraz DET, w konsekwencji czego otrzymujemy kategorię (niska, średnia, wysoka). Efektem końcowym jest liczba punktów odpowiadających zarówno kategorii, jak również wspomnianej powyżej złożoności zgodnie z tabelą:

IFPUG Counting Practices Manual

Źródło: Na podstawie IFPUG Counting Practices Manual v.4.3.1

Dla przykładu, plik danych ILF o 51 atrybutach oraz 4 rekordach należy do kategorii wysokiej, co oznacza, że jego wielkość została oszacowana na 15 punktów funkcyjnych. W rezultacie suma otrzymanych wartości wszystkich składowych jest równa liczbie punktów funkcyjnych dla danego systemu.

Warto podkreślić, że wymienione powyżej elementy oprogramowania muszą jednoznacznie wynikać z wymagań funkcjonalnych użytkownika. Co więcej, powinny przedstawiać funkcjonalność oprogramowania rozumianą w tym wypadku jako dane i funkcje, a także osiągalną dla użytkownika, lecz nie dotyczącą sposobu implementacji przedmiotowej funkcjonalności.

Główne założenia metody SNAP

Podobnie, jak w przypadku metodyki IFPUG, również tutaj, na samym początku prac należy określić i przypisać do każdego wymagania właściwą grupę. Zacznijmy od tego, że proces oceniania wielkości oprogramowania SNAP bazuje na mnogości zagadnień podzielonych na cztery kategorie oraz czternaście podkategorii. Wspomniane kategorie opisują różne aspekty wymagań niefunkcjonalnych, takich jak sposoby operowania danymi, a tym samym formatowanie i walidacja danych, czy stosowane algorytmy przetwarzania danych, jak również interfejs użytkownika, środowisko techniczne oraz architekturę rozwiązania. Poniżej zostały przedstawione poszczególne kategorie oraz podkategorie:

Główne założenia metody SNAP

Źródło:  Na podstawie IFPUG SNAP v2.4.0 (Software Non-functional Assessment Process) Quick Guide

Po określeniu i przypisaniu do każdego wymagania właściwej kategorii oraz podkategorii, kolejno należy zidentyfikować SCU (Snap Counting Unit) tj. jednostkę wielkości do oceny miary, której złożoność opisują parametry lub pytania oceniające. Te ostatnie odnoszą się do określonych atrybutów pozwalających na niefunkcjonalną ocenę danej podkategorii. W celu otrzymania SCU posłużymy się równaniami lub tabelami, które różnią się między sobą i są dedykowane dla właściwej podkategorii. W wyniku takiego działania otrzymamy punkty SNAP, będące sumą wielkości jednostek SCU dla każdej kategorii, ostatecznie wypracowując rozmiar niefunkcjonalny.

Wykorzystywanie metody SNAP w praktyce pokazało, że najczęstszymi podkategoriami, które opisują wymagania niefunkcjonalne, są procesy odpowiedzialne za walidację wprowadzanych danych (Data Entry Validation), zmiany w bazie danych podyktowane wymaganiami pozafunkcjonalnymi lecz nie zmieniającymi samej funkcjonalności (Database Technology), a także złożone algorytmy, czyli rozbudowane decyzje logiczne i operacje matematyczne odbywające się w ramach konkretnych procesów (Logical and Mathematical Operations).

Dlaczego warto wykorzystywać obydwie metody w trakcie szacowania jednego oprogramowania?

Jak już wspomniano powyżej, metoda punktów funkcyjnych IFPUG pozwala ocenić wielkość oprogramowania czy też jego modyfikację przy założeniu, że definicja funkcjonalności nowej lub zmienianej wynika z wymagań funkcjonalnych użytkownika. Jednak – jak wiadomo – wymagania funkcjonalne nie są jedynym czynnikiem określającym wielkość realizowanego projektu. W rezultacie, nie wszystkie prace powiązane z wykonaniem danego systemu mogą być oszacowane metodą IFPUG -chociażby czynności mające na celu wprowadzenie lub zmianę architektury, technologii oraz interfejs nie podlegają szacowaniu przedmiotową metodyką. Dlatego też niezwykle pomocna staje się metoda SNAP, odpowiedzialna za ocenę wymienionych powyżej wymagań niefunkcjonalnych.

Assessment Practices Manual

Źródło: SNAP v2.3 Assessment Practices Manual

Podsumowując, przy zastosowaniu w ocenie wielkości oprogramowania obydwu metod, tzn. metody IFPUG oraz SNAP, zyskujemy pewność, iż szacowaniu podlegają wymagania zawierające zarówno funkcjonalne, jak i niefunkcjonalne aspekty. W wyniku takiego działania otrzymujemy rzetelny rozmiar szacowanego systemu prezentujący się w postaci punktów funkcyjnych oraz punktów SNAP.

Leave a comment