forked from bikol/DPRI_doc_20-21
Update dokumentacji
This commit is contained in:
parent
7ce3b8fce0
commit
57277742dd
@ -1,35 +1,24 @@
|
||||
---
|
||||
author:
|
||||
- Wojciech Kubiak
|
||||
- Piotr Józefowicz
|
||||
- Sebastian Wawrzyn
|
||||
title:
|
||||
- Dokument wizji dla projektu Awionika do rakiet
|
||||
- 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ń. Grupa
|
||||
docelowa dla projektu jest koło naukowe na politechnice poznańskiej PUT
|
||||
RocketLab, zajmujące się budowa rakiet i silników rakietowych. Potrzebny
|
||||
jest komputer pokładowy do rakiety oraz aplikacje ułatwiające obsługę
|
||||
testów rakiet i silników. Nasz projekt ma dostarczyć: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ń. Grupa docelowa dla
|
||||
projektu jest koło naukowe na politechnice poznańskiej PUT RocketLab,
|
||||
zajmujące się budowa rakiet i silników rakietowych. Potrzebny jest
|
||||
komputer pokładowy do rakiety oraz aplikacje ułatwiające obsługę testów
|
||||
rakiet i silników. Nasz projekt ma dostarczyć:
|
||||
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 wyzwolenie separacji oraz
|
||||
- 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.
|
||||
|
||||
@ -47,7 +36,7 @@ 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,
|
||||
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
|
||||
@ -71,12 +60,12 @@ 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ła 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.\
|
||||
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
|
||||
@ -86,10 +75,9 @@ 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
|
||||
oraz poprzez użycie timera (ustawienie odpowiedniego opóźnienia, po
|
||||
którym zostanie wyzwolona separacja/spadochron). 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.
|
||||
(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
|
||||
|
||||
@ -100,7 +88,7 @@ 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:
|
||||
## Przykłady produktów na rynku
|
||||
|
||||
- Dużym zainteresowaniem na świecie cieszą się amerykańskie
|
||||
[EggTimery](http://eggtimerrocketry.com/home/altimeters-av-bay/).
|
||||
@ -139,16 +127,14 @@ mimo że zaawansowane również są bardzo drogie.
|
||||
|
||||
# Opis produkt
|
||||
|
||||
## Aplikacja webowa:
|
||||
## Aplikacja webowa
|
||||
|
||||
- wizytówka koła
|
||||
|
||||
- możliwością wgrania avatara
|
||||
|
||||
- dane z testów będzie można zapisywać na serwerze w celu stworzenia
|
||||
historii testów
|
||||
|
||||
- eksport danych GPS w formacie NMEA
|
||||
- eksport danych GPS w formacie KML (trajektoria lotu)
|
||||
|
||||
- eksport danych telemetrycznych do Excel'a
|
||||
|
||||
@ -156,12 +142,14 @@ mimo że zaawansowane również są bardzo drogie.
|
||||
|
||||
- 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:
|
||||
## Aplikacja desktopowa
|
||||
|
||||
- pomiary z rakiety obrazowane na żywo:
|
||||
|
||||
@ -187,7 +175,7 @@ mimo że zaawansowane również są bardzo drogie.
|
||||
|
||||
- zmiana konfiguracji modułów elektronicznych
|
||||
|
||||
## Elektronika:
|
||||
## Elektronika
|
||||
|
||||
- dokonywanie pomiarów podczas lotu (prędkość, przyspieszenie,
|
||||
wysokość, wychylenia w osiach XYZ)
|
||||
@ -198,8 +186,6 @@ mimo że zaawansowane również są bardzo drogie.
|
||||
- wykrycie apogeum (spadku swobodnego) pozwalające wyzwolić
|
||||
separacje/spadochron
|
||||
|
||||
- timer pozwalający wyzwolić separacje/spadochron
|
||||
|
||||
- wyzwolenie separacji, spadochronu poprzez odpalenie zapalnika
|
||||
elektrycznego
|
||||
|
||||
@ -207,6 +193,8 @@ mimo że zaawansowane również są bardzo drogie.
|
||||
|
||||
- odbieranie danych przez odbiornik
|
||||
|
||||
- odpalenie drugie spadochronu na określonej wysokości
|
||||
|
||||
- przekazywanie danych do aplikacji desktopowej
|
||||
|
||||
- zapisywania danych do pamięci modułu
|
||||
@ -217,16 +205,15 @@ mimo że zaawansowane również są bardzo drogie.
|
||||
|
||||
# Zakres i ograniczenia
|
||||
|
||||
## Skład zespołu:
|
||||
## Skład zespołu
|
||||
|
||||
- Wojciech Kubiak - systemy wbudowane - arduino, c++, python
|
||||
- Wojciech Kubiak - systemy wbudowane - arduino, c++, FreeRTOS, python
|
||||
|
||||
- Sebastian Wawrzyn - backend - .NET Core, C#, Docker, baza
|
||||
danych
|
||||
- Sebastian Wawrzyn - backend - .NET Core, C-.05em , Docker, NoSql
|
||||
|
||||
- Piotr Józefowicz - frontend - Vue.js, typescript
|
||||
|
||||
## Kamienie milowe:
|
||||
## Kamienie milowe
|
||||
|
||||
- I faza, I semestr (02.2020 - 07.2020):
|
||||
|
||||
@ -245,14 +232,15 @@ mimo że zaawansowane również są bardzo drogie.
|
||||
|
||||
- Poddanie MVP testom funkcjonalnym
|
||||
|
||||
- II faza, II semestr(10.2020 - 12.2020):
|
||||
- II faza, II semestr(10.2020 - 01.2021):
|
||||
|
||||
- Uaktualnienie dekumentacji i Trello
|
||||
- Uaktualnienie dokumentacji i Trello
|
||||
|
||||
- Rozpoczęcie prac programistycznych nad aplikacjami
|
||||
- Kontynuacja prac programistycznych nad aplikacjami
|
||||
|
||||
- Kontynuacje prac programistycznych nad komputerem pokładowym
|
||||
oraz rozpoczęcie prac nad nadajnikiem i odbiornikiem
|
||||
|
||||
- Rozpoczęcie prac nad nadajnikiem i odbiornikiem
|
||||
|
||||
- Testowanie komputera pokładowego oraz elektroniki naziemnej
|
||||
|
||||
@ -265,7 +253,7 @@ mimo że zaawansowane również są bardzo drogie.
|
||||
|
||||
- Wdrożenie aplikacji na publiczną domenę
|
||||
|
||||
## Harmonogram:
|
||||
## Harmonogram
|
||||
|
||||
MVP produktu zostanie wypracowane i przedstawione do końca czerwca 2020
|
||||
roku, zawierać będzie funkcjonalności takie jak:
|
||||
@ -301,7 +289,7 @@ roku, zawierać będzie funkcjonalności takie jak:
|
||||
|
||||
- Wdrożenie aplikacji na środowisko testowe
|
||||
|
||||
Pierwsza wersja produktu wypracowana i oddana do grudnia 2020 roku,
|
||||
Druga wersja produktu wypracowana i oddana do stycznia 2021 roku,
|
||||
obejmować będzie:
|
||||
|
||||
- Wszystkie funkcjonalności zdefiniowane w MVP
|
||||
@ -314,6 +302,8 @@ obejmować będzie:
|
||||
|
||||
- Konfiguracja modułu
|
||||
|
||||
- Zapis danych na pamięć flash
|
||||
|
||||
- Nadajnik/Lokalizator:
|
||||
|
||||
- Lokalizacja GPS oraz redundantny system prędkości wysokości
|
||||
@ -325,18 +315,24 @@ obejmować będzie:
|
||||
|
||||
- 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
|
||||
|
||||
- Przekazywanie danych do kolejnych urządzeń za pomocą Bluetooth
|
||||
|
||||
- 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:
|
||||
|
@ -1,10 +1,7 @@
|
||||
---
|
||||
author:
|
||||
- Wojciech Kubiak
|
||||
- Piotr Józefowicz
|
||||
- Sebastian Wawrzyn
|
||||
title:
|
||||
- Dokument wymagań projektowych
|
||||
- Wojciech Kubiak, Piotr Józefowicz, Sebastian Wawrzyn
|
||||
title: "**Dokument wymagań projektowych**"
|
||||
---
|
||||
|
||||
# Elementy składowe projektu (produkty projektu)
|
||||
@ -43,10 +40,6 @@ title:
|
||||
|
||||
- Baza danych NoSql
|
||||
|
||||
- Repozytorium git zawierające kod aplikacji, API, elektroniki
|
||||
|
||||
- Tablica projektowa -- Trello
|
||||
|
||||
# Granice projektu
|
||||
|
||||
- Produkty zawarte:
|
||||
@ -63,18 +56,18 @@ title:
|
||||
|
||||
# Lista wymagań funkcjonalnych
|
||||
|
||||
## Komputer pokładowy:
|
||||
## 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
|
||||
- Automatyczne wyzwolenie separacji za pomocą barometru w apogeum
|
||||
|
||||
- Wyzwolenie separacji na żądanej wysokości
|
||||
|
||||
- Konfiguracja/kontrola modułu:
|
||||
|
||||
@ -82,6 +75,8 @@ title:
|
||||
|
||||
- odczyt danych z flash
|
||||
|
||||
- czyszczenie pamięci flash
|
||||
|
||||
## Nadajnik/Lokalizator
|
||||
|
||||
- Lokalizacja GPS oraz redundantny system prędkości wysokości
|
||||
@ -95,6 +90,8 @@ title:
|
||||
|
||||
- odczyt danych z flash
|
||||
|
||||
- czyszczenie pamięci flash
|
||||
|
||||
## Aplikacja internetowa
|
||||
|
||||
- Logowanie za pomocą Auth0
|
||||
@ -121,19 +118,23 @@ title:
|
||||
|
||||
- Przegląd danych historycznych
|
||||
|
||||
- Wyświetlanie testów historycznych w postaci live
|
||||
|
||||
- Zintegrowania aplikacji webowej z REST API
|
||||
|
||||
- Profil użytkownika, możliwość zmiany nazwy użytkownika, imienia,
|
||||
nazwiska, emaila, hasła
|
||||
- Eksport testów do plików (json, excel)
|
||||
|
||||
## Aplikacja desktopowa:
|
||||
- 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
|
||||
|
||||
- Wyświetlenie informacji tekstowych z komputera pokładowego
|
||||
|
||||
- Konfigurowanie modułów elektronicznych
|
||||
|
||||
- Odczyt/Zapis danych z modułów elektronicznych
|
||||
@ -142,7 +143,7 @@ title:
|
||||
|
||||
- Zapis pomiarów w plikach json
|
||||
|
||||
## Aplikacja serwerowa, REST API:
|
||||
## Aplikacja serwerowa, REST API
|
||||
|
||||
- Dodanie serwisów REST pozwalających na operacje wymienione w punkcie
|
||||
"Aplikacja internetowa"
|
||||
@ -150,13 +151,13 @@ title:
|
||||
- Dodanie serwisów REST pozwalających na operacje wymienione w punkcie
|
||||
"Aplikacja desktopowa"
|
||||
|
||||
- Zintegrowania API z bazą danych
|
||||
- Zintegrowanie API z bazą danych
|
||||
|
||||
- Wdrożenie aplikacji na środowisko testowe
|
||||
|
||||
- Wdrożenie aplikacji na środowisko produkcyjne
|
||||
|
||||
## Elektronika naziemna (odbiornik):
|
||||
## Elektronika naziemna (odbiornik)
|
||||
|
||||
- Odbieranie danych od komputera pokładowego (LORA)
|
||||
|
||||
@ -164,15 +165,13 @@ title:
|
||||
|
||||
- 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:
|
||||
## Komputer pokładowy
|
||||
|
||||
- Bezpieczny w użyciu
|
||||
|
||||
@ -212,7 +211,7 @@ title:
|
||||
|
||||
- FreeRTOS
|
||||
|
||||
## Elektronika naziemna (odbiornik):
|
||||
## Elektronika naziemna (odbiornik)
|
||||
|
||||
- Bezpieczna w użyciu
|
||||
|
||||
@ -224,15 +223,13 @@ title:
|
||||
|
||||
- Z czytelnym, przejrzystym kodem
|
||||
|
||||
- Zintegrowana z REST API - wysyła dane telemetryczne
|
||||
|
||||
- Technologie:
|
||||
|
||||
- Arduino
|
||||
|
||||
- C++
|
||||
|
||||
## Aplikacja internetowa (frontend):
|
||||
## Aplikacja internetowa (frontend)
|
||||
|
||||
- Wytworzona z użyciem nowoczesnych standardów
|
||||
|
||||
@ -248,7 +245,7 @@ title:
|
||||
|
||||
- Typescript
|
||||
|
||||
## Aplikacja desktopowa:
|
||||
## Aplikacja desktopowa
|
||||
|
||||
- Wytworzona z użyciem nowoczesnych standardów
|
||||
|
||||
@ -278,11 +275,9 @@ title:
|
||||
|
||||
- .NET Core
|
||||
|
||||
- C#
|
||||
- C-.05em
|
||||
|
||||
## Aplikacja serwerowa - REST API:
|
||||
|
||||
- Używa bazy danych NoSql
|
||||
## Aplikacja serwerowa - REST API
|
||||
|
||||
- Zaprojektowana według najnowszych standardów .NET
|
||||
|
||||
@ -298,19 +293,25 @@ title:
|
||||
|
||||
- Docker
|
||||
|
||||
## Baza danych:
|
||||
## Baza danych
|
||||
|
||||
- Szybka obsługa zapytań
|
||||
|
||||
- Rozszerzalna
|
||||
|
||||
- Niezawodna
|
||||
|
||||
- Technologie:
|
||||
|
||||
- NoSql
|
||||
|
||||
## Prototyp aplikacji internetowej przetestowany przez użytkowników:
|
||||
## Prototyp aplikacji internetowej przetestowany przez użytkowników
|
||||
|
||||
- Technologie:
|
||||
|
||||
- Adobe XD
|
||||
|
||||
## Tablica projektowa - Trello:
|
||||
## Tablica projektowa - Trello
|
||||
|
||||
- Historia wymagań funkcjonalnych (User stories)
|
||||
|
||||
@ -322,6 +323,12 @@ title:
|
||||
|
||||
## Repozytorium zawierające kod aplikacji, API oraz elektroniki
|
||||
|
||||
- Czytelne
|
||||
|
||||
- Uporządkowane
|
||||
|
||||
- Tworzone i utrzymywane ze sztuką
|
||||
|
||||
- Technologie:
|
||||
|
||||
- GitHub
|
||||
@ -343,23 +350,20 @@ title:
|
||||
- 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.
|
||||
- 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 drugi semestr
|
||||
funkcjonalnych na pierwszy semestr
|
||||
|
||||
- Brak błędów utrudniających korzystanie z aplikacji
|
||||
|
||||
- Czy produkt został oddany w czasie
|
||||
- Produkt został oddany w czasie
|
||||
|
||||
## Oczekiwane
|
||||
|
||||
@ -376,12 +380,18 @@ title:
|
||||
## 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)
|
||||
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
|
||||
- Produkt został oddany w czasie
|
||||
|
||||
- Produkt został wdrożony na domenę publiczną
|
||||
|
||||
- Produkt został przekazany klientowi
|
||||
|
||||
## Oczekiwane
|
||||
|
||||
@ -411,19 +421,21 @@ Strona zespołu projektowego:
|
||||
|
||||
- Projektowanie prototypu interfejsu użytkownika
|
||||
|
||||
- Sebastian Wawrzyn
|
||||
- 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:
|
||||
## Ryzyka ze względu na zasoby
|
||||
|
||||
- Odejście członka implementującego stronę serwerową - trudności w
|
||||
ukończeniu aplikacji serwerowej
|
||||
@ -436,7 +448,7 @@ Praca jest wykonywana w metodyce SCRUM w tygodniowych sprintach. Kod
|
||||
|
||||
- Określone ramy czasowe (semestry) na stworzenie produktu
|
||||
|
||||
## Inne:
|
||||
## Inne
|
||||
|
||||
- Nieporozumienia na linii zespół a klient wynikające z nieznajomości
|
||||
pojęć domenowych lub nieporozumienia dotyczące funkcjonalności czy
|
||||
@ -478,14 +490,15 @@ Praca jest wykonywana w metodyce SCRUM w tygodniowych sprintach. Kod
|
||||
|
||||
- Poddanie MVP testom funkcjonalnym
|
||||
|
||||
- II faza, II semestr(10.2020 - 02.2021):
|
||||
- II faza, II semestr(10.2020 - 01.2021):
|
||||
|
||||
- Uaktualnienie dekumentacji i Trello
|
||||
- Uaktualnienie dokumentacji i Trello
|
||||
|
||||
- Rozpoczęcie prac programistycznych nad aplikacjami
|
||||
- Kontynuacja prac programistycznych nad aplikacjami
|
||||
|
||||
- Kontynuacje prac programistycznych nad komputerem pokładowym
|
||||
oraz rozpoczecie prac nad nadajnikiem i odbiornikiem
|
||||
|
||||
- Rozpoczęcie prac nad nadajnikiem i odbiornikiem
|
||||
|
||||
- Testowanie komputera pokładowego oraz elektroniki naziemnej
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user