Zespół io07-7e: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak. Projekt SZOP SDP

Transkrypt

1 Zespół io07-7e: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak Projekt SZOP SDP

2 Spis treści 1 Wprowadzenie Cel 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 Zarzadzanie projektem Oszacowania Plan projektu Plan faz projektu Cele szczególnych iteracji Czas Wydania Harmonogram projektu Zasoby Budżet Plany iteracji Podstawowa Obsługa Schematów Obiegu Nadzór i kontrola projektu Plan zarządzania wymaganiami Plan zarządzania harmonogramem Plan kontroli jakości Plan raportów Plan zarządzania ryzykiem Plan zamknięcia projektu Metody, narzędzia i stosowane technologie Plan akceptacji produktu Plan zarządzania zmianami Plan dokumentacji Plan zapewnienia jakości i jej oceny Plan zarządzania podwykonawcami

3 1 Wprowadzenie Celem niniejszego dokumentu jest przedstawienie planu wykonania Systemu Zarządzania Obiegiem Plików SZOP. Zawiera on wszystkie elementy m.in. oszacowanie kosztów, czasu wykonania projektu, plany iteracji, poczynione założenia, przewidywane ryzyka, sposoby radzenia sobie w sytuacjach krytycznych. 1.1 Cel projektu SZOP - aplikacja ta ma przyśpieszyć pracę i ułatwić funkcjonowanie średniej wielkości firmom poprzez stworzenie inteligentnego systemu obiegu dokumentów. 1.2 Założenia i zależności Ważnym czynnikiem mającym wpływ na harmonogram tworzenia projektu są targi oprogramowania biurowego, na których zobowiązani jesteśmy zaprezentować demo systemu, w tym szczególnie interfejs użytkownika. Targi te odbędą się 4-5 sierpnia Zakładamy również dostępność eksperta od schematów obiegu w terminie od do Produkty projektu Nazwa Data Wizja Przypadki użycia SAD PlanTestów Demo systemu wraz z interfejsem użytkownika Dokumentacja Administratora Wersja beta systemu Aplikacja Klienta Aplikacja Serwera Dokumentacja użytkownika Gotowy i wdrożony system Procedura zmian w planie projektu 1. Zgłoszenie propozycji zmian do Project Managera 2. Dyskusja zespołu nad zmianami 3. Zatwierdzenie zmian 4. Uaktualnienie planu projektu 3

4 5. Szybkie wprowadzenie zmian w życie 2 Organizacja projektu 2.1 Struktura organizacyjna Osoby zarządzające projektem: Kierownik projektu Kierownik zespołu programistów Kierownik zespołu testerów Osoba do spraw marketingu 2.2 Kontakty zewnętrzne Do stworzenie oprogramowania w szacowanym czasie potrzebować będziemy następujących osób z zewnątrz: Pracownicy firmy klienta. Pracownicy firmy dostarczającej OCR. Specjalista-konsultant od schetów obiegu i sieci Petriego. 2.3 Role i zadania Do obowiązków kierownika projektu należą: Nadzór nad członkami zespołu Cotygodniwe odbieranie raportów Zatwierdzenie propozycji zmian w projekcie Nadzór nad wprowadzaniem istotnych zmian w dokumentacji oraz implementacji Ustalenie standardów kodowania Rozdzielenie pracy i większych zadań poszczególnym zespołom Podejmowanie kroków ratujących projekt w sytuacjach krytycznych Do obowiązków kierownika zespołu programistów należą: 4

5 Nadzorowanie pracy programistów Rozdzielanie pracy nad poszczególnymi modułami pomiędzy programistów Dotrzymywanie terminów Składanie raportów z pracy zespołu Informowanie zespołu o błędach wykrytych przez zespół testerów Kontrola jakości wytwarzanego kodu Kontrola jakości dokumentacji Do obowiązków kierownika zespołu testerów należą: Rozdzielenie i nadzorowanie pracy testujących Opracowywanie testów o dużej skutezności Informownaie zespołu programistów o wykrytych błędach Do obowiązków szefa do spraw marketingu należą: Opracowanie biznesplanu Zgłoszenie i przygotowanie zespołu do wzięcia udziału w targach oprogramowania Opracowanie kampanii reklamowej promującej nasz produkt 3 Zarzadzanie projektem 3.1 Oszacowania Oszacowanie złożoności metodą punktów funkcyjnych: 1. Internal Logical File (ILF) baza dokumentów A 10 baza użytkowników L 7 baza grup L 7 baza schematów obiegu A External Interface File (EIF) 5

6 3. External Input (EI) szukanie dokumentów L 3 zarządzanie schematem obiegu H 6 usprawnianie schematu obiegu H 6 automatyczne tworzenie schematu obiegu H 6 zarządzanie grupami L 3 zarządzanie użytkownikami L 3 wprowadzanie dokumetów H 6 edycja dokumentów A 4 zarządzanie uprawnieniami A 4 tworzenie projektu L 3 odzyskiwanie wersji L 3 4. External Output (EO) wyświetlanie statystyk A 5 wyświetlanie dokumentu A 5 wysyłanie powiadomień (sms/ ) H 7 5. External Inquiry (EQ) wyświetlanie informacji o dokumencie L 3 wyświetlanie informacji o grupie L 3 wyświetlanie informacji o użytkowniku L 3 wyświetlanie stanu dokumentu A 4 6. The fourteen general system characteristics of FPA Data Communications 0 Distributed Data Processing 0 Performance 5 Heavily Used Configuration 4 Transaction Rate 4 Online Data Entry 5 End-User Efficiency 5 Online Update 0 Complex processing 5 Reusability 5 Installation ease 1 Operational Ease 4 Multiple Sites 5 Facilitate Change 1 Stąd wychodzi ostatecznie ( * 44) * 111 = 121 punktów funkcyjnych To oszacowanie powinno dobrze pokrywać część projektu związaną z interfejsami, obsługą bazy danych, gdyż pod tymi względami SZOP stanowi typowy projekt biurowy. Z uwagi na 6

7 niestandardowość optymalizacji schematów obiegu jej złożnoność prawdopodobnie jest niedostatecznie uwzględniona w tej metodzie, stąd zakładamy dodatkowy czas na jej implementację, uwględniony w harmonogramie poniżej. 3.2 Plan projektu Plan faz projektu Faza Analiza Projektowanie Iteracja 1: Pierwotna wersja interfejsu Iteracja 2: Ostateczna wersja interfejsu Iteracja 3: Postawowa obługa schemtów obiegu Iteracja 4: Zaawansowana obs. schematów obiegu Iteracja 5: Aplikacja serwera Iteracja 6: Aplikacja klienta Iteracja 7: Interfejs administratora Iteracja 8: Konfiguracja bazy danych Iteracja 9: Implementacja modelu Iteracja 10: Adapter edytora Testy Wdrożenie okres czasu 4 tygodnie 5 tygodnie 5 tygodni 4 tygodnie 6 tygodni 4 tygodnie 4 tygodnie 6 tygodni 3 tygodnie 2 tygodnie 6 tygodni 4 tygodnie 4 tygodnie 5 tygodni Cele szczególnych iteracji 1. Iteracja 1: gotowa wstępna wersja interfejsu. 2. Iteracja 2: gotowy interfejs. 3. Iteracja 3: moduł do podst. weryfikacji schematów obiegu 4. Iteracja 4: moduł do zaawansowanej weryfikacji schematów obiegu 5. Iteracja 5: gotowe moduły aplikacji serwera 6. Iteracja 6: gotowe moduły aplikacji klienta 7. Iteracja 7: interfejs administratora 8. Iteracja 8: współpracująca z systemem baza danych 9. Iteracja 9: model spełniający zadaną funkcjonalność 10. Iteracja 10: dodatki do najpopularniejszych edytorów 7

8 3.2.3 Czas Zgodnie z naszymi szacowaniami punktów funkcyjnych przewidywany czas na wykonanie projektu przez naszą firmę wynosi około roku Wydania Planujemy dwa wydania częściowe naszego systemu: jedno na Targi Oprogramowania Biurowego, drugie przeznaczone na prezentację dla klienta. Na koniec projektu powstanie jedno wydanie ostateczne Harmonogram projektu 8

9 9

10 3.2.6 Zasoby Plan zatrudnienia Kierownik projektu przez cały czas trwania projektu 1 Projektant pierwszy miesiąc (ewentualne późniejsze konsultacje) 2 Kierownik zespołu programistów przez cały czas 1 Programista cały czas trwania projektu 4 Programista - specjalista od baz danych iteracja 8 1 Głowny tester od trzeciego miesiąca 1 Zwykły tester od trzeciego miesiąca 2 Konsultant do sieci Petriego w czasie iteracji dotyczącj obiegu dokumentów 1 Osoba od spraw marketingu w końcowej fazie projektu 1 Obsługa biura przez cały czas 1 Plan szkoleń 1. szkolenie z zakresu LeTexa (1 dzień) 2. szkolene z SVNa (1 dzień) 3. szkolenie z UMLa (2 dni) 4. szkolenie z zakresu J2EE ze szczególnym uwględnieniem JDBC 5. inne szkolenia pogłębiające wiedzę na temat wykorzystywanych technologii (w czasie trwania projektu, w zależności od potrzeb) Budżet Przewidujemy, że na stworzenie naszego projektu potrzebujemy około 500 tys. zł. Pieniądze te pochodzą cześciowo z zaliczki otrzymanej od klienta oraz kredytu zaciągniętego przez firmę. 3.3 Plany iteracji 10

11 3.3.1 Podstawowa Obsługa Schematów Obiegu 11

12 3.4 Nadzór i kontrola projektu Plan zarzadzania wymaganiami Zastosujemy następującą procedurę zarządzania zmianami wymagań: Klient zgłasza propozycję zmiany Project Manager omawia złożoność zmiany z wybranymi członkami zespołu Project Manager negocjuje z klientem ew. zwiększenie kosztów lub wydłużenie terminów Ostateczną decyzje podejmuje Project Manager w porozumieniu z zarządem naszej firmy W przypadku dojścia do porozumienia zleca wykonanie zmiany wybranym programistom Plan zarzadzania harmonogramem Za zarządzanie harmonogramem odpowiada Project Manager. Kontroluje on na bieżąco postęp prac poszczególnych zespołów. W razie opóźnień w realizacji harmonogramu może on przydzielić dodatkowe osoby do grupy spóźniającej się lub zaktualizować harmonogram realizacji przedsięwzięcia (biorąc pod uwagę kamienie milowe - w szczególności Targi Oprogramowania Biurowego) Plan kontroli jakości Po każdej iteracji odbywają się kompleksowe testy stworzonego właśnie modułu. Tworzony kod ma być rzetelnie dokumentowany. Każdy składany przez zespół raport ma być kontrolowany pod względem merytorycznym i zgodności z rzeczywistością Plan raportów Mniejsze raporty zdajemy na koniec każdego tygodnia, a na koniec każdego miesiąca (wraz z końcem iteracji) zdajemy duży raport. 12

13 3.5 Plan zarzadzania ryzykiem Przewidywane ryzyka Sposoby przeciwdziałania W razie wystapienia Krótka niedyspozycja członka zespołu Brak Rozdzielamy pracę tej osoby między innych członków zespołu Długa niedyspozycja członka Brak Zatrudnienie dodatkowej zespołu osoby Utrata danych Posiadanie aktualnej wersji Powrót do ost. zarchiwizowanej systemu w kilku miejscach. wersji Zapisywanie poprzednich wersji Niedoszacowanie terminów Uwzględniony margines Renegocjacja terminów błędu Niedoszacowanie kosztów Brak zbędnych wydatków Renegocjacja kontraktów Ekspert od systemów obiegu i Wcześniejsze spisanie umowy Poszukiwanie nowego eksperta sieci Petriego jest niedostępny 3.6 Plan zamknięcia projektu Około kwietnia 2008 planujemy ogłoszenie przetargu na zakup serwera naszego systemu Początek prac nad zamknięciem projektu planujemy na Początkowo zostanie zainstalowa platforma systemowa serwerów i wymagane aplikacje zewnętrzne. Planujemy wdrożenie systemu na 2-gą połowę czerwca 2008, zostawiając sobie czas na ewentualne korekcje problemów z wdrożeniem na pierwszą połowę lipca. Równocześnie w czerwcu 2008 planujemy rozpoczęcie i przeprowadzenie testów wdrożeniowych Po 15 lipca skończy się kontrakt o pracę testerów, a programiści zostaną przeniesieni do innego zadania firmy. Project Manager zajmie się archiwizacją dokumentacji samego projektu oraz jego wdrożenia. 20 lipca przedłoży on zarządowi raport o wnioskach z projektu dla metodologii stosowanej w firmie oraz o tempie i cenie realizacji punktów funkcyjnych. 3.7 Metody, narzędzia i stosowane technologie Do modelowania biznesowego oraz tworzenia dokumentacji wykorzystamy standard UML oraz narzędzia Umbrello i Umlet, do zadań planowania zastosujemy Open Workbench Interfejs użytkownika zostanie wykonany w technologii JSwing, dla zapewnienia wieloplatformowości. Projekt systemu powien być wykonany zgodnie ze sztuką programowania obiektowego, dopuszczamy oczywiście pewne uproszczenia i naruszania standardów projektowania obiektowego, jeśli okażą się zbyt restrykcyjne lub zbędne dla danego elementu oprogramowania. Planujemy utrzymywanie wysokiej jakości kodu poprzez refaktoryzacje. Chcemy, aby kod był 13

14 możliwie samodokumentujący się. Do programowania wykorzystamy platformę Eclipse. Do testów jednostkowych planujemy wykorzystać narzędzie JUnit. Dokumentację użytkownika planujemy wydać w postaci stron html zamieszonych na stronie internetowej projektu SZOP. Dokumentacja administratora powstanie w postaci tekstowej. 3.8 Plan akceptacji produktu Po zakończeniu fazy projektowania planujemy walidację stworzonej dokumentacji podczas spotkania z klientem. Planujemy wtedy szczegółowe omówienie przypadków użycia związanych z biznesowymi potrzebami klienta r. planujemy prezentację wersji beta systemu SZOP klientowi celem uzyskania wstępnej akceptacji produktu. 3.9 Plan zarzadzania zmianami W kwestii zarządzsnia zmianami planujemy zastosować system SVN Plan dokumentacji W ramach początkowej dokumentacji projektu planujemy stworzenie minimalnego zestawu dokumentów w postaci: 1. Wizja 2. Przypadki użycia 3. Plan testów 4. SAD 5. SDP Wierzymy, że w ten sposób przy początkowych fazach implementacji będziemy mieć wystarczającą wiedzę o systemie. Programiści poradzą sobie bez zbyt szczegółowej dokumentacji poprzez utrzymywanie wysokiej jakości kodu Plan zapewnienia jakości i jej oceny Wydajność - Od planowane są testy wydajnościowe. Sprawdzimy przetwarzaną ilość tranzakcji na sekundę oraz czasu operacji na schematach obiegu. Jeśli wyniki okażą się niedostateczne programistom zostaną zlecone odpowiednie poprawki wskazane przez testerów przy użyciu profiler a. 14

15 Jakoś interfejsu użytkownika - Jakoś wykonania interfejsu zostanie oceniona przed targami oprogramowania oraz przy prezentacji beta wersji systemu klientowi. Ocenimy czas nauki wykonywania operacji systemowych oraz średni czas ich realizacji dla grupy obeznanych z systemem użytkowników( stanowic ją bedą testerzy i ew. programiści). Jeśli okaże się niedostateczna w zaplanowanym w harmonogramie terminie zostaną wykonane poprawki w lutym 2008r. W kwestii bezpieczeństwa planujemy zatrudnienie zewnętrznej firmy w celu wykonania odpowiednich testów oraz zgloszenia poprawek. Wyniki tych testów powinniśmy zgodnie z umową otrzymać do 15 maja 2008 r, aby mieć czas na ew. poprawki projektu. Pojemność - Plaujemy zakup stosownie pojemnego serwera bazy danych, ocenimy ilość przechowywanych encji dzieląc pojemność dysku serwera przez średni rozmiar encji oraz towarzyszących jej informacji w bazie danych Plan zarzadzania podwykonawcami Po zakończeniu fazy projektowania rozpiszemy przetarg na system OCR, termin jego dostarczenia wraz ze specyfikacją API ustalamy na 10 marca W grudniu 2007 roku planujemy kontrolę podwykonawcy (test zgodności z systemem), aby zapewnić czas na ewentualną jego zmianę. 15