Ocena wielkości oprogramowania na podstawie wymagań

Mirela Krzyżak

Ocena wielkości oprogramowania na podstawie wymagań, czyli dlaczego warto stosować jednocześnie metodykę IFPUG oraz SNAP
8 października, 2020 paulinamarszalek

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.

Podziel się

Autor: Mirela Krzyżak

Mirela Krzyżak

Projekt Manager

Specjalizuje się w obszarze zarządzania projektami IT. Na co dzień realizuje projekty z zakresu rozwiązań Microsoft, m.in. Active Directory, Exchange, SharePoint, a także projekty programistyczne oraz w obszarze BI. Współpracuje zarówno z Klientami z sektora publicznego, jak również prywatnego dbając o to, aby projekt zakończył się pełnym sukcesem. Zdecydowanie gracz zespołowy. W swojej pracy skupia się na budowaniu płaszczyzny komunikacji pomiędzy działami biznesu oraz IT, wykorzystując wiedzę z zakresu zarządzania ludźmi i procesami.

 

Skontaktuj się z autorem

 

Administratorem danych gromadzonych z wykorzystaniem formularza jest A.P.N. Promise S.A. Podane przez Ciebie dane będą przetwarzane w zakresie niezbędnym do podjęcia kontaktu lub realizacji określonego żądania zgodnie z art. 6 ust. 1 lit. b RODO przez okres niezbędny dla realizacji Twojego zgłoszenia. Wszelkie informacje w zakresie przetwarzania podanych przez Ciebie w formularzu danych oraz posiadanych uprawnieniach znajdziesz w Polityce prywatności. Kliknij i dowiedz się więcej jeżeli informacje podane powyżej nie są dostatecznie jasne!

Zarejestruj się i przetestuj APN Meeting Room

Wypróbuj system rezerwacji sal w praktyce, na Twojej infrastrukturze.
Wersja demonstracyjna umożliwia Ci instalację oprogramowania na 3 urządzeniach.

Chcę otrzymywać treści marketingowe od A.P.N. Promise S.A. drogą elektroniczną
Chcę otrzymywać treści marketingowe od A.P.N. Promise S.A. telefonicznie

Administratorem danych osobowych gromadzonych z wykorzystaniem formularza jest A.P.N. Promise S.A. z siedzibą w Warszawie. Kontakt z osobą odpowiedzialną za ochronę danych osobowych jest możliwy za pośrednictwem adresu e-mail: iodo@promise.pl. Podane dane będą przetwarzane w zakresie niezbędnym do realizacji określonego żądania zgodnie z art. 6 ust. 1 lit. b RODO, w zakresie niezbędnym dla prawidłowej realizacji żądania oraz oferowania i świadczenia usług, marketingu produktów i usług własnych oraz przeprowadzenia ankiet i oceny satysfakcji zgodnie z art. 6 ust. 1 lit. f RODO przez okres niezbędny dla realizacji celów oraz w przypadku wyrażenia zgody na podstawie art. 6 ust. 1 lit. a RODO w celu dostarczenia treści marketingowych środkami komunikacji elektronicznej lub za pomocą urządzeń telefonicznych.

Przysługuje Ci prawo do żądania dostępu do danych osobowych, ich sprostowania, usunięcia lub ograniczenia przetwarzania, jak również prawo sprzeciwu wobec przetwarzania, prawo do przenoszenia danych, a także prawo złożenia skargi do organu nadzorczego, którym w Polsce jest Prezes Urzędu Ochrony Danych Osobowych. Podanie danych jest dobrowolne, jednak niezbędne dla realizacji powyżej wskazanych celów. Odbiorcami danych mogą być podmioty lub osoby obsługujące administratora w zakresie w zakresie hostingu, komunikatorów internetowych, usług IT, księgowości, archiwizacji. Więcej informacji w Polityce Prywatności oraz Regulaminie.

Register and test the APN Meeting Room booking system.

Registering and installing the trial version you are allowed to install the software on 3 devices.

I want to receive marketing content from A.P.N. Promise S.A. electronically
I want to receive marketing content from A.P.N. Promise S.A. by phone

The data controller of personal data collected using the form is A.P.N. Promise S.A. with its registered office in Warsaw. Contact with the person responsible for the personal data protection is possible via following e-mail address: iodo@promise.pl. The given data shall be processed to the extent necessary to carry out specified request in accordance with art. 6(1)(b) of GDPR and to the extent necessary for the correct realization of the request and offer and provision of services, own product and services marketing and conducting surveys and satisfaction ratings in accordance with art. 6(1)(f) of GDPR for the period necessary to achieve the purposes and in the event of consent in accordance with art. 6(1)(a) of the GDPR to provide marketing content by electronic means or by telephone devices.

You have the right to request access to your personal data, rectification, deletion or limitation of processing, as well as the right to object to processing, the right to transfer data and the right to lodge a complaint with a supervisory authority, i.e. the President of the Personal Data Protection Office in Poland. Providing data is voluntary but necessary for the realization of the above-mentioned purposes. Recipients of data may be entities or persons servicing the data controller in the field of hosting, instant messengers, IT services, accounting, archiving. More information in the Privacy Policy and Regulations.

Cybersecurity w obszarze zarządzania zasobami oprogramowania

Napisz do nas, a skontaktujemy się z Tobą i bezpłatnie porozmawiamy o Twoim poziomie cyberbezpieczeństwa w obszarze SAM.

 

Administratorem danych gromadzonych z wykorzystaniem formularza jest A.P.N. Promise S.A. Podane przez Ciebie dane będą przetwarzane w zakresie niezbędnym do podjęcia kontaktu lub realizacji określonego żądania zgodnie z art. 6 ust. 1 lit. b RODO przez okres niezbędny dla realizacji Twojego zgłoszenia. Wszelkie informacje w zakresie przetwarzania podanych przez Ciebie w formularzu danych oraz posiadanych uprawnieniach znajdziesz w Polityce prywatności. Kliknij i dowiedz się więcej jeżeli informacje podane powyżej nie są dostatecznie jasne!

Zostaw adres mailowy i nie przegap kolejnego szkolenia!

[contact-form-7 404 "Not Found"]