Wykład 6 - Organizacja i Zarządzanie Projektami Informatycznymi PDF

Organizacja i zarządzanie projektami informatycznymi Moduł 6: Ocena rozmiaru i kosztu projektów informatycznych Opracowanie: dr inż. Marcin Szlenk 1 Wstęp Całkowity koszt wytworzenia systemu informatycznego obejmuje następujące elementy: koszt infrastruktury sprzętowej wchodz...

Organizacja i zarządzanie projektami informatycznymi Moduł 6: Ocena rozmiaru i kosztu projektów informatycznych Opracowanie: dr inż. Marcin Szlenk 1 Wstęp Całkowity koszt wytworzenia systemu informatycznego obejmuje następujące elementy: koszt infrastruktury sprzętowej wchodzącej w skład systemu, koszt oprogramowania pomocniczego (zakup licencji na systemy operacyjne, bazy danych, narzędzia programistyczne), koszt wyjazdów i szkoleń, koszt pracy (nakład pracy). Trzy pierwsze elementy są zazwyczaj łatwe do oszacowania. Problemem jest natomiast oszacowanie kosztu pracy. Koszt ten wynika z zatrudnienia przy realizacji projektu okre- ślonej liczby osób, czyli poniesienia pewnego nakładu pracy. Nakład pracy przy realizacji danego przedsięwzięcia zależy od liczby zaangażowanych osób oraz czasu trwania przed- sięwzięcia i wyrażany jest najczęściej liczbą osobomiesięcy (ang. person-months, PM). Oso- bomiesiąc oznacza zatrudnienie jednej osoby w ciągu jednego miesiąca. Szacowanie kosz- tów wytworzenia systemu informatycznego sprowadza się najczęściej do problemu szaco- wania nakładu pracy. Nakład pracy wiąże się zwykle w ścisły sposób z rozmiarem tworzonego systemu. Do wy- rażenia rozmiaru systemu można użyć dwóch typów miar : Miary wielkościowe, które wyrażają bezpośrednio rozmiar wyniku wykonania określo- nej czynności. Najczęściej stosowaną miarą tego typu jest liczba linii kodu źródłowe- go systemu (ang. lines of code, LOC) podawana zwykle w tysiącach (KLOC). Liczba linii kodu źródłowego zależy od języka programowania oraz przyjętych standardów ko- dowania. Pomijając szczególne przypadki, porównywanie rozmiarów systemów na podstawie tego parametru jest zatem mało miarodajne. Miary funkcyjne, które wyrażają ogólną funkcjonalność systemu informatycznego, nie- zależną od języka implementacji. Są one bardziej miarodajne, a ponadto łatwiejsze do stosowania we wczesnych fazach przedsięwzięcia, zanim jeszcze zapadły decyzje projektowe (w szczególności te dotyczące języka programowania). Ich wadą jest jed- nak pewna subiektywność oceny. Miarami tego typu są przedstawione dalej punkty funkcyjne i punkty obiektowe. 2 Metoda punktów funkcyjnych Najbardziej rozpowszechnioną metodą szacowania rozmiaru systemu w oparciu o mia- rę funkcyjną jest metoda punktów funkcyjnych (ang. function points, FP). Liczbę punktów funkcyjnych oblicza się na podstawie następujących parametrów : liczby plików wewnętrznych systemu – pliki przechowujące trwałe dane istotne dla użytkownika, liczby interfejsów zewnętrznych – pliki zewnętrzne zarządzane przez inną aplikację, z których tworzony system będzie korzystał, liczby wejść do systemu – bodźce na podstawie których uaktualniana jest informacja w plikach wewnętrznych (np. dodanie nowego zamówienia), liczby wyjść z systemu – sposoby prezentowania danych (liczba raportów i ekranów) z plików wewnętrznych i interfejsów zewnętrznych, 1  liczby zapytań – proste wejścia (bodźce) pociągające za sobą natychmiastowe wyj- ścia bez modyfikowania plików systemu (np. sprawdzenie stanu zamówienia). Plik (ang. file) nie musi tu oznaczać obiektu w systemie plików, a reprezentuje pewien zbiór danych, którym może być np. tabela w bazie danych. Wymienione wyżej parametry pre- zentuje rysunek 1. Rysunek 1: Parametry w metodzie punktów funkcyjnych Po określeniu każdego z parametrów, należy następnie określić jego złożoność („prosty”, „średni”, „złożony”) i pomnożyć przez odpowiednie współczynniki wagowe zawarte w ta- beli 1. Tabela 1: Współczynniki wagowe w metodzie punktów funkcyjnych Parametr Prosty Średni Złożony Wejścia do systemu 3 4 6 Wyjścia z systemu 4 5 7 Pliki wewnętrzne systemu 7 10 15 Interfejsy zewnętrzne (pliki zewnętrzne) 5 7 10 Zapytania 3 4 6 Suma parametrów (przemnożonych przez wagi) daje nieunormowaną liczbę punktów funkcyjnych (ang. unadjusted function-point count, UFC). Liczbę punktów funkcyjnych (unormowaną) oblicza się mnożąc nieunormowaną liczbę punktów funkcyjnych przez współczynnik złożoności technicznej (ang. technical complexity factor, TCF): FP = UFC ⋅ TCF Współczynnik TCF jest wartością z przedziału 0,65–1,35 obliczaną na podstawie wzoru: 14 TCF = 0,65 + 0,01 ⋅ ∑ F𝑖 𝑖=1 gdzie F𝑖 są czynnikami korygującymi złożoność (ang. complexity adjustment values). War- tość każdego z czynników jest odpowiedzią w skali od 0 („nie”) do 5 („tak”) na pytania przedstawione w tabeli 2. 2  Tabela 2: Czynniki korygujące złożoność Czynnik Pytanie F1 Czy system wymaga niezawodnego backupu i procedur odtwarzania? F2 Czy są wymagane mechanizmy komunikacji i wymiany danych? F3 Czy występuje przetwarzanie rozproszone? F4 Czy wydajność systemu jest parametrem krytycznym? F5 Czy będzie wymagane od systemu działanie w warunkach dużego obciążenia? F6 Czy będzie wymagane wprowadzanie danych w trybie on-line? F7 Czy transakcje wejściowe będą wymagały skomplikowanych operacji? F8 Czy będzie wymagana modyfikacja danych w trybie on-line? F9 Czy przetwarzanie danych będzie złożone? F10 Czy struktury danych i zapytania użytkownika będą złożone? F11 Czy system jest projektowany z myślą o wielokrotnym użyciu? F12 Czy mechanizmy konwersji danych z poprzedniego systemu i instalacji muszą być uwzględnione przy projektowaniu systemu? F13 Czy będzie wymagana możliwość instalacji systemu w wielu miejscach? F14 Czy będą wymagane od systemu: przyjazność i łatwość pielęgnacji? Przy użyciu metody punktów funkcyjnych można również szacować rozmiar systemu w li- niach kodu źródłowego. Przykładowe przeliczniki (liczba linii kodu przypadająca na jeden punkt funkcyjny) dla kilku języków programowania podano w tabeli 3. Tabela 3: Przeliczniki punktów funkcyjnych na liczbę li- nii kodu Języki/narzędzia programowania LOC/FP Asembler 320 C 128 Cobol, Fortran 105 Ada 70 Pascal 90 Lisp, Prolog 64 Języki obiektowe 30 Języki czwartej generacji (4GL) 20 Arkusze kalkulacyjne 6 3 Metoda punktów obiektowych W przypadku użycia bardziej zaawansowanych narzędzi programowania, jak np. języki czwartej generacji (4GL), wygodniejsza do zastosowania jest metoda punktów obiekto- wych (ang. object points, OP). Punkty obiektowe oblicza się na podstawie następujących parametrów: liczby różnych wyświetlanych ekranów (prosty ekran – 1 punkt obiektowy, średnio złożony – 2, bardzo złożony – 3), liczby tworzonych raportów (prosty raport – 2 punkty obiektowe, średnio złożony – 3  5, bardzo złożony – 8), liczby modułów w językach trzeciej generacji (3GL), które należy stworzyć w celu uzu- pełnienia kodu 4GL (każdy moduł – 10 punktów obiektowych). Wymienione parametry prezentuje rysunek 2. Rysunek 2: Parametry w metodzie punktów obiektowych Zsumowane wagi poszczególnych elementów (tj. ekranów, raportów i dodatkowych modu- łów) składają się na ostateczną liczbę punktów obiektowych, wyrażającą rozmiar systemu. Nie ma tu dodatkowego współczynnika korygującego, jak w przypadku metody punktów funkcyjnych. 4 Metody szacowania kosztu Do szacowania kosztu wytworzenia systemu informatycznego można zastosować kilka wy- mienionych niżej metod : Modele algorytmiczne Na podstawie danych o historycznych przedsięwzięciach opraco- wuje się ogólne formuły matematyczne pozwalające obliczyć nakład pracy na pod- stawie atrybutów aktualnego przedsięwzięcia. Ocena ekspertów (metoda delficka) Zasięga się rady osób z doświadczeniem przy reali- zacji podobnych projektów. Podane przez nie szacunki analizuje się i proces szaco- wania ponawia aż do uzyskania jednej uzgodnionej wartości. Ocena przez analogię Metoda polega na wyszukaniu podobnych zakończonych przedsię- wzięć. Koszt aktualnego przedsięwzięcia ocenia się przez analogię do kosztów po- przednich przedsięwzięć. Prawo Parkinsona Prawo to mówi, że koszt jest determinowany przez dostępne zasoby. Zatem, jeżeli projekt należy zrealizować w czasie 𝑥 (takie są wymagania) i mamy do dyspozycji 𝑦 osób, to spodziewany nakład pracy ocenia się na 𝑥 ⋅ 𝑦 osobomiesięcy. Wycena dla wygranej Koszt systemu jest oceniany na podstawie możliwości klienta (ile jest skłonny zapłacić) oraz ewentualnych ofert konkurencji. W dalszej części przedstawimy bliżej metody algorytmiczne: model COCOMO i jego now- szą wersję – model COCOMO II. 5 Model COCOMO Modele algorytmiczne szacowania kosztu konstrukcji systemu informatycznego, a dokład- niej kosztu wytworzenia oprogramowania, pozwalają obliczyć spodziewany nakład pracy na podstawie pewnych atrybutów przedsięwzięcia. Podstawowym z tych atrybutów jest 4 rozmiar systemu. Oczywiście, rozmiar systemu wyrażony np. liczbą linii kodu lub punkta- mi funkcyjnymi wymaga również oszacowania. Przyjmuje się jednak, że znacznie łatwiej oszacować wspomniany rozmiar systemu niż odpowiadający mu nakład pracy. Typowym przykładem algorytmicznego szacowania kosztu jest model COCOMO (Cost Con- struction Model). W modelu tym należy najpierw oszacować liczbę linii kodu oraz za- klasyfikować projekt do jednej z trzech grup: projekt organiczny (ang. organic project) – łatwy, względnie mały (pod względem rozmiaru i złożoności) projekt, realizowany przez niewielki zespół osób o wysokich umiejętnościach i dużym doświadczeniu, przy dobrze określonych i stabilnych wymaganiach co do systemu; projekt pół-oderwany (ang. semi-detached project) – średniej wielkości projekt realizo- wany przez zespół o zróżnicowanych umiejętnościach i doświadczeniu, gdzie część wymagań jest słabiej określona i może podlegać zmianom; projekt wbudowany (ang. embedded project) – projekt o bardzo złożonych wymaga- niach, ścisłych ograniczeniach, co do czasu, kosztu, platformy programowej i sprzę- towej; nietypowy, a zatem większość zespołu nie posiada doświadczenia przy reali- zacji podobnych projektów. Kolejne klasy projektów odpowiadają przedsięwzięciom coraz trudniejszym, stąd i nakład pracy związanej z ich realizacją powinien być większy. W podstawowym modelu COCOMO nakład pracy (w osobomiesiącach) oblicza się ze wzoru: PM = 𝑎 ⋅ KLOC 𝑏 gdzie KLOC jest przewidywaną liczbą tysięcy linii kodu, natomiast współczynniki 𝑎 oraz 𝑏 przyjmują wartości zależne od klasy, do której zaliczono projekt (zostały one określone na podstawie analizy około sześćdziesięciu rzeczywistych projektów), jak w tabeli 4. Tabela 4: Współczynniki w modelu COCOMO Klasa projektu 𝑎 𝑏 𝑐 Projekt organiczny 2,4 1,05 0,38 Projekt pół-oderwany 3,0 1,12 0,35 Projekt wbudowany 3,6 1,20 0,32 Obliczona liczba osobomiesięcy, pozwala określić koszty pracy, ale nie wynika z niej jesz- cze ile osób i na jak długo należy zatrudnić przy projekcie. Jeżeli szacowany nakład pracy wynosi np. 50 osobomiesięcy, to nie oznacza to, że projekt da się zrealizować zespołem 50-osobowym w przeciągu miesiąca, albo zespołem 100-osobowym w dwa tygodnie. Dla każdego typu projektu istnieje pewna optymalna, pod względem czasu trwania projektu, wielkość zespołu. W modelu COCOMO szacowany czas trwania projektu (w miesiącach) oblicza się ze wzoru: M = 2,5 ⋅ PM 𝑐 gdzie PM jest szacowaną liczbą osobomiesięcy, a współczynnik 𝑐 przyjmuje wartości zgod- nie z tabelą 4. Na podstawie liczby osobomiesięcy i czasu trwania projektu, liczba osób wymaganych przy realizacji projektu wynosi: PM P=. M 5 Model COCOMO został opracowany w roku 1981 i występował w trzech postaciach, z któ- rych przedstawiona wyżej (tzw. podstawowa, ang. basic) jest najprostszą i jednocześnie najmniej dokładną. Kolejne poziomy szacowania pozwalały uwzględnić dodatkowe czyn- niki charakteryzujące przedsięwzięcie, a także szacować koszty różnych faz przedsięwzię- cia. 6 Model COCOMO II Przy opracowywaniu modelu COCOMO przyjęto, że system będzie powstawał zgodnie z procesem kaskadowym. Założono ponadto, że wykorzystanie gotowych komponentów oprogramowania będzie niewielkie. Rozwój w dziedzinie wytwarzania oprogramowania przyniósł jednak popularność innych procesów konstrukcji systemów, jak prototy- powanie, czy procesy przyrostowe. Powszechne stało się również wykorzystywanie przy konstrukcji oprogramowania gotowych komponentów wielokrotnego użycia oraz wspieranie procesu konstrukcji oprogramowania narzędziami CASE (Computer Aided Software Engineering). Zmiany te zostały uwzględnione w opracowanym w roku 1995 modelu COCOMO II. Decyzje projektowe dotyczące wykorzystania danego języka/technologii, czy określonych gotowych podsystemów (np. bazy danych) mogą mieć duży wpływ na ostateczny nakład pracy, a nie są jeszcze znane na etapie analizy wymagań. Stąd, dokładność szacowania nakładu pracy przy tworzeniu systemu wzrasta wraz z postępami przedsięwzięcia. Model COCOMO II wyróżnia trzy fazy zaawansowania procesu tworzenia systemu informatyczne- go i dla każdej z nich pozwala szacować nakład pracy w coraz bardziej dokładny sposób. Wspomniane fazy to: faza wczesnego prototypowania – projekt jest na etapie wczesnej analizy wymagań co do systemu, faza wczesnego projektowania – projekt jest na etapie zdefiniowanych wymagań i bardzo wstępnych prac projektowych, faza postarchitektoniczna – projekt jest na etapie po zaprojektowaniu architektury systemu. Faza wczesnego prototypowania W fazie wczesnego prototypowania do szacowania nakładu pracy wykorzystuje się punk- ty obiektowe. Należy najpierw oszacować rozmiar systemu w punktach obiektowych (OP) oraz określić, jaki udział procentowy w całości systemu będą miały już istniejące elemen- ty wielokrotnego użycia (wskaźnik 𝑟). Liczba punktów obiektowych, które przypadną na tworzoną od zera część systemu wynosi zatem: 𝑟 NOP = OP ⋅ (1 − ). 100 Nakład pracy w osobomiesiącach oblicza się następnie jako: NOP PM = PROD gdzie PROD jest wskaźnikiem produktywności (liczbą punktów obiektowych na miesiąc) tak jak w tabeli 5. 6  Tabela 5: Produktywność w punktach obiektowych Doświadczenie Bardzo Bardzo programistów małe Małe Przeciętne Duże duże PROD 4 7 13 25 50 Faza wczesnego projektowania Przy użyciu narzędzi CASE część kodu źródłowego może zostać wygenerowana automa- tycznie. W fazie wczesnego projektowania, szacując nakład pracy przedstawia się go jako sumę dwóch składników: PM = PMm + PMa gdzie PMm jest nakładem pracy przy standardowym (manualnym) wytwarzaniu kodu, a PMa jest nakładem pracy związanym z integracją (połączeniem) kodu wygenerowanego automatycznie z kodem stworzonym manualnie. Składnik PMm szacuje się korzystając ze wzoru: PMm = 2,5 ⋅ KLOC 𝑏 ⋅ EAF gdzie EAF jest współczynnikiem korygującym nakład pracy (ang. effort adjustment factor), obliczanym jako iloczyn siedmiu czynników: EAF = RCPX ⋅ RUSE ⋅ PDIF ⋅ PERS ⋅ PREX ⋅ SCED ⋅ FCIL. Poszczególne czynniki są atrybutami tworzonego systemu i przedsięwzięcia: RCPX – niezawodność i złożoność systemu, RUSE – wymagany stopień użycia wielokrotnego (kodu, który będzie tworzony), PDIF – trudności platformy, PERS – możliwości członków zespołu, PREX – doświadczenie członków zespołu, SCED – wymagania co do harmonogramu, FCIL – udogodnienia pomocnicze (w ramach infrastruktury projektu). Każdy z nich wymaga oszacowania, przy czym wartością przeciętną (nie wypływającą na nakład pracy) jest 1. Wartości większe niż 1 odpowiadają większemu niż przeciętny nakła- dowi pracy, mniejsze niż 1 – mniejszemu. Liczbę tysięcy linii kodu źródłowego (KLOC) wyznacza się szacując najpierw liczbę punk- tów funkcyjnych, a następnie przeliczając je na linie kodu. Liczba ta odnosi się do kodu tworzonego w całości ręcznie, a nie wygenerowanego automatycznie lub użytego ponow- nie. Wykładnik 𝑏 we wzorze na PMm oblicza się natomiast ze wzoru: 5 𝑏 = 1,01 + 0,01 ⋅ ∑ W𝑖 𝑖=1 gdzie W𝑖 są czynnikami charakteryzującymi przedsięwzięcie. Każdy z czynników przyj- muje wartość w przedziale od 5 („bardzo mały”) do 0 („bardzo duży”), a ich interpretację zawiera tabela 6. 7  Tabela 6: Czynniki charakteryzujące przedsięwzięcie Czynnik Nazwa Pytanie W1 Doświadczenie Jaki jest poziom doświadczenia firmy w podobnych przedsięwzięciach? W2 Elastyczność Jaki jest zakres swobody w określaniu tworzenia procesu tworzenia? (Jak dużą swobodę dają np. wymagania klienta?) W3 Kontrola ryzyka Jaki jest stopień i zakres wykonanej analizy ryzyka? W4 Spójność zespołu Jaki jest poziom współpracy (zintegrowania, łatwości komunikacji) w zespole? W5 Dojrzałość procesu Jaki jest poziom dojrzałości procesu wytwarzania w firmie? Składnik PMa wyrażony jest natomiast wzorem: KLOCa ⋅ 𝑎/100 PMa = PRODa gdzie KLOCa to liczba linii kodu wygenerowanego automatycznie, wskaźnik 𝑎 to procento- wy udział kodu generowanego automatycznie w całości kodu systemu (im więcej takiego kodu, tym większy narzut związany z jego integracją z resztą kodu systemu), a PRODa to poziom produktywności (liczba linii na osobomiesiąc) takiego tworzenia kodu (głównie jego integracji). Faza postarchitektoniczna W fazie postarchitektonicznej koszty szacuje się przy użyciu tych samych formuł, co w fazie wczesnego projektowania. Współczynnik korygujący nakład pracy (EAF) oblicza się jednak bardziej dokładnie jako iloczyn nie siedmiu, a siedemnastu atrybutów podanych w tabeli 7. Tabela 7: Czynniki korygujące nakład pracy Atrybuty systemu RELY Wymagana niezawodność systemu DATA Rozmiar bazy danych CPLX Złożoność systemu RUSE Wymagany stopień użycia wielokrotnego DOCU Zakres wymaganej dokumentacji Atrybuty platformy TIME Wymagania co do czasu działania STORE Wymagania co do pamięci PVOL Stabilność konfiguracji sprzętowo-systemowej Atrybuty zespołu ACAP Możliwości analityków i projektantów PCAP Możliwości programistów PCON Ciągłość zatrudnienia członków zespołu AEXP Doświadczenie analityków i projektantów w dziedzinie przedsięwzięcia 8  Tabela 7: Czynniki korygujące nakład pracy PEXP Doświadczenie programistów w dziedzinie przedsięwzięcia LTEX Doświadczenie zespołu w stosowaniu języków i narzędzi Atrybuty projektu TOOL Użycie narzędzi programistycznych SITE Stopień rozproszenia pracy pomiędzy ośrodkami i jakość komunikacji pomiędzy nimi SCED Wymagania co do harmonogramu 7 Podsumowanie Rozdział stanowi przegląd zagadnień z zakresu szacowania rozmiaru i kosztu tworzenia systemu informatycznego. Omówiono najpopularniejsze metody szacowania rozmiaru systemu: metodę punktów funkcyjnych i metodę punktów obiektowych, oraz algorytmicz- ne modele szacowania kosztów: model COCOMO oraz COCOMO II. Mimo, że w praktyce skuteczność szacowania może być różna i zależeć chociażby od doświadczenia osoby dokonującej szacowania (określenie potrzebnych w tych metodach parametrów jest przecież subiektywne), to stanowią one dobry punkt odniesienia przy określaniu rozmia- ru/kosztu tworzonego systemu, wskazując jednocześnie, jak szeroka gama czynników może na ten rozmiar/koszt wpływać. Bibliografia Sommerville, I.: Inżynieria oprogramowania. Wydawnictwa Naukowo-Techniczne, 2003. Flasiński, M.: Zarządzanie projektami informatycznymi. Wydawnictwo Naukowe PWN, 2007. Jaszkiewicz, A.: Inżynieria oprogramowania. Wydawnictwo HELION, 1997. 9