WYMIAROWANIE FUNKCJONALNE PRZEDSI WZI ROZWOJU SYSTEMÓW OPROGRAMOWANIA WSPOMAGAJ CYCH ZARZ DZANIE NA BAZIE UOGÓLNIONYCH DANYCH HISTORYCZNYCH

Transkrypt

1 WYMIAROWANIE FUNKCJONALNE PRZEDSI WZI ROZWOJU SYSTEMÓW OPROGRAMOWANIA WSPOMAGAJ CYCH ZARZ DZANIE NA BAZIE UOGÓLNIONYCH DANYCH HISTORYCZNYCH BEATA CZARNACKA-CHROBOT Szkoła Główna Handlowa w Warszawie Streszczenie Z przeprowadzonej przez autork analizy rezultatów bada dotycz cych wiarygodno ci metod szacowania pracochłonno ci przedsi wzi rozwoju systemów oprogramowania 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 przypadku 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 gromadz dane konieczne do wyprowadzenia specyficznych dla siebie zale no ci. W takiej 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 wyra 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 jednostkach funkcjonalno ci. Celem niniejszego artykułu jest próba analizy u yteczno ci uogólnionych danych historycznych dla tzw. wymiarowania funkcjonalnego przedsi 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 funkcyjnych IFPUG, modele ekstrapolacji parametrycznej, repozytorium danych historycznych ISBSG, narz dzia wspomagaj ce wymiarowanie funkcjonalne 1. Wprowadzenie Du e znaczenie poziomu trafno ci ocen estymacyjnych dla pracochłonno przedsi wzi rozwoju SOWZ wynika z faktu, e w przypadku takich przedsi wzi atrybut ten determinuje koszty i czas ich realizacji. Dokonana przez autork w pracy [3] analiza dost pnych w literaturze przedmiotu wyników kilkudziesi ciu bada nad wiarygodno ci zasadniczych metod szacowania nakładów pracy dla tego typu projektów wykazała, e obecnie najwi ksz trafno rezultatów oferuj modele ekstrapolacji parametrycznej, które s : 1) oparte na rozmiarze SOWZ wyra onym za pomoc jednostek funkcjonalno ci,

2 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 23, ) dostosowane do specyficznych organizacyjnych warunków projektowych. Podstaw dla takich modeli stanowi zatem metody tzw. wymiarowania rozmiaru funkcjonalnego (ang. Funcional Size Measurement FSM) produktu programowego, oparte na jedynej jak dot d uznanej przez mi dzynarodowe organizacje standaryzacyjne ISO (International Organization for Standardization) i IEC (International Electrotechnical Commission) koncepcji wymiarowania rozmiaru oprogramowania bazuj cej na jego funkcjonalno ci [10]. Wymiarowanie kluczowych atrybutów przedsi wzi zmierzaj cych do rozwoju systemów oprogramowania w oparciu o t znormalizowan w standardzie ISO/IEC koncepcj mo na wi c okre li mianem wymiarowania funkcjonalnego. W metodach FSM podstawow jednostk funkcjonalno ci stanowi punkt funkcyjny (PF), który słu y 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 tak e definiowania punktu funkcyjnego, uzale niony jest od wykorzystywanej metody FSM. Do wymiarowania rozmiaru funkcjonalnego produktów programowych typu SOWZ mo na wykorzystywa wszystkie znormalizowane przez ISO/IEC metody takiego wymiarowania - jest ich obecnie 5 [4], jednak zasadnicze modele parametrycznej ekstrapolacji pracochłonno ci uwzgl dniaj w przewa aj cej wi kszo ci rozmiar uzyskany przy wykorzystaniu 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 funkcjonalno ci dostarczanej u ytkownikowi 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 podej ciu proponowanym przez IFPUG metoda ta obejmuje tak e wyznaczenie tzw. czynnika koryguj cego, który ma za zadanie dostosowanie rozmiaru funkcjonalnego produktu do rodowiska konkretnego przedsi wzi cia poprzez uwzgl dnienie wpływu wymaga technicznych i jako ciowych na proces projektowania i implementacji aplikacji. Ogólnie rzecz ujmuj c, po pomno eniu liczby NPF przez ten czynnik uzyskuje si ko cowy rezultat metody IFPUG, czyli liczb skorygowanych punktów funkcyjnych (SPF - ang. adjusted function points), wyra aj c ostateczny rozmiar oprogramowania. Jednak e ta cz metody IFPUG nie posiada aprobaty ISO i IEC - przyj te przez te organizacje zało enia wykluczaj bowiem zale no FSM od wymaga jako ciowych i technicznych. Odpowiedni liczb NPF IFPUG przypisuje si funkcjom i danym niezb dnym do ich realizacji - w zale no ci od ich rodzaju i poziomu zło ono ci. Uwzgl dniane w obliczeniach komponenty funkcjonalne to: wewn trzne pliki logiczne (dane utrzymywane przez wymiarowan aplikacj ), zewn trzne pliki komunikacyjne (dane wykorzystywane przez wymiarowan aplikacj, ale utrzymywane poza ni ) oraz procesy elementarne (funkcje, transakcje), dzi ki którym przetwarzane przez nie dane przekraczaj wyznaczone granice aplikacji, do których nale : zewn trzne wej cia, zewn trzne wyj cia i zewn trzne zapytania. Kalkulacja rozmiaru SOWZ w jednostkach funkcjonalno ci nie jest jednak warunkiem wystarczaj cym do uzyskania dostatecznie wiarygodnych ocen estymacyjnych dla pracochłonno ci przedsi wzi cia zmierzaj cego do jego rozwoju, chocia niew tpliwie silnie temu sprzyja. Ich trafno zale y tak e od poziomu dostosowania modeli ekstrapolacji parametrycznej opartych na

3 30 Wymiarowanie funkcjonalne przedsi wzi rozwoju systemów oprogramowania wspomagaj cych zarz dzanie na bazie uogólnionych danych historycznych 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 uwzgl dnienie standardowych czynników wpływaj cych na pracochłonno w powi zaniu z ró nicami wyst puj cymi mi dzy estymowanym a typowym przedsi wzi ciem (np. w przypadku korzystania po raz pierwszy z nowego narz dzia wspomagaj cego 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 warto ci produktywno ci, które zast puj standardowe czynniki wpływaj ce na pracochłonno typowego przedsi wzi cia. Poziom wysokiego dostosowania: modele estymacyjne w postaci równa regresji s wyprowadzane 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 rzeczywisto ci jak dot d wi kszo organizacji projektuj cych nie gromadzi ich w sposób rzetelny i systematyczny, niezb dny do wyprowadzenia specyficznych dla siebie zale no ci [17], co w odniesieniu do polskich wykonawców (wewn trznych i zewn trznych) dedykowanych SOWZ zostało wykazane w pracy [2]. W takim przypadku mo na albo powróci do zako czonych przedsi wzi i przy posiadaniu odpowiedniej dokumentacji wyprowadzi potrzebne zale no ci 1, albo odwoła si - nie zapominaj c jednak o pewnej dozie ostro no ci - do uogólnionych modeli ekstrapolacji parametrycznej budowanych na podstawie danych historycznych gromadzonych w specjalnie do tego celu stworzonych repozytoriach, gdzie uwzgl dnia si, oprócz informacji o przeci tnych wielko ciach, tak e dane bardziej precyzyjne, uzale nione od specyfiki przedsi wzi cia i jego produktu. Repozytoria takie posiada ka de z narz dzi wspomagaj cych estymacj atrybutów przedsi wzi cia, oferuj je tak e organizacje zainteresowane rozwojem metod szacowania, a w ród nich na szczególn uwag zasługuje repozytorium International Software Benchmarking Standards Group (ISBSG) z danymi o ponad 5 tysi cach przedsi wzi, których produkty wymiarowane s w oparciu o metody FSM 2. W takiej sytuacji wła nie, przy braku odpowiednich organizacyjnych danych historycznych, zauwa a si u yteczno repozytoriów gromadz cych dane uogólnione, słu ce do wyprowadzenia uogólnionych modeli parametrycznej 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łonno ci przedsi wzi rozwoju SOWZ ró ni si uwzgl dnianymi czynnikami koryguj cymi, poziomem ich oddziaływania na pracochłonno, sposobem dostosowania nieliniowego wpływu wzrostu rozmiaru produktu na wielko przedsi wzi cia, ale przede wszystkim miar rozmiaru produktu jako podstawowego atrybutu wej ciowego dla takich modeli3. Zasadnicze przykładowe modele parametrycznej ekstrapolacji pracochłonno ci oparte na rozmiarze produktu przedsi wzi cia wyra onym w jednostkach funkcjonalno ci przed- 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), ( ). 3 O ró nych rodzajach miar rozmiaru produktu programowego ró nicuj cych metody parametrycznej ekstrapolacji pracochłonno ci Czytelnik znajdzie informacje w pracy [4].

4 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 23, stawiono w tabeli 1. Formuły te uzyskano empirycznie a posteriori na bazie analizy danych ze zrealizowanych przedsi wzi, wyprowadzaj c równania regresji. Słu one do estymacji warto ci oczekiwanej zmiennej obja nianej (zale nej), jak stanowi pracochłonno, przy okre lonych zmiennych obja niaj cych (niezale nych), w ród których w ka dym modelu wyst puje rozmiar produktu wyra ony w skorygowanej lub nieskorygowanej liczbie PF IFPUG. Tabela 1. Podstawowe przykładowe modele parametrycznej ekstrapolacji pracochłonno ci przedsi wzi rozwoju SOWZ oparte na rozmiarze funkcjonalnym Formuła szacowania pracochłonno ci Model (NP) Kemerera 8 3 Abrana-Robillarda NP = 60,62 7, SPF NP = 41,09 + 2, 37 SPF Parametry SPF rozmiar produktu w skorygowanych punktach funkcyjnych IFPUG Matsona-Barnetta- NP = 585,7 + 15, 12 SPF Mellichampa Jianga-Naudé a 0, 736 NP NP zp = 38,3 NPF zp nakłady pracy zespołu projektowego; NPF rozmiar produktu w nieskorygowanych punktach funkcyjnych IFPUG ISBSG E NP NP (por. tak e p. 3) zp(min) = S NPF zp(min) minimalne mo liwe do wydatkowania nakłady pracy zespołu projektowego; S stała uzale niona od rodzaju platformy NP zp(max) = NPzp (min) + W NP implementacji: zp(min) dla du ych komputerów (ang. mainframe): 51,03 dla minikomputerów: 60,51 dla PC: 33,36 dla rozwi za opartych na wielu platformach: 16,96; E wykładnik pot gi uzale niony od rodzaju platformy implementacji: dla du ych komputerów: 0,722 dla minikomputerów: 0,687 dla PC: 0,721 dla rozwi za opartych na wielu platformach: 0,864; NPF rozmiar produktu w nieskorygowanych punktach funkcyjnych IFPUG; NP zp(max) maksymalne mo liwe do wydatkowania nakłady pracy zespołu projektowego; W współczynnik koryguj cy uzale niony od platformy implementacji: dla minikomputerów: 50% dla pozostałych: 70%. ródło: Opracowanie własne na podstawie: [1, s. 83], [8, s. 1-7], [13], [20].

5 32 Wymiarowanie funkcjonalne przedsi wzi rozwoju systemów oprogramowania wspomagaj cych zarz dzanie na bazie uogólnionych danych historycznych 3. Przykładowe repozytoria danych historycznych dla przedsi wzi rozwoju SOWZ ISBSG to organizacja non-profit zało ona w drugiej połowie lat 90. ubiegłego wieku w celu doskonalenia procesów zarz dzania zasobami informatycznymi zarówno w podmiotach gospodarczych, jak i w instytucjach administracji publicznej [5, s. 2]. Zadanie to realizuje poprzez utrzymywanie, rozwijanie i wykorzystywanie trzech rodzajów repozytoriów z danymi historycznymi: jedno z nich, najwi ksze, obejmuje dane dla przedsi wzi informatycznych polegaj cych na budowie i doskonaleniu systemów oprogramowania, drugie - dane dla aplikacji wspomagaj cych i utrzymywania oprogramowania, trzecie natomiast dane dotycz ce nabywania i wdra ania gotowych pakietów oprogramowania. Repozytoria te s znormalizowane zgodnie ze standardem ISO/IEC [11], zweryfikowane i reprezentatywne dla obecnej technologii. Dane zgromadzone w repozytorium przeznaczonym dla przedsi wzi polegaj cych na budowie i doskonaleniu systemów oprogramowania pochodz z ponad pi ciu tysi cy projektów zrealizowanych w ponad 25 krajach, a przewa aj ca wi kszo z nich nie jest starsza ni 7 lat. Dotycz one wielu bran i obszarów biznesowych. Dane te klasyfikuje si ze wzgl du na nast puj ce kryteria [7]: kraj, w którym podj to przedsi wzi cie; kontekst przedsi wzi cia, w tym: rodzaj organizacji (bran a) oraz obszar biznesowy; typ przedsi wzi cia, w tym: rodzaj działa (budowa, doskonalenie), przeznaczenie projektu (wewn trzne, zewn trzne) oraz liczebno zespołu projektowego; typ produktu, w tym: typ aplikacji (np. SOWZ) oraz rozmiar funkcjonalny produktu, który w przewa aj cej wi kszo ci jest wyra ony w NPF IFPUG (ok. 85% przypadków); rodowisko realizacyjne, w tym: j zyk programowania oraz platforma sprz towa; stosowane metody i narz dzia projektowania. Na bazie danych o takich przedsi wzi ciach ISBSG tworzy cykliczne raporty analityczne, dotycz ce m.in.: planowania przedsi wzi, ich kosztów, czynników determinuj cych produktywno, wpływu narz dzi i technik projektowania oraz liczebno ci zespołu projektowego na produktywno, wiarygodno ci metod estymacji atrybutów przedsi wzi oraz wczesnego ich szacowania. Z perspektywy podj tej w niniejszym artykule problematyki to ostatnie zagadnienie zasługuje na szczególn uwag. W wyniku analizy danych dotycz cych przedsi wzi budowy i doskonalenia systemów oprogramowania wyprowadzono wiele reguł przydatnych w praktyce do wst pnej estymacji kluczowych atrybutów przedsi wzi rozwoju SOWZ (tzw. rules of thumb). W ród nich na szczególn uwag zasługuj przede wszystkim zale no ci dotycz ce: 1. Weryfikacji kompletno ci wymaga funkcjonalnych dla produktu: Reguła pomocna przy sprawdzaniu kompletno ci wymaga opiera si na wynikaj cych z danych zgromadzonych przez ISBSG proporcjach wyst puj cych pomi dzy liczb nieskorygowanych punktów funkcyjnych dla poszczególnych rodzajów komponentów funkcjonalnych metody IFPUG (por. p. 1). Przedstawiaj si one nast puj co [19, s. 7]: wewn trzne pliki logiczne - 24%, zewn trzne pliki komunikacyjne - 8%, zewn trzne wej cia - 29%, zewn trzne wyj cia - 24% oraz zewn trzne zapytania - 15%. Nale y odnotowa, i rednie proporcje ww. komponentów funkcjonalnych 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 prze ledzenia wymaga funkcjonalnych u ytkownika.

6 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 23, Wczesnej estymacji rozmiaru funkcjonalnego produktu: Na bazie wy ej wymienionych proporcji istnieje równie mo liwo wst pnego oszacowania rozmiaru funkcjonalnego produktu w NPF IFPUG w pocz tkowych fazach jego cyklu ycia - s to tzw. obliczenia FP0 (ang. Function Points Zero). To za pozwala na orientacyjn estymacj pracochłonno ci, kosztów osobowych i czasu realizacji przedsi wzi cia. Oceny te maj charakter przybli ony, jednak praktyka dowodzi ich przydatno ci na wczesnym etapie projektu [19, s ]. Orientacyjny rozmiar funkcjonalny produktu uzyskuje si na bazie nast puj cej zale no ci: NPF = 4 ( LPW 7,4), gdzie: NPF rozmiar funkcjonalny produktu wyra ony w liczbie NPF metody IFPUG; LPW liczba wewn trznych plików logicznych metody IFPUG; 7,4 rednia liczba NPF dla wewn trznego pliku logicznego; (LPW 7,4) liczba NPF dla wszystkich wewn trznych plików logicznych. Do tak uzyskanego wyniku zaleca si dodanie 20-30% jego warto ci w celu uwzgl dnienia funkcjonalno ci zwykle pomijanej na etapie wst pnej koncepcji w cyklu ycia przedsi wzi cia. Nierzadko do estymacji rozmiaru funkcjonalnego stosowana jest równie tzw. zasada trzydziestu. Zgodnie z ni jeden wewn trzny plik logiczny daje w rezultacie trzydzie ci kilka (31-35) NPF IFPUG, przy czym zakłada si bł d szacunku na poziomie ±30%. 3. Wczesnej estymacji pracochłonno ci przedsi wzi cia: Reguł t zaprezentowano w tabeli 1. Wymaga ona jednak nast puj cych komentarzy ([8, s. 2-4, 6-7], [19, s. 11]): Istnieje mo liwo uzyskania wi kszej trafno ci szacunków poprzez uwzgl dnienie powy ej przedstawionych kryteriów klasyfikacji przedsi wzi wykorzystywanych w repozytorium ISBSG, np. typu aplikacji, typu organizacji, obszaru biznesowego, j zyka programowania. ISBSG bierze pod uwag mo liwo wyznaczenia orientacyjnej oceny ex ante pracochłonno ci przy wykorzystaniu jedynie rozmiaru funkcjonalnego produktu lub wraz z maksymaln liczebno ci zespołu projektowego - w oparciu o równania regresji wyprowadzone dla platformy implementacji, j zyka oraz dla kombinacji tych i innych charakterystyk. W celu wyznaczenia pracochłonno ci uwzgl dniaj cej nie tylko nakłady pracy zespołu projektowego, ale równie personelu wspomagaj cego (np. administratorów) i u ytkownika, mo na wykorzysta podział nakładów pracy pomi dzy te grupy uczestników przedsi wzi - kształtuje si on nast puj co: projektanci 67%, personel wspomagaj cy 14%, natomiast u ytkownicy 19%. 4. Wczesnej estymacji kosztów osobowych przedsi wzi cia: Na podstawie oszacowanych nakładów pracy wyznacza si przybli one koszty osobowe przedsi wzi cia, mno c pracochłonno przez koszt osobomiesi ca (osobodnia, osobogodziny) pracy, co z kolei pozwala na estymacj całkowitych kosztów projektu. Zgodnie z jednym z raportów ISBSG [9, s. 2-3]: Rozpi to 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. Rozpi to kosztów jednostkowych mierzonych w stosunku do jednostki rozmiaru funkcjonalnego produktu wynosi od 300 do 1000 USD za 1 NPF IFPUG ze redni ok. 750 USD na 1 NPF. S to koszty mierzone z uwzgl dnieniem zespołu projektowego i personelu wspomagaj -

7 34 Wymiarowanie funkcjonalne przedsi wzi rozwoju systemów oprogramowania wspomagaj cych zarz dzanie na bazie uogólnionych danych historycznych cego. Dla przykładowych rodzajów aplikacji kształtuj si one przeci tnie nast puj co: aplikacje webowe i do zarz dzania tre ci USD na 1 NPF, aplikacje 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 niezb dnej do dostarczenia 1 NPF IFPUG, wynosi dla zespołu projektowego ok. 11 osobogodzin na 1 NPF, przy uwzgl dnieniu pracowników wspomagaj cych jest ona nieco wi ksza Wczesnej estymacji czasu realizacji przedsi wzi cia: Je eli nie jest jeszcze znana technologia realizacji przedsi wzi cia, orientacyjny czas jego trwania uzyskuje si na bazie nast puj cej zale no ci [8, s. 5]: 0,37 0,38 zp C = NP gdzie: C - czas realizacji przedsi wzi cia (w miesi cach kalendarzowych), NP zp nakłady pracy zespołu projektowego. Je eli natomiast ta technologia jest ju znana, to przybli ony czas realizacji przedsi wzi cia wyprowadza si w oparciu o nast puj ce zale no ci [19, aneks 3]: 0,351 dla j zyków trzeciej generacji: C = 0,971 NPF ; 0,405 dla j zyków czwartej generacji: C = 0,622 NPF ; 0,280 dla generatorów aplikacji: C = 1,472 NPF. Wykorzystuj c powy ej przedstawione zale no ci nale y mie na uwadze, e dane zgromadzone przez ISBSG s reprezentatywne raczej dla przedsi wzi ponadprzeci tnych, co wynika z nast puj cych przyczyn: kryteria gromadzenia danych w repozytorium ISBSG uwzgl dniaj tylko te organizacje, które wykorzystuj metody FSM, a takie organizacje s przypuszczalnie bardziej dojrzałe od innych, jako e realizuj programy dotycz ce wdro enia miar oprogramowania; organizacje same wybieraj projekty, o których dane przekazuj do repozytorium ISBSG mog to by zarówno przedsi wzi cia dla nich typowe, jak i te o najlepszych parametrach; w repozytorium ISBSG nie ma wielu danych o rzeczywi cie du ych przedsi wzi ciach rozwoju SOWZ. Z bada T.C. Jonesa wynika, e w praktyce realizacji przedsi wzi rozwoju SOWZ sukces osi gaj te organizacje, które posiadaj na tyle dojrzałe standardy zarz dzania projektami, e daj si one w pewnej cz ci zautomatyzowa [14]. Dowodzi on mianowicie, e wiele przedsi wzi przekraczaj cych zaplanowane koszty i/lub czas realizacji jest tworzonych przy zbyt optymistycznych, sporz dzanych r cznie przewidywaniach. Przedsi wzi cia, przy których wykorzystuje si narz dzia estymacji oparte na powszechnie przyj tych standardach i danych historycznych, charakteryzuj si lepszymi osi gni ciami: cz ciej mieszcz si w bud ecie, nie maj te zbyt du ych 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 repozytorium 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.

8 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 23, i cz stych opó nie. W procesie realizacji przedsi wzi rozwoju SOWZ wyst puj wszak tysi ce czynników, które determinuj rezultat tego procesu, a których kombinacji nie s w stanie uwzgl dni proste algorytmy, wła ciwe dla przewidywa manualnych. Wykorzystywane w celu estymacji narz dzia maj natomiast mo liwo dynamicznego wspomagania przez cały czas realizacji przedsi wzi cia 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 narz dzi słu cych do wspomagania szacowania kluczowych atrybutów przedsi wzi rozwoju SOWZ miał jedynie kilku sprzedawców. Obecnie ocenia si, e istnieje ok. 80. dostawców takich rozwi za. Przykładowo, ISBSG oferuje narz dzie Early Estimate Checker, za pomoc którego mo na dokona wczesnej estymacji pracochłonno ci i czasu realizacji przedsi wzi cia przy uwzgl dnieniu platformy sprz towej, j zyka programowania, typu przedsi wzi cia (budowa, doskonalenie) oraz rozmiaru funkcjonalnego produktu wyra onego w PF IFPUG. W wyniku jego zastosowania otrzymuje si zakres ocen estymacyjnych w oparciu o dane dotycz ce podobnych projektów realizowanych w przeszło ci. Z kolei ISBSG Reality Check to narz dzie pozwalaj ce na porównywanie proponowanych ocen estymacyjnych z rezultatami uzyskanymi w podobnych zako czonych przedsi wzi ciach, co umo liwia zweryfikowanie stopnia prawdopodobie stwa szacunków co do pracochłonno ci i czasu realizacji, dzi ki czemu ocenia si szans powodzenia lub ryzyko przedsi wzi cia. Do innych przykładowych narz dzi, które wspomagaj szacowanie przedsi wzi rozwoju SOWZ przy wykorzystaniu rozmiaru funkcjonalnego 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 rozwi za U yteczno uogólnionych danych historycznych dla wymiarowania funkcjonalnego przedsi wzi rozwoju SOWZ Repozytoria z uogólnionymi danymi historycznymi maj słu y wspomaganiu procesu decyzyjnego w obszarze in ynierii oprogramowania na bazie obiektywnych wyników analiz, a w rezultacie wspiera przede wszystkim [19, s. 3-4]: Wła ciwe planowanie przedsi wzi cia rozwoju SOWZ, dzi ki m.in.: - weryfikacji kompletno ci wymaga funkcjonalnych u ytkownika wobec produktu; - wczesnej i wiarygodnej estymacji rozmiaru produktu, pracochłonno ci, kosztów i czasu realizacji przedsi wzi cia; - wyznaczeniu takiego rozmiaru produktu przedsi wzi cia, aby istniała mo liwo terminowej jego realizacji bez przekroczenia bud etu; - okre leniu optymalnej liczebno ci zespołu projektowego; - znalezieniu równowagi mi dzy atrybutami przedsi wzi cia z uwzgl dnieniem priorytetów (np. jako versus produktywno ); - ocenie opcji outsourcingu; - wyznaczeniu komponentów rodowiska projektu; - ustaleniu wpływu na przedsi wzi cie przyj tych narz dzi i metod projektowania; - wycenie unikalnego, rozwijanego na indywidualne zamówienie u ytkownika produktu przedsi wzi cia; 5 International Function Point Users Group (IFPUG), ( ).

9 36 Wymiarowanie funkcjonalne przedsi wzi rozwoju systemów oprogramowania wspomagaj cych zarz dzanie na bazie uogólnionych danych historycznych - wła ciwemu zarz dzaniu ryzykiem przedsi wzi cia poprzez weryfikacj wiarygodno ci ocen estymacyjnych dla jego atrybutów oraz wczesn i wiarygodn ich kontrol w trakcie jego trwania. Rozwój organizacji zajmuj cych si projektowaniem, dzi ki m.in.: - mo liwo ci porównywania charakterystyk wła ciwych dla danej organizacji z charakterystykami w organizacjach o podobnym profilu działalno ci; - umo liwieniu konstrukcji organizacyjnej, opartej na własnych do wiadczeniach bazy z danymi o produktywno ci działa projektowych; - sprzyjaniu wzrostowi produktywno ci; - sprzyjaniu skróceniu czasu rozwoju i wprowadzania na rynek nowych produktów. Powy ej przedstawione ogólne reguły praktyczne wyprowadzone przez ISBSG s przydatne do wyznaczania orientacyjnych warto ci kluczowych atrybutów przedsi wzi cia rozwoju SOWZ we wst pnych fazach jego cyklu ycia przede wszystkim w celu stwierdzenia mo liwo ci jego realizacji przy ograniczonych zasobach. To z kolei sprzyja wła ciwym decyzjom inwestycyjnym: rezygnacji z tych przedsi wzi, dla których szansa zako czenia przy okre lonych zasobach jest nikła, lub korekcie przeznaczonych na nie zasobów w taki sposób, aby były one jak najbli sze mo liwym do osi gni cia warto ciom. W ten sposób stosowanie zasad wst pnej estymacji, zbudowanych na bazie uogólnionych danych historycznych, przyczynia si do zwi kszenia skuteczno ci realizacji rozwa anych kategorii przedsi wzi, która - jak pokazuj liczne badania - w przypadku SOWZ jest wyj tkowo niska w zestawieniu z innymi kategoriami produktów programowych ([18], [21]). Narz dzia wspomagaj ce wymiarowanie funkcjonalne przedsi wzi rozwoju SOWZ umo liwiaj zazwyczaj dodatkowo: konwersj wyników uzyskanych według starszych wersji metod FSM na rezultaty zgodne z aktualnie obowi zuj cymi wersjami, jak równie miedzy ró nymi metodami FSM, czasami tak e mi dzy rozmiarem funkcjonalnym a liczb linii kodu ródłowego w zale no ci od j zyka programowania; gromadzenie, aktualizowanie i analizowanie oblicze, znacz co przy tym przy pieszaj c nie tylko same obliczenia, ale tak e analizowanie ich rezultatów oraz oferuj c 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 zarz dzanie przyrostem zakresu przedsi wzi cia; konstruowanie szczegółowych planów zada, wykorzystania zasobów oraz harmonogramowanie przedsi wzi cia; realizacj oblicze na ró nych poziomach hierarchii funkcji dla produktu, tj. dla całej aplikacji lub dla jej fragmentów; wyznaczenie atrybutów przy uwzgl dnieniu celów, charakterystyk i ogranicze dla przedsi wzi cia zdefiniowanych przez u ytkownika, np. w taki sposób, aby w kontek cie jego priorytetów zrównowa y zasoby z mo liw do dostarczenia funkcjonalno ci czy wymagania jako- ciowe z wymaganiami dotycz cymi produktywno ci; uwzgl dnienie czynników ryzyka, oferuj c pomoc w ich okre laniu i dokonuj c ich oceny;

10 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 23, kalibracj szacunków ze wzgl du na ró ne domeny funkcjonalne produktów przedsi wzi cia, ró ne kategorie projektów (budowa, doskonalenie, kastomizacja, utrzymanie), a tak e ze wzgl du na takie czynniki, jak urlopy, nadgodziny, zarobki etc.; pomiar i estymacj wydajno ci pracy zespołów projektowych, stopy bł dów i szybko ci dostarczania; wykorzystywanie danych historycznych z innych narz dzi zarz dzania projektami; raportowanie na ró nym poziomie szczegółowo ci: pocz wszy od przegl dania oblicze, poprzez informacje o komponentach funkcjonalnych, a sko czywszy na ogólnych podsumowaniach skierowanych dla osób zarz dzaj cych. adne z oferowanych na rynku narz dzi nie jest idealne. Jednak dzi ki takim rozwi zaniom mo na otrzyma oceny szacunkowe, których bł d nie przekracza kilku-kilkunastu procent. Narz dzia wspomagaj ce szacowanie atrybutów przedsi wzi rozwoju SOWZ pozwalaj bowiem unikn bł dów ludzkich prowadz cych do nietrafnych rezultatów, s zdecydowanie szybsze od manualnych metod estymacji, a przez to tak e bardziej efektywne. Wi ksza powszechno ich wykorzystania powinna przynie efekty znacz co zwi kszaj ce skal skuteczno ci realizacji tego typu przedsi wzi. 6. Uwagi ko cowe Celem gromadzenia i analizy danych historycznych o przedsi wzi ciach informatycznych jest przede wszystkim odkrycie i zrozumienie prawidłowo ci obowi zuj cych w odniesieniu do ró nych rodzajów tego typu przedsi wzi. Takie repozytoria, jak zaprezentowane powy ej repozytorium ISBSG, czy te zasoby danych, na bazie których Software Productivity Research opracowuje cyklicznie ogólne zasady szacowania [15], podobnie jak narz dzia wspomagaj ce wymiarowanie funkcjonalne przedsi wzi w oparciu o takie dane niew tpliwie ów cel przybli aj. Dane historyczne gromadzone w tego typu repozytoriach słu opracowywaniu zale no ci o charakterze ogólnym, które wprawdzie nie s wystarczaj ce do formalnej wyceny produktów, wymagaj sporej dozy ostro no ci przy ich wykorzystywaniu i wiadomo ci, e stanowi one odzwierciedlenie zale no ci wyst puj cych w grupie przedsi wzi o okre lonej specyfice, a dostosowanie ich do innej specyfiki nie jest zadaniem prostym, to jednak s u yteczne w sytuacji braku własnych organizacyjnych danych historycznych. wiadcz o tym m.in. rezultaty bada przeprowadzonych przez autork w ród polskich wykonawców (wewn trznych i zewn trznych) dedykowanych systemów oprogramowania wspomagaj cych zarz dzanie, z których odno nie analizowanego w artykule zagadnienia wynika, e [2]: Zasadnicz przyczyn stosowania metody IFPUG wraz z obci onymi du ym ryzykiem metodami eksperckimi (dotyczy to ponad połowy wykonawców deklaruj cych stosowanie metody IFPUG) stanowi brak jak dot d wystarczaj cych zasobów odpowiednich własnych danych historycznych, które pozwoliłyby na wyprowadzenie wła ciwych dla organizacji zale no ci. W przypadku stosowania obu powy szych metod do estymacji pracochłonno ci wykorzystuje si zatem zwykle ogólne dane historyczne, czasami skorygowane o standardowe czynniki wpływaj ce na pracochłonno (poziom niskiego dostosowania). Takie podej cie jest zazwyczaj uwa ane za wystarczaj ce w przypadku konieczno ci rozstrzygni cia istotnych rozbie no- 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, przy czym s one wykorzystywane w celu kalkulacji produktywno ci działa projektowych

11 38 Wymiarowanie funkcjonalne przedsi wzi rozwoju systemów oprogramowania wspomagaj cych zarz dzanie na bazie uogólnionych danych historycznych ( redni poziom dostosowania). W badaniu nie stwierdzono natomiast adnego przypadku wysokiego poziomu dostosowania sposobu estymacji pracochłonno ci do specyfiki organizacji, tj. takiego, przy którym wyprowadza si własne równanie regresji. Oprócz braku wystarczaj cych zasobów odpowiednich organizacyjnych danych historycznych, wynika to równie z postrzegania pracochłonno ci takiego podej cia jako nadmiernej w stosunku do mo liwych korzy ci. Jedn z zasadniczych zalet stanowi cych rezultat wykorzystywania metody IFPUG jest mo liwo korzystania dzi ki tej metodzie z wiedzy i do wiadczenia spoza organizacji, tj. wła nie z uogólnionych danych historycznych i wyprowadzonych na ich podstawie modeli ekstrapolacji parametrycznej, a tak e mo liwo odniesienia uzyskanych w oparciu o ni wyników szacowania do zestawie zewn trznych, co stanowi istotny argument w negocjacjach z klientem. Jednak e w ród dostawców deklaruj cych znajomo metody IFPUG jednym z głównych powodów zaniechania jej wykorzystywania jest brak odpowiednich organizacyjnych danych historycznych i jednocze nie brak zaufania do danych ogólnych. To wła nie głównie u ytkownicy metody IFPUG widz potrzeb gromadzenia odpowiednich własnych danych organizacyjnych, chocia wi kszo z nich jeszcze nie dysponuje wystarczaj cym 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 1993, s Czarnacka-Chrobot B.: Usage of the software Projects Scope Estimation Methods by Polish MIS Providers. In: Information Management, B. Kubiak (ed.), The 9 th International Conference on Information Management, Gda sk University Press, Gda sk 2009 (w druku). 3. Czarnacka-Chrobot B.: Wiarygodno metod szacowania pracochłonno ci przedsi wzi rozwoju systemów oprogramowania wspomagaj cych zarz dzanie. W: Informatyka Ekonomiczna. Informatyka w zarz dzaniu, Prace Naukowe Uniwersytetu Ekonomicznego we Wrocławiu, Wrocław 2009 (w druku). 4. Czarnacka-Chrobot B., Kobyli ski 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, International Function Point Users Group: IFPUG Function Point Counting Practices Manual, Release 4.2, Part 1-4, IFPUG, Princeton Junction, NJ, January International Software Benchmarking Standards Group: Release 10 Repository Demographics, ISBSG, Hawthorn VIC, Australia, January International Software Benchmarking Standards Group: The ISBSG Special Analysis Report: Early Lifecycle Software Estimation, ISBSG, Hawthorn VIC, Australia, September International Software Benchmarking Standards Group: The ISBSG Special Analysis Report: Software Project Costs, ISBSG, Hawthorn VIC, Australia, June 2005.

12 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 23, ISO/IEC Information Technology Software measurement Functional size measurement Part 1-6, ISO, Geneva ISO/IEC 15939:2007 Systems and software engineering - Measurement process, ISO, Geneva ISO/IEC 20926:2003 Software engineering - IFPUG 4.1 Unadjusted functional size measurement method - Counting practices manual, ISO, Geneva 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 Jones T.C.: Software Cost Estimating Methods for Large Projects. In: CrossTalk. The Journal of Defence Software Engineering, April 2005, s Jones T.C.: Software Estimating Rules of Thumb, Version 3, Software Productivity Research, Burlington 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 Kasunic M.: The State of Software Measurement Practice: Results of 2006 Survey, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, December Panorama Consulting Group: 2008 ERP Report, Topline Results, Denver, Practical Project Estimation (2 nd edition): A Toolkit for Estimating Software Development Effort and Duration, P.R. Hill (ed.), International Software Benchmarking Standards Group, Hawthorn VIC, Australia, Pressman R.S.: Software Engineering: A Practitioner s Approach, 6 th Edition, McGraw- Hill Science/Engineering/Math, New York Standish Group: CHAOS Summary 2009, West Yarmouth, Massachusetts, 2009.

13 40 Wymiarowanie funkcjonalne przedsi wzi rozwoju systemów oprogramowania wspomagaj cych zarz dzanie na bazie uogólnionych danych historycznych 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 presented 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 adjusted 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 belongs 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 development and enhancement projects functional measurement against a background of the main possibilities existing in that area. Keywords: functional measurement, ISO/IEC norm, IFPUG Function Points Method, extrapolation parametric models, ISBSG benchmarking data repository, functional measurement supporting tools Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Warszawa, Al. Niepodległo ci bczarn@sgh.waw.pl