2021-01-22 19:25:32 +01:00
|
|
|
---
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
# 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)
|
|
|
|
|
|
|
|
|
|
- Odpalenie zapalnika elektrycznego
|
|
|
|
|
|
|
|
|
|
- Automatyczne wyzwolenie separacji za pomocą barometru w apogeum
|
|
|
|
|
|
|
|
|
|
- Wyzwolenie separacji na żądanej wysokości
|
|
|
|
|
|
|
|
|
|
- Konfiguracja/kontrola modułu:
|
|
|
|
|
|
|
|
|
|
- zmiana parametrów uruchomieniowych
|
|
|
|
|
|
|
|
|
|
- odczyt danych z flash
|
|
|
|
|
|
|
|
|
|
- czyszczenie pamięci 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
|
|
|
|
|
|
|
|
|
|
- czyszczenie pamięci 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
|
|
|
|
|
|
|
|
|
|
- Wyświetlanie testów historycznych w postaci live
|
|
|
|
|
|
|
|
|
|
- Zintegrowania aplikacji webowej z REST API
|
|
|
|
|
|
|
|
|
|
- Eksport testów do plików (json, excel)
|
|
|
|
|
|
|
|
|
|
- Eksport trajektorii lotu rakiety do pliku KML (Google earth)
|
|
|
|
|
|
|
|
|
|
- Profil użytkownika, możliwość zmiany nazwy użytkownika, imienia,
|
|
|
|
|
nazwiska, e-maila, hasła
|
|
|
|
|
|
|
|
|
|
## Aplikacja desktopowa
|
|
|
|
|
|
|
|
|
|
- Wyświetlanie danych z testów live (wykresy)
|
|
|
|
|
|
|
|
|
|
- Wyświetlanie lokalizacji za pośrednictwem Google Maps
|
|
|
|
|
|
|
|
|
|
- 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"
|
|
|
|
|
|
|
|
|
|
- Zintegrowanie 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
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
|
- Typescript
|
|
|
|
|
|
|
|
|
|
- .NET Core
|
|
|
|
|
|
|
|
|
|
- C-.05em
|
|
|
|
|
|
|
|
|
|
## Aplikacja serwerowa - REST API
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
|
- Szybka obsługa zapytań
|
|
|
|
|
|
|
|
|
|
- Rozszerzalna
|
|
|
|
|
|
|
|
|
|
- Niezawodna
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
|
- Czytelne
|
|
|
|
|
|
|
|
|
|
- Uporządkowane
|
|
|
|
|
|
|
|
|
|
- Tworzone i utrzymywane ze sztuką
|
|
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
- Przekazanie plików instalacyjnych do aplikacji desktopowej
|
|
|
|
|
|
|
|
|
|
- Na koniec drugiego semestru klient otrzyma system w wersji beta.
|
|
|
|
|
|
|
|
|
|
# Kryteria akceptacji projektu dla I semestru prac
|
|
|
|
|
|
|
|
|
|
## Wymagane
|
|
|
|
|
|
|
|
|
|
- Ukończenie zdefiniowanych funkcjonalności z listy wymagań
|
|
|
|
|
funkcjonalnych na pierwszy semestr
|
|
|
|
|
|
|
|
|
|
- Brak błędów utrudniających korzystanie z aplikacji
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
|
- Produkt został oddany w czasie
|
|
|
|
|
|
|
|
|
|
- Produkt został wdrożony na domenę publiczną
|
|
|
|
|
|
|
|
|
|
- Produkt został przekazany klientowi
|
|
|
|
|
|
|
|
|
|
## 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 - DevOps
|
|
|
|
|
|
|
|
|
|
- Implementacja backendu aplikacji
|
|
|
|
|
|
|
|
|
|
- Stworzenie bazy danych na potrzeby aplikacji API
|
|
|
|
|
|
|
|
|
|
- Wdrożenie i dockeryzacja aplikacji
|
|
|
|
|
|
|
|
|
|
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 - 01.2021):
|
|
|
|
|
|
|
|
|
|
- Uaktualnienie dokumentacji i Trello
|
|
|
|
|
|
|
|
|
|
- Kontynuacja prac programistycznych nad aplikacjami
|
|
|
|
|
|
|
|
|
|
- Kontynuacje prac programistycznych nad komputerem pokładowym
|
|
|
|
|
|
|
|
|
|
- Rozpoczęcie 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ę
|
