Software Development Plan dla systemu USOSweb 2.0

Transkrypt

1 Software Development Plan dla systemu USOSweb 2.0 Adam Radziwończyk-Syta Karol Sobczak Marcin Koziński Grzegorz Paszt 4 czerwca

2 Spis treści 1 Wprowadzenie Cel Zakres Definicje Omówienie reszty dokumentu Omówienie projektu Cel i zakres projektu Założenia i zależności Produkty projektu Procedura zmian w planie projektu Organizacja projektu Struktura organizacyjna Kontakty zewnętrzne Zarzadzanie projektem Oszacowania Analiza punktów funkcyjnych Unadjusted Function Points Count Value adjustment factor Adjusted function point count Plan projektu Plan faz projektu Cele poszczególnych iteracji Wydania Zasoby Budżet Plan pierwszej iteracji Nadzór i kontrola projektu Plan zarządzania wymaganiami Plan zarządzania harmonogramem Plan kontroli jakości Plan raportów Plan zamknięcia projektu Plan zarzadzania ryzykiem 14 6 Plany procesów technicznych Metody, narzędzia i stosowane technologie Plan zarządzania zmianiami

3 6.3 Plan oceny Historia zmian 16 3

4 1 Wprowadzenie 1.1 Cel Celem dokumentu Software Development Plan jest szczegółowe opisanie planu pracy nad projektem USOSweb 2.0. Opisuje on harmonogram plan pracy nad projektem, organizację projektu, podział obowiązków i produkty, które zostaną wytworzone podczas realizacji projektu. 1.2 Zakres Niniejszy dokument dotyczy systemu USOSweb 2.0 przygotowywanego w ramach zajęć Inżynierii Oprogramowania w 2006/2007 przez zespół złożony z autorów tego dokumenty. Przygotowany został w zgodzie z i korzystając z dokumentów Wizja produktu USOSweb 2.0, Przypadki użycia systemu USOSweb 2.0 i Software Architecture Devolopment dla system USOSweb Definicje USOS Uniwersytecki System Obsługi Studiów, USOSweb webowy interfejs do USOSa, dający dostęp do zasobów studentom i pracownikom naukowym wydziału System system, którego ten dokument dotyczy USOSweb Omówienie reszty dokumentu Kolejne częsci dokumentu omawiają szczegółowo następujące zagadnienia: Sekcja 2 - zakres realizowanego projektu i jego produkty Sekcja 3 - organizacja zespołu uczestniczącego w projekcie i kontakty z zewnętrznymi osobami Sekcja 4 - podział projektu na iteracje i harmonogram projektu, oszacowania kosztów projektu Sekcja 5 - plan zarządzania ryzykiem w projekcie Sekcja 6 - opis stosowanych w trakcie realizacji projektu metod, procesów i narzędzi 4

5 2 Omówienie projektu 2.1 Cel i zakres projektu Celem projektu jest stworzenie rozbudowanego rozszerzenia (jednocześnie będącego samodzielnym systemem) USOSWeb. Nowy system o handlowej nazwie USOSWeb 2.0 ma wspierać dotychczasowe komponenty USOSWeb oraz udostępniać użytkownikom nowoczesną funkcjonalność społeczną. USOSWeb 2.0 jest skierowany głównie do studentów, jednakże będą go mogli wykorzystywać także pracodawcy poszukujący pracowników spełniających określone wymagania. 2.2 Założenia i zależności Czas na wykonanie projektu to trzy semestry akademickie. Jest to okres, w którym odbywają się przedmioty Inżynieria Oprogramowania oraz Zespołowy Projekt Programistyczny. W projekt zaangażowane są cztery osoby w ramach przedmiotu Inżynieria Oprogramowania. Projekt zakłada chociażby minimalną współpracę administratorów USOSWeb. Nie ma żadnego zewnętrzengo źródła finansowania, nie przewiduje się również zysków materialnych z wykonania projektu, więc budżet jest zerowy. Wersja beta projektu ukaże się w styczniu 2008 roku. 2.3 Produkty projektu Dokumenty, które powstały/powstaną w trakcie projektu Nazwa Planowana data ukończenia Wizja Przypadki użycia Plan architektury systemu Interfejs Oprogramowanie, które powstało/powstanie w trakcie projektu Applet Java obsługi kalendarza Nakładka do komunikacji z USOS-em Interfejs WWW systemu USOSWeb 2.0 5

6 2.4 Procedura zmian w planie projektu Zmiany w planie projektu są jak najbardziej możliwe. Aby ich dokonać, należy uzgodnić ich treść z członkami zespołu, po czym zostaną one zaakceptowane bądź odrzucone. Każdy członek zespołu powinień śledzić zmiany oraz być zaznajomionym z bieżącą wersją tego dokumentu. 3 Organizacja projektu Zespół pracujący nad projektem składa się z czterech osób. Nie planujemy angażowania dodatkowych osób podczas prac. 3.1 Struktura organizacyjna Funkcja Zadania Osoby Kierownik Nadzorowanie prac nad projektem, przestrzegania Marcin Koziński projektu harmonogramu i budżetu Analityk Analizowanie i projektowanie systemu Marcin Koziński, Grzegorz Paszt Adam Radziwończyk- Syta, Karol Sobczak Programista Implementacja systemu zgodnie z dokumentami Marcin Koziński, Grzegorz utworzonymi podczas analizy systemu Paszt, Adam Radziwończyk- Syta, Karol Sobczak Webdesigner Zaprojektowanie strony graficznej interfejsu Karol Sobczak Tester Przygotowywanie testów funkcjonalnych i Adam Radziwończyk-Syta integrujących Kontakty zewnętrzne Kontakty z opiekunem projektu i prodziekanem ds. USOS Marcin Koziński Osoba odpowiedzialna Utworzenie dokumentacji użytkownika Grzegorz Paszt za dokumentację 3.2 Kontakty zewnętrzne Zespół komunikuje się z także z Opiekunem projektu na ZPP, który kontroluje postęp realizacji projektu, a także z pełnomocnikiem Rektora ds. USOS odnośnie komunikacji z systemem USOS, możliwości integracji z nim i standardów bezpieczeństwa, które powinien spełniać USOSweb

7 4 Zarzadzanie projektem 4.1 Oszacowania Projekt zostanie zrealizowany bez wkładu finansowego w ramach Zespołowego Projektu Programistycznego. Zostanie ukończony w trakcie zimowego i letniego semestru 2007/2008, ponieważ chcemy, żeby pozwolił zaliczyć nam ZPP, który trwa w wymienionych ramach czasowych. Głównym punktem, kiedy nastąpi przeszacowanie harmonogramu będzie koniec semestru zimowego, kiedy będziemy mogli dokładnie się przyjrzeć jaką pracę udało się wykonać w trakcie jedengo semestru. Pomniejsze przeszacowania są też przewidywane około miesiąca przed końcem każdego z semestrów, kiedy konieczna będzie prawdopodobnie intesyfikacja prac. 4.2 Analiza punktów funkcyjnych Dokonamy teraz oszacowania pracochłonności projektu metodą punktów funkcyjnych Unadjusted Function Points Count Najpierw policzymy wartości dla funkcji jakie mają być dostępne w systemie: Funkcja ILF EIF EI EO EQ L A H L A H L A H L A H L A H Terminarz dodanie terminu 1 1 wyświetlenie terminarza 1 konfiguracja 1 1 Znajomi dodanie Znajomego 1 1 wyświetlenie danych Z. 1 1 Ogłoszenia dodanie 1 1 wyświetlenie 1 przeszukanie 1 Pliki wgranie 1 1 pobranie 1 wyszukanie 1 Opinie i komentarze dodanie 1 1 wyświetlenie 1 Inne wybór funkcji w menu 1 7

8 logowanie 1 1 autoryzacja 1 aktualizacja profilu 1 1 forum prywatne wiadomości ŁACZNIE: Kilka przykładowych uzasadnień: Konfiguracja terminarza zawiera prosty ILF, ponieważ jest to tylko uaktualnienie nieskomplikowanego rekordu, zaś dodanie terminu jest już średnio trudne, gdyż terminarze są ułożone w ciekawszą strukturę są związane z osobami, przedmiotami, grupami, lub jeszcze innymi mniej lub bardziej abstrakcyjnymi bytami; w swoim prywatnym terminarzu można chcieć ustawić widoczność danego zdarzenia; terminy mogą być stałe, lub powtarzane, np. co tydzień lub dwa tygodnie; mogą trwać przez kilka dni, lub tylko w wyznaczonych godzinach; być może czasem trzeba inaczej traktować zdarzenie przypadające w dzień wolny, etc. Podobnie ma się sprawa z EI: zmiana konfiguracji to wypełnienie prostego formularza, dodanie terminu wymaga najpierw zlokalizowanie odpowiedniego terminarza, wybranie dnia z kalendarza, przedziału czasowego i wielu dodatkowych możliwości. Jedyny EIF jest w wyświetleniu danych Znajomego, które wymaga skomunikowania się z USOSem. Przewidujemy, że interfejs wymiany danych z USOSem może być mało elastyczny, lub wręcz prowizoryczny, więc obsługa go będzie trudna. Forum ma trudniejsze EQ od Prywatnych Wiadomości, ponieważ na forum trzeba wyświetlać wiele wiadomości (postów, wpisów) jednocześnie, dzielić je na strony, itd. PW wymgają jedynie wyświetlenia pojedyńczego listu. Logowanie jest trudniejszym (od prostego, czyli tak naprawdę średnim) przypadkiem EI, gdyż należy zadbać o bezpieczeństwo tego procesu. Wgranie pliku też nie jest proste, bo nie zawsze plik może zostać wgrany (może być za duży, mieć zabronione rozszerzenie, użytkownik może mieć zakaz, itd.). UFPC = (9*7 + 1*10 + 1*15) + (1*10) + (8*3 + 3*4) + (6*5) + (1*3 + 3*4) = ( ) ( ) (3 + 12) = = Value adjustment factor Kategoria Uzasadnienie textbfwaga System complexity 12 Data communication System USOSweb jest system webowym, 5 com- plexity więc przesyłanie datych odgrywa ważną rolę, System wspiera kilka protokołów przesyłania danych 8

9 Distributed data processing complexity Perfomance complexity Heavily used configuration complexity Transaction rate complexity On-line date entry complexity End-user efficiency complexity On-line update complexity Complex processing complexity Reusability complexity Installation ease complexity Operational ease complexity Multiple sites complexity Facilitate change complexity rozproszony przetwarzanie danych jest wykonywane online i komunikacja odbywa się w obydwu kierunkach czas reakcji systemu jest ważny jedynie podczas godzin najwyższego obciążenia systemu implementacja systemu będzie w miarę niezależna od konfiguracji sprzętowej Input and Output complexity 12 Żadne transakcje biznesowe nie mają 0 wpływu na System Większość zadań systemu wymaga interaktywnego wprowadzania danych USOSweb 2.0 jako aplikacja dostępna online wymaga uwzględnienia dużego znacze- 4 nia ułatwień dla użytkowników Zakres danych, które podlegają update om 3 online jest przeciętny Application complexity 9 System musi zapewniać jedynie wysokie bezpieczeństwo 3 przetwarzania Kod reużywalny w zasadzie ograniczać się będzie do kodu modułu komunikacji z USO- Sem Podczas kodowania systemu należy brać pod uwagę konfigurację systemu, na którym obecnie jest uruchomiony USOS System powinien być odporny na niespodziewany awarie, więc będzie wspierał przywracanie i back-up y System jest przeznaczony do instalacji i użycia jedynie z USOSem MIM Nie będą podejmowane działania, które umożliwią łatwe zmiany struktury przechowywanych danych w Systemie (USOSweb 2.0 i tak pobiera sporą część danych z USOSa)

10 33 Complexity factor wynosi * 33 = Adjusted function point count Adjusted function point count wynosi 179 * 0.98 = Plan projektu Plan faz projektu Podział projektu na fazy Projekt zamierzamy zrealizować w dwóch iteracjach, po jednej w każdym semestrze. W każdej iteracji zamierzemy przeprowadzić typowe fazy: Analizę, Projektowanie, Budowę i Testy. Ponadto po drugiej iteracji zaplanowaliśmy Wdrożenie, ze względu na to, że System jest przewidziany do współpracy z innym systemem USOSem i spodziewamy się, że zespół odpowiedzialny za USOSa będzie chciał najpierw zobaczyć i ocenić końcowy efekt naszej pracy, zanim zdecyduje się na ewentualną integrację. Wykres faz Kamienie milowe i wydania Widoczne na wykresie dwa kamienie milowe ściśle wiążą się z wydaniami. Czerwony jest to prezentacja na koniec semestru zimowego. Zamierzamy wtedy przedstawić stabilną wersję demonstracyjną, pokazującą dwie najciekawsze funkcje Systemu, umieszczone w interfejsie jaki wykonamy już z myślą o całości systemu. Zielony oznacza ukończenie prac nad projektem, m.in. pokaz w pełni działającej i (mamy nadzieję) wdrożonej do pracy z USOSem wersji Systemu Cele poszczególnych iteracji W pierwszej iteracji chcemy zaprogramować dwie z funkcji, które bardziej odznaczają się ważnością, ciekawością i pomysłowością. W drugiej części tej iteracji chcemy też już opleść te fukncje w interfejs, który docelowo miałby służyć finalnej wersji Systemu. Uznamy tę iterację 10

11 za udaną, jeśli na jej koniec będziemy dysponowali stabilną wersją demonstracyjną, pokazującą dwie ważniejsze funkcje Systemu i przyjemny interfejs. W drugiej chcemy uzupełnić System o pozostałe przewidziane dla niego funkcje, dopracować i ulepszyć interfejs. Ponadto zamierzamy przeprowadzić dokładne testy Systemu pod różnymi kątami, także wydajności. Chcielibyśmy, żeby zakończyła się ona wdrożeniem Systemu do pracy z USOSem, jednak uznamy iterację za zakończoną sukcesem, jeśli stworzymy w jej czasie stabilną końcową wersję Systemu, przygotowaną do pracy z USOSem, ale niekoniecznie jeszcze uruchomioną Wydania Wersja Termin Opis demo Dwie sztandarowe funkcje (Terminarze i Ogłoszenia), sprawny interfejs, brak integracji funkcji z USOSem; wersja pokazowa. ostateczna Wszystkie funkcje działające i sprawne, dopracowany interfejs, zoptymalizowana wydajność, współpraca z USOSem (lub gotowość jej) Zasoby Plan zatrudnienia Członkowie zespołu (p. 3.1) będą wykonywać przewidziane dla nich zadania w ramach harmonogramu w dowolnych dniach tygodnia i w dowolnych godzinach tych dni, kiedy tylko będzie im na to pozwalała organizacja ich zajęć akademickich oraz plany pozanaukowe. W trakcie realizacji projektu, z powodu ograniczeń nałożonych na projekt przez regulamin ZPP, nie planujemy zatrudniania innych pracowników niż wymienieni powyżej. Plan szkoleń Wszyscy pracownicy biorący udział w projekcie zostali przeszkoleni podczas drugiego roku studiów Informatyki w zakresie stosowanych metod projektowych w stopniu wystarczającym do udziału w projekcie. Pracownicy powinni także we własnym zakresie uzupełnić wiedzę dotyczących stosowanych narzędzi (J2EE i JBOSS), by w terminie przewidzianym w harmonogramie można było przystąpić do budowy systemu Budżet Nie przwidujemy budżetu na realizację tego studenckiego projektu. Będziemy pracować w labie lub na swoich komputerach, nie mamy żadnych źródeł finansowania. 4.4 Plan pierwszej iteracji Pierwsza iteracja jest podzielona na następujące fazy: 11

12 Analiza i Projektowanie łączymy tutaj dwie fazy, które standardowo są osobno, ponieważ większość pracy przewidzianej na nie została wykonana w semestrze letnim 2006/2007 podczas zajęć z Inżynierii Oprogramowania; przewidujemy tylko przegląd utworzonej dokumentacji, drobne poprawki i ewentualne uzupełnienia; Budowa faza implementacji zaprojektowanych fukncji Systemu oraz interfejsu wraz z testami jednostkowymi do nich; Testy krótkie testy stworzonej części systemu, mające zapewnić stabilność i jak najlepszą możliwą do uzyskania w krótkim czasie jakość działających funkcji. Pierwsza iteracja kończy się prezentacją wersji demonstracyjnej. Oto plan rozbicia jej na poszczególne zadania: 12

13 A oto wykres wykorzystania zasobów (w tym wypadku: członków zespołu): Jak widać, programiści nie są ciężko obłożeni. Są to szacowania prawdopodobne a nie oczekiwane. Przewidujemy, że na początku semestru nie będziemy mieli motywacji, a na koniec czasu. 4.5 Nadzór i kontrola projektu Plan zarzadzania wymaganiami Jedyne wymagania zewnętrzne może postawić pełnomocnik ds. USOS. Zamierzamy zebrać kompletną listę wymagań w ciągu pierwszego miesiąca pierwszego semestru. Jeśli wymagania będą się zmieniać i uznamy, że nie jesteśmy w stanie ich spełnić, możliwe jest zrezygnowanie z wdrażania Systemu do pracy z USOSem, gdyż jest to opcjonalne. Wówczas System posłuży jedynie do zaliczenia ZPP Plan zarzadzania harmonogramem Przestrzegania harmonogramu będzie pilnował Kierownik projektu. W przypadku przekraczania terminów Kierownik będzie się starał przede wszystkim motywować wszystkich do wzmożonej pracy. Jeśli to zawiedzie, będziemy rezygnowali z różnych wymagań wobec projektu w pierwszej kolejności porzucimy plan wdrożenia Systemu do pracy z USOSem, gdyż jest to opcjonalne Plan kontroli jakości Kontrola jakości odbywa się poprzez przeprowadzanie testów jednostkowych, a później testów integracyjnych i jakościowych Plan raportów Nie będziemy generować do siebie żadnych formalnych pism. O wszystkim będziemy się informować na bieżąco podczas nieformalnych spotkań. Przewiduje się doraźne tworzenie jakichś raportów na wyraźne życzenie prowadzącego przedmiot ZPP. 4.6 Plan zamknięcia projektu Projekt zostanie uznany za zakończony gdy strona USOSWeb będzie dostępna publicznie. W tym momencie dwóch członków zespołu zostanie przydzielonych do administrowania stroną oraz wszelkiego rodzaju działań związanych z jej poprawnym funkcjonowaniem. Zajmą się 13

14 oni równierz archwizacją danych projektu. W tym celu zostaną utworzone trzy kopie plików z dwóch ostatnich kamieni milowych projektu, oraz trzy wersje poprzedzjące ostateczną. Pozostałych dwóch członków zespołu będzie miało za zadanie w przeciągu pierwszego miesiąca rozpropagować stronę wśród środowisk studenckich na wydziale. Po upływie miesiąca osoby te będą miały za zadanie dołaczyć do grupy administrującej stroną w związku z przewidywanym wzrostem liczby użytkowników. Zostanie wtedy również opublikowany raport dotyczący rozwoju serwisu i w razie potrzeby omawiający kolejne działania. 5 Plan zarzadzania ryzykiem Ryzyko Konsekwencje Przeciwdziałanie Plan działania w przypadku wystąpienia Choroba członka opóźnienie w harmonogramie Zrównoleglanie Podział obowiązków, wy- zespołu pracy spowoduje korzystanie części czasu minimalizację opóźnień buforowego na akomoda- w przypadku cję ryzyka wystąpienie ryzyka Ograniczenie czasu członków zespołu poprzez obciążenia przedmiotami Niewywiązywanie się członków zespołu z powierzonych zadań Brak umiejętności i doświadczenia zespołu w zakresie posługiwania się używanym technologiami (J2EE, JBOSS) Brak współpracy ze strony obsługi oryginalnego systemu USOS opóźnienie w harmonogramie niemożliwość zakończenia projektu Niska jakość produktu, spowolnienie prac nad projektem Możliwe opóźnienia w projekcie lub ograniczenie funkcjonalności systemu USOSWeb 2.0 Lepsza organizacja pracy, rozsądne zaplanowanie obciążeń podczas obydwu semestrów Kontrola postępów prac Poświęcenie części czasu wakacji 2007 na zapoznanie się z technologiami Maksymalne uniezależnienie się od tych części systemu USOS, do użycia których niezbędna jest współpraca z jego obsługą praca podczas przerw w roku akademickim, świadoma akceptacja opóźnienia terminu zakończenia projektu Kontakt z opiekunem projektem, ewentualne negocjacje zmniejszenia zakresu projektu Wymaganie od pracowników, by wolny czas podczas fazy planowania poświęcili na zapoznanie z używanymi narzędziami Próba obejścia problemu okrężną drogą, ewentualnie ograniczenie funkcjonalności 14

15 6 Plany procesów technicznych 6.1 Metody, narzędzia i stosowane technologie Metody, technologie i narzędzie stowane w programie obejmują: Rational Unified Process Unified Modeling Language - język modelowania Visual Paradigm - narzędzie CASE Open Source Requirements Management Tool - program do zarządzania wymaganiami SVN - system kontroli wersji L A TEX - system składu tekstu J2EE JBOSS - serwer aplikacji 6.2 Plan zarzadzania zmianiami Każda zmiana będzie musiała zostać przedyskutowania w obecności wszystkich członków zespołu. Decyzja o zmianie zostanie zapisana w osobnym dokumencie zawierającym historię ważnych decyzji i zmian. Ponadto wszystkie niezbędne poprawki zostaną naniesione na pozostałe dokumenty. 6.3 Plan oceny Ocena projektu odbędzie się w następujących fazach: 1. Ocena wewnętrzna - członkowie zespołu będą mieli za zadanie sprawdzić pełną funkcjonalność systemu, a następnie przeprowadzić symulowane testy obciążeniowe. 2. Zamknięta ocena zewnętrzna - do oceny projektu zostaną zaproszone osoby z wydziału (grupa maksymalnie 30 osób), każdej zostanie przydzielone konto i ich zadaniem będzie sprawdzenie czy system zapewnia dostateczną funkcjonalność, czy spełnia wymogi bezpieczeństwa oraz czy jego wygląd jest dobrze odbierany. 3. Ocena wydziału - reprezentant władz wydziału zostanie poproszony o ocene projektu, oraz gdy będzie ona pozytywna - o rozpatrzenie możliwości umieszczenia całego projektu pod patronatem wydziału. 4. Otwarta ocena zewnętrzna - pierwszy miesiąc działania projektu będzie formą oceny, na podstawie której sporządzony zostanie ostatni raport dotyczący projektu. Każdy użytkownik serwisu będzie mógł przesyłać swoje zastrzeżenia i propozycje. 15

16 7 Historia zmian $Log: 22 V 2007: Utworzenie dokumentu, dodano rozdziały Wprowadzenie i Omówienie projektu. 23 V 2007: Dodano rozdział Zarządzanie projektem i diagram Gantta. 27 V 2007: Dodano rozdziały Organizacja projektu i Plan Zarządzania ryzykiem. 31 V 2007: Analiza punktów funkcyjnych. 4 VI 2007: Ostateczne poprawki i uzupełnienia. $ 16