From 048eea333eff6ff1e4cc438430bf012ee2a07613 Mon Sep 17 00:00:00 2001 From: Sebastian Wawrzyn Date: Fri, 22 Jan 2021 19:25:32 +0100 Subject: [PATCH] Electron update Auth0 and Electron production conflict --- Przybylski/awionika/wizja_projektu.md | 727 +++++++------ Przybylski/awionika/wymagania_projektowe.md | 1025 +++++++++---------- 2 files changed, 873 insertions(+), 879 deletions(-) diff --git a/Przybylski/awionika/wizja_projektu.md b/Przybylski/awionika/wizja_projektu.md index 7683104..252e733 100644 --- a/Przybylski/awionika/wizja_projektu.md +++ b/Przybylski/awionika/wizja_projektu.md @@ -1,364 +1,363 @@ ---- -author: -- Wojciech Kubiak -- Piotr Józefowicz -- Sebastian Wawrzyn -title: -- Dokument wizji dla projektu Awionika do rakiet sondażowych ---- - -# Executive summary - -Dokument dotyczy projektu realizowanego w ramach przedmiotu projekt -inżynierski. Niniejszy dokument służy przedstawieniu przeznaczenia -tworzonego systemu, jego głównych cech i przyjętych założeń. Grupą -docelową dla projektu jest koło naukowe na politechnice poznańskiej PUT -RocketLab, zajmujące się budową rakiet i silników rakietowych. Potrzebny -jest komputer pokładowy do rakiety oraz aplikacje umożliwiające obsługę -testów rakiet i silników. Nasz projekt ma dostarczyć: - -- Aplikację desktopową pozwalająca wyświetlać dane na żywo z testów, - konfigurować ustawienia modułów komputera pokładowego oraz - zapisywać/usuwać dane z pamięci podręcznej modułów. - -- Komputer pokładowy posiadający układ wyzwalający separację oraz - zbierający dane telemetryczne o locie, które będą mogły być - przekazywane na żywo do aplikacji poprzez nadajnik i odbiornik. - -- Aplikację webową służącą jako baza danych testów oraz odgrywającą - rolę wizytówki koła - -# Cel i grupa docelowa - -Grupą docelową dla projektu jest koło naukowe na Politechnice -Poznańskiej PUT RocketLab. Koło zajmuje się budową rakiet i silników -rakietowych oraz rozwija systemy awioniczne i naziemne do ich -testowania. Potrzebny jest komputer pokładowy do rakiety, który będzie -odpowiadał za jej lot, zapisywanie danych z tego lotu, oraz lokalizację -rakiety po jej wylądowaniu. Potrzebna jest również aplikacja, która -będzie pełniła funkcję kontrolera lotów/testów. Takie testy generują -dużą liczbę danych, które ciężko uporządkować więc potrzebne jest też -miejsce, w którym będzie można je porządkować i wyświetlać w przejrzysty -sposób. Koło nie posiada też strony internetowej - tak zwanej wizytówki, -która ma budować rozpoznawalność w internecie i pomóc w kontakcie -przyszłym kandydatom na członków koła.\ -Projekt oprócz komputera pokładowego będzie się składał z dwóch -aplikacji -- aplikacji webowej oraz aplikacji desktopowej. Aplikacja -desktopowa ma odgrywać rolę kontrolera testów. To, że aplikacja jest -desktopowa, wynika z faktu, że testy zazwyczaj wykonywane są w miejscach -bez dostępu do internetu. Aplikacja webowa będzie pełniła funkcję -wizytówki oraz bazy danych testów. Członkowie koła będą posiadali login -i hasło do aplikacji, gdzie będą katalogowane dane historyczne z testów. -Dane będzie można eksportować w wygodnym formacie, a także wyświetlać w -formie wykresów i tabelek z danymi. Strona będzie miała możliwość -wprowadzenia danych ręcznie, jednak preferowaną opcją będzie dodawanie -danych przez aplikację desktopowa, która to zrobi w sposób -zautomatyzowany. Aplikacja desktopowa będzie umożliwiała wyświetlanie -danych z testów rakiet oraz silników na żywo. Po teście dane będą -przekazywane do aplikacji webowej, jeśli będzie dostęp do internetu. -Jeśli nie będzie dostępu, to dane zostaną zapisane w pamięci komputera i -przekazane od razu po podłączeniu komputera do Internetu. Aplikacja -desktopowa ma również dać możliwość konfiguracji modułów elektroniki -komputera pokładowego rakiety oraz odczytywania i zapisywania z nich -danych. Pobrane dane będą od razu przekazywane do chmury tak jak w -przypadku testu na żywo. Będzie również możliwa zmiana konfiguracji tych -modułów-zmiany ustawień parametrów programu na danym module (np. ilość -bitów na sekundę podczas wysyłania danych, częstotliwość, moc anteny), -są to parametry, które muszą być zmieniane podczas czasu życia modułu. -Ta funkcjonalność ma na celu zapewnić większe bezpieczeństwo podczas -zmiany tych parametrów. Parametry nie będą zmieniane poprzez wgranie -nowego kodu tylko przez aplikacje, dzięki temu na samym urządzeniu nie -trzeba będzie zmieniać kodu źródłowego.\ -Klientowi zależy na tym, aby pozyskać z rakiety dane, które pozwolą -sprawdzić, czy rakieta osiągnęła oczekiwane parametry lotu zgodne z -wcześniejszą symulacją takie jak apogeum, prędkość, liczba macha czy -przyspieszenie. W tym celu muszą dokonać pomiarów fizycznych za pomocą -odpowiednich czujników takich jak akcelerometr, barometr, magnetometr -czy żyroskop, a następnie zapisać te dane i wyświetlić je w czytelnej -formie w celu ich analizy. Komputer pokładowy będzie umożliwiał zebranie -powyższych danych, a także wyzwolenie separacji/spadochronu w dwóch -różnych konfiguracjach: poprzez automatyczne wykrycie spadku swobodnego -(apogeum). Rakieta będzie też wyposażona w lokalizator, który będzie -umożliwiał odnalezienie rakiety po lokalizacji GPS wysłanej za pomocą -komunikacji bezprzewodowej LORA. - -# Rynek - -Wyposażenie pokładowe rakiety (awionika) składa się głównie z dwóch -części: komputera pokładowego i lokalizatora. Komputery pokładowe -znajdujące się na rynku mają wysoką cenę i większość z nich, nie -oferuje, aplikacji do zbierania danych, przez co robi się z nimi bałagan -i trzeba dbać samemu o to, by te dane katalogować. Gotowe lokalizatory, -mimo że zaawansowane również są bardzo drogie. - -## Przykłady produktów na rynku - -- Dużym zainteresowaniem na świecie cieszą się amerykańskie - [EggTimery](http://eggtimerrocketry.com/home/altimeters-av-bay/). - Posiadają one wiele różnych konfiguracji komputerów oraz - lokalizatorów. Mają jednak one dość wysokie ceny modułów i nie - oferują zintegrowanej aplikacji, która umożliwiałaby analizę danych, - musimy korzystać z osobnych programów. - -- Dostępne są [niemieckie komputery - pokładowe](https://www.rocketronics.de/shop/de/altimax-g3-standard.html?fbclid=IwAR2Btg-xkFvGJoPM6sU9-zkdCB5SZMVawdttTxnr6m8iG2iS46GtkmWs8Fc) - firmy Rocketronics oferujące wysoką jakość danych oraz dokładną - separację. Ich aplikacja nie umożliwia podglądu danych na żywo. Nie - ma w nich lokalizatorów i mają wysoką cenę. - -- [Lokalizator - Featherweight](https://www.featherweightaltimeters.com/featherweight-gps-tracker.html) - (koszt to 610-2000 zł) - wysoka cena, zawiera aplikację, ale do tego - potrzebny jest jeszcze komputer pokładowy.  - -- Jeden z najtańszych i najpopularniejszych sposobów (przynajmniej w - Polsce) na lokalizację rakiety polega na używaniu taniego - [lokalizatora](https://abc-rc.pl/product-pol-7625-Lokalizator-GPS-TK102B-Tracker-GPS-Sledzenie-w-WWW.html), - który wysyła podstawowe dane telemetryczne dzięki modułowi GPS i - GSM. Nie są to jednak produkty przeznaczone konkretnie do rakiet i - nie mogą zostać zintegrowane z komputerem pokładowym.  - -- Nowością jest komputer pokładowy - [Signal-R2](https://bps.space/shop/signal-r2) z aplikacją na telefon - (koszt to ok 1400 zł). Aplikacja dostępna na platformy android oraz - iOS jest zintegrowana z komputerem pokładowym. Cały system - komunikacji jest oparty na Bluetooth, co daje zasięg 10 metrów, - dlatego nie można używać aplikacji do odczytów danych na żywo - podczas lotu. Aby uzyskać szerszy dostęp do dokumentacji, kodów - źródłowych i informacji na temat projektu trzeba dodatkowo - miesięczne płacić za subskrypcje na specjalnej platformie Patronite. - -# Opis produkt - -## Aplikacja webowa - -- wizytówka koła - -- dane z testów będzie można zapisywać na serwerze w celu stworzenia - historii testów - -- eksport danych GPS w formacie KML (trajektoria lotu) - -- eksport danych telemetrycznych do Excel'a - -- import danych pomiarowych z pliku - -- wyświetlenie danych historycznych (z testów) - -- wyświetlenie danych historycznych w formie live (z testów) - -- wyszukiwanie testu po nazwie i dacie - -- kategoryzacja danych telemetrycznych (historia testów) przypisana do - testu - -## Aplikacja desktopowa - -- pomiary z rakiety obrazowane na żywo: - - - wykres prędkości od czasu, - - - wykres przyspieszenia od czasu, - - - wykresy orientacji XYZ, - - - wykres wysokości i wychylenia w osiach XYZ od czasu, - - - wyświetlenie lokalizacji GPS na mapie (Google Maps) - -- obrazowane danych z hamowni na żywo - - - wykres ciągu do czasu - - - wykres ciśnienia do czasu - -- dane po teście rakiety czy silnika będą zapisywane na serwerze - -- zgrywania/usuwanie danych z modułów elektronicznych - -- zmiana konfiguracji modułów elektronicznych - -## Elektronika - -- dokonywanie pomiarów podczas lotu (prędkość, przyspieszenie, - wysokość, wychylenia w osiach XYZ)  - -- lokalizacja GPS oraz pomiary wysyłane do stacji naziemnej za - pośrednictwem komunikacji bezprzewodowej LORA  - -- wykrycie apogeum (spadku swobodnego) pozwalające wyzwolić - separacje/spadochron - -- wyzwolenie separacji, spadochronu poprzez odpalenie zapalnika - elektrycznego  - -- przesyłanie danych do stacji naziemnej przez moduł komunikacyjny  - -- odbieranie danych przez odbiornik - -- odpalenie drugie spadochronu na określonej wysokości - -- przekazywanie danych do aplikacji desktopowej - -- zapisywania danych do pamięci modułu - -- odczytywanie danych z pamięci modułu - -- zmiana konfiguracji modułu - -# Zakres i ograniczenia - -## Skład zespołu - -- Wojciech Kubiak - systemy wbudowane - arduino, c++, FreeRTOS, python - -- Sebastian Wawrzyn - backend - .NET Core, C# , Docker, NoSql - -- Piotr Józefowicz - frontend - Vue.js, typescript - -## 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ę - -## Harmonogram - -MVP produktu zostanie wypracowane i przedstawione do końca czerwca 2020 -roku, zawierać będzie funkcjonalności takie jak: - -- Komputer pokładowy 1.0: - - - Dokonywanie pomiarów telemetrycznych - - - Zapis danych na kartę SD - - - Wyzwolenie separacji za pomocą timera - - - Odpalenie zapalnika elektrycznego - -- Aplikacja internetowa (frontend): - - - Stworzenie konta użytkownika, logowanie - - - Dodawanie testów z pliku - - - Wyświetlanie danych z testów - - - Przegląd danych historycznych - - - Zintegrowania aplikacji webowej z REST API - -- Aplikacja serwerowa, REST API: - - - Dodanie serwisów REST pozwalających na operacje wymienione w - punkcie "Aplikacja internetowa" - - - Zintegrowania API z bazą danych - - - Wdrożenie aplikacji na środowisko testowe - -Druga wersja produktu wypracowana i oddana do stycznia 2021 roku, -obejmować będzie: - -- Wszystkie funkcjonalności zdefiniowane w MVP - -- Komputer pokładowy 2.0: - - - Układ wyzwolenia separacji - - - Komunikacja z nadajnikiem - - - Konfiguracja modułu - - - Zapis danych na pamięć flash - -- Nadajnik/Lokalizator: - - - Lokalizacja GPS oraz redundantny system prędkości wysokości - przyspieszenia - - - Komunikacja bezprzewodowa LORA - - - Konfiguracja modułu - -- Elektronika naziemna/Odbiornik: - - - Konfiguracja modułu - - - Odbieranie danych od komputera pokładowego (LORA) - - - Przekazywanie danych do serwera za pomocą REST API - - - Przekazywanie danych do kolejnych urządzeń za pomocą Seriala - -- Aplikacja internetowa (frontend): - - - Wyświetlanie i gromadzenie danych historycznych testów - - - Wyświetlanie testów historycznych w postaci live - - - Eksport testów do plików - - - Widok podsumowania testu - - - Profil użytkownika - -- Aplikacja desktopowa: - - - Wyświetlanie danych z testów live (wykresy) - - - Wyświetlanie lokalizacji za pośrednictwem Google Maps - - - Konfigurowanie płytki - - - Odczyt danych z płytki - - - Usuwanie danych z płytki - -- 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" - - - Wdrożenie aplikacji na środowisko produkcyjne - -Ograniczeniem projektu jest hosting, nie wiadomo czy politechnika -udostępni nam domenę oraz otworzy porty na zewnątrz. +--- +author: +- Wojciech Kubiak, Piotr Józefowicz, Sebastian Wawrzyn +title: "**Dokument wizji dla projektu Awionika do rakiet**" +--- + +# Executive summary + +Dokument dotyczy projektu realizowanego w ramach przedmiotu projekt +inżynierski. Niniejszy dokument służy przedstawieniu przeznaczenia +tworzonego systemu, jego głównych cech i przyjętych założeń. Grupą +docelową dla projektu jest koło naukowe na politechnice poznańskiej PUT +RocketLab, zajmujące się budową rakiet i silników rakietowych. Potrzebny +jest komputer pokładowy do rakiety oraz aplikacje umożliwiające obsługę +testów rakiet i silników. Nasz projekt ma dostarczyć: + +- Aplikację desktopową pozwalająca wyświetlać dane na żywo z testów, + konfigurować ustawienia modułów komputera pokładowego oraz + zapisywać/usuwać dane z pamięci podręcznej modułów. + +- Komputer pokładowy posiadający układ wyzwalający separację oraz + zbierający dane telemetryczne o locie, które będą mogły być + przekazywane na żywo do aplikacji poprzez nadajnik i odbiornik. + +- Aplikację webową służącą jako baza danych testów oraz odgrywającą + rolę wizytówki koła + +# Cel i grupa docelowa + +Grupą docelową dla projektu jest koło naukowe na Politechnice +Poznańskiej PUT RocketLab. Koło zajmuje się budową rakiet i silników +rakietowych oraz rozwija systemy awioniczne i naziemne do ich +testowania. Potrzebny jest komputer pokładowy do rakiety, który będzie +odpowiadał za jej lot, zapisywanie danych z tego lotu, oraz lokalizację +rakiety po jej wylądowaniu. Potrzebna jest również aplikacja, która +będzie pełniła funkcję kontrolera lotów/testów. Takie testy generują +dużą liczbę danych, które ciężko uporządkować więc potrzebne jest też +miejsce, w którym będzie można je porządkować i wyświetlać w przejrzysty +sposób. Koło nie posiada też strony internetowej - tak zwanej wizytówki, +która ma budować rozpoznawalność w internecie i pomóc w kontakcie +przyszłym kandydatom na członków koła.\ +Projekt oprócz komputera pokładowego będzie się składał z dwóch +aplikacji -- aplikacji webowej oraz aplikacji desktopowej. Aplikacja +desktopowa ma odgrywać rolę kontrolera testów. To, że aplikacja jest +desktopowa, wynika z faktu, że testy zazwyczaj wykonywane są w miejscach +bez dostępu do internetu. Aplikacja webowa będzie pełniła funkcję +wizytówki oraz bazy danych testów. Członkowie koła będą posiadali login +i hasło do aplikacji, gdzie będą katalogowane dane historyczne z testów. +Dane będzie można eksportować w wygodnym formacie, a także wyświetlać w +formie wykresów i tabelek z danymi. Strona będzie miała możliwość +wprowadzenia danych ręcznie, jednak preferowaną opcją będzie dodawanie +danych przez aplikację desktopowa, która to zrobi w sposób +zautomatyzowany. Aplikacja desktopowa będzie umożliwiała wyświetlanie +danych z testów rakiet oraz silników na żywo. Po teście dane będą +przekazywane do aplikacji webowej, jeśli będzie dostęp do internetu. +Jeśli nie będzie dostępu, to dane zostaną zapisane w pamięci komputera i +przekazane od razu po podłączeniu komputera do Internetu. Aplikacja +desktopowa ma również dać możliwość konfiguracji modułów elektroniki +komputera pokładowego rakiety oraz odczytywania i zapisywania z nich +danych. Pobrane dane będą od razu przekazywane do chmury tak jak w +przypadku testu na żywo. Będzie również możliwa zmiana konfiguracji tych +modułów-zmiany ustawień parametrów programu na danym module (np. ilość +bitów na sekundę podczas wysyłania danych, częstotliwość, moc anteny), +są to parametry, które muszą być zmieniane podczas czasu życia modułu. +Ta funkcjonalność ma na celu zapewnić większe bezpieczeństwo podczas +zmiany tych parametrów. Parametry nie będą zmieniane poprzez wgranie +nowego kodu tylko przez aplikacje, dzięki temu na samym urządzeniu nie +trzeba będzie zmieniać kodu źródłowego.\ +Klientowi zależy na tym, aby pozyskać z rakiety dane, które pozwolą +sprawdzić, czy rakieta osiągnęła oczekiwane parametry lotu zgodne z +wcześniejszą symulacją takie jak apogeum, prędkość, liczba macha czy +przyspieszenie. W tym celu muszą dokonać pomiarów fizycznych za pomocą +odpowiednich czujników takich jak akcelerometr, barometr, magnetometr +czy żyroskop, a następnie zapisać te dane i wyświetlić je w czytelnej +formie w celu ich analizy. Komputer pokładowy będzie umożliwiał zebranie +powyższych danych, a także wyzwolenie separacji/spadochronu w dwóch +różnych konfiguracjach: poprzez automatyczne wykrycie spadku swobodnego +(apogeum). Rakieta będzie też wyposażona w lokalizator, który będzie +umożliwiał odnalezienie rakiety po lokalizacji GPS wysłanej za pomocą +komunikacji bezprzewodowej LORA. + +# Rynek + +Wyposażenie pokładowe rakiety (awionika) składa się głównie z dwóch +części: komputera pokładowego i lokalizatora. Komputery pokładowe +znajdujące się na rynku mają wysoką cenę i większość z nich, nie +oferuje, aplikacji do zbierania danych, przez co robi się z nimi bałagan +i trzeba dbać samemu o to, by te dane katalogować. Gotowe lokalizatory, +mimo że zaawansowane również są bardzo drogie. + +## Przykłady produktów na rynku + +- Dużym zainteresowaniem na świecie cieszą się amerykańskie + [EggTimery](http://eggtimerrocketry.com/home/altimeters-av-bay/). + Posiadają one wiele różnych konfiguracji komputerów oraz + lokalizatorów. Mają jednak one dość wysokie ceny modułów i nie + oferują zintegrowanej aplikacji, która umożliwiałaby analizę danych, + musimy korzystać z osobnych programów. + +- Dostępne są [niemieckie komputery + pokładowe](https://www.rocketronics.de/shop/de/altimax-g3-standard.html?fbclid=IwAR2Btg-xkFvGJoPM6sU9-zkdCB5SZMVawdttTxnr6m8iG2iS46GtkmWs8Fc) + firmy Rocketronics oferujące wysoką jakość danych oraz dokładną + separację. Ich aplikacja nie umożliwia podglądu danych na żywo. Nie + ma w nich lokalizatorów i mają wysoką cenę. + +- [Lokalizator + Featherweight](https://www.featherweightaltimeters.com/featherweight-gps-tracker.html) + (koszt to 610-2000 zł) - wysoka cena, zawiera aplikację, ale do tego + potrzebny jest jeszcze komputer pokładowy.  + +- Jeden z najtańszych i najpopularniejszych sposobów (przynajmniej w + Polsce) na lokalizację rakiety polega na używaniu taniego + [lokalizatora](https://abc-rc.pl/product-pol-7625-Lokalizator-GPS-TK102B-Tracker-GPS-Sledzenie-w-WWW.html), + który wysyła podstawowe dane telemetryczne dzięki modułowi GPS i + GSM. Nie są to jednak produkty przeznaczone konkretnie do rakiet i + nie mogą zostać zintegrowane z komputerem pokładowym.  + +- Nowością jest komputer pokładowy + [Signal-R2](https://bps.space/shop/signal-r2) z aplikacją na telefon + (koszt to ok 1400 zł). Aplikacja dostępna na platformy android oraz + iOS jest zintegrowana z komputerem pokładowym. Cały system + komunikacji jest oparty na Bluetooth, co daje zasięg 10 metrów, + dlatego nie można używać aplikacji do odczytów danych na żywo + podczas lotu. Aby uzyskać szerszy dostęp do dokumentacji, kodów + źródłowych i informacji na temat projektu trzeba dodatkowo + miesięczne płacić za subskrypcje na specjalnej platformie Patronite. + +# Opis produkt + +## Aplikacja webowa + +- wizytówka koła + +- dane z testów będzie można zapisywać na serwerze w celu stworzenia + historii testów + +- eksport danych GPS w formacie KML (trajektoria lotu) + +- eksport danych telemetrycznych do Excel'a + +- import danych pomiarowych z pliku + +- wyświetlenie danych historycznych (z testów) + +- wyświetlenie danych historycznych w formie live (z testów) + +- wyszukiwanie testu po nazwie i dacie + +- kategoryzacja danych telemetrycznych (historia testów) przypisana do + testu + +## Aplikacja desktopowa + +- pomiary z rakiety obrazowane na żywo: + + - wykres prędkości od czasu, + + - wykres przyspieszenia od czasu, + + - wykresy orientacji XYZ, + + - wykres wysokości i wychylenia w osiach XYZ od czasu, + + - wyświetlenie lokalizacji GPS na mapie (Google Maps) + +- obrazowane danych z hamowni na żywo + + - wykres ciągu do czasu + + - wykres ciśnienia do czasu + +- dane po teście rakiety czy silnika będą zapisywane na serwerze + +- zgrywania/usuwanie danych z modułów elektronicznych + +- zmiana konfiguracji modułów elektronicznych + +## Elektronika + +- dokonywanie pomiarów podczas lotu (prędkość, przyspieszenie, + wysokość, wychylenia w osiach XYZ)  + +- lokalizacja GPS oraz pomiary wysyłane do stacji naziemnej za + pośrednictwem komunikacji bezprzewodowej LORA  + +- wykrycie apogeum (spadku swobodnego) pozwalające wyzwolić + separacje/spadochron + +- wyzwolenie separacji, spadochronu poprzez odpalenie zapalnika + elektrycznego  + +- przesyłanie danych do stacji naziemnej przez moduł komunikacyjny  + +- odbieranie danych przez odbiornik + +- odpalenie drugie spadochronu na określonej wysokości + +- przekazywanie danych do aplikacji desktopowej + +- zapisywania danych do pamięci modułu + +- odczytywanie danych z pamięci modułu + +- zmiana konfiguracji modułu + +# Zakres i ograniczenia + +## Skład zespołu + +- Wojciech Kubiak - systemy wbudowane - arduino, c++, FreeRTOS, python + +- Sebastian Wawrzyn - backend - .NET Core, C-.05em , Docker, NoSql + +- Piotr Józefowicz - frontend - Vue.js, typescript + +## 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ę + +## Harmonogram + +MVP produktu zostanie wypracowane i przedstawione do końca czerwca 2020 +roku, zawierać będzie funkcjonalności takie jak: + +- Komputer pokładowy 1.0: + + - Dokonywanie pomiarów telemetrycznych + + - Zapis danych na kartę SD + + - Wyzwolenie separacji za pomocą timera + + - Odpalenie zapalnika elektrycznego + +- Aplikacja internetowa (frontend): + + - Stworzenie konta użytkownika, logowanie + + - Dodawanie testów z pliku + + - Wyświetlanie danych z testów + + - Przegląd danych historycznych + + - Zintegrowania aplikacji webowej z REST API + +- Aplikacja serwerowa, REST API: + + - Dodanie serwisów REST pozwalających na operacje wymienione w + punkcie "Aplikacja internetowa" + + - Zintegrowania API z bazą danych + + - Wdrożenie aplikacji na środowisko testowe + +Druga wersja produktu wypracowana i oddana do stycznia 2021 roku, +obejmować będzie: + +- Wszystkie funkcjonalności zdefiniowane w MVP + +- Komputer pokładowy 2.0: + + - Układ wyzwolenia separacji + + - Komunikacja z nadajnikiem + + - Konfiguracja modułu + + - Zapis danych na pamięć flash + +- Nadajnik/Lokalizator: + + - Lokalizacja GPS oraz redundantny system prędkości wysokości + przyspieszenia + + - Komunikacja bezprzewodowa LORA + + - Konfiguracja modułu + +- Elektronika naziemna/Odbiornik: + + - Konfiguracja modułu + + - Odbieranie danych od komputera pokładowego (LORA) + + - Przekazywanie danych do serwera za pomocą REST API + + - Przekazywanie danych do kolejnych urządzeń za pomocą Seriala + +- Aplikacja internetowa (frontend): + + - Wyświetlanie i gromadzenie danych historycznych testów + + - Wyświetlanie testów historycznych w postaci live + + - Eksport testów do plików + + - Widok podsumowania testu + + - Profil użytkownika + +- Aplikacja desktopowa: + + - Wyświetlanie danych z testów live (wykresy) + + - Wyświetlanie lokalizacji za pośrednictwem Google Maps + + - Konfigurowanie płytki + + - Odczyt danych z płytki + + - Usuwanie danych z płytki + +- 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" + + - Wdrożenie aplikacji na środowisko produkcyjne + +Ograniczeniem projektu jest hosting, nie wiadomo czy politechnika +udostępni nam domenę oraz otworzy porty na zewnątrz. + +Kolejnym ograniczeniem jest konflikt pomiędzy Auth0 i Electronem. Okazuje się, że na chwilę obecną niemożliwym jest zintegrowanie tych dwóch narzędzi. Problem został zgłoszony do supportu obu tych firm i kiedy zostanie on rozwiązany, wznowimy pracę nad tą częścią projektu. diff --git a/Przybylski/awionika/wymagania_projektowe.md b/Przybylski/awionika/wymagania_projektowe.md index cd0610d..63033c3 100644 --- a/Przybylski/awionika/wymagania_projektowe.md +++ b/Przybylski/awionika/wymagania_projektowe.md @@ -1,515 +1,510 @@ ---- -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 - - - Electron - - - Typescript - - - .NET Core - - - C# - -## 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ę +--- +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ę