Software Development Plan

Transkrypt

1 Software Development Plan Autor: Tkaczyk Cezary Data ostatniej zmiany: 25 listopada 2004 Streszczenie: Dokument definiuje sposób pracy nad projektem. Wyszczególnia osoby i ich zadania, określa terminy, opisuje plan testów

2 Podstawowe informacje o dokumencie Autor: Tkaczyk Cezary Status: roboczy Tytuł: Software Development Plan Projekt: Q-PROJECT Utworzenie: 7 listopada 2004 roku roku Ostatnie zmiany: 25 listopada 2004 Liczba stron: 16+2

3 SPIS TREŚCI Spis treści 1 Wprowadzenie Cel Zakres Definicje Załączniki Omówienie reszty dokumentu Omówienie projektu Cel, zakres i objectives projektu Założenia i zależności Produkty projektu Procedura zmian w planie projektu Organizacja projektu Struktura organizacyjna Kontakty zewnętrzne Role i zadania Kierownik zespołu Kierownik kontroli jakości Inne Zarzadzanie projektem Oszacowania Plan projektu Plan faz projektu Cele poszczególnych iteracji Zasoby Plan zarządzania wymaganiami Plan zarządzania harmonogramem Plan kontroli budżetu Q-Group 1

4 4.2.7 Plan kontrol jakości Plan raportów Plan pomiarów Plan zarządzania ryzykiem Plan zamknięcia projektu Plany procesów technicznych Programowanie Metody, narzędzia i stosowane technologie Plan infrastruktury Plan akceptacji produktu Plany pomocnicze Plan zarządzania zmianami Plan oceny Plan dokumentacji Plan zapewnienia jakości Plan rozwiązywania problemów Inne plany Plan zwoływania zebrań Historia zmian 16 2 SOFTWARE DEVELOPMENT PLAN

5 1 Wprowadzenie 1.1 Cel Dokument SDP opisuje organizację pracy przy projekcie Q-PROJECT. Wyszczególnia wszystkie czynności i procedury potrzebne podczas pracy nad projektem i implementacją. Zebranie ich w jednym miejscu ma usprawnić pracę oraz ułatwić podejmowanie strategicznych decyzji. 1.2 Zakres SDP opisuje proces tworzenia projektu i implementacji systemu Q-PROJECT. W szczególności dokument zawiera: - Omówienie projektu - Organizacje projektu - Zarządzanie projektem - Plany procesów technicznych - Plany pomocnicze 1.3 Definicje - Q-GROUP - zespół w składzie Tomasz Krasuski, Piotr Kwiatkowski, Cezary Tkaczyk, Tomasz Zdunowski - Q-PROJECT - dokumentacja i implementacja hurtowni danych realizowany przez Q-GROUP w ramach zajęć ZPP - projekt - dokumentacja implementowanego oprogramowania. Składają się na nią: - Business Vision - Software Development Plan - Business Use Case - Use Case - Software Architecture Document - Acceptance Plan - ZPP - przedmiot Zespołowy Projet Programistyczny prowadzony w ramach zajęć na wydziale MIM Uniwersytetu Warszawskiego - quad_group - quad_group@yahoogroups.com - darmowa grupa dyskusyjna założona w serwisie yahoo, służąca do organizacji pracy wewnątrz zespołu Q-Group 3

6 1.4 Załaczniki 1.5 Omówienie reszty dokumentu Dalsza część dokumentu omawia krótko cele i zakres projektu, a następnie koncentruje się na organizacji pracy zespołu podczas realizacji projektu i implementacji. 2 Omówienie projektu 2.1 Cel, zakres i objectives projektu Głównym celem dla każdego członka Q-GROUP jest zaliczenie z jak najlepszą oceną przedmiotu ZPP. Znaczny wpływ na ocenę ma uczestnictwo w tworzeniu Q-PROJECT. Zakres Q-PROJECT obejmuje: - Stworzenie dokumentacji, szczegółowej zwłaszcza w części implementacyjnej. - Implementacji projektu - Przeprowadzenia serii testów i wdrożenia testowego - Napisania przez każdego z członków Q-GROUP pracy licencjackiej 2.2 Założenia i zależności Założenia dotyczące projektu: - projekt powstaje na potrzeby zajęć ZPP - projekt jest realizowany przez Q-GROUP - w projekcie nie będą szacowane żadne wydatki - wszystkie pliki i korespondencja między członkami Q-GROUP w sprawie projektu będą przechowywane na grupie dyskusyjnej quad_group - cały zakres czynności będzie realizowany przy pomocy narzędzi dostępnych dla Q-GROUP darmowo - oznaczenia wersji dokumentów będą nadawane wg zasad podanych w pliku oznaczenia.txt 4 SOFTWARE DEVELOPMENT PLAN

7 2.3 Produkty projektu Produktami projektu są dokumentacja i implementacja. Dokumentacja obejmuje: - Business Vision - Software Development Plan - Business Use Case - Use Case - Software Architecture Document - Acceptance Plan 2.4 Procedura zmian w planie projektu Dokument SDP będzie tworzony w następujących iteracjach: Data przygotowania 8.XI XI XI.2004 Wersja Wersja wstępna Wersja robocza Ostateczna wersja 3 Organizacja projektu 3.1 Struktura organizacyjna - Tomasz Krasuski - kierownik kontroli jakości - Piotr Kwiatkowski - Cezary Tkaczyk - kierownik - Tomasz Zdunowski 3.2 Kontakty zewnętrzne dr Paweł Janowski - opiekun projektu, ocenia projekt Q-Group 5

8 3.3 Role i zadania Kierownik zespołu - Odpowiada za całą pracę zespołu. - Przydziela zadania członkom zespołu. - Ustala standardy projektowania i implementacji - Zatwierdza proponowane wymagania - Nadzoruje wprowadzanie istotnych zmian w dokumentach. - Nadzoruje rozwiązywanie trudnych problemów projektowych. - Zwołuje zebrania zespołu. - Rozlicza członków zespołu z wykonanej pracy Kierownik kontroli jakości Kierownik kontroli jakości w fazie projektowania współdzieli pracę związaną z utrzymaniem jakości z kierownikiem zespołu. Mimo to, odpowiedzialność spoczywa na kierowniku kontroli jakości. - Nadzoruje wprowadzanie istotnych zmian w implementacji. - Nadzoruje rozwiązywanie trudnych problemów implementacyjnych. - Kontroluje projekt pod względem: - spełniania wymagań - spójności definicji - spójności modelu i perspektyw projektowych - poprawności językowej - Kontroluje ostateczne wersje dokumentów stworzonych przez zespół Inne Pozostałe role i zadania są dzielone na wszystkich członków zespołu. O to aby podział był równy dba kierownik. 6 SOFTWARE DEVELOPMENT PLAN

9 4.2 Plan projektu 4 Zarzadzanie projektem 4.1 Oszacowania Czasowe: - dokumentacja - Całość dokumentacji powstaje w pierwszym semestrze akademickim roku 2004/05. Prace rozpoczęły się 5 października 2004, będą trwały do 5 stycznia implementacja i wdrożenie - drugi semestr roku akademickiego 2004/05. Dokładnie od 5 stycznia do 18 maja Plan projektu Plan faz projektu... Faza Iteracja Czas Trwania Poczatek Koniec Rozpoczęcie A 1.5 m-c 5.X XI.2004 Opracowanie A 2 m-c 9.XI I.2005 Opracowanie B 2 tyg. 4.I I.2005 Budowa A 2 m-c 15.II IV.2005 Budowa B 1 m-c 29.III V.2005 Budowa C 2 tyg 3.V V.2005 Przekazanie A 2 tyg 17.V V.2005 Tablica 2: Fazy projektu i czas ich trwania Faza Czynności Wyniki Rozpoczęcie zaplanowanie pracy, zebranie wymagań, analizowanie wymagań rynku, analizowanie przypadków użycia a- plikacji, zbadanie możliwości implementacji oraz dostępnych narzędzi Opracowanie zaprojektowanie architektury Q-PROJECT, rozpoznanie podstawowych klas, sprawdzenie zgodności zaprojektowanej aplikacji z przypadkami użycia Budowa programowanie aplikacji, testowanie przypadków użycia aplikacji ustalenie zakresu projektu i jego celów, stworzenie Business Vision, Business Use Cases i Software Development Plan projekt umożliwiający rozpoczęcie fazy implementacyjnej, dokumenty: Diagram Klas, Diagram Przejść, Use Case, Diagram Komunikatów, Software Architecture Document aplikacja gotowa do oddania do pierwszych testów Q-Group 7

10 Faza Czynności Wyniki Przekazanie testowe wdrożenie, testowanie system gotowy do rozpoczęcia działania całości, zbieranie uwag i wprowadzenie poprawek w aplikacji, prezentacja aplikacji, pisanie przez członków prac licencjackich Tablica 3: Opis faz projektu i ich wyników Cele poszczególnych iteracji Faza Itaracja Wyniki Rozpoczęcia A Business Vision, Business Use Cases i Software Development Plan Opracowanie A Use Case, Diagram Klas, Diagram Przejść, Diagram Komunikatów Opracowanie B Software Architectue Document Budowa A gotowe testy modułów oraz moduły nimi przetestowane Budowa B integracja modułów i stworzenie i zaaplikowanie testów integracyjnych całości Budowa C ostateczne wersje warstw klienckich, testy przypadków użycia Przekazanie A system gotowy do rozpoczęcia działania, prace licencjackie gotowe do oddania Tablica 4: Cele poszczególnych iteracji 8 SOFTWARE DEVELOPMENT PLAN

11 4.2 Plan projektu Q-Group 9

12 4.2.3 Zasoby Plan zatrudnienia się z czterech osób: Zespół pracujący nad projektem jest przez cały okres niezmienny. Składa - Tomasz Krasuski - Piotr Kwiatkowski - Cezary Tkaczyk - Tomasz Zdunowski Szkolenie Uczestniczacy Prowadzacy Java - podstawy Wszyscy n.d. przedmiot XML Cezary Tkaczyk n.d. Latex referat Wszyscy Tomasz Krasuski CVS referat Wszyscy n.d. JavaDoc referat Wszyscy n.d. XML referat Wszyscy n.d. Tablica 5: Plan Szkoleń Plan szkoleń Plan zarzadzania wymaganiami Wymagania mogą być zgłaszane przez dowolnego członka Q-GROUP oraz przez klienta. Każde zgłoszone wymaganie trafia do kierownika Q-GROUP. Zostaje zatwierdzone i ogłoszone do wiadomości wszystkich na grupie dyskusyjnej, lub odrzucone, o czym zostanie poinformowany zgłaszający Plan zarzadzania harmonogramem Kierownik Q-GROUP jest odpowiedzialny i zarządza harmonogramem. Kierownik na bieżąco przydziela zadania członkom zespołu. Jeśli któryś z członków nie jest w stanie skończyć zadania w określonym czasie, zgłasza problem do Kierownika. Kierownik przydziela część (lub całość) zadania innym członkom zespołu, lub odpowiednio zmienia harmonogram. 10 SOFTWARE DEVELOPMENT PLAN

13 4.3 Plan zarządzania ryzykiem Plan kontroli budżetu Plan kontrol jakości Przed oddaniem każdy dokument musi zostać: - przejrzany przez Kierownika Q-GROUP pod względem: merytorycznej poprawności zgodności z wymaganiami spójności definicji spójności modelu i perspektyw projektowych jasności zawartych sformułowań poprawności językowej i stylistycznej estetyki Plan raportów Decyzja o generowaniu raportu będzie podejmowana na bieżąco przez Kierownika Q-GROUP Plan pomiarów 4.3 Plan zarzadzania ryzykiem Opis Skutki Przeciwdziałanie Gdy się zdarzy Odejście jednego z Nieoddanie produktów wzajemna kontrola przyjąć do zespołu członków zespołu zgodnie z oraz zachęcanie i nowego członka, lub Harmonogramem motywowanie do zmienić harmonogram pracy lub/i zmniejszyć funkcjonalność produktu Chwilowa niedyspozycyjność Nieoddanie pro- Wcześniejsze infor- rozłożenie pracy jednego duktów zgodnie z mowanie o możli- realizowanej przez z członków zespołu Harmonogramem wości zajścia nieobecnego na pozostałych członków zespołu Q-Group 11

14 Opis Skutki Przeciwdziałanie Gdy się zdarzy Absencja kierownika nierozdzielenie zadań jak najlepsze dostosowanie Kierownik drogą elek- na zebraniu na następny tydzień terminów troniczną rozdziela między członków zadania, lub określa zespołu - tygodniowe opóźnienie swojego zastępcę Zbyt późne oddanie jednego z dokumentów Brak w pełni funkcjonalnego systemu Konieczność rozpoczęcia prac nad zniszczonym produktem na nowo Obniżona ocena z ZPP, ogólne opóźnienie prac projektem zebrań do możliwości zespołu, komunikacja elektroniczna między członkami zespołu Niezdolność do spełnienia wymagań z powodów technologicznych Zniszczenie któregoś z produktów projektu Realistyczne ocenianie możliwości technologicznych zespołu przez kierownika Regularne archiwizowanie produktów i częste tworzenie kopii zapasowych trzymanych na oddalonych fizycznie komputerach. Konkretnie - główne archiwum znajduje się na grupie dyskusyjnej, wraz z pojawieniem się tam nowych dokumentów, każdy z członków zapisuje go na własny dysk lokalny Kierownik tworząc plan pracy na następny tydzień przydziela na każde zadanie większą ilość czasu, niż wymagana, i często kontroluje postęp prac na czas zebrania. W przypadku braku kontaktu z kierownikiem obecne osoby wybierają zastępcę. wprowadzenie zmian w funkcjonalności i zmiana zakresu działalności systemu odtworzenie zniszczonego produktu z najbardziej aktualnego archiwum Zmiana terminów oddawania dokumentów, przydzielenie do danego dokumentu większej ilości osób 12 SOFTWARE DEVELOPMENT PLAN

15 4.4 Plan zamknięcia projektu Opis Skutki Przeciwdziałanie Gdy się zdarzy Błędy w dokumentach Konieczność Kierownik kontroli Szybkie i sprawne późniejszego jakości sprawdza wprowadzanie wprowadzania gruntownie każdy niezbędnych zmian i poprawek, możliwe, dokument przed jego poprawek że w wielu różnych oddaniem dokumentach 4.4 Plan zamknięcia projektu W ramach zamknięcia projektu zostaną wykonane następujące czynności: 1. Rewizja dokumentów - Kierownik 2. Nagranie dokumentów i oprogramowania na płytę CD 3. Przekazanie wyników pracy prowadzącemu zajęcia z ZPP 4. Dopełnienie formalności związanych z zaliczeniem przedmiotu. 5. Prezentacja multimedialna systemu 5 Plany procesów technicznych 5.1 Programowanie 5.2 Metody, narzędzia i stosowane technologie Narzędzia wykorzystywane przy tworzeniu dokumentacji: - darmowe edytory tekstu: emacs, vim, etc. Standardy dotyczące tworzenia dokumentacji - dokumentację tworzymy przy użyciu systemu L A TEX - używamy czcionek w standarcie ISO (latin 2) - dokumentacja będzie zgodna z procesem RUP, oparta na szablonach dokumentów dostarczonych przez prowadzącego zajęcia ZPP 5.3 Plan infrastruktury Projekt powstaje na domowych komputerach członków zespołu, oraz komputerach zapewnionych przez wydział MIM UW w laboratorium komputerowym. Sprzęt do prezentacji multimedialnej zostanie zapewniony przez dr Janusza Jabłonowskiego. Q-Group 13

16 5.4 Plan akceptacji produktu 6 Plany pomocnicze 6.1 Plan zarzadzania zmianami Wprowadzanie zmian do dokumentacji (produktów fazy Opracowanie) przez wyznaczonego do produkcji danego dokumentu i kierownika: - zapisania zmienionej wersji w nowym pliku dopisując do Historii zmian: datę i godzinę, krótki opis zmian, nazwisko zmieniającego - można szczegółowiej opisać zmiany w pliku ChangeLog - wysłać nową wersję spakowaną przy pomocy skryptu backup na grupę dyskusyjna, włączając opcję powiadamiający - poinformować kierownika i prowadzącego ZPP o zmianach, jeśli dokument został już oddany do oceny - przejrzeć wszystkie dokumenty zależne, w celu sprawdzenia spójności przez inne osoby: - Tworzy nową wersję dokumentów z wprowadzonymi zmianami, zaznaczając gdzie zostały wprowadzone zmiany i dodając do nazwy plików postfix * _niezatwierdzone. - Wysyła dokumenty na grupę dyskusyjną - Wysyła posta, w którym informuje tych członków zespołu, których zmiany dotyczą, o nowej wersji dokumentów. - członkowie zespołu zapoznają się ze zmianami - jeśli do następnego zebrania zespołu nie zostaną zgłoszone uwagi, dokumenty zaczynają obowiązywać - zostaje zabrany im postfix - wpp. dodaje się do nazw dokumentów postfix * _nieobowiązujące, oraz rozpoczyna się kolejna iteracja wprowadzania nowej wersji dokumentów przez zgłaszającego uwagi Wprowadzanie zmian do modułów (produktów fazy Budowa) - Do każdego modułu przydzielona jest odpowiedzialna za niego osoba - Zmiany w implementacji modułu następują wedle ustaleń odpowiedzialnej za niego osoby - Zmiany w interfejsie modułu wymagają poinformowania kierownika, który może uznać że: Wystarczy jeśli osoba wprowadzająca zmiany poinformuje wszystkich, których zmiany dotyczą Należy zainicjować burzę mózgów, nad problemem konieczności wprowadzania zmian 14 SOFTWARE DEVELOPMENT PLAN

17 6.2 Plan oceny - Każda zmiana w interfejsie musi zostać wpisana do dokumentacji, ponadto wprowadzający zmianę musi poinformować o niej wszystkich potencjalnie zainteresowanych członków zespołu 6.2 Plan oceny Ocena całości projektu, poszczególnych produktów, referatów leży w gestii prowadzącego zajęcia ZPP. Kierownik rozdziela przyznaną punktację pomiędzy członków zespołu. 6.3 Plan dokumentacji - Business Vision - Software Development Plan - Business Use Case - Use Case - Software Architecture Document - Acceptance Plan 6.4 Plan zapewnienia jakości 6.5 Plan rozwiazywania problemów 1. Fakt wystąpienia problemu zgłaszany jest kierownikowi 2. Kierownik zleca rozwiązanie problemu członkowi zespołu 3. W przypadku niepowodzenia zwoływane jest nadzwyczajne zebranie zespołu, gdzie przez burzę mózgów rozwiązywany jest problem 4. Kierownik wyznacza osobę do wykonania rozwiązania problemu lub wprowadza zmiany do harmonogramu 7 Inne plany 7.1 Plan zwoływania zebrań Kierownik podejmuje decyzję o zwołaniu zebrania. Po ustaleniu dogodnego dla wszystkich uczestników terminu, wysyła informację na grupę dyskusyjna. Q-Group 15

18 8 Historia zmian $Log: sdp.tex $ Revision /11/24 12:16:29 Cezary Tkaczyk Wersja ostateczna, chociaż aspekty dotyczące implementacji mogą jeszcze ulec zmianie Revision /11/15 7:50:20 Cezary Tkaczyk Wersja robocza, praktycznie wszystkie potrzebne rozdziały opisane Revision /11/08 7:49:15 Cezary Tkaczyk Niepełna wersja dokumentu 16 SOFTWARE DEVELOPMENT PLAN