Co nale y oszacowa

ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 1
Co nale y oszacowa ?
• pracochłonno
• harmonogram – czas trwania zada i całego projektu
• zasoby ludzkie – jak du y zespół
• bud et
− koszty wynagrodze
− koszty sprz tu i oprogramowania
− koszty materiałów
− koszty usług obcych (podwykonawców)
− koszty szkole , wyjazdów itp.
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 2
Trudno ci w szacowaniu
• bardzo du e zró nicowanie i zło ono
informatycznych
projektów
• nieliniowy wzrost zło ono ci oprogramowania przy
zwi kszaniu zakresu projektu
• zmienno wymaga , rodowiska, organizacji przy
ka dym nowym projekcie
technologii – praktycznie ka dy nowy
• zmienno
projekt w innej technologii
• rosn cy udział kosztu opracowania oprogramowania
w ogólnych kosztach systemu
• niematerialny charakter oprogramowania trudny z
natury do oszacowania
• brak do wiadczenia zespołów projektowych – zwykle
młodzi ludzie
• brak dojrzałych metryk oprogramowania dobrze
skorelowanych z procesem tworzenia oprogramowania
Dodatkowo
• konieczno dokonywania oszacowa przed
− specyfikacj wymaga
− wykonaniem projektu, który okre la technologi ,
narz dzia i architektur
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 3
Przy szacowaniu trzeba uwzgl dni
• zło ono
zadania
• umiej tno ci i do wiadczenie pracowników
• znajomo
i dost pno
technologii
• czas nieproduktywny (praca w innych projektach,
administrowanie, wakacje, choroby, szkolenia)
• czynno ci i czas zwi zany z zarz dzaniem (spotkania,
przygotowywanie raportów, sprawozda itp.)
• czas niezb dny dla komunikacji w zespole
• czas przeznaczony na kontrol
przegl dy, inspekcje)
jako ci (np. audyty,
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 4
Czas realizacji a liczba pracowników
Zale no nieliniowa
Przyczyny
• wraz z liczb pracowników ro nie nakład czasu na
komunikacj
• niepodzielno
zada
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 5
Miesi ce
Czas realizacji a liczba pracowników
Pracownicy
Miesi ce
Projekty wymagaj ce niewielkiej komunikacji
Pracownicy
Projekty wymagaj ce intensywnej komunikacji
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 6
Zalecenia przy szacowaniu
• aktualizowanie oszacowa – im pó niej szacujemy,
tym dokładniej bo mamy wi cej informacji (w praktyce
zalecenie to sprowadza si do weryfikacji oszacowa )
• dekompozycja
− mo liwo precyzyjniejszego oszacowania mniejszego
zadania, modułu itp.
− zmniejszenie
wpływu
bł dów
oszacowania
poszczególnych elementów na sumaryczny szacunek
cało ci
• opieranie si na charakterystyce produktywno ci
zespołu – konieczno
mierzenia produktywno ci,
gromadzenia danych i uaktualniania charakterystyki
• stosowanie ró norodnych oszacowa
•d
enie do okre lania i minimalizacji rozrzutu
szacunków
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 7
Metody szacowania pracochłonno ci
• szacowanie wst puj ce (np. metoda PERT)
• szacowanie
zst puj ce
–
okre lenie
stopnia
pracochłonno ci zadania wzgl dem wi kszej cało ci (np. na
zasadzie reguły 40-20-40)
• na zasadzie analogii z podobnymi przedsi wzi ciami
• ocena ekspertów
− metoda delficka
• Standard Task Method – podział zada
wielko ci i zło ono ci
wzgl dem
• metoda AQUA
• szacowanie algorytmiczne
− na podstawie linii kodu (np. COCOMO)
− na podstawie struktury programu (np. metoda punktów
funkcyjnych)
• u ycie i porównanie kilku metod
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
Szacowanie 8
ą
Szacowanie zst puj ce (top-down)
Przykład
Cały projekt
100%
Projektowanie
40%
Oprogramowanie
20%
Testowanie
i wdro enie
40%
Specyfikacja
wymaga
15%
Kodowanie
10%
Integracja
15%
Analiza
i projekt
25%
Testy
modułów
10%
Testowanie
20%
ń
Dokumentacja
5%
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 9
Metoda delficka
• szacowania dokonuje grupa ekspertów – ka dy z
osobna (w sposób tajny)
• wyniki zbiera si i wyznacza
− najbardziej optymistyczne oszacowanie
− warto
redni oszacowa
− najbardziej pesymistyczne oszacowanie
• powy sze wielko ci przedstawia si ekspertom i prosi
si ich znowu o dokonanie (zrewidowanie) oszacowania
proces kontynuuje si a si uzyska zbie no ocen
(albo si nie uzyska)
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 10
Standard Task Method
• klasyfikacja projektu (zadania) wzgl dem wielko ci,
np. mały, redni, du y
• klasyfikacja projektu (zadania) wzgl dem zło ono ci,
np. prosty, umiarkowany, zło ony
• tabelaryczna ocena pracochłonno ci (kosztu)
Przykład
„Przygotowanie planu realizacji projektu”
Zło ono
Rozmiar
projektu
Mały
redni
Du y
projektu
Prosty
Umiarkowany
Zło ony
10
osobodni
12
osobodni
15
osobodni
13
osobodni
15
osobodni
18
osobodni
15
osobodni
18
osobodni
21
osobodni
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 11
Metoda AQUA
• opiera si na analizie danych historycznych
− warto ci atrybutów
− pracochłonno
• badany jest stopie podobie stwa aktualnego
projektu do projektów historycznych na podstawie
porównywania warto ci atrybutów
• okre lenie N najbardziej podobnych przypadków w
oparciu o warto ci miary podobie stwa (N
wyliczane automatycznie)
• wyliczana jest pracochłonno nowego projektu na
podstawie pracochłonno N projektów najbardziej
podobnych (jako rednia wa ona wzgl dem miar
podobie stwa)
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 12
Metoda COCOMO
(COnstructive COst MOdel)
• pracochłonno
– E [osobomiesi ce]
E = a ∗ (KDSI)b ∗ d
KDSI (Kilo Delivered Source Instructions) – tysi ce
instrukcji ródłowych w programie (oszacowanie liczby
linii kodu)
• czas trwania projektu – T [miesi ce]
T = 2,5∗ Ec
• liczebno
zespołu – S
S = E/T
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 13
Współczynniki modelu COCOMO
• a, b, c – zale
od rodzaju systemu
♦ prosty – mały, typowy, w stabilnym rodowisku
♦ typowy – redni, typowy z modyfikacjami, w
umiarkowanie zło onym rodowisku
♦ zło ony – du y, unikalny, w zło onym rodowisku
prosty
typowy
zło ony
a
2,40
3,00
3,60
b
1,05
1,12
1,20
c
0,38
0,35
0,32
• d – współczynnik koryguj cy zale ny od atrybutów procesu,
produktu i rodowiska tworzenia oprogramowania (w
klasycznym modelu d=1)
Przykład
Program – 20 tys. instrukcji ródłowych (linii kodu), typowy
projekt
• pracochłonno
– 86 osobomiesi cy
• czas trwania
– 12 miesi cy
• zespół
– 7-8 osób
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 14
Zastrze enia do metod opartych na liniach
kodu
• wymagaj oszacowania linii kodu (szacowanie
pracochłonno ci zast pujemy szacowaniem linii kodu)
• szacowanie pracochłonno ci odbywa si tylko na
podstawie samego procesu kodowania programu, a
jest to tylko jeden z etapów realizacji
oprogramowania
• liczba linii kodu (instrukcji ródłowych) jest miar
długo ci programu i nie bierze pod uwag w
bezpo redni sposób jego zło ono ci i mo liwo ci
funkcjonalnych
• miara w postaci liczby linii kodu uniemo liwia
wykonywanie bada porównawczych, gdy silnie
zale y od rodków implementacji (j zyka)
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 15
Metoda punktów funkcyjnych
• obliczenie liczby wst pnych punktów funkcyjnych
(UFP– Unadjusted Function Points)
• obliczenie sumarycznego poziomu technicznej
zło ono ci (TCF– The Technical Complexity Factor)
• obliczenie punktów funkcyjnych (FP – Function
Points)
FP = UFP ∗ TCF
• wyznaczenie pracochłonno ci projektu na podstawie
wyliczonej liczby punktów funkcyjnych
• okre lenie czasu trwania projektu
• okre lenie liczebno ci zespołu
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 16
Wst pne punkty funkcyjne
(UFP – Unadjusted Function Points)
• klasyfikacja składników systemu
− wej cia do systemu
− wyj cia systemu
− wewn trzne zbiory danych
− zewn trzne zbiory danych
− zapytania
• okre lenie kategorii zło ono ci funkcji
− proste
− rednie
− zło one
• obliczenie sumy wag zło ono ci na podstawie
tabeli
Proste
rednie Zło one
Wej cia
3
4
6
Wyj cia
4
5
7
Zbiory wewn.
7
10
15
Zbiory zewn.
5
7
10
Zapytania
3
4
6
ń
K.Pie kosz
Zarz dzanie Projektami Informatycznymi
ą
Szacowanie 17
Poziom technicznej zło ono ci systemu
(TCF– The Technical Complexity Factor)
• szacowanie wpływu czynników koryguj cych ( w skali
0, 1, 2, 3, 4, 5 – im wi kszy wpływ tym wi cej
punktów)
1. szybko przesyłania danych
2. rozproszenie przetwarzania
3. wydajno
4. stopie obci enia systemu
5. cz stotliwo wykonywania transakcji
6. ilo danych wprowadzanych on-line
7. wydajno u ytkownika ko cowego
8. aktualizacja danych w trybie on-line
9. zło ono przetwarzania danych
10. przenaszalno oprogramowania
11. łatwo instalacji
12. prostota obsługi systemu
13. liczba lokalizacji stanowisk
14. łatwo wprowadzania zmian
• obliczenie zło ono ci przetwarzania F (suma stopni
wpływu poszczególnych czynników)
• wyznaczenie współczynnika koryguj cego, np.
TCF = 0,65 + (0.01 ∗ F)