Wykorzystanie inżynierskich metod pomiaru rozmiaru oprogramowania Wisła, 26.11.2012 r. Arkadiusz Maliszewski arkadiusz.maliszewski@psmo.pl Polskie Stowarzyszenie Miar Oprogramowania www.psmo.pl
Wymiarowanie jako Święty Graal czyli? Nieosiągalny ideał gdyż aktualne rozwiązania rzekomo są: Nieskuteczne? Nieefektywne? Niedopasowane? Niestosowane?
Co chcemy uzyskać dzięki wymiarowaniu? Wymagania projektu Wymiary oprogramowania harmonogram - w tym fazy projektu i ryzyka koszty - z podziałem na typy zadań i ryzyka zespół - z podziałem na role błędy - z podziałem na fazy, produkty projektu - kod, przypadki testowe efektywność - w zespołach, projektach
Skutki złego wymiarowania projektów IT Podejmowanie racjonalnych decyzji inwestycyjnych przez zleceniodawców przedsięwzięć rozwoju Systemów Oprogramowania (SO) CEL: Uzyskanie SO spełniającego wymagania zleceniodawcy co do funkcji i cech jakościowych w zaplanowanym czasie i w ramach zaplanowanego budżetu, Tylko 37% projektów rozwoju SO kończy się sukcesem, Produktom dostarczonym w rezultacie niemal 45% takich projektów brakuje średnio prawie 35% wymaganych funkcji i cech, Planowany czas dostarczenia produktu jest przekraczany średnio o 80%, a koszty średnio o 55%. Objaw tego stanu rzeczy: koszty ponoszone przez różne organizacje na bardzo zbliżone aplikacje różnią się nawet piętnastokrotnie Prof. dr hab. B. Czarnacka-Chrobot (SGH, Katedra Informatyki, PSMO) wystąpienie na Konferencji WSI organizacji PSMO, 25 kwietnia 2012
Przyczyny błędnego szacowania: - nadmierny optymizm Zanim rozpoczniemy nasze Seminarium z Zarządzania Czasem czy każdy posiada już jeden z tych 36-godzinnych zegarków?
Przyczyny: brak akceptacji faktów Twoje złe nastawienie zaczęło już mieć zły wpływ na innych. Teraz jest zdecydowanie lepiej.
Przyczyny: nieuczenie się na błędach Zapomniałem zrobić back-up mojego mózgu tak więc wszystko czego nauczyłem się w ostatnim semestrze uleciało.
Przyczyny: ukrywanie porażek Zrobiłem moją pracę domową z dwudniowym opóźnieniem ale to jest i tak szybko bo normalnie mam czterodniowe opóźnienie.
Skutki złego wymiarowania projektów IT Annual cost of failures and over-runs: US market (Standish) ~100 Billion US$ European market ~100 Billion dr Charles Symons (MkII, COSMIC, ISBSG) wystąpienie na Konferencji WSI organizacji PSMO, 25 kwietnia 2012
Stereotypy i przekonania
Demitologizacja
Rozwiązanie: obiektywne wymiarowanie Punkty funkcyjne to metryka złożoności oprogramowania wyznaczana w oparciu o określające to oprogramowanie wymagania funkcjonalne Liczba punktów funkcyjnych, wraz z benchmarkami, może być wykorzystana jako podstawa do wymiarowania projektów IT
Miary funkcjonalne oprogramowania Kupmy sobie węgiel czy poprosimy o tyle węgla ile przez tydzień wydobędzie jeden górnik? (O/M) czy poprosimy o 1000 bryłek węgla? (LOC) nie, raczej poprosimy o 1 tonę. (PF)
Czym jest szacowanie złożoności oprogramowania? Obszar analizy jednostki miary złożoności (PF,(PF) LOC ) Opis Rozmiar funkcjonalny oprogramowania Atrybuty X = oprogramowania Złożoność oprogramowania Obszar zarządzania Złożoność oprogramowania Dane historyczne X = Atrybuty produkcji $, czas, zespół Wymiary projektu ROZWÓJ
Szacowanie złożoności oprogramowania Model analityczny w notacji UML Metoda szacowania LICZBA FP
IFPUG v1 DeMarco bang FP IFPUG v2 IFPUG v3 ASMA FP IFPUG v4 Albrecht FP Rubin/ESTIMACS FP Finnish FP CRIM micro FP Bachman Analyst FP Oracle FP SPR backfire FP SPR FP 3 Adj Factors ViaSoft backfire FP Reifer coupling FP & Halstead metrics Gartner Group backfire FP Gartner Group backfire FP Jak wybrać metodę wymiarowania? Use Case Point Story Point Boeing 3D FP COSMIC FP ISO rules for functional sizing Nokia FP for telcom NESMA FP SPR Aprox FP Full FP for realtime British Mark II Object Point SPR Analogy Based FP SPR Feature Point Air Force engineering FP Compass Group backfire FP SPR Taxonomy Based FP Data point for DB sizing
Certyfikowane metody szacowania W roku 2006 organizacje ISO/IEC uznały miary funkcjonalne oprogramowania za jedyny obiektywny mechanizm określania rozmiaru oprogramowania. Istnieje 5 metod posiadających certyfikację tych organizacji, z czego 3 z nich to lokalne, krajowe odmiany metody IFPUG. ISO/IEC 14143:2006
Wiarygodność i obiektywność jednostek rozmiaru funkcjonalnego oprogramowania State Government of Victoria (Australia): wycena Systemów Oprogramowania na potrzeby tej instytucji administracji państwa na bazie jednostki funkcjonalności powoduje zmniejszenie średniego przekroczenia budżetu do mniej niż 10% (wiarygodność) + różnice w szacunkach tzw. scope manager ów do 30% (a nawet do 10%), a nie 15-krotne (obiektywność) ISBSG: przedsięwzięcia, w których produkt wyceniano przy wykorzystaniu jednostki funkcjonalności, charakteryzują się trafnymi szacunkami: dla 90% przypadków oceny szacunkowe kosztów wykazały odchylenie nieprzekraczające 20% ich rzeczywistej wartości, przy czym w przypadku 70% projektów przekroczenie nie było większe niż 10% faktycznych nakładów Prof. dr hab. B. Czarnacka-Chrobot (SGH, Katedra Informatyki, PSMO) wystąpienie na Konferencji WSI organizacji PSMO, 25 kwietnia 2012
Dane benchmarkingowe Dane benchmarkingowe gromadzi, weryfikuje i analizuje wiele organizacji. Jedną z bardziej znanych niezależnych organizacji jest International Software Benchmarking Standard Group (www.isbsg.org). Organizacja utrzymuje repozytorium danych oraz udostępnia ich próbki oraz publikuje ich analizy.
Podsumowanie Szacowanie projektów z wykorzystaniem miar funkcjonalnych jest jedynym skutecznym i obiektywnym sposobem pomiaru złożoności oprogramowania Miara punktów funkcyjnych staje się na świecie uznaną za standard metryką dla oprogramowania Zastosowanie funkcjonalnych miar oprogramowania w znaczącym stopniu zwiększa prawdopodobieństwo zakończenia projektu sukcesem
Dziękuję za uwagę