Merge branch 'master' into master

This commit is contained in:
Dawid Wietrzych 2021-01-16 13:26:14 +01:00
commit 2b7355875f
51 changed files with 2486 additions and 2 deletions

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

View 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.

View 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ę

View File

@ -0,0 +1,157 @@
# Dokument wizji projektu
#### Nazwa projektu: Solomonoff
#### Autorzy: Aleksander Mendoza, Bogdan Bondar, Marcin Jabłoński
#### Data: 13.12.2020
### 1\. Executive summary
This project focuses on research in the field of automata theory and inductive inference. While many existing libraries already provide support for general purpose automata and implement various related algorithms, this project takes a slightly different approach. The primary tool for working with the library, is through doman specific language of regular expressions. Most of the things can be done without writing even a single line of Java code.
The main applications concern formal methods, natural language processing, state-based system modeling, pattern recognition, inductive inference and machine learning. It can be of great help for researchers as well as can be used on industrial scale.
The greatest competitor for Solomonoff is Google's OpenFST project. Solomonoff introduces dozens of improvements. The most important being efficiency improvements, symbolic ranges, nondeterminism detection and type system.
### 2\. Goal and target audience
The goal is provide an better alternative for OpenFST. Solomonoff strives to provide improvement in the following domains:
- OpenFst has Matcher that was meant to compactify ranges. In Solomonoff all transitions are ranged and follow the theory of symbolic automata. They are well integrated with regular expressions and Glushkov's construction. They allow for more efficient squaring and subset construction. Instead of being an ad-hoc feature, they are well integrated everywhere.
- OpenFst has no built-in support for regular expression and it was added only later in form of Thrax grammars, that aren't much more than another API for calling library functions. In Solomonoff the regular expressions are the library. Instead of having separate procedures for union, concatenation and Kleene closure, there is only one procedure that takes arbitrary regular expression and compiles it in batch. This way everything works much faster, doesn't lead to introduction of any ε-transitions (in Solomonoff, ε-transitions aren't even implemented, because they were never needed thanks to Glushkov's construction). This leads to significant differences in performance. You can see benchmarks below.
- Many operations are implemented in "better" way. For example
- Solomonoff has no need for ArcSort because all arcs are always sorted
- Solomonoff has no Optimise because compiler decides much better when to optimise things
- Solomonoff has no RmEpsilon, because it has no epsilons in the first place
- Solomonoff has no CDRewrite because the same effect can be achieved much more efficeintly with lexicographic weights and Kleene closure.
- In OpenFST if you perform `("a":"b"):"c"` you get as a result `"b":"c"`. OpenFST treats : as a binary operation. Solomonoff on the other hand treats : as unary operation. `("a":"b"):"c"` results in `"a":"bc"`. In fact `:'b'` is treated as `'':'b'` and `'a':'b'` is merely a syntactic sugar for 'a' '':'b'. You can write for example :'b' 'a'. The strings prefixed with : are the output strings, whereas strings without : are the input strings. You can very easily perform inversion of automaton by turning input strings into output strings and vice-versa. For example in Thrax you have `Inverse["a":"b"]` which results in `"b":"a"`. In Solomonoff the inverse of `'a':'b'` becomes `:'a' 'b'`. Very stright-forward. The semantics of `:` in OpenFST strip the output of the left-hand side. In fact, `X:Y` in OpenFST translates more literally to `stripOutput[X]:Y` in Solomonoff.
- Thrax supports so called "temporary"/"outside of alphabet" symbols. Any time you write `"[NEW_SYMBOL]"` it will take some large UNICODE codepoint hoping that it's not used anywhere else. In Solomonoff this is not necessary, because using type system is much better suited for this task. You can just write
x = 'abcd' // some regex
x <: [a-z]* //ensure that it uses specific alphabet
z = x <404> x // use codepoint 404 as some "external symbol"
z <: ([a-z]|<404>)*
Opis celu powstania projektu powinien w szczególności odpowiadać na następujące pytania:
- Solomonoff is much fater. Results of benchmarks on a large linguistic dictionary are as follows. Thrax compiles in 19 minutes, while Solomonoff in just 4 seconds. OpenFST executes in 250 milliseconds, while Solomonoff in 5 milliseconds. FAR file takes up 27M while Solomonoff's archive only 552K. OpenFST takes up 6336K in RAM, whole Solomonoff only 738K. OpenFST is written in C++, while Solomonoff in Java, so our implementation performs better despite being disadvantaged.
The project found approval among members of Samsung's R&D team for Bixby developement and inductive inference researchers from Dortmund Technical University, Germany.
### 3\. Market
Currently there exists only one serious alternative, which is openfst library with their Thrax extension for writing regex-like grammars. Their solution has numerous problems. It's focus on probabilistic approach to modeling nondeterminism, made the library quite slow. It also became a double-edged sword, by making rule-based system difficult to maintain (compiler doesn't warn programmer when nondeterminism causes some rules to overshadow others). Compilation of grammars is lacking in many aspects. The grammar expression language is very basic and obscure. Compiler is not parallized and highly inefficient. On top of that, the probabilistic approach.
Our solution completely gets rid of nondeterminism. We will not attempt to model any probabilistic models. We will focus more heavily on making the expression language user-friendly and helpful in detecting potential non-determinism. The compiler should be able to process multiple rules in parallel to make compilation time faster. We could also take advantage of guarantees of determinism. There are many optimisations to be made thanks to this. The end goal is to make the whole system work in linear time and linear space.
For better user experience and easier management of code, we add build system and basic package manager (although, we don't provide centralised package repository)
Our project has been noticed by other researchers. We will work together with Dortmund University and make Solomonoff publicly available.
There used to be another similar project, developed by AT&T but it's been long discontinued and replaced by OpenFST. Aside from that, the market is extremely niche. There do not exist any other tools (or at least, they are not available publicly). The closest other competitors might include general-purpose automata libraries like Google's RE2 or Anders Møller's BRICS library. However, those projects are fundamentally different as they implement classical automata instead of tranasducers.
### 4\. Product description
A simple and efficient library written in C will be the main and primary component of our product. On top of that, it will have command-line interface equipped with compiler. For easy and quick access, we should support online repl for all curious people who want to give our library a try. The compiler should support parallelism, warn user about non-determinism and allow for possibly some extent of generic programming (by defining functions working on regular expressions or bulk-generation of rules according to some regularities). We should ,however pay extra attention, to not making this language turing complete/undecidable by accident (otherwise compilation might never end).
- simple and efficient library written in Java
- essential functions for operations of
- concatenation
- Kleene closure
- union
- composition
- projection
- additional less important operations
- inverse
- composition
- algorithms of inference
- type system
- integration with LearnLib
- is optimised for functional ranged transducers (so called symbolic automata)
- REPL and build system
- support for parallelism
- non-determinism warnings
- packaging system
- dependency resolver
- supports everything that compiler does
- additional directives
- online repl
- can write regular expressions on-the-fly
- can test for determinism without constructing automata (it's more efficient)
- user can download effects of their work for their local computer
Proposed architecture (one of possible ways we could implement it):
- there is all theoretical work and background written in our PDF
- theoretical paper serves as basis for formal specification of library functions
- Java compiler - everything can be done from regualr expressions. User does not need to write a single Java line to use the compiler.
- REPL is extensions of compiler itself and shares codebase
- build system is developed and shipped independently from compiler
package manager is intergrated with build system and shares common codebase
- online REPL is built by compiling Java compiler with JWebAssembly
- backend in Spring
- website with basic info, documentation, examples and tutorials
YouTube channel and blog contain additional resources. They help us to promote the library and attract users.
Our target audiences include:
- researchers who want to:
- have some ready-made library with functionalities they need for experiments.
- verify formal properties of complex sequential systems
- linguists
- working on rule-based translation
- machine-learning experts
- who work in fields related to natural language processing
who use Solomonoff inference
- Companies developing artifical inteligence systems
who might use it as one of their tools. (Especially if their employees are any of the people above)
### 5\. Scope and limitations
Time is our most valuable resource. If we start running out of it, we might drop support for formal specification and/or transducers. By the end of semester we should have working library, although there is no guarantee that it will be optimised. Optimisations should be ready by the end of second semester, though. There should also be a working basic version of expression language and compiler for it by the end of first semester. We should also have more-or-less working prototype of online repl, although the extent of what "working" means depends heavily on state of library.
Work schedule:
- first semester
- formal specification
- C library prototype (unoptimised)
- compiler prototype
- online repl prototype (with dummy compiler functionality)
- second semester
- optimised Java compiler
- compiler usable in practice and tested on real life users
- online repl integrated with compiler
- machine learning algorithms
- build system
- packaging system
Team:
- Aleksander Mendoza
- formal specification and theoretical foundations
- compiler implementation (Java)
- Bogdan Bondar
- web design (Bootstrap)
- backend development (Spring)
- Marcin Jabłoński
- build system (Java)
- REPL (ANTLR)
- assisting with compiler implementation

View File

@ -0,0 +1,138 @@
# Project Vision Document
### Project name: Solomonoff
### Authors: Aleksander Mendoza, Bogdan Bondar, Marcin Jabłoński
### Date: 13.12.2020
#### 0\. Document version
- 13.12.2020 - initial version
#### 1\. Project's components (project's products)
- simple and efficient library written in Java
- essential functions for operations of
- concatenation
- Kleene closure
- union
- composition
- projection
- additional less important operations
- inverse
- composition
- algorithms of inference
- type system
- integration with LearnLib
- is optimised for functional ranged transducers (so called symbolic automata)
- REPL and build system
- support for parallelism
- non-determinism warnings
- packaging system
- dependency resolver
- supports everything that compiler does
- additional directives
- online repl
- has all features of the compiler itself
- user can download effects of their work for their local computer
- syntax highlighting
- documentation and code samples
- theory and specification
- scientific papers explaining the theory with appropriate mathematical rigour
- papers with proofs of correctness of essential algorithms
- specification of algorithms expressed with assertions, deeply checked with runtime analysis
#### 2\. Project limitations
There are not many limitations in our project. It does not require keeping track of userbase, by using Java we do not impose any restrictions on operating systems and most importantly, we support most of the required features. Some users might feel restricted by not being able to define nondeterministic transducers but in reality it's for the better. Solomonoff has certain restrictions, that are there by design and in practice, they should not be a major issue. We do not support probabilistic transducers, but it's because probabilities do not play well with manually crafted regular expressions and they may lead to unstable solutions in the long term. Solomonoff also hides most of its API from user. Only very minimalist Java methods are exposed and transducers should not be manipulated programmatically. This also is by design, because Solomonoff puts heavy emphasis on the language of regular expressions. It embeds regexes in a special vernacular language that more than compensates lack of programmatic API. It also makes the system more user friendly as a whole.
#### 3\. List of functional requirements
- basic usage via regular expressions: union, concatenation, kleene closure, composition, inversion
- advanced usage via extensibility and native functions: Glushkovs construction supports calls to extenal functions
- ease of setup and efficient compilation: easy to use build system
- user firendly REPL from web browser without any required setup: compiler integrated in form of a library used by Spring backend
#### 4\. List of non-functional requirements
- scientific papers describing the theory in detail
- end user tests
- integration in Samsung
- integration with LearnLib
- performance benchmarks
#### 5\. Measurable indicators
- efficiency benchmarks on large datasets of regular expressions
- RAM usage
- disk usage
- execution speed
- compilation speed
- parallel compilation
- prepackaged executable avaiable for download
- unit tests
- user experience feedback
#### 6\. Acceptation criteria for first semester
- basic regular expressions: union, concatenation, kleene closure
- basic online playground with syntax highlighter and WebAssembly
- prototype of type system and weighted automata
#### 7\. Acceptation criteria for second semester
- extended regular expressions
- optimised compiler
- inductive inference algorithms
- build system
- REPL
- online playground with backend, docs, samples and tutorials
#### 8\. Project work organization
- Aleksander Mendoza (Product owner)
- Glushkov's construction
- weighted transducers
- inductive inference
- nondeterministic minimization
- Bogdan Bondar (implementation)
- backend
- frontend
- compiler integration
- Marcin Jabłoński (implementation)
- build system
- repl
- dependency resolver
Aleksander Mendoza is responsible for finding clients and communicating with them.
Initially our team attempted to use Scrum, but later we switched to incremental methodology, because workflow relied heavily on specification and long-term planning. Scrum's main advantage lies in its flexibility, which wasn't the key for this project. It also imposed unrealistic and unnatural team dynamics, which only made work more complicated than it had to be. Scrum gives all team memebrs high degree of independence and autonomy. In scrumchat, implementators describe the progress they made. On the other hand, in our project the specification is more rigid and work progresses according to it. Hence, it's always well understood who does what at what moment. The future tasks are generally known ahead of time.
Tools:
- JIRA
- git & GitHub
We do not use continous integration, as the project is not meant to be continuously integrated at all. Compiler and library is released in versions.
REPL and website are meant to follow this versioning as well.
#### 9\. Project risks
The most important risk of our project was its heavy reliance on advanced theoretical concepts. It required plenty of rigour to make sure our foundations are correct and well defined. Should anything in our understanding of automata be wrong, the whole project would at risk of becoming irrelevant.
The second most critical concern was time. There was plenty to do and very little time. It was haard to estimate how much time any of the tasks would take. While missing initial deadlines due to unforseen complications is typical for software engineering projects, our project was exposed to a such risks at a much larger scale. Should anything be wrong in the formal specification, it could require months of additional research. In the worst case, if there was a mistake, some goals might turn out to be mathematically impossible. For this reason our team had to be rigorous about their promises.
There was little risk with respect to technologies, although the most significant one was chosing the appropriate infrastructure for an open-source non-profit project. We can't bear large costs of maintenance, therefore we used open-source and free resources as much as possible. While in the end the project had to switch from WebAssembly to using backend, we hope that in the long-trem we will find hosting sponsored by some research institution. In the worst case, should we not get any sponsorship, the most of the project is resilient and can still remain relevant even without backend. The web interface could be then treated as an optional addition, that user can download and run locally as an alternative to terminal-based interface.
#### 10\. Milestones
- proof of concept and first implementation of Glushkov's construction (Deadline: end of first semester)
- proof of concept for type system (Deadline: end of first semester)
- establishing relations with Dortmund University
- preparing code for adoption in Samsung. It requires writing a very specific feature that allows for converting legacy codebase from Thrax to Solomonoff. (Deadline: end of 2020)
- getting build system ready (Deadline: end of 2020)
- testing (Deadline: end of January 2021)
- full integration in Samsung (Deadline: February 2021)

View 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.

View 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

View File