Szacowanie

oprogramowania

Realizm czy szarlataneria

Po co „mierzyć”

oprogramowanie?

Celem projektów informatycznych jest wytworzenie
nowego, unikalnego produktu lub usługi (definicja
PMBOK)
Przedsięwzięcie musi być określone:

jak długo będzie trwało?
jakie będą koszty?
co będzie produktem końcowym?

W przypadku projektów komercyjnych musimy
odpowiedzieć także:

jak wycenić produkt/usługę?
jakie będzie TCO systemu?
jaki harmonogram zaproponować klientowi?

TCO

• TCO (Total Cost of Ownership) - zgodnie z Gartner

Group, jest to całkowity koszt pozyskania,

instalowania, użytkowania, utrzymywania i w końcu

pozbycia się aktywów w firmie na przestrzeni

określonego czasu.

• Ostatnio mówi się o TCO w kontekście inwestycji

firmy w narzędzia informatyczne. Należy w ich

przypadku brać na przykład pod uwagę nie tylko cenę

zakupu, ale też przemyśleć ile będzie kosztowało

utrzymanie narzędzi, oraz ich ewentualna rozbudowa.

• Źródło

„http://pl.wikipedia.org/wiki/Total_Cost_of_Ownership”

Co można

mierzyć/szacować?

Zakres funkcjonalny (funkcjonalność,
wielkość) systemu – punkty funkcyjne,
punkty obiektowe, przypadki użycia, liczba
linii kodu itd.
Jakość oprogramowania – ilość błędów na
moduł/plik/komponent, poziom trudności
utrzymania, itd.
Koszt oraz czas wytworzenia
oprogramowania – ilość osobodni,
osobotygodni osobomiesiące, czas trwania
projektu, ilość niezbędnych zasobów

Powiązania pomiędzy

parametrami projektu

Parametry definiujące
projekt:

zakres
czas
koszt
jakość

Zmiana jednego z nich
pociąga zmianę
pozostałych
Najczęściej tracimy na
jakości

Na czym polega szacowanie

w projekcie informatycznych

Podając jedną
wartość estymacji
sugerujemy 100%
pewności naszych
przewidywań
W rzeczywistości
nigdy nie możemy
mieć takiej
pewności

Estymacja jako ustalenie

prawdopodobieństwa

Naturalnym
rozwinięciem
estymacji
jednopunktowej jest
rozkład naturalny
Krzywa Gauss’a nie
odzwierciedla
jednak natury
projektu
informatycznego

Rozkład

prawdopodobieństwa

estymacji

Badania
heurystyczne
wykazały
zbieżność danych
statystycznych z
rozkładem β
Rezultat nominalny
(mediana) określa
oszacowanie 50/50

Czy dobre szacowanie jest

możliwe?

Dobre oszacowanie osiąga dokładność
±10% (Jones 1998)
Estymacje z takim poziomem błędu są
możliwe tylko dla dobrze kontrolowanych
projektów
Projekty chaotyczne charakteryzuje zbyt
duża zmienność
Organizacje poprawiają swoje
estymację poprzez poprawę kontroli
projektów, a nie metod estymacji

Przykłady z rynku

informatycznego

System dla ZUS Płatnik – planowany
budżet 750 mln PLN, już zostało wydane
1500 mln PLN
System CEPiK – w 2004 roku wygrała oferta
z budżetem 230 mln PLN i rok na
wdrożenie.
Projekt trwa nadal
System PPARS (zarządzanie w służbie
zdrowia) został przerwany w momencie
przekroczenia budżet o 140 mln funtów
(2007), przy budżecie 8,8 mln

Jedynie 32 procent wszystkich projektów IT kończy się
sukcesem, a więc realizowanych jest w założonym czasie,
budżecie i spełnia założone wymogi jakościowe. Całkowitą
porażką kończy się 24 procent projektów, zaś 44 procent –
niepowodzeniem częściowym, co oznacza, że projekty te
przekraczają czas lub budżet bądź też nie przynoszą
użytkownikom wszystkich zakładanych początkowo korzyści
(2008).

Dlaczego dobre oszacowanie
parametrów projektu jest ważne?

Konsekwencje:

wstrzymane projekty
utrata szansy biznesowej
zła inwestycja, nieuzasadnione

koszty

Porażki i sukcesy

Galant-Pater

Prawdopodobieństwo

porażki w projekcie

uż

yt

ko

w

e

ou

ts

ou

rc

in

g

ko

m

er

cy

jn

e

Z

S

Z

w

oj

sk

ow

e

sy

st

em

ow

a

10 fp

1000 fp

100 000 fp

0

10

20

30

40

50

60

70

80

90

100

10 fp
100 fp
1000 fp
10 000 fp
100 000 fp

Ryzyko projektu

informatycznego

Rośnie wraz z wielkością projektu
(nieliniowo!!!)
Heurystycznie ustalony prób
bezpieczny dla projektów to 1500 FP
Jeżeli to możliwe to duże projekty
należy dzielić na mniejsze pod-
projekty
Produkty poszczególnych
podprojektów powinny być
realizowane i odbierane niezależnie

Testy umiejętności

szacowania

Proszę podać dolną i górną granicę
przedziału, który wydaje się na 90%
zawierać prawidłowa odpowiedź
Przedziały nie powinny być zbyt duże, ani
zbyt małe
Proszę nie korzystać z pomocy kolegów
lub materiałów pomocniczych – testujemy
umiejętność szacowania, a nie wiedzę
Przykład pytania: długość wieży Eiffla
Odpowiedź: 300-350m

Lista pytań

1.

Średnia odległość Słońca od Ziemi?

2.

Średnia masa Ziemi?

3.

Przybliżona objętość oceanu Atlantyckiego (z
morzami)?

4.

Długość granic Polski?

5.

Powierzchnia dorzecza Wisły?

6.

Data urodzenia króla Salomona (biblijny król Izraela)?

7.

Długość największego odkrytego brachiozaura?

8.

Liczba sprzedanych książek o Harrym Potte’rze
(autorstwa J.K. Rowling) w 2003 roku?

9.

Powierzchnia Chin?

10. Odległość od Ziemi gwiazdy Alfa Centauri A w latach

świetlnych?

Odpowiedzi

1. 149,6 x 10

6

km

2. 5,9736x10

24

kg

3. 354 700 000 km

3

4. 3511 km
5. 194 424 km

2

6. 931 p.n.e
7. 27 m
8. 200 mln egz.
9. 9 596 960 km

2

10. 4,36 ly

Inne pytania – Steve McConell

„Szacowanie oprogramowania. Kulisy

czarnej magii”

1. Temperatura na powierzchni słońca
2. Szerokość geograficzna Szanghaju
3. Powierzchnia Azji
4. Rok urodzenia Aleksandra Wielkiego
5. Łączna wartość waluty amerykańskiej pozostającej w

obrocie w 2004 roku

6. Całkowita objętość Wielkich Jezior
7. Łączne wpływy kasowe na całym świecie ze sprzedaży

biletów na film Titanic

8. Całkowita długość linii brzegowej Oceanu Spokojnego
9. Liczba tytułów książek opublikowanych w USA od 1776

roku

10. Najcięższy płetwal błękitny jaki został kiedykolwiek

zarejestrowany

Odpowiedzi

• Temperatura na powierzchni słońca

6000

o

C

Szerokość geograficzna Szanghaju

31

o

szerokości N

• Powierzchnia Azji 44390000 km

2

Rok urodzenia Aleksandra Wielkiego

356 p.n.e.

Łączna wartość waluty amerykańskiej pozostającej w obrocie w

2004 roku 719,9 miliarda dolarów

Całkowita objętość Wielkich Jezior

23000 km

3

=6,8*1023

litrów

Łączne wpływy kasowe na całym świecie ze sprzedaży biletów

na film Titanic

1,835 mld dolarów

Całkowita długość linii brzegowej Oceanu Spokojnego 135663

km

Liczba tytułów książek opublikowanych w USA od 1776 roku 22

mln

Najcięższy płetwal błękitny jaki został kiedykolwiek

zarejestrowany

170 000 kg

Wnioski z podobnych badań

Dla większość ludzi 90% pewności oznacza
jedynie 30% (Zultner 1999, Jorgensen 2002)
Częściej podawane są wartości zaniżone
Człowiek ma naturalną skłonność do
zawężania przedziałów bez wyraźnego
zewnętrznego impulsu:

instynkt – dokładniej, znaczy lepiej
profesjonalizm
pycha
wyimaginowana presja otoczenia

Wartość dokładność

oszacowań

Najczęściej spotykana definicja
oszacowania:

Najbardziej optymistyczna prognoza o

niezerowym prawdopodobieństwie
spełnienia – Tom DeMarco

Według niektórych autorytetów
(Capers Jones) nierealne terminy są
najbardziej destrukcyjne dla projektu i
oprogramowania

Negatywne czynniki

zawyżonego oszacowania

Prawo Parkinsona – realizacja zadania
zawsze wypełnia cały dostępny czas i
dostępne zasoby
Syndrom studenta – zwlekanie na ostatnią
chwilę z rozpoczęciem zadania
Kierownik typu X – pracownicy są
nieodpowiedzialni, okłamują szefów,
zawyżają oszacowania i wymagają ciągłej
kontroli
Daty w kalendarzu są bliższe niż myślisz

Negatywne czynniki

zaniżania oszacowania

• Brak możliwości rzeczywistego zaplanowania prac w projekcie
• Mniejsze prawdopodobieństwo na terminowe wykonanie

projektu

• „Ucinanie kantów” na szkoleniu, dokumentacji, projekcie

technicznym prowadzi do zmniejszenia jakości produktu

• Dodatkowe czynności i zasoby związane z gaszeniem pożaru

(spotkania, eskalacje, raporty, wersje beta, itd.)

• Ucieczka pracowników wykwalifikowanych i znających

problematykę

• „Ludzie pod presją nie myślą szybciej”

„Projekty można prowadzić na dwa sposób: a) zaplanować i
realizować lub b) realizować wstrzymać zaplanować i

realizować”

Wynik dobrego oszacowania

projektu

Możliwość lepszego zaplanowania zadań w
projekcie
Osiągnięcie planowanej jakości
Zdecydowanie lepsze zarządzanie
budżetem projektu – system motywacyjny
Uznanie dla profesjonalizmu zespołu
projektowego
Możliwość planowania kolejnych projektów
Dobre relacje z klientem – lepsze
perspektywy na kolejne kontrakty

Błędy metod

Brak odniesienia do poprzednich projektów
Stosowanie tylko jednej metody bez
możliwości weryfikacji z wynikami innych
metod
Brak ciągłego uaktualniania estymacji i
porównania z rzeczywistymi wielkościami po
zakończeniu projektu
Brak stosowania jakiejkolwiek metody
estymacji
Szacowanie w celu dostosowania wielkości do
oczekiwań sponsora projektu, klienta,
udziałowców, „price to win” itd.

Błędy społeczne

Nadmierny optymizm w stosunku do
dostępności i kompetencji zespołu
projektowego
Przecenianie wpływu narzędzi i
nowych technologii
Brak odniesieni do krzywej uczenia
się zespołu projektowego
Utajnianie złych informacji przed
przełożonymi

Błędy organizacyjne

Brak doświadczonych kierowników
projektów
Rozproszenie odpowiedzialności w
strukturze organizacyjnej, brak
jasnych ścieżek raportowania
Rozproszenie zespołu projektowego
Nieodpowiednie narzędzia i
technologia

Proces estymacji

Estymacja wykonana na późniejszym
etapie projektu jest bardziej wiarygodna
W przypadku oszacowań
jednopunktowych stosowane są
przedziały predefiniowane dla
poszczególnych etapów projektów –
stożek niepewności
W przypadku projektów iteracyjnych,
każda iteracja powinna być traktowana
jako pełny projekt

Dokładność estymacji od

fazy projektu – stożek

niepewności

Stożek niepewności – brak

kontroli projektu

Często pomijane zadania w oszacowaniach

(COCOMO II) (ang. constructive cost model) –

model szacowania liczby osobogodzin w

procesie tworzenia oprogramowania

Wymagania pozafunkcjonalne:

poprawa wydajności
elastyczność
współbieżność
niezawodność
skalowalność
bezpieczeństwo (audity, certyfikacje, itd.)
ergonomia interfejsu

Często pomijane zadania w

oszacowaniach (COCOMO II)

Obszar wymagań funkcjonalnych:

instalacja i konfiguracja programu
opracowanie konwersji danych
interfejsy do systemów zewnętrznych
dokumenty pomocy
etap wdrożenia
spotkania, konferencje, wizytacje
przygotowania dokumentów
projektowych