Plan zarządzania projektem



Podobne dokumenty
OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA

Biuro projektu: ul. Kościuszki 4/6a, Rzeszów, tel.: ,

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Zasady organizacji projektów informatycznych

Zarządzanie Projektami zgodnie z PRINCE2

Wstęp do zarządzania projektami

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Projektowanie systemów informatycznych. wykład 6

Instrukcja budowy Harmonogramu Bazowego, Harmonogramu Operacyjnego i Harmonogramu Zamawiającego. opracowanie własne AQUANET S.A.

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Usługa: Testowanie wydajności oprogramowania

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

Etapy życia oprogramowania

Wstęp do zarządzania projektami

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK

PRINCE2. Metodyka zarządzania projektami. Na podstawie prezentacji R. Radzik, J. Binkiewicz, K. Kasprzak

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Certified IT Manager Training (CITM ) Dni: 3. Opis:

Testowanie i walidacja oprogramowania

PODSTAWY ZARZĄDZANIA PROJEKTAMI

Wstęp do zarządzania projektami

Zarządzanie projektem prawnym w praktyce

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Zastosowania informatyki w gospodarce Projekt

PROJEKT ZARZĄDZANIE PROJEKT. Przedsięwzięcie powtarzalne, kilkurazowe = PROCES

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2

Zarządzanie projektem prawnym w praktyce

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Szkolenie 1. Zarządzanie projektami

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.

Praktyczne zarządzanie projektami według metodyki PRINCE2

ŚCIEŻKA: Zarządzanie projektami

KIERUNKOWE EFEKTY KSZTAŁCENIA KIERUNEK STUDIÓW INFORMATYCZNE TECHNIKI ZARZĄDZANIA

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC oraz BS doświadczenia audytora

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013

Zarządzanie projektami. Wydanie II.

Dokument Detaliczny Projektu

Metodyki zarządzania projektami PRINCE2

Dokument Detaliczny Projektu

Część I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

Pytania z przedmiotów kierunkowych

ECDL ZARZĄDZANIE PROJEKTAMI

Zarządzenie nr 94. Platforma Analiz i Archiwizacji Danych (PAAD)

Skuteczne zarządzanie projektami IT w otoczeniu uczelnianym. Piotr Ogonowski

2.11. Monitorowanie i przegląd ryzyka Kluczowe role w procesie zarządzania ryzykiem

Zapewnij sukces swym projektom

PRINCE2 Foundation & Practitioner - szkolenie z egzaminem certyfikacyjnym

Program kształcenia i plan studiów podyplomowych: Zarządzanie projektami

Zarządzanie projektami a zarządzanie ryzykiem

Spis treści Wstęp 1. Wprowadzenie 2. Zarządzanie ryzykiem systemów informacyjnych

Właściwe środowisko wewnętrzne w sposób zasadniczy wpływa na jakość kontroli zarządczej.

Wprowadzenie do narzędzi zarządzania projektami informatycznymi.

Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny) kierunkowy (podstawowy / kierunkowy / inny HES)

Spis treści. Lekcja 1: Podstawy projektu 1. Lekcja 2: Określanie zasobów 28. Umiejętności do zdobycia w tej lekcji 28

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

MS Project 2010 w harmonogramowaniu - planowanie zadań, działań, operacji i przedsięwzięć

Inżynieria Programowania Zarządzanie projektem

Strategia testów mająca doprowadzić do osiągnięcia pożądanych celów

Małopolska Agencja Rozwoju Regionalnego S.A.

Plan zarządzania projektem

SKUTECZNE ZARZĄDZANIE PROJEKTEM

Załącznik nr 2 do Umowy nr... z dnia... Zawartość Planu Jakości Projektu i wymagania w zakresie jego aktualizacji

STUDIA PODYPLOMOWE ZARZĄDZANIE PROJEKTAMI INFORMATYCZNYMI

Głównym zadaniem tej fazy procesu zarządzania jest oszacowanie wielkości prawdopodobieństwa i skutków zaistnienia zidentyfikowanych uprzednio ryzyk.

Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, Warszawa tel: , faks:

Metodyka Sure Step. Agenda:

E-1IZ s2. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)

Zarządzanie projektami zadaniowymi w oparciu o metodykę PMI

Zarządzanie projektami. Porównanie podstawowych metodyk

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

I. Analiza ryzyka Bancassurance ocena zakładu ubezpieczeń

Egzamin / zaliczenie na ocenę*

PRINCE2 Foundation - szkolenie z egzaminem certyfikacyjnym

Walidacja elementów systemów sterowania związanych z bezpieczeństwem jako krok do zapewnienia bezpieczeństwa użytkowania maszyn

II. DZIAŁANIA I DOKUMENTY

Łódź, dnia r. Wykonawcy uczestniczący w postępowaniu o udzielenie zamówienia publicznego

PODYPLOMOWE STUDIA ZARZĄDZANIA PROJEKTAMI KATOWICE

Usługa: Audyt kodu źródłowego

Spis treści. Konwencja zapisu przyjęta w niniejszym podręczniku

PODYPLOMOWE STUDIA ZARZĄDZANIA PROJEKTAMI KATOWICE

Feature Driven Development

ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0

Kod doskonały : jak tworzyć oprogramowanie pozbawione błędów / Steve McConnell. Gliwice, cop Spis treści. Wstęp 15.

Procedura Odbioru. 1. Niniejsza Procedura odbioru obejmuje:

Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji.

Zarządzanie projektami - narzędzia, software, dokumentacja, metodyka PMBOK

"Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny".

Procedury ustalania kompetencji w projekcie EDGE wzór do celów badań w zakładach

Łódź, dnia r. Wykonawcy uczestniczący w postępowaniu o udzielenie zamówienia publicznego

Koordynacja projektów inwestycyjnych

Zarządzanie ryzykiem teoria i praktyka. Ewa Szczepańska Centrum Projektów Informatycznych Warszawa, dnia 31 stycznia 2012 r.

KARTA MODUŁU KSZTAŁCENIA

Standard ISO 9001:2015

Transkrypt:

Plan zarządzania projektem Opracował: Zatwierdził: Podpis: Podpis: Spis treści: 1. Wst p... 2 1.1 Cel... 2 1.2 Zakres... 2 1.3 Przeznaczenie dokumentu... 2 1.4 Organizacja dokumentu... 2 1.5 Dokumenty powi zane... 3 2. Definicje... 3 3. Zarys projektu... 3 4. Produkty projektu... 3 5. Model procesu projektowego... 4 6. Organizacja projektu... 4 6.1 Struktura organizacyjna... 4 6.2 Granice organizacyjne i interfejsy... 4 6.3 Podział odpowiedzialno ci... 4 7. Zarz dzanie... 5 7.1 Cele i priorytety zarz dzania... 5 7.2 Zało enia, uwarunkowania i ograniczenia... 5 7.3 Zarz dzanie ryzykiem... 5 7.4 Mechanizmy ledzenia i kontroli... 5 7.5 Plan zatrudnienia... 6 8. Proces techniczny... 6 8.1 Metody, narz dzia i techniki... 6 8.2 Dokumentacja oprogramowania... 6 8.3 Funkcje wspomagaj ce projekt... 6 9. Etapy pracy, harmonogram i bud et... 6 9.1 Podział projektu na etapy i zadania... 7 9.2 Wymagania zasobów... 7 9.3 Bud et i rozdział zasobów... 7 9.4 Harmonogram... 8 10. Ewolucja planu projektu... 8 11. Bibliografia... 8

1. Wstęp 1.1 Cel Plan Projektu jest dokumentem kontrolnym dla zarządzania projektem informatycznym. Definiuje organizację oraz procesy techniczne i zarządzania niezbędne do spełnienia założeń projektu. Format i treść Planu Projektu informatycznego można zastosować do wszystkich typów projektów informatycznych niezależnie od wielkości, stopnia złożoności lub krytyczności produktu informatycznego. Można zastosować w każdym etapie cyklu życia produktu informatycznego. Opis Planu Projektu jest integralną częścią procedur zarządzania projektem IT. Plan Projektu informatycznego jest podstawą dla działu zapewnienia jakości do planowania przeglądów, testów i innych działań w zakresie zapewnienia jakości projektu. 1.2 Zakres Plan Projektu opisuje ogólne cele i potrzeby biznesowe, produkty projektu organizację i sposób zarządzania. Obejmuje wyszczególnienie głównych prac i etapów projektu oraz określenie zasobów wymaganych na jego realizację. Przedstawia ogólny harmonogram i budżet. Plan projektu uwzględnia i opisuje relacje projektu do innych powiązanych projektów i działań firmy. 1.3 Przeznaczenie dokumentu Plan projektu jest przeznaczony dla wszystkich osób biorących udział w projekcie. Jest przygotowywany i uaktualniany przez Kierownika Projektu, dla którego może stanowić narzędzie planowego przeprowadzenia projektu. Dla osób pełniących role zarządzające w projekcie stanowi podstawę oceny zgodności przebiegu projektu z założeniami i rozliczenia wykonawców poszczególnych zadań. Dla osób pełniących role wykonawcze stanowi źródło informacji o zadaniach do wykonania, terminach i stanowi postawę rozliczenia pracy. 1.4 Organizacja dokumentu Rozdziały tego dokumentu odnoszą się do następujących zagadnień: Rozdział 2 definiuje terminy stosowane w tym dokumencie Rozdział 3 określa zakres i ogólne informacje o projekcie Rozdział 4 podaje jak wybrać i opisać produkty projektu Rozdział 5 zawiera sposób opisu procesu projektowego Rozdział 6 podaje opis organizacji projektu Rozdział 7 opisuje elementy zarządzania projektem Rozdział 8 zawiera bibliografię.

1.5 Dokumenty powiązane Opisy pozostałych dokumentów tworzonych w projektach software owych to: Opis planu zapewnienia jakości Opis specyfikacji wymagań użytkownika Opis projektu wstępnego Opis projektu szczegółowego Opis dokumentacji technicznej Opis dokumentacji użytkownika Opis planu testów Opis wyników testów Opis raportów z przeglądów 2. Definicje cykl życia oprogramowania - Okres czasu, który rozpoczyna się, gdy powstaje wyobrażenie oprogramowania a kończy się gdy nie ma więcej możliwości jego użytkowania. Cykl życia oprogramowania obejmuje zazwyczaj fazy koncepcyjną, analizy wymagań, realizacji, testowania, instalowania i sprawdzania, działania i konserwacji oraz czasami fazę wycofania. plan projektu - Dokument, który opisuje podejście techniczne i w zakresie zarządzania, jakie ma być zastosowane w projekcie. Plan opisuje zazwyczaj prace do wykonania, wymagane zasoby, zastosowane metody, procedury, jakie mają być przestrzegane, terminy, jakie mają być dotrzymane i sposób, w jaki projekt będzie zorganizowany. produkt informatyczny - Kompletny zestaw programów komputerowych, procedur i ewentualnie powiązanych dokumentów i danych przeznaczonych do dostarczenia użytkownikowi. produkt projektu - produkt, jaki ma być dostarczony zleceniodawcy. 3. Zarys projektu Zwięzłe streszczenie celów projektu i krótki opis tworzonego produktu. Powinny się tu znaleźć najważniejsze informacje o projekcie dotyczące zakresu, zamierzonych wyników, oszacowania budżetu i wymaganych zasobów. 4. Produkty projektu Wymienić i opisać wszystkie produkty (systemy, instalacje, dokumentacja itp.), jakie mają zostać dostarczone w wyniku realizacji projektu. Opis produktu powinien zawierać nazwę produktu, określenie,

datę dostawy, miejsce dostawy oraz wymaganą wielkość. W opisie produktów należy uwzględnić wszystkie produkty końcowe, tzn. te, które będą podlegały formalnemu odbiorowi. 5. Model procesu projektowego Zidentyfikować i opisać główne funkcje, które będą wykonywane w ramach projektu z uwzględnieniem działań w zakresie rozpoczęcia i zakończenia projektu. Funkcje mogą mieć charakter czasowy (być wykonywane jednorazowo przez jakiś czas w projekcie np. Rozpoczęcie projektu), mogą być wielokrotne (wykonywane wielokrotnie w czasie trwania projektu np. Odbiór produktu jeśli projekt zakłada wykonanie wielu produktów w pewnych odstępach czasowych) lub ciągłe (wykonywane ciągle w czasie trwania projektu np. Zarządzanie) Definiuje się tu również zależności pomiędzy głównymi funkcjami projektu poprzez określenie synchronizacji, zasad tworzenia wersji produktów, przeglądów produktów, oraz warunków zakończenia projektu. Model procesu może zostać opisany przy użyciu zapisu graficznego i tekstowego. 6. Organizacja projektu 6.1 Struktura organizacyjna Opisać strukturę organizacyjną dla zarządzania projektem. Do przedstawienia struktur zarządzania, odpowiedzialności i komunikacji w ramach projektu można użyć narzędzi graficznych lub tabel np. diagramów do przedstawienia hierarchii organizacji. 6.2 Granice organizacyjne i interfejsy Jest tu opisane otoczenie projektu tzn. granice administracyjne i zarządzania pomiędzy strukturą projektu a: organizacją nadrzędną organizacją zleceniodawcy organizacjami podwykonawczymi innymi podmiotami organizacyjnymi mającymi związki z projektem. Należy uwzględnić interfejsy administracyjne i zarządzania w zakresie funkcji wspierających projekt, takich jak zarządzanie konfiguracją, zapewnienie jakości oraz weryfikacja i sprawdzanie. 6.3 Podział odpowiedzialności Identyfikuje się tu i określa charakter poszczególnych głównych funkcji i działań w ramach projektu oraz podaje osoby odpowiedzialne za ich realizację. Dla przedstawienia obowiązków w ramach projektu można zastosować tablicę funkcji i działań, na której

zaznaczone zostaną osoby odpowiedzialne. 7. Zarządzanie 7.1 Cele i priorytety zarządzania Przedstawić filozofię, cele i priorytety działań zarządzania w czasie projektu. Określić jakie czynniki będą miały decydujący wpływ na podejmowane decyzje. Mogą one dotyczyć: częstotliwości i mechanizmów zastosowanej sprawozdawczości, względnych priorytetów wymagań, harmonogramu budżetu dla projektu realizacji procedur zarządzania ryzykiem zamiaru nabycia, modyfikowania lub używania istniejącego oprogramowania. 7.2 Założenia, uwarunkowania i ograniczenia Jeśli są jakieś uwarunkowania zewnętrzne lub ograniczenia dla projektu, to należy je tu podać. Mogą one dotyczyć: zewnętrznych wydarzeń, na których opiera się projekt (np. uchwalenie jakiejś ustawy) przyjętych w firmie standardów i procedur gdy projekt jest realizowany wewnątrz firmy Rozdział ten określa założenia, na których opiera się ten projekt, zewnętrzne wydarzenia, od których projekt zależy oraz ograniczenia, przy których projekt ma zostać przeprowadzony. 7.3 Zarządzanie ryzykiem Określić i ocenić czynniki ryzyka związane z projektem. Opisać mechanizmy śledzenia różnych czynników ryzyka i plany postępowania w przypadku wystąpienia czynnika. Czynniki ryzyka, jakie należy uwzględnić, to między innymi: ryzyka związane z wykonaniem umowy ryzyka technologiczne ryzyka związane z wielkością i stopniem skomplikowania produktu ryzyka związane z pozyskiwaniem i utrzymaniem personelu ryzyka związane z uzyskiwaniem akceptacji zleceniodawcy dla produktu. 7.4 Mechanizmy śledzenia i kontroli Opisać w jaki sposób będzie kontrolowana zgodność realizacji projektu z planem i jakie zostaną zastosowane mechanizmy sprawozdawczości. Podać formaty raportów (np. w formie załączników) oraz

określić przepływy informacji pomiędzy elementami struktury organizacyjnej. Jeśli inne narzędzia i techniki będą stosowane do śledzenia i kontrolowania zgodności z planem projektu należy je tu opisać. 7.5 Plan zatrudnienia Podać liczbę i rodzaj personelu wymaganego do realizacji projektu. Przy wyborze personelu należy uwzględnić plan dokumentowania oprogramowania, oraz plany funkcji wspomagających projekt takich jak zapewnienie jakości, zarządzanie konfiguracją, weryfikacja i sprawdzanie. 8. Proces techniczny 8.1 Metody, narzędzia i techniki Opisać metodologię opracowywania systemu(ów) komputerowego(ych), strukturę(y) zespołu(ów), język(i) programowania i inne pojęcia, narzędzia, techniki i metody, jakie są stosowane do opisywania, projektowania, budowania, testowania, integrowania, dokumentowania, dostarczania, modyfikowania lub konserwacji produktów projektu. Uwzględnić bezpośrednio lub w formie odniesień do innych dokumentów standardy techniczne, strategie i procedury regulujące opracowywanie lub modyfikacje produktów projektu. 8.2 Dokumentacja oprogramowania Podać bezpośrednio albo w postaci odniesień, plan dokumentowania projektu. Określić wymaganą dokumentację według etapów projektu, zasady tworzenia wersji, przeglądy i warunki zakończenia prac nad dokumentacją oprogramowania. Określić w harmonogramie zadania oraz zasoby dla wykonania dokumentacji. Plan dokumentowania projektu może zawierać wytyczne odnośnie stylu, konwencje nazewnictwa i formaty dokumentów. 8.3 Funkcje wspomagające projekt Podać bezpośrednio lub w postaci odniesień, opis funkcji wspomagających projekt informatyczny. Funkcje te mogą dotyczyć np.: zarządzania konfiguracją zapewnienia jakości oprogramowania weryfikacji i sprawdzania. Plany funkcji wspomagania projektu należy opracować do poziomu zgodności szczegółów z innymi rozdziałami planu projektu. W szczególności, należy tu określić zadania, wymagania zasobów, harmonogram i budżet dla każdej funkcji wspomagającej. 9. Etapy pracy, harmonogram i budżet

9.1 Podział projektu na etapy i zadania Określić podział projektu na etapy. W ramach etapów, w miarę możliwości określić bardziej szczegółowy podział prac. Każdy etap i element podziału prac powinien być jednoznacznie oznaczony i opisany. Oznaczenie może się opierać na schemacie numerycznym i tytułach opisowych. Dla przedstawienia relacji hierarchicznych podziału projektu można zastosować wykres przedstawiający podział działań na poddziałania i zadania (struktura podziału pracy). Oszacować pracochłonność poszczególnych działań przy wybranym podejściu. Uwzględnić: - zarządzanie projektem i poszczególnymi etapami - zadania kontroli projektu. Określić relacje porządkujące pomiędzy etapami pracy i podanymi działaniami. Dla przedstawienia zależności pomiędzy etapami pracy i działaniami można zastosować listy zależności (ang.dependency lists), sieci działań (ang. activity networks) lub metody ścieżek krytycznych (ang. critical path method). 9.2 Wymagania zasobów Przedstawić, w funkcji czasu dane szacunkowe całkowitych zasobów wymaganych do realizacji projektu. Typowe zasoby jakie powinny zostać uwzględnione obejmują: liczbę i rodzaj personelu, czas komputerowy, oprogramowanie wspierające, sprzęt komputerowy, urządzenia biurowe i laboratoryjne, podróże i wymagania w zakresie konserwacji. 9.3 Budżet i rozdział zasobów Określić przydział budżetu i zasobów do realizacji różnych etapów, funkcji i działań projektu. Uwzględnić koszty: - ludzkich zasobów - sprzętu i urządzeń - utrzymania zespołu - szkolenia zespołu - wydatków na końcowy produkt - szkolenia użytkowników produktu. Dla przydziału budżetu i zasobów oraz dla oszacowania wydatków i wykorzystania zasobów można użyć schematu uzyskanych wartości (ang. earned value scheme - por. propozycje schematów MS-Project).

9.4 Harmonogram Przedstawić harmonogram projektu z uwzględnieniem funkcji, działań i zadań. Należy zaznaczyć relacje następstwa oraz daty rozpoczęcia i zakończenia poszczególnych etapów i prac. Poziom szczegółowości harmonogramu jest zależny od określenia projektu. W Planie Projektu zwykle wystarczy kompletny harmonogram na poziomie etapów. Jedynie dla pierwszego etapu projektu należy przygotować harmonogram na poziomie zadań z przydziałem zasobów dokładnym i określeniem czasochłonności. Harmonogramy mogą być wyrażane według kalendarza lub w postaci przyrostów w stosunku do wyróżnionych punktów (ang. milestones) projektu. 10. Ewolucja planu projektu Podać sposób przeprowadzenia zarówno zaplanowanych jak i niezaplanowanych uaktualnień planu projektu. Należy uwzględnić metody rozpowszechniania aktualnych wersji. Są tu określone mechanizmy zapoczątkowania kontroli zmiany pierwszej wersji planu projektu oraz kontrolowania kolejnych zmian planu. 11. Bibliografia IEEE Std 1058.1-1987 (Reaff 1993), Standard IEEE dla planów zarządzania projektami oprogramowania (ANSI)