Studencka Pracownia Inżynierii Oprogramowania Zespół nr 2, IIUWR 2008/09. Bartłomiej Gałkowski, Marek Kembrowski, Tomasz Maciejewski.

Transkrypt

1 Studencka Pracownia Inżynierii Oprogramowania Zespół nr, IIUWR 00/0 Bartłomiej Gałkowski, Marek Kembrowski, Tomasz Maciejewski Zium System zarządzania komunikacją miejską Harmonogram Data Wersja Opis Autor Wersja początkowa Bartłomiej Gałkowski Poprawki dat Marek Kembrowski Zmiana formatu i poprawki Bartłomiej Gałkowski Szacowanie czasochłonności Bartłomiej Gałkowski Diagram Gantta, poprawki Bartłomiej Gałkowski

2 Spis treści 1. Szacowanie czasochłonności 1.1. Czynniki złożoności środowiska Czynniki złożoności technicznej Przypadki użycia Harmonogram 1. Szacowanie czasochłonności Szacowanie pracochłonności wykonamy używając metody Use Case Points []. Czas trwania produkcji otrzymujemy, dzieląc pracochłonność przez zakładaną liczbę programistów. Wynosi ona, jak napisano w kosztorysie, pięć. Omówimy poniżej wyróżniane w metodzie punktów funkcyjnych aspekty tworzenia oprogramowania w odniesieniu do naszego przedsięwzięcia. W nawiasach są umieszczone wartości przyporządkowane przez nas każdemu z punktów Czynniki złożoności środowiska Zaznajomienie z projektem (wartość ). Zakładamy, że systemy zarządzania komunikacją są na tyle rozpowszechnione, że nasi pracownicy zetknęli się już z nimi. Ponadto nie jest to dziedzina wymagająca wyczerpującej wiedzy specjalistycznej. Przesłanki te prowadzą do wniosku, że nasi pracownicy dobrze rozumieją cel przedsięwzięcia. Doświadczenie w tworzeniu aplikacji (wartość ). Do tworzenia aplikacji będą zatrudnieni programiści z kilkuletnim doświadczeniem i znajomością metodyki RUP. Doświadczenie w projektowaniu aplikacji obiektowych (wartość ). Zatrudnieni programiści wykazują się dobrą znajomością modelu obiektowego i umiejętnością projektowania diagramów w języku UML. Umiejętności głównego analityka (wartość ). Analityk naszego zespołu powinien wykazywać się doświadczeniem, profesjonalizmem oraz zainteresowaniem tematem komunikacji miejskiej. Motywacja (wartość ). Spodziewamy się, że zespół będzie wykazywać się przeciętną motywacją. Jedynym i najważniejszym bodźcem będzie wynagrodzenie. Stabilność wymagań (wartość ). Liczymy na wysoką stabilność wymagań. Systemy komunikacji miejskiej cechują się zrównoważonym i powolnym rozwojem. Nie przewidujemy też technicznego przełomu w dziedzinie transportu, mogącego zagrozić dotychczasowemu modelowi opisu połączeń (np. wprowadzenie wynajmowanych rowerów). Spodziewamy się natomiast sprawnej współpracy z MPK we Wrocławiu i innymi przewoźnikami. Ułatwi ona ustalenie wymagań. Pracownicy pracujący w niepełnym wymiarze (wartość 0). Zagrożenie to nie dotyczy naszego projektu, jako że zatrudnimy programistów w pełnym wymiarze.

3 Trudność języka programowania (wartość ). Język PHP jest jednym z pięciu najbardziej popularnych języków programowania. 1 Jest więc dobrze udokumentowany. Wykazuje duże podobieństwo do Javy i C/C++. Jest imperatywny, dynamicznie typowany i obiektowy. Czyni go to prostym do przyswojenia i stosowania dla programistów z doświadczeniem w innych często używanych językach. Podane argumenty pokazują, że jest to język względnie prosty w użyciu. 1.. Czynniki złożoności technicznej System rozproszony (wartość 0). Nasz system z założenia jest scentralizowany. Wydajność (wartość ). Jak oszacowano w Koncepcji ogólnej[1] system nie powinien przetwarzać więcej niż 000 żądań na dziennie. Stanowi to duże obciążenie jak na aplikacje internetową. Można także zakładać wzmożone obciążenie w krótkich okresach (np. przed świętami Bożego Narodzenia). Wydajność dla użytkownika końcowego (wartość ). Pisane przez nas oprogramowanie jest systemem czasu rzeczywistego. Jego maksymalne opóźnienie nie powinno przekraczać sekundy. Złożone przetwarzanie wewnętrzne (wartość ). System ten jest dość prosty, nie będą stosowane żadne złożone algorytmy teorii grafów. Ponowne użycie (wartość ). Kod tworzonej aplikacji będzie pisany tak, aby można było dodać dodatkowe funkcje lub zaimplementować go w innej aglomeracji. Łatwość w instalowania (wartość ). System będzie wdrażany przez wyszkolony personel. Jego łatwość użycia jest drugoplanowa. Łatwość użycia (wartość ). System powinna cechować wysoka prostota, estetyka i funkcjonalność. Przenośność (wartość ). Ponieważ piszemy aplikacje internetową, będzie można z niej skorzystać w każdym systemie obsługującym przeglądanie stron internetowych. Łatwość wprowadzania zmian (wartość ). Zakładamy, że system będzie mógł być rozbudowany w ograniczonym zakresie (np. o szukanie połączeń). Wysoce pożądana jest prostota konserwacji i budowa umożliwiająca szybkie znajdowanie błędów. Współbieżność (wartość 1). Do lepszego rozładowania obciążenia, serwer HTTP będzie stosował współbieżność. Nie będzie ona jednak uwzględniona w architekturze naszego oprogramowania. Zabezpieczenia specjalne (wartość ). W celu uwierzytelniania administratorów oraz zabezpieczenia przed atakami typu człowiek pośrodku (ang.man-in-the-middle) zastosowany będzie szyfrowany protokół (np. HTTPS). Zależność od zewnętrznych bibliotek (wartość 0). Nie spodziewamy się by stopień złożoności wymagał zastosowanie zewnętrznych bibliotek. Dodatkowe szkolenia użytkowników (wartość 1). Zamierzamy zbudować system łatwy w obsłudze i intuicyjny. W razie problemów pasażerowie powinni opierać się na dokumentacji. 1 Por.

4 1.. Przypadki użycia Niedostosowane wagi aktorów (wartość ). Według koncepcji ogólnej posiadamy aktorów: przewoźnika,pasażera i administratora. Wszyscy trzej są aktorami bardzo złożonymi, gdyż wymagają stworzenia graficznego interfejsu użytkownika. Wagi przypadków użycia (wartość 1). Powołujemy się na koncepcje ogólną. Mamy siedem prostych przypadków użycia. Dotyczą one użytkowników i przewoźników. Wszystkie sześć przypadków związanych z administratorami zaliczamy do złożonych. Przy takich uwarunkowaniach uzyskujemy 11 punktów funkcyjnych. Zakładamy pesymistyczny współczynnik produktywności 0 roboczogodzin na punkt. Nasza pracochłonność wynosi wtedy około 00 osobogodzin. Dla pięciu zatrudnionych programistów czas wytworzenia oprogramowania wyniesie prawie miesięcy.

5 . Harmonogram Id. Nazwa zadania Cz. trw. 1 Faza wstępna dn Negocjowanie warunków umowy z MPK dn Zbieranie informacji na temat wrocławskiego systemu komunikacji dn Wstępna charakterystyka uŝywanego oprogramowania i narzędzi dn Charakterystyka głównych cech produktu dn Wstępna identyfikacja profili uŝytkowników systemu dn Wstępny kosztorys dn Przedstawienie koncepcji i wstępnego kosztorysu 1 dzień Opracowanie przypadków uŝycia 10 dn 10 Wymagania funkcjonalne i niefunkcjonalne 10 dn 11 Wymagania dotyczące dokumentacji i systemu pomocy 10 dn 1 Faza projektowania 1 dn 1 Specyfikacja architektury oraz schemat produktu dn 1 Ustalenie wymaganego sprzętu, oprogramowania i baz danych 1 dn 1 Opracowanie logicznej struktury programowej części projektu 10 dn 1 Opracowanie połączeń i relacji między elementami struktury logicznej 10 dn 1 Standard formatowania kodu źródłowego dn 1 Sposób weryfikacji spełniania przez system wymagań dn 1 Weryfikacja architektury pod względem realizacji cech głównych dn 0 Weryfikacja uŝyteczności i ergonomii dn 1 Ogólne wytyczne dotyczące komunikacji z uŝytkownikiem dn Tworzenie reprezentacji graficznej głównych interfejsów 10 dn Opracowanie reprezentacji graficznej połączeń 10 dn Analiza najpopularniejszych protokołów sieciowych dn Wybór protokołów spełniających załoŝenia dn Analiza zagroŝeń systemu ze strony uŝytkowników dn Specyfikacja bazy danych dn Schemat funkcjonalny relacji w bazie danych 1 dn Ustalenie ostatecznego kosztorysu 10 dn 0 Ustalenie i uściślenie najczęściej uŝywanej terminologii dn 1 Faza implementacji dn Wytworzenie fragmentu kodu 0 dn Wytworzenie fragmentu dokumentacji uŝytkownika 1 dn Przetestowanie rezultatu pod względem zgodności z wymaganiami dn Oszacowanie niezawodności dn Testowanie przez zewnętrznych testerów 1 dn Przygotowanie kursów i materiałów szkoleniowych 1 dn Kolejne iteracje fazy implementacji 11 dn Faza wdraŝania 0 dn 0 Instalowanie systemu 10 dn 1 Organizacja szkoleń administratorów 1 dn Usuwanie błędów i wprowadzanie zmian dn Badania zadowolenia uŝytkowników dn Organizacja zaplecza technicznego, w tym dalszego usuwania błędów 1 dn Ocena realizacji przedsięwzięcia, uczenie się na błędach dn Ocena zgodności wykonanych prac z koncepcją systemu i specyfikacją 10 dn s p ś p n w c s p ś p n

6 Id n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p

7 Id n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p

8 Id n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p n w c s p ś p

9 Literatura [1] Bartłomiej Gałkowski, Marek Kembrowski, Tomasz Maciejewski: Zium - system zarządzania komunikacją miejską. Koncepcja ogólna. Wrocław, SPIO IIUWr 00. [] Karner G., Resource Estimation for Objectory Projects. Torshamnsgatan, Objective Systems SF AB, 1.