Pobierz

Transkrypt

Pobierz
Inżynieria oprogramowania 2
Szacowanie pracochłonności
i budżetu projektu
Piotr Miklosik
[email protected]
Mirosław Ochodek
[email protected]
Cel wykładu
• Jakie są podejścia do
szacowania
pracochłonności i
kosztów?
• Przegląd wybranych
metod
2
Plan wykładu
• Wprowadzanie
• Rozmiar oprogramowania – punkty funkcyjne
• Szacowanie pracochłonności
– Miary dokładności szacowania pracochłonności
– Przegląd metod szacowania pracochłonności
• Przez analogię
• Eksperckie
• Algorytmiczne
• Harmonogram i budżet
Plan wykładu
• Wprowadzanie
• Rozmiar oprogramowania – punkty funkcyjne
• Szacowanie pracochłonności
– Miary dokładności szacowania pracochłonności
– Przegląd metod szacowania pracochłonności
• Przez analogię
• Eksperckie
• Algorytmiczne
• Harmonogram i budżet
Dlaczego szacujemy pracochłonność?
Czy powinniśmy
podpisać kontrakt?
Jak stworzyć harmonogram
Ile to będzie kosztowało?
60-80% projektów
przekracza budżet
i harmonogram
K. Moløkken and M. Jørgensen. A review of software surveys on software effort estimation. In Empirical
Software Engineering, 2003. ISESE 2003. Proceedings. 2003 International Symposium on, pages 223–230.
Skutki błędnej estymacji pracochłonności
• przeszacowanie
– utrata kontraktu
– prawo Parkinsona
– Syndrom studenta
• niedoszacowanie
– przekroczenie budżetu i terminu
– niska jakość
Dlaczego szacujemy pracochłonność?
Planowanie w wydaniu Jasia Fasoli
Czy chodzi o estymację?
• Cel
• Zobowiązanie
• Estymacja
8
Dobra estymata pracochłonności
Czego mogę
oczekiwać od
metod szacowania?
9
Dobra estymata pracochłonności?
Dobre oszacowanie to takie które wspiera
czynności związane z zarządzanie projektem
takie jak planowanie i negocjacja zasobów
projektu, zarządzanie zmianą i ryzykiem, itd..
Wybór metody szacowania
•
•
•
•
Model finansowania projektu
Dziedzina oraz rodzaj produktów
Różne etapy szacowania
Różny poziom samoświadomości organizacji
Wybór metody szacowania
•
•
•
•
Model finansowania projektu
Dziedzina oraz rodzaj produktów
Różne etapy szacowania
Różny poziom samoświadomości organizacji
Trójkąty równowagi w projekcie
“Everybody wants things good, wants them fast,
and wants them cheap.
Everyone knows you can actually achieve any
two of the three”
[John Boddie].
You need to decide which two do you want?
Trójkąty równowagi w projekcie
Jakość
Optymalizacja
zakresu
Funkcjonalność
Zasoby
Trójkąty równowagi w projekcie
Jakość
Optymalizacja
zakresu
Pracochłonność
Optymalizacja
zasobów
Funkcjonalność
Produktywność
Ludzie
Czas trwania
Trójkąty równowagi w projekcie
Stały zakres
Jakość
Optymalizacja
zakresu
Pracochłonność
Klient
Optymalizacja
zasobów
Funkcjonalność
Produktywność
Ludzie
Czas trwania
Trójkąty równowagi w projekcie
Stały zakres
Jakość
Optymalizacja
zakresu
Pracochłonność
Klient
Optymalizacja
zasobów
Funkcjonalność
Produktywność
Ludzie
Czas trwania
Trójkąty równowagi w projekcie
Pytanie: Jaki będzie koszt wytworzenia
systemu?
Stały zakres
Jakość
Optymalizacja
zakresu
Pracochłonność
Klient
Optymalizacja
zasobów
Funkcjonalność
Produktywność
Ludzie
Czas trwania
Trójkąty równowagi w projekcie
Stała cena
Jakość
Optymalizacja
zakresu
Pracochłonność Klient
Optymalizacja
zasobów
Funkcjonalność
Produktywność
Ludzie
Czas trwania
Trójkąty równowagi w projekcie
Stała cena
Jakość
Optymalizacja
zakresu
Pracochłonność Klient
Optymalizacja
zasobów
Funkcjonalność
Produktywność
Ludzie
Czas trwania
Trójkąty równowagi w projekcie
Pytanie: Czy i w jakim stopniu będę w
stanie rozwiązać mój problem?
Stała cena
Jakość
Optymalizacja
zakresu
Pracochłonność Klient
Funkcjonalność
Produktywność
Ludzie
?
Optymalizacja
zasobów
Czas trwania
Wybór metody szacowania
•
•
•
•
Model finansowania projektu
Dziedzina oraz rodzaj produktów
Różne etapy szacowania
Różny poziom samoświadomości organizacji
Dziedzina i rodzaj produktów
• Software
– Standardowe
– Półstandardowe
– Innowacyjne
• Hardware
• Mieszane
Wybór metody szacowania
•
•
•
•
Model finansowania projektu
Dziedzina oraz rodzaj produktów
Różne etapy szacowania
Różny poziom samoświadomości organizacji
Szacowanie na różnych etapach
Planowanie
projektu
Krótka
perspektywa
Planowanie wydania
czasowa (stała)
~Stały zespół
Niezależne zadania o
podobnej złożoności
Miara „Velocity”
Zadanie
Zadanie
Zadanie
Szacowanie na różnych etapach
Planowanie projektu
Planowanie wydania
Produkt
Produkt
Zadanie
Zadanie
Zadanie
Szacowanie na różnych etapach
Planowanie projektu
Produkt
Planowanie wydania
Produkt niedokreślony
Produkt
Ryzyka, zmiany…
Pytanie o wykonalność
Agile - Scrum, XP, …
Planowanie projektu
Planowanie wydania
Produkt
Produkt
Zadanie
Zadanie
Zadanie
Stożek niepewności B. Boehma
Barry Boehm et al. Cost Models for Future Software Life Cycle Processes: COCOMO
Stożek niepewności B. Boehma
Barry Boehm et al. Cost Models for Future Software Life Cycle Processes: COCOMO
Wybór metody szacowania
•
•
•
•
Model finansowania projektu
Dziedzina oraz rodzaj produktów
Różne etapy szacowania
Różny poziom samoświadomości organizacji
Proces szacowania kosztów
Jak wygląda typowy
proces szacowania
kosztów?
32
Systematyczne podejście do planowania
Szacowanie
rozmiaru
Szacowanie
pracochłonności
Szacowanie
budżetu
i harmonogramu
Plan wykładu
• Wprowadzanie
• Rozmiar oprogramowania – punkty funkcyjne
• Szacowanie pracochłonności
– Miary dokładności szacowania pracochłonności
– Przegląd metod szacowania pracochłonności
• Przez analogię
• Eksperckie
• Algorytmiczne
• Harmonogram i budżet
Rozmiar oprogramowania
Miary kodu
Miary
funkcjonalności
35
Allan Albrecht
• 1984 Function Points
Wejście
Wyjście
Zapytania
Pliki
wewnętrzne
Pliki zewnętrzne
36
Allan Albrecht
• 1984 Function Points
Niska, średnia, wysoka
Wejście
+14 czynników
technicznych
+/- 35%
Wyjście
Zapytania
Pliki
wewnętrzne
Pliki zewnętrzne
37
IFPUG
• International Function Point User Group
– Założona w 1986 roku
– Counting Practices Committee
– Counting Practices Manual (4.3.1)
– Certyfikacja
– ISO/IEC 20926:2009
http://www.ifpug.org/
38
IFPUG FPA 4.3.1
1. Gather the available documentation
2. Determine counting scope and boundary and
identify functional user requirements
3. Measure data functions
4. Measure transactional functions
5. Calculate functional size
6. Document and report
39
IFPUG FPA 4.3.1
1. Gather the available documentation
2. Determine counting scope and boundary
and identify functional user requirements
3. Measure data functions
4. Measure transactional functions
5. Calculate functional size
6. Document and report
40
Przykład: menadżer zadań
• Celem pomiaru jest:
– Dokonanie pomiaru rozmiaru funkcjonalnego
tworzonej aplikacji do delegowania zadań.
– Development project FP count – jest to nowo
tworzona aplikacja.
41
Przykład: menadżer zadań
• Zakres pomiaru:
– Wymagania zdefiniowane dla pierwszego
przyrostu tworzonego systemu:
•
•
•
•
dodawanie zadań,
wyświetlanie zadań
wyświetlanie liczby zadań dla osoby
przypisywanie osób do zadań
42
Przykład: menadżer zadań
• Granica systemu
– Zarządzanie zadaniami
należy do menadżera
zadań, natomiast
osobami zarządza
książka kontaktów
43
IFPUG FPA 4.3.1
1. Gather the available documentation
2. Determine counting scope and boundary and
identify functional user requirements
3. Measure data functions
4. Measure transactional functions
5. Calculate functional size
6. Document and report
44
IFPUG FPA 4.3.1
3. Measure data functions
45
Przykład: menadżer zadań
• Pliki logiczne
– zadanie + lokalizacje (lokalizacja bez zadania nie
ma znaczenia z punktu widzenia użytkownika)
– osoby
46
Przykład: menadżer zadań
• Internal Logical File (ILF)
• czy?
• External Interface File (EIF)
47
Przykład: menadżer zadań
• Data Element Type (DET)
– Nazwa
– Nazwa lokalizacji
– Termin
– Opis
– Imię i nazwisko
– Adres e-mail
– Telefon
– Adres
48
Przykład: menadżer zadań
• Data Element Type (DET)
– Nazwa
– Nazwa lokalizacji
– Termin
– Opis
– Imię i nazwisko
– Adres e-mail
– Telefon
– Adres
3xDET
2xDET
+1xDET
+1xDET
4xDET
49
Przykład: menadżer zadań
• Data Element Type (DET)
– Nazwa
– Nazwa lokalizacji
– Termin
– Opis
– Imię i nazwisko
– Adres e-mail
– Telefon
– Adres
6xDET
5xDET
50
Przykład: menadżer zadań
• Record Element Type
– podgrupa DET’ów,
która jest
rozpoznawalna przez
użytkownika.
2xRET
1xRET
51
Przykład: menadżer zadań
• ILF – ?
• EIF – ?
2xRET
6xDET
EIF/ILF
1xRET
5xDET
52
Przykład: menadżer zadań
• ILF – Low (7)
• EIF – Low (5)
2xRET
6xDET
EIF/ILF
1xRET
5xDET
53
IFPUG FPA 4.3.1
1. Gather the available documentation
2. Determine counting scope and boundary and
identify functional user requirements
3. Measure data functions
4. Measure transactional functions
5. Calculate functional size
6. Document and report
54
IFPUG FPA 4.3.1
4. Measure transactional functions
55
IFPUG FPA 4.3.1
• External Input
– Dokonuje modyfikacji danych w ILF
Dodaj fakturę
Faktura
56
IFPUG FPA 4.3.1
• External Inquiry
– Dane na zewnątrz bez przetwarzania
Pobierz fakturę
Faktura
57
IFPUG FPA 4.3.1
• External Output
– Dane na zewnątrz z przetwarzaniem
Faktura
Wyświetl łączną
wartość produktów na
fakturach w tym miesiącu
58
Przykład: menadżer zadań
• Elementarne procesy:
– dodawanie zadań,
– wyświetlanie zadań
– wyświetlanie liczby zadań dla osoby
– przypisywanie osób do zadań
EI | EQ | EO
EI | EQ | EO
EI | EQ | EO
EI | EQ | EO
59
Przykład: menadżer zadań
• Elementarne procesy:
– dodawanie zadań,
– wyświetlanie zadań
– wyświetlanie liczby zadań dla osoby
– przypisywanie osób do zadań
EI | EQ | EO
EI | EQ | EO
EI | EQ | EO
EI | EQ | EO
60
Przykład: menadżer zadań
• Liczba DET’ów:
– dodawanie zadań – 8x DET,
– wyświetlanie zadań – 12x DET,
– wyświetlanie liczby zadań dla osoby – 2x DET,
– przypisywanie osób do zadań – 3x DET,
62
Przykład: menadżer zadań
• Liczba plików logicznych:
– dodawanie zadań – 1x ILF,
– wyświetlanie zadań – 1x ILF + 1x EIF,
– wyświetlanie liczby zadań dla osoby – 1x ILF + 1x EIF,
– przypisywanie osób do zadań – 1x ILF + 1x EIF,
63
IFPUG FPA 4.3.1
4. Measure transactional functions
EI
EO/EQ
Niska, średnia, wysoka
64
Przykład: menadżer zadań
• Złożoność / rozmiar funkcjonalny:
– dodawanie zadań – low / 3,
– wyświetlanie zadań – average / 4,
– wyświetlanie liczby zadań dla osoby – low / 4,
– przypisywanie osób do zadań – low / 3,
65
IFPUG FPA 4.3.1
1. Gather the available documentation
2. Determine counting scope and boundary and
identify functional user requirements
3. Measure data functions
4. Measure transactional functions
5. Calculate functional size
6. Document and report
66
Przykład: menadżer zadań
• Rozmiar funkcjonalny:
DFP = 7 + 5 + 3 + 4 + 4 + 3 = 26
Funkcje danych
Funkcje transakcyjne
67
Plan wykładu
• Wprowadzanie
• Rozmiar oprogramowania – punkty funkcyjne
• Szacowanie pracochłonności
– Miary dokładności szacowania pracochłonności
– Przegląd metod szacowania pracochłonności
• Przez analogię
• Eksperckie
• Algorytmiczne
• Harmonogram i budżet
Dokładność a precyzja
Lepsze oszacowanie liczby Pi?
• 3,143323223214141
• 3,14
Precyzja
Dokładność
69
Miary oceny dokładności szacowania
Mean Magnitude of Relative Error
MMRE
Miary oceny dokładności szacowania
Prediction Quality
Pred
e - estimation error level
k - number of projects with error (MRE) <= e
n - number of projects considered
Plan wykładu
• Wprowadzanie
• Rozmiar oprogramowania – punkty funkcyjne
• Szacowanie pracochłonności
– Miary dokładności i rodzaje rezultatów
– Przegląd metod szacowania pracochłonności
• Przez analogię
• Eksperckie
• Algorytmiczne
• Harmonogram i budżet
Klasyfikacja metod szacowania
Metody
szacowania
Analogia
Eksperckie
Algorytmiczne
Parametryczne
Hybrydowe
Nieparametryczne
Klasyfikacja metod szacowania
Metody
szacowania
Analogia
Eksperckie
Algorytmiczne
Parametryczne
Hybrydowe
Nieparametryczne
Analogia
Nowy projekt:
Pracochłonność
Kontekst
?
Sklep internetowy. Python, Django.
Umiejętności programistyczne: Średnie
Baza historyczna:
Pracochłonność
Rozmiar
Kontekst
1000 [h]
30 FP
Sklep internetowy. Java, Servlets, JSP.
programistyczne: Wysokie
600 [h]
20 FP
Prosty CMS. PHP. Umiejętności
programistyczne: Wysokie
1300 [h]
30 FP
Sklep internetowy. PHP. programistyczne:
Średnie
…
Analogia
Nowy projekt:
Pracochłonność
Kontekst
1300 [h]
Sklep internetowy. Python, Django.
Umiejętności programistyczne: Średnie
Baza historyczna:
Pracochłonność
Rozmiar
Kontekst
1000 [h]
30 FP
Sklep internetowy. Java, Servlets, JSP.
programistyczne: Wysokie
600 [h]
20 FP
Prosty CMS. PHP. Umiejętności
programistyczne: Wysokie
1300 [h]
30 FP
Sklep internetowy. PHP. programistyczne:
Średnie
…
Analogia
Nowy projekt:
Pracochłonność
Kontekst
Średnia 1092 ±72 (95%)
< 1020 ; 1164 >
Sklep internetowy. Python, Django.
Umiejętności programistyczne: Średnie
Pracochłonność projektów podobnych:
1400
Normal Q-Q Plot
1200
1100
1000
900
Sample Quantiles
1300
840, 920, 930, 1020, 1030, 1022, 1030, 1100, 1200, 1300, 1400,
1200, 1110, 1100, 1050, 1120, 1200
Średnia jako estymator
-2
-1
0
Theoretical Quantiles
1
2
Analogia
Nowy projekt:
Pracochłonność
Kontekst
Min = 1066 [h]
Max = 1386 [h]
Sklep internetowy. Python, Django.
Umiejętności programistyczne: Średnie
Baza historyczna:
Pracochłonność
Rozmiar
Kontekst
1000 [h]
30 FP
Sklep internetowy. Java, Servlets, JSP.
programistyczne: Wysokie
600 [h]
20 FP
Prosty CMS. PHP. Umiejętności
programistyczne: Wysokie
1300 [h]
30 FP
Sklep internetowy. PHP. programistyczne:
Średnie
Analogia
Nowy projekt:
Pracochłonność
Kontekst
?
Sklep internetowy. Python, Django.
Umiejętności programistyczne: Średnie
Pracochłonność projektów podobnych:
840, 920, 930, 1020, 1030, 1022, 1030, 1100, 1200, 1300, 1400,
1200, 1110, 1100, 1050, 1120, 1200
Analogia
Jest 80% szans, że
pracochłonność nie
będzie większa niż 1200h
0.8
0.6
0.4
0.2
0.0
prawdopodobieństwo
1.0
cdf
600
800
1000
1200
pracochłonność [h]
n:17 m:0
1400
1600
Analogia
0.8
0.6
0.4
0.2
0.0
prawdopodobieństwo
1.0
cdf
600
800
1000
1200
pracochłonność [h]
n:10000 m:0
1400
1600
Klasyfikacja metod szacowania
Metody
szacowania
Analogia
Eksperckie
Algorytmiczne
Parametryczne
Hybrydowe
Nieparametryczne
Wideband Delphi
Moderator
Eksperci
Wideband Delphi
Przygotowanie indywidualne
Moderator
Eksperci
Wideband Delphi
Dyskusja
Moderator
Eksperci
Wideband Delphi
Moderator
Anonimowa ocena
ekspertów
Eksperci
Wideband delphi – karta oceny
Data: 05.07.2006
Ekspert: Jan Kowalski
Projekt: Internet e-shop system
300
600
900
1200
- Estymacja
- Twoja estymacja
- Średnia estymacja
1400
Twoja estymacja: ..................... LOC
Będzie problem z technologiami
Uzasadnienie....................................................
1500
LOC
Wideband Delphi
Moderator
Moderator opracowuje
wyniki z kart oceny
Eksperci
Wideband delphi – karta oceny
Data: 05.07.2006
Ekspert: Jan Kowalski
Projekt: Internet e-shop system
300
600
900
1200
- Estymacja
- Twoja estymacja
- Średnia estymacja
1400
Twoja estymacja: ..................... LOC
Będzie problem z technologiami
Uzasadnienie....................................................
1500
LOC
Wideband Delphi
Moderator
Eksperci otrzymują swoje
karty z powrotem
Eksperci
Wideband Delphi
Następna runda albo:
Moderator
Effort= (O + 4A + P) / 6
Eksperci
The Work Breakdown Structure - WBS
• Hierarchiczny pracy do wykonania – tu
skończyłem!!!!
WBS – Elementy struktury
Poziom #0
Cel do osiągnięcia
Cel
WBS – Elementy struktury
Poziom #0
Poziom #1
Cel
Czynność
Czynność – fragment
pracy do wykonania na
wysokim poziomie
abstrakcji
Czynność
WBS – Elementy struktury
Poziom #0
Cel
Poziom #1
…
Czynność
…
Dalsza dekompozycja
Czynność
…
…
WBS – Elementy struktury
Poziom #0
Cel
#1
ZadanieLevel
– najmniejszy
fragment pracy (work
package)
…
…
Level #m
Czynność
Zadanie
#1
Czynność
…
…
Zadanie
#2
Zadanie
#n
WBS – Elementy struktury
Poziom #0
Cel
Level #1
…
Level #m
Czynność
…
Czynność
…
…
Czynność
na poziomie
N jest
ukończona jeśli wszystkie
Zadanie zdekomponowane
Zadanie
Zadanie
czynności na
#1
#2
#n
poziomie N+1 są ukończone
Podejścia do budowy WBS
Rzeczowniki –
reprezentują wynik
KAWA
ZIARNA
Wsyp
FILIŻANKA
Zmiel
Umyj
Rozgrzej
Czasowniki reprezentują
czynności
WODA
Ugotuj
Mieszaj
Wlej
Podejścia do budowy WBS
Rzeczowniki –
reprezentują wynik
KAWA
FILIŻANK
A
ZIARNA
Kawa
wsypana
Zmielone
ziarna
Filiżanka
umyta
Filiżanka
rozgrzana
WODA
Woda
zagotowana
Kawa
zamieszana
Woda wlana
do filiżanki
Podejścia do budowy WBS
Top-down - Dekompozycja
KAWA
FILIŻANK
A
ZIARNA
Kawa
wsypana
Zmielone
ziarna
Filiżanka
umyta
Filiżanka
rozgrzana
Bottom-up – Burza mózgów
WODA
Woda
zagotowana
Kawa
zamieszana
Woda wlana
do filiżanki
Przykład
KAWA
ZIARNA
FILIŻANKA
Kawa
zamieszana
WODA
1’
Kawa
wsypana
1’
Zmielone
ziarna
2’
Filiżanka
umyta
2’
Filiżanka
rozgrzana
15’
Woda
zagotowana
3’
Woda wlana
do filiżanki
1’
Przykład
3’
ZIARNA
FILIŻANKA
KAWA
25’
17’
4’
Kawa
zamieszana
WODA
1’
Kawa
wsypana
1’
Zmielone
ziarna
2’
Filiżanka
umyta
2’
Filiżanka
rozgrzana
15’
Woda
zagotowana
3’
Woda wlana
do filiżanki
1’
Kryteria dobrze zdefiniowanej czynności / zadania
•
•
•
•
•
•
Mierzalny status
Zdefiniowane zdarzenia rozpoczęcia / zakończenia
Zdefiniowany rezultat
Oszacowany czas / koszt
Akceptowalny czas wykonania
Niezależność
103
Klasyfikacja metod szacowania
Metody
szacowania
Analogia
Eksperckie
Algorytmiczne
Parametryczne
Hybrydowe
Nieparametryczne
Metoda COCOMO II
PMNS = A  SizeE  i=116 EMi
gdzie E = B + 0.01  i=15 SFi
Size w KSLOC
Wartości A, B skalibrowane na podstawie 161 projektów:
A = 2.94
B = 0.91
Dla przeciętnego projektu EMi = 1.
0  i=15 SFi  31.6
PMNS = 2.94  SizeE
gdzie 0.91  E  1.226
Barry W. Boehm
Wpływ czynników skali, SF, na pracochłonność
E= 1.226
E= 1
E= 0.91
Use Case Points (UCP)
4
Gustav Karner (1993)
C#
C++
Java
Technical Complexity
Factors
5
Environment Factors
System informatyczny
1
3
Aktorzy
UC1
UC1
UC1
2
Przypadki użycia
Użytkownicy
Metoda punktów przypadków użycia
Use Case Points (UCP)
Gustav Karner (1993)
Aktorzy Klasyfikacja do klasy złożoności na podstawie typu
(UAW) interfejsu służącego do komunikacji z systemem
1 punkt: Prosty - zdefiniowane API
2 punkt : Średni - TCP/IP lub tekst
Złożoność 3 punkt : Złożony - GUI
aktora
C++
4
C#
Java
Technical Complexity
Factors
5
Environment Factors
Software System
1
3
UC1
UC1
UC1
2
Use Cases
Actors
Users
Use Case Points (UCP)
Gustav Karner (1993)
Aktorzy Klasyfikacja do klasy złożoności na podstawie typu
(UAW) interfejsu służącego do komunikacji z systemem
Use Cases Klasyfikacja do trzech klas złożoności na podstawie
(UUCW) liczby transakcji
UC1
C++
4
Złożoność
przypadku użycia
C#
Java
Technical Complexity
Factors
5
Environment Factors
Software System
5 points : Prosty – do 3 transakcji
10 points : Średni – 4-7 transakcji
15 points : Złożony – ponad 7 transakcji
1
3
UC1
UC1
UC1
2
Use Cases
Actors
Users
UUCP = UAW+UUCW
Transakcje w przypadkach użycia
1. Autor wybiera opcję zgłoszenia artykułu.
Interakcja
2. System prosi o podanie danych artykułu.
Ile transakcji?
UC1: Zgłoś artykuł
Poziom: Użytkownika
Aktor główny: Autor
Scenariusz główny:
1. Autor wybiera opcję zgłoszenia artykułu.
2. System prosi o podanie danych artykułu.
3. Autor podaje wymagane dane na temat artykułu.
4. System informuje o pomyślnym zgłoszeniu artykułu.
Scenariusze alternatywne i rozszerzenia:
1.A. Author chciałby zgłosić zmienioną wersję artykułu.
1.A.1. Autor wybiera opcję ponownego zgłoszenia swoich artykułów.
1.A.2. System prezentuje artykuły zgłoszone dotychczas przez Autora.
1.A.3. Autor wybiera jeden z artykułów oraz opcję jego ponownego zgłoszenia.
1.A.4. Przejdź do kroku 2.
112
Use Case Points (UCP)
Gustav Karner (1993)
Aktorzy Klasyfikacja do klasy złożoności na podstawie typu
(UAW) interfejsu służącego do komunikacji z systemem
Use Cases Klasyfikacja do trzech klas złożoności na podstawie
(UUCW) liczby transakcji
Technical Complexity 13 czynników, których wpływ na projekt oceniany
Factors (TCF) jest w skali 0-5
C++
4
C#
Java
Technical Complexity
Factors
5
Environment Factors
Environmental 8 czynników, których wpływ na projekt oceniany jest
Factors (EF) w skali 0-5
Software System
1
3
UC1
UC1
UC1
2
Use Cases
Actors
Users
Czynniki techniczne (Technical Factors)
TFactor = ∑ ei Ti
ei = 0, 1, .., 5
T1 System rozproszony
2
T2 Wydajność
2
T3 Wydajności z pkt użytkownika1
T4 Złożoność przetwarzania
1
T5 Reużywalność kodu
1
T6 Łatwość instalacji
0.5
T7 Łatwość użycia
0.5
T8 Przenośność
2
T9 Łatwość zmiany
1
T10 Współbieżność
1
T11 Bezpieczeństwo (security)
1
T12 Dostęp stron trzecich
1
T13 Wymagane spec. szkolenia 1
Czynniki środowiska (Environment Factors)
F1 Znajomość metodyki
F2 Doświadczenie w aplikacji
F3 Doświadczenie w obiektowości
F4 Możliwości gł. analityka
F5 Motywacja
F6 Stabilne wymagania
F7 Pracownicy na część etatu
F8 Trudny język programowania
EFactor = ∑ ei Fi
ei = 0, 1, .., 5
1.5
0.5
1
0.5
1
2
-1
-2
Use Case Points (UCP)
Gustav Karner (1993)
Aktorzy Klasyfikacja do klasy złożoności na podstawie typu
(UAW) interfejsu służącego do komunikacji z systemem
Use Cases Klasyfikacja do trzech klas złożoności na podstawie
(UUCW) liczby transakcji
Technical Complexity 13 czynników, których wpływ na projekt oceniany
Factors (TCF) jest w skali 0-5
C++
4
C#
Java
Technical Complexity
Factors
5
Environment Factors
Environmental 8 czynników, których wpływ na projekt oceniany jest
Factors (EF) w skali 0-5
Software System
1
3
UC1
UC1
UC1
2
Actors
Users
UCP = (UAW+UUCW) x TCF x EF
Use Cases
TCF= 0,6 + (0,01*TFactor) EF= 1,4 + (-0,03*EFactor)
Use Case Points (UCP)
Gustav Karner (1993)
Effort = UCP x PF
Productivity Factor
(domyślnie 20 h/UCP, należy
skalibrować na podstawie danych
historycznych) – typowo <10,30>
Model parametryczny
Regresja liniowa
UCP a pracochłonność
4000
R² = 0,9277
3500
3000
2500
Effort
2000
Linear (Effort)
1500
1000
500
0
0
20
40
60
80
100
120
140
Klasyfikacja metod szacowania
Metody
szacowania
Analogia
Eksperckie
Algorytmiczne
Parametryczne
Hybrydowe
Nieparametryczne
Plan wykładu
• Wprowadzanie
• Rozmiar oprogramowania – punkty funkcyjne
• Szacowanie pracochłonności
– Miary dokładności szacowania pracochłonności
– Przegląd metod szacowania pracochłonności
• Przez analogię
• Eksperckie
• Algorytmiczne
• Harmonogram i budżet
Harmonogramowanie
• Czas realizacji a pracochłonność
• Liczba wykonawców
• Zależności między zadaniami
Czas realizacji a pracochłonność
• Jaka byłaby pracochłonność (effort) i czas
realizacji (duration) zadania domowego:
– Napisz program obliczający silnię – n!
– Termin oddania 12 grudnia 2014
Czas realizacji:
1 tydzień
Pracochłonność:
10 minut?
Czas realizacji a pracochłonność
• Czas realizacji i pracochłonność nie muszą być
takie same!
Wysocki, R. K., & McGary, R. (2003). Effective project management: traditional, adaptive, extreme. Wiley.
Liczba wykonawców
• Czy czas realizacji zmniejszy się jak zwiększę
liczbę wykonawców?
Liczba wykonawców
• Wynieść krzesło z pokoju
Liczba wykonawców
• Wynieść krzesło z pokoju
Liczba wykonawców
• Wynieść krzesło z pokoju
Liczba wykonawców
• Wynieść krzesło z pokoju
Liczba wykonawców
• Wynieść krzesło z pokoju
– Podwójmy zasoby!
Liczba wykonawców
• Wynieść krzesło z pokoju
– Podwójmy zasoby!
Liczba wykonawców
• Wynieść krzesło z pokoju
– Podwójmy zasoby!
Liczba wykonawców
• Wynieść krzesło z pokoju
– Podwójmy zasoby!
Liczba wykonawców
• Wynieść krzesło z pokoju
– Podwójmy zasoby!
Crashpoint!
Liczba wykonawców
• Czy czas realizacji zmniejszy się jak zwiększę
liczbę wykonawców?
– Do pewnego momentu (zależy od zadania)
– Dodanie większej liczby osób - Crashpoint!
– Dodanie zbyt dużej liczby osób zwiększy
pracochłonność z uwagi na narzut na komunikację
Crashpoint!
Zależność między zadaniami
3’
ZIARNA
FILIŻANKA
KAWA
25’
17’
4’
Kawa
zamieszana
WODA
1’
Kawa
wsypana
1’
Zmielone
ziarna
2’
Filiżanka
umyta
2’
Filiżanka
rozgrzana
15’
Woda
zagotowana
3’
Woda wlana
do filiżanki
1’
Zależność między zadaniami
Pracochłonność czy
czas realizacji?
3’
ZIARNA
FILIŻANKA
KAWA
25’
17’
4’
Kawa
zamieszana
WODA
1’
Kawa
wsypana
1’
Zmielone
ziarna
2’
Filiżanka
umyta
2’
Filiżanka
rozgrzana
15’
Woda
zagotowana
3’
Woda wlana
do filiżanki
1’
Jak stworzyć harmonogram?
Diagramy sieciowe i wykresy Gantta
Gantt chart
Network diagram
Precedence Diagramming Method
• Do tworzenia diagramów sieciowych
• Dwie wersje
– AOA – activity on the arrow (starsze)
– AON – activity on the node
PDM – activity node
•
•
•
•
•
•
•
ES – earliest start
EF – earliest finish
LS – latest start
LF – latest finish
E – duration
ID – id of task
Slack (luz)
PDM
1. Stwórz sieć bazując na zależnościach
– Jedno wejście
– Jedno wyjście
Zależność między zadaniami
Jaka zależność między
zadaniami?
3’
ZIARNA
FILIŻANKA
KAWA
25’
17’
4’
Kawa
zamieszana
WODA
1’
Kawa
wsypana
1’
Zmielone
ziarna
2’
Filiżanka
umyta
2’
Filiżanka
rozgrzana
15’
Woda
zagotowana
3’
Woda wlana
do filiżanki
1’
Zależność między zadaniami
• Kawa wsypana zależy od:
– FILIŻANKA
– Zmiel kawę
• Woda wlana do filiżanki zależy od:
– Woda zagotowana
– FILIŻANKA
– Kawa wsypana
• Kawa zamieszana zależy od:
– Woda wlana do filiżanki
– Kawa wsypana (?)
144
KAWA
Zagotowana
FILIŻANKA
Zmielona
WODA
PDM
Umyta
2
2
Wsypana
3
Rozgrzana
1
Wlana
15
1
Zamieszana
1
PDM
2. Stwórz wczesne uszeregowanie (forward pass)
– Pokazuje najwcześniejsze możliwe czasy kiedy
zadanie może się rozpocząć i zakończyć
PDM
2. Stwórz wczesne uszeregowanie (forward pass)
– ES input = 1
– EFA = ESA + EA - 1
– ESc = max{EFA, EFB} + 1
A
c
B
PDM
Zmielona
Zagotowana
FILIŻANKA
KAWA
?
WODA
?
Umyta
2
2
Wsypana
3
Rozgrzana
1
Wlana
15
1
Zamieszana
1
PDM
KAWA
1
2
WODA
Umyta
?
Wsypana
1
3
Zagotowana
1
FILIŻANKA
2
Zmielona
1
?
2
3
Wlana
3
2
Rozgrzana
17
15
1
Zamieszana
1
PDM
KAWA
1
2
WODA
Umyta
18
Wsypana
3
Zagotowana
1
FILIŻANKA
2
Zmielona
1
18
2
?
3
Wlana
3
2
1
Rozgrzana
17
15
?
1
Zamieszana
1
PDM
KAWA
1
2
WODA
Umyta
18
Wsypana
3
Zagotowana
1
FILIŻANKA
2
Zmielona
1
18
2
19
3
Wlana
3
2
1
Rozgrzana
17
15
19
1
20
Zamieszana
20
1
PDM
3. Stwórz późne uszeregowanie (backward pass)
– Pokazuje ostateczny czas rozpoczęcia i
zakończenia taki, który nie spowoduje opóźnienia
projektu
PDM
3. Stwórz późne uszeregowanie (backward pass)
– LF output = EF output
– LSA = LFA – EA + 1
– LFA = min{LSB, LSC} – 1
B
A
c
PDM
KAWA
1
2
2
Zmielona
WODA
1
18
18
Wsypana
3
Zagotowana
1
19
3
Wlana
19
1
20
FILIŻANKA
Umyta
2
3
2
Rozgrzana
17
15
1
Zamieszana
?
1
20
?
PDM
KAWA
1
2
2
Zmielona
WODA
1
18
18
Wsypana
3
Zagotowana
1
19
3
Wlana
19
1
20
FILIŻANKA
Umyta
2
3
2
Rozgrzana
17
15
1
Zamieszana
20
1
20
20
PDM
KAWA
1
2
18
2
Zmielona
18
Wsypana
?
WODA
1
FILIŻANKA
1
Umyta
?
3
Zagotowana
2
19
3
3
2
1
Rozgrzana
17
15
19
Wlana
1
19
19
20
20
1
Zamieszana
20
20
PDM
KAWA
1
2
18
2
Zmielona
18
Wsypana
18
WODA
1
FILIŻANKA
1
Umyta
18
3
Zagotowana
2
19
3
3
2
1
17
15
Rozgrzana
?
?
19
Wlana
1
19
19
20
20
1
Zamieszana
20
20
PDM
KAWA
1
2
2
Zmielona
16
WODA
16
2
19
3
3
2
1
18
18
2
Umyta
1
18
3
Zagotowana
1
18
Wsypana
17
1
FILIŻANKA
18
Rozgrzana
3
17
15
17
19
Wlana
1
19
19
20
20
1
Zamieszana
20
20
PDM
1
• Okno czasowe
2
Zmielona
16
17
Zmielona
1
17
Zmielona
1
…
2
17
PDM
4. Ścieżka krytyczna (critical path)
– Jakiekolwiek opóźnienie zadań na ścieżce
krytycznej spowoduje opóźnienie projektu
PDM
4. Ścieżka krytyczna (critical path)
– Ścieżka z najdłuższym czasem wykonania
– Activity Slack Time (przepływ) – tolerowana
wielkość opóźnienia startu lub zakończenia
zadania, która nie spowoduje opóźnienia
projektu
Slack (luz) = LF – EF
PDM
KAWA
1
2
2
Zmielona
16
WODA
16
2
19
3
3
2
1
18
18
2
Umyta
1
18
3
Zagotowana
1
18
Wsypana
17
1
FILIŻANKA
18
Rozgrzana
3
17
15
17
19
Wlana
1
19
19
20
20
1
Zamieszana
20
20
PDM
KAWA
1
2
Zmielona
16
WODA
1
Umyta
1
18
Wsypana
17
18
2
0 2
2
0 1
18
3
16
FILIŻANKA
15 2
Zagotowana
1
18
19
15 3
Wlana
18
19
3
17
Rozgrzana
0 15
3
17
19
0 1
19
20
Zamieszana
20
20
0 1
20
PDM
KAWA
1
2
Zmielona
16
WODA
1
Umyta
1
18
Wsypana
17
18
2
0 2
2
0 1
18
3
16
FILIŻANKA
15 2
Zagotowana
1
18
19
15 3
Wlana
18
19
3
17
Rozgrzana
0 15
3
17
19
0 1
19
20
Zamieszana
20
20
0 1
20
Opóźnienie tych zadań
opóźni projekt!
Koszt
• Wycena na podstawie rozmiaru
• Wycena na podstawie pracochłonności
• Wycena na podstawie czasu realizacji
– Odległość w czasie
– Konieczność utrzymania etatów
– Fazy realizacji projektu
165
Q&A time

Podobne dokumenty