forked from bikol/DPRI_doc_20-21
Merge branch 'master' into master
This commit is contained in:
commit
34dfafe015
BIN
Dyczkowski/scouting/Wizja projektu.pdf
Normal file
BIN
Dyczkowski/scouting/Wizja projektu.pdf
Normal file
Binary file not shown.
BIN
Dyczkowski/scouting/Wymagania projektowe.pdf
Normal file
BIN
Dyczkowski/scouting/Wymagania projektowe.pdf
Normal file
Binary file not shown.
BIN
Dyczkowski/techniki-dentystyczne/wizja projektu.docx
Normal file
BIN
Dyczkowski/techniki-dentystyczne/wizja projektu.docx
Normal file
Binary file not shown.
BIN
Hanckowiak/sprawozdania/Dokument wizji projektu(poprawiony).pdf
Normal file
BIN
Hanckowiak/sprawozdania/Dokument wizji projektu(poprawiony).pdf
Normal file
Binary file not shown.
BIN
Hanckowiak/sprawozdania/Dokument wymagań projektowych.docx
Normal file
BIN
Hanckowiak/sprawozdania/Dokument wymagań projektowych.docx
Normal file
Binary file not shown.
BIN
Hanckowiak/wycena/Wizja_PRI.pdf
Normal file
BIN
Hanckowiak/wycena/Wizja_PRI.pdf
Normal file
Binary file not shown.
BIN
Hanckowiak/wycena/Zakres_projektu.pdf
Normal file
BIN
Hanckowiak/wycena/Zakres_projektu.pdf
Normal file
Binary file not shown.
BIN
Hanckowiak/wyklady/project-requirements.docx
Normal file
BIN
Hanckowiak/wyklady/project-requirements.docx
Normal file
Binary file not shown.
BIN
Hanckowiak/wyklady/project-vision.docx
Normal file
BIN
Hanckowiak/wyklady/project-vision.docx
Normal file
Binary file not shown.
BIN
Hanckowiak/zapisy/dokument wymagań projektowych.pdf
Normal file
BIN
Hanckowiak/zapisy/dokument wymagań projektowych.pdf
Normal file
Binary file not shown.
BIN
Pilka/buiness-cards/project-requiments-BusinessCard.docx
Normal file
BIN
Pilka/buiness-cards/project-requiments-BusinessCard.docx
Normal file
Binary file not shown.
BIN
Pilka/buiness-cards/project-vision-BusinessCard.docx
Normal file
BIN
Pilka/buiness-cards/project-vision-BusinessCard.docx
Normal file
Binary file not shown.
BIN
Pilka/zapisy-studentow/project-requirements.docx
Normal file
BIN
Pilka/zapisy-studentow/project-requirements.docx
Normal file
Binary file not shown.
BIN
Pilka/zapisy-studentow/project-vision.docx
Normal file
BIN
Pilka/zapisy-studentow/project-vision.docx
Normal file
Binary file not shown.
365
Przybylski/awionika/wizja_projektu.md
Normal file
365
Przybylski/awionika/wizja_projektu.md
Normal file
@ -0,0 +1,365 @@
|
|||||||
|
---
|
||||||
|
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ń. 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ć:
|
||||||
|
|
||||||
|
- 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
|
||||||
|
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ł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.\
|
||||||
|
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
|
||||||
|
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.
|
||||||
|
|
||||||
|
# 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
|
||||||
|
|
||||||
|
- 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 telemetrycznych do Excel'a
|
||||||
|
|
||||||
|
- import danych pomiarowych z pliku
|
||||||
|
|
||||||
|
- wyświetlenie danych historycznych (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
|
||||||
|
|
||||||
|
- timer pozwalający wyzwolić separacje/spadochron
|
||||||
|
|
||||||
|
- wyzwolenie separacji, spadochronu poprzez odpalenie zapalnika
|
||||||
|
elektrycznego
|
||||||
|
|
||||||
|
- przesyłanie danych do stacji naziemnej przez moduł komunikacyjny
|
||||||
|
|
||||||
|
- odbieranie danych przez odbiornik
|
||||||
|
|
||||||
|
- 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++, python
|
||||||
|
|
||||||
|
- Sebastian Wawrzyn - backend - .NET Core, C#, Docker, baza
|
||||||
|
danych
|
||||||
|
|
||||||
|
- 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 - 12.2020):
|
||||||
|
|
||||||
|
- Uaktualnienie dekumentacji i Trello
|
||||||
|
|
||||||
|
- Rozpoczęcie prac programistycznych nad aplikacjami
|
||||||
|
|
||||||
|
- Kontynuacje prac programistycznych nad komputerem pokładowym
|
||||||
|
oraz 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
|
||||||
|
|
||||||
|
Pierwsza wersja produktu wypracowana i oddana do grudnia 2020 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
|
||||||
|
|
||||||
|
- Nadajnik/Lokalizator:
|
||||||
|
|
||||||
|
- Lokalizacja GPS oraz redundantny system prędkości wysokości
|
||||||
|
przyspieszenia
|
||||||
|
|
||||||
|
- Komunikacja bezprzewodowa LORA
|
||||||
|
|
||||||
|
- Konfiguracja modułu
|
||||||
|
|
||||||
|
- 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
|
||||||
|
|
||||||
|
- Aplikacja internetowa (frontend):
|
||||||
|
|
||||||
|
- Wyświetlanie i gromadzenie danych historycznych testów
|
||||||
|
|
||||||
|
- 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.
|
||||||
499
Przybylski/awionika/wymagania_projektowe.md
Normal file
499
Przybylski/awionika/wymagania_projektowe.md
Normal file
@ -0,0 +1,499 @@
|
|||||||
|
---
|
||||||
|
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ę
|
||||||
197
Przybylski/sprawdziany/wizja-projektu.md
Normal file
197
Przybylski/sprawdziany/wizja-projektu.md
Normal file
@ -0,0 +1,197 @@
|
|||||||
|
**Dokument wizji projektu**
|
||||||
|
|
||||||
|
**Nazwa projektu:**\
|
||||||
|
**\"Platforma do generowania i publikacji sprawdzianów z matematyki --
|
||||||
|
Gen-Mat\"**
|
||||||
|
|
||||||
|
**Autorzy:**
|
||||||
|
|
||||||
|
**Damian Kuich**
|
||||||
|
|
||||||
|
**Mikołaj Kowalczyk**\
|
||||||
|
**Łukasz Adam Kubiak**\
|
||||||
|
**Mateusz Michalski**
|
||||||
|
|
||||||
|
**Data: 31.10.2020**
|
||||||
|
|
||||||
|
**1. Executive summary.**
|
||||||
|
|
||||||
|
Projekt "Gen-Mat" jest to nowy serwis do generowania i publikacji
|
||||||
|
sprawdzianów z matematyki na poziomie szkół ponadpodstawowych. Generator
|
||||||
|
ma za zadanie znacznie uprościć proces tworzenia sprawdzianów, dzięki
|
||||||
|
czemu użytkownik zaoszczędzi cenny czas. Zakładamy też, że możliwość
|
||||||
|
generowania unikalnych sprawdzianów pozwoli na zmniejszenie procentu
|
||||||
|
uczniów wymieniających się odpowiedziami do zadań. Skutkiem czego będzie
|
||||||
|
bardziej sumienne przygotowywanie się do testów sprawdzających wiedzę i
|
||||||
|
umiejętności z matematyki.
|
||||||
|
|
||||||
|
**2. Cel i grupa docelowa.**
|
||||||
|
|
||||||
|
Celem projektu jest zaoszczędzenie czasu potrzebnego na własnoręczne
|
||||||
|
tworzenie sprawdzianów z matematyki. Rozwiązaniem tego problemu będzie
|
||||||
|
serwis pozwalający na automatyczne generowanie takich sprawdzianów
|
||||||
|
korzystając z gotowej i sprawdzonej bazy zadań. "Gen-Mat" jest
|
||||||
|
skierowany głównie dla nauczycieli szkół ponadpodstawowych, ponieważ w
|
||||||
|
aktualnej swej formie baza będzie zawierać tylko zadania z matur za
|
||||||
|
zgodą uzyskaną od CKE. Dotarcie do grup docelowych umożliwią nam np.
|
||||||
|
Grupy dla nauczycieli z matematyki na platformie Facebook albo
|
||||||
|
komunikacja ze zaznajomionymi szkołami ponadpodstawowymi. Głównym
|
||||||
|
produktem naszego projektu będzie aplikacja webowa, ponieważ jest to
|
||||||
|
temat w którym każdy z członków zespołu jest zaznajomiony.
|
||||||
|
|
||||||
|
**3. Rynek (min. 3 konkurencyjne produkty).**
|
||||||
|
|
||||||
|
W fazie rozwoju platforma będzie darmowym serwisem. Gdy serwis zostanie
|
||||||
|
doprowadzony do pełnej funkcjonalności przewidywana jest płatna
|
||||||
|
subskrypcja, a dla studentów uczących się na uczelniach, gdzie nasz
|
||||||
|
produkt będzie wykorzystywany, dostęp do niego będzie darmowy. Wiele
|
||||||
|
generatorów testów i sprawdzianów z matematyki (np. klasowki.pl,
|
||||||
|
kompozytorklasowek.gwo.pl, dlanauczyciela.pl/generator) jest do siebie
|
||||||
|
podobnych. Naszym zadaniem jest stworzyć system spełniający oczekiwania
|
||||||
|
klientów. Zawierałby ulepszone funkcjonalności konkurencyjnych serwisów
|
||||||
|
i dodawał nowe, które ułatwiłyby pracę z naszym serwisem i rozszerzyły
|
||||||
|
jego możliwości. Generator w odróżnieniu od istniejących serwisów
|
||||||
|
umożliwiających generowanie sprawdzianów z matematyki może na podstawie
|
||||||
|
wygenerowanych wcześniej sprawdzianów utworzyć sprawdzian poprawkowy a
|
||||||
|
także wygenerować powtórkę przed sprawdzianem, zawierającą część
|
||||||
|
praktyczną jak i teoretyczną, gdzie zadanie może zawierać podpowiedzi
|
||||||
|
np. potrzebne wzory lub sposób rozwiązania.
|
||||||
|
|
||||||
|
**4. Opis produktu (min. 3 moduły/epiki)**
|
||||||
|
|
||||||
|
- Panel Administratora :
|
||||||
|
|
||||||
|
- Obszar: zarządzanie danymi, kontrola danych.
|
||||||
|
|
||||||
|
- Rodzaj: Administrator
|
||||||
|
|
||||||
|
- Generator Sprawdzianów:
|
||||||
|
|
||||||
|
- Obszar: przetwarzanie danych
|
||||||
|
|
||||||
|
- Rodzaj: autoryzowany użytkownik
|
||||||
|
|
||||||
|
- Panel Rejestracji:
|
||||||
|
|
||||||
|
- Obszar: przetwarzanie danych, autoryzacja
|
||||||
|
|
||||||
|
- Rodzaj: użytkownik o ograniczonych prawach
|
||||||
|
|
||||||
|
- Panel Logowania:
|
||||||
|
|
||||||
|
- Obszar: przetwarzanie danych, autoryzacja
|
||||||
|
|
||||||
|
- Rodzaj: autoryzowany uzytkownik
|
||||||
|
|
||||||
|
**5. Zakres i ograniczenia.**
|
||||||
|
|
||||||
|
**5.1 Skład zespołu:**
|
||||||
|
|
||||||
|
Damian Kuich(Backend) - odpowiedzialny za wdrożenie RESTful API do
|
||||||
|
projektu i deploy aplikacji na serwer. Zajmuje się także wprowadzaniem
|
||||||
|
zadań do bazy. Preferowane technologie: Python
|
||||||
|
|
||||||
|
Mikołaj Kowalczyk(Backend) - odpowiedzialny za utworzenie bazy danych i
|
||||||
|
pomoc przy tworzeniu API. Zajmujesię także wprowadzaniem zadań do bazy.
|
||||||
|
Preferowane technologie: Python
|
||||||
|
|
||||||
|
Łukasz Kubiak(Frontend)- odpowiedzialny za funkcjonalność Frontend'u i
|
||||||
|
odbierania endpointów od Backend'u. Pomaga przy tworzeniu UI projektu.
|
||||||
|
Preferowane technologie: JavaScript
|
||||||
|
|
||||||
|
Mateusz Michalski(Frontend) - odpowiedzialny za tworzenie UI projektu.
|
||||||
|
Pomaga przy funkcjonalnościach. Preferowane technologie: JavaScript
|
||||||
|
|
||||||
|
**5.2 Kamienie milowe:**
|
||||||
|
|
||||||
|
- **I faza, I semestr(02.2020 - 07.2020):**
|
||||||
|
|
||||||
|
- Przygotowanie backlogu serwisu
|
||||||
|
|
||||||
|
- Przygotowanie prototypu interfejsu
|
||||||
|
|
||||||
|
- Rozpoczęcie prac programistycznych
|
||||||
|
|
||||||
|
- Przygotowanie MVP serwisu
|
||||||
|
|
||||||
|
- Poddanie MVP testom funkcjonalnym
|
||||||
|
|
||||||
|
- **II faza, II semestr(10.2020 - 03.2021):**
|
||||||
|
|
||||||
|
- Przygotowanie sprintów na drugi semestr
|
||||||
|
|
||||||
|
- Ukończenie prac wraz ze wszystkimi zdefiniowanymi
|
||||||
|
funkcjonalnościami
|
||||||
|
|
||||||
|
- Publikacja serwisu na domenie publicznej i włączenie jej na
|
||||||
|
serwer
|
||||||
|
|
||||||
|
|
||||||
|
**5.3 Szkic Harmonogramu:**
|
||||||
|
|
||||||
|
**Semestr I:**
|
||||||
|
|
||||||
|
- Utworzenie konta użytkownika (logowanie i rejestracja)
|
||||||
|
|
||||||
|
- Utworzenie bazy danych z zadaniami
|
||||||
|
|
||||||
|
- Edycja konta użytkownika
|
||||||
|
|
||||||
|
- Resetowanie hasła
|
||||||
|
|
||||||
|
- Dodanie możliwości wyboru działów i umiejętności
|
||||||
|
|
||||||
|
- Wyszukiwarka zadań
|
||||||
|
|
||||||
|
- Ręczne tworzenie sprawdzianu
|
||||||
|
|
||||||
|
- Podział na grupy(Dla ręcznego tworzenia)
|
||||||
|
|
||||||
|
- Możliwość dodania obrazka
|
||||||
|
|
||||||
|
- Prototyp generatora(Wybór: trudności zadań i ich ilości, działów i
|
||||||
|
umiejętności)
|
||||||
|
|
||||||
|
- Generowanie karty odpowiedzi i klucza odpowiedzi
|
||||||
|
|
||||||
|
- Eksport sprawdzianu do PDF
|
||||||
|
|
||||||
|
**Semestr II:**
|
||||||
|
|
||||||
|
- Edycja wygenerowanego sprawdzianu
|
||||||
|
|
||||||
|
- Dodawanie obrazka do zadania(jpg,png)
|
||||||
|
|
||||||
|
- Miejsce pod zadaniem
|
||||||
|
|
||||||
|
- Dodawanie własnych zadań
|
||||||
|
|
||||||
|
- Edycja dodanych zadań
|
||||||
|
|
||||||
|
- Ustawienie zadań na prywatne/publiczne
|
||||||
|
|
||||||
|
- Możliwość udostępniania swoich zadań innym nauczycielom
|
||||||
|
|
||||||
|
- Możliwość oszacowania czasu na rozwiązanie zadania
|
||||||
|
|
||||||
|
- Edytor równań
|
||||||
|
|
||||||
|
- Postawienie strony na serwerze
|
||||||
|
|
||||||
|
- Dodanie publicznej domeny
|
||||||
|
|
||||||
|
**5.4 Ograniczenia:**
|
||||||
|
|
||||||
|
W pierwszej fazie projektu, produkt oferować będzie ograniczoną ilość
|
||||||
|
działów, co za tym idzie ograniczoną ilość umiejętności potrzebnych do
|
||||||
|
rozwiązania zadania i zadań z powodu praw autorskich. Możliwa będzie
|
||||||
|
edycja wyłącznie zadań dodanych przez użytkowników (jeżeli autor zadania
|
||||||
|
wyrazi na to zgodę). Do tej pory udało nam się otrzymać pozwolenie od
|
||||||
|
CKE na korzystanie z ich zadań, jednakże pod dwoma warunkami: brak
|
||||||
|
możliwości edycji zadań oraz obowiązkowe podanie autora zadania wraz z
|
||||||
|
zasadami oceniania. Możliwy będzie wybór trudności zadań wraz z ich
|
||||||
|
liczbą, podział na grupy (maks. 4), edytowanie i eksport sprawdzianu do
|
||||||
|
pdf, ustalenie punktacji do zadań, możliwość stworzenia własnego
|
||||||
|
sprawdzianu. Będzie możliwość stworzenia konta użytkownika i jego edycji
|
||||||
|
ale nie będzie posiadał możliwości uwierzytelniania czy osoba jest
|
||||||
|
uprawniona do używania serwisu.
|
||||||
305
Przybylski/sprawdziany/wymagania-projektowe.md
Normal file
305
Przybylski/sprawdziany/wymagania-projektowe.md
Normal file
@ -0,0 +1,305 @@
|
|||||||
|
**Dokument wymagań projektowych**
|
||||||
|
|
||||||
|
**Nazwa projektu:**\
|
||||||
|
**\"Platforma do generowania i publikacji sprawdzianów z matematyki --
|
||||||
|
Gen-Mat\"**
|
||||||
|
|
||||||
|
**Autorzy:**
|
||||||
|
|
||||||
|
**Damian Kuich**
|
||||||
|
**Mikołaj Kowalczyk**\
|
||||||
|
**Łukasz Adam Kubiak**\
|
||||||
|
**Mateusz Michalski**
|
||||||
|
|
||||||
|
**Data: 31.10.2020**
|
||||||
|
|
||||||
|
**1. Wersja dokumentu**
|
||||||
|
|
||||||
|
**1. Elementy składowe projektu (produkty projektu)**
|
||||||
|
|
||||||
|
**Semestr I:**
|
||||||
|
|
||||||
|
- Instancja serwera bazy danych oparta o silnik MySQL.
|
||||||
|
|
||||||
|
- Business Model Canvas.
|
||||||
|
|
||||||
|
- Value Proposition Canvas.
|
||||||
|
|
||||||
|
- Dokument Wizji Projektu.
|
||||||
|
|
||||||
|
- Prezentacja projektu.
|
||||||
|
|
||||||
|
- Harmonogram prac.
|
||||||
|
|
||||||
|
- Prototyp UI wykonany z użyciem Adobe XD.
|
||||||
|
|
||||||
|
- Arkusz z wynikami testów UI.
|
||||||
|
|
||||||
|
- Zakres Projektu.
|
||||||
|
|
||||||
|
- Dokumentacja Techniczna.
|
||||||
|
|
||||||
|
- Repozytorium Git.
|
||||||
|
|
||||||
|
- Strona projektowa na Jira.
|
||||||
|
|
||||||
|
**Semestr II:**
|
||||||
|
|
||||||
|
- Instancja serwerowa oparta o Heroku.
|
||||||
|
|
||||||
|
- Prezentacja prac na 2 semestr
|
||||||
|
|
||||||
|
- Aplikacja webowa w języku Python oparta o framework Django.
|
||||||
|
|
||||||
|
- Pomocnicza aplikacja webowa w Node JS
|
||||||
|
|
||||||
|
**2. Granice projektu**
|
||||||
|
|
||||||
|
Projekt jest tworzony jako serwis webowy, ponieważ większość nauczycieli
|
||||||
|
swoją pracę spędza przy komputerach. Przy tworzeniu sprawdzianu mniejszy
|
||||||
|
ekran(np. Telefon, tablet) byłby ogromnym minusem przy tego typu
|
||||||
|
aplikacji. Serwis, też będzie posiadał ograniczoną bazę danych
|
||||||
|
posiadającą tylko zadania z CKE, ponieważ korzystanie z innych źródeł
|
||||||
|
jest narażone na opłatę praw do użytku. Kolejnym problemem jest obsługa
|
||||||
|
ogromnej ilości użytkowników na raz co przy aktualnym serwerze jest
|
||||||
|
niemożliwe bez własnego wkładu finansowego. Aplikacja też nie posiada
|
||||||
|
funkcjonalności autoryzacji, czy podana osoba jest nauczycielem. Taka
|
||||||
|
funkcjonalność byłaby bardzo ciężka do wdrożenia, ponieważ
|
||||||
|
potrzebowałaby bardzo dobrych zabezpieczeń i bardzo dobrego pomysłu na
|
||||||
|
autoryzację. Niektóre funkcję nie zostaną wdrożone, ponieważ po upływie
|
||||||
|
czasu okazywały się albo za trudne do implementacji albo niepotrzebne.
|
||||||
|
Np. możliwość rysowania własnych grafik jest funkcjonalnością, która
|
||||||
|
byłaby bardzo trudna do dobrej implementacji przy responsywnym tworzeniu
|
||||||
|
pdf'a. Tworzenie arkusza powtórzeniowego do matury jest też
|
||||||
|
funkcjonalnością niepotrzebną, ponieważ jest to bardzo zbliżone do
|
||||||
|
tworzenia normalnego sprawdzianu.
|
||||||
|
|
||||||
|
**3. Lista wymagań funkcjonalnych**
|
||||||
|
|
||||||
|
- Rejestracja i logowanie użytkowników (Użytkownik podczas rejestracji
|
||||||
|
podaje nazwę użytkownika, hasło oraz email, na który wysłana
|
||||||
|
zostanie wiadomość z linkiem aktywującym konto. Podczas logowania
|
||||||
|
wymagane jest podanie nazwy użytkownika oraz hasła)
|
||||||
|
|
||||||
|
- Wylogowywanie
|
||||||
|
|
||||||
|
- Odzyskiwanie hasła (Mail zawierający hasło użytkownika lub token)
|
||||||
|
|
||||||
|
- Możliwość wyboru działów i umiejętności zawartych w bazie zadań (Po
|
||||||
|
wybraniu opcji "utwórz sprawdzian" użytkownik zobaczy listę z
|
||||||
|
dostępnymi działami i związanych z nimi umiejętnościami. Działy i
|
||||||
|
umiejętności pozyskiwane są z akruszy zadaniowych CKE.)
|
||||||
|
|
||||||
|
- Tworzenie ręczne sprawdzianów (Użytkownik wybiera dział oraz
|
||||||
|
umiejętności, a następnie tworzy sprawdzian z zadań znajdujących się
|
||||||
|
w zbiorze zadań należących do wybranego działu lub umiejętności.
|
||||||
|
Istnieje opcja pominięcia wyboru działów lub umiejętności.)
|
||||||
|
|
||||||
|
- Wyszukiwarka zadań (Wyszukiwanie na podstawie działów,
|
||||||
|
umiejętności.)
|
||||||
|
|
||||||
|
- Możliwość dodania grafiki do sprawdzianu (jpg,png)
|
||||||
|
|
||||||
|
- Eksport sprawdzianów do PDF
|
||||||
|
|
||||||
|
- Generowanie kart i arkuszy odpowiedzi (Karty i arkusze dostosowane
|
||||||
|
do ilości grup w sprawdzianie.)
|
||||||
|
|
||||||
|
- Edytor równań oparty o LaTeX
|
||||||
|
|
||||||
|
- Automatyczne generowanie sprawdzianów (Na podstawie wybranych
|
||||||
|
działów i umiejętności, losowane są zadania a następnie dodawane do
|
||||||
|
sprawdzianu. Użytkownik może wybrać czy chce, aby generowane były
|
||||||
|
arkusze i karty odpowiedzi.
|
||||||
|
|
||||||
|
- Edycja wygenerowanych sprawdzianów (Możliwa będzie zmiana układu
|
||||||
|
zadań w sprawdzianie oraz usunięcie zadania, które nam nie odpowiada
|
||||||
|
i dodanie nowego.)
|
||||||
|
|
||||||
|
- Dodawanie własnych zadań i możliwość ich edycji (Zadania będą
|
||||||
|
dzielić się na publiczne i prywatne. Użytkownik może zdecydować czy
|
||||||
|
chce, aby inni użytkownicy mieli dostęp do jego zadań.)
|
||||||
|
|
||||||
|
- Możliwość oszacowania czasu potrzebnego na rozwiązanie
|
||||||
|
sprawdzianu/zadania (Autor zadania będzie musiał podać szacowany
|
||||||
|
czas na rozwiązanie go, szacowany czas na ukończenie sprawdzianu
|
||||||
|
będzie suma czasów potrzebnych na rozwiązanie poszczególnych zadań.)
|
||||||
|
|
||||||
|
- Miejsce pod zadaniem na rozwiązanie (Użytkownik może wybrać czy
|
||||||
|
miejsce do rozwiązania zadania ma znajdować się pod nim. )
|
||||||
|
|
||||||
|
**4. Lista wymagań niefunkcjonalnych**
|
||||||
|
|
||||||
|
- Niski czas reakcji na zapytania ze strony użytkowników.
|
||||||
|
|
||||||
|
- Łatwość korzystania z aplikacji, estetyka, szybkość uczenia się obsługi aplikacji.
|
||||||
|
|
||||||
|
- brak wad, szybki czas naprawy wad i błędów, dostępność korzystania z wszystkich cech aplikacji.
|
||||||
|
|
||||||
|
- Możliwość korzystania z serwisu na wielu wyszukiwarkach.
|
||||||
|
|
||||||
|
**5. Mierzalne wskaźniki wdrożeniowe**
|
||||||
|
|
||||||
|
Semestr II:
|
||||||
|
|
||||||
|
- System zostanie udostępniony w domenie internetowej gen-mat i będzie
|
||||||
|
mogło jednocześnie z niego korzystać od 5 do 20 osób.
|
||||||
|
|
||||||
|
- Na koniec drugiego semestru system opublikowany w wersji testowej
|
||||||
|
beta.
|
||||||
|
|
||||||
|
- Baza zadań zostanie zasilona pozyskanymi danymi od CKE.
|
||||||
|
|
||||||
|
**6. Kryteria akceptacji projektu dla I semestru prac**
|
||||||
|
|
||||||
|
- **Wymagane :**
|
||||||
|
|
||||||
|
- Rejestracja i logowanie/wylogowanie użytkowników (użytkownik
|
||||||
|
posiada konto, na którym może zapisywać swoje sprawdziany)
|
||||||
|
|
||||||
|
- Tworzenie ręczne sprawdzianów
|
||||||
|
|
||||||
|
- Możliwość wyboru działów i umiejętności
|
||||||
|
|
||||||
|
- Wyszukiwarka zadań (wyszukiwanie wg. działów, umiejętności)
|
||||||
|
|
||||||
|
- Możliwość dodania grafiki do sprawdzianu
|
||||||
|
|
||||||
|
- Generowanie kart i arkuszy odpowiedzi
|
||||||
|
|
||||||
|
- Możliwość stworzenia duplikatu sprawdzianu
|
||||||
|
|
||||||
|
**7. Kryteria akceptacji projektu dla II semestru prac**
|
||||||
|
|
||||||
|
- **Wymagane :**
|
||||||
|
|
||||||
|
- Eksport sprawdzianów do PDF
|
||||||
|
|
||||||
|
- Edytor równań
|
||||||
|
|
||||||
|
- Automatyczne generowanie sprawdzianów na podstawie wybranych
|
||||||
|
umiejętności, działów, trudności i ilości zadań
|
||||||
|
|
||||||
|
- Tworzenie grup sprawdzianu
|
||||||
|
|
||||||
|
- Edycja sprawdzianu
|
||||||
|
|
||||||
|
- Edycja wygenerowanych sprawdzianów
|
||||||
|
|
||||||
|
- Dodawanie własnych zadań i możliwość ich edycji
|
||||||
|
|
||||||
|
- Publikacja serwisu na publicznej domenie
|
||||||
|
|
||||||
|
- Możliwość udostępniania swoich zadań innym nauczycielom
|
||||||
|
|
||||||
|
- Możliwość oszacowania czasu potrzebnego na rozwiązanie
|
||||||
|
sprawdzianu/zadania
|
||||||
|
|
||||||
|
- Miejsce pod zadaniem
|
||||||
|
|
||||||
|
- **Oczekiwane:**
|
||||||
|
|
||||||
|
- Integracja z zewnętrznym serwisem hostingowym.
|
||||||
|
|
||||||
|
- **Planowane:**
|
||||||
|
|
||||||
|
- Rozszerzenie bazy o dodatkowe zadania spoza CKE
|
||||||
|
|
||||||
|
- Autoryzacja nauczycieli
|
||||||
|
|
||||||
|
**8. Organizacja pracy zespołu**
|
||||||
|
|
||||||
|
**Organizacja zespołu:**
|
||||||
|
|
||||||
|
Zespół jest podzielony na dwie osoby odpowiedzialne za Front'end i dwie
|
||||||
|
za Back'end. Obraliśmy też metodykę pracy Scrum. Głównym narzędziem
|
||||||
|
wspomagającym pracę jest PyCharm ale też serwis Heroku na którym mamy
|
||||||
|
wdrożoną naszą aplikacje. Kody są przechowywane w rezpozytorium kodu na
|
||||||
|
GitHub'ie. Przebieg projektu jest kontrolowany przy pomocy Jiry, gdzie
|
||||||
|
dla każdej osoby z projektu przydzielane są zadania na dany Sprint.
|
||||||
|
Zadania są przypisywane przez Scrum Mastera na podstawie umiejętności
|
||||||
|
danego członka zespołu. Potem, co jakiś czas sprawdzany jest postęp
|
||||||
|
danego zadania na podstawie tzw. "Task Review". Ostatni punkt zadania to
|
||||||
|
testowanie, czy zostało wykonane dobrze, dopisanie należytych podzadań,
|
||||||
|
które są uważane za najbardziej kluczowe i podanie logtime'u.
|
||||||
|
|
||||||
|
**Organizacja prac w zespole:**
|
||||||
|
|
||||||
|
- **Damian Kuich**
|
||||||
|
|
||||||
|
- Implementacja aplikacji serwerowej API
|
||||||
|
|
||||||
|
- Zarządzanie dokumentacją
|
||||||
|
|
||||||
|
- Pomoc przy tworzeniu bazy danych na potrzeby aplikacji API
|
||||||
|
|
||||||
|
- Reprezentatywna rola przed klientem
|
||||||
|
|
||||||
|
- Projektowanie architektury aplikacji serwerowej
|
||||||
|
|
||||||
|
- Komunikacja na linii zespół - klient(nauczyciele matematyki dla
|
||||||
|
szkół ponadpodstawowych, jak i podstawowych). Komunikacja
|
||||||
|
odbywała się mailowo, bądź przy pomocy portali
|
||||||
|
społecznościowych(np. facebook).
|
||||||
|
|
||||||
|
- **Mikołaj Kowalczyk**
|
||||||
|
|
||||||
|
- Implementacja aplikacji serwerowej API
|
||||||
|
|
||||||
|
- Zarządzanie dokumentacją
|
||||||
|
|
||||||
|
- Stworzenia bazy danych na potrzeby aplikacji API
|
||||||
|
|
||||||
|
- Projektowanie architektury aplikacji serwerowej
|
||||||
|
|
||||||
|
- **Łukasz Kubiak**
|
||||||
|
|
||||||
|
- Implementacja aplikacji webowej
|
||||||
|
|
||||||
|
- Obsługa API i formularzy.
|
||||||
|
|
||||||
|
- Zarządzanie dokumentacją
|
||||||
|
|
||||||
|
- Projektowanie architektury aplikacji webowej
|
||||||
|
|
||||||
|
- **Mateusz Michalski**
|
||||||
|
|
||||||
|
- Projektowanie interface'u użytkownika
|
||||||
|
|
||||||
|
- Zarządzanie dokumentacją
|
||||||
|
|
||||||
|
- Projektowanie architektury aplikacji webowej
|
||||||
|
|
||||||
|
**9. Ryzyka projektowe**
|
||||||
|
|
||||||
|
- W projekcie planujemy wykorzystać moduł LaTeX do tworzenia własnych
|
||||||
|
zadań. Generuje to problem, ponieważ nakłada to niepotrzebną
|
||||||
|
trudność do naszego projektu. Najlepszym rozwiązaniem, będzie
|
||||||
|
utworzenie jak najłatwiejszego panelu wprowadzania zadań do bazy i
|
||||||
|
dobrze napisanej instrukcji obsługi.
|
||||||
|
|
||||||
|
**10. Kamienie milowe**
|
||||||
|
|
||||||
|
- **I faza, I semestr(02.2020 - 07.2020):**
|
||||||
|
|
||||||
|
- Przygotowanie backlogu serwisu
|
||||||
|
|
||||||
|
- Przygotowanie prototypu interfejsu
|
||||||
|
|
||||||
|
- Rozpoczęcie prac programistycznych
|
||||||
|
|
||||||
|
- Przygotowanie MVP serwisu
|
||||||
|
|
||||||
|
- Poddanie MVP testom funkcjonalnym
|
||||||
|
|
||||||
|
- **II faza, II semestr(10.2020 - koniec 01.2021):**
|
||||||
|
|
||||||
|
- Przygotowanie sprintów na drugi semestr
|
||||||
|
|
||||||
|
- Ukończenie prac wraz ze wszystkimi zdefiniowanymi
|
||||||
|
funkcjonalnościami
|
||||||
|
|
||||||
|
- Publikacja serwisu na domenie publicznej i włączenie jej na
|
||||||
|
serwer
|
||||||
|
|
||||||
|
- Zdanie produktu klientowi
|
||||||
203
Przybylski/unity/dokument-wymagan-proj.md
Normal file
203
Przybylski/unity/dokument-wymagan-proj.md
Normal file
@ -0,0 +1,203 @@
|
|||||||
|
# **Dokument wymagań projektowych**
|
||||||
|
|
||||||
|
**Nazwa projektu: Platformowa gra w Unity**
|
||||||
|
|
||||||
|
**Autorzy: Kamil Tyrek, Mateusz Hypś, Jakub Kozubal**
|
||||||
|
|
||||||
|
**Data: 13.12.2020r.**
|
||||||
|
|
||||||
|
**0. Wersje dokumentu**
|
||||||
|
|
||||||
|
01.11.2020r. – aktualizacja na rozpoczęcie semestru drugiego w oparciu o nowy wzór
|
||||||
|
|
||||||
|
15.11.2020r. – aktualizacja funkcjonalności i kamieni milowych
|
||||||
|
|
||||||
|
13.12.2020r - aktualizacja dotycząca platformy, na której umieszczona zostanie gra
|
||||||
|
|
||||||
|
**1. Elementy składowe projektu (produkty projektu)**
|
||||||
|
|
||||||
|
**Przykładami** elementów programistycznych są:
|
||||||
|
|
||||||
|
- Gra platformowa 2D stworzona na silniku UNITY
|
||||||
|
|
||||||
|
**Przykładami** elementów nieprogramistycznych są choćby:
|
||||||
|
|
||||||
|
- Dokument wizji projektu,
|
||||||
|
- Prototyp UI głównego menu,
|
||||||
|
- Value Proposition Canvas,
|
||||||
|
- Business Model Canvas,
|
||||||
|
- Raporty z wykonanych testów użyteczności menu głównego
|
||||||
|
- Repozytorium zawierające kod aplikacji - GitHub
|
||||||
|
- Tablica projektowa - JIRA
|
||||||
|
|
||||||
|
**2. Granice projektu**
|
||||||
|
|
||||||
|
- Produkt dostępny na systemy, ze względu na wymagania Unity 2019.1:
|
||||||
|
|
||||||
|
- Windows 7 SP1+
|
||||||
|
- macOS 10.12+
|
||||||
|
- Ubuntu 16.04+
|
||||||
|
- Nie jest dostępna na konsolach oraz urządzeniach mobilnych z powodu braku przewidzianej konfiguracji sterowania innego niż klawiaturą i myszką
|
||||||
|
- Funkcjonalność sterowania padem nie zostanie wdrożona, ponieważ ze względu na typ gry może on przeszkadzać – przykładem mogą być mini-gry, gdzie konieczne jest odpowiednie wybranie danego obiektu, co w przypadku poruszania padem może być uciążliwe
|
||||||
|
|
||||||
|
**3. Lista wymagań funkcjonalnych**
|
||||||
|
|
||||||
|
- Gracz może swobodnie i płynnie poruszać się postacią po świecie gry
|
||||||
|
- Możliwość wczytania gry
|
||||||
|
- Możliwość ręcznego ustawienia poziomu głośności gry oraz muzyki
|
||||||
|
- Możliwość ręcznego ustawienia rozdzielczości, v-sync, fullscreen
|
||||||
|
- Możliwość ręcznej zmiany ustawień sterowania odpowiadających za konkretne czynności
|
||||||
|
- Zapisywanie się ustawień graficznych, dźwiękowych i sterowania
|
||||||
|
- Pula podpowiedzi w trakcie rozgrywki określających sterowanie i/lub zadanie gracza
|
||||||
|
- Gracz dysponuje ekwipunkiem, który będzie posiadał ograniczoną ilość miejsc. W ekwipunku będą znajdować się miecze, eliksiry dodające punkty życia oraz wytrychy, pozwalające na rozpoczęcie mini-gry z otwieraniem skarbu
|
||||||
|
- Gracz dysponuje możliwością przeczytania opisu przedmiotu znajdującego się w ekwipunku
|
||||||
|
- Gracz może w dowolnej chwili zatrzymać oraz wznowić grę
|
||||||
|
- Gracz może przechodzić opcjonalne mini-gry w celu zdobycia doświadczenia – przykładem jest mini-gra przesuwanych puzzli
|
||||||
|
- Gracz może rozdawać punkty doświadczenia w drzewku umiejętności
|
||||||
|
- Gracz może cofać rozdane wcześniej punkty doświadczenia określonym wcześniej kosztem
|
||||||
|
- Gracz może wybrać styl rozgrywki poprzez wybranie konkretnej gałęzi w drzewku umiejętności – podział na umiejętności związane z siłą, poruszaniem się i wytrzymałością
|
||||||
|
- Gracz może używać nauczonej umiejętności od razu po dodaniu jej w drzewku
|
||||||
|
- Gracz może likwidować przeciwników zyskując za to punkty doświadczenia
|
||||||
|
- Możliwość pominięcia przeciwników przeskakując nad nimi
|
||||||
|
- Gracz musi przejść poziom wprowadzający do gry w celu przejścia dalej
|
||||||
|
- Przeciwnicy poruszają się po wyznaczonych ścieżkach
|
||||||
|
- Przeciwnicy poruszają się w kierunku gracza w określonych granicach
|
||||||
|
- Gracz traci określoną ilość punktów życia po ataku przez przeciwnika
|
||||||
|
- Gracz po utracie wszystkich punktów życia cofa się na ostatni checkpoint (lub w przypadku całkowitej straty żyć na początek poziomu)
|
||||||
|
- Istnienie elementów w grze, które zmuszają gracza do szybszego podejmowania decyzji
|
||||||
|
|
||||||
|
- Znikające platformy
|
||||||
|
- Ruchome platformy
|
||||||
|
- Mini-gra rury
|
||||||
|
|
||||||
|
- Gra automatycznie się zapisuje informując o tym gracza
|
||||||
|
- Gracz jest na bieżąco wprowadzany do fabuły gry
|
||||||
|
- Gracz do dyspozycji będzie mieć 3 poziomy:
|
||||||
|
- Poziom samouczka, którego średni czas przejścia trwa 8 minut
|
||||||
|
- Poziom pierwszy, którego średni czas przejścia trwa 18 minut
|
||||||
|
- Poziom do wyboru poziomów
|
||||||
|
|
||||||
|
**4. Lista wymagań niefunkcjonalnych**
|
||||||
|
|
||||||
|
- Niezawodność, dostępność – System powinien być dostępny w każdy dzień tygodnia, ponadto wszystkie błędy gry na bieżąco naprawiane
|
||||||
|
- Wydajność - System w miarę możliwości powinien być dostępny dla jak największej liczby urządzeń ze względu na wymagania sprzętowe
|
||||||
|
- Użyteczność - System ma spełniać co najmniej 90% wymagań funkcjonalnych
|
||||||
|
- Ergonomia - Używanie systemu powinno być intuicyjne i przejrzyste dla użytkownika.
|
||||||
|
- Zrozumiałość - Konstrukcja gry powinna być zrobiona w taki sposób, że użytkownik jest w stanie zrozumieć w jakim elemencie rozgrywki aktualnie się znajduje
|
||||||
|
- Dostępność - Aplikacja powinna być dostępna w serwisie z grami (np. Steam, itch.io itp.)
|
||||||
|
- Postępowość - System jest na bieżąco uaktualniany w celu eliminacji błędów oraz rozwijania o nowe funkcjonalności/poziomy.
|
||||||
|
- Płynność - Gra powinna działać płynnie jeśli jest uruchomiona na urządzeniu zgodnym z wymaganiami sprzętowymi i systemów
|
||||||
|
|
||||||
|
**5. Mierzalne wskaźniki wdrożeniowe**
|
||||||
|
|
||||||
|
- Gra zostanie opublikowana na platformie itch.io pod koniec grudnia
|
||||||
|
- Produkt będzie regularnie testowany (raz na dwa tygodnie) pod kątem poprawnego działania funkcjonalności przez grono osób wybrane przez zespół deweloperski. Zespół deweloperski będzie również testował produkt co przyrost, czyli co tydzień.
|
||||||
|
|
||||||
|
- Na koniec grudnia system zostanie dostarczony do klienta w wersji testowej alpha (rozumianej zgodnie z metodyką Agile). Pod koniec stycznia klient otrzyma system w wersji testowej beta.
|
||||||
|
|
||||||
|
**6 . Kryteria akceptacji projektu dla I semestru prac**
|
||||||
|
|
||||||
|
- Kryteria wymagane:
|
||||||
|
- Do funkcjonalności wymaganych należało:
|
||||||
|
- Stworzenie modeli poziomu pierwszego oraz samouczka
|
||||||
|
- Funkcjonalne menu wraz z muzyką
|
||||||
|
- Dodanie jednej łamigłówki na jednym z wcześniej wymienionych poziomów
|
||||||
|
- Model bohatera wraz z animacjami oraz możliwością poruszania się
|
||||||
|
- Bierni wrogowie rozłożeni na poziomie samouczkowym
|
||||||
|
- Kryteria oczekiwane:
|
||||||
|
- Do funkcjonalności oczekiwanych należało:
|
||||||
|
- Dodanie kolejnej łamigłówki
|
||||||
|
- Rozwój przeciwników o możliwości walki z graczem
|
||||||
|
- Zwiększenie rozmiaru poziomu samouczka
|
||||||
|
- Możliwość rozwiązywania mini-gier (rury i puzzle)
|
||||||
|
- Stworzenie urozmaiceń na poziomie samouczka w postaci ruchomych platform czy interakcji z obiektami środowiska
|
||||||
|
- Kryteria planowane:
|
||||||
|
- Do funkcjonalności planowanych należało:
|
||||||
|
- System zapisywania i wczytywania gry
|
||||||
|
- System zbierania doświadczenia i wbijania poziomów
|
||||||
|
- Możliwość poruszania się po mapie za pomocą skakania po linach
|
||||||
|
|
||||||
|
**7. Kryteria akceptacji projektu dla II semestru prac**
|
||||||
|
|
||||||
|
- Kryteria wymagane:
|
||||||
|
- Do funkcjonalności wymaganych należą:
|
||||||
|
- Skonfigurowanie globalnego zapisu stanu gry oraz możliwości wczytania go z dowolnej instancji gry, a także dodanie systemu autozapisu
|
||||||
|
- Rozwinięty system zbierania doświadczenia wraz z drzewkiem umiejętności
|
||||||
|
- Dodanie ekwipunku dla bohatera
|
||||||
|
- Kryteria oczekiwane
|
||||||
|
- Wersja beta gry dodana na platformę itch.io
|
||||||
|
- Przeprowadzone testy na wersji alfa gry
|
||||||
|
- Do funkcjonalności oczekiwanych należą:
|
||||||
|
- Dodanie kolejnych mini-gier i łamigłówek również na poziomie 1
|
||||||
|
- Rozwinięta fabuła
|
||||||
|
- Kryteria planowane
|
||||||
|
- Stworzenie planów marketingowych
|
||||||
|
- Do funkcjonalności planowanych należą:
|
||||||
|
- system wyboru poziomów trudności
|
||||||
|
- stworzenie zaawansowanej, wieloczęściowej walki z końcowym przeciwnikiem
|
||||||
|
|
||||||
|
**8. Organizacja pracy zespołu**
|
||||||
|
|
||||||
|
- Strona klienta:
|
||||||
|
|
||||||
|
a) Jakub Kozubal:
|
||||||
|
|
||||||
|
§ Product Owner – odpowiedzialność za dostarczenie produktu na platformę itch.io
|
||||||
|
|
||||||
|
- Strona zespołu projektowego:
|
||||||
|
|
||||||
|
a) Mateusz Hypś
|
||||||
|
|
||||||
|
§ Projektowanie architektury gry
|
||||||
|
|
||||||
|
§ Tworzenie dokumentacji
|
||||||
|
|
||||||
|
§ Implementacja produktu końcowego
|
||||||
|
|
||||||
|
b) Jakub Kozubal
|
||||||
|
|
||||||
|
§ Projektowanie architektury gry
|
||||||
|
|
||||||
|
§ Tworzenie dokumentacji
|
||||||
|
|
||||||
|
§ Implementacja produktu końcowego
|
||||||
|
|
||||||
|
§ Nadzorowanie testów
|
||||||
|
|
||||||
|
c) Kamil Tyrek
|
||||||
|
|
||||||
|
§ Projektowanie architektury gry
|
||||||
|
|
||||||
|
§ Tworzenie dokumentacji
|
||||||
|
|
||||||
|
§ Tworzenie prototypu opcji
|
||||||
|
|
||||||
|
§ Nadzorowanie testów
|
||||||
|
|
||||||
|
§ Nadzorowanie przebiegiem sprintów – zakładanie zadań, zarządzanie spotkań cotygodniowych
|
||||||
|
|
||||||
|
Jako metodykę pracy przyjęto Scrum. Głównymi powodami tej decyzji jest doświadczenie części zespołu w tej metodyce oraz przejrzystość i rozsądne zarządzanie pracą. Nie rozważano innych metodyk pracy. Przy zarządzaniu pracą wspomaga nas serwis JIRA, który pozwala zarządzać regularne sprinty – w pierwszym semestrze dwutygodniowe, w drugim semestrze tygodniowe. Kod źródłowy zarządzany jest poprzez GitHub. Dla przejrzystości pracy, każdy commit na GitHub oznaczany jest id zadania na Jirze, dzięki czemu wchodząc w zadanie widzimy commit powiązany z jego rozwiązaniem. W momencie rozpoczęcia zadania deweloper, jeśli następuje potrzeba, tworzy podzadania do zadań na Jirze. Dotyczy to większych zadań, których wykonanie polega na tworzeniu większej ilości funkcjonalności. Dzięki temu realizując nowe zadania, o podobnej budowie, można sugerować się podobnym sposobem działania zadania. Po każdym commicie programista wyznacza ile czasu poświęcił na zadanie, poprzez wbudowaną w Jirze funkcjonalność "Log Work". Gdy zadanie zostanie zakończone, programista oznacza je statusem "DONE".
|
||||||
|
|
||||||
|
**9. Ryzyka projektowe**
|
||||||
|
|
||||||
|
- Ryzyko ze względu na zasoby
|
||||||
|
- Określone ramy czasowe projektu
|
||||||
|
- Brak doświadczenia z publikacją gry w serwisie itch.io - trudności w dodaniu gry na serwis. Pierwotnie miała być to platforma Steam, jednak ze względu na koszty wymagane przez tę platformę (100$) oraz ryzyko niedotrzymania zakładanych terminów, zrezygnowano ze Steam.
|
||||||
|
- Odejście członka zespołu zajmującego się grafiką - trudności w dokończeniu oprawy wizualnej gry
|
||||||
|
- Odejście jednego z członków zajmującego się programowaniem - trudności w implementacji kolejnych funkcjonalności, wynikające z większego nakładu pracy na osobę
|
||||||
|
- Inne
|
||||||
|
- Brak wystarczającego zaangażowania członków zespołu
|
||||||
|
- Nieporozumienia w zakresie implementacji skryptów - ryzyko złego użycia kodu przez osobę, która go nie tworzyła, co może prowadzić do błędów aplikacji
|
||||||
|
|
||||||
|
**10. Kamienie milowe**
|
||||||
|
|
||||||
|
- **Semestr 1**
|
||||||
|
- Przygotowanie prototypu interfejsu
|
||||||
|
- Przygotowanie backlogu dla projektu projektu w systemie JIRA, opracowanie funkcjonalności, user stories
|
||||||
|
- Testy użyteczności interfejsu
|
||||||
|
- Przygotowanie wersji demonstracyjnej gry z dwoma poziomami
|
||||||
|
- **Semestr 2**
|
||||||
|
- Rozwinięcie poziomu pierwszego, którego średni czas przejścia będzie trwał 18 minut, licząc walki z ostatecznym przeciwnikiem – koniec listopada
|
||||||
|
- Utworzenie systemu rozwoju umiejętności (drzewko umiejętności) – koniec grudnia
|
||||||
|
- Wdrożenie aplikacji do platformy z grami – koniec grudnia
|
||||||
|
- Ukończenie aplikacji wraz z zapowiedzianymi funkcjonalnościami – koniec stycznia
|
||||||
110
Przybylski/unity/wizja-proj.md
Normal file
110
Przybylski/unity/wizja-proj.md
Normal file
@ -0,0 +1,110 @@
|
|||||||
|
# **Dokument wizji projektu**
|
||||||
|
|
||||||
|
**Nazwa projektu: Platformowa gra w Unity**
|
||||||
|
|
||||||
|
**Autorzy: Kamil Tyrek, Mateusz Hypś, Jakub Kozubal**
|
||||||
|
|
||||||
|
**Data: 15.11.2020 r.**
|
||||||
|
|
||||||
|
**1. Executive summary (max. 150 słów)**
|
||||||
|
|
||||||
|
Projekt ma na celu stworzenie gry platformowej, której celem będzie zapewnienie graczom rozrywki. Przechodzenie kolejnych etapów gry wymaga zręczności i szybkiego podejmowanie decyzji, dzięki czemu rozgrywka jest ciekawsza i może zaciekawić użytkownika. Grupą docelową jest każda osoba, która chce dobrze spędzić czas. Nie jest wymagana umiejętność czy doświadczenie gracza, gdyż gra wprowadza użytkownika do świata rozgrywki poprzez poziom samouczka. Zyski z gry będą wynikać z korzystania z platformy itch.io, która pozwoli na sprzedaż gry oraz jej aktualizowanie. Portal pozwala na darmowe udostępnienie gry. Ryzykiem jest brak zainteresowania produktem, czego skutkiem będzie brak zysku. Podczas rozgrywki użytkownik będzie walczył z wrogami, wchodził w interakcje z obiektami, rozwiązywał łamigłówki oraz mini-gry.
|
||||||
|
|
||||||
|
**2. Cel i grupa docelowa (min. 150 słów)**
|
||||||
|
|
||||||
|
Celem produktu jest zapewnienie rozrywki dla klienta. Klient, korzystając z naszego produktu, zostanie wprowadzony w świat gry, zostanie mu przedstawiona mechanika gry poprzez samouczek, który będzie przedstawiał kolejne funkcjonalności produktu. Użytkownik w czasie przechodzenia kolejnych etapów będzie musiał wykazywać się zręcznością oraz szybkim podejmowaniem decyzji. W czasie rozgrywki będzie musiał pokonywać między innymi zapadające się pod nim platformy, poruszające się platformy, rozwiązywać łamigłówki, czy też pokonywać mini-gry, których wykonanie nie zawsze będzie obowiązkowe. Wszystkie te aspekty zapewniają, że gra nie polega na prostym przechodzeniu kolejnych etapów i pokonywania wrogów, przez co rozgrywka bardziej wciąga i jest ciekawsza. Grupy docelowe można podzielić na dwie podgrupy: doświadczonych graczy i niedoświadczonych. Pierwsza grupa nie będzie miała problemów z początkową rozgrywką. Nasz produkt, jeśli chodzi o mechanikę, nie wyróżnia się znacznie od innych tego typu gier. Różnice polegają na dodaniu nietypowych elementów, które pojawiają się w czasie przechodzenia etapów, takie jak mini-gry. Drugą grupą są osoby niedoświadczone. Dla takich osób przygotowane jest wprowadzenie – poziom 0. Podczas poziomu dla użytkownika przekazywane są informacje o mechanikach i możliwościach gry. Pozwala to na zaznajomienie się z produktem. Komunikaty są jasne i przedstawione w sposób zrozumiały.
|
||||||
|
|
||||||
|
Chcemy dotrzeć do klientów umieszczając go na platformie itch.io. Jest to platforma z grami typu indie. Umieszczenie tej gry na tej platformie pozwoli na łatwiejszy dostęp do niej oraz możliwość aktualizacji gry przez zespół deweloperski w dowolnym momencie. Ułatwi też kontakt z klientem, który będzie mógł zgłaszać błędy, które wyniknęłyby w trakcie rozgrywki.
|
||||||
|
|
||||||
|
**3. Rynek (min. 3 konkurencyjne produkty)**
|
||||||
|
|
||||||
|
Hollow Knight – Dwuwymiarowa przygodowa gra akcji. Została wyprodukowana przez Team Cherry i wydana w 2017 roku. Gra ta również polega na ratowaniu świata, w tym wypadku przed infekcją bestii. Gra wyróżnia się głównie ręcznie malowanymi sceneriami, które bardzo dobrze trzymają w klimacie. Nasza gra nie posiada wielu ręcznie rysowanych elementów, za to wyróżnia się elementami logicznymi, na które napotyka się użytkownik w trakcie przechodzenia gry.
|
||||||
|
|
||||||
|
Super Meat Boy – Dwuwymiarowa gra zręcznościowa wydana w 2011 roku przez Team Meat. Gra opiera się głównie na elementach zręcznościowych i szybkiej rozgrywce gdyż każdy poziom ma określony czas w którym należy go przejść. Nasza gra wyróżnia się fabułą, która w Super Meat Boy jest dużo bardziej uboga. Super Meat Boy poza elementami zręcznościowymi i mapami tematycznymi do danego etapu gry nie ma za dużo elementów pobocznych w rozgrywce.
|
||||||
|
|
||||||
|
Ori and the blind forest – Dwuwymiarowa gra przygodowa wydana przez studio Microsoft Games. Gra wyróżnia się bardzo starannie ręcznie rysowanymi elementami, fabułą jak i bardzo rozbudowaną rozgrywką. W grze występują również elementy logiczne, dużo pobocznych zadań i zdobywanie nowych umiejętności.
|
||||||
|
|
||||||
|
**4. Opis produktu (min. 3 moduły/epiki)**
|
||||||
|
|
||||||
|
- Moduł głównego menu:
|
||||||
|
- Rozpoczęcie nowej gry
|
||||||
|
- Wczytanie gry z ostatniego zapisu
|
||||||
|
- Dostosowanie:
|
||||||
|
- rozdzielczości
|
||||||
|
- poziomu jasności gry
|
||||||
|
- głośności muzyki i efektów
|
||||||
|
- Włączenie opcji synchronizacji pionowej
|
||||||
|
- Przełączanie między trybem pełnego ekranu z okienkowym
|
||||||
|
- Możliwość zmiany domyślnie przypisanych klawiszy sterownia
|
||||||
|
- Wyjście z gry do pulpitu
|
||||||
|
- Animowane tło
|
||||||
|
- Obszar: Konfiguracja ustawień, Przetwarzanie danych,
|
||||||
|
- Rodzaj: Użytkownicy
|
||||||
|
- Moduł mini-gier:
|
||||||
|
- Obszar: puzzle, rury, otwieranie skarbu
|
||||||
|
- Wyjście z mini-gry
|
||||||
|
- Możliwość restartu puzzli
|
||||||
|
- Rodzaj: Użytkownicy
|
||||||
|
- Moduł poziomów:
|
||||||
|
- Obszar: poziom samouczkowy, poziom 1, poziom do wyborów poziomów:
|
||||||
|
- Możliwość przejścia do następnego poziomu
|
||||||
|
- Odpalenie łamigłówek z interakcją kamery
|
||||||
|
- Walka z wrogami
|
||||||
|
- Rodzaj: Użytkownicy
|
||||||
|
|
||||||
|
**5. Zakres i ograniczenia**
|
||||||
|
|
||||||
|
- **Semestr 1**
|
||||||
|
- Przygotowanie prototypu interfejsu
|
||||||
|
- Przygotowanie backlogu dla projektu projektu w systemie JIRA, opracowanie funkcjonalności, user stories
|
||||||
|
- Testy użyteczności interfejsu
|
||||||
|
- Przygotowanie wersji demonstracyjnej gry z dwoma poziomami
|
||||||
|
- **Semestr 2**
|
||||||
|
- Rozwinięcie poziomu pierwszego, którego średni czas przejścia będzie trwał 18 minut, licząc walki z ostatecznym przeciwnikiem – koniec listopada
|
||||||
|
- Utworzenie systemu rozwoju umiejętności (drzewko umiejętności) – koniec grudnia
|
||||||
|
- Wdrożenie aplikacji do platformy z grami – koniec grudnia
|
||||||
|
- Ukończenie aplikacji wraz z zapowiedzianymi funkcjonalnościami – koniec stycznia
|
||||||
|
- Zespół:
|
||||||
|
|
||||||
|
a) Mateusz Hypś
|
||||||
|
|
||||||
|
§ Projektowanie architektury gry
|
||||||
|
|
||||||
|
§ Tworzenie dokumentacji
|
||||||
|
|
||||||
|
§ Implementacja produktu końcowego
|
||||||
|
|
||||||
|
b) Jakub Kozubal
|
||||||
|
|
||||||
|
§ Projektowanie architektury gry
|
||||||
|
|
||||||
|
§ Tworzenie dokumentacji
|
||||||
|
|
||||||
|
§ Implementacja produktu końcowego
|
||||||
|
|
||||||
|
§ Nadzorowanie testów
|
||||||
|
|
||||||
|
c) Kamil Tyrek
|
||||||
|
|
||||||
|
§ Projektowanie architektury gry
|
||||||
|
|
||||||
|
§ Tworzenie dokumentacji
|
||||||
|
|
||||||
|
§ Tworzenie prototypu opcji
|
||||||
|
|
||||||
|
§ Nadzorowanie testów
|
||||||
|
|
||||||
|
§ Nadzorowanie przebiegiem sprintów – zakładanie zadań, zarządzanie spotkań cotygodniowych
|
||||||
|
|
||||||
|
**Harmonogram na semestr II:**
|
||||||
|
|
||||||
|
- **Listopad**
|
||||||
|
- Poziom do wyboru poziomów
|
||||||
|
- Ekwipunek postaci
|
||||||
|
- Otwieranie skrzyń – mini-gra
|
||||||
|
- Rozwój poziomu 1 o nowe funkcjonalności, rozszerzenie mapy
|
||||||
|
- Stworzenie przeciwnika o rozwiniętych mechanikach, typu boss
|
||||||
|
- **Grudzień**
|
||||||
|
- Stworzenie drzewka umiejętności opartego o trzy gałęzie
|
||||||
|
- **Styczeń**
|
||||||
|
- Stworzenie poziomu do walki z wrogami – fale wrogów, z biegiem czasu przychodzi więcej przeciwników
|
||||||
@ -1,3 +1,7 @@
|
|||||||
# Instrukcja
|
# CARPOOL
|
||||||
|
|
||||||
W tym katalogu należy umieścić dokumenty wizji systemu oraz wymagań projektowych zgodnie z szablonami.
|
## Dokumenty
|
||||||
|
- [Dokument wymagań projektu](docs/project_requirements.md)
|
||||||
|
---
|
||||||
|
## Linki zewnętrzne
|
||||||
|
- [GitHub]("https://github.com/carpool-team/carpool")
|
||||||
216
Zywica/car-pool/docs/project_requirements.md
Normal file
216
Zywica/car-pool/docs/project_requirements.md
Normal file
@ -0,0 +1,216 @@
|
|||||||
|
# Dokument wymagań projektowych
|
||||||
|
|
||||||
|
## Nazwa projektu: Carpool
|
||||||
|
|
||||||
|
## Autorzy: Michał Dulski, Julian Kobryński, Norbert Litkowski, Maciej Sobkowiak
|
||||||
|
|
||||||
|
### 1. Elementy składowe projektu
|
||||||
|
|
||||||
|
#### 1.1 Elementy programistyczne:
|
||||||
|
|
||||||
|
- Aplikacja mobilna dla systemów Android stworzona przy pomocy biblioteki React Native.
|
||||||
|
- Aplikacja mobilna dla systemów iOS stworzona przy pomocy biblioteki React Native.
|
||||||
|
- REST API w języku C# oparty na frameworku .NET 5.
|
||||||
|
- Identity Provider w języku C# i frameworku .NET 5.
|
||||||
|
- Aplikacja webowa w języku TypeScript oparta na frameworku React.
|
||||||
|
- Instancja bazy danych oparta o silnik MSSQL.
|
||||||
|
|
||||||
|
#### 1.2 Elementy nieprogramistyczne:
|
||||||
|
|
||||||
|
- Prototyp aplikacji webowej wykonany przy użyciu Adobe XD,
|
||||||
|
- Prototyp aplikacji mobilnej wykonany przy użyciu Adobe XD,
|
||||||
|
- Opis interfejsu API wykonany przy użyciu Swaggera,
|
||||||
|
- Event Storming wykonany przy użyciu tablicy Miro.
|
||||||
|
|
||||||
|
### 2. Granice projektu
|
||||||
|
|
||||||
|
- Aplikacja mobilna w Apple AppStore – ze względu na ograniczenia budżetowe projektu, nie zdecydowaliśmy się na umieszczenie aplikacji w AppStore. Aplikacja będzie dostępna na platformie Google Play
|
||||||
|
- Chat wewnątrz aplikacji – chcemy, aby aplikacja była jak najbardziej wyspecjalizowana. Ze względu, że użytkownicy korzystający z przejazdów wewnątrz jednej grupy najczęściej znają się, mają też prawdopodobnie kontakt w innej aplikacji do komunikacji tekstowej.
|
||||||
|
- Przejazdy poza grupami – aplikacja skierowana jest do grup znajomych lub pracowników z jednej firmy. Zdecydowaliśmy, że przejazdy będą możliwe jedynie wewnątrz takich grup, gdyż do przejazdów między obcymi ludźmi istnieje wiele konkurencyjnych rozwiązań.
|
||||||
|
- Aplikacja nie przewiduje rejestracji korporacyjnych lub grupowych. Każdy z użytkowników tworzy konto samodzielnie. Może natomiast zostać po rejestracji dodany do firmowej grupy.
|
||||||
|
- System nie będzie obsługiwał rozliczeń między uczestnikami przejazdów. Będą one z założenia dokonywane między zainteresowanymi.
|
||||||
|
|
||||||
|
### 3. Lista wymagań funcjonalnych
|
||||||
|
|
||||||
|
1. Jako użytkownik mogę stworzyć konto w aplikacji,
|
||||||
|
2. Jako użytkownik mogę zalogować się do aplikacji używając loginu i hasła,
|
||||||
|
3. Jako użytkownik mogę wylogować się z aplikacji,
|
||||||
|
4. Jako użytkownik mogę usunąć swoje konto,
|
||||||
|
5. Jako użytkownik mogę edytować swoje dane w aplikacji,
|
||||||
|
6. Jako użytkownik mogę łatwo przełączać tryby aplikacji (tryb pasażera lub kierowcy),
|
||||||
|
7. Jako użytkownik mogę przeglądać otrzymane zaproszenia do grup,
|
||||||
|
8. Jako użytkownik mogę akceptować lub odrzucać zaproszenia do grup,
|
||||||
|
9. Jako użytkownik mogę przeglądać grupy, do których należę,
|
||||||
|
10. Jako użytkownik mogę wyświetlić szczegóły dowolnej grupy, do której należę,
|
||||||
|
11. Jako użytkownik mogę opuścić grupę,
|
||||||
|
12. Jako użytkownik mogę stworzyć nową grupę,
|
||||||
|
13. Jako administrator mogę zapraszać użytkowników do grupy,
|
||||||
|
14. Jako administrator mogę usuwać członków grupy,
|
||||||
|
15. Jako administrator mogę przeglądać zaplanowane przejazdy w grupie,
|
||||||
|
16. Jako administrator mogę przeglądać odbyte przejazdy w grupie,
|
||||||
|
17. Jako administrator mogę edytować dane grupy,
|
||||||
|
18. Jako administrator mogę usunąć grupę,
|
||||||
|
19. Jako administrator mogę wygenerować raport działalności grupy w wybranym przedziale czasowym,
|
||||||
|
20. Jako pasażer mogę przeglądać przejazdy w grupach,
|
||||||
|
21. Jako pasażer mogę wysyłać prośby o dołączenie do przejazdu,
|
||||||
|
22. Jako pasażer mogę przeglądać przejazdy, do których jestem zapisany,
|
||||||
|
23. Jako pasażer mogę przeglądać przejazdy, w których uczestniczyłem,
|
||||||
|
24. Jako pasażer mogę przeglądać szczegóły przejazdu,
|
||||||
|
25. Jako pasażer mogę zrezygnować z przejazdu, na który się zapisałem,
|
||||||
|
26. Jako kierowca mogę tworzyć przejazdy jednorazowe lub regularne,
|
||||||
|
27. Jako kierowca mogę wyświetlać prośby o dołączenie do przejazdu,
|
||||||
|
28. Jako kierowca mogę akceptować lub odrzucać prośby o dołączenie do przejazdu,
|
||||||
|
29. Jako kierowca mogę wyświetlać zaplanowane przejazdy,
|
||||||
|
30. Jako kierowca mogą wyświetlać odbyte przejazdy,
|
||||||
|
31. Jako kierowca mogę wyświetlić szczegóły przejazdu,
|
||||||
|
32. Jako kierowca mogę usuwać pasażerów z przejazdu,
|
||||||
|
33. Jako kierowca mogę anulować przejazdy,
|
||||||
|
|
||||||
|
### 4. Lista wymagań niefuncjonalnych
|
||||||
|
|
||||||
|
1. Internacjonalizacja – system musi posiadać lokalizowane zasoby tekstowe
|
||||||
|
2. Dostępność - aplikacja mobilna musi być dostępna dla systemów Android 4.4 (API 19+), ze względu na to, że wsparcie dla tej wersji wzwyż zapewnia obsługę większości użytkowników systemu Android
|
||||||
|
3. Dostęp do repozytorium kodu - repozytorium kodu systemu będzie publicznie dostępne
|
||||||
|
4. Aplikacja webowa dostępna dla przeglądarek mobilnych oraz desktopowych - MS Edge, Firefox, Chrome, Safari, Opera
|
||||||
|
5. Autoryzacja tradycyjna w oparciu o JWT
|
||||||
|
|
||||||
|
### 5. Mierzalne wskaźniki wdrożeniowe
|
||||||
|
|
||||||
|
- Aplikacja webowa zostanie udostępniona na domenie carpool.com.pl i za jej pomocą w systemie zostanie utworzone co najmniej 5 grup obejmujących co najmniej 25 użytkowników.
|
||||||
|
- W obrębie każdej grupy zostanie wykonany co najmniej jeden przejazd.
|
||||||
|
- Aplikacja mobilna zostanie udostępniona na Google Play i będzie z niej korzystać co najmniej 20 osób.
|
||||||
|
- REST API zostanie poddane testom obciążeniowym, które zapewnią, że maksymalny czas odpowiedzi z serwera dla nie więcej niż 100 użytkowników jednoczenie nie przekroczy 2 sekund
|
||||||
|
|
||||||
|
### 6. Kryteria akceptacji projektu dla I semestru prac
|
||||||
|
|
||||||
|
#### 1. Wymagane
|
||||||
|
|
||||||
|
- Prototyp aplikacji
|
||||||
|
- Możliwość tworzenia grup z poziomu aplikacji webowej
|
||||||
|
- Spójna stylistycznie z prototypem aplikacja webowa
|
||||||
|
- Możliwość tworzenia przejazdów w aplikacji mobilnej
|
||||||
|
- Możliwość zapisu na istniejące przejazdy w aplikacji mobilnej
|
||||||
|
- Spójna stylistycznie z prototypem aplikacja mobilna
|
||||||
|
- Serwer REST API obsługujący obie aplikacje
|
||||||
|
- Zintegrowanie REST API z bazą danych
|
||||||
|
|
||||||
|
#### 2. Oczekiwane
|
||||||
|
|
||||||
|
- Wyświetlanie lokalizacji grup i punktów odbioru na mapie
|
||||||
|
- Wdrożenie aplikacji webowej na Azure
|
||||||
|
- Wdrożenie serwera REST API na Azure
|
||||||
|
|
||||||
|
#### 3. Planowane
|
||||||
|
|
||||||
|
- Zapraszanie użytkowników do dołączenia do grupy w aplikacji webowej
|
||||||
|
- Wyświetlanie informacji o grupach w aplikacji mobilnej
|
||||||
|
|
||||||
|
### 7. Kryteria akceptacji projektu dla II semestru prac
|
||||||
|
|
||||||
|
#### 1. Wymagane
|
||||||
|
|
||||||
|
- Możliwość tworzenia kont użytkowników z poziomu aplikacji mobilnej i webowej
|
||||||
|
- Identity provider zapewniający dostęp do zasobów REST API
|
||||||
|
- Zarządzanie grupami (edycja danych grupy, dodawanie/usuwanie użytkowników należących do grupy, wyświetlanie przejazdów odbywających się w danej grupie)
|
||||||
|
- Możliwość wyświetlania danych o odbytych przejazdach w aplikacjach mobilnej i webowej
|
||||||
|
- Możliwość tworzenia przejazdów i zarządzania nimi w aplikacjach mobilnej i webowej
|
||||||
|
- Pozytywne zakończenie testów obciążeniowych REST API
|
||||||
|
- Wymagania funkcjonalne: 1, 2, 3, 4, 6, 8, 11, 12, 13, 14, 17, 20, 21, 26, 27, 28, 31, 32, 33
|
||||||
|
|
||||||
|
#### 2. Oczekiwane
|
||||||
|
|
||||||
|
- Generowanie raportów podsumowujących przejazdy w danej grupie
|
||||||
|
- Udostępnienie aplikacji webowej na domenie carpool.com.pl
|
||||||
|
- Udostępnienie aplikacji mobilnej w sklepie Google Play
|
||||||
|
- Testy akceptacyjne aplikacji mobilnej
|
||||||
|
- Testy akceptacyjne aplikacji webowej
|
||||||
|
- Wymagania funkcjonalne: 5, 7, 9, 10, 15, 17, 18, 19, 22, 23, 24, 25, 29, 30, 33
|
||||||
|
|
||||||
|
#### 3. Planowane
|
||||||
|
|
||||||
|
- Możliwość logowania się przy użyciu konta Google
|
||||||
|
- Podział kosztów na uczestników przejazdu wewnątrz systemu
|
||||||
|
- Identity provider ma umożliwić uwierzytelnianie przy użyciu zewnętrznych dostawców tożsamości (Google, Facebook)
|
||||||
|
|
||||||
|
### 8. Organizacja pracy zespołu
|
||||||
|
|
||||||
|
#### Zespół projektowy
|
||||||
|
|
||||||
|
- Maciej Sobkowiak - Product Owner, Web Developer
|
||||||
|
|
||||||
|
- Zarządzanie zadaniami w projekcie
|
||||||
|
- Projektowanie prototypu aplikacji webowej
|
||||||
|
- Implementacja aplikacji webowej
|
||||||
|
|
||||||
|
- Michał Dulski – Backend Developer
|
||||||
|
|
||||||
|
- Projektowanie architektury serwera REST API
|
||||||
|
- Implementacja aplikacji serwera REST API
|
||||||
|
- Implementacja identity provider’a
|
||||||
|
- Zarządzanie zasobami platformy chmurowej
|
||||||
|
- Kontakt z klientem
|
||||||
|
|
||||||
|
- Norbert Litkowski – Web Developer
|
||||||
|
|
||||||
|
- Projektowanie architektury aplikacji webowej
|
||||||
|
- Implementacja aplikacji webowej
|
||||||
|
- Integracja aplikacji webowej z platformą chmurową
|
||||||
|
|
||||||
|
- Julian Kobryński – Mobile Developer
|
||||||
|
- Projektowanie prototypu aplikacji mobilnej
|
||||||
|
- Implementacja aplikacji mobilnej
|
||||||
|
- Projektowanie architektury aplikacji mobilnej
|
||||||
|
|
||||||
|
#### Kontakt z klientem
|
||||||
|
|
||||||
|
Organizujemy regularne spotkania z klientem, na których przedstawiamy postępy, które poczyniliśmy od ostatniego spotkania i dyskutujemy o planach na dalszy rozwój aplikacji. Prezentujemy również nasze pomysły na zmiany lub usprawnienia w aplikacji oraz ewentualne problemy, które napotkaliśmy.
|
||||||
|
|
||||||
|
#### Cykl życia zdania w projekcie
|
||||||
|
|
||||||
|
Każde zadanie po powstaniu umieszczane jest w kolumnie “To Do”, a następnie jest przypisywane do osoby, która będzie odpowiedzialna za jego zrealizowanie. Kiedy programista rozpoczyna prace nad zadaniem przenosi je do kolumny “In Progress”. Wykonane zadanie trafia do kolumny “QA” (Quality Assurance) i tworzony jest Pull Request. Inny członek zespołu przygląda się zmianom wprowadzonym w związku z danym zadaniem i jeśli uważa, że zostało wykonane prawidłowo, akceptuje Pull Request i kod trafia na główną gałąź w repozytorium, a zadanie do kolumny “Done”.
|
||||||
|
|
||||||
|
#### Metodyka pracy
|
||||||
|
|
||||||
|
Metodyka pracy, według której realizujemy projekt od samego początku to klasyczny Scrum. W początkowej fazie projektu wypełniliśmy backlog i oszacowaliśmy wszystkie zadania. Organizujemy dwutygodniowe sprinty, do których przydzielamy kilka zadań z backlogu. Zdecydowaliśmy się na tę metodykę, ponieważ została ona nam zasugerowana oraz dokładnie wytłumaczona przez promotora projektu i uważamy, że jest najbardziej skuteczna.
|
||||||
|
|
||||||
|
#### Narzędzia wspomagające
|
||||||
|
|
||||||
|
- Aplikacja webowa – przy każdym commicie na główną gałąź w repozytorium uruchamiany aplikacja jest budowana w chmurze Azure. Jeśli build zakończy się sukcesem, uruchamia się release pipeline, który ten build umieszcza w odpowiednim folderze na serwerze
|
||||||
|
- Aplikacja serwerowa – przy każdym commicie na główną gałąź repozytorium uruchamiany jest workflow w GitHub Actions, który najpierw buduje aplikację, a następnie publikuje aplikację webową w chmurze Azure oraz dodaje logi całej operacji w chmurze.
|
||||||
|
|
||||||
|
- [Repozytorium kodu](https://github.com/carpool-team/carpool) - korzystamy z publicznego repozytorium na platformie GitHub
|
||||||
|
|
||||||
|
- [Jira](https://jira.wmi.amu.edu.pl/secure/RapidBoard.jspa?rapidView=281&projectKey=CARP&view=planning.nodetail) - służy nam do planowania pracy w oparciu o metodykę Agile
|
||||||
|
|
||||||
|
### 9. Ryzyka projektowe
|
||||||
|
|
||||||
|
- Określone ramy czasowe na stworzenie projektu okazały się nie wystarczające do całkowitego stworzenia aplikacji.
|
||||||
|
- Brak osób zainteresowanych korzystaniem z aplikacji –wymagane samodzielne korzystanie i testowanie aplikacji przez członków zespołu.
|
||||||
|
- Projekt jest o podwyższonym stopniu ryzyka ze względu na sytuację pandemiczną na świecie w związku z rozprzestrzenianiem się wirusa COVID-19. W związku z powyższym, testy z udziałem prawdziwych użytkowników mogą nie być możliwe do wykonania.
|
||||||
|
- Nieporozumienia w zespole dotyczące rozwiązań implementacyjnych, architektury, funkcjonalności lub używanych technologii
|
||||||
|
- Odejście członka zespołu - w zależności osoby, problem w ukończeniu składowej projektu.
|
||||||
|
- Brak doświadczenia w wdrażaniu aplikacji serwerowej na platformy chmurowe.
|
||||||
|
- Brak zaangażowania w projekt ze strony członków zespołu (niedostarczanie funkcjonalności na czas, brak komunikacji)
|
||||||
|
- Nagły brak wsparcia jednej z wykorzystywanych technologii lub narzędzia –konieczność zmiany narzędzi/technologii i implementacja funkcjonalności od zera w oparciu o nowe rozwiązanie albo modyfikacja obecnie istniejących funkcjonalności, aby działały z nowo wybraną technologią/narzędziem.
|
||||||
|
|
||||||
|
### 10. Kamienie milowe
|
||||||
|
|
||||||
|
#### Faza 1 (I semestr), do czerwca 2020:
|
||||||
|
|
||||||
|
- Przygotowanie prototypu aplikacji mobilnej
|
||||||
|
- Wypełnienie backlogu w systemie Jira
|
||||||
|
- Rozpoczęcie prac programistycznych nad aplikacją serwerową, webową i mobilną
|
||||||
|
- Utworzenie zasobów do hostowania bazy danych, aplikacji webowej i aplikacji serwerowej na platformie Azure
|
||||||
|
- Ukończenie MVP projektu
|
||||||
|
- Wdrożenie MVP aplikacji serwerowej na platformę Azure
|
||||||
|
|
||||||
|
#### Faza 2 (II semestr), do stycznia 2021:
|
||||||
|
|
||||||
|
- Ukończenie zaplanowanych funkcjonalności w aplikacji mobilnej, webowej i serwerowej
|
||||||
|
- Utworzenie zasobów do hostowania identity provider’a na platformie azure
|
||||||
|
- Konfiguracja narzędzi ciągłej integracji (CI) dla aplikacji serwerowej REST API
|
||||||
|
- Konfiguracja narzędzi ciągłej integracji (CI) dla identity provider’a
|
||||||
|
- Konfiguracja narzędzi ciągłej integracji (CI) dla aplikacji webowej
|
||||||
|
- Opublikowanie aplikacji mobilnej w Play Store
|
||||||
|
- Stworzenie testów dla aplikacji webowej i serwerowej
|
||||||
|
- Opublikowanie aplikacji webowej w domenie internetowej
|
||||||
Binary file not shown.
BIN
Zywica/pickup/Project Requirements.pdf
Normal file
BIN
Zywica/pickup/Project Requirements.pdf
Normal file
Binary file not shown.
BIN
Zywica/travellan/Travellan - project requirements.docx.pdf
Normal file
BIN
Zywica/travellan/Travellan - project requirements.docx.pdf
Normal file
Binary file not shown.
BIN
Zywica/ulti-tracker/UltiTracker - wymagania projektowe.pdf
Normal file
BIN
Zywica/ulti-tracker/UltiTracker - wymagania projektowe.pdf
Normal file
Binary file not shown.
BIN
templates/~$oject-requirements.docx
Normal file
BIN
templates/~$oject-requirements.docx
Normal file
Binary file not shown.
Loading…
Reference in New Issue
Block a user