Zarz dzanie Projektami Informatycznymi

Transkrypt

1 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 1 Zarz dzanie Projektami Informatycznymi dr in. Krzysztof Pie kosz Instytut Automatyki i Informatyki Stosowanej Politechniki Warszawskiej pok. 560 A tel.: K.Pienkosz@ia.pw.edu.pl

2 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 2 Zarz dzanie Projektami Informatycznymi Literatura uzupełniaj ca Szyjewski Z.: Metodyki zarz dzania projektami informatycznymi, PLACET, Flasi ski M.: Zarz dzanie Projektami Informatycznymi, PWN, Sommerville I.: In ynieria oprogramowania, WNT, Cantor M.: Jak kierowa zespołem programistów, WNT, Cadle J., Yeates D.: Zarz dzanie procesem tworzenia systemów informacyjnych, WNT, Yourdon E.: Marsz ku kl sce, poradnik dla projektanta systemów, WNT, 2000 Beck K.: Wydajne programowanie, MIKOM, 2001 Highsmith J.: APM: Agile Project Management, MIKOM, 2005

3 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 3 Procesy in ynierii oprogramowania w projekcie informatycznym specyfikacja wymaga systemu analiza projektowanie implementacja integracja i testowanie oprogramowania integracja i testowanie systemu instalacja piel gnacja (konserwacja) systemu i oprogramowania

4 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 4 Procesy zarz dzania w projekcie informatycznym zarz dzanie wymaganiami organizowanie zespołów projektowych planowanie projektu zarz dzanie ryzykiem kontrola post pu prac i bud etu zarz dzanie jako ci zarz dzanie zespołem

5 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 5 Zarz dzanie Projektami Informatycznymi Główny cel: realizacja projektu na czas w bud ecie odpowiedniej jako ci spełniaj cego potrzeby klienta Kluczowe parametry projektu zakres czas koszt jako

6 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 6 Przyczyny niepowodze projektów informatycznych wynikaj ce ze sposobu zarz dzania zbyt mało kompetencji i do wiadczenia (zbyt ambitne cele) specyfikacje s niekompletne lub niejednoznaczne za mały udział u ytkowników stworzenie u ytecznego produktu informatycznego bez udziału u ytkowników jest niemo liwe zła komunikacja za mało planowania złe oszacowania nieobiektywna ocena post pu prac brak jasnego okre lenia zakresu odpowiedzialno ci niesko czone ulepszanie mało uwagi po wi cone problemom jako ci słaba dokumentacja

7 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 7 Przyczyny niepowodze projektów informatycznych c.d. wynikaj ce z natury projektów informatycznych du e zró nicowanie projekty maj charakter jednostkowy interdyscyplinarno konieczno komunikacji i współpracy ekspertów z ro nych dziedzin zmienno technologii praktycznie ka dy nowy projekt w innej technologii (cz sto słabo rozpoznanej) niematerialny charakter oprogramowania trudno ci w szacowaniu kosztów i produktywno ci oraz w kontrolowaniu zwykle brak znajomo ci dziedziny problemu przez decydentów (niejasno celów) konieczno współdziałania z innymi systemami i technologiami (problemy integracji) du a zmienno wymaga i uwarunkowa w trakcie realizacji projektów

8 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 8 Ogólne zasady skutecznego działania ustal wyra ny cel przeanalizuj wszystkie kierunki działa i rodki, za pomoc których mo na osi gn zało ony cel ułó plan działa zmierzaj cych do celu, przy zastosowaniu najlepszych w danych warunkach rodków wykonaj zało ony plan (dokonuj c ewentualnych korekt) skontroluj osi gni te wyniki i porównaj z zało onym celem wyci gnij wnioski na przyszło

9 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 9 Kluczowe czynniki powodzenia wspólna wizja produktu atmosfera zaanga owania i współodpowiedzialno ci za projekt do wiadczona i kompetentna kadra praca zespołowa w szczególno ci współpraca z u ytkownikiem planowanie działa my lenie przyszło ciowe zapobieganie zagro eniom, nie za tylko usuwanie skutków (zarz dzanie zagro eniami) dobra komunikacja i przepływ informacji kontrola zmian regularne przegl dy projektu

10 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 10 Sformalizowane metody zarz dzania projektem (metodyki) zdefiniowany proces post powania stosowanie ci le okre lonych procedur planowanie działa i post powanie według opracowanych planów dokumentowanie działa

11 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 11 Korzy ci ze stosowania metodyk koordynacja działa i lepsze wykorzystanie zasobów lepsze ukierunkowanie projektów na osi gniecie wła ciwych celów i korzy ci wi ksza przewidywalno projektów wi ksze mo liwo ci kontroli ograniczanie (minimalizacja) ryzyka jednolita praktyka realizacji Niedogodno ci pracochłonno i koszty procesów zarz dzania konieczno prowadzenia dokumentacji usztywnienie sposobu realizacji projektu spowolnienie realizacji projektu (w skali krótkiego horyzontu czasu)

12 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 12 Przykłady metodyk PRINCE2 (Project Management In Controlled Environment) PMI (metodyka Project Management Institute) Metodyki du ych firm wykonawczych i konsultingowych (ORACLE, IBM, HP, NCR, SIEMENS ) Metodyki lekkie (XP, SCRUM, Agile Project Management) Najwa niejsze, podstawowe zasady zapewniaj ce sukces s te same

13 K.Pieńkosz Zarządzanie Projektami Informatycznymi Wprowadzenie 13 Zarz dzanie Projektami Informatycznymi Ustalenie zakresu wymaga cel, zakres i ograniczenia projektu Organizacja projektu struktura zespołu wykonawców uprawnienia i zakres odpowiedzialno ci sposoby komunikacji struktury zarz dzania i nadzoru procedury sterowania i kontroli projektu Planowanie rozbicie projektu na etapy i zadania szacowanie pracochłonno ci i kosztów rozdział zasobów harmonogramowanie zada i bud etu projektu analiza ryzyka i plan zarz dzania ryzykiem plan jako ci Prowadzenie projektu monitorowanie i kontrola post pu prac działania naprawcze (koryguj ce) zarz dzanie zespołem zarz dzanie zmianami Zamkni cie projektu przekazanie produktu u ytkownikowi archiwizacja dokumentów i danych o projekcie przegl d i ocena projektu doskonalenie procesu zarz dzania

14 K.Pieńkosz Zarządzanie Projektami Informatycznymi Rozpoczęcie projektu 1 Etapy projektu informatycznego (od strony zarz dzania) Faza wst pna (przygotowanie projektu) Rozpocz cie projektu (organizacja i planowanie) Prowadzenie projektu (realizacja i kontrola) Zamkni cie projektu Faza wstępna Aktywno Organizowanie i planowanie Realizacja i kontrola Zamknięcie projektu Pocz tek projektu Koniec projektu Czas

15 K.Pieńkosz Zarządzanie Projektami Informatycznymi Rozpoczęcie projektu 2 Faza wst pna (przed podj ciem decyzji o realizacji projektu) System na zamówienie zapytanie ofertowe analiza warunków przetargu analiza ryzyka decyzja o przyst pieniu do przetargu okre lenie sposobu realizacji projektu przygotowanie i zło enie oferty PRZETARG negocjacje ze zleceniodawc podpisanie umowy Oprogramowanie sprzedawane rynkowo badania marketingowe studium wykonalno ci (feasibility study)

16 K.Pieńkosz Zarządzanie Projektami Informatycznymi Rozpoczęcie projektu 3 Zapytanie ofertowe (SIWZ specyfikacja istotnych warunków zamówienia) Instrukcja dla wykonawców charakterystyka zamawiaj cego opis procedury przetargowej okre lenie przedmiotu zamówienia, terminu zamówienia opis sposobu przygotowania oferty (formularze) wymagania dotycz ce wadium termin, do którego wykonawca b dzie zwi zany ofert miejsce i termin składania ofert oraz ich otwarcia opis sposobu udzielania wyja nie sposób i kryteria ocen ofert dodatkowe informacje formalne, np. o sposobie podpisania umowy, uniewa nieniu przetargu itp. Szczegółowy opis przedmiotu zamówienia Istotne postanowienia umowy główne warunki umowy

17 K.Pieńkosz Zarządzanie Projektami Informatycznymi Rozpoczęcie projektu 4 Elementy decyzyjne ocena wykonalno ci ocena opłacalno ci korzy ci strategiczne wpływ na rozwój powtarzalno marketing, reklama ocena szans sukcesu decyzje o stopniu zaanga owania w przygotowanie oferty Zało enia realizacji projektu wybór modelu, według którego b dzie realizowany projekt okre lenie stopnia wykorzystania gotowych komponentów wybór technik realizacji (metodyki) wybór narz dzi wybór rodowiska implementacji okre lenie trzonu zespołu wykonawców (podj cie decyzji o współpracy z innymi wykonawcami)

18 K.Pieńkosz Zarządzanie Projektami Informatycznymi Rozpoczęcie projektu 5 Zawarto oferty Charakterystyka oferenta i zespołu wykonawców Opis sposobu wykonania zamówienia opis rozwi zania technicznego (architektura, funkcjonalno technologia, warunki gwarancji i serwisu) metoda wykonania metoda zarz dzania projektem harmonogram, wykaz produktów Przyj te zało enia i oczekiwania wobec zamawiaj cego Warunki finansowe (cena i warunki płatno ci) Dokumenty formalne (dowód wniesienia wadium, za wiadczenia dotycz ce działalno ci firmy, referencje, CV wykonawców, certyfikaty, pełnomocnictwa)

19 K.Pieńkosz Zarządzanie Projektami Informatycznymi Rozpoczęcie projektu 6 Kryteria oceny ofert Do wiadczenie oferenta Do wiadczenie zespołu wykonawców Proponowany sposób realizacji przedmiotu zamówienia Cena

20 K.Pieńkosz Zarządzanie Projektami Informatycznymi Rozpoczęcie projektu 7 Studium wykonalno ci Zagadnienia techniczna wykonalno systemu alternatywne opcje wytworzenia systemu czas potrzebny do wytworzenia systemu niezb dne zasoby (w tym zasoby ludzkie) koszt wytworzenia systemu zapotrzebowanie rynku na planowany system strategiczna warto systemu dla firmy okres zwrotu kosztów zwi zanych z systemem

21 K.Pieńkosz Zarządzanie Projektami Informatycznymi Rozpoczęcie projektu 8 Rozpocz cie projektu ustalenie celu, zakresu i ogranicze projektu (zało enia projektu) uzasadnienie biznesowe sposób realizacji projektu organizacja projektu struktura zarz dzania i kontroli struktura zespołu wykonawczego (role, odpowiedzialno ci i uprawnienia) obsada ról w projekcie opracowanie procedur sterowania i kontroli projektu procedury komunikacji w projekcie (plan komunikacji) procedury zapewnienia i kontroli jako ci (plan jako ci) procedury kontroli post pów i wykorzystania bud etu procedury kontroli zmian procedury rozwi zywania problemów i rozstrzygania kwestii spornych harmonogram i krzywa kosztów analiza ryzyka i plan zarz dzania ryzykiem system zarz dzania dokumentacj projektu Plan Realizacji Projektu (co, kiedy, ile, gdzie, kto)

22 K.Pieńkosz Zarządzanie Projektami Informatycznymi Rozpoczęcie projektu 9 Zało enia projektu (Terms of Reference, Project Charter) cel, zakres i ograniczenia projektu główne produkty oczekiwania jako ciowe klienta spodziewane korzy ci otoczenie projektu i powi zania z innymi systemami kluczowe terminy bud et Zało enia s okre lane na podstawie: warunków umowy zlecenia / zapytania ofertowego analizy rodowiska klienta

23 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 1 rodowisko projektu klient osoba lub instytucja zamawiaj ca i finansuj ca produkt decydenci u ytkownicy sponsor udziałowcy osoby, na które wdro enie systemu b dzie miało bezpo redni wpływ wykonawcy osoby lub instytucje tworz ce produkt kierownik projektu główny projektant pełnomocnik ds. jako ci liderzy zespołów członkowie zespołów konsultanci kooperanci (podwykonawcy) otoczenie dostawcy wyposa enia opinia publiczna konkurencja

24 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 2 Ogólna struktura organizacyjna zarz dzania i kontroli projektu Sponsor finansowanie projektu okre lanie ogólnych wytycznych do projektu strategiczna kontrola na projektem Komitet Steruj cy (rada, zarz d projektu) taktyczna kontrola nad projektem ogólny nadzór nad realizacj projektu ocena i akceptacja poszczególnych etapów projektu ustalanie kierunków dalszej realizacji projektu Kierownik Projektu (etapu) przygotowanie planów projektu organizowanie, przydział i zarz dzanie zasobami prowadzenie projektu operacyjna kontrola nad post pami projektu raportowanie o stanie prac Zespoły wykonawcze wykonywanie szczegółowych zada zwi zanych z realizacj projektu

25 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 3 Struktura zarz dzania projektem Sponsor Komitet Steruj cy Pełnomocnik ds. jako ci Kierownik Projektu Wsparcie projektu Lider zespołu Lider zespołu Lider zespołu Zespół zadaniowy Zespół zadaniowy Zespół zadaniowy

26 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 4 Zadania sponsora projektu okre lanie ogólnych zało e projektu (planów strategicznych) zapewnienie odpowiednich rodków finansowych niezb dnych do realizacji projektu popieranie projektu zapewnienie dost pu ekspertów, których wiedza i zaanga owanie jest niezb dne do realizacji projektu rozwi zywanie konfliktów wewn trz organizacji zwi zanych z projektem

27 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 5 Zadania Komitetu Steruj cego inicjowanie projektu nadzór projektu raporty okresowe raporty o istotnych odchyleniach przegl dy etapów ustalanie priorytetów działa zatwierdzanie planów projektu na nast pne etapy harmonogramu i bud etu planu jako ci planów naprawczych okre lanie parametrów tolerancji wsparcie projektu i pomoc w podejmowaniu kluczowych decyzji zamykanie projektu opracowanie raportu o stanie projektu dla sponsora stopie realizacji celów projektu wykorzystany i planowany bud et projektu planowany harmonogram realizacji projektu z kluczowymi datami

28 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 6 Ocena etapu Plan realizacji projektu Raport ko cowy etapu Plan etapu nast pnego Uzasadnienie biznesowe Rejestr ryzyka OCENA ETAPU Decyzje dotycz ce dalszych losów projektu - kontynuowanie prac - inicjowanie nast pnego etapu - powtórzenie cz ci lub całego etapu - zawieszeniem realizacji projektu - przerwanie projektu Zatwierdzone plany dla nast pnego etapu Parametry tolerancji dla odchyle harmonogramu i kosztów Zalecenia dla kierownika projektu

29 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 7 Ocena nadzwyczajna Raport o istotnych odchyleniach Decyzje wst pne Pro ba o Plan Naprawczy Plan Naprawczy OCENA NADZWYCZAJNA Wcze niejsze zamkni cie projektu Zgoda na kontynuacj i realizacj Planu Naprawczego

30 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 8 Po co Komitet Steruj cy? Mo e zabezpieczy projekt przed: przekroczeniami bud etu i czasu (poprzez nadzór osób spoza grona wykonawców) nieosi gni ciem celów projektu po ka dym przegl dzie Komitet Steruj cy mo e zmieni kierunek projektu tak, by osi gn cele brakiem lub nadmiern reakcj na zmiany w wymaganiach, rodowisku lub zasobach Cz stotliwo spotka Komitetu Steruj cego raz na jeden-dwa miesi ce oraz na zako czenie ka dego etapu projektu w sytuacjach krytycznych

31 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 9 Zadania Kierownika Projektu zarz dzanie projektem organizowanie planowanie kierowanie i koordynacja prac kontrolowanie nadzorowanie dokumentacji projektu raportowanie raporty okresowe raport ko cowy etapu raport o istotnych odchyleniach

32 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 10 Raporty Kierownika Projektu raport okresowe post p prac osi gni ty w danym okresie produkty wykonane stan bud etu aktualne lub potencjalne problemy uaktualniony rejestr zagro e produkty do wykonania w nast pnym etapie raport ko cowy etapu terminy planowane i faktyczne nakłady pracy planowane i poniesione koszty planowane i poniesione produkty dostarczone i potwierdzenie, e spełniaj okre lone dla nich kryteria jako ci raport o istotnych odchyleniach informacja o przekroczeniu granic tolerancji powody odchyle wpływ na etap i projekt wpływ na uzasadnienie biznesowe rekomendacje

33 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 11 Zadania liderów zespołów okre lanie szczegółowych zada w krótkoterminowym (np. tygodniowym) horyzoncie czasu ustalanie krótkoterminowego harmonogramu i przydział zada w zespole ocena pracy członków zespołu raportowanie Zadania członków zespołów zadaniowych wykonywanie zada w terminie udział w spotkaniach zespołowych dokumentacja prac

34 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 12 Wsparcie projektu (Biuro projektu) administrowanie poszczególnych procesów pilnowanie przestrzegania standardów zarz dzanie dokumentacj projektu rozsyłanie komunikatów i dokumentów zarz dzanie konfiguracj gromadzenie raportów i danych o faktycznym post pie prac organizacji i obsługa zebra koordynacja kontaktów z klientem

35 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 13 Hierarchia ról u wykonawców Kierownik Projektu i Główny Projektant ta sama osoba zwykle tylko w małych projektach mało jest osób maj cych tak wszechstronne zdolno ci trudno pogodzi pracochłonno obu ról Kierownik Projektu ponad Głównym Projektantem powinny by du e uprawnienia dla Głównego Projektanta w zakresie podejmowania decyzji technicznych Główny Projektant ponad Kierownikiem Projektu Kierownik Projektu pełni funkcje administracyjne Pełnomocnik ds. jako ci przeciwwaga dla Kierownika Projektu

36 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 14 Organizacja struktury zespołu wykonawczego Zalecenia jasno okre lone cele działania i kryteria oceny przydział ról adekwatnych do posiadanych kompetencje i wagi podejmowanych decyzji jednoznacznie i precyzyjnie okre lony zakres odpowiedzialno ci przydział uprawnie decyzyjnych zdefiniowane procedury komunikacji

37 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 15 Organizacja struktury zespołu wykonawczego Procedura identyfikacja potrzeb projektu identyfikacja ról opis roli nazwa wymagane kwalifikacje (preferencje) profil realizowanych zada ograniczenia okre lenie uprawnie i zakresu odpowiedzialno ci dla poszczególnych ról schemat organizacyjny projektu hierarchia zale no ci schemat raportowania post pu prac i sygnalizowania sytuacji krytycznych plan obsady ról w projekcie mo e by rozło ony w czasie

38 K.Pieńkosz Zarządzanie Projektami Informatycznymi Organizacja projektu 16 Trudno ci z doborem zespołu personel z odpowiednimi kompetencjami i do wiadczeniem mo e nie by dost pny w ramach firmy, a nawet w jej otoczeniu bud et projektu nie pozwala na zatrudnienie takich wykonawców firma mo e oczekiwa, aby do projektu anga owa mniej do wiadczonych pracowników w celu doskonalenia ich umiej tno ci (nale y w pierwszej kolejno ci wykorzystywa zasoby firmy)

39 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 1 Procedury zarz dzania projektem procedury komunikacji w projekcie procedury kontroli zmian procedury zapewnienia jako ci procedury kontroli post pu prac procedury rozwi zywania problemów

40 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 2 Cele formalizacji procedur utrwalanie dobrych do wiadcze redukcja ró norodno ci procesów stosowanych w firmie poprawa komunikacji skrócenie czasu szkole (wdra ania si ) zwi kszenie opłacalno ci automatycznego wspomagania procesów pierwszy krok do jego wprowadzenia

41 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 3 Sposoby komunikacji Komunikacja formalna komunikacja pisemna korespondencja, notatki itp. raporty wymiana dokumentacji komunikacja bezpo rednia spotkania (zebrania) w ramach zespołów zadaniowych (robocze) okresowe spotkania wszystkich zespołów (seminaria) spotkania przegl du pracy (etapowe) spotkania w chwilach kryzysu kontakty indywidualne Komunikacja nieformalna miejsca pracy pomieszczenia socjalne

42 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 4 Procedury komunikacji wewn trz zespołu projektowego organizacja komunikacji forma komunikacji (spotkania, , telefon) dane kontaktowe członków zespołu grafik dost pno ci cz stotliwo i uczestnicy spotka spotkania wszystkich zespołów okresowe spotkania liderów i konsultantów w miar potrzeb spotkania wewn trz zespołów zadaniowych odprawy indywidualne kontakty zasady raportowania post pu prac i sygnalizowania sytuacji krytycznych osoby odpowiedzialne i odbiorcy cz stotliwo szczegółowo (format) procedury obiegu informacji projektowej organizacja biblioteki projektowej procedury zbierania, autoryzacji i gromadzenia (archiwizacji) dokumentacji zasady dost pu do informacji i jej dystrybucji (kto ma dost p, kiedy, jaki rodzaj informacji, w jakiej formie)

43 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 5 Procedury komunikacji zewn trznej z klientem, podwykonawc, itd. Nale y okre li kto jest odpowiedzialny za udost pnienie informacji jakie informacje maj by udost pniane jakie s maksymalne czasy oczekiwania na informacj jakie jest post powanie w przypadku przekroczenia tych czasów

44 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 6 ródła zmian zewn trzne zmiany w specyfikacji wymaga przez klienta zmiany technologii zmiany w rodowisku projektu, np. zmiany prawne, rynkowe wewn trzne niezgodno ci braki w specyfikacji wymaga bł dy w projekcie niespełnienie wymaga naruszenie standardów zgłoszenia potrzeby zmian usprawnienia (udoskonalenia) rozszerzenia, np. nowe funkcjonalno ci

45 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 7 Czynno ci zwi zane z wprowadzeniem zmiany w oprogramowaniu zaprojektowanie sposobu wprowadzenia zmiany wykonanie zmiany przerobienie fragmentów powi zanych testowanie zmiany testowanie skutków zmiany w innych cz systemu wdro enie zmiany dokumentacja zmiany ciach

46 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 8 Proces zarz dzania zmianami rejestrowanie i ledzenie zgłosze zmian rozpatrzenie konieczno ci zmiany analiza konieczno ci (korzy ci) wprowadzenia zmiany analiza czy mo na unikn zmiany analiza wpływu i konsekwencji zmiany zatwierdzenie (autoryzacja) zmiany do realizacji nadawanie zmianom priorytetów i planowanie ich realizacji w czasie koordynacja wprowadzania zmian wdro enie zmiany udokumentowanie zmiany testowanie i ledzenie skutków zmiany utworzenie kolejnej wersji

47 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 9 Analiza wpływu zmiany zakres zmiany zło ono zmiany nakład pracy zwi zany z wprowadzeniem zmiany zasoby wymagane do realizacji wpływ na tempo realizacji projektu koszty dokonania zmiany wpływ na wydajno systemu skutki zmiany w innych cz ciach systemu ryzyko wprowadzenia zmiany rozpatrzenie alternatywnych sposobów realizacji zmiany

48 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 10 Procedura kontroli zmian zewn trznych (musi by formalna i uzgodniona z klientem) danie zmiany rejestracja dania (wypełnienie formularza) rozpatrzenie i zlecenie zbadania Projektu) dania zmiany (Kierownik analiza wpływu i konsekwencji wprowadzenia zmiany podj cie decyzji (Komitet Steruj cy) zlecenie bardziej szczegółowej analizy skutków zmiany wykonanie zmiany odło enie wykonania zmiany (np. do czasu zako czenia etapu, projektu) odrzucenie wykonania zmiany

49 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 11 Co daje kontrola zmian? zapobiega nieuzasadnionym zmianom zapobiega pomini ciu zgłaszanych propozycji zmian zapewnia, e wpływ zmiany jest dokładnie zbadany zanim zostanie wdro ona umo liwia koordynacj w przypadku zgłaszania propozycji podobnych zmian umo liwia zaplanowanie i organizacj procesu wprowadzania zmian zapewnia, e wszystkie strony, których dotyczy zmiana maj mo liwo ustosunkowania si zapewnia, e termin wprowadzenia zmiany jest rozpatrywany w kontek cie innych prac prowadzonych w ramach projektu rejestr zmian, co mo e by potem wykorzystywane np. do bada trendów i analiz statystycznych

50 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 12 Elementy konfiguracji systemu oprogramowanie dokumentacja oprogramowania (techniczna i u ytkowa) dane niezb dne do wytworzenia systemu narz dzia stosowane do konstrukcji oprogramowania rodowisko

51 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 13 Zarz dzanie konfiguracj ustalenie zasad utrzymywania integralno ci ewoluuj cego systemu procedury (standardy) narz dzia organizacja repozytorium osoby odpowiedzialne (bibliotekarz) identyfikacja wszystkich elementów systemu, ich historii i wzajemnych powi za kontrola wersji monitorowanie i rejestrowanie aktualnego stanu ka dego obiektu konfiguracji autoryzacja kolejnych wersji produktów ( zamra anie ) zarz dzanie zmianami rejestrowanie potrzeb i zgłosze zmian analiza wpływu zmian na projekt przegl d i zatwierdzanie zmian do realizacji koordynacja wprowadzania zmian nadawanie zmianom priorytetów i planowanie ich realizacji w czasie ledzenie realizacji zmian zarz dzanie dokumentacj gromadzenie udost pnianie

52 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 14 Ró norodno wersji zró nicowanie ze wzgl du na zakres realizowanych funkcji zró nicowanie ze wzgl du na wprowadzane zmiany i usprawnienia zró nicowanie ze wzgl du na przystosowanie do rozmaitych platform sprz towych i oprogramowania Skutek wiele wersji o ró nych konfiguracjach mo e by w u yciu jednocze nie

53 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 15 Kontrola wersji ile i jakie wersje utworzono jaka jest struktura poszczególnych wersji na które wersje systemu mo e mie wpływ konkretna zmiana ile zgłoszonych usterek ( danej wersji da zmian) dotyczy jaka konfiguracja sprz tu i systemu operacyjnego jest konieczna do uruchomienia konkretnej wersji systemu jakie s zbiory testów do poszczególnych wersji którym klientom dostarczono dan wersj systemu

54 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 16 Procedury kontroli post pu prac terminy spotka zespołów ( odpraw ) zasady raportowania zakres szczegółowo cz stotliwo odbiorcy raportu procedury odbioru prac sposób zgłaszania prac do odbioru zasady i warunki odbioru plany testów akceptacyjnych

55 K.Pieńkosz Zarządzanie Projektami Informatycznymi Procedury zarządzania 17 Procedury rozwi zywania problemów Typowe problemy problemy komunikacyjne zmiany w zasadach funkcjonowania firmy problemy natury ludzkiej Istotne jest: zdefiniowanie schematu zgłaszania problemów i zagro e zdefiniowanie procedury rozstrzygania problemów

56 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 1 Co nale y oszacowa? pracochłonno harmonogram czas trwania zada i całego projektu zasoby ludzkie jak du y zespół bud et koszty wynagrodze koszty sprz tu i oprogramowania koszty materiałów koszty usług obcych (podwykonawców) koszty szkole, wyjazdów itp.

57 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 2 Trudno ci w szacowaniu bardzo du e zró nicowanie i zło ono projektów informatycznych nieliniowy wzrost zło ono ci oprogramowania przy zwi kszaniu zakresu projektu zmienno wymaga, rodowiska, organizacji przy ka dym nowym projekcie zmienno technologii praktycznie ka dy nowy projekt w innej technologii rosn cy udział kosztu opracowania oprogramowania w ogólnych kosztach systemu niematerialny charakter oprogramowania trudny z natury do oszacowania brak do wiadczenia zespołów projektowych zwykle młodzi ludzie brak dojrzałych metryk oprogramowania dobrze skorelowanych z procesem tworzenia oprogramowania Dodatkowo konieczno dokonywania oszacowa przed specyfikacj wymaga wykonaniem projektu, który okre la technologi, narz dzia i architektur

58 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 3 Przy szacowaniu trzeba uwzgl dni zło ono zadania umiej tno ci i do wiadczenie pracowników znajomo i dost pno technologii czas nieproduktywny (praca w innych projektach, administrowanie, wakacje, choroby, szkolenia) czynno ci i czas zwi zany z zarz dzaniem (spotkania, przygotowywanie raportów, sprawozda itp.) czas niezb dny dla komunikacji w zespole czas przeznaczony na kontrol jako ci (np. audyty, przegl dy, inspekcje)

59 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 4 Czas realizacji a liczba pracowników Zale no nieliniowa Przyczyny wraz z liczb pracowników ro nie nakład czasu na komunikacj niepodzielno zada

60 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 5 Czas realizacji a liczba pracowników Projekty wymagaj ce niewielkiej komunikacji Miesi ce Miesi ce Pracownicy Pracownicy Projekty wymagaj ce intensywnej komunikacji

61 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 6 Zalecenia przy szacowaniu aktualizowanie oszacowa im pó niej szacujemy, tym dokładniej bo mamy wi cej informacji (w praktyce zalecenie to sprowadza si do weryfikacji oszacowa ) dekompozycja mo liwo precyzyjniejszego oszacowania mniejszego zadania, modułu itp. zmniejszenie wpływu bł dów oszacowania poszczególnych elementów na sumaryczny szacunek cało ci opieranie si na charakterystyce produktywno ci zespołu konieczno mierzenia produktywno ci, gromadzenia danych i uaktualniania charakterystyki stosowanie ró norodnych oszacowa enie do okre lania i minimalizacji rozrzutu szacunków d

62 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 7 Metody szacowania pracochłonno ci szacowanie wst puj ce (np. metoda PERT) szacowanie zst puj ce okre lenie stopnia pracochłonno ci zadania wzgl dem wi kszej cało ci (np. na zasadzie reguły ) na zasadzie analogii z podobnymi przedsi wzi ciami ocena ekspertów metoda delficka Standard Task Method podział zada wzgl dem wielko ci i zło ono ci metoda AQUA szacowanie algorytmiczne na podstawie linii kodu (np. COCOMO) na podstawie struktury programu (np. metoda punktów funkcyjnych) u ycie i porównanie kilku metod

63 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 8 Szacowanie zst puj ce (top-down) Przykład Cały projekt 100% Projektowanie 40% Specyfikacja wymagań 15% Oprogramowanie 20% Kodowanie 10% Testowanie i wdro enie 40% Integracja 15% Analiza i projekt 25% Testy modułów 10% Testowanie 20% Dokumentacja 5%

64 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 9 Metoda delficka szacowania dokonuje grupa ekspertów ka dy z osobna (w sposób tajny) wyniki zbiera si i wyznacza najbardziej optymistyczne oszacowanie warto redni oszacowa najbardziej pesymistyczne oszacowanie powy sze wielko ci przedstawia si ekspertom i prosi si ich znowu o dokonanie (zrewidowanie) oszacowania proces kontynuuje si a si uzyska zbie no ocen (albo si nie uzyska)

65 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 10 Standard Task Method klasyfikacja projektu (zadania) wzgl dem wielko ci, np. mały, redni, du y klasyfikacja projektu (zadania) wzgl dem zło ono ci, np. prosty, umiarkowany, zło ony tabelaryczna ocena pracochłonno ci (kosztu) Przykład Przygotowanie planu realizacji projektu Mały 10 Rozmiar osobodni projektu redni 12 osobodni Du y 15 osobodni Zło ono projektu Prosty Umiarkowany Zło ony 13 osobodni 15 osobodni 18 osobodni 15 osobodni 18 osobodni 21 osobodni

66 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 11 Metoda AQUA opiera si na analizie danych historycznych warto ci atrybutów pracochłonno badany jest stopie podobie stwa aktualnego projektu do projektów historycznych na podstawie porównywania warto ci atrybutów okre lenie N najbardziej podobnych przypadków w oparciu o warto ci miary podobie stwa (N wyliczane automatycznie) wyliczana jest pracochłonno nowego projektu na podstawie pracochłonno N projektów najbardziej podobnych (jako rednia wa ona wzgl dem miar podobie stwa)

67 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 12 Metoda COCOMO (COnstructive COst MOdel) pracochłonno E [osobomiesi ce] E = a (KDSI) b d KDSI (Kilo Delivered Source Instructions) tysi ce instrukcji ródłowych w programie (oszacowanie liczby linii kodu) czas trwania projektu T [miesi ce] T = 2,5 E c liczebno zespołu S S = E/T

68 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 13 Współczynniki modelu COCOMO a, b, c zale od rodzaju systemu prosty mały, typowy, w stabilnym rodowisku typowy redni, typowy z modyfikacjami, w umiarkowanie zło onym rodowisku zło ony du y, unikalny, w zło onym rodowisku prosty typowy zło ony a 2,40 3,00 3,60 b 1,05 1,12 1,20 c 0,38 0,35 0,32 d współczynnik koryguj cy zale ny od atrybutów procesu, produktu i rodowiska tworzenia oprogramowania (w klasycznym modelu d=1) Przykład Program 20 tys. instrukcji ródłowych (linii kodu), typowy projekt pracochłonno 86 osobomiesi cy czas trwania zespół 12 miesi cy 7-8 osób

69 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 14 Zastrze enia do metod opartych na liniach kodu wymagaj oszacowania linii kodu (szacowanie pracochłonno ci zast pujemy szacowaniem linii kodu) szacowanie pracochłonno ci odbywa si tylko na podstawie samego procesu kodowania programu, a jest to tylko jeden z etapów realizacji oprogramowania liczba linii kodu (instrukcji ródłowych) jest miar długo ci programu i nie bierze pod uwag w bezpo redni sposób jego zło ono ci i mo liwo ci funkcjonalnych miara w postaci liczby linii kodu uniemo liwia wykonywanie bada porównawczych, gdy silnie zale y od rodków implementacji (j zyka)

70 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 15 Metoda punktów funkcyjnych obliczenie liczby wst pnych punktów funkcyjnych (UFP Unadjusted Function Points) obliczenie sumarycznego poziomu technicznej zło ono ci (TCF The Technical Complexity Factor) obliczenie punktów funkcyjnych (FP Function Points) FP = UFP TCF wyznaczenie pracochłonno ci projektu na podstawie wyliczonej liczby punktów funkcyjnych okre lenie czasu trwania projektu okre lenie liczebno ci zespołu

71 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 16 Wst pne punkty funkcyjne (UFP Unadjusted Function Points) klasyfikacja składników systemu wej cia do systemu wyj cia systemu wewn trzne zbiory danych zewn trzne zbiory danych zapytania okre lenie kategorii zło ono ci funkcji proste rednie zło one obliczenie sumy wag zło ono ci na podstawie tabeli Proste rednie Zło one Wej cia Wyj cia Zbiory wewn Zbiory zewn Zapytania 3 4 6

72 K.Pieńkosz Zarządzanie Projektami Informatycznymi Szacowanie 17 Poziom technicznej zło ono ci systemu (TCF The Technical Complexity Factor) szacowanie wpływu czynników koryguj cych ( w skali 0, 1, 2, 3, 4, 5 im wi kszy wpływ tym wi cej punktów) 1. szybko przesyłania danych 2. rozproszenie przetwarzania 3. wydajno 4. stopie obci enia systemu 5. cz stotliwo wykonywania transakcji 6. ilo danych wprowadzanych on-line 7. wydajno u ytkownika ko cowego 8. aktualizacja danych w trybie on-line 9. zło ono przetwarzania danych 10. przenaszalno oprogramowania 11. łatwo instalacji 12. prostota obsługi systemu 13. liczba lokalizacji stanowisk 14. łatwo wprowadzania zmian obliczenie zło ono ci przetwarzania F (suma stopni wpływu poszczególnych czynników) wyznaczenie współczynnika koryguj cego, np. TCF = 0,65 + (0.01 F)

73 K.Pieńkosz Zarządzanie Projektami Informatycznymi Planowanie 1 Planowanie (harmonogramowanie) Po co planować? w celu okre lenia wszystkich zada do wykonania w celu efektywnego wykorzystania czasu i zasobów (okre lenia niezb dnych zasobów i kosztów) planowanie ujawnia w skie gardła i zagro enia planowanie umo liwia sformułowanie cz stkowych celów oraz hierarchii ich wa no ci plan okre la wizj całego projektu wag zada i udział poszczególnych wykonawców, co zwykle wpływa na wi ksze zaanga owanie w projekcie planowanie okre la re im realizacji projektu ograniczaj c wpływ chwilowych opinii i emocji plan jest podstaw do koordynacji i kontroli projektu plan stanowi dokumentacj, która mo e by poddana ocenie oraz mo e by wykorzystywana do doskonalenia procesu planowania w przyszło ci

74 K.Pieńkosz Zarządzanie Projektami Informatycznymi Planowanie 2 Niedogodności planowania planowanie wymaga czasu planowanie jest kosztowne (wymaga dobrych fachowców) planowanie jest oparte na oszacowaniach i prognozach przyszłych wydarze stosowanie planów usztywnia funkcjonowanie przedsi biorstwa

75 K.Pieńkosz Zarządzanie Projektami Informatycznymi Planowanie 3 NajwaŜniejsze elementy planowania uzgodnienie celów i ogranicze projektu strategia realizacji okre lenie etapów i zada zdefiniowanie produktów ko cowych i po rednich okre lenie infrastruktury projektu oszacowanie pracochłonno ci i kosztów opracowanie harmonogramu, bud etu i przydziału zasobów okre lenie punktów kontrolnych

76 K.Pieńkosz Zarządzanie Projektami Informatycznymi Planowanie 4 Hierarchia harmonogramów harmonogram negocjacyjny estymacja zgrubna na poziomie całego projektu czasu bud etu harmonogram kontraktowy bardziej szczegółowy harmonogram w oparciu o wymagania u ytkownika z podziałem na etapy kontrakt zwykle obejmuje pierwsze etapy, a nast pne etapy warunkowo z mo liwo ci renegocjacji harmonogram szczegółowy na poziomie etapu czynno ci bud etu zasobów procedur kontroli W trakcie realizacji projektu Struktura dwupoziomowa aktualny etap harmonogram szczegółowy nast pne etapy harmonogram zgrubny (np. kontraktowy)

77 K.Pieńkosz Zarządzanie Projektami Informatycznymi Planowanie 5 Czynniki decydujące o długości etapu struktura projektu poziom ryzyka mo liwo oceny przebiegu, sensowno ci i kosztów projektu stopie poinformowania kierownictwa czas niezb dny na przegl dy etapów (przygotowanie dokumentacji, przeprowadzenie przegl du itd.) utrzymywanie zaanga owania W praktyce długo etapu to kilka miesi cy (2 do 6) i zale y od fazy projektu

78 K.Pieńkosz Zarządzanie Projektami Informatycznymi Planowanie 6 Elementy planowania okre lenie zakresu prac zaproponowanie technologii sposobu wykonywania prac (kolejno ci, standardów, narz dzi, zasobów itd.) zdefiniowanie produktów ko cowych i po rednich oszacowanie pracochłonno ci i kosztów rozplanowanie zada w czasie z uwzgl dnieniem dost pnych zasobów, ogranicze i czynników ryzyka

79 K.Pieńkosz Zarządzanie Projektami Informatycznymi Planowanie 7 Etapy harmonogramowania szczegółowego uzgodnienie celu, zakresu i ogranicze etapu (TOR - Terms of Reference) podział etapu i zadania na zadania (WBS - Work Breakdown Structure) specyfikacja zada okre lenie ogranicze kolejno ciowych zada szacowanie czasów wykonania zada okre lenie efektów wykonania zada (produktów) przydział zasobów do zada sporz dzenie i analiza sieci czynno ci analiza cie ki krytycznej analiza rozdziału zasobów opracowanie wst pnego harmonogramu projektu szacowanie i harmonogramowanie kosztów zdefiniowanie punktów kontrolnych weryfikacje i korekty (proces iteracyjny) akceptacja harmonogramu

80 K.Pieńkosz Zarządzanie Projektami Informatycznymi Planowanie 8 Specyfikacja zadań cel zadania procedura opis czynno ci wchodz cych w skład zadania czas przeznaczony na realizacj zadania dane wej ciowe materiały ródłowe dla zadania produkty efekt realizacji zadania kryteria rozpocz cia kiedy, przy jakich warunkach mo na rozpocz realizacj zadania kryteria zako czenia kryteria akceptacji (odbioru) role kto realizuje zadanie (jaka komórka) i jest za nie odpowiedzialny narz dzia, zasoby niezb dne do realizacji metryki opis danych o zadaniu, które nale y gromadzi w trakcie jego realizacji inne inne dane, dokumenty, standardy, wymagania, ograniczenia itp., które maj wpływ na sposób realizacji zadania

81 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie ryzykiem 1 Zarz dzanie ryzykiem (zarz dzanie w warunkach wyst powania ryzyka) Ryzyko mo liwo nie uda (zagro enie)., prawdopodobie stwo, e co si Kategorie ryzyka znane gdy wyst pienie zagro enia jest prawie pewne; przewidywalne gdy wyst pienie zagro enia jest prawdopodobne i mo e by wcze niej wykryte/rozpoznane; nieprzewidywalne gdy wyst pienia zagro enia nie mo na przewidzie z wyprzedzeniem (przypadki losowe). Zarz dzanie ryzykiem zajmuje si dwiema pierwszymi kategoriami tzn. ryzykiem znanym oraz przewidywalnym koncentruje si na wczesnym wykrywaniu mo liwego ryzyka i działaniach zapobiegawczych, nie za na usuwaniu skutków powstałych problemów Wersja 12.03

82 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie ryzykiem 2 Typowe ródła ryzyka charakter projektu du y stopie zło ono ci napi te (mało elastyczne) terminy długi czas trwania projektu du e prawdopodobie stwo znacznych zmian (technologii, pracowników, otoczenia, kierownictwa, prawa, itd.) zbyt optymistyczny bud et nieznana, nie wypróbowana nowa technologia rodowisko zespołu wykonawczego do wiadczenie i umiej tno ci zespołu (merytoryczne, w metodykach prowadzenia projektu, w zarz dzaniu, itd.) motywacja i zaanga owanie zespołu zdrowie fizyczne i psychiczne koordynacja du a liczba kooperantów (dostawców, podwykonawców itd.) rozmieszczenie miejsc realizacji projektu rodowisko klienta zaanga owanie klienta w projekt (specyfikacja wymaga, zmiany wymaga, komunikacja) poziom wiedzy u ytkowników organizacja klienta liczba komórek obj tych projektem konieczno wprowadzenia reorganizacji czynniki zewn trzne Wersja 12.03

83 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie ryzykiem 3 Metodyka zarz dzania ryzykiem analiza ryzyka identyfikacja zagro e ocen ryzyka specyfikacja zagro e (z przypisanymi wagami) planowanie przeciwdziała planowanie działa bezwarunkowych (w celu unikni cia zagro enia lub zredukowania jego skutków) ustalenie procedury działania w przypadku wyst pienia zagro enia monitorowanie ryzyka doskonalenie procesów zarz dzania ryzykiem RYZYKO Analiza ryzyka Planowanie przeciwdziała Monitorowanie ryzyka Specyfikacja zagro e Strategie zapobiegania Plany rezerwowe Ocena ryzyka Wersja 12.03

84 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie ryzykiem 4 Metody identyfikacji ryzyka analiza ródeł ryzyka charakter projektu klient wykonawcy podwykonawcy procesy zarz dzania i tworzenia oprogramowania technologia (sprz t, oprogramowanie) inne czynniki wewn trzne i zewn trzne wywiady, warsztaty, burze mózgów listy kontrolne kwestionariusze oceny zagro e (ryzyka) informacja archiwalna z poprzednich projektów analogie do znanych przypadków eksperymenty lub testy (np. nowej technologii) Wersja 12.03

85 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie ryzykiem 5 Ocena ryzyka prawdopodobie stwo wyst pienia parametry liczbowe podział na kategorie np. prawdopodobie stwo bardzo wysokie, wysokie, rednie, niskie, bardzo niskie skutki wyst pienia liczone w pracochłonno ci, koszcie, opó nieniu, jako ci produktu itp. podział na kategorie np. skutki katastrofalne, du e, rednie, małe okre lenie wagi ryzyka waga ryzyka = (prawdopodobie stwo) (skutek) na podstawie macierzy wag np. ryzyko wysokie, rednie, niskie, nieistotne, itp. Skutek Bardzo du e Prawdopodobie stwo Du e rednie Małe Bardzo małe Katastrofalny wysokie wysokie wysokie rednie niskie Du y wysokie wysokie rednie niskie nieistotne redni rednie rednie niskie nieistotne nieistotne Mały rednie niskie niskie nieistotne nieistotne na podstawie graficznej reprezentacji wagi ryzyka Wersja 12.03

86 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie ryzykiem 6 Specyfikacja ryzyka (wynik analizy ryzyka) nazwa ryzyka opis ryzyka prawdopodobie stwo pojawienia si ryzyka wpływ na projekt (skutki) waga ryzyka symptomy ryzyka czas wyst powania zagro enia Wersja 12.03

87 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie ryzykiem 7 Planowanie zarz dzania ryzykiem (planowanie przeciwdziałania zagro eniom) Strategie zarz dzania ryzykiem unikanie ryzyka eliminacja zagro e, np. przez usuwanie ich przyczyn, rezygnacj z ryzykownych alternatyw łagodzenie wpływu ryzyka redukcja prawdopodobie stwa wyst pienia, np. poprzez wprowadzenie redundancji, prototypowanie, wybór standardowych rozwi za redukcja warto ci strat przenoszenie ryzyka np. na inny etap, na klienta (ujmuj c to w umowie) lub inn instytucj (ubezpieczenie) akceptacja ryzyka zgoda na skutki ryzyka ustalenie procedury działania w przypadku wyst pienia zagro enia ledzenie poziomu ryzyka Wersja 12.03

88 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie ryzykiem 8 Plan post powania awaryjnego opis zagro enia, którego plan dotyczy metoda ledzenia ryzyka zwi zanego z zagro eniem przypisanie odpowiedzialno ci za ledzenie ryzyka i realizacj planu warunki uruchomienia planu opis akcji awaryjnych przydział zasobów do wykonania planu Wersja 12.03

89 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie ryzykiem 9 Monitorowanie ryzyka wykrywanie pierwszych symptomów ryzyka uruchamianie akcji naprawczych monitorowanie działa zwi zanych z ograniczaniem ryzyka ponawianie oceny ryzyka korygowanie specyfikacji zagro e oraz planów przeciwdziałania zagro eniom Wersja 12.03

90 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 1 Zarz dzanie wymaganiami usystematyzowane podej cie do ustalania i utrzymywania porozumienia mi dzy klientem i zespołem wykonawców zarz dzanie procesem pozyskiwania, specyfikacji i weryfikacji wymaga opracowanie standardu specyfikacji wymaga zarz dzanie specyfikacj wymaga w ró nych fazach realizacji projektu (analiza, projektowanie, programowanie) utrzymywanie zgodno ci stworzenie systemu identyfikacji i ledzenia wymaga w dokumentacji zarz dzanie zmianami wymaga Wersja04.06

91 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 2 Trudno ci w okre leniu wymaga klienci i u ytkownicy cz sto nie wiedz dokładnie czego chc i zaczynaj rozumie swoje potrzeby dopiero wtedy, kiedy widz system podczas pracy du e systemy s wykorzystywane przez wielu u ytkowników z ró nymi punktami widzenia (mog by bardzo ró ne nawet sprzeczne wymagania) klient z reguły nie wie dokładnie w jaki sposób osi gn zało one cele konieczno negocjacji wymaga ró nice rodowiskowe i poj ciowe trudno ci we wzajemnym zrozumieniu klient mo e nie dostrzega pewnych ogranicze lub mo e uznawa je za oczywiste (powszechnie znane) konieczno wynegocjowania zmiany organizacji pracy w przedsi biorstwie ( eby nie informatyzowa bałaganu) niestabilne koncepcje systemu lub uwarunkowania zewn trzne (np. wymagania prawne) pełzanie wymaga Wersja04.06

92 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 3 Pozyskiwanie wymaga ustalenie zakresu systemu identyfikacja ródeł pozyskiwania wymaga i ró nych punktów widzenia wydobywanie wymaga analiza wymaga wst pna reprezentacja wymaga potwierdzenie wła ciwego zrozumienia wymaga konsolidacja i specyfikacja wymaga analiza specyfikacji: weryfikacja i walidacja ustalenie hierarchii wymaga Proces iteracyjny Wersja04.06

93 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 4 Punkty widzenia bezpo redni u ytkownicy funkcje systemu i sposób u ytkowania wy sze kierownictwo cele strategiczne, bezpiecze stwo administrator systemu niezawodno, funkcje wykrywania i diagnozy bł dów itp. kierownik marketingu nowoczesno rozwi za kierownik finansowy koszty Wersja04.06

94 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 5 Metody zbierania wymaga wywiady z wy szym kierownictwem odno nie strategii firmy i celów systemu z kadr in yniersk odno nie potrzeb i ogranicze technicznych z bezpo rednimi u ytkownikami warsztaty wymaga, burze mózgów ankiety (ograniczona u yteczno ) analiza scenariuszy zdarze (przypadków u ycia) poznawanie rodowiska docelowego, w którym zostanie zainstalowany system odgrywanie ról u ytkowników studiowanie innych istniej cych systemów stosowanie prototypów Wersja04.06

95 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 6 Prototypowanie budowa uproszczonego modelu systemu za pomoc szybkich i tanich rodków implementacja ograniczonego zestawu funkcji prezentacja głównie warstwy zewn trznej (interfejsu) pomini cie wzgl dów jako ciowych Podej cia do prototypowania prototypowanie z porzuceniem (celem jest okre lenie i zatwierdzenie wymaga ) prototypowanie ewolucyjne (z rozbudow ) (celem jest dostarczenie wst pnej wersji systemu z zamiarem dalszej jej rozbudowy) Ogólne wymagania Prototypowanie z porzuceniem Prototypowanie ewolucyjne Specyfikacja wymaga Wst pna wersja systemu Doskonalenie i rozbudowa Prototypy ukierunkowane na rozbudow maj du o wi ksze wymagania jako ciowe Wersja04.06

96 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 7 Korzy ci ze stosowania prototypów u ytkownik uzyskuje szybki wgl d na posta systemu mo liwo doprecyzowywania niejasnych wymaga i wczesnego wykrycia złych interpretacji Problemy przy prototypowaniu z porzuceniem sposób u ytkowania prototypu mo e by inny ni docelowego systemu (kwestia reakcji klienta) klient mo e odnie wra enie e system jest ju prawie gotowy przy prototypowaniu ewolucyjnym problemy z zarz dzaniem brak szczegółowej specyfikacji wymaga trudno zaplanowa prace i okre li bud et problemy z utrzymywaniem dokumentacji (raczej jej brak) kłopoty z zachowaniem sensownej struktury systemu weryfikacja i odbiór systemu oparte na subiektywnej ocenie wybranych u ytkowników (kłopoty z zamkni ciem projektu) kłopoty ze sformułowaniem umowy Wersja04.06

97 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 8 Analiza wymaga gł bsze poznawanie wymaga kształtowanie modelu przyszłego systemu wykrywanie braków w zestawie wymaga bł dów (wymagania bł dnie wyspecyfikowane) sprzeczno ci (konfliktów) nadmiarowo ci luk (wymagania niewyspecyfikowane) wymaga spoza zakresu systemu badanie wzajemnych zwi zków mi dzy wymaganiami analiza sytuacji nietypowych Wersja04.06

98 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 9 Specyfikacja Wymaga Historia zmian (wersji) Spis tre ci Wst p ogólny opis systemu cel i przeznaczenie systemu zakres systemu Model (kontekst) systemu definicja współpracuj cych obiektów zewn trznych definicja zale no ci mi dzy elementami systemu i rodowiska Wymagania funkcjonalne opis funkcji (usług) systemu Wymagania niefunkcjonalne wła ciwo ci systemu niezawodno kompatybilno wydajno (szybko ) bezpiecze stwo w razie awarii (safety) bezpiecze stwo dost pu (security) Ograniczenia projektowe rodowisko sprz towe rodowisko programowe przepisy i normy dotycz ce produktu i procesu tworzenia Opis ewolucji systemu przewidywane zmiany, rozwój Słownik lista u ywanych terminów i skrótów Dodatki (zał czniki) Skorowidz Wersja04.06

99 K.Pieńkosz Zarządzanie Projektami Informatycznymi Zarządzanie wymaganiami 10 Po dane cechy Specyfikacji Wymaga jednoznaczno w interpretacji wymaga kompletno poprawno spójno (niesprzeczno ) weryfikowalno istniej procedury sprawdzenia spełnienia wymaga modyfikowalno mo liwo łatwego uwzgl dnienia zmian w specyfikacji jasny system identyfikacji i odwoła Wersja04.06