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