zarządzanie projektem systemu informatycznego

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

Weryfikacjaprzez klienta

Pełne określenie wymagań

Realizacja pełnego systemu

tak

nie

Programowanie odkrywcze

Ogólne określenie wymagań

Budowa systemu

Systemdziała

poprawnie

Przetestuj system

Dostarcz system

taknie

Realizacja przyrostowa

Określenie wymagań

Projekt ogólny

Wybór podzbioru funkcji

Dostarczenie zrealizowanej

części systemu

Projekt szczegółowy,

implementacja i testy

Proces realizowanyiteracyjnie

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ślaniewymagań

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


• 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 (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


• 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.)


• 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)


• 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”


• 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


• 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 zmianyjego 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

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


• 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


• 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


• 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.


• 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

zarządzanie projektem systemu informatycznego

Documents