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 tak Weryfikacja przez klienta tak nie Pełne określenie wymagań Realizacja pełnego systemu

Programowanie odkrywcze Ogólne określenie wymagań Budowa systemu Przetestuj system System działa poprawnie tak nie 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 Analiza ryzyka Atestowanie Konstrukcja (model kaskadowy)

Formalne transformacje Formalna specyfikacja wymagań Postać pośrednia ... Postać pośrednia Kod

Model ogólny cyklu życia Określanie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza 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 użytkownika działający system

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