Podstawy Inżynierii Oprogramowania. Wykład 9 Zarządzanie projektem

Transkrypt

1 Podstawy Inżynierii Oprogramowania Wykład 9 Zarządzanie projektem

2 Cel: Wyjaśnienie podstawowych czynności procesu zarządzania projektem informatycznym Wprowadzenie w pojęcia związane z planowaniem projektu i planowaniem procesu Omówienie graficznych reprezentacji harmonogramu Wprowadzenie w zagadnienia zarządzania ryzykiem czyli uzmysłowienie sobie dlaczego kierowanie projektami informatycznymi jest tak niewdzięcznym zadaniem

3 Zarządzenie projektem informatycznym Aktywności związane z zapewnianiem, że: oprogramowanie będzie dostarczone zgodnie z harmonogramem Oprogramowanie będzie spełniało wymagania Zarządzanie projektem jest potrzebne zawsze Tworzenie oprogramowania jest powiązane z kwestiami ekonomicznymi (budżet, harmonogram) 3

4 Problemy PM Produkt jest nieuchwytny Produkt jest unikatowy Inżynieria oprogramowania nie jest tak dobrze rozeznaną dziedziną jak np. mechanika, elektrotechnika Proces IO nie jest ustandaryzowany Wiele projektów cechuje się jednorazowością 4

5 Podstawowe pojęcia zarządzania projektami (1) Termin Projekt project Pod-projekt subproject Definicja Zbiór aktywności wykonywanych w określonym celu np. wytworzenia unikalnego produktu, usługi bądź rezultatu. Aktywności są tymczasowe, ponieważ mają zdefiniowany początek i koniec. Zakończenie aktywności zachodzi, gdy cel zostały osiągnięte lub stało się jasne, że nie zostały lub nie mogą zostać osiągnięte. Zbiór aktywności przypisanych pojedynczej jednostce organizacji projektu w celu podzielenia projektu na łatwiejsze do zarządzania komponenty. Program program Grupa powiązanych projektów zarządzana w sposób skoordynowany w celu osiągnięcia większych korzyści oraz kontroli niż w przypadku zarządzania indywidualnego. 5

6 Podstawowe pojęcia zarządzania projektami (2) Termin Zarządzanie projektem project management Definicja Stosowanie wiedzy, zdolności, narzędzi i technik do aktywności projektowych w celu osiągnięcia celów projektu Portfel portfolio Kolekcja programów projektów oraz innych prac, zgrupowanych w celu ułatwienia procesu efektywnego zarządzania nimi dla osiągnięcia strategicznych celów biznesowych Zarządzanie portfelem portfolio management Scentralizowane zarządzanie jednym lub wieloma portfelami z uwzględnieniem identyfikacji, priorytetyzacji, autoryzacji, zarządzania oraz kontroli projektów, programów oraz innych zadań w celu osiągnięcia strategicznych celów biznesowych 6

7 Podstawowe pojęcia zarządzania projektami (3) Termin Stopniowe dopracowywanie progressive elaboration Definicja Ciągły proces udoskonalania planów wraz z napływem bardziej szczegółowych danych i oszacowań w trakcie trwania projektu. Celem jest iteracyjne opracowywanie bardziej precyzyjnych planów przedsięwzięcia. Biuro zarządzania projektem Project Management Office (PMO) Sponsor Ciało organizacyjne odpowiedzialne za scentralizowane i skoordynowane zarządzanie podległymi projektami. Osoba lub organizacja władna wykonywać, zlecać lub zapewniać ukończenie następujących zobowiązań projektowych: - Formalizacja powiązania z dostawcą rozwiązania - Zatwierdzenie momentu rozpoczęcia procesu i/lub poszczególnych jego faz - Akceptacja efektów projektu - Pokrywanie kosztów projektu, lub jego faz 7

8 Proces zarządzania projektem (PMP) Projekt składa się z procesów Proces jest serią aktywności, w efekcie których otrzymujemy rezultat Proces zorientowany na produkt powiązany jest z opracowaniem specyfikacji oraz wytworzeniem produktu procesu Proces zarządzania projektem oraz proces zorientowany na produkt nakładają się na siebie i współdziałają przez cały czas życia projektu 8

9 Czynności PM Definicja systemu Planowanie i harmonogramowanie projektu Kosztorysowanie projektu Monitorowanie i przeglądy Wybór i ewaluacja personelu Raportowanie i prezentacje 9

10 Kierownik projektu Kierownik projektu reprezentuje pojedynczy punkt kontaktowy w projekcie Jest osobiście odpowiedzialny za: Planowanie i organizacje prac Zarządzanie codziennymi aktywnościami wykonywanymi w ramach projektu Dostarczaniem efektów projektu (do klientów) Identyfikacją grup zainteresowania 10

11 Wartość kierownika projektu Kierownik projektu zwiększa prawdopodobieństwo tego, że projekt: Wytworzy produkty odpowiedniej jakości Zostanie ukończony zgodnie z harmonogramem Zostanie ukończony w ramach budżetu Spełni wymagania klientów Osiągnie sukces 11

12 Personel Częstym problemem jest brak możliwości zebrania odpowiedniego zespołu Budżet nie pozwala Brak odpowiednich ludzi Polityka organizacji Kierownik projektu musi sobie samodzielnie radzić z takimi problemami 12

13 Planowanie projektu Najbardziej czasochłonny element zarządzania. Aktywność ciągła. Regularne aktualizacje. Potrzeba istnienia wielu planów. 13

14 Rodzaje planów Plan jakości Procedury oraz standardy jakości wykorzystywane w projekcie Plan walidacji Podejście do walidacji, harmonogram, potrzebne zasoby Plan zarządzania konfiguracją Procedury i struktury zarządzania konfiguracją Plan konserwacji Przewidywania wymagań pielęgnacyjnych, kosztów, nakładu pracy Plan zatrudnienia W jaki sposób rozwijane będą umiejętności i doświadczenie zespołu. 14

15 Proces planowania projektu 1. Określenie ograniczeń projektu 2. Zebranie początkowych parametrów projektu 3. Zdefiniowanie kamieni milowych oraz produktów 4. Dopóki projekt nie zakończony wykonuj w pętli: a. Narysuj harmonogram projektu b. Zainicjuj aktywności zgodnie z harmonogramem c. Czekaj d. Dokonaj przeglądu projektu e. Przejrzyj oszacowania i parametry projektu f. Zaktualizuj harmonogram g. Re-negocjuj ograniczenia projektu oraz produkty h. Jeżeli pojawi się problem -> rozpocznij przegląd techniczny i dokonaj rewizji projektu 15

16 Proces planowania projektu Określenie ograniczeń Definicja początkowych parametrów Definicja kamieni milowych i produktów Określenie harmonogramu Inicjalizacja czynności projektowych Renegocjacja ograniczeń projektu Aktualizacja harmonogramu Przegląd parametrów Przegląd projektu Oczekiwanie Problem? Przegląd techniczny Rewizja projektu 16

17 Struktura planu projektu Wprowadzenie Organizacja projektu Analiza zagrożeń Wymagania sprzętowe i narzędziowe Podział pracy Harmonogram projektu Mechanizmy monitorowania i raportowania 17

18 Organizacja aktywności projektowych Aktywności projektowe powinny być tak zorganizowane aby produkowały jednoznaczne rezultaty w mierzalnej formie. Kamienie milowe (milestones) końcowe punkty aktywności Produkty (deliverables) rezultaty projektu dostarczane użytkownikom Kamienie milowe najprościej jest określać na podstawie modelu kaskadowego 18

19 Harmonogramowanie projektu schedule Podział projektu na zadania oraz szacowanie czasu i wymaganych zasobów potrzebnych do realizacji każdego z nich Dla optymalnego wykorzystania zasobów ludzkich powinny być organizowane równolegle Zależności pomiędzy zadaniami powinny być minimalizowane Zależne od intuicji i doświadczenia kierownika

20 Proces harmonogramowania Identyfikacja czynności Identyfikacja zależności Szacowanie zasobów dla czynności Alokacja zasobów Opracowanie wykresów Wymagania Diagramy aktywności Diagramy paskowe 20

21 Problemy harmonogramowania Szacowanie jest trudnym zadaniem Produktywność nie jest proporcjonalna do liczności personelu Adding manpower to a late software project makes it later (Frederick P. Brooks Jr.) Rzeczy nieoczekiwane zawsze się zdarzają! Harmonogram powinien uwzględniać taką ewentualność (ryzyko) 21

22 Wykresy paskowe i diagramy aktywności Notacja graficzna dla prezentacji harmonogramu Pokazuje projekt podzielony na zadania. Nie powinny być zbyt drobnoziarniste (optymalnie 1-2 tygodnie) Sieci aktywności pokazują zależności pomiędzy zadaniami oraz ścieżki krytyczne Wykresy paskowe pokazują harmonogram w kontekście kalendarzowym 22

23 Czas trwania i zależności pomiędzy zadaniami Zadanie Czas (dni) Zależności T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8) 23

24 Sieci aktywności 15 dni 8 dni 15 dni 5 dni 15 dni 20 dni 7 dni 10 dni 10 dni 15 dni 25 dni 24

25 Diagram Gantta 4/7 11/7 18/7 2 5/7 1/8 8/8 1 5/8 22/8 2 9/8 5/9 12/9 1 9/9 T4 T1 T2 Star t M1 T7 T3 M5 T8 M3 M2 T6 T5 T9 M4 M7 T10 T11 M6 M8 T12 Finish 25

26 Przydzielenie personelu do zadań 4/7 1 1/7 18/7 2 5/7 1/8 8/8 15/8 2 2/8 2 9/8 5/9 1 2/9 19/9 Fred Jane Anne T4 T1 T2 T3 T8 T6 T9 T10 T11 T12 Jim T7 Mary T5 26

27 Ryzyko/Zagrożenie Ryzyko jest to zmienna, która może zagrozić lub nawet uniemożliwić zakończenie projektu z sukcesem. Wszystko to co może stanąć nam na drodze do sukcesu a jest obecnie nieznane lub niepewne. Ryzyko może być: Bezpośrednie na które mamy wpływ. Pośrednie na które wpływu nie mamy (lub nasz wpływ może być minimalny). 27

28 Harmonogram a ryzyko Doświadczenie pokazuje, że 85% zagrożeń ma bezpośredni lub pośredni wpływ na harmonogram. Tylko ok. 5% ma wpływ tylko na koszty. Niektóre projekty mają sztywno ograniczony czas (drop-dead). Konkurencja, która zrobi to szybciej Finansowanie unijne 28

29 Zarządzanie ryzykiem Identyfikacja oraz określanie planów minimalizacji wpływu zagrożeń na powodzenie projektu Proces: Identyfikacja Identyfikacja zagrożeń produktu, procesu i biznesu Analiza Prawdopodobieństwo i wpływ na projekt Planowanie Plan minimalizacji wpływu Monitoring Monitoring zagrożeń w czasie trwania projektu 29

30 Proces zarządzania ryzykiem Identyfikacja zagrożeń Analiza zagrożeń Planowanie Monitoring Lista potencjalnych zagrożeń Priorytetyzowana lista zagrożeń Plan minimalizacji wpływu Ocena zagrożeń 30

31 Identyfikacja zagrożeń Typy zagrożeń Technologiczne Technologia (stabilność, bezpieczeństwo, nietypowe wymagania techniczne) Zależności zewnętrzne (gotowe elementy, równoległe projekty, integracja narzędzi) Organizacyjne/biznesowe Konkurencja, wartość projektu a jego koszty, dostępność poddostawców Związane z wymaganiami Stabilność wymagań, możliwość pomiaru Szacowania Dostępności zasobów, personelu, budżetu, wymagań szkoleniowych

32 Analiza zagrożeń Prawdopodobieństwo pojawienia się Wysokie (High) Znaczące (Significant) Umiarkowane (Moderate) Niewielkie (Minor) Niskie (Low) Efekt (wpływ na projekt) Katastroficzny, poważny, tolerowalny, nieznaczący 32

33 Analiza ryzyka przykład (1) Ryzyko Problemy finansowe organizacji redukcja budżetu projektu Prawdopod obieństwo Niskie Efekt Katastroficzny Brak odpowiednio wykształconego personelu Wysokie Katastroficzny Kluczowi pracownicy chorują w krytycznym momencie Umiarkowane Poważny Komponenty ponownego użycia zawierają błędy ograniczające ich funkcjonalność Proponowane są zmiany w wymaganiach, które powodują potrzebę dużych zmian w projekcie Umiarkowane Umiarkowane Poważny Poważny Organizacja jest w trakcie restrukturyzacji, co powoduje zmiany w kadrze zarządzającej projektem Wysokie Poważny 33

34 Analiza ryzyka przykład (2) Ryzyko Wykorzystywana baza danych nie jest w stanie przetwarzać wymaganej liczby transakcji na sekundę Prawdopodobień stwo Średnie Efekt Poważny Czas potrzebny na budowę systemu jest niedoszacowany Wysokie Poważny Narzędzia CASE nie integrują się Wysokie Tolerowalny Klienci nie są w stanie zrozumieć wpływu zmian w wymaganiach na projekt Umiarkowane Tolerowalny Brak możliwości szkolenia personelu Umiarkowane Tolerowalny Rozmiar oprogramowania jest niedoszacowany Wysokie Tolerowalny Kod generowany przez narzędzi CASE jest mało wydajny Średnie Nieznaczący 34

35 Planowanie Kluczowa idea: Atakuj ryzyko zanim ono zaatakuje Ciebie! Opracuj strategię zarządzania ryzykiem. Unikanie ryzyka Reorganizacja projektu aby ryzyko nie miało wpływu Transfer ryzyka Przeniesienie ryzyka na kogoś innego (klienta, bank, itp.) Akceptacja ryzyka Akceptujemy ryzyko jako ewentualność, która może się pojawić (migracja ryzyka, plan awaryjny) 35

36 Strategie zarządzania ryzykiem (1) Ryzyko Problemy organizacyjne i finansowe Problem wymagań Choroby personelu Psujące się komponenty Strategia Przygotuj dokument dla zarządu pokazujący w jaki sposób projekt realizuje najistotniejsze cele biznesowe i stanowi dla nich znaczącą wartość dodaną Zawiadom klientów o potencjalnych problemach i opóźnieniach, zbadaj możliwość dostarczenia funkcjonalności poprzez gotowe elementy Zreorganizuj projekt w taki sposób aby prace mocniej na siebie nachodziły, tak żeby pracownicy wiedzieli co robią inni Zastąp niestabilne komponenty innymi, bardziej wiarygodnymi 36

37 Strategie zarządzania ryzykiem (2) Ryzyko Zmiany w wymaganiach Restrukturyzacja organizacji Wydajność bazy danych Strategia Wypracuj dane o zależnościach aby określić wpływ zmian, zmaksymalizuj dekompozycję projektu na niezależne elementy Przygotuj dokument dla zarządu pokazujący w jaki sposób projekt realizuje najistotniejsze cele biznesowe i stanowi dla nich znaczącą wartość dodaną Zbadaj możliwość zakupienia bardziej wydajnej bazy danych Niedoszacowany czas produkcji Zbadaj możliwość wykorzystania gotowych komponentów, generatorów 37

38 Monitoring zagrożeń Regularne dokonywanie oceny każdego zagrożenia Jak zmienia się prawdopodobieństwo? Jak zmienia się wpływ na projekt? Każde zagrożenie powinno być przedyskutowane po zakończeniu etapu prac 38

39 Wskaźniki zagrożeń Technologiczne Zasoby ludzkie Narzędzia Organizacja Wymagania Oszacowania Ryzyko Potencjalny wskaźnik Opóźniona dostawa sprzętu, oprogramowania narzędziowego, duża liczba raportowanych problemów technologicznych Niskie morale, słaba komunikacja pomiędzy członkami zespołu, dostępność innego zatrudnienia Niechęć do korzystania z narzędzi, narzekania na narzędzia, wymagania co do wydajniejszych stacji roboczych Plotki, brak aktywności kadry zarządczej Duża liczba zmian w wymaganiach, narzekania klientów Niedotrzymywanie harmonogramu, nieudane poprawy błędów 39

40 Inżynierskie kompromisy (1) Trójkąt kompromisu (tradeoff triangle) Zasoby Cechy Harmonogram Istnieje bezpośrednia zależność pomiędzy zakresem (cechami systemu) a zasobami i harmonogramem przedsięwzięcia Kluczem do sukcesu jest odpowiednia równowaga pomiędzy zasobami, datą dostarczenia i cechami systemu. 40

41 Inżynierskie kompromisy (2) Macierz kompromisu (tradeoff matrix) Zasoby Stała Określona Zmienna Harmonogram Cechy Przyjmując stałe/y. wybierzemy określone/y. i w razie potrzeby zmodyfikujemy 41

42 Podsumowanie Dobre zarządzanie projektem jest kluczem do powodzenia projektu Nieuchwytna natura oprogramowania powoduje problemy zarządzania Kierownik projektu ma wiele zadań, ale do podstawowych należą planowanie, szacowanie i harmonogramowanie Planowanie i szacowanie są procesami iteracyjnymi. Kamień milowy projektu to możliwy do określenia i przewidzenia stan, który jest podstawą do utworzenia formalnego raportu z postępów 42

43 Podsumowanie Harmonogramowanie projektu wymaga utworzenia graficznych reprezentacji aktywności projektu, czasu jego trwania oraz zatrudnienia (przydzielenia zasobów do zadań) Zarządzanie ryzykiem związane jest z identyfikacją zagrożeń, które mogą utrudnić wykonanie projektu oraz opracowaniem planów, które zapobiegną negatywnym wpływom zmaterializowanych zagrożeń. 43

44 Do poczytania Sommerville: Inżynieria Oprogramowania, rozdział 4. Dąbrowski, Subieta: Podstawy Inżynierii Oprogramowania, rozdział 2. Barry W. Boehm Software Risk Management: Principles and Practices, IEEE Software, Jan. 1991, IEEE, pp Marvin J. Carr, et al Taxonomy-Based Risk Identification, Technical Report CMU/SEI-93-TR-6, Pittsburgh, PA, SEI, June 1993, 24p. Richard Fairley "Risk Management for Software Project," IEEE Software, 11 (3), May 1994, pp