Inżynierski Projekt Zespołowy

Transkrypt

1 Inżynierski Projekt Zespołowy Projekt Funkcji Systemu 1. Wymagania funkcjonalne i niefunkcjonalne Prace nad specyfikacją powinny się koncentrowad na funkcjonalnościach, interakcji systemu z użytkownikiem, wykrywaniu kategorii błędów na które system powinien byd szczególnie odporny, uwarunkowaniach środowiskowych. Na tym etapie nie powinno się koncentrowad na doborze technologii, tworzeniu projektu czy struktury aplikacji. Czynności wchodzące w skład zbierania wymagao to: Identyfikacja aktorów definiowanie typów przyszłych użytkowników oraz innych sprawców działao w systemie. Identyfikacja scenariuszy określanie elementów funkcjonalności systemu. Scenariusze powstają w wyniku porozumienia z klientem i służą jako platforma współpracy twórców i użytkowników. Ich analiza pozwala na lepsze zrozumienie dziedziny aplikacyjnej oraz jej ewentualną korektę. Identyfikacja przypadków użycia kompletne przedstawienie funkcjonalności aplikacji poprzez generalizację scenariuszy. Przypadek użycia odwzorowuje abstrakcję opisującą szczegółowe scenariusze danego typu. Wymagania niefunkcjonalne określają aspekty niezwiązane z funkcjonalnościami. Przykładowo można wyróżnid następujące kategorie wymagao niefunkcjonalnych (Jacobson, et. al, 1999): Użytecznośd określana jako łatwośd uczenia się obsługi programu przez użytkowników. Obejmuje intuicyjny interfejs, łatwośd wyszukiwania funkcji, łatwośd przygotowania danych wejściowych i interpretacji otrzymanych wyników. Dodatkowo kategoria ta może zawierad wymagania dotyczące zakresu i konstrukcji pomocy on-line, kolorystyki czy czcionki. Niezawodnośd zdolnośd systemu do pełnego działania w określonych warunkach i w określonym czasie. Określid ją można jako średni czas działania aplikacji pomiędzy awariami, odpornośd na ataki z zewnątrz, radzenie sobie z niepoprawnymi danymi, działanie pod dużym obciążeniem środowiskowym, bezpieczeostwo. Wydajnośd rozumianą jako czas reakcji systemu, przepustowośd, dostępnośd oraz dokładnośd. Wspieralnośd określana jako łatwośd wprowadzania zmian po wdrożeniu systemu. Obejmuje ona dodawanie nowych funkcjonalności, usuwanie usterek, konserwacja, implementacja nowych technologii, regionalizacja (dostosowanie do innych języków, jednostek miar, formatów dat, itd.), przenośnośd pomiędzy różnymi platformami sprzętowymi i programowymi. Inny model (FURPS+) zakłada dodatkowe kategorie wymagao: implementacyjne obejmujące narzędzia, języki programowania i platformy sprzętowe; interfejsu narzucane często przez systemy zewnętrzne i standardowo przyjęte formaty; operacyjne związane z czynnościami administracyjnymi oraz konfiguracyjnymi; pakietowe, zwykle rozumiane jako sposób dostarczenia i instalacji aplikacji; prawne związane z certyfikacją, licencjonowaniem, zgodności z przepisami i normami.

2 Wymagania niefunkcjonalne są ogólnie traktowane jako ograniczenia i wymagania jakościowe. Warto zauważyd, że wymagania dotyczące budżetu i harmonogramowania również zalicza się do wymagao niefunkcjonalnych. 2. Hierarchiczny model funkcji systemu Hierarchiczny model funkcji SI powinien obejmowad całą aplikację i pokazywad jej modułową budowę. Jest to diagram, na podstawie którego będą budowane diagramy DFD. System 1. Moduł A 2. Moduł B 3. Moduł Moduł N 1.1 Podmoduł C 2.1 Podmoduł E 4.1 Podmoduł H 1.2 Podmoduł D Podmoduł F Podmoduł I Podmoduł G 4.2 Podmoduł J

3 Przykład: System zarządzania aukcją System Zarządzania Aukcją 1. Zarządzanie kontem 2. Obsługa licytacji 3. Zarządzanie aukcją 4. Moduł wyszukiwania 5. Moduł administracji 6. Moduł komunikacji 1.1 Obsługa logowania 2.1 Licytacja standarodwa 3.1 Wystawienie przedmiotu 4.1 Wyszukiwanie aukcji 5.1 Raportowanie 6.1 Wystawienie opinii Logowanie 2.2 Licytacja kup teraz 3.2 Wycofanie przedmiotu 4.2 Wyświetlenie szczegółów aukcji Wystawienie raportu finansowego 6.2 Wysłanie informacji Przypomnienie hasła 2.3 Obsługa płatności 3.3 Zmiana danych aukcji Wystawienie raportu o użytkownikach 1.2 Tworzenie konta 5.2 Zgłaszanie błęd 1.3 Edycja konta 5.3 Blokada konta użytkownika 1.4 Usunięcie konta

4 3. Identyfikacja zdarzeo Dla każdego typu konta użytkownika w systemie należy utworzyd tabelkę opisującą identyfikację zdarzeo w systemie. Tabelkę tę należy wykorzystad w konstrukcji diagramów DFD. Przykład: Konto gośd Lp Zdarzenie Obiekt Dokument 1 Odczyt strony startowej Gośd 2 Odczyt aktualności Gośd 3 Złożenie zamówienia Gośd Formularz: Imię, nazwisko, telefon, PESEL, adres, kod pocztowy, poczta, adres 4 Potwierdzenie zamówienia Gośd Potwierdzenie zamówienia przesłane na podany Wiadomośd przesłana na adres podczas zamówienia 4. Specyfikacja procesów Każda funkcja powinna byd opisana w tabelce. Przykład: Nazwa funkcji Opis Dane wejściowe Źródło danych Wynik Uwagi 2.1 Licytacja standardowa Możliwośd kupienia produktu przez użytkowników ID kupującego + dane sprzedającego + dane aukcji + cena Kupujący + baza danych aukcji + baza danych sprzedających Wybranie najlepszej oferty Kolejna oferta musi byd wyższa od pozostałych, Aukcja kooczy się w określonym czasie 5. Diagramy DFD Należy utworzyd diagramy poziomu 0 (diagram kontekstowy), poziomu 1 (diagram systemowy) oraz poziomów 2 i ewentualnie 3. Każdy diagram powinien mied dodatkowo opis tekstowy. 6. Diagramy BPMN Diagramy powinny byd utworzone dla wszystkich procesów poziomu x.x. Dla każdego z procesu należy utworzyd jeden diagram (BPMN standard oraz BPMN swim). Jednak liczba diagramów obu typów powinna byd zbliżona. 7. Diagram przypadków użycia Diagram przypadków użycia to graficzne przedstawienie przypadków użycia, aktorów oraz związków między nimi. Są graficznym przedstawieniem przypadków użycia, aktorów oraz związków między nimi, przedstawiają działanie systemu z pt. widzenia aktora. Pozwalają na zrozumienie zadao

5 systemu, wymagao i praw dostępu. Pojedynczy diagram składa się z przypadków użycia, aktorów, oraz zależności pomiędzy nimi. Pojedynczy przypadek użycia to specyfikacja ciągu akcji i ich wariantów, które system może wykonad poprzez interakcje z aktorami. Aktorzy to sprawcy zdarzeo (niekoniecznie użytkownicy), którzy powodują uruchomienie danego przypadku użycia w systemie (osoby korzystające z systemu, osoby potrzebne do działania systemu, elementy zewnętrzne dostarczające lub pobierające dane). Związki na diagramie: - Asocjacja najbardziej popularny związek; opisuje powiązania pomiędzy aktorem a przypadkiem użycia; asocjacja najczęściej jest linią ciągłą, nieskierowana - co oznacza jej dwukierunkowośd; zwykle nie podaje się tu nazwy. Dodatkowe opcje asocjacji to: liczebnośd związku (np. uczestnik może dokonad rejestracji tylko 1 raz (1:1)); klient może kupid wiele produktów (1: 0..n) (ale dany produkt może byd kupiony tylko przez 1 klienta) kierunkowośd związku (rzadko używana asocjacja skierowana wskazuje kierunek odpowiedzialności w systemie) - Zależności pomiędzy przypadkami : <<include>> zawieranie; obowiązkowe wywołanie (przypadek a zawiera przypadek wywoływany (zawierany) b); oznaczenie związku to linia przerywana skierowana od przypadku a do przypadku b <<extend>> - opcjonalne rozszerzenie (przypadek bazowy a rozszerza (może, ale nie musi wywoład) przypadek b; oznaczenie związku to linia przerywana skierowana od przypadku b do przypadku a - Generalizacja uogólnienie (np. kierownik ma prawo do uruchamiania tych samych przypadków użycia co pracownik, ale poza tym może uruchamiad dodatkowe) Przykład:

6 Inżynierski Projekt Zespołowy