Inicjacja projektu

Zarządzanie projektem systemu
informatycznego
Cykl życia projektu
• Formalnie określony sposób realizacji projektu
(plan projektu, metodologia budowy systemu)
• Uporządkowanie przebiegu prac
• Ułatwienie planowania zadań
• Monitorowanie przebiegu realizacji zadań
Modele cyklu życia
•
•
•
•
•
•
•
Realizacja kierowana dokumentami
Prototypowanie
Programowanie odkrywcze
Realizacja przyrostowa
Montaż z gotowych elementów
Model spiralny
Formalne transformacje
Prototypowanie
Ogólne określenie
wymagań
Budowa
prototypu
nie
Weryfikacja
przez klienta
tak
Pełne określenie
wymagań
Realizacja pełnego
systemu
Programowanie odkrywcze
Ogólne określenie
wymagań
Budowa
systemu
Przetestuj
system
nie
System
działa
poprawnie
tak
Dostarcz system
Realizacja przyrostowa
Proces realizowany
iteracyjnie
Określenie wymagań
Projekt ogólny
Wybór podzbioru
funkcji
Projekt szczegółowy,
implementacja i testy
Dostarczenie
zrealizowanej
części systemu
Montaż z gotowych elementów
• Źródła:
– biblioteki
– języki czwartej generacji
– pełne aplikacje
• Metody pozyskania:
– zakup modułów
– standaryzacja produktów
• Zalety:
– wysoka niezawodność, zmniejszenie ryzyka
– narzucenie standardów
– redukcja kosztów
Model spiralny
Planowanie
Atestowanie
Analiza ryzyka
Konstrukcja
(model kaskadowy)
Formalne transformacje
Formalna specyfikacja
wymagań
Postać pośrednia
...
Postać pośrednia
Kod
Model ogólny cyklu życia
Określanie
wymagań
Faza
strategiczna
Projektowanie
Implementacja
Analiza
Testowanie
Konserwacja
Instalacja
Dokumentacja
Rational Unified Process
• Rational Unified Process (RUP) to proces
iteracyjnego wytwarzania oprogramowania
opracowany przez firmę Rational Software
Corporation (firma została obecnie przejęta przez
IBM)
• Proces RUP nie jest pojedynczym, ściśle
określonym procesem, ale raczej szablonem
procesu
Rational Unified Process
• Został zaprojektowany w celu przystosowania do
charakteru konkretnej organizacji, konkretnego
zespołu projektowego lub nawet charakteru
konkretnego projektu
• Z szablonu RUP można wybrać elementy w
zależności od konkretnych potrzeb
Rational Unified Process
• Rational Unified Process (RUP) to także nazwa
oprogramowania, opracowanego przez Rational
Software (obecnie dostępnego w IBM)
zawierającego hipertekstową bazę wiedzy z
przykładowymi artefaktami oraz szczegółowymi
opisami wielu typów czynności
• Process RUP definiowany jest także w produkcie
Rational Method Composer (RMC), który
pozwala na tworzenie spersonalizowanych wersji
RUP
Iteracyjne wytwarzanie
oprogramowania
• Wytwarzanie oprogramowania w kolejnych
iteracjach, pozwala skupić się w pierwszej
kolejności na obszarach najbardziej ryzykownych
(np. najmniej rozpoznanych)
• W idealnym przypadku każda iteracja kończy się
stworzeniem wykonywalnego artefaktu - pomaga
to zredukować ryzyko w projekcie, otrzymujemy
szybciej opinie od odbiorców oprogramowania a
programistom pozwalamy skupić się na węższej
dziedzinie
Architektura bazująca na
komponentach
• Pozwala na stworzenie systemu, który jest łatwo
rozszerzalny, intuicyjnie zrozumiały i wspomaga ponowne
użycie (komponent to zbiór powiązanych obiektów)
• RUP skupia się na stworzeniu prostej architektury w
początkowych iteracjach
• Ewoluuje ona w każdej iteracji zbliżając się do
architektury finalnej
• Poprzez iteracyjne wytwarzanie oprogramowania
zyskujemy możliwość stopniowej identyfikacji
komponentów, które mogą być w dalszej części:
zakupione, zbudowane, lub użyte ponownie
Wizualne modelowanie
oprogramowania
• Abstrakcja projektowania od kodu i przedstawienie
koncepcji za pomocą bloków graficznych może być
efektywnym sposobem aby pokazać perspektywę
rozwiązania
• Reprezentacja graficzna jest produktem pośrednim
pomiędzy analizą procesu biznesowego, a implementacją
• Model w tym kontekście jest formą wizualizacji oraz
uproszczeniem bardziej skomplikowanego projektu
• RUP specyfikuje wymagane modele i opisuje dlaczego są
wymagane
Kontrola i weryfikacja jakości
oprogramowania
• Ocena jakości jest najczęstszym słabym punktem
projektów programistycznych ponieważ jest często
planowana po fakcie budowy systemu i czasami
obsługiwana przez inny zespół
• RUP pomaga w planowaniu kontroli jakości i jej ocenie
poprzez wbudowanie jej w cały proces i zaangażowanie w
nią wszystkich członków zespołu
• Proces koncentruje się na spełnieniu wymaganego
poziomu jakości i zapewnia mechanizmy do pomiaru tego
poziomu
Zarządzanie zmianami w
oprogramowaniu
• RUP definiuje metody śledzenia, ewidencji i
kontroli zmian
• Zdefiniowane są także tzw. secure workspaces
(bezpieczne przestrzenie robocze), które
pozwalają na zagwarantowanie, że zmiany w
innych systemach nie wpłyną na system tworzony
• Koncepcja ta jest ściśle powiązana z tworzeniem
architektury zorientowanej komponentowo
nazwa etapu
cele
produkty
Rozpoczęcie
(ang. Inception)
ustalenie zakresu projektu i
warunków granicznych
dokument wizji systemu
lista przypadków użycia
słownik systemu
ocena ryzyka
Opracowanie
(ang.
Elaboration)
definicja, walidacja architektury
model najważniejszych przypadków użycia
model architektury (widok logiczny)
uściślony plan i ocena ryzyka
Konstruowanie
(ang.
Construction)
otrzymanie użytecznych wersji
systemu
minimalizacja kosztów
wytwarzania
osiągnięcie adekwatnej jakości
produkt zintegrowany z docelową
platformą
podręcznik użytkownika
opis bieżącego wydania
Przekazanie
(ang.
Transition)
wdrożenie systemu u końcowego działający system
użytkownika
Struktura organizacyjna
• RUP proponuje strukturę zespołów w dwóch
obszarach
– biznesowym (business unit)
– projektowym
• Zadaniem zespołu biznesowego jest
koordynowanie funkcji i zasobów
wykorzystywanych w wielu projektach z
zastosowaniem wspólnej technologii i zasad
Struktura organizacyjna
• Zespół biznesowy odpowiada za
–
–
–
–
definicję i doskonalenie procesów
przestrzeganie założeń umów (kontraktów)
dostarczenie narzędzi programistycznych
wsparcie logistyczne personelu (trening, biblioteki,
organizacja badań i rozwoju itp.)
Struktura organizacyjna
• Organizacja projektowa składa się z następujących
zespołów:
–
–
–
–
–
–
zarządzania oprogramowaniem (Software Management Team)
inżynierii systemowej (Systems Engineering Team)
administracyjny (Administration Team)
architektury oprogramowania (Software Architecture Team)
rozwoju oprogramowania (Software Development Team)
oceny oprogramowania (Software Assessment Team)
Struktura organizacyjna
• W ramach oceny realizowane są następujące
zadania:
– Zarządzanie konfiguracją
• identyfikacja konfiguracji, kontrola zmian, raportowanie
statusów, audyty
– Zapewnienie jakości
– Testowanie
– Zarządzanie narzędziami
Zalety RUP
• RUP jest procesem iteracyjnym zakładającym budowanie
systemu w kolejnych przebiegach
• Po zakończeniu iteracji produkowany jest fragment
systemu spełniający wymagania klienta, jest on następnie
udostępniany
• W ten sposób zespół analityczno-projektowy otrzymuje
szybko sygnał zwrotny od klienta, który umożliwia bieżącą
ocenę ryzyka niepowodzenia projektu jak również pozwala
stwierdzić czy zespół analityczno-projektowy dobrze
zrozumiał wymagania klienta wobec systemu
Zalety RUP
• W razie wystąpienia problemów zostaną one
szybko wykryte i zespół analityczno-projektowy
będzie mógł wdrożyć odpowiednie postępowanie
zaradcze
• Podejście iteracyjne powoduje gwałtowną
redukcję ryzyka niepowodzenia projektu już po
zakończeniu pierwszej iteracji
Wady RUP
•
•
•
•
•
Rup to metodyka ciężka i kosztowna
Wymaga obszernego dokumentowania procesu
Ogranicza inicjatywę i samodzielność
Wysokie koszty administracyjne
Sztywne procedury (np. audytu)
Metodyki zwinne (agile)
• Irytacja podejściami nastawionymi na
kontrolowanie procedur i dyscyplinę
• W jaki sposób można „odchudzić” procesy
wytwarzania oprogramowania, przy zachowaniu
wysokiej jakości (lub czasem wręcz jej
poprawieniu)?
• Powstały „lekkie” metodyki rozwoju
oprogramowania, których dobrym przykładem jest
Programowanie Ekstremalne, po angielsku zwane
również „XP”
Metodyki zwinne (agile)
• Programowanie Ekstremalne (XP) wymyślone
przez Kenta Becka w latach 1996-1999, kiedy to
pracował w firmie Chrysler nad
oprogramowaniem przetwarzającym listy płac dla
87000 pracowników
• XP i inne lekkie podejścia, wyrosły na
pragmatycznym gruncie sukcesu tzw. "dobrych
praktyk" programistycznych
Metodyki zwinne (agile)
• Praktyki te obejmują m. in.:
– aktywny udział klienta w pracach rozwojowych
– szybkie sprzężenie zwrotne pomiędzy formułowaniem
wymagań biznesowych a ich realizacją
– nieustanną pielęgnację jakości wytwarzanego
oprogramowania poprzez intensywne testowanie
– refaktoryzację* oraz konstrukcję efektywnego zespołu
*Termin refaktoryzacja definiuje się jako mechanizm zmiany struktury kodu bez zmiany
jego zachowania
Manifest zwinności (Agile Manifesto)
• Kent Beck - twórca metody kart CRC stosowanej podczas
analizy obiektowej, autor narzędzi xUnit wspomagających testowanie jednostkowe oraz twórca XP
• Alistair Cockburn - autor rodziny zwinnych metodyk
Crystal, oraz książek poświęconych inżynierii wymagań
(głównie przypadkom użycia)
• Martin Fowler - twórca pomysłu refaktoryzacji, autor
świetnej książki „UML Distilled” (UML w kropelce)
• Jim Highsmith - autor metodyki Adaptive Software
Development
Manifest zwinności
• Jednostki i interakcje są ważniejsze niż procesy i
narzędzia
• Działające oprogramowanie jest ważniejsze niż
obszerna dokumentacja
• Współpraca z klientem jest ważniejsza niż
negocjacja kontraktu
• Nadążanie ze zmianami jest ważniejsze niż
trzymanie się planu
Wartości XP
•
•
•
•
•
Komunikacja
Prostota
Sprzężenie zwrotne
Odwaga
Szacunek
Komunikacja
• Budowanie systemów informatycznych wymaga
przekazania wymagań od klienta do programistów
• W tradycyjnych metodykach wykorzystuje się w tym celu
dokumenty (specyfikację wymagań)
• XP posługuje się komunikacją werbalną, dzięki czemu
wiedza o systemie bardzo szybko rozprzestrzenia się w
zespole
• Dzięki komunikacji wszyscy członkowie zespołu mają
takie samo wyobrażenie przyszłego systemu i wiedzą w
jakim kierunku projekt dąży
Prostota
• XP zachęca do rozpoczęcia najprostszym możliwym
rozwiązaniem problemu (minimalnym, spełniającym
pewne początkowe wymagania)
• Dopiero kiedy się upewnimy że idziemy w prawidłowym
kierunku, na tej podstawie dobudowujemy resztę
• Dzięki refaktoryzacji jakość produktu jest stale na
najwyższym poziomie
• Dzięki prostocie programiści skupiają się na projektowaniu
i kodowaniu na potrzeby bieżącego dnia, a nie robią nic na
wyrost
Sprzężenie zwrotne
• System - ważna jest odpowiedź systemu, otrzymywana w
procesie testowania jednostkowego
• Klient - przygotowuje testy akceptacyjne wraz z testerem;
dzięki takim testom można sprawdzić w jakim stanie
znajduje się aktualnie budowany system
• Zespół - w momencie kiedy klient proponuje nowe
wymagania podczas gry planistycznej, zespół podaje
szacunki ile czasu zajmie ich zaimplementowanie
Odwaga
• Odwaga jest potrzebna, aby przestrzegać zasady
projektowania i kodowania wg aktualnych potrzeb, bez
zastanawiania się co będzie potrzebne w przyszłości
• Odwaga, aby nie angażować się za bardzo w
projektowanie i od razu przejść do kodowania
• Odwaga jest potrzebna, aby zrefaktoryzować kod, wtedy
kiedy to jest potrzebne, aby nie bać się refaktoryzacji
• Jeżeli okaże się, że pewien fragment kodu jest już
nieprzydatny, lub musi zostać zmieniony, do podjęcia
decyzji o wyrzuceniu takiego kodu potrzeba dużo odwagi
Szacunek
• Nie można wysyłać do repozytorium zmian, które
nie dają się skompilować lub powodują błędy w
testach jednostkowych, gdyż przez to praca innych
osób będzie utrudniona, lub niemożliwa i stracą
one dużo czasu
• Dzięki dążeniu do najwyższej jakości i szukanie
najlepszych rozwiązań projektowych (dzięki
refaktoryzacji) innym osobom będzie dużo łatwiej
wykorzystać kod napisany przez nas
XP
Reguły i praktyki
Struktura zespołu
• XP nie pokazuje wprost struktury zespołu
• Dwie główne role w zespole pełnią:
– programiści
– klient
• Klient uważany jest za członka zespołu, więc musi
przez cały czas pracować razem z informatykami
(w jednym pomieszczeniu); czasem nie występuje
w tej roli osobiście, lecz za pośrednictwem
przedstawiciela klienta
Struktura zespołu
• Role pomocnicze pełnią:
– tester, którego zadaniem jest napisanie skryptów
testowych na podstawie rozmów z klientem
– coach, to osoba, która pomaga rozwiązywać napotkane
problemy
– tracker natomiast zbiera statystyki dotyczące
wykonanych zadań, czasu pracy i tworzy
podsumowania postępów projektu
Opowieści użytkowników
• Przedstawiciel klienta jest ciągłym źródłem wymagań
• Wymagania są dyskutowane z nim na bieżąco, natomiast
ślad z tych dyskusji jest przechowywany w formie
opowieści użytkowników
• Każda opowieść jest zapisana w kilku zdaniach na małej
kartce papieru
• Może być oznaczona dodatkowymi atrybutami (np. data
utworzenia, typ, numer, rozmiar)
Hydrodynamiczny model projektu
Hydrodynamiczny model projektu
Cykl życia
Cykl życia
Wydania i przyrosty
• Każde wydanie ma wartość użytkową i trafia do
użytkowników końcowych, dzięki czemu programiści
dostają sprzężenie zwrotne
• Należy stosować częste i krótkie wydania
• Przyrosty mają charakter wewnętrzny
• Pośrednie przyrosty niekoniecznie stanowią produkt, z
którego klient byłby w stanie skorzystać
• Każdy przyrost powinien trwać 2-3 tygodnie, oraz
zawierać kilka opowieści użytkownika
Gra planistyczna
• Na początku gry planistycznej podczas rozmów
dotyczących wymagań systemu klient spisuje
opowieści użytkownika
• Informatycy szacują rozmiar opowieści, podając
liczbę osobo-dni potrzebnych do jej zrealizowania
• Jeżeli opowieść jest za duża (np. wykracza poza
jeden przyrost), wówczas dzieli się ją na mniejsze
• Jeżeli opowieść jest też zbyt mała wtedy łączy się
ją z inną opowieścią
Gra planistyczna
• W momencie kiedy spisane są wstępne opowieści
i oszacowane przez informatyków, klient wybiera
zakres kolejnych przyrostów
• Klient zna koszt każdej opowieści i może
zadecydować czy będzie ona realizowana czy też
nie, oraz kiedy będzie realizowana, czyli do
którego dwutygodniowego przyrostu należy ją
przypisać
Zapewnienie jakości
• XP stawia na prostotę rozwiązań (optymalizować kod
należy tylko wtedy, gdy jest to konieczne)
• Przed rozpoczęciem kodowania należy przygotować
przypadki testowe (ang. test-first-coding)
• Tak przygotowane testy są następnie jak najczęściej
wykonywane automatycznie - dzięki czemu na bieżąco
wychwytywane są błędy
• Do poprawy czytelności kodu stosuje się refaktoryzację
Zapewnienie jakości
• Zanim udostępni się zmiany dla innych programistów,
należy dokładnie przetestować go za pomocą testów
jednostkowych
• Jeżeli wykryjemy jakiś błąd na przetestowanym kodzie,
oznacza to, że sito złożone z testów jednostkowych w
pewnym miejscu jest „nieszczelne”; w takiej sytuacji
należy je „uszczelnić” dodając nowe przypadki testowe
zapobiegające przedostaniu się tego błędu w przyszłości
• Należy również jak najczęściej uruchamiać testy
integracyjne i akceptacyjne
Programowanie parami
• W tym podejściu, przy jednym komputerze siedzą
2 osoby jednocześnie: autor i recenzent
• Autor pisze kod, natomiast recenzent na bieżąco
go przegląda i wychwytuje defekty
• Autor jest bardzo skupiony na tworzeniu kodu, a
recenzent ma więcej czasu na myślenie; może się
okazać zatem, że znajdzie lepszy sposób na
rozwiązanie problemu, lub np. dostrzeże problemy
związane z testowaniem obecnego kodu, lub po
prostu wychwyci błąd w programie
Programowanie parami
• XP zaleca, żeby każdy fragment kodu powstał poprzez
programowanie parami
• Potrzebny jest wspólny standard kodowania dla całego
zespołu
• XP zakłada, że będą następować częste zmiany w parach,
tak aby każda osoba pracowała nad każdym fragmentem
systemu co ma dodatkową zaletę w postaci przepływania
wiedzy pomiędzy poszczególnymi programistami
• Dodatkowo w momencie kiedy jeden programista
odejdzie z zespołu, dla każdego fragmentu kodu
znajdziemy inną osobę, która będzie znała ten fragment
Programowanie parami
• W XP nie ma osoby odpowiedzialnej za każdą
część kodu - kod jest własnością całego zespołu
• Nie da się wydajnie pracować parami, jeżeli nie
ma w firmie systemu zarządzania wersjami, np.
CVS
• Wymagana jest również otwarta przestrzeń pracy
dla zespołu - aby poszczególne osoby mogły się
łatwo komunikować
Czynniki ryzyka
• Założenie, że klient przez cały czas pracuje z zespołem
może się okazać nierealne - rzadko który klient może sobie
pozwolić na oddelegowanie jednego pracownika na kilka
miesięcy (gdyż tyle może trwać projekt)
• Brak dokumentacji z jednej strony powoduje
przyspieszenie projektu, lecz czasem może się okazać, że
po pewnym czasie trzeba wrócić do prac nad systemem
(np. dodać nową funkcjonalność); wtedy, bez
odpowiedniej dokumentacji, trudno przypomnieć sobie za
co poszczególne fragmenty kodu były odpowiedzialne
Czynniki ryzyka
• Niektórzy zarzucają również brak fazy
projektowania - twierdzą, że rozwiązania powstają
za bardzo ad hoc
• Krótka perspektywa planowania (planuje się tylko
kolejne wydanie) nie pozwala przewidzieć, kiedy
system będzie ukończony
Metodyka PRINCE2
• Projects in a Controlled Environment tzn. Projekty w
sterowanym środowisku
• 1989 - brytyjska agenda rządowa Central Computer and
Telecommunications Agency (CCTA) opublikowało
standard pod nową nazwą – PRINCE
• 1996 - PRINCE2 opublikowany jako ogólna metoda
zarządzania projektami niezależna od dziedziny
biznesowej zastosowania
• 2005 - ostatnie zmiany opublikowane przez Office for
Government Commerce (OGC) – następcę CCTA
Uruchamianie projektu
• Przygotowanie projektu do uruchomienia
• Ma zapewnić, że projekt będzie wart ponoszonych
kosztów i że da się go zrealizować
• Informacją wejściową dla procesu jest Zlecenie
Przygotowania Projektu (Project Mandate)
• W proces zaangażowane jest wyższe
kierownictwo organizacji, które ustanawia i
wybiera Komitet Sterujący (Project Board), który
nadzoruje projekt i wybiera Kierownika Projektu
Uruchamianie projektu
• Uzasadnienie projektu jest zarysowane w
Podstawowych Założeniach Projektu
• W zależności od specyfiki projektu wybierana jest
formuła realizacyjna
• Wykonany jest także plan etapu inicjowania
projektu.
Uruchamianie projektu
• PP1. Mianowanie Przewodniczącego Komitetu
Sterującego i Kierownika Projektu
• PP2. Projektowanie zespołu zarządzania projektem
• PP3. Mianowanie zespołu zarządzania projektem
• PP4. Przygotowanie podstawowych założeń projektu
• PP5. Definiowanie formuły realizacyjnej/Definiowanie
• PP6. Planowanie etapu inicjowania
Zarządzanie strategiczne projektem
• Realizuje funkcje, za które odpowiedzialny jest
Komitet Sterujący
• Kierownik Projektu informuje Komitet Sterujący
w raportach okresowych o stanie projektu
• Bieżące zarządzanie pozostawione jest w
wyłącznej kompetencji Kierownika Projektu
Zarządzanie strategiczne projektem
• Komitet Sterujący angażuje się tylko na granicach
etapów zarządczych, gdzie decyduje, czy należy
kontynuować prace przechodząc do następnego
etapu
• Fundamentalną zasadą PRINCE2 jest zarządzanie
poprzez wyjątki management by exception, co
oznacza, że Komitet Sterujący angażuje się w
podejmowanie decyzji projektowych jedynie, gdy
uzyska informacje, że projekt jest zagrożony
wyjściem poza zakres tolerancji
Planowanie
•
•
•
•
•
•
•
PL1. Projektowanie planu
PL2. Definiowanie i analizowanie produktów
PL3. Określanie działań i zależności
PL4. Szacowanie
PL5. Harmonogramowanie
PL6. Analizowanie ryzyka
PL7. Kompletowanie planu
Inicjowanie projektu
• IP1. Planowanie jakości
• IP2. Planowanie projektu
• IP3. Doprecyzowanie Uzasadnienia Biznesowego
i Ryzyka
• IP4. Ustanowienie elementów sterowania
• IP5. Ustanowienie dokumentacji projektowej
• IP6. Zestawienie Dokumentu Inicjującego Projekt
Sterowanie etapem
•
•
•
•
•
•
•
•
•
SE1. Zgoda na wykonanie grupy zadań
SE2. Ocena postępów
SE3. Rejestrowanie zagadnień projektowych
SE4. Analizowanie zagadnień projektowych
SE5. Przeglądanie stanu etapu
SE6. Raportowanie o ważnych zdarzeniach
SE7. Podejmowanie działań korekcyjnych
SE8. Eskalowanie zagadnień projektowych
SE9. Odbieranie wykonanych grupy zadań
Zarządzanie wytwarzaniem produktów
• PRINCE2 to metodyka oparta na produktach;
produktem może być rzecz materialna np. książka
• Może nim być też rzecz bardziej niematerialna np.
poziom usług serwisowych
• W zasadzie wszystko, co zostało wytworzone
przez projekt zgodny z PRINCE2, włączając w to
dokumenty jest produktem
• Produkt może być wytworzony przez
kogokolwiek, także przez zewnętrznego dostawcę.
Zarządzanie wytwarzaniem produktów
• WP1. Przyjęcie grupy zadań do realizacji
• WP2. Wytwarzanie grupy zadań
• WP3. Dostarczanie grupy zadań
Zarządzanie zakresem etapu
• Zgodnie z PRINCE2 każdy etap musi być
ukończony i zaakceptowany zanim Komitet
Sterujący autoryzuje przejście do następnego
etapu
• W tym procesie weryfikowane jest, czy etap
dostarczył wszystkie wymagane produkty i czy
pierwotne parametry biznesowe nie uległy
zmianie
• Planowany jest też w tym kontekście
uszczegółowiony plan następnego etapu
Zarządzanie zakresem etapu
• ZE1. Planowanie etapu
• ZE2. Uaktualnienia planu projektu
• ZE3. Uaktualnienie uzasadnienia biznesowego
projektu
• ZE4. Uaktualnienie rejestru ryzyka
• ZE5. Raportowanie końca etapu
• ZE6. Opracowanie planu naprawczego
Zamykanie projektu
• Według metodyki PRINCE2 projekty muszą być
zamykane w sposób uporządkowany i kontrolowany
• Wszystkie doświadczenia zdobyte w trakcie prowadzenia
projektu są rejestrowane, tworzony jest dokument
przekazania i planowany jest przegląd powdrożeniowy
• Po zakończeniu projektu w zaplanowanym momencie
pozwalającym na należytą ocenę skutków biznesowych
projektu przeprowadzany jest przegląd poprojektowy
Zamykanie projektu
• ZP1. Przygotowanie projektu do zamknięcia
• ZP2. Określanie działań następczych
• ZP3. Przegląd oceniający projekt
Komponenty
•
•
•
•
•
•
•
•
Uzasadnienie biznesowe
Organizacja
Plany
Elementy sterowania
Zarządzanie ryzykiem
Jakość w środowisku projektu
Zarządzanie konfiguracją
Sterowanie zmianam
Uzasadnienie biznesowe
• Przeznaczeniem Uzasadnienia Biznesowego jest
określenie mierzalnych celów uzasadniających
zaangażowanie zasobów w projekcie
• Uzasadnienie biznesowe musi być aktualizowane
przez cały cykl życia projektu
• Właścicielem uzasadnienia biznesowego jest
Przewodniczący Komitetu Sterującego
Organizacja
• Główne role w projekcie pełnią:
– Komitet Sterujący (Project Board)
• Przewodniczący Komitetu Sterującego (Executive)
• Główny Użytkownik (Senior User)
• Główny Dostawca (Senior Supplier)
–
–
–
–
Kierownik projektu (Project Manager)
Nadzór projektu (Project Assurance)
Kierownik Zespołu – rola opcjonalna (Team Manager)
Wsparcie Projektu – rola opcjonalna (Project Support)
Plany
• Plany zgodnie z PRINCE2 muszą być zatwierdzone zanim
zostaną przekazane do realizacji. Wyróżnia się 3 poziomy
planu:
• Plan projektu (Project Plans)
• Plan etapu (Stage Plans)
• Plan pracy zespołu (Team Plans)
• Ponadto czwartym typem planu jest plan naprawczy
(Exception plan), który zastępuje plan etapu w wypadku
pojawienia się zagrożenia istotnymi odchyleniami
przekraczającymi tolerancję
Elementy sterowania
• Elementy sterowania mają zapewnić, że projekt jest
prowadzony zgodnie z planem i uzasadnieniem
biznesowym
• PRINCE2 stosuje metodę zwaną 'management by
exception', która angażuje Komitet Sterujący tylko wtedy
kiedy pojawia się odchylenie wskazujące na możliwość
wykroczenia projektu poza ramy określone tolerancją i
uzasadnieniem biznesowym
• Cała odpowiedzialność za bieżące zarządzanie projektem
oraz podejmowanie decyzji zmierzających do realizacji
zadań projektowych zgodnie z planem spoczywa na
Kierowniku Projektu
Elementy sterowania
• Podstawowymi elementami sterowania są:
–
–
–
–
–
–
–
Inicjowanie projektu
Raporty o ważnych wydarzeniach
Raporty o istotnych odchyleniach
Ocena nadzwyczajna
Ocena końcowa etapu
Zamknięcie projektu
Tolerancja
Zarządzanie Ryzykiem
• Każdy projekt z uwagi na niepowtarzalność
parametrów realizacyjnych oraz zmiany w
otoczeniu biznesowym musi brać pod uwagę
możliwość wystąpienia zdarzeń nieplanowanych
mogących mieć istotny wpływ na sposób jego
realizacji
• Ryzyko to niepewność wyniku
• Zarządzanie ryzykiem polega na utrzymywaniu
ryzyka w akceptowalnych granicach w sposób
efektywny i racjonalny kosztowo
Zarządzanie Ryzykiem
• Zarządzanie ryzykiem opiera się na 3 zasadach:
– Tolerancji na ryzyko
– Odpowiedzialności za ryzyko
– Własności (przynależność) ryzyka
Jakość w środowisku projektowym
• Celem projektu jest wytworzenie produktów,
zgodnych z ich przeznaczeniem, zaspokajających
potrzeby oraz oczekiwania jakościowe klienta
• Oczekiwania jakościowe są określone w Zleceniu
Projektu (Project Mandate), Założeniach Projektu
(Project Brief) oraz Dokumencie Inicjującym
Projekt (Project Initiation Document)
Jakość w środowisku projektowym
• Zarządzanie jakością opiera się na 4 składnikach:
–
–
–
–
Systemie Zarządzania Jakością
Funkcji zapewniania jakości
Planowaniu jakości
Kontroli jakości
Zarządzanie konfiguracją
• Zarządzanie konfiguracją zajmuje się
kontrolowaniem wszystkich produktów projektu
• Konfiguracja to zbiór logicznie powiązanych
produktów, które muszą być traktowane i
zarządzane jako złożona całość uwzględniająca
zależności pomiędzy wersjami części składowych
i ich statusami
Zarządzanie konfiguracją
• Zarządzanie konfiguracją składa się z 5
elementów:
–
–
–
–
–
Planowanie
Identyfikacja
Kontrola
Charakteryzowanie statusu
Weryfikacja
Techniki projektowe
• Planowanie oparte na produktach
• Sterowanie zmianami
• Przeglądy jakości
Planowanie oparte na produktach
• PRINCE2 stosuje planowanie oparte na produktach nie zaś
oparte na działaniach
• Polega to na tym, że PRINCE2 planuje i mierzy postęp
projektu realizacją poszczególnych precyzyjnie
zdefiniowanych produktów a nie subiektywnie mierzonych
działań
• Planowanie oparte na produktach stosuje następujące
produkty:
– Struktura produktowa
– Opisy produktów
– Diagram następstwa produktów
Sterowanie zmianami
• W PRINCE2 wszystkie zmiany są traktowane jako
zagadnienia projektowe:
– wnioski o zmianę – dotyczące zmiany w wymaganiach
albo produkcie
– odstępstwo – rejestrowane kiedy produkt nie spełnia
wymagań.
– sugestie
– zapytania
– zagadnienia ogólne
Sterowanie zmianami
• Obsługa wszystkich zagadnień projektowych jest w gestii Kierownika
Projektu
• Ich zgłoszenia muszą być udokumentowane w Rejestrze zagadnień
(Issue Log)
• Wnioski o zmianę muszą być zaakceptowane przez Komitet Sterujący
lub Komitet ds. zmian (Change Authority)
• Przed akceptacją zmiany musi być wykonana analiza wpływu zmiany
• Odstępstwa (Off specification) mogą być załatwiane w ramach działań
korygujących przez Kierownika Projektu o ile nie wykraczają one
poza określone dla projektu granice tolerancji
• Komitet Sterujący może zaakceptować odstępstwa bez uruchamiania
działań korygujących definiując je jako ustępstwo
Przeglądy jakości
• PRINCE2 wymaga aby produkty podlegały
przeglądowi jakości
• Zadaniem przeglądów jakości jest określenie czy
produkt spełnia kryteria jakości określone w
Opisie Produktu tzn. czy nie zawiera błędów,
braków lub innych niezgodności.
Mocne strony PRINCE2
• Stosowanie tej metodyki zapewnia wysoką standaryzację i
powtarzalność projektów o wspólnym podejściu,
terminologii i dokumentacji co zapewnia możliwość
doskonalenia kompetencji
• Metodyka w sposób racjonalny opiera się na najlepszych
praktykach w zarządzaniu projektami
• Wprowadza management by exception jako podstawową
zasadę, która zapewnia Kierownikowi Projektów swobodę
działania bez zbędnej ingerencji, zapewniając jednocześnie
zaangażowanie wyższego kierownictwa, wtedy kiedy
projekt jest zagrożony wykroczeniem poza granice
tolerancji lub przestaje realizować uzasadnienie biznesowe
Mocne strony PRINCE2
• Sprawuje kontrolę nad startem, realizacją i końcem
projektu
• Każdy z dokumentów wymaganych przez PRINCE2 jest
dostarczony jako szablon zawierający wymagane metrykę,
rozdziały i pola informacyjne co zapewnia przejrzystość,
standaryzację i kompletność dokumentacji
• Przewiduje możliwość adaptacji do specjalnych potrzeb
organizacji, programu lub projektu
• Jej stosowanie nie wymaga opłat autorskich
• Materiały PRINCE2 są opublikowane i szeroko dostępne
co ogranicza prace nad wypracowywaniem własnych
standardów i przygotowaniem materiałów szkoleniowych
Słabości PRINCE2
• Dużo organizacji cierpi na syndrom PINO (Prince In Name
Only tzn. PRINCE2 tylko z nazwy), wybierając bez
głębszej analizy tylko niektóre składniki metodyki nie
zwracając uwagi na podstawowe zasady
• PRINCE2 kładzie duży nacisk na dokumentowanie jako
narzędzie sprawnej kontroli sposobu realizacji projektu
• W niektórych organizacjach dokumenty stają się jednak
celem samym w sobie, a rzeczywiste projekty kończą się
niepowodzeniem
Słabości PRINCE2
• Podobnie uwaga jaką zwraca PRINCE2 na potrzebę dobrej
organizacji i regularną wymianę informacji pomiędzy
zainteresowanymi odbierana jest niesłusznie jako zachęta
do ciągłych bezproduktywnych spotkań zabierających czas
niezbędny na rzeczywistą pracę
• PRINCE2 nie definiuje wprost analizy wymagań tak więc
może prowadzić do niepowodzenia projektu z uwagi na
przyjęcie fałszywych założeń (z drugiej strony jasno jest
określone, kto ponosi odpowiedzialność za przyjęcie złych
założeń i akceptację nietrafnego uzasadnienia biznesowego
a przesłanki tych decyzji są udokumentowane i mogą
stanowić nauczkę na przyszłość)
Słabości PRINCE2
• Zbyt ścisłe przestrzeganie PRINCE2 bez
odpowiedniej adaptacji do realiów biznesowych
może być zbyt pracochłonne w zastosowaniu do
małych projektów
• Niezbyt "zwinna"
XPrince
• Koncepcja metodyki XPrince została zaproponowana
przez Jerzego Nawrockiego z Instytutu Informatyki
Politechniki Poznańskiej i jest rozwijana przez zespół
Inżynierii Oprogramowania
• Pod koniec 2004 roku do tego projektu akademickiego
przyłączyła się grupa firm wytwarzających
oprogramowanie i zostało powołane Konsorcjum XPrince,
które przejęło patronat nad rozwijaniem i promowaniem
metodyki XPrince
• Aktualnie metodyka XPrince jest wdrażana w
przedsiębiorstwach będących członkami konsorcjum
Źródło
• Równowaga między zwinnością a dyscypliną z
wykorzystaniem XPrince
• Łukasz Olek we współpracy z Jerzym
Nawrockim, Michałem Jasińskim, Bartoszem
Paliświatem, Bartoszem Walterem, Błażejem
Pietrzakiem i Piotrem Godkiem
• Politechnika Poznańska, Instytut Informatyki
ul. Piotrowo 3A, 60-965 Poznań
Założenia
• Jak zauważyli Barry Boehm i Richard Turner: każde
pomyślne przedsięwzięcie w zmieniającym się świecie
wymaga zarówno zwinności jak i dyscypliny
• XPrince (eXtreme PRogramming IN Controlled
Environments) bazuje na trzech innych metodykach: XP,
PRINCE2 oraz RUP i jest zintegrowaną i elastyczną
metodologię wytwarzania oprogramowania wraz z
towarzyszącymi narzędziami, której celem jest wyważenie
między zwinnością i dyscypliną
Założenia
• W tym celu zintegrowano metodykę zarządzania
projektem (PRINCE2) z metodyką wytwarzania
oprogramowania (XP) oraz stworzono narzędzia, które
pomagają efektywnie zintegrować różne techniki
wytwarzania oprogramowania
• Narzędzie UC Workbench jest zintegrowanym edytorem
wymagań w postaci przypadków użycia z generatorem
makiet funkcjonalnych oraz kalkulatorem pracochłonności
• Zintegrowano również ponowne użycieoprogramowania
(reuse) z testowaniem (przypadki testowe są
wykorzystywane jako specyfikacja wyszukiwanych
komponentów oprogramowania).
Porównanie struktur organizacyjnych
Cykle życia
Rozpoczęcie projektu
• Jest zazwyczaj wykonywane przez Menadżera
Projektu, który ma następujące zadania:
– ustanowić zespół zarządzania projektem
– stworzyć wizję systemu (jest to krótsza i bardziej
konkretna wersja dokumentów Szkic projektu i
Podejście do projektu z XPRINCE, zawiera on wstępne
argumenty biznesowe)
– zaplanować fazę Inicjacji projektu
Inicjacja projektu
• Celem inicjacji jest dostarczenie planu i
stworzenie środowiska organizacyjnego dla
projektu
• Jest to połączenie Inicjacji projektu z PRINCE2
oraz fazy Rozpoczęcia z RUP
• Zadania tej fazy wykonują głównie Kierownik
projektu i Analityk z pomocą Architekta
Inicjacja projektu
• Zrozumieć, co należy zbudować
– niekiedy konieczne jest stworzenie lekkiej wersji
dokumentu ConOps, zawierającego model biznesowy
bazujący na przypadkach użycia, listę problemów,
które należy rozwiązać oraz najważniejszą
funkcjonalność wymaganą do rozwiązania tych
problemów
– kluczowej funkcjonalności powinna towarzyszyć lista
kryteriów jakości i produktów
– osobą odpowiedzialną za to zadanie jest Analityk, który
powinien również śledzić ryzyko z tym związane.
Inicjacja projektu
• Zaproponowanie początkowej architektury
– powinien to być krótki, wysokopoziomowy opis,
dostarczający informacji potrzebnej do zaplanowania
projektu
– powinien również zawierać listę potrzebnych narzędzi
– osobą odpowiedzialną za to zadanie, wraz z czynnikami
ryzyka z nim związanymi jest Architekt, lecz w
przypadku gdy architektura rozwiązania wydaje się być
oczywista, również Analityk może wykonać to zadanie
Inicjacja projektu
• Zaplanowanie całego projektu i dopracowanie
uzasadnienia biznesowego (ang. business case)
– ten cel jest nadzorowany przez Menadżera Projektu, który jest
również odpowiedzialny za śledzenie ryzyka z tym związanego
– plan projektu pokazuje projekt ze strategicznego punktu widzenia
– w celu wspierania „zwinności” plan projektu powinien być
zbudowany zgodnie z zasadą „rzeczy najważniejsze najpierw”
– powinien precyzować liczbę wydań i przydzielić do nich
funkcjonalność (przypadki użycia na wysokim poziomie). Im
dłuższy projekt, tym plan projektu powinien być mniej konkretny
– faktyczne planowanie powinno się odbywać na poziomie wydań
Inicjacja projektu
• Zaplanowanie całego projektu i dopracowanie
uzasadnienia biznesowego (ang. business case)
– w XP nie istnieje plan projektu – są jedynie plany wydań
– w XPrince plan projektu został dodany nie tylko ze względu na
zgodność z PRINCE2, lecz również aby zapewnić szerszą
perspektywę, która okazuje się bardzo potrzebna
– należy zrozumieć, iż plan projektu jest źródłem cennej informacji,
nie zaś usprawiedliwieniem odrzucania propozycji zmian
– każda późniejsza propozycja zmiany powinna być zaakceptowana,
jeżeli pomaga osiągnąć cele biznesowe
Inicjacja projektu
• Ustalenie kanałów komunikacyjnych i
środowiska zarządzania projektem
– kanały komunikacyjne obejmują raporty (np. wyniki
cotygodniowych testów akceptacyjnych, sugerowanych
przez XP)
– środowisko zarządzania projektem może być klasyczne,
bazujące na plikach i dokumentach, lub może być
wspomagane zaawansowanymi narzędziami
– ten cel leży w obowiązkach Menadżera Projektu.
• Plan fazy elaboracji
Faza Elaboracji
• Faza Elaboracji dotyczy głównie architektury. Architekt
powinien zaproponować mechanizmy architektoniczne,
rozpoznać ryzyko z tym związane (np. za pomocą
eksperymentów) oraz stworzyć szkielet, który będzie
wykorzystywany przez Programistów
• Analityk i Menadżer Projektu w tej fazie udoskonalają
wymagania i plan projektu
• Każde Wydanie składa się z kilku przyrostów, po których
następuje faza tranzycji
• Na tym etapie proces wytwarzania oprogramowania
bardzo przypomina XP
• Architekt i Programiści produkują kod i przypadki testowe
Faza Elaboracji
• Analityk jest odpowiedzialny za wymagania i testy
akceptacyjne, jak również gra rolę klienta będącego na
miejscu
• Przyrost jest jedynie wewnętrznym punktem kontrolnym
• Każde Wydanie jest zakończone fazą tranzycji, w której
nowa wersja systemu jest
• wdrażana i przekazywana użytkownikom końcowym
• Podobnie jak w XP, każdy przyrost powinien być tak samo
długi – to pomaga Programistom czuć rytm iteracji oraz w
rezultacie nauczyć się lepiej planować przyrosty
Zamknięcie projektu
• Zamknięcie projektu bardzo przypomina
odpowiadającą fazę z PRINCE2
• Projekt jest zamykany, identyfikowane są dalsze
akcje i następuje ocena projektu.
Narzędzia PRINCE2
• UC Workbench to narzędzie wspomagające
zarządzanie wymaganiami i modelowanie
dziedziny biznesowej bazujące na przypadkach
użycia, rozwijane na Politechnice Poznańskiej
Programowanie
• Programowanie parami jest kluczową praktyką w XP
• Para programistów wyposażona w jeden komputer jest
przydzielana do zadania programistycznego
• Jeden z programistów pisze kod, natomiast drugi śledzi
jego pracę, zadaje pytania i proponuje przypadki testowe,
tak więc zapewnia to tzw. ciągły przegląd
• Inne podejście do programowania zespołowego to
programowanie Side-by-Side (SbS), które zostało
zaproponowane przez Cockburn’a
Programowanie
• W tym podejściu pojedyncze zadanie jest rozwiązywane
przez dwóch programistów, lecz każdy z nich posiada
osobny komputer
• Wyniki badań eksperymentalnych dotyczących wydajności
programowania parami oscylują pomiędzy
optymistycznymi (przyspieszenie rzędu 40% czasu i narzut
20% pracochłonności przy porównaniu z programowaniem
indywidualnym, a całkiem pesymistycznymi
(przyspieszenie rzędu 20%, narzut 60% )
• Niestety, nie ma opublikowanych żadnych aktualnych
wyników eksperymentów dotyczących szybkości
programowania SbS