Wersja: P
Tytuł:				Data wydania: ____.__.__
				Strona / stron 1 / 16
Opracował:			Podpis:
Zatwierdził:			Podpis:
Spis treści: 1. Wstęp
Wstęp 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. 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. 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. 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ę. 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 Definicje Plik - zbiór danych, o skończonej długości, posiadający szereg atrybutów i stanowiący dla systemu operacyjnego całość. PDF - format plików służący do prezentacji, przenoszenia i drukowania treści tekstowo-graficznych, stworzony i promowany przez firmę Adobe Systems. PAR - format plików przygotowany na potrzeby projektu „eGazety”, będący specjalnie zaszyfrowaną wersją piku PDF. Aplikacja - konkretny ze względu na oferowaną użytkownikom funkcjonalność element oprogramowania użytkowego, służący ułatwieniu lub usprawnieniu działania użytkownika. Czytnik - aplikacja umożliwiająca odtwarzanie i wyświetlanie plików PAR. ZKDP - Związek Kontroli i Dystrybucji Prasy, organizacja wydawców, agencji reklamowych i ogłoszeniodawców, zajmująca się zbieraniem i weryfikowaniem danych o dystrybucji prasy i sprzedaży reklam. Basecamp - aplikacja sieciowa służąca do zarządzania projektami oraz ich nadzorowania. Wydanie, Edycja - odpowiednio przygotowany tekst lub zespołu tekstów zrealizowany w określonym czasie, miejscu i formie graficznej za pomocą określonych technik drukarskich. Wydawca - osoba bądź instytucja, za której pieniądze przygotowywane, opracowywane, a następnie drukowane jest czasopismo, książka, lub publikowana podobna rzecz, np. komercyjny portal internetowy. UML - Język formalny służący do opisu świata obiektów w analizie obiektowej oraz programowaniu obiektowym. Serwer - jest to program świadczący usługi na rzecz innych programów, zazwyczaj korzystających z innych komputerów połączonych w sieć. Serwerem nazywa się często komputer świadczący takie usługi, sprowadzające się zazwyczaj do udostępniania pewnych zasobów innym komputerom lub pośredniczący w przekazywaniu danych między komputerami. Urządzenie mobilne - przenośne urządzenie elektroniczne pozwalające na przetwarzanie, odbieranie oraz wysyłanie danych bez konieczności utrzymywania przewodowego połączenia z siecią, np. palmtop, telefon komórkowy. Palmtop, PDA - mały, przenośny komputer osobisty. Mniejszy od laptopa - z powodzeniem mieści się w dłoni lub w kieszeni. E-book, e-książka - treść zapisana w formie elektronicznej, przeznaczona do odczytania za pomocą odpowiedniego oprogramowania zainstalowanego w urządzeniu komputerowym. Baza danych - zbiór danych zapisanych w ściśle określony sposób w strukturach odpowiadających założonemu modelowi danych. W potocznym ujęciu obejmuje dane oraz program komputerowy wyspecjalizowany do gromadzenia i przetwarzania tych danych. Wersja deweloperska - wersja programu w trakcie tworzenia, może różnić się od wersji końcowej, zwykle pracuje na oddzielnych serwerach by nie wpływać na działanie aktualnej wersji. Zarys projektu Projekt „eGazety” obejmuje stworzenie serwisu internetowego służącego do dystrybucji prasy i E-booków w formie cyfrowej, aplikacji umożliwiającej klientom czytanie zakupionych tytułów, a także aplikacji niezbędnych do odbierania plików z gazetami od wydawców, przetwarzania ich a następnie udostępniania klientom. Dodatkowo przewidziano stworzenie wersji dla urządzeń mobilnych, ze względu na dynamicznie rozwijający się rynek tych urządzeń. Serwis umożliwiał będzie wydawcom rozpowszechnianie swoich tytułów w formie plików .par, które przygotowywane będą automatycznie przez wyznaczony serwer na podstawie dostarczonych przez wydawcę materiałów. Użytkownik po opłaceniu będzie mógł czytać pobrany plik przy pomocy dedykowanej aplikacji klienckiej wytworzonej jako część projektu. Największymi konkurentami są serwisy nexto i e-kiosk, które działają już na rynku od pewnego czasu i zdążyły zdobyć pewną grupę czytelników, jednak nie oferują one usług mobilnych, a rynek gazet elektronicznych jest na tyle młody, że wciąż nie ma określonego lidera. Mniejszą konkurencję stanowią również własne rozwiązania konkretnych wydawców. Do realizacji projektu „eGazety” przewidziano łącznie 21 osób, którym trzeba będzie zapewnić odpowiednie warunki pracy, zasoby w postaci sprzętu komputerowego, oprogramowania i inne. Łączny koszt projektu został skalkulowany na około 900 000,00 PLN. 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 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. Organizacja projektu 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!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 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. 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. Zarządzanie 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. 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. 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. 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ć. 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. Proces techniczny Metody, narzędzia i techniki Opisać metodykę 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. 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. 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. Etapy pracy, harmonogram i budżet Podział projektu na etapy i zadania 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 Wymagania zasobów Wykresy poniżej przedstawiają szacunkowe wykorzystanie zasobów w trakcie trwania projektu. • 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. Budżet i rozdział 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. 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 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. 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 4 / 18

1

Plan zarządzania projektem

Plan zarządzania projektem

---