Szacowanie
oprogramowania
Realizm czy szarlataneria
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