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.
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.
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.
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ę.
Opisy pozostałych dokumentów tworzonych w projektach software'owych to:
Opis planu zapewnienia jakości
Opis specyfikacji wymagań użytkownika
Opis projektu szczegółowego
Opis dokumentacji technicznej
Opis dokumentacji użytkownika
Opis raportów z przeglądów
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.
Layout - Graficzny szablon prezentacji informacji, najczęściej z podziałem na sekcje przeznaczonych do konkretnych celów. Najczęściej terminu tego używa się w kontekście stron internetowych i DTP. Przedstawia rozmieszczenie elementów prezentujących informacje. Mówiąc dokładniej: layout jest święty — jego się nie zmienia.
DTP - (ang. Desktop Publishing) - przygotowywanie dokumentów do publikacji w postaci elektronicznej (cyfrowej).
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.
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.
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 „Alonzo”, 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 którym działają developerskie wersje aplikacji WWW oraz serwera aplikacji wydań.
Skonfigurowany serwer „Alonzo”, na którym działają produkcyjne 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
W celu usprawnienia i dokumentowania komunikacji przy powstawaniu projektu „eGazety” posłuży system Basecamp dostępny pod adresem www.egazety.projectpath.com. Basecamp idealnie pasuje do czynności takich jak:
przydzielania zadań odpowiednim osobom,
monitorowania postępów wykonania,
zgłaszania ewentualnych błędów,
komunikacji między użytkownikami
W każdy piątek podczas trwania projektu organizowane są sztaby na których podsumowywany jest mijający tydzień. Sztab składa się z komitetu sterującego oraz ewentualnie zaproszonych wybranych osób.
Podczas podejmowania decyzji wymagających wspólnych ustaleń zwoływane są spotkania w terminach ustalonych przez kierownika projektu. Obowiązek uczestniczenia w nich mają wszyscy pracownicy biorący udział w projekcie
Granice organizacyjne i interfejsy
Na schemacie przedstawione jest otoczenie projektu składające się z innych podmiotów organizacyjnych oraz osób odpowiedzialnych za komunikowanie się. Komunikacja inna niż spotkanie prowadzona jest poprzez wybrane osoby spoza projektu dodane do systemu Basecamp w tym systemie.
ZKDP - odpowiedzialny jest za kontrolę i dystrybucję prasy w Polsce. Prenumeraty dystrybuowane przez system „eGazety” muszą być zaraportowane do ZKDPu. Przy projektowaniu systemu niezbędne jest ustalenie informacji potrzebnych do poprawnego raportowania sprzedaży.
Organizacja zleceniodawcy - działy księgowości i marketingu w celu ustalenia standardów dokumentowania sprzedaży, rozliczania, przygotowania aplikacji wewnętrznej do zarządzania zamówieniami
Axel Springer Polska - niezależny wydawca, który został zaproszony jako potencjalny klient zainteresowany platformą. Współpraca pomoże ustalić informacje potrzebne do budowy systemu.
Herbatha.pl - agencja interaktywna odpowiedzialna za zaprojektowanie i przygotowanie graficznego layoutu serwisu „eGazety” oraz aplikacji leadera.
Podział odpowiedzialności
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 - 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.
Kierownik Projektu (Project Manager) - osoba z odpowiednią ilością czasu przeznaczoną dla prac projektowych. Kierownik Projektu powinien posiadać pełną władzę w podejmowaniu decyzji organizacyjnych i działaniach bieżących. Jest odpowiedzialny za:
Zarządzanie procesem zbierania dokumentacji i informacji.
Koordynowanie i zapewnienie zasobów ludzkich, lokalowych oraz sprzętowych dla zespołu projektowego (np. miejsca spotkań roboczych).
Koordynacja współpracy wszystkich zespołów.
Komunikowanie się z firmami zewnętrznymi (np. konsultingowymi) w celu zapewnienia efektywnej wymiany informacji oraz terminowego podejmowania decyzji niezbędnych dla projektu.
Zaplanowanie i nadzór nad zadaniami.
Zaplanowanie i nadzór nad budżetem projektu.
Tworzenie i zarządzanie zespołami.
Zatrudnienie, zwalnianie personelu.
Nadzorowanie harmonogramu.
Rozwiązywanie konfliktów.
Ze względu na obowiązki, Koordynator Projektu musi mieć odpowiednią moc decyzyjną oraz prawo podpisywania dokumentów projektowych.
Zastępca Kierownika Projektu - osoba z ograniczoną odpowiedzialnością kierownika projektu - moc decyzyjna jest ograniczana przez akceptacje głównego Kierownika projektu.
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.
Zespół administratorów baz danych jest odpowiedzialny za:
Zaprojektowanie baz danych.
Optymalizację wydajności i strojenie bazy danych.
Instalację i konfigurację baz danych.
Opracowanie systemu tworzenia kopii bezpieczeństwa.
Ustalenie standardów związanych z używaniem składni poleceń SQL oraz języka PL/SQL.
Zespół administratorów systemowych i sieciowych jest odpowiedzialny za:
Instalacje i konfiguracja sprzętu.
Rozwiązywanie problemów konfiguracyjnych.
Zespół analityków jest odpowiedzialny za:
Analizy potrzebne do projektu.
Poszukiwanie rozwiązań problemów.
Zbieranie potrzebnych informacji.
Dostarczanie informacji analitycznych kierownikowi projektu
Architekt aplikacji jest odpowiedzialny za:
Nadzoruje poprawność tworzenia aplikacji.
Pracuje nad optymalizacją efektywności działania aplikacji.
Architekt logiki i infrastruktury jest odpowiedzialny za:
Tworzy model pojęciowy systemów.
Planuje sposób wymiany danych i komunikacji między aplikacjami.
Architekt bezpieczeństwa jest odpowiedzialny za:
Nadzór tworzonych aplikacji pod kątem bezpieczeństwa.
Opracowanie zabezpieczeń do programu „eGazety Reader” chroniących przed kopiowaniem i współdzieleniem plików.
Opracowanie zabezpieczeń przed współdzieleniem konta użytkownika zarejestrowanego w systemie pomiędzy innymi osobami.
Zespoły programistów są odpowiedzialne za:
Implementację systemów oraz aplikacji.
Informowanie o postępach i trudnościach w implementowaniu wybranych funkcjonalności.
Zespół testerów jest odpowiedzialny za:
Wyszukiwanie słabości w aplikacjach.
Sprawdzanie i kontrola zabezpieczeń.
Zgłaszanie wykrytych błędów oraz problemów.
Zgłaszanie uwag odnośnie funkcjonalności.
Raportowanie scenariuszy przeprowadzanych testów.
Podsumowanie kolejnych etapów testów.
Grafik jest odpowiedzialny za:
Pocięcie otrzymanych layoutów - szablonów.
Przygotowywanie elementów interfejsu użytkownika.
Wprowadzania zmian do otrzymanych szablonów w celu zwiększenia ergonomiczności interfejsów.
Cele i priorytety zarządzania
Głównym celem zarządzania będzie stworzenie dobrego jakościowo serwisu spełniającego jak najpełniej i najdokładniej oczekiwania klienta. Aby było możliwe osiągnięcie tego celu konieczne jest odpowiednie nadzorowanie zespołu projektowego. Trzeba stworzyć właściwe mechanizmy oceny wykonywanych prac oraz system raportowania co umożliwi stworzenie projektu zgodnego z założeniami.
Priorytety zarządzania mające decydujący wpływ na podejmowane decyzje:
Projekt ma sprostać oczekiwaniom klienta.
Czas realizacji projektu. Konieczne jest nadzorowanie terminów zakończenia poszczególnych części projektu tak aby zgadzały się z harmonogramem.
Koszt stworzenia projektu - nie może przekroczyć zaplanowanego budżetu.
Założenia, uwarunkowania i ograniczenia
wzrost popularności urządzeń mobilnych będzie przyspieszał lub nie zwolni poniżej obecnego trendu
projekt zostanie zakończony w terminie
kryzys gospodarczy pogłębi się nie wcześniej niż po terminie zakończenia projektu
prognoza kryzysu gospodarczego nie wpłynie na decyzję zarządu o porzuceniu projektu
nie nastąpi pospieszny, związany z kryzysem, odpływ mody na ekologię, rozbudowującej się znacznie w ciągu ostatnich 2 lat
w związku z rygorem czasowym i podjętym modelem procesu projektowego nie jest brana pod uwagę praca zdalna; przewiduje się premię liczoną przez zespół QM na podstawie wydajności pracy
budżet należy traktować co najmniej ostrożnie z powodu niepewnej sytuacji Złotego w nadchodzących kwartałach
Mechanizm śledzenia ryzyka
Plan postępowania w przypadku wystąpienia ryzyka
Przekroczenie budżetu - projekt generuje straty finansowe zamiast zysków
Kosztorys projektu powinien być poddany bardzo dokładnej analizie uwzględniającej wszystkie koszty wytworzenia systemu oraz niezbędny margines.
Należy zbadać skalę problemu oraz ocenić rentowność projektu przy nowym kosztorysie.
Błędnie określony harmonogram prac nad projektem
Przekroczenie terminu uruchomienia projektu, co wiąże się z ryzykiem utraty rynku na rzecz konkurencyjnych rozwiązań
Dokładnie opracowany harmonogram projektu, uwzględniający na każdym etapie dodatkowy czas przeznaczony na ewentualne poprawki. Dodatkowo powinna zostać wdrożona metoda kontroli postępu prac (raporty, sprawozdania).
W zależności od postępu prac oraz skali problemu:
- Przyspieszenie prac nad projektem poprzez zatrudnienie dodatkowych pracowników.
- Przesunięcie daty zakończenia projektu.
Błędy przy zatrudnieniu pracowników
Zatrudniono zbyt małą liczbę pracowników, lub okazali się oni niekompetentni.
- Dokładne określenie liczby pracowników potrzebnych do realizacji projektu
- Przywiązanie dużej wagi do procesu rekrutacji, a zwłaszcza rozmów kwalifikacyjnych
Przeprowadzenie szybkiej rekrutacji - ogłoszenia w mediach, ew. pomoc firmy head-hunterskiej. Zwolnienie niekompetentnych osób.
Problemy z utrzymaniem kadry
Pracownicy rezygnują, są podkupywani przez konkurencję, duża rotacja kadr.
Śledzenie ruchów kadrowych oraz nastrojów panujących w zespole.
Znalezienie przyczyny problemu i wyeliminowanie go - Wprowadzenie programów lojalnościowych, nagród motywujących, poprawa stosunków między pracownikami.
Rozbieżności w specyfikacji wymagań funkcjonalnych i niefunkcjonalnych
Wymagania i założenia brane pod uwagę przy projektowaniu systemu mogą się okazać nie dość precyzyjne, niekompletne lub mogą się zmienić w trakcie trwania projektu
Stała komunikacja między zarządem firmy (zleceniodawcą) a zespołem projektowym. Poszukiwanie niejasności i rozbieżności w założeniach projektu na każdym etapie prac.
Szybkie wprowadzenie zmian w odpowiednich modułach projektu, lub zmodyfikowanie założeń projektu.
Awaria systemu, utrata danych - skasowanie, uszkodzenie dysku, kradzież
Systematyczne tworzenie kopii zapasowych przez każdego pracownika oraz przenoszenie ich na centralny serwer oraz do kierownika projektu.
Przywrócić kopię zapasową z centralnego serwera lub uzyskanie uprzednio wykonanej kopii od kierownika projektu
Brak lub niewystarczająca ilość sprzętu potrzebnego do ukończenia projektu
Przygotowanie szczegółowej specyfikacji sprzętu potrzebnego do realizacji projektu.
Dokonać zakupu niezbędnego sprzętu lub wykorzystać firmę zewnętrzną, która dysponuje odpowiednim zapleczem i zlecić jej wykonanie zadania.
W ocenie strat wywołanych przez dane zagrożenia oraz ich prawdopodobieństwa została przyjęta skala (rosnąco):
Małe - skutki zagrożenia można łatwo zniwelować, a nawet gdy nie uda się go wyeliminować nie spowoduje ono dużych strat
Średnie - Zagrożenie takie może, ale nie musi być powodem niepowodzenia projektu. Skutki da się zniwelować, lecz w niektórych przypadkach może się to wiązać z przesunięciami w harmonogramie.
Duże - Oznacza duże zagrożenie dla projektu. Może spowodować przesunięcia w harmonogramie oraz powiększać potrzebny do ukończenia projektu budżet.
Bardzo duże - Zdarzenie takie jest bardzo niebezpieczne dla powodzenia całego projektu. Wiąże się najczęściej z przesunięciami w harmonogramie oraz zazwyczaj z dużymi, dodatkowymi kosztami dla firmy.
Małe - prawdopodobieństwo na poziomie 0 - 25%
Średnie - prawdopodobieństwo na poziomie 26 - 50%
Duże - prawdopodobieństwo na poziomie 51 - 75%
Bardzo duże - prawdopodobieństwo na poziomie 76 - 100%
Mechanizmy śledzenia i kontroli
krótkie spotkania całego zespołu w każdy poniedziałek (oprócz 13.04) na początku dnia pracy
codzienna ewaluacja jakości i wydajności pracy członków zespołu prowadzona przez zespół QM wg metryk
tygodniowe raporty zespołu QM do kierownika projektu (przed każdą sobotą oprócz 11.04)
„skrzynka na racjonalizacje” (wirtualna lub fizyczna), do której każdy pracownik może wrzucić swoje propozycje
wyznaczone „dni otwarte” dla klienta, organizacja takich wydarzeń należy do zadań kierownika
kilka „dni milestone'owych” rozłożonych w czasie zgodnie z harmonogramem w celu cyklicznej synchronizacji pracy całego zespołu; w późniejszych fazach projektu dni te są głównie przeznaczone na kompleksowe testy i przedstawienie zespołowi (przez kierownika) raportu, podsumowującego poprzednią fazę i nakreślającego plan kolejnych zadań
deweloperzy nie piszą raportów, ich zadaniem jest skupienie na swojej pracy
budżet przewiduje niewielką rezerwę na „awaryjne” zatrudnianie dodatkowych deweloperów
Plan zatrudnienia przy realizacji projektu przedstawiony jest za pomocą wykresów ilustrujących ilość osób. Na początku przedstawione są wykresy ilustrujące zatrudnienie w poszczególnych działach, a na końcu całkowita ilość osób potrzebna do realizacji projektu.
Dział kierowniczy (łącznie 2 osoby)
Kierownik projektu (1 osoba)
Zastępca kierownika projektu (1 osoba)
Dział architektów i analityków (łącznie 6 osób)
Architekt logiki i infrastruktury (1 osoba)
Architekt aplikacji (1 osoba)
Architekt bezpieczeństwa (1 osoba)
Zespół analityków (3 osoby)
Dział projektowy (łącznie 9 osób)
Zespół programistów C# (2 osoby)
Zespół programistów Java (4 osoby)
Zespół testerów (2 osoby)
Dział administratorów (łącznie 4 osoby)
Zespół administratorów baz danych (2 osoby)
Zespół administratorów sieci (2 osoby)
Metody, narzędzia i techniki
Projekt będzie pisany w oparciu o wzorzec projektowy MVC(Model - View - Controller). MVC umożliwi w sprawny i szybki sposób stworzenie modyfikowalnej aplikacji. Więc jeśli zajdzie konieczność zmiany struktury bazy danych, lub wymiany całej bazy, zmieniany będzie tylko kod modelu. Dzięki temu będziemy mieli pewność iż nie będzie miało to wpływu na inne części aplikacji.
Językiem programowania który posłuży do napisania aplikacji będzie Java Enterprise Edition wersja 5 oraz platforma .NET z wykorzystaniem języka C#. Standardy kodowania mają być zgodne z GNU Coding Standards a obowiązującą notacją przy pisaniu kodu jest notacja węgierska. Do wykonania interfejsu graficznego posłuży nam Adobe Photoshop CS2. Jako system bazy danych wykorzystamy Oracle 11g. Natomiast jako serwer posłuży nam Apacze Toccat gdyż umożliwia uruchamianie aplikacji internetowych w technologiach Java Servlets oraz JSP (Java Server Pages).
Kierownik projektu / Zastępca kierownika projektu - (2 osoby) Prowadzi projekt podejmując główne decyzje i motywując personel do ich właściwego wykonania.
Programiści - (6 osób) Odpowiadają za oprogramowanie zarówno aplikacji klienckich jak i tych przeznaczonych dla serwera.
Testerzy - (2 osoby) Przygotowywanie oraz przeprowadzanie testów poszczególnych części jak i całej aplikacji w celu wyszukania słabości i niedociągnięć w aplikacjach.
Administratorzy Baz Danych / Administratorzy Sieci - (4 osoby) Osoby odpowiedzialne za obsługę komunikacji sieciowej oraz obsługę baz danych.
Analitycy / Architekci - (6 osób) Osoby odpowiedzialne za zaprojektowanie całego systemu.
Grafik - (1 osoba) Przygotowanie od strony graficznej interfejsów klienta i serwera.
Konfiguracja: Intel Core Duo 2,4 GHz, 1024 MB RAM, 200 GB HDD, DVD-RW, Karta sieciowa
Oprogramowanie: Windows XP Pro SP2, MS Office, Visio
Konfiguracja: Intel Core Duo 2,4 GHz, 2048 MB RAM, 250 GB HDD, DVD-RW, Karta sieciowa
Oprogramowanie: Windows XP Pro SP2, MS Office, Visio
Konfiguracja: Intel Core Duo 2,4 GHz, 2048 MB RAM, 2x500 GB HDD, DVD-RW, GeForce GTX 260 Karta sieciowa
Oprogramowanie: Windows XP Pro SP2, MS Office, Photoshop CS2
Konfiguracja: 2x Quad-Core Intel Xeon Processor 5405 - 2,00 GHz, 8 GB RAM, 4 x 350 GB SCSI HDD SATA (macierz), DVD-RW
Oprogramowanie: Linux SuSe Enterprise, Oracle 11 g
Konfiguracja: Intel Itanium 3,2 GHz, 4 GB RAM, 500 GB SCSI HDD, DVD, Karta sieciowa
Oprogramowanie: Linux SuSe Enterprise
Konfiguracja: Intel Celeron, 1 GB RAM, 8 x 750 GB SCSI HDD, Karta sieciowa
Oprogramowanie: FarStone DriveClone PRO 5
Testy funkcjonalne (czarnej skrzynki) - Aplikacja jest testowana bez wnikania w techniczne szczegóły działania programu.
Testy strukturalne (szklanej skrzynki) - Testerzy będą mieli dostęp do kodu źródłowego oprogramowania, będą mogli obserwować jak zachowują się różne części aplikacji, jakie moduły i biblioteki są wykorzystywane w trakcie testu.
Testy jednostkowe - testują oprogramowanie na najbardziej podstawowym poziomie - na poziomie działań pojedynczych funkcji (metod)
Testy integracyjne - pozwolą sprawdzić jak współpracują ze sobą różne komponenty
Testy systemowe - pozwolą sprawdzić różne wymagania niefunkcjonalne: szybkość działania, bezpieczeństwo, niezawodność, dobrą współpracę z innymi aplikacjami i sprzętem.
Dokumentacja oprogramowania
Do projektu należeć będą następujące typy dokumentacji:
Wymagań - zbierająca oczekiwania klientów odnośnie produktu oraz wymaganą funkcjonalność. Powstaje w wyniku konsultacji z przedstawicielami klientów, w których uczestniczy kierownik projektu, a także analityk, architekt i programista. Jest ona sporządzana w formie pliku tekstowego zawierającego opis wymagań w języku naturalnym, bez zbędnych szczegółów technicznych. Po zakończeniu konsultacji ostateczną wersję przygotowuje kierownik projektu, jest ona następnie zatwierdzana przez dyrektora zadań ze strony klientów.
Projektowa - zawierająca analityczny opis projektu. Stanowi bazę, z której korzystają programiści w trakcie tworzenia projektu. Przygotowywana jest przez analityków i architektów na bazie ostatecznej wersji dokumentacji wymagań. Składa się z głównego pliku tekstowego, oraz dołączonych obrazów lub innych plików specyficznych dla wykorzystywanego przez zespół oprogramowania. Po zakończeniu etapu planowania ostateczną wersję przygotowuje główny analityk, a zatwierdza kierownik projektu.
Techniczna - przygotowywana przez poszczególnych programistów, zawiera opis tworzonego przez nich kodu, wykorzystywanych algorytmów i interfejsów. Każdy zespół programistyczny dokumentuje swoją część pracy, dokumentacja ta jest następnie zatwierdzana przez kierownika danego zespołu po zakończeniu pracy danego zespołu. Dokumentacja przygotowywana jest formie plików tekstowych, w części generowanych automatycznie poprzez narzędzia specyficzne dla języka programowania, w którym pracuje dany zespół, a następnie uzupełnianych przez odpowiedzialną za dany fragment osobę.
Użytkowa - Instrukcja obsługi wytworzonego oprogramowania dla użytkowników końcowych. Przygotowywana jest przez wyznaczonych programistów i testerów na etapie wdrożenia, w formie plików PDF. Ostateczną wersję zatwierdza dyrektor zadań ze strony klientów w trakcie odbioru produktu.
Dokumentacje wymagań, projektowa i techniczna posiadają zbliżony format - każda z nich w swoich plikach tekstowych powinna zawierać przedstawiony niżej nagłówek:
Nazwa pliku powinna odzwierciedlać typ dokumentacji do którego należy. Dodatkowo wersja dołączana jest na końcu nazwy pliku, a najnowsza wersja dodatkowo literą A, np. Dokumentacja_wymagan_3.doc. , Dokumentacja_wymagan_4_A.doc.
Wersja określana jest liczbą, inkrementowaną o jeden po każdej znaczącej zmianie dokumentu. Niewielkie modyfikacje - poprawianie literówek w tekście, formatu itd. Są zapisywane bez zmiany numeru wersji. Wersja ostateczna przedstawiana do zatwierdzenia oznaczana jest literą F zamiast numeru wersji.
Jako zatwierdzenie rozumiane jest podpisanie wydruku danego dokumentu przez odpowiedzialną za to osobę.
W wypadku dokumentacji technicznej przyjęte będą konwencje typowe dla danego języka programowania, lub uzgodnione uprzednio i opisane przez dany zespół programistyczny.
Dokumentacja użytkowa, z racji na swoją specyfikę, nie posiada cech typowych dla pozostałych typów dokumentacji, jej wygląd ustalają odpowiedzialne za nią osoby.
Część dokumentacji przygotowywana przy użyciu platformy Basecamp może odbiegać od powyższych specyfikacji, ze względu na przyjęte tam konwencje. Ostateczna wersja powinna jednak zostać skopiowana do pliku zgodnego z powyższymi wytycznymi.
Funkcje wspomagające projekt
Nad zapewnieniem jakości będzie czuwał zespół QM. Do jego zadań będzie należała codzienna ocena wydajności członków zespołu oraz składanie cotygodniowych raportów bezpośrednio do kierownika projektu. Kierownik projektu będzie czuwał nad zgodnością poszczególnych elementów z wymaganiami odnośnie projektu. W razie konieczności będzie mógł wstrzymać przygotowywanie modułu do czasu poprawienia funkcjonalności we wcześniej skończonym module. Aby uniknąć jakichkolwiek nieporozumień będą wyznaczone podczas całego procesu tworzenia projektu dni spotkań z klientem na których będą weryfikowane ewentualne niezgodności.
Architekt logiki i infrastruktury będzie odpowiedzialna za poprawność konfiguracji. Do jego zadań będzie należało poinformowanie całego zespołu a w szczególności kierownika projektu w przypadku konieczności wniesienia jakiś zmian. Każdy programista jest zobowiązany poinformować go w przypadku chęci naniesienia jakiś poprawek bądź też usprawnień.
Rodzaj wykonywanych testów został opisany w rozdziale 8.1. Będą one wykonywane zgodnie z wcześniej zaplanowanym harmonogramem. W razie potrzeby kierownik lub jego zastępca może zlecić wykonanie dodatkowych testów.
Etapy pracy, harmonogram i budżet
Podział projektu na etapy i zadania
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 projektu
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.2. Określenie standardów jakościowych dla produktów projektu
1.7.3. Testy zgodności z jakością
1.7.4. Optymalizacja procesów
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.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.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.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.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
Wykresy poniżej przedstawiają szacunkowe wykorzystanie zasobów w trakcie trwania projektu.
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.
Zastępca kierownika projektu
Architekt logiki i infrastruktury
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.
Pełnym harmonogram dostępny jest w pliku eGazety - project.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
Planowane aktualizacje planu projektu zostały wyróżnione poniższej tabeli.
Wydanie zaakceptowane do projektowania systemu
Wydanie uwzględniające poprawki z etapu projektowania systemu
Wydanie po utworzeniu systemu i oddaniu go do testów
Serwer projektowy będzie zawierał mechanizm dystrybucji planu projektu. Będzie on udostępniał najnowsze wersje planu powstałe w wyniku wprowadzenia planowanych i nieplanowanych zmian. Powstanie nowej wersji spowoduje wysłanie emaili informujących o pojawieniu się nowej wersji do wszystkich członków zespołu pracującego nad projektem.
Dodatkowo użyte zostanie narzędzie rejestrujące zmiany w planie projektu. Będzie ono centralnym punktem śledzenia i zbierania informacji o wszelkich zmianach w planie, ułatwi tym samym zarządzanie wersjami planu.
Aplikacja będzie przechowywała następujące informacje o wersji:
Generowany automatycznie numer identyfikacyjny
Istotność (w 5-stopniowej skali od najmniej ważnych do kluczowych zmian)
Status (otwarta, zamknięta, zatwierdzona)
Proces śledzenia zmian będzie polegał na odnotowywaniu przez wszystkich uczestników projektu wprowadzanych zmian w centralnym systemie. Dzięki temu kierownik projektu będzie w stanie kontrolować postęp prac na dokumentem i gdy wprowadzone zostaną większe zmiany - stworzyć nową wersję planu. Nowe wersje planu może tworzyć tylko kierownik (lub jego zastępca). Gdy taka wersja zostanie utworzona, zostaje umieszczona na serwerze projektowym i rozpowszechniona przez zainstalowany na nim system dystrybucji. Wszyscy członkowie zespołu zostaną o tym automatycznie powiadomieni drogą e-mailową.
IEEE Std 1058.1-1987 (Reaff 1993), Standard IEEE dla planów zarządzania projektami oprogramowania (ANSI)
|