Wymiarowanie funkcjonalne przedsięwzięć rozwoju systemów oprogramowania

BEATA CZARNACKA-CHROBOT Szkoła Główna Handlowa w Warszawie

Streszczenie

Z przeprowadzonej przez autorkĊ analizy rezultatów badaĔ dotyczących wiary-godnoĞci metod szacowania pracochłonnoĞci przedsiĊwziĊü rozwoju systemów opro-gramowania wspomagających zarządzanie (SOWZ) wynika, Īe spoĞród wszystkich uwzglĊdnionych zasadniczych podejĞü o charakterze metodycznym najbardziej trafne oceny estymacyjne dają obecnie modele ekstrapolacji parametrycznej oparte na rozmiarze SOWZ wyraĪonym w jednostkach funkcjonalnoĞci - szczególnie w przy-padku ich dostosowania do specyficznych organizacyjnych warunków projektowych, do czego niezbĊdne jest gromadzenie odpowiednich własnych danych historycznych przez ich wykonawców. Tymczasem w praktyce organizacje projektowe rzadko gro-madzą dane konieczne do wyprowadzenia specyficznych dla siebie zaleĪnoĞci. W ta-kiej sytuacji ujawnia siĊ uĪytecznoĞü repozytoriów gromadzących uogólnione dane historyczne o przedsiĊwziĊciach rozwoju SOWZ zrealizowanych w przeszłoĞci, na bazie których, wyprowadza siĊ uogólnione modele ekstrapolacji parametrycznej, wskazujące na zaleĪnoĞü pracochłonnoĞci od rozmiaru produktu przedsiĊwziĊcia wy-raĪonego w jednostkach funkcjonalnoĞci. Obecnie najwiĊkszym repozytorium takich danych dysponuje organizacja International Software Benchmarking Standards Group. Repozytoria takie posiada takĪe kaĪde z narzĊdzi wspomagających estymacjĊ atrybutów przedsiĊwziĊcia w oparciu o rozmiar jego produktu wyraĪony w jednost-kach funkcjonalnoĞci. Celem niniejszego artykułu jest próba analizy uĪytecznoĞci uogólnionych danych historycznych dla tzw. wymiarowania funkcjonalnego przed-siĊwziĊü rozwoju SOWZ na tle istniejących w tym obszarze zasadniczych moĪliwoĞci. Słowa kluczowe: wymiarowanie funkcjonalne, norma ISO/IEC 14143, metoda punktów

funkcyj-nych IFPUG, modele ekstrapolacji parametrycznej, repozytorium dafunkcyj-nych histo-rycznych ISBSG, narzdzia wspomagajce wymiarowanie funkcjonalne

1. Wprowadzenie

Due znaczenie poziomu trafnoci ocen estymacyjnych dla pracochłonno przedsiwzi rozwoju SOWZ wynika z faktu, e w przypadku takich przedsiwzi atrybut ten determinuje koszty i czas ich realizacji. Dokonana przez autork w pracy [3] analiza dostpnych w literaturze przedmiotu wyników kilkudziesiciu bada nad wiarygodnoci zasadniczych metod szacowania nakładów pracy dla tego typu projektów wykazała, e obecnie najwiksz trafno rezultatów oferuj modele ekstrapolacji parametrycznej, które s:

2) dostosowane do specyficznych organizacyjnych warunków projektowych.

Podstaw dla takich modeli stanowi zatem metody tzw. wymiarowania rozmiaru funkcjonal-nego (ang. Funcional Size Measurement – FSM) produktu programowego, oparte na jedynej jak dotd uznanej przez midzynarodowe organizacje standaryzacyjne ISO (International Organization for Standardization) i IEC (International Electrotechnical Commission) koncepcji wymiarowania rozmiaru oprogramowania bazujcej na jego funkcjonalnoci [10]. Wymiarowanie kluczowych atrybutów przedsiwzi zmierzajcych do rozwoju systemów oprogramowania w oparciu o t znormalizowan w standardzie ISO/IEC 14143 koncepcj mona wic okreli mianem wymiaro-wania funkcjonalnego.

W metodach FSM podstawow jednostk funkcjonalnoci stanowi punkt funkcyjny (PF), który słuy do wymiarowania tzw. rozmiaru funkcjonalnego oprogramowania. Zgodnie z definicj ISO/IEC przez rozmiar taki rozumie si „rozmiar oprogramowania otrzymany przez iloĞciowe okreĞlenie wymagaĔ funkcjonalnych uĪytkownika” [10, Part 1, s. 2]. Sposób kalkulacji rozmiaru funkcjonalnego, a co za tym idzie take definiowania punktu funkcyjnego, uzaleniony jest od wykorzystywanej metody FSM. Do wymiarowania rozmiaru funkcjonalnego produktów progra-mowych typu SOWZ mona wykorzystywa wszystkie znormalizowane przez ISO/IEC metody takiego wymiarowania - jest ich obecnie 5 [4], jednak zasadnicze modele parametrycznej ekstrapo-lacji pracochłonnoci uwzgldniaj w przewaajcej wikszoci rozmiar uzyskany przy wykorzy-staniu metody stworzonej przez International Function Point Users Group (IFPUG) [12].

W metodzie IFPUG podstawow jednostk pomiaru rozmiaru funkcjonalnego stanowi tzw. nieskorygowany punkt funkcyjny (NPF – ang. unadjusted function point). Zgodnie z definicj IFPUG liczba NPF to miara funkcjonalnoci dostarczanej uytkownikowi w wyniku realizacji projektu lub przez zainstalowan, gotow aplikacj [6, s. G-7]. Przy jej kalkulacji uwzglĊdnia siĊ zatem jedynie wymagania funkcjonalne uĪytkownika. W podejciu proponowanym przez IFPUG metoda ta obejmuje take wyznaczenie tzw. czynnika korygujcego, który ma za zadanie dostosowanie rozmiaru funkcjonalnego produktu do rodowiska konkretnego przedsiwzicia poprzez uwzgldnienie wpływu wymaga technicznych i jakociowych na proces projektowania i implementacji aplikacji. Ogólnie rzecz ujmujc, po pomnoeniu liczby NPF przez ten czynnik uzyskuje si kocowy rezultat metody IFPUG, czyli liczb skorygowanych punktów funkcyjnych (SPF - ang. adjusted function points), wyraajc ostateczny rozmiar oprogramowania. Jednake ta cz metody IFPUG nie posiada aprobaty ISO i IEC - przyjte przez te organizacje załoenia wykluczaj bowiem zaleno FSM od wymaga jakociowych i technicznych.

Odpowiedni liczb NPF IFPUG przypisuje si funkcjom i danym niezbdnym do ich realiza-cji - w zalenoci od ich rodzaju i poziomu złoonoci. Uwzgldniane w obliczeniach komponenty funkcjonalne to: wewntrzne pliki logiczne (dane utrzymywane przez wymiarowan aplikacj), zewntrzne pliki komunikacyjne (dane wykorzystywane przez wymiarowan aplikacj, ale utrzy-mywane poza ni) oraz procesy elementarne (funkcje, transakcje), dziki którym przetwarzane przez nie dane przekraczaj wyznaczone granice aplikacji, do których nale: zewntrzne wejcia, zewntrzne wyjcia i zewntrzne zapytania.

Kalkulacja rozmiaru SOWZ w jednostkach funkcjonalnoci nie jest jednak warunkiem wystar-czajcym do uzyskania dostatecznie wiarygodnych ocen estymacyjnych dla pracochłonnoci przedsiwzicia zmierzajcego do jego rozwoju, chocia niewtpliwie silnie temu sprzyja. Ich trafno zaley take od poziomu dostosowania modeli ekstrapolacji parametrycznej opartych na

rozmiarze funkcjonalnym produktu do specyficznych organizacyjnych warunków projektowych. M. Jørgensen [16] proponuje wyróni trzy poziomy takiego dostosowania:

• Poziom niskiego dostosowania: dostosowanie realizowane poprzez uwzgldnienie standardo-wych czynników wpływajcych na pracochłonno w powizaniu z rónicami wystpujcymi midzy estymowanym a typowym przedsiwziciem (np. w przypadku korzystania po raz pierwszy z nowego narzdzia wspomagajcego dodanie 10% całkowitych nakładów pracy). Przy tym poziomie zatem nie analizuje si organizacyjnych danych historycznych.

• Poziom redniego dostosowania: dostosowanie poprzez wykorzystanie specyficznych dla organizacji wartoci produktywnoci, które zastpuj standardowe czynniki wpływajce na pracochłonno typowego przedsiwzicia.

• Poziom wysokiego dostosowania: modele estymacyjne w postaci równa regresji s wyprowa-dzane jedynie na bazie specyficznych dla organizacji danych.

Wprawdzie istniej firmy, które dane historyczne gromadz od lat (np. IBM, Volkswagen AG, Dresdner Bank AG), ale w rzeczywistoci jak dotd wikszo organizacji projektujcych nie gromadzi ich w sposób rzetelny i systematyczny, niezbdny do wyprowadzenia specyficznych dla siebie zalenoci [17], co w odniesieniu do polskich wykonawców (wewntrznych i zewntrznych) dedykowanych SOWZ zostało wykazane w pracy [2]. W takim przypadku mona albo powróci do zakoczonych przedsiwzi i przy posiadaniu odpowiedniej dokumentacji wyprowadzi potrzeb-ne zalenoci1_{, albo odwoła si - nie zapominajc jednak o pewnej dozie ostronoci - do} uogól-nionych modeli ekstrapolacji parametrycznej budowanych na podstawie danych historycznych gromadzonych w specjalnie do tego celu stworzonych repozytoriach, gdzie uwzgldnia si, oprócz informacji o przecitnych wielkociach, take dane bardziej precyzyjne, uzalenione od specyfiki przedsiwzicia i jego produktu. Repozytoria takie posiada kade z narzdzi wspomagajcych estymacj atrybutów przedsiwzicia, oferuj je take organizacje zainteresowane rozwojem metod szacowania, a wród nich na szczególn uwag zasługuje repozytorium International So-ftware Benchmarking Standards Group (ISBSG) z danymi o ponad 5 tysicach przedsiwzi, których produkty wymiarowane s w oparciu o metody FSM2_{. W takiej sytuacji włanie, przy} braku odpowiednich organizacyjnych danych historycznych, zauwaa si uyteczno repozyto-riów gromadzcych dane uogólnione, słuce do wyprowadzenia uogólnionych modeli parame-trycznej ekstrapolacji nakładów pracy opartych na rozmiarze funkcjonalnym SOWZ.

2. Przykładowe uogólnione modele parametrycznej ekstrapolacji pracochłonnoĞci oparte na rozmiarze funkcjonalnym SOWZ

Modele parametrycznej ekstrapolacji pracochłonnoci przedsiwzi rozwoju SOWZ róni si uwzgldnianymi czynnikami korygujcymi, poziomem ich oddziaływania na pracochłonno, sposobem dostosowania nieliniowego wpływu wzrostu rozmiaru produktu na wielko przedsi-wzicia, ale przede wszystkim miar rozmiaru produktu jako podstawowego atrybutu wejciowego dla takich modeli3. Zasadnicze przykładowe modele parametrycznej ekstrapolacji pracochłonnoci oparte na rozmiarze produktu przedsiwzicia wyraonym w jednostkach funkcjonalnoci

1 _{Na takim podejĞciu właĞnie Tom DeMarco oparł swoją sławną opowieĞü pt. „ZdąĪyü przed terminem. OpowieĞü o}

zarządzaniu projektami”, wydaną w Polsce w 2002 przez Studio EMKA.

2 _{International Software Benchmarking Standards Group (ISBSG), http://www.isbsg.org (11.05.2009).}

3 _{O róĪnych rodzajach miar rozmiaru produktu programowego róĪnicujących metody parametrycznej ekstrapolacji}

stawiono w tabeli 1. Formuły te uzyskano empirycznie a posteriori na bazie analizy danych ze zrealizowanych przedsiwzi, wyprowadzajc równania regresji. Słu one do estymacji wartoci oczekiwanej zmiennej objanianej (zalenej), jak stanowi pracochłonno, przy okrelonych zmiennych objaniajcych (niezalenych), wród których w kadym modelu wystpuje rozmiar produktu wyraony w skorygowanej lub nieskorygowanej liczbie PF IFPUG.

Tabela 1. Podstawowe przykładowe modele parametrycznej ekstrapolacji pracochłonnoĞci przed-siĊwziĊü rozwoju SOWZ oparte na rozmiarze funkcjonalnym

Model Formuła szacowania pracochłonnoĞci

(NP) Parametry Kemerera 8 3

10

728

,

7

62

,

60

SPF

NP

₌

_×

_×

_×

_NP

_SPF

×

+

=

41

,

09

2

,

37

NP

=

585

,

7

+

15

,

12

×

SPF

SPF – rozmiar produktu w skorygowanych punktach funkcyjnych IFPUG

Jianga-Naudé’a 0,736

3

,

38

NPF

NP

₌

_×

NPF – rozmiar produktu w nieskorygowa-nych punktach funkcyjnieskorygowa-nych IFPUG ISBSG (por. take p. 3) E zp

S

NPF

NP

₌

_×

NP

W

NP

NP

₌

₊

_×

NPzp(min) – minimalne moliwe do

wydatko-wania nakłady pracy zespołu projektowego; S – stała uzaleniona od rodzaju platformy implementacji:

 dla duych komputerów (ang. mainfra-me): 51,03

 dla minikomputerów: 60,51  dla PC: 33,36

 dla rozwiza opartych na wielu platfor-mach: 16,96;

E – wykładnik potgi uzaleniony od rodzaju platformy implementacji:

 dla duych komputerów: 0,722  dla minikomputerów: 0,687  dla PC: 0,721

 dla rozwiza opartych na wielu platfor-mach: 0,864;

NPF – rozmiar produktu w nieskorygowa-nych punktach funkcyjnieskorygowa-nych IFPUG; NPzp(max) – maksymalne moliwe do

wydatkowania nakłady pracy zespołu projektowego;

W – współczynnik korygujcy uzaleniony od platformy implementacji:

 dla minikomputerów: 50%  dla pozostałych: 70%.

3. Przykładowe repozytoria danych historycznych dla przedsiĊwziĊü rozwoju SOWZ

ISBSG to organizacja non-profit załoona w drugiej połowie lat 90. ubiegłego wieku w celu doskonalenia procesów zarzdzania zasobami informatycznymi zarówno w podmiotach gospodar-czych, jak i w instytucjach administracji publicznej [5, s. 2]. Zadanie to realizuje poprzez utrzy-mywanie, rozwijanie i wykorzystywanie trzech rodzajów repozytoriów z danymi historycznymi: jedno z nich, najwiksze, obejmuje dane dla przedsiwzi informatycznych polegajcych na budowie i doskonaleniu systemów oprogramowania, drugie - dane dla aplikacji wspomagajcych i utrzymywania oprogramowania, trzecie natomiast – dane dotyczce nabywania i wdraania gotowych pakietów oprogramowania. Repozytoria te s znormalizowane zgodnie ze standardem ISO/IEC 15939 [11], zweryfikowane i reprezentatywne dla obecnej technologii.

Dane zgromadzone w repozytorium przeznaczonym dla przedsiwzi polegajcych na budo-wie i doskonaleniu systemów oprogramowania pochodz z ponad piciu tysicy projektów zreali-zowanych w ponad 25 krajach, a przewaajca wikszo z nich nie jest starsza ni 7 lat. Dotycz one wielu bran i obszarów biznesowych. Dane te klasyfikuje si ze wzgldu na nastpujce kryteria [7]:

• kraj, w którym podjto przedsiwzicie;

• kontekst przedsiwzicia, w tym: rodzaj organizacji (brana) oraz obszar biznesowy;

• typ przedsiwzicia, w tym: rodzaj działa (budowa, doskonalenie), przeznaczenie projektu (wewntrzne, zewntrzne) oraz liczebno zespołu projektowego;

• typ produktu, w tym: typ aplikacji (np. SOWZ) oraz rozmiar funkcjonalny produktu, który w przewaajcej wikszoci jest wyraony w NPF IFPUG (ok. 85% przypadków);

• rodowisko realizacyjne, w tym: jzyk programowania oraz platforma sprztowa; • stosowane metody i narzdzia projektowania.

Na bazie danych o takich przedsiwziciach ISBSG tworzy cykliczne raporty analityczne, do-tyczce m.in.: planowania przedsiwzi, ich kosztów, czynników determinujcych produktyw-no, wpływu narzdzi i technik projektowania oraz liczebnoci zespołu projektowego na produk-tywno, wiarygodnoci metod estymacji atrybutów przedsiwzi oraz wczesnego ich szacowania. Z perspektywy podjtej w niniejszym artykule problematyki to ostatnie zagadnienie zasługuje na szczególn uwag.

W wyniku analizy danych dotyczcych przedsiwzi budowy i doskonalenia systemów opro-gramowania wyprowadzono wiele reguł przydatnych w praktyce do wstpnej estymacji kluczo-wych atrybutów przedsiwzi rozwoju SOWZ (tzw. rules of thumb). Wród nich na szczególn uwag zasługuj przede wszystkim zalenoci dotyczce:

1. Weryfikacji kompletnoci wymaga funkcjonalnych dla produktu:

Reguła pomocna przy sprawdzaniu kompletnoci wymaga opiera si na wynikajcych z da-nych zgromadzoda-nych przez ISBSG proporcjach wystpujcych pomidzy liczb nieskorygowada-nych punktów funkcyjnych dla poszczególnych rodzajów komponentów funkcjonalnych metody IFPUG (por. p. 1). Przedstawiaj si one nastpujco [19, s. 7]: wewntrzne pliki logiczne - 24%, ze-wntrzne pliki komunikacyjne - 8%, zeze-wntrzne wejcia - 29%, zeze-wntrzne wyjcia - 24% oraz zewntrzne zapytania - 15%. Naley odnotowa, i rednie proporcje ww. komponentów funkcjo-nalnych pozostaj stosunkowo stabilne od kilkunastu lat [19, s. 6]. Znaczne odchylenia od nich mog wskazywa na niekompletno zbioru poszczególnych komponentów, co powinno prowadzi do ponownego przeledzenia wymaga funkcjonalnych uytkownika.

2. Wczesnej estymacji rozmiaru funkcjonalnego produktu:

Na bazie wyej wymienionych proporcji istnieje równie moliwo wstpnego oszacowania rozmiaru funkcjonalnego produktu w NPF IFPUG w pocztkowych fazach jego cyklu ycia - s to tzw. obliczenia FP0 (ang. Function Points Zero). To za pozwala na orientacyjn estymacj praco-chłonnoci, kosztów osobowych i czasu realizacji przedsiwzicia. Oceny te maj charakter przy-bliony, jednak praktyka dowodzi ich przydatnoci na wczesnym etapie projektu [19, s. 10-11]. Orientacyjny rozmiar funkcjonalny produktu uzyskuje si na bazie nastpujcej zalenoci:

),

4

,

7

(

4

_×

_×

=

LPW

NPF

NPF – rozmiar funkcjonalny produktu wyraony w liczbie NPF metody IFPUG; LPW – liczba wewntrznych plików logicznych metody IFPUG;

7,4 – rednia liczba NPF dla wewntrznego pliku logicznego;

(LPW × 7,4) – liczba NPF dla wszystkich wewntrznych plików logicznych.

Do tak uzyskanego wyniku zaleca si dodanie 20-30% jego wartoci w celu uwzgldnienia funkcjonalnoci zwykle pomijanej na etapie wstpnej koncepcji w cyklu ycia przedsiwzicia.

Nierzadko do estymacji rozmiaru funkcjonalnego stosowana jest równie tzw. „zasada trzy-dziestu”. Zgodnie z ni jeden wewntrzny plik logiczny daje w rezultacie „trzydzieci kilka” (31-35) NPF IFPUG, przy czym zakłada si błd szacunku na poziomie ±30%.

3. Wczesnej estymacji pracochłonnoci przedsiwzicia:

Reguł t zaprezentowano w tabeli 1. Wymaga ona jednak nastpujcych komentarzy ([8, s. 2-4, 6-7], [19, s. 11]):

• Istnieje moliwo uzyskania wikszej trafnoci szacunków poprzez uwzgldnienie powyej przedstawionych kryteriów klasyfikacji przedsiwzi wykorzystywanych w repozytorium ISBSG, np. typu aplikacji, typu organizacji, obszaru biznesowego, jzyka programowania. • ISBSG bierze pod uwag moliwo wyznaczenia orientacyjnej oceny ex ante pracochłonnoci

przy wykorzystaniu jedynie rozmiaru funkcjonalnego produktu lub wraz z maksymaln liczeb-noci zespołu projektowego - w oparciu o równania regresji wyprowadzone dla platformy im-plementacji, jzyka oraz dla kombinacji tych i innych charakterystyk.

• W celu wyznaczenia pracochłonnoci uwzgldniajcej nie tylko nakłady pracy zespołu projek-towego, ale równie personelu wspomagajcego (np. administratorów) i uytkownika, mona wykorzysta podział nakładów pracy pomidzy te grupy uczestników przedsiwzi - kształtuje si on nastpujco: projektanci – 67%, personel wspomagajcy – 14%, natomiast uytkownicy – 19%.

4. Wczesnej estymacji kosztów osobowych przedsiwzicia:

Na podstawie oszacowanych nakładów pracy wyznacza si przyblione koszty osobowe przedsiwzicia, mnoc pracochłonno przez koszt osobomiesica (osobodnia, osobogodziny) pracy, co z kolei pozwala na estymacj całkowitych kosztów projektu. Zgodnie z jednym z rapor-tów ISBSG [9, s. 2-3]:

• Rozpito kosztów jednostkowych mierzonych w stosunku do jednostki czasu pracy wynosi od 60 do 105 USD za godzin pracy ze redni ok. 80 USD na 1 godzin.

• Rozpito kosztów jednostkowych mierzonych w stosunku do jednostki rozmiaru funkcjonal-nego produktu wynosi od 300 do 1000 USD za 1 NPF IFPUG ze redni ok. 750 USD na 1 NPF. S to koszty mierzone z uwzgldnieniem zespołu projektowego i personelu

wspomagaj-cego. Dla przykładowych rodzajów aplikacji kształtuj si one przecitnie nastpujco: aplika-cje webowe i do zarzdzania treci - 800 USD na 1 NPF, aplikaaplika-cje CRM i administracyjne – 400 USD na 1 NPF, generatory raportów – 200 USD na 1 NPF.

• Mediana PDR (ang. Project Delivery Rate), czyli warto rodkowa liczby osobogodzin pracy brutto niezbdnej do dostarczenia 1 NPF IFPUG, wynosi dla zespołu projektowego ok. 11 oso-bogodzin na 1 NPF, przy uwzgldnieniu pracowników wspomagajcych jest ona nieco wik-sza4_.

5. Wczesnej estymacji czasu realizacji przedsiwzicia:

Jeeli nie jest jeszcze znana technologia realizacji przedsiwzicia, orientacyjny czas jego trwania uzyskuje si na bazie nastpujcej zalenoci [8, s. 5]:

37 , 0

38

,

0

NP

C

=

×

C - czas realizacji przedsiwzicia (w miesicach kalendarzowych), NPzp – nakłady pracy zespołu projektowego.

Jeeli natomiast ta technologia jest ju znana, to przybliony czas realizacji przedsi-wzicia wyprowadza si w oparciu o nastpujce zalenoci [19, aneks 3]:

• dla jzyków trzeciej generacji:

C

=

0

,

971

×

NPF

;

C

=

0

,

622

×

NPF

;

C

=

1

,

472

×

NPF

.

Wykorzystujc powyej przedstawione zalenoci naley mie na uwadze, e dane zgroma-dzone przez ISBSG s reprezentatywne raczej dla przedsiwzi ponadprzecitnych, co wynika z nastpujcych przyczyn:

• kryteria gromadzenia danych w repozytorium ISBSG uwzgldniaj tylko te organizacje, które wykorzystuj metody FSM, a takie organizacje s przypuszczalnie bardziej dojrzałe od innych, jako e realizuj programy dotyczce wdroenia miar oprogramowania;

• organizacje same wybieraj projekty, o których dane przekazuj do repozytorium ISBSG – mog to by zarówno przedsiwzicia dla nich typowe, jak i te o najlepszych parametrach; • w repozytorium ISBSG nie ma wielu danych o rzeczywicie duych przedsiwziciach rozwoju

SOWZ.

Z bada T.C. Jonesa wynika, e w praktyce realizacji przedsiwzi rozwoju SOWZ sukces osigaj te organizacje, które posiadaj na tyle dojrzałe standardy zarzdzania projektami, e daj si one w pewnej czci zautomatyzowa [14]. Dowodzi on mianowicie, e wiele przedsiwzi przekraczajcych zaplanowane koszty i/lub czas realizacji jest tworzonych przy zbyt optymistycz-nych, sporzdzanych rcznie przewidywaniach. Przedsiwzicia, przy których wykorzystuje si narzdzia estymacji oparte na powszechnie przyjtych standardach i danych historycznych, charak-teryzuj si lepszymi osigniciami: czciej mieszcz si w budecie, nie maj te zbyt duych

4

Mediana stanowi w tym przypadku wartoĞü bardziej wiarygodną niĪ Ğrednia arytmetyczna, jako Īe unika siĊ w ten sposób wpływu kilku nietypowych projektów. PDR zaleĪy oczywiĞcie od wielu czynników (w repozyto-rium ISBSG wymienia siĊ ich niemal 50), w tym m.in. od: rodzaju organizacji, dziedziny zastosowania, jĊzyka programowania, platformy implementacji. Istnieje zatem moĪliwoĞü wyboru PDR najbardziej dopasowanego do charakterystyk danego przedsiĊwziĊcia.

i czstych opónie. W procesie realizacji przedsiwzi rozwoju SOWZ wystpuj wszak tysice czynników, które determinuj rezultat tego procesu, a których kombinacji nie s w stanie uwzgld-ni proste algorytmy, właciwe dla przewidywa manualnych. Wykorzystywane w celu estymacji narzdzia maj natomiast moliwo dynamicznego wspomagania przez cały czas realizacji przed-siwzicia ponownego szacowania harmonogramów i kosztów, co ma szczególne znaczenie przy długotrwałym cyklu projektowym.

Na przełomie lat 80. i 90. cały rynek narzdzi słucych do wspomagania szacowania kluczo-wych atrybutów przedsiwzi rozwoju SOWZ miał jedynie kilku sprzedawców. Obecnie ocenia si, e istnieje ok. 80. dostawców takich rozwiza. Przykładowo, ISBSG oferuje narzdzie Early Estimate Checker, za pomoc którego mona dokona wczesnej estymacji pracochłonnoci i czasu realizacji przedsiwzicia przy uwzgldnieniu platformy sprztowej, jzyka programowania, typu przedsiwzicia (budowa, doskonalenie) oraz rozmiaru funkcjonalnego produktu wyraonego w PF IFPUG. W wyniku jego zastosowania otrzymuje si zakres ocen estymacyjnych w oparciu o dane dotyczce podobnych projektów realizowanych w przeszłoci. Z kolei ISBSG Reality Check to narzdzie pozwalajce na porównywanie proponowanych ocen estymacyjnych z rezulta-tami uzyskanymi w podobnych zakoczonych przedsiwziciach, co umoliwia zweryfikowanie stopnia prawdopodobiestwa szacunków co do pracochłonnoci i czasu realizacji, dziki czemu ocenia si szans powodzenia lub ryzyko przedsiwzicia. Do innych przykładowych narzdzi, które wspomagaj szacowanie przedsiwzi rozwoju SOWZ przy wykorzystaniu rozmiaru funk-cjonalnego uzyskanego za pomoc metody IFPUG zalicza si: Function Point WORKBENCH, Software Metrics Manager, PQMPlus, SPR KnowledgePLAN, SCOPE Project Sizing Software i inne. Obecnie certyfikowane przez IFPUG s tylko trzy pierwsze z wymienionych rozwiza5. 4. UĪytecznoĞü uogólnionych danych historycznych dla wymiarowania funkcjonalnego

przedsiĊwziĊü rozwoju SOWZ

Repozytoria z uogólnionymi danymi historycznymi maj słuy wspomaganiu procesu decy-zyjnego w obszarze inynierii oprogramowania na bazie obiektywnych wyników analiz, a w rezultacie wspiera przede wszystkim [19, s. 3-4]:

• Właciwe planowanie przedsiwzicia rozwoju SOWZ, dziki m.in.:

- weryfikacji kompletnoci wymaga funkcjonalnych uytkownika wobec produktu;

- wczesnej i wiarygodnej estymacji rozmiaru produktu, pracochłonnoci, kosztów i czasu re-alizacji przedsiwzicia;

- wyznaczeniu takiego rozmiaru produktu przedsiwzicia, aby istniała moliwo terminowej jego realizacji bez przekroczenia budetu;

- okreleniu optymalnej liczebnoci zespołu projektowego;

- znalezieniu równowagi midzy atrybutami przedsiwzicia z uwzgldnieniem priorytetów (np. jako versus produktywno);

- ocenie opcji outsourcingu;

- wyznaczeniu komponentów rodowiska projektu;

- ustaleniu wpływu na przedsiwzicie przyjtych narzdzi i metod projektowania;

- wycenie unikalnego, rozwijanego na indywidualne zamówienie uytkownika produktu przedsiwzicia;

- właciwemu zarzdzaniu ryzykiem przedsiwzicia poprzez weryfikacj wiarygodnoci ocen estymacyjnych dla jego atrybutów oraz wczesn i wiarygodn ich kontrol w trakcie jego trwania.

• Rozwój organizacji zajmujcych si projektowaniem, dziki m.in.:

- moliwoci porównywania charakterystyk właciwych dla danej organizacji z charaktery-stykami w organizacjach o podobnym profilu działalnoci;

- umoliwieniu konstrukcji organizacyjnej, opartej na własnych dowiadczeniach bazy z da-nymi o produktywnoci działa projektowych;

- sprzyjaniu wzrostowi produktywnoci;

- sprzyjaniu skróceniu czasu rozwoju i wprowadzania na rynek nowych produktów.

Powyej przedstawione ogólne reguły praktyczne wyprowadzone przez ISBSG s przydatne do wyznaczania orientacyjnych wartoci kluczowych atrybutów przedsiwzicia rozwoju SOWZ we wstpnych fazach jego cyklu ycia przede wszystkim w celu stwierdzenia moliwoci jego realizacji przy ograniczonych zasobach. To z kolei sprzyja właciwym decyzjom inwestycyjnym: rezygnacji z tych przedsiwzi, dla których szansa zakoczenia przy okrelonych zasobach jest nikła, lub korekcie przeznaczonych na nie zasobów w taki sposób, aby były one jak najblisze moliwym do osignicia wartociom. W ten sposób stosowanie zasad wstpnej estymacji, zbudo-wanych na bazie uogólnionych danych historycznych, przyczynia si do zwikszenia skutecznoci realizacji rozwaanych kategorii przedsiwzi, która - jak pokazuj liczne badania - w przypadku SOWZ jest wyjtkowo niska w zestawieniu z innymi kategoriami produktów programowych ([18], [21]).

Narzdzia wspomagajce wymiarowanie funkcjonalne przedsiwzi rozwoju SOWZ umoli-wiaj zazwyczaj dodatkowo:

• konwersj wyników uzyskanych według starszych wersji metod FSM na rezultaty zgodne z aktualnie obowizujcymi wersjami, jak równie miedzy rónymi metodami FSM, czasami take midzy rozmiarem funkcjonalnym a liczb linii kodu ródłowego w zalenoci od jzyka programowania;

• gromadzenie, aktualizowanie i analizowanie oblicze, znaczco przy tym przypieszajc nie tylko same obliczenia, ale take analizowanie ich rezultatów oraz oferujc pomoc w formie udokumentowanych reguł obliczeniowych;

• realizacj oblicze na rónych poziomach struktury podziału pracy: na poziomie fazy, czynno-ci i zadania;

• porównywanie oblicze uzyskanych w rónych fazach projektowania, co ułatwia zarzdzanie przyrostem zakresu przedsiwzicia;

• konstruowanie szczegółowych planów zada, wykorzystania zasobów oraz harmonogramowa-nie przedsiwzicia;

• realizacj oblicze na rónych poziomach hierarchii funkcji dla produktu, tj. dla całej aplikacji lub dla jej fragmentów;

• wyznaczenie atrybutów przy uwzgldnieniu celów, charakterystyk i ogranicze dla przedsi-wzicia zdefiniowanych przez uytkownika, np. w taki sposób, aby w kontekcie jego prioryte-tów zrównoway zasoby z moliw do dostarczenia funkcjonalnoci czy wymagania jako-ciowe z wymaganiami dotyczcymi produktywnoci;

• kalibracj szacunków ze wzgldu na róne domeny funkcjonalne produktów przedsiwzicia, róne kategorie projektów (budowa, doskonalenie, kastomizacja, utrzymanie), a take ze wzgldu na takie czynniki, jak urlopy, nadgodziny, zarobki etc.;

• pomiar i estymacj wydajnoci pracy zespołów projektowych, stopy błdów i szybkoci dostar-czania;

• wykorzystywanie danych historycznych z innych narzdzi zarzdzania projektami;

• raportowanie na rónym poziomie szczegółowoci: poczwszy od przegldania oblicze, poprzez informacje o komponentach funkcjonalnych, a skoczywszy na ogólnych podsumowa-niach skierowanych dla osób zarzdzajcych.

adne z oferowanych na rynku narzdzi nie jest idealne. Jednak dziki takim rozwizaniom mona otrzyma oceny szacunkowe, których błd nie przekracza kilku-kilkunastu procent. Narz-dzia wspomagajce szacowanie atrybutów przedsiwzi rozwoju SOWZ pozwalaj bowiem unikn błdów ludzkich prowadzcych do nietrafnych rezultatów, s zdecydowanie szybsze od manualnych metod estymacji, a przez to take bardziej efektywne. Wiksza powszechno ich wykorzystania powinna przynie efekty znaczco zwikszajce skal skutecznoci realizacji tego typu przedsiwzi.

6. Uwagi koĔcowe

Celem gromadzenia i analizy danych historycznych o przedsiwziciach informatycznych jest przede wszystkim odkrycie i zrozumienie prawidłowoci obowizujcych w odniesieniu do ró-nych rodzajów tego typu przedsiwzi. Takie repozytoria, jak zaprezentowane powyej repozyto-rium ISBSG, czy te zasoby danych, na bazie których Software Productivity Research opracowuje cyklicznie ogólne zasady szacowania [15], podobnie jak narzdzia wspomagajce wymiarowanie funkcjonalne przedsiwzi w oparciu o takie dane niewtpliwie ów cel przybliaj.

Dane historyczne gromadzone w tego typu repozytoriach słu opracowywaniu zalenoci o charakterze ogólnym, które wprawdzie nie s wystarczajce do formalnej wyceny produktów, wymagaj sporej dozy ostronoci przy ich wykorzystywaniu i wiadomoci, e stanowi one odzwierciedlenie zalenoci wystpujcych w grupie przedsiwzi o okrelonej specyfice, a dostosowanie ich do innej specyfiki nie jest zadaniem prostym, to jednak s uyteczne w sytuacji braku własnych organizacyjnych danych historycznych. wiadcz o tym m.in. rezultaty bada przeprowadzonych przez autork wród polskich wykonawców (wewntrznych i zewntrznych) dedykowanych systemów oprogramowania wspomagajcych zarzdzanie, z których odnonie analizowanego w artykule zagadnienia wynika, e [2]:

• Zasadnicz przyczyn stosowania metody IFPUG wraz z obcionymi duym ryzykiem meto-dami eksperckimi (dotyczy to ponad połowy wykonawców deklarujcych stosowanie metody IFPUG) stanowi brak jak dotd wystarczajcych zasobów odpowiednich własnych danych hi-storycznych, które pozwoliłyby na wyprowadzenie właciwych dla organizacji zalenoci. • W przypadku stosowania obu powyszych metod do estymacji pracochłonnoci wykorzystuje

si zatem zwykle ogólne dane historyczne, czasami skorygowane o standardowe czynniki wpływajce na pracochłonno (poziom niskiego dostosowania). Takie podejcie jest zazwy-czaj uwaane za wystarzazwy-czajce w przypadku koniecznoci rozstrzygnicia istotnych rozbieno-ci w ocenach ekspertów lub wymaganego przez klienta uzasadnienia rezultatów szacowania. • Kilku dostawców zadeklarowało równie wykorzystywanie własnych danych historycznych,

(redni poziom dostosowania). W badaniu nie stwierdzono natomiast adnego przypadku wy-sokiego poziomu dostosowania sposobu estymacji pracochłonnoci do specyfiki organizacji, tj. takiego, przy którym wyprowadza si własne równanie regresji. Oprócz braku wystarczajcych zasobów odpowiednich organizacyjnych danych historycznych, wynika to równie z postrzega-nia pracochłonnoci takiego podejcia jako nadmiernej w stosunku do moliwych korzyci. • Jedn z zasadniczych zalet stanowicych rezultat wykorzystywania metody IFPUG jest

moli-wo korzystania dziki tej metodzie z wiedzy i dowiadczenia spoza organizacji, tj. włanie z uogólnionych danych historycznych i wyprowadzonych na ich podstawie modeli ekstrapolacji parametrycznej, a take moliwo odniesienia uzyskanych w oparciu o ni wyników szacowa-nia do zestawie zewntrznych, co stanowi istotny argument w negocjacjach z klientem.

Jednake wród dostawców deklarujcych znajomo metody IFPUG jednym z głównych po-wodów zaniechania jej wykorzystywania jest brak odpowiednich organizacyjnych danych histo-rycznych i jednoczenie brak zaufania do danych ogólnych. To włanie głównie uytkownicy metody IFPUG widz potrzeb gromadzenia odpowiednich własnych danych organizacyjnych, chocia wikszo z nich jeszcze nie dysponuje wystarczajcym w ich ocenie zbiorem takich danych.

Bibliografia

1. Abran A., Robillard P.N.: Reliability of Function Points Productivity Models for Enhancement Projects (A Field Study), Conference on Software Maintenance 1993-CSM-93, Montreal, IEEE Computer Society Press, Los Alamitos 191993-CSM-93, s. 80-97.

2. Czarnacka-Chrobot B.: Usage of the software Projects Scope Estimation Methods by Polish MIS Providers. In: Information Management, B. Kubiak (ed.), The 9th International Conference on Information Management, Gdask University Press, Gdask 2009 (w druku).

3. Czarnacka-Chrobot B.: Wiarygodno metod szacowania pracochłonnoci przedsiwzi rozwoju systemów oprogramowania wspomagajcych zarzdzanie. W: Informatyka Ekonomiczna. Informatyka w zarzdzaniu, „Prace Naukowe Uniwersytetu Ekonomicznego we Wrocławiu”, Wrocław 2009 (w druku).

4. Czarnacka-Chrobot B., Kobyliski A.: Ocena miar zakresu produktu programowego, "Prace Naukowe Uniwersytetu Ekonomicznego we Wrocławiu", Wrocław 2009 (w druku).

5. Hill P.R.: Some practical uses of the ISBSG history data to improve Project Management, ISBSG, Hawthorn VIC, Australia, 2007.

6. International Function Point Users Group: IFPUG Function Point Counting Practices Manual, Release 4.2, Part 1-4, IFPUG, Princeton Junction, NJ, January 2004.

7. International Software Benchmarking Standards Group: Release 10 Repository Demographics, ISBSG, Hawthorn VIC, Australia, January 2007.

8. International Software Benchmarking Standards Group: The ISBSG Special Analysis Report: Early Lifecycle Software Estimation, ISBSG, Hawthorn VIC, Australia, September 2005.

9. International Software Benchmarking Standards Group: The ISBSG Special Analysis Report: Software Project Costs, ISBSG, Hawthorn VIC, Australia, June 2005.

10. ISO/IEC 14143 Information Technology – Software measurement – Functional size measurement – Part 1-6, ISO, Geneva 1998-2007.

11. ISO/IEC 15939:2007 Systems and software engineering - Measurement process, ISO, Geneva 2007.

12. ISO/IEC 20926:2003 Software engineering - IFPUG 4.1 Unadjusted functional size measurement method - Counting practices manual, ISO, Geneva 2003.

13. Jiang Z., Jiang B., Naudé P.: The Effects of Software Size on Development Effort and Software Quality. In: International Journal of Computer and Information Science and Engineering, vol. 1, no. 4, 2007, s. 230-234.

14. Jones T.C.: Software Cost Estimating Methods for Large Projects. In: CrossTalk. The Journal of Defence Software Engineering, April 2005, s. 8-12.

15. Jones T.C.: Software Estimating Rules of Thumb, Version 3, Software Productivity Research, Burlington 2007.

16. Jørgensen M.: Estimation of Software Development Work Effort: Evidence on Expert Judgment and Formal Models. In: International Journal of Forecasting, 23(3), 2007, s. 449-462.

17. Kasunic M.: The State of Software Measurement Practice: Results of 2006 Survey, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, December 2006. 18. Panorama Consulting Group: 2008 ERP Report, Topline Results, Denver, 2008.

19. Practical Project Estimation (2nd edition): A Toolkit for Estimating Software Development Effort and Duration, P.R. Hill (ed.), International Software Benchmarking Standards Group, Hawthorn VIC, Australia, 2005.

20. Pressman R.S.: Software Engineering: A Practitioner’s Approach, 6th Edition, McGraw-Hill Science/Engineering/Math, New York 2004.

BSS DEVELOPMENT AND ENHANCEMENT PROJECTS FUNCTIONAL MEASUREMENT ON THE BASIS OF GENERAL BENCHMARKING DATA

Summary

The author of this article made an attempt to analyse the studies’ results pre-sented in the subject literature concerning the reliability of five essential Business Software Systems (BSS) development and enhancement projects effort estimation methods. When summing up conclusions of the research it should be stated that the most reliable estimations are currently offered by extrapolation parametric models based on BSS size expressed in functionality units – especially when they are ad-justed to the organisation specificity, what requires gathering of relevant own benchmarking data. Whereas in practice the BSS providers gather such data rather sporadically. In this situation the usefulness of general benchmarking past projects data is perceived. These data serve as the basis of general extrapolation parametric models developing, indicating dependencies between work effort and product size expressed in functionality units. The biggest repository of such data currently be-longs to International Software Benchmarking Standards Group. Project estimation tools based on functional measurement offer such repositories too. In this paper the author attempts to analyse the usefulness of general benchmarking data for BSS de-velopment and enhancement projects functional measurement against a background of the main possibilities existing in that area.

Keywords: functional measurement, ISO/IEC 14143 norm, IFPUG Function Points Method, extrapolation parametric models, ISBSG benchmarking data repository, functional measurement supporting tools

Beata Czarnacka-Chrobot

Katedra Informatyki Gospodarczej Szkoła Główna Handlowa

Warszawa, Al. Niepodległoci 164 e-mail: bczarn@sgh.waw.pl