plan zarz 5, plan zarządzania


Wersja: P

0x08 graphic
Tytuł:

Data wydania:

____.__.__

Strona / stron

/

Opracował:

Podpis:

Zatwierdził:

Podpis:

Spis treści:

1. Wstęp

  1. Wstęp

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

  1. Definicje

cykl życia oprogramowania - Okres czasu, który rozpoczyna się, gdy powstaje wyobrażenie oprogramowaniakończy się gdy nie ma więcej możliwości jego użytkowania. Cykl życia oprogramowania obejmuje zazwyczaj fazy koncepcyjną, analizy wymagań, realizacji, testowania, instalowaniasprawdzania, działaniakonserwacji oraz czasami fazę wycofania.

plan projektu - Dokument, który opisuje podejście techniczne i w zakresie zarządzania, jakie ma być zastosowaneprojekcie. Plan opisuje zazwyczaj prace do wykonania, wymagane zasoby, zastosowane metody, procedury, jakie mają być przestrzegane, terminy, jakie mają być dotrzymanesposób,jaki projekt będzie zorganizowany.

produkt informatyczny - Kompletny zestaw programów komputerowych, procedurewentualnie powiązanych dokumentówdanych przeznaczonych do dostarczenia użytkownikowi.

produkt projektu - produkt, jaki ma być dostarczony zleceniodawcy.

  1. Zarys projektu

Zwięzłe streszczenie celów projektukrótki opis tworzonego produktu. Powinny się tu znaleźć najważniejsze informacjeprojekcie dotyczące zakresu, zamierzonych wyników, oszacowania budżetuwymaganych zasobów.

  1. Produkty projektu

Serwis WWW eGazety - skonfigurowany i działający na serwerze „Diario”. Aplikacja umożliwia poprzez stronę internetową rejestrowanie się użytkowników w systemie, przegląd oferty wydań aktualnych po okresie wydawniczym lub kategorii, przegląd i wyszukiwanie wydań archiwalnych, składanie zamówień, przegląd zamówień archiwalnych. W odpowiednich działach serwisu można znaleźć informacje kontaktowe oraz pomoc.

Aplikacja wewnętrzna „Stokrotka” umożliwia zarządzanie zamówieniami, tytułami, użytkownikami, wydaniami, działająca na serwerze „Diario”.

Aplikacja „Wydawcy” dla wydawców umożliwiająca ręczne dodawanie stron wydań, podgląd raportów sprzedaży oraz prowizji, działająca na serwerze „Diario”

Aplikacja serwera dla programu „eGazety Reader” - skonfigurowana i działająca na serwerze „Alonzo”, serwer odpowiedzialny jest za serwowanie wydań do klientów na podstawie generowanych dostępów przez aplikacje pomocnicze, dodatkowo do wybranych klientów lub zamówień przesyła treści reklamowe.

Aplikacja kliencka „eGazety Reader” - służy do pobierania i przeglądania zamówionych wydań lub prenumerat przez klientów na ich własnych komputerach.

Aplikacja do przetwarzania plików PDF otrzymywanych przez wydawców - działająca na serwerze „Ośmiornica”. Przerabia pliki z formy drukarskiej na lekką przystępną dla klienta - wiąże się to z utratą jakości przy przetwarzaniu zdjęć.

Wewnętrzne aplikacje pomocnicze działające na serwerze „Ośmiornica” takie jak: przyznawanie dostępów do wydań, wysyłanie powiadomień o końcu prenumeraty.

Skonfigurowany serwer „Diario” na którym działają aplikacje WWW.

Skonfigurowany serwer „Tito” na którym działa główna baza danych Oracle.

Skonfigurowany serwer „Devel” na którym działają developerskie bazy Oracle.

Skonfigurowany serwer „Dante” na działają developerskie wersje aplikacji WWW oraz serwera aplikacji wydań.

Dokumentacja końcowa projektu, usługa przeszkolenia pracowników działu marketingu i sprzedaży.

Wszystkie produkty końcowe zostaną przekazane do formalnego odbioru dnia 27.06.2009 w siedzibie firmy Presspublica Sp. z o. o. mieszczącej się pod adresem Prosta Office Center, ul. Prosta 51, 00-838 Warszawa

  1. Model procesu projektowego

Zidentyfikowaćopisać główne funkcje, które będą wykonywaneramach projektuuwzględnieniem działańzakresie rozpoczęciazakończenia projektu.

Funkcje mogą mieć charakter czasowy (być wykonywane jednorazowo przez jakiś czasprojekcie np. Rozpoczęcie projektu), mogą być wielokrotne (wykonywane wielokrotnieczasie trwania projektu np. Odbiór produktu jeśli projekt zakłada wykonanie wielu produktówpewnych odstępach czasowych) lub ciągłe (wykonywane ciągleczasie 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 graficznegotekstowego.

  1. Organizacja projektu

    1. Struktura organizacyjna

Rada Nadzorcza(sponsor) - odpowiedzialna jest za zatwierdzanie i finansowanie projektu oraz za strategiczne decyzje dotyczące postępów i wdrożenia projektu. Jest również odpowiedzialna za sformowanie Komitetu Sterującego oraz sama lub wraz z Komitetem Sterującym za terminowe podejmowanie decyzji strategicznych.

Dyrektor Projektu (firma konsultingowa) - Jest w pełni odpowiedzialny przed Inicjatorem Projektu za wszelkie aspekty zarządzania oraz przebiegu projektu np.: za jakość, terminowość, budżet, eskalację problemów oraz komunikację w sprawach dotyczących projektu.

Koordynator Projektu (Project Manager) - osoba z odpowiednią ilością czasu przeznaczoną dla prac projektowych. Koordynator Projektu powinien posiadać pełną władzę w podejmowaniu decyzji organizacyjnych i działaniach bieżących. Jest odpowiedzialny za:

    • o Zarządzanie procesem zbierania dokumentacji i informacji.

    • o Koordynowanie i zapewnienie zasobów ludzkich, lokalowych oraz sprzętowych dla zespołu projektowego (np. miejsca spotkań roboczych).

    • o Komunikowanie się z firmami zewnętrznymi (np. konsultingowymi) w celu zapewnienia efektywnej wymiany informacji oraz terminowego podejmowania decyzji niezbędnych dla projektu.

Ze względu na obowiązki, Koordynator Projektu musi mieć odpowiednią moc decyzyjną oraz prawo podpisywania dokumentów projektowych.

Komitet Sterujący - Ma obowiązek uczestniczyć w spotkaniach i prezentacjach zamykających poszczególne etapy projektu, w szczególności poprzez analizę konkluzji i wyjaśnianie stanowiska oraz jego strategicznych priorytetów w obszarach objętych Projektem.

Członkowie Zespołów (Analitycy, programiści, testerzy, Administratorzy, grafik, architekci) - są odpowiedzialni za realizowanie poszczególnych merytorycznych części projektu oraz dostarczanie informacji analitycznych Kierownikowi Projektu. W przypadku konsultantów wewnętrznych, osoby te są zobowiązane do dostarczania wysokiej jakości, zweryfikowanych danych i informacji w odpowiednim formacie elektronicznym oraz do udzielania wyczerpujących odpowiedzi w wyznaczonym terminie.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!dodać rysunki!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    1. Granice organizacyjneinterfejsy

Jest tu opisane otoczenie projektu tzn. granice administracyjnezarządzania pomiędzy strukturą projektu a:

  • organizacją nadrzędną

  • organizacją zleceniodawcy

  • organizacjami podwykonawczymi

  • innymi podmiotami organizacyjnymi mającymi związkiprojektem.

Należy uwzględnić interfejsy administracyjnezarządzaniazakresie funkcji wspierających projekt, takich jak zarządzanie konfiguracją, zapewnienie jakości oraz weryfikacjasprawdzanie.

    1. Podział odpowiedzialności

Identyfikuje się tuokreśla charakter poszczególnych głównych funkcjidziałańramach projektu oraz podaje osoby odpowiedzialne za ich realizację.

Dla przedstawienia obowiązkówramach projektu można zastosować tablicę funkcjidziałań, na której zaznaczone zostaną osoby odpowiedzialne.

  1. Zarządzanie

    1. Celepriorytety zarządzania

Przedstawić filozofię, celepriorytety działań zarządzaniaczasie projektu. Określić jakie czynniki będą miały decydujący wpływ na podejmowane decyzje. Mogą one dotyczyć:

  • częstotliwościmechanizmó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.

    1. Założenia, uwarunkowaniaograniczenia

    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ętychfirmie standardówprocedur 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.

      1. Zarządzanie ryzykiem

    Określićocenić czynniki ryzyka związaneprojektem. Opisać mechanizmy śledzenia różnych czynników ryzykaplany postępowaniaprzypadku wystąpienia czynnika.

    Czynniki ryzyka, jakie należy uwzględnić, to między innymi:

    • ryzyka związanewykonaniem umowy

    • ryzyka technologiczne

    • ryzyka związanewielkością i stopniem skomplikowania produktu

    • ryzyka związanepozyskiwaniemutrzymaniem personelu

    • ryzyka związaneuzyskiwaniem akceptacji zleceniodawcy dla produktu.

      1. Mechanizmy śledzeniakontroli

      Opisaćjaki sposób będzie kontrolowana zgodność realizacji projektuplanemjakie zostaną zastosowane mechanizmy sprawozdawczości. Podać formaty raportów (np.formie załączników) oraz określić przepływy informacji pomiędzy elementami struktury organizacyjnej.

      Jeśli inne narzędziatechniki będą stosowane do śledzeniakontrolowania zgodnościplanem projektu należy je tu opisać.

        1. Plan zatrudnienia

      Podać liczbę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ą, weryfikacjasprawdzanie.

      1. Proces techniczny

        1. Metody, narzędziatechniki

      Opisać metodykę opracowywania systemu(ów) komputerowego(ych), strukturę(y) zespołu(ów), język(i) programowaniainne pojęcia, narzędzia, technikimetody, jakie są stosowane do opisywania, projektowania, budowania, testowania, integrowania, dokumentowania, dostarczania, modyfikowania lub konserwacji produktów projektu.

      Uwzględnić bezpośrednio lubformie odniesień do innych dokumentów standardy techniczne, strategieprocedury regulujące opracowywanie lub modyfikacje produktów projektu.

        1. Dokumentacja oprogramowania

      Podać bezpośrednio albopostaci odniesień, plan dokumentowania projektu. Określić wymaganą dokumentację według etapów projektu, zasady tworzenia wersji, przeglądywarunki zakończenia prac nad dokumentacją oprogramowania. Określićharmonogramie zadania oraz zasoby dla wykonania dokumentacji.

      Plan dokumentowania projektu może zawierać wytyczne odnośnie stylu, konwencje nazewnictwaformaty dokumentów.

        1. Funkcje wspomagające projekt

      Podać bezpośrednio lubpostaci odniesień, opis funkcji wspomagających projekt informatyczny. Funkcje te mogą dotyczyć np.:

      • zarządzania konfiguracją

      • zapewnienia jakości oprogramowania

      • weryfikacjisprawdzania.

      Plany funkcji wspomagania projektu należy opracować do poziomu zgodności szczegółów innymi rozdziałami planu projektu.szczególności, należy tu określić zadania, wymagania zasobów, harmonogrambudżet dla każdej funkcji wspomagającej.

      1. Etapy pracy, harmonogrambudżet

        1. Podział projektu na etapyzadania

      1. Zarządzanie projektem

      1.1 Budżet
      1.1.1 Oszacowanie kosztów projektu
      1.1.2 Zakup niezbędnych elementów potrzebnych do realizacji projektu
      1.1.3 Analiza kosztów zatrudnienia w różnych wariantach
      1.1.3.1 Ze względu na przedłużanie się projektu
      1.1.3.2 Ze względu na zapotrzebowania kadrowe
      1.1.4 Przygotowanie raportu na temat możliwych lecz niekoniecznie potrzebnych wydatkach
      1.1.5 Przygotowanie wstępnego podziału budżetu
      1.1.6 Zatwierdzenie wstępnego budżetu

      1.2 Harmonogram
      1.2.1 Analiza wymagań i kosztów projektu
      1.2.2 Podział projektu na zadania
      1.2.3 Rekrutacja pracowników
      1.2.4 Zakup sprzętu
      1.2.5 Przydział zespołów do zadań
      1.2.6 Opracowywanie dokumentacji
      1.2.7 Realizacja projektu
      1.2.8 Testy
      1.2.9 Odbiór systemu przez klienta

      1.3 Komunikacja
      1.3.1 Określenie standardów komunikacyjnych w zespołach
      1.3.2 Określenie standardów komunikacyjnych pomiędzy zespołami oraz jednostkami zewnętrznymi
      1.3.3 Analiza i wybór sposobów oraz rodzaju komunikacji ze względu na efektywność i wydajność

      1.4 Dokumentacja
      1.4.1 Określić cele i wymagania potrzebne do przygotowania dokumentacji
      1.4.2 Przygotowanie szkieletu dokumentu
      1.4.3 Przedstawienie przygotowanej formy dokumentacyjnej projektu klientowi

      1.5 Zasoby Ludzkie
      1.5.1 Analiza i określenie zapotrzebowania na osoby potrzebne do wykonania prjektu
      1.5.2 Zatrudnienie i rekrutacja
      1.5.3 Podział osób na zespoły
      1.5.4 Przydział ról i kompetencji w zespołach

      1.6 Ryzyko
      1.6.1 Przygotowanie raportu o możliwych zagrożeniach mogących wystąpić podczas realizacji projektu
      1.6.2 Oszacowanie pesymistycznych czasów dla zadań w czasie projektu
      1.6.3 Przygotowanie raportu dotyczącego dostępnego budżetu podczas przeciągania się realizacji projektu
      1.6.4 Analiza problemów technologicznych

      1.7 Zarządzanie Jakością
      1.7.1 Określenie standardów jakościowych dla wytwarzanego oprogramowania oraz dokumentacji
      1.7.1 Określenie standardów jakościowych dla produktów projektu
      1.7.2 Testy zgodności z jakością
      1.7.3 Optymalizacja procesów

      2. System Engineering

      2.1 Planowanie techniczne
      2.1.1 Analiza i określenie wymogów technicznych
      2.1.2 Przygotowanie wstępnego planu technicznego, wybór technologii, narzędzi
      2.1.3 Konsultacje wewnętrzne lub audyt zewnętrzny
      2.1.4 Zatwierdzenie ostatecznej wersji planu

      2.2 Specyfikacja aplikacji
      2.2.1 Spotkanie z klientami
      2.2.2 Opracowanie wymagań klientów
      2.2.3 Konsultacja opracowania z klientami

      2.3 Zabezpieczenia
      2.3.1 Porównanie rozwiązań zastosowanych w już wdrożonych systemach
      2.3.2 Przegląd gotowych rozwiązań komercyjnych
      2.3.3 Analiza dostępnych rozwiązań pod kątem bezpieczeństwa i kosztowej efektywności
      2.3.4 Wybór sposobu zabezpieczenia i przygotowanie planu jego implementacji

      2.4 Wizja działania
      2.4.1 Analiza specyfikacji pod kątem potrzebnych zasobów materialnych, ludzkich oraz czasu realizacji
      2.4.2 Wybór metodyk, przegląd technologii, narzędzi
      2.4.3 Połączenie planu technicznego z ogólnym harmonogramem projektu

      2.5 Zdefiniowanie wymagań biznesowych
      2.5.1 Rozmowy z klientem, spisanie jego wymagań
      2.5.2 Przygotowanie spisu wymagań funkcjonalnych i niefunkcjonalnych
      2.5.3 Przedstawienie dokumentu klientowi, naniesienie ew. poprawek

      2.6 Zdefiniowanie wymagań systemowych
      2.6.1 Oszacowanie obciążenia serwera generowanego przez jednego klienta
      2.6.2 Oszacowanie maksymalnej ilości klientów podłączonych do serwera (przewidując dalszy rozwój serwisu)
      2.6.3 Obliczenie na podstawie zebranych danych potrzebnej mocy obliczeniowej oraz przepustowości łącza internetowego

      3. Aplikacje

      3.1 Programowanie aplikacji klienckich - robione równolegle z serwerami
      3.1.1 Programowanie podstawowej funkcjonalności
      3.1.2 Poprawki uwzględniające uwagi z testów
      3.1.3 Poprawki uwzględniające uwagi klientów na temat prototypów
      3.1.4 Programowanie pełnej funkcjonalności
      3.1.5 Poprawki uwzględniające uwagi z testów
      3.1.6 Poprawki uwzględniające uwagi klientów na temat prototypów
      3.1.7 Przygotowanie wersji finalnej

      3.2 Programowanie aplikacji serwerów - robione równolegle z klienckimi
      3.2.1 Programowanie podstawowej funkcjonalności
      3.2.2 Poprawki uwzględniające uwagi z testów
      3.2.3 Poprawki uwzględniające uwagi klientów na temat prototypów
      3.2.4 Programowanie pełnej funkcjonalności
      3.2.5 Poprawki uwzględniające uwagi z testów
      3.2.6 Poprawki uwzględniające uwagi klientów na temat prototypów
      3.2.7 Przygotowanie wersji finalnej

      3.3 Programowanie aplikacji wewnętrznych - zaczynają sie po skończeniu pierwszych wersji klienckich i serwerów
      3.3.1 Programowanie podstawowej funkcjonalności
      3.3.2 Poprawki uwzględniające uwagi z testów
      3.3.3 Programowanie pełnej funkcjonalności
      3.3.4 Poprawki uwzględniające uwagi z testów
      3.3.5 Przygotowanie wersji finalnej

      4. Hardware

      4.1. Zapotrzebowanie
      4.1.1. Analiza i określenie potrzeb
      4.1.2. Przygotowanie wstępnego zestawienia sprzętowego

      4.2. Wybór podzespołów
      4.2.1. Sporządzenie oferty potrzebnego sprzętu
      4.2.2. Weryfikacja kompatybilności wybranych elementów
      4.2.3. Ewentualne zmiany przygotowanej oferty
      4.2.4. Zatwierdzenie oferty

      4.3. Zakup
      4.3.1. Wybór dostawcy
      4.3.2. Sprawdzenie kompletności oraz poprawności działania dostarczonego sprzętu

      4.4. Instalacja
      4.4.1. Instalacja systemów operacyjnych oraz oprogramowania
      4.4.2. Rozwiązywanie problemów związanych z instalacją

      4.5. Konfiguracja
      4.5.1. Konfiguracja połączenia sieciowego
      4.5.2. Dostosowanie sprzętu oraz oprogramowania pod instalację aplikacji serwerów
      4.5.3. Rozwiązywanie problemów konfiguracyjnych

      5. Testowanie

      5.1. Ustalenie metryk
      5.1.1. Metryki złożoności aplikacji
      5.1.2. Metryki wydajności aplikacji i podsystemów
      5.1.3. Metryki ergonomii i zadowolenia klientów
      5.1.4. Metryki wagi błędów

      5.2. Testowanie modułów
      5.2.1. Testowanie glass-box osobno aplikacji klienckiej i serwera pod kątem bezpieczeństwa i funkcjonalności (na podstawie specyfikacji z 2.2, 2.3, 2.5) po ukończeniu kolejnych części składowych
      5.2.2. Testowanie komunikacji klient-serwer dla różnych konfiguracji sieci
      5.2.3. Szacowanie szybkości tworzenia aplikacji na potrzeby QM

      5.3. Testowanie podsystemów
      5.3.1. Diagnostyczne testowanie zgodności aplikacji wewnętrznych ze specyfikacją
      5.3.2. Ocena niezależności i odpowiedzialności podsystemów wobec aplikacji serwera

      5.4. Testy wydajnościowe i obciążeniowe
      5.4.1. Testy zużycia zasobów i odpornościowe od wersji alpha
      5.4.2. Testy obciążeniowe i wydajnościowe od wersji beta

      5.5. Testy akceptacyjne
      5.5.1. Testy ergonomii i komfortu pracy prowadzone przez grupę kontrolną, wybraną spośród docelowych klientów
      5.5.2. Ewaluacja ergonomii i akceptacja przez grupę przyszłych administratorów systemu

      5.6 Testy niezawodności
      5.6.1. Zbieranie informacji o usterkach od momentu wdrożenia systemu
      5.6.2. Ocena stopnia zagrożenia ze strony usterek
      5.6.3. Przygotowanie hierarchii poprawek

      6. Wdrożenie

      6.1. Instalacja
      6.1.1. Instalacja aplikacji klienckich na komputerach odbiorców
      6.1.2. Rozwiązywanie problemów z instalacja


      6.2. Konfiguracja
      6.2.1. Dostosowanie programów klienckich
      6.2.2. Rozwiązywanie problemów z konfiguracja,

      6.3. Szkolenie
      6.3.1. Udostępnienie on-line instrukcji obsługi
      6.3.2. Sesje szkolenie dla pracowników dużych instytucji

      6.4. Weryfikacja poprawności działania
      6.4.1. Zbieranie uwag od użytkowników
      6.4.2. Rozpatrzenie uwag
      6.4.3. Wdrożenie wybranych uwag
      6.4.4. Odbiór finalnej instalacji przez klientów

      6.5. Support
      6.5.1. Umieszczenie FAQ na stronie serwisu
      6.5.2. Udostępnienie kanałów obsługi klienta (Telefon, GG, Skype)
      6.5.3. Pomoc “u klienta”, dla dużych instytucji

        1. Wymagania zasobów

      Wykresy poniżej przedstawiają szacunkowe wykorzystanie zasobów w trakcie trwania projektu.

      0x01 graphic

      0x01 graphic

      0x01 graphic

      • Urządzenia biurowe

      Na czas realizacji projektu i po jego realizacji zostanie udostępniona drukarka wraz ze skanerem. Można przyjąć, że oba te urządzenia będą eksploatowane przez cały czas.

      • Podróże i wymagania w zakresie konserwacji.

      Projekt nie przewiduje, żadnych podróży służbowych. Pierwsze potrzeby związane z konserwacją pojawią się długo po wdrożeniu i zakończeniu projektu.

        1. Budżetrozdział zasobów

      Zespół tworzący projekt eGazety składa się z 21 osób. Poniższa tabela przedstawia koszty jakie ponosi firma, w trakcie trwania projektu.

      Id

      Nazwa zasobu

      Maks jednostek

      Stawka zasad

      Koszt

      1

      Kierownik projektu

      100%

      90 zł./godz.

      90 000,00 zł

      2

      Zastępca kierownika projektu

      100%

      60 zł/godz.

      60 000,00 zł

      3

      Programista

      600%

      30 zł/godz.

      144 000,00 zł

      4

      Tester

      200%

      30 zł/godz.

      4 800,00 zł

      5

      Administrator Baz Danych

      200%

      50 zł/godz.

      78 000,00 zł

      6

      Administrator Sieci

      200%

      50 zł/godz.

      80 000,00 zł

      7

      Analityk

      300%

      40 zł/godz.

      50 400,00 zł

      8

      Grafik

      100%

      30 zł/godz.

      15 600,00 zł

      9

      Architekt logiki i infrastruktury

      100%

      50 zł/godz.

      35 000,00 zł

      10

      Architekt aplikacji

      100%

      50 zł/godz.

      35 000,00 zł

      11

      Architekt bezpieczeństwa

      100%

      50 zł/godz.

      35 000,00 zł

      12

      Monitor 22"

      20 szt .

      0,00 zł/godz.

      10 000,00 zł

      13

      Monitor 24"

      10 szt.

      0,00 zł/godz.

      12 000,00 zł

      14

      Notebook

      4 szt.

      0,00 zł/godz.

      12 000,00 zł

      15

      Komputer PC DEV

      12 szt.

      0,00 zł/godz.

      48 000,00 zł

      16

      Stacja graficzna

      1 szt.

      0,00 zł/godz.

      10 000,00 zł

      17

      Drukarka

      1 szt.

      0,00 zł/godz.

      1 000,00 zł

      18

      Skaner

      1 szt.

      0,00 zł/godz.

      500,00 zł

      19

      Serwer baz danych

      4 szt.

      0,00 zł/godz.

      24 000,00 zł

      20

      Serwer WWW

      3 szt.

      0,00 zł/godz.

      18 000,00 zł

      21

      Serwer backup

      1 szt.

      0,00 zł/godz.

      6 000,00 zł

      22

      Papier

      30 szt.

      0,00 zł/godz.

      360,00 zł

      24

      Długopisy

      50 szt.

      0,00 zł/godz.

      50,00 zł

      25

      Napoje

      250 szt.

      0,00 zł/godz.

      1 250,00 zł

      26

      Tablice

      2 szt.

      0,00 zł/godz.

      400,00 zł

      27

      System BD Oracle

      1 szt.

      0,00 zł/godz.

      100 000,00 zł

      28

      Windows

      16 szt.

      0,00 zł/godz.

      7 200,00 zł

      29

      Microsoft Office

      16 szt.

      0,00 zł/godz.

      9 600,00 zł

      30

      Windows Server 2003

      1 szt.

      0,00 zł/godz.

      1 000,00 zł

      31

      Visual Studio 2008

      2 szt.

      0,00 zł/godz.

      1 000,00 zł

      Razem

      890 160,00 zł

      • Szkolenia zespołu

      Budżet nie obejmuje szkoleń pracowników, ponieważ zatrudniany będzie tylko i wyłącznie w pełni wykwalifikowany personel.

      • Wydatki na końcowy produkt

      Budżet nie obejmuję tych wydatków, ponieważ ew. wydatki będą znikome i pojawią się dopiero po zakończeniu projektu.

      • Szkolenia użytkowników produktu

      Jeżeli jakakolwiek instytucja będzie chciała przeszkolić swoich pracowników pod kątem korzystania z tej aplikacji sama poniesie te koszty. Poza tym, ze względu na specyfikę i złożoność końcowego produktu szkolenia nie są niezbędne.

        1. Harmonogram

      Pełnym harmonogram dostępny jest w plik {Łukasz, wpisz tu nazwę}.mpp.

      Projekt składa się z następujących faz:

      Rozpoczęcie projektu 2009.01.05

      Określenie wymagań i Faza Analizy 2009.01.05 - 2009.02.06

      Faza Projektowania 2009.02.09 - 2009.02.27

      Faza Implementacji 2009.03.02 - 2009.06.26

      Hardware 2009.03.02 - 2009.03.27

      Testowanie 2009.05.25 - 2009.05.29

      Wdrożenie 2009.06.15 - 2009.06.26

      Zakończenie projektu 2009.06.27

      1. Ewolucja planu projektu

      Podać sposób przeprowadzenia zarówno zaplanowanych jakniezaplanowanych 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.

      1. Bibliografia

      IEEE Std 1058.1-1987 (Reaff 1993), Standard IEEE dla planów zarządzania projektami oprogramowania (ANSI)

Wersja: P

Tytuł:

Data wydania:

____.__.__

Strona / stron

/

1

Plan zarządzania projektem

Plan zarządzania projektem



Wyszukiwarka

Podobne podstrony:
plan zarz 7, plan zarządzania
plan zarz 2, plan zarządzania
plan zarz 6, plan zarządzania
plan zarz 9, plan zarządzania
plan zarz 14 final v3, plan zarządzania
plan zarz 3, plan zarządzania
plan zarz 11, plan zarządzania
plan zarz 12, plan zarządzania
plan zarz 10, plan zarządzania
PLAN ZARZADZANIA NIERUCHOMOŚCIAMI MIESZKALNYMI
4a Plan Zarzadzania Ryzykiem
plan zarządzania nieruchomością
3 Plan Zarzadzania Projektem
Plan zarządzania

więcej podobnych podstron