DPRI_doc_20-21/Przybylski/awionika/wymagania_projektowe.md

500 lines
11 KiB
Markdown
Raw Permalink Normal View History

---
author:
- Wojciech Kubiak
- Piotr Józefowicz
- Sebastian Wawrzyn
title:
- Dokument wymagań projektowych
---
# Elementy składowe projektu (produkty projektu)
## Semestr I
- Aplikacja webowa
- Komputer pokładowy (MVP)
- Aplikacja serwerowa - REST API (WEB)
- Relacyjna baza danych
- Prototyp interfejsu użytkownika aplikacji webowej
- Repozytorium git zawierające kod aplikacji, API, elektroniki
- Tablica projektowa -- Trello
## Semestr II
- Komputer pokładowy
- Nadajnik
- Odbiornik
- Wizytówka
- Aplikacja webowa
- Aplikacja desktopowa
- Aplikacja serwerowa lokalna
- Baza danych NoSql
- Repozytorium git zawierające kod aplikacji, API, elektroniki
- Tablica projektowa -- Trello
# Granice projektu
- Produkty zawarte:
- 1\. Wyszczególnione produkty projektu
- Funkcjonalności nie zawarte:
- Integracja z systemem APRS, wiele urządzeń lokalizacyjnych ma tę
funkcję, jednak zaimplementowanie jej jest zbyt czasochłonne.
- Integracja z innymi komputerami pokładowymi, format danych różni
się w zależności od komputera.
# Lista wymagań funkcjonalnych
## Komputer pokładowy:
- Dokonywanie pomiarów telemetrycznych (barometr, żyroskop,
akcelerometr)
- Zapis danych na flash (format tekstowy)
- Wyzwolenie separacji za pomocą timera
- Odpalenie zapalnika elektrycznego
- Automatyczne wyzwolenie separacji za pomocą barometru
- Konfiguracja/kontrola modułu:
- zmiana parametrów uruchomieniowych
- odczyt danych z flash
## Nadajnik/Lokalizator
- Lokalizacja GPS oraz redundantny system prędkości wysokości
przyspieszenia
- Komunikacja bezprzewodowa LORA (połączenie jednokierunkowe)
- Konfiguracja/kontrola modułu:
- zmiana parametrów uruchomieniowych
- odczyt danych z flash
## Aplikacja internetowa
- Logowanie za pomocą Auth0
- Wizytówka koła:
- informacje o kole
- formularz kontaktowy
- prezentacja projektów koła
- Zarządzanie użytkownikami na koncie administratora:
- dodawanie i usuwanie użytkowników
- zmiana danych użytkownika
- nadawanie i odbieranie uprawnień użytkownikom
- Dodawanie pomiarów z pliku (json, csv)
- Wyświetlanie danych z testów (wykresy)
- Przegląd danych historycznych
- Zintegrowania aplikacji webowej z REST API
- Profil użytkownika, możliwość zmiany nazwy użytkownika, imienia,
nazwiska, emaila, hasła
## Aplikacja desktopowa:
- Wyświetlanie danych z testów live (wykresy)
- Wyświetlanie lokalizacji za pośrednictwem Google Maps
- Wyświetlenie informacji tekstowych z komputera pokładowego
- Konfigurowanie modułów elektronicznych
- Odczyt/Zapis danych z modułów elektronicznych
- Wysyłanie testów na serwer
- Zapis pomiarów w plikach json
## Aplikacja serwerowa, REST API:
- Dodanie serwisów REST pozwalających na operacje wymienione w punkcie
"Aplikacja internetowa"
- Dodanie serwisów REST pozwalających na operacje wymienione w punkcie
"Aplikacja desktopowa"
- Zintegrowania API z bazą danych
- Wdrożenie aplikacji na środowisko testowe
- Wdrożenie aplikacji na środowisko produkcyjne
## Elektronika naziemna (odbiornik):
- Odbieranie danych od komputera pokładowego (LORA)
- Przekazywanie danych do serwera za pomocą REST API
- Przekazywanie danych do kolejnych urządzeń za pomocą Seriala
- Przekazywanie danych do kolejnych urządzeń za pomocą Bluetooth
- Konfiguracja/kontrola modułu:
- zmiana parametrów uruchomieniowych
# Lista wymagań niefunkcjonalnych
## Komputer pokładowy:
- Bezpieczny w użyciu
- Prosty w użyciu
- Niezawodny
- Dokładny
- Z czytelnym, przejrzystym kodem
- Technologie:
- Arduino
- C++
- FreeRTOS
## Nadajnik/Lokalizator
- Bezpieczna w użyciu
- Prosta w użyciu
- Niezawodny
- Dokładny
- Z czytelnym, przejrzystym kodem
- Technologie:
- Arduino
- C++
- FreeRTOS
## Elektronika naziemna (odbiornik):
- Bezpieczna w użyciu
- Prosta w użyciu
- Niezawodny
- Ładnie obudowana
- Z czytelnym, przejrzystym kodem
- Zintegrowana z REST API - wysyła dane telemetryczne
- Technologie:
- Arduino
- C++
## Aplikacja internetowa (frontend):
- Wytworzona z użyciem nowoczesnych standardów
- Single Page Application
- Responsywna
- Intuicyjna w obsłudze
- Technologie:
- Vue.js
- Typescript
## Aplikacja desktopowa:
- Wytworzona z użyciem nowoczesnych standardów
- Single Page Application
- Responsywna
- Intuicyjna w obsłudze
- Zaprojektowana według najnowszych standardów .NET
- Używa nowych technologii i podejść programistycznych
- Z czytelnym i przejrzystym kodem
- Szybka obsługa zapytań
- Zintegrowana z elektroniką naziemną oraz pozostałymi modułami
- Technologie:
- Vue.js
- Electron
- Typescript
- .NET Core
- C#
## Aplikacja serwerowa - REST API:
- Używa bazy danych NoSql
- Zaprojektowana według najnowszych standardów .NET
- Używa nowych technologii i podejść programistycznych
- Z czytelnym i przejrzystym kodem
- Szybka obsługa zapytań
- Technologie:
- .Net Core
- Docker
## Baza danych:
- Technologie:
- NoSql
## Prototyp aplikacji internetowej przetestowany przez użytkowników:
- Technologie:
- Adobe XD
## Tablica projektowa - Trello:
- Historia wymagań funkcjonalnych (User stories)
- Historia prac zdefiniowana zadaniami
- Lista wymagań funkcjonalnych zaplanowanych na przyszłość
- Lista zadań zaplanowanych na przyszłość
## Repozytorium zawierające kod aplikacji, API oraz elektroniki
- Technologie:
- GitHub
# Mierzalne wskaźniki wdrożeniowe
## Semestr I
- System zostanie przekazany w wersji testowej alpha.
- System zostanie zasilony danymi z symulacji lotu rakiet oraz danymi
historycznymi testów silników
## Semestr II
- System zostanie udostępniony w domenie internetowej i będą z niego
korzystać członkowie koła (około 20 osób)
- Wizytówka koła będzie oglądana przez ludzi chcących się dowiedzieć
czegoś o kole.
- System zostanie zasilony danymi z testów silników oraz rakiet.
- Przekazanie plików instalacyjnych do aplikacji desktopowej
- Na koniec drugiego semestru klient otrzyma system w wersji testowej
beta.
# Kryteria akceptacji projektu dla I semestru prac
## Wymagane
- Ukończenie zdefiniowanych funkcjonalności z listy wymagań
funkcjonalnych na drugi semestr
- Brak błędów utrudniających korzystanie z aplikacji
- Czy produkt został oddany w czasie
## Oczekiwane
- Wykonanie produktu zgodnie z ustalonymi wymaganiami odnośnie
technologii
## Planowane
- Zawieranie testów jednostkowych, integracyjnych, oraz czy spełniają
swoje zadanie
# Kryteria akceptacji projektu dla II semestru prac
## Wymagane
- Ukończenie zdefiniowanych funkcjonalności z listy wymagań
funkcjonalnych na drugi semestr, przetestowanie aplikacji pod kątem
użytkowym przez testerów (klientów końcowych)
- Brak błędów utrudniających korzystanie z aplikacji
- Czy produkt został oddany w czasie
## Oczekiwane
- Wykonanie produktu zgodnie z ustalonymi wymaganiami odnośnie
technologii
## Planowane
- Zawieranie testów jednostkowych, integracyjnych, oraz czy spełniają
swoje zadanie
# Organizacja pracy zespołu
Strona zespołu projektowego:
- Wojciech Kubiak - Product Owner
- Implementacja systemów wbudowanych
- Zarządzanie dokumentacją
- Komunikacja z klientem - czynny udział w kole
- Piotr Józefowicz - Scrum Master
- Implementacja frontendu
- Projektowanie prototypu interfejsu użytkownika
- Sebastian Wawrzyn
- Implementacja backendu aplikacji
- Stworzenie bazy danych na potrzeby aplikacji API
Praca jest wykonywana w metodyce SCRUM w tygodniowych sprintach. Kod
źródłowy trzymany jest na repozytorium na Githubie. Do podziału pracy i
śledzenia progresu używamy aplikacji Trello
# Ryzyka projektowe
## Ryzyka ze względu na zasoby:
- Odejście członka implementującego stronę serwerową - trudności w
ukończeniu aplikacji serwerowej
- Odejście członka implementującego stronę frontendową - trudności w
ukończeniu aplikacji
- Odejście członka implementującego systemy wbudowane - trudności w
ukończeniu aplikacji
- Określone ramy czasowe (semestry) na stworzenie produktu
## Inne:
- Nieporozumienia na linii zespół a klient wynikające z nieznajomości
pojęć domenowych lub nieporozumienia dotyczące funkcjonalności czy
innych rzeczy
- Nieporozumienia w zespole dotyczące rozwiązań implementacyjnych,
architektury, funkcjonalności lub używanych technologii
- Brak odpowiedniego zaangażowania w projekt ze strony zespołu,
wybranych członków zespołu
- Nagły brak wsparcia dla lub przerwanie rozwijania wykorzystywanej
technologii lub narzędzia - konieczność implementacji od nowa, lub
kontynuowanie implementacji w nieużywanym/źle zaprojektowanym
narzędziu, bibliotece
- Napięty termin, nakład obowiązków związanych z uczelnią oraz sprawy
prywatne, mogą negatywnie wpłynąć na pracę nad aplikacją
- Niestandardowy temat projektu, mogą pojawić się nieoczekiwane
trudności (rocket science)
# Kamienie milowe
- I faza, I semestr (02.2020 - 07.2020):
- Przygotowanie prototypu aplikacji
- Przygotowanie backlogu dla projektu w systemie Trello,
opracowanie funkcjonalności, user stories
- Rozpoczęcie prac programistycznych nad aplikacją
- Rozpoczęcie prac programistycznych nad komputerem pokładowym 1.0
- Testowanie komputera pokładowego
- Ukończenie MVP aplikacji i komputera pokładowego
- Poddanie MVP testom funkcjonalnym
- II faza, II semestr(10.2020 - 02.2021):
- Uaktualnienie dekumentacji i Trello
- Rozpoczęcie prac programistycznych nad aplikacjami
- Kontynuacje prac programistycznych nad komputerem pokładowym
oraz rozpoczecie prac nad nadajnikiem i odbiornikiem
- Testowanie komputera pokładowego oraz elektroniki naziemnej
- Ukończenie aplikacji wraz ze wszystkimi zdefiniowanymi
funkcjonalnościami
- Integracja aplikacji z elektroniką
- Testy integracyjne
- Wdrożenie aplikacji na publiczną domenę