Zarzadzanie projektem systemu informatycznego

1
Zarzadzanie projektem systemu informatycznego
2
Cykl zycia projektu

• Formalnie okreslony sposób realizacji projektu
  (plan projektu, metodologia budowy systemu)
• Uporzadkowanie przebiegu prac
• Ulatwienie planowania zadan
• Monitorowanie przebiegu realizacji zadan

3
Modele cyklu zycia

• Realizacja kierowana dokumentami
• Prototypowanie
• Programowanie odkrywcze
• Realizacja przyrostowa
• Montaz z gotowych elementów
• Model spiralny
• Formalne transformacje

4
Prototypowanie
Ogólne okreslenie wymagan
Budowa prototypu
tak
nie
Pelne okreslenie wymagan
Realizacja pelnego systemu
5
Programowanie odkrywcze
Ogólne okreslenie wymagan
Budowa systemu
Przetestuj system
System dziala poprawnie
tak
nie
Dostarcz system
6
Realizacja przyrostowa
Proces realizowany iteracyjnie
Okreslenie wymagan
Projekt ogólny
Wybór podzbioru funkcji
Projekt szczególowy, implementacja i testy
Dostarczenie zrealizowanej czesci systemu
7
Montaz z gotowych elementów

• Zródla
• biblioteki
• jezyki czwartej generacji
• pelne aplikacje
• Metody pozyskania
• zakup modulów
• standaryzacja produktów
• Zalety
• wysoka niezawodnosc, zmniejszenie ryzyka
• narzucenie standardów
• redukcja kosztów

8
Model spiralny
Planowanie
Analiza ryzyka
Atestowanie
Konstrukcja (model kaskadowy)
9
Formalne transformacje
Formalna specyfikacja wymagan
Postac posrednia
...
Postac posrednia
Kod
10
Model ogólny cyklu zycia
Okreslanie wymagan
Projektowanie
Implementacja
Testowanie
Konserwacja
Faza strategiczna
Analiza
Instalacja
Dokumentacja
11
Rational Unified Process

• Rational Unified Process (RUP) to proces
  iteracyjnego wytwarzania oprogramowania
  opracowany przez firme Rational Software
  Corporation (firma zostala obecnie przejeta przez
  IBM)
• Proces RUP nie jest pojedynczym, scisle
  okreslonym procesem, ale raczej szablonem procesu

12
Rational Unified Process

• Zostal zaprojektowany w celu przystosowania do
  charakteru konkretnej organizacji, konkretnego
  zespolu projektowego lub nawet charakteru
  konkretnego projektu
• Z szablonu RUP mozna wybrac elementy w zaleznosci
  od konkretnych potrzeb

13
Rational Unified Process

• Rational Unified Process (RUP) to takze nazwa
  oprogramowania, opracowanego przez Rational
  Software (obecnie dostepnego w IBM) zawierajacego
  hipertekstowa baze wiedzy z przykladowymi
  artefaktami oraz szczególowymi opisami wielu
  typów czynnosci
• Process RUP definiowany jest takze w produkcie
  Rational Method Composer (RMC), który pozwala na
  tworzenie spersonalizowanych wersji RUP

14
Iteracyjne wytwarzanie oprogramowania

• Wytwarzanie oprogramowania w kolejnych
  iteracjach, pozwala skupic sie w pierwszej
  kolejnosci na obszarach najbardziej ryzykownych
  (np. najmniej rozpoznanych)
• W idealnym przypadku kazda iteracja konczy sie
  stworzeniem wykonywalnego artefaktu - pomaga to
  zredukowac ryzyko w projekcie, otrzymujemy
  szybciej opinie od odbiorców oprogramowania a
  programistom pozwalamy skupic sie na wezszej
  dziedzinie

15
Architektura bazujaca na komponentach

• Pozwala na stworzenie systemu, który jest latwo
  rozszerzalny, intuicyjnie zrozumialy i wspomaga
  ponowne uzycie (komponent to zbiór powiazanych
  obiektów)
• RUP skupia sie na stworzeniu prostej architektury
  w poczatkowych iteracjach
• Ewoluuje ona w kazdej iteracji zblizajac sie do
  architektury finalnej
• Poprzez iteracyjne wytwarzanie oprogramowania
  zyskujemy mozliwosc stopniowej identyfikacji
  komponentów, które moga byc w dalszej czesci
  zakupione, zbudowane, lub uzyte ponownie

16
Wizualne modelowanie oprogramowania

• Abstrakcja projektowania od kodu i przedstawienie
  koncepcji za pomoca bloków graficznych moze byc
  efektywnym sposobem aby pokazac perspektywe
  rozwiazania
• Reprezentacja graficzna jest produktem posrednim
  pomiedzy analiza procesu biznesowego, a
  implementacja
• Model w tym kontekscie jest forma wizualizacji
  oraz uproszczeniem bardziej skomplikowanego
  projektu
• RUP specyfikuje wymagane modele i opisuje
  dlaczego sa wymagane

17
Kontrola i weryfikacja jakosci oprogramowania

• Ocena jakosci jest najczestszym slabym punktem
  projektów programistycznych poniewaz jest czesto
  planowana po fakcie budowy systemu i czasami
  obslugiwana przez inny zespól
• RUP pomaga w planowaniu kontroli jakosci i jej
  ocenie poprzez wbudowanie jej w caly proces i
  zaangazowanie w nia wszystkich czlonków zespolu
• Proces koncentruje sie na spelnieniu wymaganego
  poziomu jakosci i zapewnia mechanizmy do pomiaru
  tego poziomu

18
Zarzadzanie zmianami w oprogramowaniu

• RUP definiuje metody sledzenia, ewidencji i
  kontroli zmian
• Zdefiniowane sa takze tzw. secure workspaces
  (bezpieczne przestrzenie robocze), które
  pozwalaja na zagwarantowanie, ze zmiany w innych
  systemach nie wplyna na system tworzony
• Koncepcja ta jest scisle powiazana z tworzeniem
  architektury zorientowanej komponentowo

19
(No Transcript)
20
nazwa etapu cele produkty
Rozpoczecie (ang. Inception) ustalenie zakresu projektu i warunków granicznych dokument wizji systemu lista przypadków uzycia slownik systemu ocena ryzyka
Opracowanie (ang. Elaboration) definicja, walidacja architektury model najwazniejszych przypadków uzycia model architektury (widok logiczny) uscislony plan i ocena ryzyka
Konstruowanie (ang. Construction) otrzymanie uzytecznych wersji systemu minimalizacja kosztów wytwarzania osiagniecie adekwatnej jakosci produkt zintegrowany z docelowa platforma podrecznik uzytkownika opis biezacego wydania
Przekazanie (ang. Transition) wdrozenie systemu u koncowego uzytkownika dzialajacy system
21
Struktura organizacyjna

• RUP proponuje strukture zespolów w dwóch
  obszarach
• biznesowym (business unit)
• projektowym
• Zadaniem zespolu biznesowego jest koordynowanie
  funkcji i zasobów wykorzystywanych w wielu
  projektach z zastosowaniem wspólnej technologii i
  zasad

22
Struktura organizacyjna

• Zespól biznesowy odpowiada za
• definicje i doskonalenie procesów
• przestrzeganie zalozen umów (kontraktów)
• dostarczenie narzedzi programistycznych
• wsparcie logistyczne personelu (trening,
  biblioteki, organizacja badan i rozwoju itp.)

23
Struktura organizacyjna

• Organizacja projektowa sklada sie z nastepujacych
  zespolów
• zarzadzania oprogramowaniem (Software Management
  Team)
• inzynierii systemowej (Systems Engineering Team)
• administracyjny (Administration Team)
• architektury oprogramowania (Software
  Architecture Team)
• rozwoju oprogramowania (Software Development
  Team)
• oceny oprogramowania (Software Assessment Team)

24
Struktura organizacyjna

• W ramach oceny realizowane sa nastepujace
  zadania
• Zarzadzanie konfiguracja
• identyfikacja konfiguracji, kontrola zmian,
  raportowanie statusów, audyty
• Zapewnienie jakosci
• Testowanie
• Zarzadzanie narzedziami

25
Zalety RUP

• RUP jest procesem iteracyjnym zakladajacym
  budowanie systemu w kolejnych przebiegach
• Po zakonczeniu iteracji produkowany jest fragment
  systemu spelniajacy wymagania klienta, jest on
  nastepnie udostepniany
• W ten sposób zespól analityczno-projektowy
  otrzymuje szybko sygnal zwrotny od klienta, który
  umozliwia biezaca ocene ryzyka niepowodzenia
  projektu jak równiez pozwala stwierdzic czy
  zespól analityczno-projektowy dobrze zrozumial
  wymagania klienta wobec systemu

26
Zalety RUP

• W razie wystapienia problemów zostana one szybko
  wykryte i zespól analityczno-projektowy bedzie
  mógl wdrozyc odpowiednie postepowanie zaradcze
• Podejscie iteracyjne powoduje gwaltowna redukcje
  ryzyka niepowodzenia projektu juz po zakonczeniu
  pierwszej iteracji

27
Wady RUP

• Rup to metodyka ciezka i kosztowna
• Wymaga obszernego dokumentowania procesu
• Ogranicza inicjatywe i samodzielnosc
• Wysokie koszty administracyjne
• Sztywne procedury (np. audytu)

28
Metodyki zwinne (agile)

• Irytacja podejsciami nastawionymi na
  kontrolowanie procedur i dyscypline
• W jaki sposób mozna odchudzic procesy
  wytwarzania oprogramowania, przy zachowaniu
  wysokiej jakosci (lub czasem wrecz jej
  poprawieniu)?
• Powstaly lekkie metodyki rozwoju
  oprogramowania, których dobrym przykladem jest
  Programowanie Ekstremalne, po angielsku zwane
  równiez XP

29
Metodyki zwinne (agile)

• Programowanie Ekstremalne (XP) wymyslone przez
  Kenta Becka w latach 1996-1999, kiedy to pracowal
  w firmie Chrysler nad oprogramowaniem
  przetwarzajacym listy plac dla 87000 pracowników
• XP i inne lekkie podejscia, wyrosly na
  pragmatycznym gruncie sukcesu tzw. "dobrych
  praktyk" programistycznych

30
Metodyki zwinne (agile)

• Praktyki te obejmuja m. in.
• aktywny udzial klienta w pracach rozwojowych
• szybkie sprzezenie zwrotne pomiedzy formulowaniem
  wymagan biznesowych a ich realizacja
• nieustanna pielegnacje jakosci wytwarzanego
  oprogramowania poprzez intensywne testowanie
• refaktoryzacje oraz konstrukcje efektywnego
  zespolu

Termin refaktoryzacja definiuje sie jako
mechanizm zmiany struktury kodu bez zmiany jego
zachowania
31
Manifest zwinnosci (Agile Manifesto)

• Kent Beck - twórca metody kart CRC stosowanej
  podczas analizy obiektowej, autor narzedzi xUnit
  - wspomagajacych testowanie jednostkowe oraz
  twórca XP
• Alistair Cockburn - autor rodziny zwinnych
  metodyk Crystal, oraz ksiazek poswieconych
  inzynierii wymagan (glównie przypadkom uzycia)
• Martin Fowler - twórca pomyslu refaktoryzacji,
  autor swietnej ksiazki UML Distilled (UML w
  kropelce)
• Jim Highsmith - autor metodyki Adaptive Software
  Development

32
Manifest zwinnosci

• Jednostki i interakcje sa wazniejsze niz procesy
  i narzedzia
• Dzialajace oprogramowanie jest wazniejsze niz
  obszerna dokumentacja
• Wspólpraca z klientem jest wazniejsza niz
  negocjacja kontraktu
• Nadazanie ze zmianami jest wazniejsze niz
  trzymanie sie planu

33
Wartosci XP

• Komunikacja
• Prostota
• Sprzezenie zwrotne
• Odwaga
• Szacunek

34
Komunikacja

• Budowanie systemów informatycznych wymaga
  przekazania wymagan od klienta do programistów
• W tradycyjnych metodykach wykorzystuje sie w tym
  celu dokumenty (specyfikacje wymagan)
• XP posluguje sie komunikacja werbalna, dzieki
  czemu wiedza o systemie bardzo szybko
  rozprzestrzenia sie w zespole
• Dzieki komunikacji wszyscy czlonkowie zespolu
  maja takie samo wyobrazenie przyszlego systemu i
  wiedza w jakim kierunku projekt dazy

35
Prostota

• XP zacheca do rozpoczecia najprostszym mozliwym
  rozwiazaniem problemu (minimalnym, spelniajacym
  pewne poczatkowe wymagania)
• Dopiero kiedy sie upewnimy ze idziemy w
  prawidlowym kierunku, na tej podstawie
  dobudowujemy reszte
• Dzieki refaktoryzacji jakosc produktu jest stale
  na najwyzszym poziomie
• Dzieki prostocie programisci skupiaja sie na
  projektowaniu i kodowaniu na potrzeby biezacego
  dnia, a nie robia nic na wyrost

36
Sprzezenie zwrotne

• System - wazna jest odpowiedz systemu,
  otrzymywana w procesie testowania jednostkowego
• Klient - przygotowuje testy akceptacyjne wraz z
  testerem dzieki takim testom mozna sprawdzic w
  jakim stanie znajduje sie aktualnie budowany
  system
• Zespól - w momencie kiedy klient proponuje nowe
  wymagania podczas gry planistycznej, zespól
  podaje szacunki ile czasu zajmie ich
  zaimplementowanie

37
Odwaga

• Odwaga jest potrzebna, aby przestrzegac zasady
  projektowania i kodowania wg aktualnych potrzeb,
  bez zastanawiania sie co bedzie potrzebne w
  przyszlosci
• Odwaga, aby nie angazowac sie za bardzo w
  projektowanie i od razu przejsc do kodowania
• Odwaga jest potrzebna, aby zrefaktoryzowac kod,
  wtedy kiedy to jest potrzebne, aby nie bac sie
  refaktoryzacji
• Jezeli okaze sie, ze pewien fragment kodu jest
  juz nieprzydatny, lub musi zostac zmieniony, do
  podjecia decyzji o wyrzuceniu takiego kodu
  potrzeba duzo odwagi

38
Szacunek

• Nie mozna wysylac do repozytorium zmian, które
  nie daja sie skompilowac lub powoduja bledy w
  testach jednostkowych, gdyz przez to praca innych
  osób bedzie utrudniona, lub niemozliwa i straca
  one duzo czasu
• Dzieki dazeniu do najwyzszej jakosci i szukanie
  najlepszych rozwiazan projektowych (dzieki
  refaktoryzacji) innym osobom bedzie duzo latwiej
  wykorzystac kod napisany przez nas

39
XP

• Reguly i praktyki

40
Struktura zespolu

• XP nie pokazuje wprost struktury zespolu
• Dwie glówne role w zespole pelnia
• programisci
• klient
• Klient uwazany jest za czlonka zespolu, wiec musi
  przez caly czas pracowac razem z informatykami (w
  jednym pomieszczeniu) czasem nie wystepuje w tej
  roli osobiscie, lecz za posrednictwem
  przedstawiciela klienta

41
Struktura zespolu

• Role pomocnicze pelnia
• tester, którego zadaniem jest napisanie skryptów
  testowych na podstawie rozmów z klientem
• coach, to osoba, która pomaga rozwiazywac
  napotkane problemy
• tracker natomiast zbiera statystyki dotyczace
  wykonanych zadan, czasu pracy i tworzy
  podsumowania postepów projektu

42
(No Transcript)
43
Opowiesci uzytkowników

• Przedstawiciel klienta jest ciaglym zródlem
  wymagan
• Wymagania sa dyskutowane z nim na biezaco,
  natomiast slad z tych dyskusji jest przechowywany
  w formie opowiesci uzytkowników
• Kazda opowiesc jest zapisana w kilku zdaniach na
  malej kartce papieru
• Moze byc oznaczona dodatkowymi atrybutami (np.
  data utworzenia, typ, numer, rozmiar)

44
Hydrodynamiczny model projektu
45
Hydrodynamiczny model projektu
46
Cykl zycia
47
Cykl zycia
48
Wydania i przyrosty

• Kazde wydanie ma wartosc uzytkowa i trafia do
  uzytkowników koncowych, dzieki czemu programisci
  dostaja sprzezenie zwrotne
• Nalezy stosowac czeste i krótkie wydania
• Przyrosty maja charakter wewnetrzny
• Posrednie przyrosty niekoniecznie stanowia
  produkt, z którego klient bylby w stanie
  skorzystac
• Kazdy przyrost powinien trwac 2-3 tygodnie, oraz
  zawierac kilka opowiesci uzytkownika

49
Gra planistyczna

• Na poczatku gry planistycznej podczas rozmów
  dotyczacych wymagan systemu klient spisuje
  opowiesci uzytkownika
• Informatycy szacuja rozmiar opowiesci, podajac
  liczbe osobo-dni potrzebnych do jej zrealizowania
• Jezeli opowiesc jest za duza (np. wykracza poza
  jeden przyrost), wówczas dzieli sie ja na
  mniejsze
• Jezeli opowiesc jest tez zbyt mala wtedy laczy
  sie ja z inna opowiescia

50
Gra planistyczna

• W momencie kiedy spisane sa wstepne opowiesci i
  oszacowane przez informatyków, klient wybiera
  zakres kolejnych przyrostów
• Klient zna koszt kazdej opowiesci i moze
  zadecydowac czy bedzie ona realizowana czy tez
  nie, oraz kiedy bedzie realizowana, czyli do
  którego dwutygodniowego przyrostu nalezy ja
  przypisac

51
Zapewnienie jakosci

• XP stawia na prostote rozwiazan (optymalizowac
  kod nalezy tylko wtedy, gdy jest to konieczne)
• Przed rozpoczeciem kodowania nalezy przygotowac
  przypadki testowe (ang. test-first-coding)
• Tak przygotowane testy sa nastepnie jak
  najczesciej wykonywane automatycznie - dzieki
  czemu na biezaco wychwytywane sa bledy
• Do poprawy czytelnosci kodu stosuje sie
  refaktoryzacje

52
Zapewnienie jakosci

• Zanim udostepni sie zmiany dla innych
  programistów, nalezy dokladnie przetestowac go za
  pomoca testów jednostkowych
• Jezeli wykryjemy jakis blad na przetestowanym
  kodzie, oznacza to, ze sito zlozone z testów
  jednostkowych w pewnym miejscu jest
  nieszczelne w takiej sytuacji nalezy je
  uszczelnic dodajac nowe przypadki testowe
  zapobiegajace przedostaniu sie tego bledu w
  przyszlosci
• Nalezy równiez jak najczesciej uruchamiac testy
  integracyjne i akceptacyjne

53
Programowanie parami

• W tym podejsciu, przy jednym komputerze siedza 2
  osoby jednoczesnie autor i recenzent
• Autor pisze kod, natomiast recenzent na biezaco
  go przeglada i wychwytuje defekty
• Autor jest bardzo skupiony na tworzeniu kodu, a
  recenzent ma wiecej czasu na myslenie moze sie
  okazac zatem, ze znajdzie lepszy sposób na
  rozwiazanie problemu, lub np. dostrzeze problemy
  zwiazane z testowaniem obecnego kodu, lub po
  prostu wychwyci blad w programie

54
Programowanie parami

• XP zaleca, zeby kazdy fragment kodu powstal
  poprzez programowanie parami
• Potrzebny jest wspólny standard kodowania dla
  calego zespolu
• XP zaklada, ze beda nastepowac czeste zmiany w
  parach, tak aby kazda osoba pracowala nad kazdym
  fragmentem systemu co ma dodatkowa zalete w
  postaci przeplywania wiedzy pomiedzy
  poszczególnymi programistami
• Dodatkowo w momencie kiedy jeden programista
  odejdzie z zespolu, dla kazdego fragmentu kodu
  znajdziemy inna osobe, która bedzie znala ten
  fragment

55
Programowanie parami

• W XP nie ma osoby odpowiedzialnej za kazda czesc
  kodu - kod jest wlasnoscia calego zespolu
• Nie da sie wydajnie pracowac parami, jezeli nie
  ma w firmie systemu zarzadzania wersjami, np. CVS
  
• Wymagana jest równiez otwarta przestrzen pracy
  dla zespolu - aby poszczególne osoby mogly sie
  latwo komunikowac

56
Czynniki ryzyka

• Zalozenie, ze klient przez caly czas pracuje z
  zespolem moze sie okazac nierealne - rzadko który
  klient moze sobie pozwolic na oddelegowanie
  jednego pracownika na kilka miesiecy (gdyz tyle
  moze trwac projekt)
• Brak dokumentacji z jednej strony powoduje
  przyspieszenie projektu, lecz czasem moze sie
  okazac, ze po pewnym czasie trzeba wrócic do prac
  nad systemem (np. dodac nowa funkcjonalnosc)
  wtedy, bez odpowiedniej dokumentacji, trudno
  przypomniec sobie za co poszczególne fragmenty
  kodu byly odpowiedzialne

57
Czynniki ryzyka

• Niektórzy zarzucaja równiez brak fazy
  projektowania - twierdza, ze rozwiazania powstaja
  za bardzo ad hoc
• Krótka perspektywa planowania (planuje sie tylko
  kolejne wydanie) nie pozwala przewidziec, kiedy
  system bedzie ukonczony

58
Metodyka PRINCE2

• Projects in a Controlled Environment tzn.
  Projekty w sterowanym srodowisku
• 1989 - brytyjska agenda rzadowa Central Computer
  and Telecommunications Agency (CCTA) opublikowalo
  standard pod nowa nazwa PRINCE
• 1996 - PRINCE2 opublikowany jako ogólna metoda
  zarzadzania projektami niezalezna od dziedziny
  biznesowej zastosowania
• 2005 - ostatnie zmiany opublikowane przez Office
  for Government Commerce (OGC) nastepce CCTA

59
Uruchamianie projektu

• Przygotowanie projektu do uruchomienia
• Ma zapewnic, ze projekt bedzie wart ponoszonych
  kosztów i ze da sie go zrealizowac
• Informacja wejsciowa dla procesu jest Zlecenie
  Przygotowania Projektu (Project Mandate)
• W proces zaangazowane jest wyzsze kierownictwo
  organizacji, które ustanawia i wybiera Komitet
  Sterujacy (Project Board), który nadzoruje
  projekt i wybiera Kierownika Projektu

60
Uruchamianie projektu

• Uzasadnienie projektu jest zarysowane w
  Podstawowych Zalozeniach Projektu
• W zaleznosci od specyfiki projektu wybierana jest
  formula realizacyjna
• Wykonany jest takze plan etapu inicjowania
  projektu.

61
Uruchamianie projektu

• PP1. Mianowanie Przewodniczacego Komitetu
  Sterujacego i Kierownika Projektu
• PP2. Projektowanie zespolu zarzadzania projektem
• PP3. Mianowanie zespolu zarzadzania projektem
• PP4. Przygotowanie podstawowych zalozen projektu
• PP5. Definiowanie formuly realizacyjnej/Definiowan
  ie
• PP6. Planowanie etapu inicjowania

62
Zarzadzanie strategiczne projektem

• Realizuje funkcje, za które odpowiedzialny jest
  Komitet Sterujacy
• Kierownik Projektu informuje Komitet Sterujacy w
  raportach okresowych o stanie projektu
• Biezace zarzadzanie pozostawione jest w wylacznej
  kompetencji Kierownika Projektu

63
Zarzadzanie strategiczne projektem

• Komitet Sterujacy angazuje sie tylko na granicach
  etapów zarzadczych, gdzie decyduje, czy nalezy
  kontynuowac prace przechodzac do nastepnego etapu
• Fundamentalna zasada PRINCE2 jest zarzadzanie
  poprzez wyjatki management by exception, co
  oznacza, ze Komitet Sterujacy angazuje sie w
  podejmowanie decyzji projektowych jedynie, gdy
  uzyska informacje, ze projekt jest zagrozony
  wyjsciem poza zakres tolerancji

64
Planowanie

• PL1. Projektowanie planu
• PL2. Definiowanie i analizowanie produktów
• PL3. Okreslanie dzialan i zaleznosci
• PL4. Szacowanie
• PL5. Harmonogramowanie
• PL6. Analizowanie ryzyka
• PL7. Kompletowanie planu

65
Inicjowanie projektu

• IP1. Planowanie jakosci
• IP2. Planowanie projektu
• IP3. Doprecyzowanie Uzasadnienia Biznesowego i
  Ryzyka
• IP4. Ustanowienie elementów sterowania
• IP5. Ustanowienie dokumentacji projektowej
• IP6. Zestawienie Dokumentu Inicjujacego Projekt

66
Sterowanie etapem

• SE1. Zgoda na wykonanie grupy zadan
• SE2. Ocena postepów
• SE3. Rejestrowanie zagadnien projektowych
• SE4. Analizowanie zagadnien projektowych
• SE5. Przegladanie stanu etapu
• SE6. Raportowanie o waznych zdarzeniach
• SE7. Podejmowanie dzialan korekcyjnych
• SE8. Eskalowanie zagadnien projektowych
• SE9. Odbieranie wykonanych grupy zadan

67
Zarzadzanie wytwarzaniem produktów

• PRINCE2 to metodyka oparta na produktach
  produktem moze byc rzecz materialna np. ksiazka
• Moze nim byc tez rzecz bardziej niematerialna np.
  poziom uslug serwisowych
• W zasadzie wszystko, co zostalo wytworzone przez
  projekt zgodny z PRINCE2, wlaczajac w to
  dokumenty jest produktem
• Produkt moze byc wytworzony przez kogokolwiek,
  takze przez zewnetrznego dostawce.

68
Zarzadzanie wytwarzaniem produktów

• WP1. Przyjecie grupy zadan do realizacji
• WP2. Wytwarzanie grupy zadan
• WP3. Dostarczanie grupy zadan

69
Zarzadzanie zakresem etapu

• Zgodnie z PRINCE2 kazdy etap musi byc ukonczony i
  zaakceptowany zanim Komitet Sterujacy autoryzuje
  przejscie do nastepnego etapu
• W tym procesie weryfikowane jest, czy etap
  dostarczyl wszystkie wymagane produkty i czy
  pierwotne parametry biznesowe nie ulegly zmianie
• Planowany jest tez w tym kontekscie
  uszczególowiony plan nastepnego etapu

70
Zarzadzanie zakresem etapu

• ZE1. Planowanie etapu
• ZE2. Uaktualnienia planu projektu
• ZE3. Uaktualnienie uzasadnienia biznesowego
  projektu
• ZE4. Uaktualnienie rejestru ryzyka
• ZE5. Raportowanie konca etapu
• ZE6. Opracowanie planu naprawczego

71
Zamykanie projektu

• Wedlug metodyki PRINCE2 projekty musza byc
  zamykane w sposób uporzadkowany i kontrolowany
• Wszystkie doswiadczenia zdobyte w trakcie
  prowadzenia projektu sa rejestrowane, tworzony
  jest dokument przekazania i planowany jest
  przeglad powdrozeniowy
• Po zakonczeniu projektu w zaplanowanym momencie
  pozwalajacym na nalezyta ocene skutków
  biznesowych projektu przeprowadzany jest przeglad
  poprojektowy

72
Zamykanie projektu

• ZP1. Przygotowanie projektu do zamkniecia
• ZP2. Okreslanie dzialan nastepczych
• ZP3. Przeglad oceniajacy projekt

73
Komponenty

• Uzasadnienie biznesowe
• Organizacja
• Plany
• Elementy sterowania
• Zarzadzanie ryzykiem
• Jakosc w srodowisku projektu
• Zarzadzanie konfiguracja
• Sterowanie zmianam

74
Uzasadnienie biznesowe

• Przeznaczeniem Uzasadnienia Biznesowego jest
  okreslenie mierzalnych celów uzasadniajacych
  zaangazowanie zasobów w projekcie
• Uzasadnienie biznesowe musi byc aktualizowane
  przez caly cykl zycia projektu
• Wlascicielem uzasadnienia biznesowego jest
  Przewodniczacy Komitetu Sterujacego

75
Organizacja

• Glówne role w projekcie pelnia
• Komitet Sterujacy (Project Board)
• Przewodniczacy Komitetu Sterujacego (Executive)
• Glówny Uzytkownik (Senior User)
• Glówny Dostawca (Senior Supplier)
• Kierownik projektu (Project Manager)
• Nadzór projektu (Project Assurance)
• Kierownik Zespolu rola opcjonalna (Team
  Manager)
• Wsparcie Projektu rola opcjonalna (Project
  Support)

76
Plany

• Plany zgodnie z PRINCE2 musza byc zatwierdzone
  zanim zostana przekazane do realizacji. Wyróznia
  sie 3 poziomy planu
• Plan projektu (Project Plans)
• Plan etapu (Stage Plans)
• Plan pracy zespolu (Team Plans)
• Ponadto czwartym typem planu jest plan naprawczy
  (Exception plan), który zastepuje plan etapu w
  wypadku pojawienia sie zagrozenia istotnymi
  odchyleniami przekraczajacymi tolerancje

77
Elementy sterowania

• Elementy sterowania maja zapewnic, ze projekt
  jest prowadzony zgodnie z planem i uzasadnieniem
  biznesowym
• PRINCE2 stosuje metode zwana 'management by
  exception', która angazuje Komitet Sterujacy
  tylko wtedy kiedy pojawia sie odchylenie
  wskazujace na mozliwosc wykroczenia projektu poza
  ramy okreslone tolerancja i uzasadnieniem
  biznesowym
• Cala odpowiedzialnosc za biezace zarzadzanie
  projektem oraz podejmowanie decyzji zmierzajacych
  do realizacji zadan projektowych zgodnie z planem
  spoczywa na Kierowniku Projektu

78
Elementy sterowania

• Podstawowymi elementami sterowania sa
• Inicjowanie projektu
• Raporty o waznych wydarzeniach
• Raporty o istotnych odchyleniach
• Ocena nadzwyczajna
• Ocena koncowa etapu
• Zamkniecie projektu
• Tolerancja

79
Zarzadzanie Ryzykiem

• Kazdy projekt z uwagi na niepowtarzalnosc
  parametrów realizacyjnych oraz zmiany w otoczeniu
  biznesowym musi brac pod uwage mozliwosc
  wystapienia zdarzen nieplanowanych mogacych miec
  istotny wplyw na sposób jego realizacji
• Ryzyko to niepewnosc wyniku
• Zarzadzanie ryzykiem polega na utrzymywaniu
  ryzyka w akceptowalnych granicach w sposób
  efektywny i racjonalny kosztowo

80
Zarzadzanie Ryzykiem

• Zarzadzanie ryzykiem opiera sie na 3 zasadach
• Tolerancji na ryzyko
• Odpowiedzialnosci za ryzyko
• Wlasnosci (przynaleznosc) ryzyka

81
Jakosc w srodowisku projektowym

• Celem projektu jest wytworzenie produktów,
  zgodnych z ich przeznaczeniem, zaspokajajacych
  potrzeby oraz oczekiwania jakosciowe klienta
• Oczekiwania jakosciowe sa okreslone w Zleceniu
  Projektu (Project Mandate), Zalozeniach Projektu
  (Project Brief) oraz Dokumencie Inicjujacym
  Projekt (Project Initiation Document)

82
Jakosc w srodowisku projektowym

• Zarzadzanie jakoscia opiera sie na 4 skladnikach
• Systemie Zarzadzania Jakoscia
• Funkcji zapewniania jakosci
• Planowaniu jakosci
• Kontroli jakosci

83
Zarzadzanie konfiguracja

• Zarzadzanie konfiguracja zajmuje sie
  kontrolowaniem wszystkich produktów projektu
• Konfiguracja to zbiór logicznie powiazanych
  produktów, które musza byc traktowane i
  zarzadzane jako zlozona calosc uwzgledniajaca
  zaleznosci pomiedzy wersjami czesci skladowych i
  ich statusami

84
Zarzadzanie konfiguracja

• Zarzadzanie konfiguracja sklada sie z 5
  elementów
• Planowanie
• Identyfikacja
• Kontrola
• Charakteryzowanie statusu
• Weryfikacja

85
Techniki projektowe

• Planowanie oparte na produktach
• Sterowanie zmianami
• Przeglady jakosci

86
Planowanie oparte na produktach

• PRINCE2 stosuje planowanie oparte na produktach
  nie zas oparte na dzialaniach
• Polega to na tym, ze PRINCE2 planuje i mierzy
  postep projektu realizacja poszczególnych
  precyzyjnie zdefiniowanych produktów a nie
  subiektywnie mierzonych dzialan
• Planowanie oparte na produktach stosuje
  nastepujace produkty
• Struktura produktowa
• Opisy produktów
• Diagram nastepstwa produktów

87
Sterowanie zmianami

• W PRINCE2 wszystkie zmiany sa traktowane jako
  zagadnienia projektowe
• wnioski o zmiane dotyczace zmiany w wymaganiach
  albo produkcie
• odstepstwo rejestrowane kiedy produkt nie
  spelnia wymagan.
• sugestie
• zapytania
• zagadnienia ogólne

88
Sterowanie zmianami

• Obsluga wszystkich zagadnien projektowych jest w
  gestii Kierownika Projektu
• Ich zgloszenia musza byc udokumentowane w
  Rejestrze zagadnien (Issue Log)
• Wnioski o zmiane musza byc zaakceptowane przez
  Komitet Sterujacy lub Komitet ds. zmian (Change
  Authority)
• Przed akceptacja zmiany musi byc wykonana analiza
  wplywu zmiany
• Odstepstwa (Off specification) moga byc
  zalatwiane w ramach dzialan korygujacych przez
  Kierownika Projektu o ile nie wykraczaja one poza
  okreslone dla projektu granice tolerancji
• Komitet Sterujacy moze zaakceptowac odstepstwa
  bez uruchamiania dzialan korygujacych definiujac
  je jako ustepstwo

89
Przeglady jakosci

• PRINCE2 wymaga aby produkty podlegaly przegladowi
  jakosci
• Zadaniem przegladów jakosci jest okreslenie czy
  produkt spelnia kryteria jakosci okreslone w
  Opisie Produktu tzn. czy nie zawiera bledów,
  braków lub innych niezgodnosci.

90
Mocne strony PRINCE2

• Stosowanie tej metodyki zapewnia wysoka
  standaryzacje i powtarzalnosc projektów o
  wspólnym podejsciu, terminologii i dokumentacji
  co zapewnia mozliwosc doskonalenia kompetencji
• Metodyka w sposób racjonalny opiera sie na
  najlepszych praktykach w zarzadzaniu projektami
• Wprowadza management by exception jako podstawowa
  zasade, która zapewnia Kierownikowi Projektów
  swobode dzialania bez zbednej ingerencji,
  zapewniajac jednoczesnie zaangazowanie wyzszego
  kierownictwa, wtedy kiedy projekt jest zagrozony
  wykroczeniem poza granice tolerancji lub
  przestaje realizowac uzasadnienie biznesowe

91
Mocne strony PRINCE2

• Sprawuje kontrole nad startem, realizacja i
  koncem projektu
• Kazdy z dokumentów wymaganych przez PRINCE2 jest
  dostarczony jako szablon zawierajacy wymagane
  metryke, rozdzialy i pola informacyjne co
  zapewnia przejrzystosc, standaryzacje i
  kompletnosc dokumentacji
• Przewiduje mozliwosc adaptacji do specjalnych
  potrzeb organizacji, programu lub projektu
• Jej stosowanie nie wymaga oplat autorskich
• Materialy PRINCE2 sa opublikowane i szeroko
  dostepne co ogranicza prace nad wypracowywaniem
  wlasnych standardów i przygotowaniem materialów
  szkoleniowych

92
Slabosci PRINCE2

• Duzo organizacji cierpi na syndrom PINO (Prince
  In Name Only tzn. PRINCE2 tylko z nazwy),
  wybierajac bez glebszej analizy tylko niektóre
  skladniki metodyki nie zwracajac uwagi na
  podstawowe zasady
• PRINCE2 kladzie duzy nacisk na dokumentowanie
  jako narzedzie sprawnej kontroli sposobu
  realizacji projektu
• W niektórych organizacjach dokumenty staja sie
  jednak celem samym w sobie, a rzeczywiste
  projekty koncza sie niepowodzeniem

93
Slabosci PRINCE2

• Podobnie uwaga jaka zwraca PRINCE2 na potrzebe
  dobrej organizacji i regularna wymiane informacji
  pomiedzy zainteresowanymi odbierana jest
  nieslusznie jako zacheta do ciaglych
  bezproduktywnych spotkan zabierajacych czas
  niezbedny na rzeczywista prace
• PRINCE2 nie definiuje wprost analizy wymagan tak
  wiec moze prowadzic do niepowodzenia projektu z
  uwagi na przyjecie falszywych zalozen (z drugiej
  strony jasno jest okreslone, kto ponosi
  odpowiedzialnosc za przyjecie zlych zalozen i
  akceptacje nietrafnego uzasadnienia biznesowego a
  przeslanki tych decyzji sa udokumentowane i moga
  stanowic nauczke na przyszlosc)

94
Slabosci PRINCE2

• Zbyt scisle przestrzeganie PRINCE2 bez
  odpowiedniej adaptacji do realiów biznesowych
  moze byc zbyt pracochlonne w zastosowaniu do
  malych projektów
• Niezbyt "zwinna"

95
XPrince

• Koncepcja metodyki XPrince zostala zaproponowana
  przez Jerzego Nawrockiego z Instytutu Informatyki
  Politechniki Poznanskiej i jest rozwijana przez
  zespól Inzynierii Oprogramowania
• Pod koniec 2004 roku do tego projektu
  akademickiego przylaczyla sie grupa firm
  wytwarzajacych oprogramowanie i zostalo powolane
  Konsorcjum XPrince, które przejelo patronat nad
  rozwijaniem i promowaniem metodyki XPrince
• Aktualnie metodyka XPrince jest wdrazana w
  przedsiebiorstwach bedacych czlonkami konsorcjum

96
Zródlo

• Równowaga miedzy zwinnoscia a dyscyplina z
  wykorzystaniem XPrince
• Lukasz Olek we wspólpracy z Jerzym Nawrockim,
  Michalem Jasinskim, Bartoszem Paliswiatem,
  Bartoszem Walterem, Blazejem Pietrzakiem i
  Piotrem Godkiem
• Politechnika Poznanska, Instytut Informatyki
  ul. Piotrowo 3A, 60-965 Poznan

97
Zalozenia

• Jak zauwazyli Barry Boehm i Richard Turner kazde
  pomyslne przedsiewziecie w zmieniajacym sie
  swiecie wymaga zarówno zwinnosci jak i dyscypliny
• XPrince (eXtreme PRogramming IN Controlled
  Environments) bazuje na trzech innych metodykach
  XP, PRINCE2 oraz RUP i jest zintegrowana i
  elastyczna metodologie wytwarzania oprogramowania
  wraz z towarzyszacymi narzedziami, której celem
  jest wywazenie miedzy zwinnoscia i dyscyplina

98
Zalozenia

• W tym celu zintegrowano metodyke zarzadzania
  projektem (PRINCE2) z metodyka wytwarzania
  oprogramowania (XP) oraz stworzono narzedzia,
  które pomagaja efektywnie zintegrowac rózne
  techniki wytwarzania oprogramowania
• Narzedzie UC Workbench jest zintegrowanym
  edytorem wymagan w postaci przypadków uzycia z
  generatorem makiet funkcjonalnych oraz
  kalkulatorem pracochlonnosci
• Zintegrowano równiez ponowne uzycieoprogramowania
  (reuse) z testowaniem (przypadki testowe sa
  wykorzystywane jako specyfikacja wyszukiwanych
  komponentów oprogramowania).

99
Porównanie struktur organizacyjnych
100
Cykle zycia
101
Rozpoczecie projektu

• Jest zazwyczaj wykonywane przez Menadzera
  Projektu, który ma nastepujace zadania
• ustanowic zespól zarzadzania projektem
• stworzyc wizje systemu (jest to krótsza i
  bardziej konkretna wersja dokumentów Szkic
  projektu i Podejscie do projektu z XPRINCE,
  zawiera on wstepne argumenty biznesowe)
• zaplanowac faze Inicjacji projektu

102
Inicjacja projektu

• Celem inicjacji jest dostarczenie planu i
  stworzenie srodowiska organizacyjnego dla
  projektu
• Jest to polaczenie Inicjacji projektu z PRINCE2
  oraz fazy Rozpoczecia z RUP
• Zadania tej fazy wykonuja glównie Kierownik
  projektu i Analityk z pomoca Architekta

103
Inicjacja projektu

• Zrozumiec, co nalezy zbudowac
• niekiedy konieczne jest stworzenie lekkiej wersji
  dokumentu ConOps, zawierajacego model biznesowy
  bazujacy na przypadkach uzycia, liste problemów,
  które nalezy rozwiazac oraz najwazniejsza
  funkcjonalnosc wymagana do rozwiazania tych
  problemów
• kluczowej funkcjonalnosci powinna towarzyszyc
  lista kryteriów jakosci i produktów
• osoba odpowiedzialna za to zadanie jest Analityk,
  który powinien równiez sledzic ryzyko z tym
  zwiazane.

104
Inicjacja projektu

• Zaproponowanie poczatkowej architektury
• powinien to byc krótki, wysokopoziomowy opis,
  dostarczajacy informacji potrzebnej do
  zaplanowania projektu
• powinien równiez zawierac liste potrzebnych
  narzedzi
• osoba odpowiedzialna za to zadanie, wraz z
  czynnikami ryzyka z nim zwiazanymi jest
  Architekt, lecz w przypadku gdy architektura
  rozwiazania wydaje sie byc oczywista, równiez
  Analityk moze wykonac to zadanie

105
Inicjacja projektu

• Zaplanowanie calego projektu i dopracowanie
  uzasadnienia biznesowego (ang. business case)
• ten cel jest nadzorowany przez Menadzera
  Projektu, który jest równiez odpowiedzialny za
  sledzenie ryzyka z tym zwiazanego
• plan projektu pokazuje projekt ze strategicznego
  punktu widzenia
• w celu wspierania zwinnosci plan projektu
  powinien byc zbudowany zgodnie z zasada rzeczy
  najwazniejsze najpierw
• powinien precyzowac liczbe wydan i przydzielic do
  nich funkcjonalnosc (przypadki uzycia na wysokim
  poziomie). Im dluzszy projekt, tym plan projektu
  powinien byc mniej konkretny
• faktyczne planowanie powinno sie odbywac na
  poziomie wydan

106
Inicjacja projektu

• Zaplanowanie calego projektu i dopracowanie
  uzasadnienia biznesowego (ang. business case)
• w XP nie istnieje plan projektu sa jedynie
  plany wydan
• w XPrince plan projektu zostal dodany nie tylko
  ze wzgledu na zgodnosc z PRINCE2, lecz równiez
  aby zapewnic szersza perspektywe, która okazuje
  sie bardzo potrzebna
• nalezy zrozumiec, iz plan projektu jest zródlem
  cennej informacji, nie zas usprawiedliwieniem
  odrzucania propozycji zmian
• kazda pózniejsza propozycja zmiany powinna byc
  zaakceptowana, jezeli pomaga osiagnac cele
  biznesowe

107
Inicjacja projektu

• Ustalenie kanalów komunikacyjnych i srodowiska
  zarzadzania projektem
• kanaly komunikacyjne obejmuja raporty (np. wyniki
  cotygodniowych testów akceptacyjnych,
  sugerowanych przez XP)
• srodowisko zarzadzania projektem moze byc
  klasyczne, bazujace na plikach i dokumentach, lub
  moze byc wspomagane zaawansowanymi narzedziami
• ten cel lezy w obowiazkach Menadzera Projektu.
• Plan fazy elaboracji

108
Faza Elaboracji

• Faza Elaboracji dotyczy glównie architektury.
  Architekt powinien zaproponowac mechanizmy
  architektoniczne, rozpoznac ryzyko z tym zwiazane
  (np. za pomoca eksperymentów) oraz stworzyc
  szkielet, który bedzie wykorzystywany przez
  Programistów
• Analityk i Menadzer Projektu w tej fazie
  udoskonalaja wymagania i plan projektu
• Kazde Wydanie sklada sie z kilku przyrostów, po
  których nastepuje faza tranzycji
• Na tym etapie proces wytwarzania oprogramowania
  bardzo przypomina XP
• Architekt i Programisci produkuja kod i przypadki
  testowe

109
Faza Elaboracji

• Analityk jest odpowiedzialny za wymagania i testy
  akceptacyjne, jak równiez gra role klienta
  bedacego na miejscu
• Przyrost jest jedynie wewnetrznym punktem
  kontrolnym
• Kazde Wydanie jest zakonczone faza tranzycji, w
  której nowa wersja systemu jest
• wdrazana i przekazywana uzytkownikom koncowym
• Podobnie jak w XP, kazdy przyrost powinien byc
  tak samo dlugi to pomaga Programistom czuc rytm
  iteracji oraz w rezultacie nauczyc sie lepiej
  planowac przyrosty

110
Zamkniecie projektu

• Zamkniecie projektu bardzo przypomina
  odpowiadajaca faze z PRINCE2
• Projekt jest zamykany, identyfikowane sa dalsze
  akcje i nastepuje ocena projektu.

111
Narzedzia PRINCE2

• UC Workbench to narzedzie wspomagajace
  zarzadzanie wymaganiami i modelowanie dziedziny
  biznesowej bazujace na przypadkach uzycia,
  rozwijane na Politechnice Poznanskiej

112
(No Transcript)
113
Programowanie

• Programowanie parami jest kluczowa praktyka w XP
• Para programistów wyposazona w jeden komputer
  jest przydzielana do zadania programistycznego
• Jeden z programistów pisze kod, natomiast drugi
  sledzi jego prace, zadaje pytania i proponuje
  przypadki testowe, tak wiec zapewnia to tzw.
  ciagly przeglad
• Inne podejscie do programowania zespolowego to
  programowanie Side-by-Side (SbS), które zostalo
  zaproponowane przez Cockburna

114
Programowanie

• W tym podejsciu pojedyncze zadanie jest
  rozwiazywane przez dwóch programistów, lecz kazdy
  z nich posiada osobny komputer
• Wyniki badan eksperymentalnych dotyczacych
  wydajnosci programowania parami oscyluja pomiedzy
  optymistycznymi (przyspieszenie rzedu 40 czasu i
  narzut 20 pracochlonnosci przy porównaniu z
  programowaniem indywidualnym, a calkiem
  pesymistycznymi (przyspieszenie rzedu 20, narzut
  60 )
• Niestety, nie ma opublikowanych zadnych
  aktualnych wyników eksperymentów dotyczacych
  szybkosci programowania SbS