Merge branch 'master' into master

Przybylski/awionika/wizja_projektu.md

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

Przybylski/awionika/wymagania_projektowe.md

@@ -0,0 +1,515 @@
+---
+author:
+- Wojciech Kubiak
+- Piotr Józefowicz
+- Sebastian Wawrzyn
+title: 
+- Dokument wymagań projektowych
+---
+
+# Elementy składowe projektu (produkty projektu)
+
+## Semestr I
+
+-   Aplikacja webowa
+
+-   Komputer pokładowy (MVP)
+
+-   Aplikacja serwerowa - REST API (WEB)
+
+-   Relacyjna baza danych
+
+-   Prototyp interfejsu użytkownika aplikacji webowej
+
+-   Repozytorium git zawierające kod aplikacji, API, elektroniki
+
+-   Tablica projektowa -- Trello
+
+## Semestr II
+
+-   Komputer pokładowy
+
+-   Nadajnik
+
+-   Odbiornik
+
+-   Wizytówka
+
+-   Aplikacja webowa
+
+-   Aplikacja desktopowa
+
+-   Aplikacja serwerowa lokalna
+
+-   Baza danych NoSql
+
+# Granice projektu
+
+-   Produkty zawarte:
+
+    -   1\. Wyszczególnione produkty projektu
+
+-   Funkcjonalności nie zawarte:
+
+    -   Integracja z systemem APRS, wiele urządzeń lokalizacyjnych ma tę
+        funkcję, jednak zaimplementowanie jej jest zbyt czasochłonne.
+
+    -   Integracja z innymi komputerami pokładowymi, format danych różni
+        się w zależności od komputera.
+
+# Lista wymagań funkcjonalnych
+
+## Komputer pokładowy
+
+-   Dokonywanie pomiarów telemetrycznych (barometr, żyroskop,
+    akcelerometr)
+
+-   Zapis danych na flash (format tekstowy)
+
+-   Odpalenie zapalnika elektrycznego
+
+-   Automatyczne wyzwolenie separacji za pomocą barometru w apogeum
+
+-   Wyzwolenie separacji na żądanej wysokości
+
+-   Konfiguracja/kontrola modułu:
+
+    -   zmiana parametrów uruchomieniowych
+
+    -   odczyt danych z flash
+
+    -   czyszczenie pamięci flash
+
+## Nadajnik/Lokalizator
+
+-   Lokalizacja GPS oraz redundantny system prędkości wysokości
+    przyspieszenia
+
+-   Komunikacja bezprzewodowa LORA (połączenie jednokierunkowe)
+
+-   Konfiguracja/kontrola modułu:
+
+    -   zmiana parametrów uruchomieniowych
+
+    -   odczyt danych z flash
+
+    -   czyszczenie pamięci flash
+
+## Aplikacja internetowa
+
+-   Logowanie za pomocą Auth0
+
+-   Wizytówka koła:
+
+    -   informacje o kole
+
+    -   formularz kontaktowy
+
+    -   prezentacja projektów koła
+
+-   Zarządzanie użytkownikami na koncie administratora:
+
+    -   dodawanie i usuwanie użytkowników
+
+    -   zmiana danych użytkownika
+
+    -   nadawanie i odbieranie uprawnień użytkownikom
+
+-   Dodawanie pomiarów z pliku (json, csv)
+
+-   Wyświetlanie danych z testów (wykresy)
+
+-   Przegląd danych historycznych
+
+-   Wyświetlanie testów historycznych w postaci live
+
+-   Zintegrowania aplikacji webowej z REST API
+
+-   Eksport testów do plików (json, excel)
+
+-   Eksport trajektorii lotu rakiety do pliku KML (Google earth)
+
+-   Profil użytkownika, możliwość zmiany nazwy użytkownika, imienia,
+    nazwiska, e-maila, hasła
+
+## Aplikacja desktopowa
+
+-   Wyświetlanie danych z testów live (wykresy)
+
+-   Wyświetlanie lokalizacji za pośrednictwem Google Maps
+
+-   Konfigurowanie modułów elektronicznych
+
+-   Odczyt/Zapis danych z modułów elektronicznych
+
+-   Wysyłanie testów na serwer
+
+-   Zapis pomiarów w plikach json
+
+## Aplikacja serwerowa, REST API
+
+-   Dodanie serwisów REST pozwalających na operacje wymienione w punkcie
+    "Aplikacja internetowa"
+
+-   Dodanie serwisów REST pozwalających na operacje wymienione w punkcie
+    "Aplikacja desktopowa"
+
+-   Zintegrowanie API z bazą danych
+
+-   Wdrożenie aplikacji na środowisko testowe
+
+-   Wdrożenie aplikacji na środowisko produkcyjne
+
+## Elektronika naziemna (odbiornik)
+
+-   Odbieranie danych od komputera pokładowego (LORA)
+
+-   Przekazywanie danych do serwera za pomocą REST API
+
+-   Przekazywanie danych do kolejnych urządzeń za pomocą Seriala
+
+-   Konfiguracja/kontrola modułu:
+
+    -   zmiana parametrów uruchomieniowych
+
+# Lista wymagań niefunkcjonalnych
+
+## Komputer pokładowy
+
+-   Bezpieczny w użyciu
+
+-   Prosty w użyciu
+
+-   Niezawodny
+
+-   Dokładny
+
+-   Z czytelnym, przejrzystym kodem
+
+-   Technologie:
+
+    -   Arduino
+
+    -   C++
+
+    -   FreeRTOS
+
+## Nadajnik/Lokalizator
+
+-   Bezpieczna w użyciu
+
+-   Prosta w użyciu
+
+-   Niezawodny
+
+-   Dokładny
+
+-   Z czytelnym, przejrzystym kodem
+
+-   Technologie:
+
+    -   Arduino
+
+    -   C++
+
+    -   FreeRTOS
+
+## Elektronika naziemna (odbiornik)
+
+-   Bezpieczna w użyciu
+
+-   Prosta w użyciu
+
+-   Niezawodny
+
+-   Ładnie obudowana
+
+-   Z czytelnym, przejrzystym kodem
+
+-   Technologie:
+
+    -   Arduino
+
+    -   C++
+
+## Aplikacja internetowa (frontend)
+
+-   Wytworzona z użyciem nowoczesnych standardów
+
+-   Single Page Application
+
+-   Responsywna
+
+-   Intuicyjna w obsłudze
+
+-   Technologie:
+
+    -   Vue.js
+
+    -   Typescript
+
+## Aplikacja desktopowa
+
+-   Wytworzona z użyciem nowoczesnych standardów
+
+-   Single Page Application
+
+-   Responsywna
+
+-   Intuicyjna w obsłudze
+
+-   Zaprojektowana według najnowszych standardów .NET
+
+-   Używa nowych technologii i podejść programistycznych
+
+-   Z czytelnym i przejrzystym kodem
+
+-   Szybka obsługa zapytań
+
+-   Zintegrowana z elektroniką naziemną oraz pozostałymi modułami
+
+-   Technologie:
+
+    -   Vue.js
+
+    -   Electron
+
+    -   Typescript
+
+    -   .NET Core
+
+    -   C#
+
+## Aplikacja serwerowa - REST API
+
+-   Zaprojektowana według najnowszych standardów .NET
+
+-   Używa nowych technologii i podejść programistycznych
+
+-   Z czytelnym i przejrzystym kodem
+
+-   Szybka obsługa zapytań
+
+-   Technologie:
+
+    -   .Net Core
+
+    -   Docker
+
+## Baza danych
+
+-   Szybka obsługa zapytań
+
+-   Rozszerzalna
+
+-   Niezawodna
+
+-   Technologie:
+
+    -   NoSql
+
+## Prototyp aplikacji internetowej przetestowany przez użytkowników
+
+-   Technologie:
+
+    -   Adobe XD
+
+## Tablica projektowa - Trello
+
+-   Historia wymagań funkcjonalnych (User stories)
+
+-   Historia prac zdefiniowana zadaniami
+
+-   Lista wymagań funkcjonalnych zaplanowanych na przyszłość
+
+-   Lista zadań zaplanowanych na przyszłość
+
+## Repozytorium zawierające kod aplikacji, API oraz elektroniki
+
+-   Czytelne
+
+-   Uporządkowane
+
+-   Tworzone i utrzymywane ze sztuką
+
+-   Technologie:
+
+    -   GitHub
+
+# Mierzalne wskaźniki wdrożeniowe
+
+## Semestr I
+
+-   System zostanie przekazany w wersji testowej alpha.
+
+-   System zostanie zasilony danymi z symulacji lotu rakiet oraz danymi
+    historycznymi testów silników
+
+## Semestr II
+
+-   System zostanie udostępniony w domenie internetowej i będą z niego
+    korzystać członkowie koła (około 20 osób)
+
+-   Wizytówka koła będzie oglądana przez ludzi chcących się dowiedzieć
+    czegoś o kole.
+
+-   Przekazanie plików instalacyjnych do aplikacji desktopowej
+
+-   Na koniec drugiego semestru klient otrzyma system w wersji beta.
+
+# Kryteria akceptacji projektu dla I semestru prac
+
+## Wymagane
+
+-   Ukończenie zdefiniowanych funkcjonalności z listy wymagań
+    funkcjonalnych na pierwszy semestr
+
+-   Brak błędów utrudniających korzystanie z aplikacji
+
+-   Produkt został oddany w czasie
+
+## Oczekiwane
+
+-   Wykonanie produktu zgodnie z ustalonymi wymaganiami odnośnie
+    technologii
+
+## Planowane
+
+-   Zawieranie testów jednostkowych, integracyjnych, oraz czy spełniają
+    swoje zadanie
+
+# Kryteria akceptacji projektu dla II semestru prac
+
+## Wymagane
+
+-   Ukończenie zdefiniowanych funkcjonalności z listy wymagań
+    funkcjonalnych na drugi semestr
+
+-   Przetestowanie aplikacji pod kątem użytkowym przez testerów
+    (klientów końcowych)
+
+-   Brak błędów utrudniających korzystanie z aplikacji
+
+-   Produkt został oddany w czasie
+
+-   Produkt został wdrożony na domenę publiczną
+
+-   Produkt został przekazany klientowi
+
+## Oczekiwane
+
+-   Wykonanie produktu zgodnie z ustalonymi wymaganiami odnośnie
+    technologii
+
+## Planowane
+
+-   Zawieranie testów jednostkowych, integracyjnych, oraz czy spełniają
+    swoje zadanie
+
+# Organizacja pracy zespołu
+
+Strona zespołu projektowego:
+
+-   Wojciech Kubiak - Product Owner
+
+    -   Implementacja systemów wbudowanych
+
+    -   Zarządzanie dokumentacją
+
+    -   Komunikacja z klientem - czynny udział w kole
+
+-   Piotr Józefowicz - Scrum Master
+
+    -   Implementacja frontendu
+
+    -   Projektowanie prototypu interfejsu użytkownika
+
+-   Sebastian Wawrzyn - DevOps
+
+    -   Implementacja backendu aplikacji
+
+    -   Stworzenie bazy danych na potrzeby aplikacji API
+
+    -   Wdrożenie i dockeryzacja aplikacji
+
+Praca jest wykonywana w metodyce SCRUM w tygodniowych sprintach. Kod
+źródłowy trzymany jest na repozytorium na Githubie. Do podziału pracy i
+śledzenia progresu używamy aplikacji Trello
+
+# Ryzyka projektowe
+
+## Ryzyka ze względu na zasoby
+
+-   Odejście członka implementującego stronę serwerową - trudności w
+    ukończeniu aplikacji serwerowej
+
+-   Odejście członka implementującego stronę frontendową - trudności w
+    ukończeniu aplikacji
+
+-   Odejście członka implementującego systemy wbudowane - trudności w
+    ukończeniu aplikacji
+
+-   Określone ramy czasowe (semestry) na stworzenie produktu
+
+## Inne
+
+-   Nieporozumienia na linii zespół a klient wynikające z nieznajomości
+    pojęć domenowych lub nieporozumienia dotyczące funkcjonalności czy
+    innych rzeczy
+
+-   Nieporozumienia w zespole dotyczące rozwiązań implementacyjnych,
+    architektury, funkcjonalności lub używanych technologii
+
+-   Brak odpowiedniego zaangażowania w projekt ze strony zespołu,
+    wybranych członków zespołu
+
+-   Nagły brak wsparcia dla lub przerwanie rozwijania wykorzystywanej
+    technologii lub narzędzia - konieczność implementacji od nowa, lub
+    kontynuowanie implementacji w nieużywanym/źle zaprojektowanym
+    narzędziu, bibliotece
+
+-   Napięty termin, nakład obowiązków związanych z uczelnią oraz sprawy
+    prywatne, mogą negatywnie wpłynąć na pracę nad aplikacją
+
+-   Niestandardowy temat projektu, mogą pojawić się nieoczekiwane
+    trudności (rocket science)
+
+# Kamienie milowe
+
+-   I faza, I semestr (02.2020 - 07.2020):
+
+    -   Przygotowanie prototypu aplikacji
+
+    -   Przygotowanie backlogu dla projektu w systemie Trello,
+        opracowanie funkcjonalności, user stories
+
+    -   Rozpoczęcie prac programistycznych nad aplikacją
+
+    -   Rozpoczęcie prac programistycznych nad komputerem pokładowym 1.0
+
+    -   Testowanie komputera pokładowego
+
+    -   Ukończenie MVP aplikacji i komputera pokładowego
+
+    -   Poddanie MVP testom funkcjonalnym
+
+-   II faza, II semestr(10.2020 - 01.2021):
+
+    -   Uaktualnienie dokumentacji i Trello
+
+    -   Kontynuacja prac programistycznych nad aplikacjami
+
+    -   Kontynuacje prac programistycznych nad komputerem pokładowym
+
+    -   Rozpoczęcie prac nad nadajnikiem i odbiornikiem
+
+    -   Testowanie komputera pokładowego oraz elektroniki naziemnej
+
+    -   Ukończenie aplikacji wraz ze wszystkimi zdefiniowanymi
+        funkcjonalnościami
+
+    -   Integracja aplikacji z elektroniką
+
+    -   Testy integracyjne
+
+    -   Wdrożenie aplikacji na publiczną domenę

Przybylski/kompilator/Wizja.md

@@ -0,0 +1,153 @@
+# Project Vision Document
+
+#### Project name: MealyCompiler (Solomonoff)
+
+#### Authors: Aleksander Mendoza, Bogdan Bondar, Marcin Jabłoński
+
+#### Date: 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 domain specific language of regular expressions. Most of the things can be done without writing even a single line of Java code. We provide commandline as well as web interface and integrated build system. 
+
+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 to provide a better alternative for OpenFST. 
+
+OpenFst was a niche project with sparse documentation and neglected user interface. Everything is done primarily in C++ with templates, while commandline interface is basic, regular expression language has many fundamental flaws, their build system consists of tool for generating Makefiles that only call the compiler. Solomonoff strives to bring improvement with the following features: 
+
+- We have online REPL with examples and guides where everything works out of the box. Everything can be done with our rich and carefully designed regular expression language, so there is no need to write code. 
+
+- We provide extensive documentation in form of 3 scientific papers, detailed technical documentation of compiler implementation, extensive GitHub page and interactive REPL tutorial. 
+
+- We ship with integrated build system that supports parallelism and interacts with compiler directly for optimum performance. It can be configured in TOML build files. 
+
+- Everything can be done in regular expressions and there is no need to interact with compiler's API (althought we do provide as an addition).
+
+- There are plentiful of technical improvements, performance optimisations and innovative algorithms. All of them are described in detail in our documentation. We also provide performance benchamrks on our GitHub
+
+- Unlike any other existing automata tool, we ship with out-of-the functions for box inductive inference.
+
+
+The project found approval among members of Samsung's R&D team for Bixby developement and inductive inference researchers from Dortmund Technical University, Germany. Our system will be deployed in Samsung, our website can aid linguists with easily learning Solomonoff and our build system should make commandline usage more accessible.
+
+The main products are:
+
+- compiler backend - the core of the project
+- commandline interface with build system - allows more technical users to automate Solomonoff with shell scripts
+- website and REPl - allows less technical users to experiene Solomonoff without much friction.
+
+Our project brings performance, which was measured with benchmarks (available on GitGub). We provide innovation, which can be easily noticed by the sheer amount of features Solomonoff implements, which are not available in any other existing tool (more information in scientific papers). We are user-friendly and we assesed it during usability tests and by collecting feedback from end users. 
+
+### 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 implement Glushkov's construction and take advantage of special properties of functional transducers. For better user experience and easier management of code, we provide integrated build system and online REPL with extensive documentation.
+
+
+
+There used to be another similar project, developed by AT&T but it's been long discontinued and replaced by OpenFST. Aside from those two competitors, the market is very niche. There do not exist any other tools (or at least, they are not available publicly) strictly for compiling transducer. 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. As a result, Solomonoff is strictly more powerful and superior to those solutions. There is no other automata compiler with support for inductive inference. There is no ther symbolic transducer library (although there exist general-purpose libraries for symbolic automata, like `symbolicautomata`, `Microsoft Automata Library`, `Rex`, `Bex`, `Fast`, `Mona`). 
+
+
+
+### 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 compiler-backend written in Java
+  - regular expression (concatenation, Kleene closure, union, composition, projection, inverse, composition, difference)
+  - algorithms of inductive inference
+  - type system
+  - integration with LearnLib
+  - is optimised for functional ranged transducers (symbolic automata)
+
+- REPL and build system
+    - support for parallelism
+    - non-determinism warnings
+    - packaging system
+    - dependency resolver
+    - supports everything that compiler does
+    - additional directives
+    - TOML configurations
+
+- online repl and interactive tutorial
+    - can write regular expressions on-the-fly
+    - has all functions of the compiler
+    - saves work of user (cookies and session)
+    - syntax highlighting
+    - user can download the effects of their work for their local computer
+    - visualizes graphs of automata
+    - provides technical documentation
+
+Project architecture and key components:
+
+  - there is all theoretical work and background written in our PDF
+  - theoretical paper serves as basis for formal specification of library functions
+  - Java compiler uses as few libraries as possible: ANTLR for parsing, LearnLib for inductive inference
+  - REPL is developed on top of compiler backend and is not included in the compiler itself (although compiler provides certain facilities necessary for implementing REPL)
+  - build system is developed and shipped independently from compiler backend
+  - online REPL with backend in Spring, uses compiler's Java API.
+  - the REPL used by build system and web brwoser has overlaping features but due to inherent differences between the two enviroments their implementations differ a little.
+  - website contains documentation, examples and tutorials
+
+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
+
+
+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
+
+Team:
+
+- Aleksander Mendoza
+  - formal specification and theoretical foundations
+  - compiler implementation (Java)
+  - unit tests (JUnit)
+- Bogdan Bondar
+  - web design (Bootstrap)
+  - backend development (Spring)
+  - integration tests (Selenium)
+- Marcin Jabłoński
+  - build system (Java)
+  - REPL (ANTLR)
+  - assisting with compiler implementation (initial but discontinued C version)
+
+Limitations:
+
+- no official support for mobile devices. Website is responsive but no mobile-optimised version was added. End users should not code on their smartphones, which is not a common practice either way.
+- no/limited compiler backend for embedded devices. While JavaME does exist, the compiler was not meant to be deployed in embedded systems.
+- no (centralised) package manager for build-system. Developing package manager infrastructure is a prohibitively expensive operation.
+
+
+
+
+

Przybylski/kompilator/wymagania projektowe.md

@@ -0,0 +1,254 @@
+# Project Requirements Document
+
+### Project name: MealyCompiler (Solomonoff)
+
+### Authors: Aleksander Mendoza, Bogdan Bondar, Marcin Jabłoński
+
+### Date: 8.01.2021
+
+#### 0\. Document version
+
+- 13.12.2020 - initial version
+- 8.01.2021 - minor improvements and final touch
+
+#### 1\. Project's components (project's products)
+
+
+Done in first semester:
+
+- C compiler backend (discontinued, because requirements shifted more towards Java)
+	- regular expression (concatenation, Kleene closure, union, output)
+	
+- Java prototype
+	- regular expression (concatenation, Kleene closure, union
+	- type system
+
+- Online REPL prototype
+   - runs C backend in WebAssembly
+   - Ace editor with syntax highlighting
+
+Second semester:
+
+
+- simple and efficient compiler-backend written in Java
+  - regular expression (concatenation, Kleene closure, union, output, composition, projection, inverse, composition, difference)
+  - algorithms of inductive inference
+  - type system
+  - integration with LearnLib
+  - is optimised for functional ranged transducers (symbolic automata)
+  - parser in ANTLR
+
+
+- REPL and build system
+    - support for parallelism
+    - non-determinism warnings
+    - packaging system
+    - dependency resolver
+    - supports everything that compiler does
+    - additional directives 
+    - TOML configurations
+
+- online repl and interactive tutorial
+    - can write regular expressions on-the-fly and has all functions of the compiler (REST calls to Spring backend, which calls compiler Java API)
+    - saves work of user (cookies and session)
+    - syntax highlighting (Ace editr)
+    - user can download the effects of their work for their local computer
+    - visualizes graphs of automata (uses viz.js)
+    - provides technical documentation (formulas with MathJax)
+- tests
+	- integration tests in Python with Selenium (Firefox + Chrome)
+	- all invariants, precodnitions, postconditions of specification expressed in form of assertions. Runtime analysis of specification with JUnit. 
+	- automatically generated tests for random automata 
+	- performance benchmarks
+	- usability tests
+- theory and specification
+    - scientific papers explaining the theory with appropriate mathematical rigour
+    - papers with proofs of correctness of essential algorithms
+
+#### 2\. Project limitations
+
+- The minimal required Java version 1.8 . Oracle has dropped support for older versions long ago
+- Website makes minimal use of CSS3, but older browsers should still be able to use the website. 
+- Internet explorer is not supported, because Microsoft stopped developing it.
+- We did not test website for Safari and Edge, but they should work as well.
+- build system and commandline interface works on all systems that can run Java. Embedded devices are not supported, as such a use case is unlikely. In the future we might add lightweight runtime that can execute automata on embedded envronments.
+
+Justifications:
+
+- initially we started writing compiler in C for best performance. Over the course of development it turned out that performance gains were minimal compared to Java, while the speed writing C code was much slower compared to ease of higher level development in Java. Moreover, the Samsung infrastructure heavily relies on Java and we found out that Java libraries are always preferred over C. Later we also established cooperation with LearnLib from Dortmund university and their entire library is written purely in Java. Hence we decided to switch to Java for better compatibility.
+- we decided to make a website, because this technology is universaly accessible to everyone. A mobile app would require installation (and touch screen would be uncomfortable for writing regexes), command-line interface is only accessible to advanced users and desktop GUI apps require downloading, installation and setup. An online REPL would make Solomonoff easily accessible to masses.
+- The build system was implemented in Java for compatibility with compiler backend. It is primarly targeted at more advanced users and large projects. Build system allows for working with multiple files, which extends the compiler backend that is only capable of working with monolithic streams of code.
+- We considered using user authorization but we decided to keep it simple. Cookies and downloads are out only mean of permanent storage. Hiding our REPL behind "login wall" could potentially turn away some impatient users. There are many demo websites similar to ours that follow similar strategy and don't retain any user data.
+- There are plenty of compiler features that we purposely did not implement. We do not support probabilistic automata, because their semantics tend to be unpredictable and difficult to control by regexes. We don't allow epsilon transitions and it allows for many optimisations. More such examples and technical details can be found in our documentation.
+- Build system does not support namespaces. Instead we took approach similar to C, where "modules" are not a first-class language feature and are instead based on naming convention. When it comes to language features we are strong believers that simplicity and follow the mantra of "less means more". 
+
+
+#### 3\. List of functional requirements 
+
+- Java API:
+   - load/save transducer from/to file
+   - compile reguler expression
+   - run transducer
+   - create multiple independent instances of compiler that can work in parallel
+- Build system
+   - load one or more files
+   - use transducers defined in other files
+   - compile files in project in parallel
+   - define list of source files in build configuration
+   - store many independent configuration files, even in the same directory
+   - run REPL after building project
+- Online REPL
+   - open website and follow tutorial (shows additional tips for first time)
+   - compile a larger piece of code and then experiment with it in REPL
+   - compile code line by line in REPL
+   - read the technical documentation
+   - reopen website and continue where you left off (depending on time limit some things might be lost. The server should not store compiler instances indefinitely)  
+   - download work progress locally
+   - go to GitHub page/download compiler and build system JAR
+- Language functionalities:
+   - union, concatenation, kleene closure, output, composition, difference, inversion, identity, clear output
+   - inference: RPNI, RPNI-EDSM, RPNI-MEALY, OSTIA
+   - weights, reflections, functional nondeterminism
+   - ambiguous nondeterminism detection, typechecking
+   - lazy composition, linear programs, hoare-triples
+   - external native functions, optional user extensions
+
+
+#### 4\. List of non-functional requirements
+
+- scientific papers describing the theory in detail
+- end user tests
+- integration in Samsung
+- integration with LearnLib
+- performance benchmarks
+- accessible and easy tutorials even for less technical users like linguists
+
+
+#### 5\. Measurable indicators 
+
+- efficiency benchmarks on large datasets of regular expressions
+	- RAM usage
+	- disk usage 
+	- execution speed
+	- compilation speed
+- list of features
+- contributions to LearnLib
+- deployment on http://solomonoff.projektstudencki.pl/
+- unit tests
+- integration tests
+- user experience feedback
+
+
+#### 6\. Acceptation criteria for first semester 
+
+- required:
+	- C compiler implementation:
+	   - union, 
+	   - concatenation, 
+	   - kleene closure
+	   - output
+	   - execution
+	- Java prototype, theory and specification
+	   - Glushkov's construction with variables
+	   - type system
+	   - nondeterminism detection
+	   - binary search execution
+	- online compiler 
+		- WebAssembly bindings
+		- Ace editor and syntax highlighting
+		- website design
+- expected:
+	- usable precompiled delivery
+	- optimised algorithms
+	- additional operations (composition, inverse, subtraction)
+- planned:
+	- support for formal verification
+	- inductive inference
+	- optimisations
+	- fully developed compiler
+	- tutorials, examples, how-tos
+	- extensive testing
+
+#### 7\. Acceptation criteria for second semester 
+
+- required:
+   - fully usable optimised compiler with all additional features
+   - working with multiple source files
+   - inductive inference
+   - tutorials, examples how-tos
+   - compatibility with client's existing Java infrastructure
+   - compatibility with LearnLib
+- expected:
+   - secondary compiler features (graph visualisation, export/import, external utility functions)
+   - parallel compilation
+   - configurable build system
+   - inductive inference artifacts as build dependencies
+   - scripts for automated integration tests
+   - great performance benchmarks
+   - detailed technical documentation
+- planned:
+   - partial inductive inference (OSTIA-C) for LearnLib
+   - Thrax-Solomonoff converter for backward-compatibility with legacy systems
+   - Video tutorials
+   - advanced online code editor/full online IDE
+   - extensible build system with plugins and repositories
+
+#### 8\. Project work organization
+
+- Aleksander Mendoza (Product owner)
+  - Glushkov's construction 
+  - weighted transducers
+  - inductive inference
+  - nondeterministic minimization
+  - 
+- Bogdan Bondar (implementation)
+  - Spring backend
+  - frontend
+  - compiler integration
+  - testing (Selenium, unittest, JUnit)
+- Marcin Jabłoński (implementation)
+  - build system (Java)
+  - repl 
+  - dependency resolver 
+  - compiler developemnt (assistance and C implementation)
+  - compiler extension for handling multi-file projects
+
+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 which moment. The future tasks are generally known ahead of time.
+
+Tools:
+
+- JIRA
+- git & GitHub
+- CircleCI
+- Selenium for integration tests
+- MS Teams for video chats, Messanger for daily quick chat
+
+We created a full detailed list of planned tasks at the beginning of semester and tried to follow it, but we also added more unforseen tasks on the rolling basis according to necessity.
+Every task corresponded to some palpable feature and its implementation allowed for closing the task.
+
+#### 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 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.
+
+- The organization of work was a challenge. Project requirements often required us to learn new technologies and solve nontrivial problems. Our team often got stuck on challenging problems and sometimes we had to change plans as some of our plans turned out to be technically impossible:
+    - we struggled with JWebAssembly and in the end switched to Spring
+    - the low-level C implementation was going too slow and we faced the risk of not delivering on time
+    - after the first semester we gained plenty of experience developing Java prototype and we noticed a galore of details that could be done better than we initially planned. We took a drastic decision to rewrite the compiler in Java, which was seen as risky.
+
+  Due to these and many other difficulties, our team could have failed on multiple occations.
+
+- Our project is very niche and finding clients is not easy. If any of our clients lost interest in our solution, finding a new one might become impossible.
+
+#### 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)

Przybylski/sprawdziany/wizja-projektu.md

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

Przybylski/sprawdziany/wymagania-projektowe.md

@@ -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

Przybylski/unity/dokument-wymagan-proj.md

@@ -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

Przybylski/unity/wizja-proj.md

@@ -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

Witkowski/aport-me/dokument_wymagan_projektowych.md

@@ -0,0 +1,216 @@
+# Dokument wymagań projektowych
+
+## Nazwa projektu: **AportMe**
+
+## Autorzy: _Dawid Wietrzych, Jacek Krakowski, Matusz Lesiecki, Wojciech Jarmosz_
+
+## Data: 13.11.2020r.
+
+## **0. Wersje dokumentu**
+
+| Wersja |     Data     |                  Zmiany                   |
+| :----: | :----------: | :---------------------------------------: |
+|  1.0   | 13.11.2020r. | Utworzenie dokumentu wymagań projektowych |
+|  1.1   | 16.01.2021r. | Poprawka opisu organizacji pracy zespołu  |
+
+## **1. Elementy składowe projektu (produkty projektu)**
+
+#### **Programistyczne:**
+
+- Aplikacja webowa oparta o framework Vue.js.
+- Aplikacja mobilna dla systemów Android 16+ i iOS 9+.
+- Instancja serwera bazodanowego oparta o silnik PostgreSQL.
+- Aplikacja serwerowa w języku Java oparta o framework Spring Boot.
+
+#### **Nieprogramistyczne:**
+
+- Zbieranie wymagań projektowych przy współpracy z przedstawicielem fundacji.
+- Stworzenie dokumentu wizji projektu.
+- Dokument wymagań projektowych.
+- Dokumentacja techniczna.
+- Diagram UML, obrazujący schemat bazy danych.
+- Ankieta użyteczności/wrażeń użytkownika projektu.
+
+## **2. Granice projektu**
+
+- **Dlaczego aplikacja nie zostanie udostępniona w Apple Store?**
+  Produkt na urządzenia marki Apple, wymagają posiadania sprzętu tego producenta. Zespół nie dysponuje obecnie wystarczającą ilością sprzętu umożliwiającą przetestowanie aplikacji w stopniu umożliwiającym jej bezpieczne i pewne wdrożenie. Projekt zakłada wydanie wersji oraz rozwój na platformę iOS w przypadku sukcesu aplikacji na platformę Android. Cały proces wiąże się z kosztami, których w obecnej chwili nie jesteśmy w stanie pokryć.
+
+- **Dlaczego funkcjonalność płatności nie została wdrożona?**
+  Obecnie większość systemów do płatności online wymaga przesłania pieniędzy na nasze konto, a my bezpośrednio przelewamy na konto fundacji. Obecnie posiadamy za mało wiedzy żeby móc działać w tym zakresie w pełni legalnie. Rozważamy założenie fundacji która pozwoli nam na legalne obsługiwanie tej funkcjonalności, bez ryzyka problem ze strony Urzędu Skarbowego.
+
+- **Dlaczego konta dla fundacji są tworzone na bazie po stronie naszego zespołu?**
+  Nasza aplikacja zakłada rejestrację fundacji za pośrednictwem naszego zespołu, ze względów bezpieczeństwa i ograniczenia do minimum podszywania się zwykłych użytkowników pod konta fundacji. Po naszej stronie leży sprawdzenie wiarygodności fundacji, która zechce u nas założyć konto i takowe konto przekazać z hasłem tymczasowym, które potem fundacja może zmienić w panelu użytkownika.
+
+- **Dlaczego nie zdecydowano się na integrację z zewnętrznymi systemami (np. systemami autoryzacji)?**
+  Nie zdecydowaliśmy się na wykorzystanie usługi Keycloak (rozważaliśmy taką opcję autoryzacji użytkowników) z powodu braku doświadczenia w jej wykorzystaniu. Braliśmy również pod uwagę zintegrowanie aplikacji z usługą Firebase, jednak wymagał on zbyt dużej (jak nie całkowitej) integracji naszego projektu z usługami Google’a czego nie chcieliśmy robić.
+
+- **Dlaczego niektóre funkcjonalności nie zostały (lub nie zostaną) wdrożone, chociaż nie wymagają istotnego nakładu prac?**
+  Staramy się na ten moment wypuścić produkt spełniający minimalne wymagania fundacji i użytkowników (model MVP). Umożliwi to wcześniejsze zebranie opinii na temat przyszłych funkcjonalności projektu i dalszego rozwoju. Pozwoli też na uniknięcie wprowadzania niepotrzebnych modułów. Projekt wymaga również większego nakładu prac (z racji używanych technologii i platform - mobilna oraz webowa).
+
+## **3. Lista wymagań funkcjonalnych**
+
+#### **Aplikacja mobilna**
+
+- Użytkownik loguje się do aplikacji mobilnej.
+- Użytkownik rejestruje się loguje do aplikacji mobilnej.
+- Użytkownik może przejść do aplikacji bez autoryzacji.
+- Użytkownik może wysłać email z linkiem do resetu hasła.
+- Użytkownik przegląda listę zwierząt dostępnych w systemie.
+- Użytkownik przegląda listę fundacji dostępnych w systemie.
+- Użytkownik może przejrzeć szczegółowy opis zwierzęcia.
+- Użytkownik może skontaktować się z fundacją za pośrednictwem telefonu lub maila (przekierowanie do dedykowanej aplikacji).
+- Zalogowany użytkownik może dodać zwierzęta do ulubionych.
+- Zalogowany użytkownik może dodać fundacje do ulubionych.
+- Zalogowany użytkownik może przeglądać polubione zwierzęta i fundacje.
+- Zalogowany użytkownik może się wylogować.
+- Zalogowany użytkownik może utworzyć ankietę adopcyjną.
+- Zalogowany użytkownik może przeglądać swoje ankiety adopcyjne.
+- Możliwość filtrowania, wyszukiwania określonych zwierząt według kryteriów określonych przez fundacje..
+- Możliwość wsparcia finansowego zwierząt/schronisk.
+- Możliwość wyrażenia chęci adopcji wybranego zwierzaka.
+- Możliwość zmiany hasła.
+- Dodawanie do polubionych fundacji i zwierząt.
+- Obliczanie odległości od schroniska na podstawie lokalizacji użytkownika.
+- Optymalizacja pobierania wpisów.
+- Autoryzacja.
+
+#### **Aplikacja webowa**
+
+- Pozwala zalogować się fundacji.
+- Pozwala zarządzać ogłoszeniami zwierząt fundacji.
+- Pozwala aktualizować dane fundacji.
+- Fundacja ma wgląd w ankiety adopcyjne.
+- Dodanie kreatora ankiet, które użytkownicy będą wypełniać w celu złożenia wniosku o adopcję danego zwierzęcia.
+- Dodanie możliwości przeglądania nadesłanych wniosków z poziomu aplikacji.
+- Dodanie małego workflow obiegu wniosków (zaakceptowany/odrzucony etc.).
+- Przystosowanie aplikacji webowej również dla urządzeń mobilnych (breakpointy).
+- Podpięcie api związanego z logowaniem zmianą hasła użytkowników.
+- Panel umożliwiający prezentację płatności, które zostały przekazane na rzecz zwierząt z określonej fundacji.
+- Zrealizowanie poprawek przekazanych przez komisję na pierwszej obronie projektu.
+
+#### **Serwer**
+
+- Wdrożenie modułu płatności umożliwiającego datkowanie zwierząt.
+- Tworzenie logiki biznesowej do ankiet adopcyjnych.
+- Pokrycie testami.
+- Autoryzacja.
+
+## **4. Lista wymagań niefunkcjonalnych**
+
+- Aplikacja webowa, powinna posiadać interfejs wielojęzyczny (język angielski oraz polski).
+- Maksymalny czas ładowania się aplikacji webowej powinien wynosić maksymalnie 10s.
+- Aplikacja webowa będzie wspierać wszystkie najpopularniejsze przeglądarki (tj. Google Chrome, Mozilla Firefox, Opera, Microsoft Edge, Safari) z wyłączeniem Internet Explorer z racji zapowiedzianego przez firmę Microsoft braku dalszego wsparcia oraz ewentualnych problemów z wczytywaniem paczek npm.
+
+## **5. Mierzalne wskaźniki wdrożeniowe**
+
+- Aplikacja mobilna zostanie wdrożona w sklepie Google Play.
+- System do zarządzania ogłoszeniami zwierząt dla fundacji zostanie wdrożony na domenie publicznej. Ogłoszenia zostaną dodane przez przynajmniej jedną współpracującą fundację.
+- Pod koniec pierwszego semestru wersja testowa zostanie przedstawiona współpracującej fundacji oraz zostaną zebrane informacje zwrotne o tym co należy poprawić.
+- Pod koniec drugiego semestru system zostanie przedstawiony potencjalnym użytkownikom względem zebrania informacji o konwersji aplikacji.
+- System backendowy zostanie wdrożony na dedykowany serwer.
+
+## **6. Kryteria akceptacji projektu dla I semestru prac**
+
+#### **Aplikacja mobilna:**
+
+- Główna lista zwierzaków do adopcji i podgląd profilu wraz ze szczegółami o danych zwierzęciu. - **wymagane**
+- Lista fundacji występująca w aplikacji i podgląd szczegółowych informacji. - **wymagane**
+- Ekrany logowania i rejestracji użytkowników. - **oczekiwane**
+- Zakładka “ulubione” z fundacjami i zwierzętami. - **planowane**
+- Ekran profilu użytkownika. - **oczekiwane**
+- Intro slider. - **oczekiwane**
+
+#### **Aplikacja webowa:**
+
+- Stworzenie interfejsu zarządzania profilami tj. główna lista dodanych profili, a także ich podgląd oraz edycja (CRUD). - **wymagane**
+- Stworzenie panelu edycji profilu fundacji oraz ustawień konta. - **wymagane**
+- Wdrożenie możliwości kadrowania oraz dodawania zdjęć do profili zwierząt. - **oczekiwane**
+- Stworzenie podstron: “Strony głównej”, “O nas”, “Kontakt”. - **oczekiwane**
+- Stworzenie interfejsu logowania użytkowników. - **oczekiwane**
+
+#### **Aplikacja backendowa:**
+
+- Stworzenie encji ORM fundacji, użytkownika, profili zwierząt oraz danych użytkownika. - **wymagane**
+- Stworzenie REST API dla profili, danych użytkownika, a także profili fundacji. - **wymagane**
+- Stworzenie podstawowego modelu autoryzacji użytkowników. - **wymagane**
+- Zgodność aplikacji z polityką RODO. - **wymagane**
+- Testy obciążeniowe aplikacji. - **oczekiwane**
+  - zdajemy sobie sprawę z ryzyka dużej liczebności użytkowników naszej aplikacji, co za tym idzie ze zwiększonego “ruchu” i obciążenia serwera. Dołożymy wszelkich starań aby aplikacja była jak najbardziej wydajna w stosunku do liczby korzystających z niej osób.
+
+## **7. Kryteria akceptacji projektu dla II semestru prac**
+
+#### **Aplikacja mobilna:**
+
+- Możliwość filtrowania, wyszukiwania określonych zwierząt według kryteriów określonych przez fundacje. - **wymagane**
+- Możliwość wsparcia finansowego zwierząt/schronisk. - **planowane**
+- Możliwość wyrażenia chęci adopcji wybranego zwierzaka. - **wymagane**
+- Dodawanie do polubionych fundacji i zwierząt. - **oczekiwane**
+- Możliwość zmiany hasła. - **wymagane**
+- Obliczanie odległości od schroniska na podstawie lokalizacji użytkownika. - **planowane**
+- Optymalizacja pobierania wpisów. - **wymagane**
+- Autoryzacja. - **wymagane**
+
+#### **Aplikacja webowa:**
+
+- Dodanie kreatora ankiet, które użytkownicy będą wypełniać w celu złożenia wniosku o adopcję danego zwierzęcia. - **wymagane**
+- Dodanie możliwości przeglądania nadesłanych wniosków z poziomu aplikacji. - **wymagane**
+- Dodanie małego workflow obiegu wniosków (zaakceptowany/odrzucony etc.). - **oczekiwane**
+- Przystosowanie aplikacji webowej również dla urządzeń mobilnych (breakpointy). - **oczekiwane**
+- Podpięcie api związanego z logowaniem zmianą hasła użytkowników. - **wymagane**
+- Panel umożliwiający prezentację płatności, które zostały przekazane na rzecz zwierząt z określonej fundacji. - **planowane**
+- Zrealizowanie poprawek przekazanych przez komisję na pierwszej obronie projektu. - **wymagane**
+
+#### **Aplikacja backendowa:**
+
+- Wdrożenie modułu płatności umożliwiającego datkowanie zwierząt. - **planowane**
+- Pokrycie testami. - **oczekiwane**
+- Tworzenie logiki biznesowej do ankiet adopcyjnych. - **wymagane**
+- Autoryzacja. - **wymagane**
+
+## **8. Organizacja pracy zespołu**
+
+- Komunikacją z klientem zajmował się Mateusz Lesiecki, polegała ona na wykonywaniu wideokonferencji z klientem oraz zespołem AportMe po ukończonym sprincie i prezentacji aktualnego stanu projektu. Klient oceniał funkcje projektu oraz ich UX. Głównym interesariuszem projektu jest TTB Poznań - fundacja zajmująca się pomocą Bulterierom. Fundacja ta jest również przyszłym klientem korzystającym z aplikacji w roli fundacji/schroniska.
+  Podział zespołu ze względu na technologię przedstawia się następująco:
+- _Dawid Wietrzych_ - Frontend
+- _Wojciech Jarmosz_ - Frontend, Backend
+- _Mateusz Lesiecki_ - Backend, Mobile
+- _Jacek Krakowski_ - Backend, Mobile
+
+- Z racji chęci ścisłej współpracy z fundacją pod kątem użyteczności funkcji w aplikacji, zdecydowaliśmy się na metodykę zwinną, opartą o kilkutygodniowe sprinty, po których następowała konsultacja z klientem.
+- Jakie narzędzia wspomagające prace projektowe wykorzystuje zespół? W jaki sposób zespół zarządza kodami źródłowymi? W jaki sposób zarządza przebiegiem projektu? Czy wykorzystuje się narzędzia CI/CD? Czy stosowane narzędzia są ze sobą zintegrowane? Jeśli tak, to w jaki sposób?<br/>
+  **Narzędzia:** DBeaver, Jira, Postman, Swagger, ESlint + Prettier, Husky<br/>
+  **Zarządzanie kodem:** Git, Github, wzajemny Code Review członków zespołu<br/>
+  **CI\CD:** Docker, GitHub Actions<br/>
+  **Czy zintegrowane:** Tak, w postaci zdalnego repozytorium, korzystanie z jego funkcji (PR,CR)
+- Cykl życia oprogramowania zaczyna się od dodania zadania do backlogu, programista przypisuje się do zadania, a następnie przystępuje do jego realizacji, każda nowa funkcjonalność jest tworzona na osobnym branchu na gicie. Co 3 dni odbywają się spotkania (na wzór daily) gdzie omawiamy problemy i ewentualne ich rozwiązania. Po skończeniu pracy nad funkcjonalnością, wystawiany jest pull request, a następnie przeprowadzanie Code Review. Po poprawkach w Code Review branch jest mergowany do głównego brancha - _develop_.
+
+## **9. Ryzyka projektowe**
+
+Z uwagi na złożoność niektórych funkcjonalności i ograniczenia technologiczne/sprzętowe, wdrożenie ich może okazać się niemożliwe lub znacznie utrudnione, do takich elementów należą:
+
+- Obsługa datkowania fundacji - rozwiązanie aspektów prawnych i bezpieczeństwa danych.
+- Obsługa lokalizacji użytkownika względem lokalizacji schroniska
+- Wdrożenie aplikacji mobilnej na system IOS.
+- Odpowiednie przetestowanie aplikacji pod kątem wydajności i bezpieczeństwa.
+- Integracja z systemami obsługi płatności - Dotpay, Przelewy24, lub innym.
+
+## **10. Kamienie milowe**
+
+#### **Listopad**
+
+- Stworzenie systemu do zarządzania ogłoszeniami przez fundacje.
+- Stworzenie kreatora ankiet adopcyjnych.
+- Stworzenie końcowego szkieletu REST API.
+
+#### **Grudzień**
+
+- Usprawnienie modułu Autoryzacji
+- Dodanie możliwości wypełnienia ankiety w aplikacji mobilnej.
+- Próba deploy'u aplikacji na serwer oraz wystawienie aplikacji mobilnej w Google Play
+
+#### **Styczeń**
+
+- Stworzenie wszystkich ekranów w aplikacji mobilnej
+- Testy i ewentualne poprawki REST API
+- Testy użytkowe aplikacji webowej i mobilnej

Witkowski/conference-page/dokument-wymagan-projektowych-2a.md

@@ -0,0 +1,290 @@
+# Dokument wymagań projektowych
+
+## Dokument wizji dla projektu Conference Web
+
+### Autorzy: Konrad Pierzyński, Michał Starski, Maciej Więcek, Patrycja Łaźna
+
+### Data: 14.11.2020r
+
+-----
+
+#### **0. Wersje dokumentu**
+
+14.11.2020r - stworzenie dokumentu
+
+18.11.2020r - poprawki według zaleceń prowadzącego
+
+19.11.2020r - uzupełnienie dokumentu o elementy związane z wtyczką
+
+-----
+
+#### **1. Elementy składowe projektu**
+
+* aplikacja webowa w języku JavaScript oparta o framework React;
+
+* aplikacja serwerowa w języku Java oparta o framework Spring;
+
+* instancja serwera bazy danych oparta o silnik PostgreSQL;
+
+* wtyczka do edycji wyglądu strony działająca w przeglądarce;
+
+* prototyp wtyczki wykonany w Adobe XD;
+
+* dokumenty: "wizja projektu", "kryteria akceptacji", "dokumentacja techniczna", "dokument wymagań projektowych"
+
+-----
+
+#### **2. Granice projektu**
+
+Z uwagi na uproszczenia, które stosujemy, aby aplikacja była przystępna dla osób nietechnicznych, jak i skupienie na jednym typie generowanych stron, produkt nie będzie tak rozwinięty, jak obecne na rynku inne rozbudowane i komercyjne CMS’y.
+Do funkcjonalności, które nie znajdą się w aplikacji, należą między innymi:
+
+- tworzenie treści wykraczających poza schemat strony konferencyjnej,
+- obsługa płatności.
+
+Dodatkowo, ze względu na podział prac w grupie, stworzony jest oddzielny moduł do edycji wyglądu stron, działający jedynie w przeglądarkach opartych o silnik chromium.
+
+-----
+
+#### **3. Lista wymagań funkcjonalnych**
+
+Na panel administratora składają się następujące sekcje:
+
+1. Strona główna   
+   
+   a) z tego poziomu można przejść na pozostałe sekcje,
+   
+   b) służy jako ekran powitalny panelu administratora,
+   
+   c) wyświetla stworzone przez użytkownika podstrony,
+   
+   d) pozwala na pobranie stron;
+
+2. Sekcja 'generowania strony'
+   
+   a) pozwala użytkownikowi wygenerować pojedynczą podstronę o podanej nazwie,
+   
+   b) umożliwia wybranie odpowiedniego szablonu,
+   
+   c) pozwala wypełnić szablon komponentami;
+
+3. Sekcja 'szablony'
+   
+   a) umożliwia stworzenie niestandardowego szablonu (układu komponentów na stronie), nadanie mu nazwy i zapisanie w systemie;
+
+4. Sekcja 'ustawienia'
+   
+   a) pozwala na uzupełnienie danych o konferencji na podstawie których wypełniane będą komponenty;
+
+5. Sekcja 'uczestnicy'
+   
+   a) zawiera listę uczestników z możliwym poglądem, edycją i usunięciem
+   
+   b) pozwala na manualne utworzenie uczestników
+   
+   c) pozwala na powiadomienie uczestnika o zaakceptowaniu płatności (bez jej obsługi)
+
+Oprócz tego, dążymy do tego, aby produkt końcowy umożliwiał wygenerowanie strony zawierającej:
+
+* lista uczestników
+* informacje o opłacie konferencyjnej
+* informacje na temat miejsca organizacji konferencji
+* zaproszeni mówcy
+* plan konferencji
+* dofinansowanie
+* lista uczestników
+* komitet ( programowy / naukowy )
+* kontakt
+* aktualności
+* dojazd
+* zakwaterowanie
+* poprzednie konferencje
+* zdjęcia
+* publikacja
+* konfigurowalna strona
+* konfigurowalne pole menu
+
+
+Na wtyczkę składają się dwa główne moduły:
+1. Menu, z którego można wybrać elementy do edycji oraz własności elementów:
+    - kolor,
+    - krój czcionki i jej wielkość,
+    - marginesy i przestrzeń wokół elementu,
+    - wymiary,
+    - obramowanie,
+    - położenie elementu,
+    - widoczność elementu;
+2. Podstrona wtyczki
+    - znajduje się tutaj edytor CSS, w którym dynamicznie jest generowany kod wynikowy oraz krótka instrukcja użytkowania wtyczki;
+    - pozwala na pobranie pliku CSS;
+
+-----
+
+#### **4. Lista wymagań niefunkcjonalnych**
+
+Aplikacja jest przystosowana do pracy i działania z najpopularniejszymi przeglądarkami - tj. Mozilla Firefox i tymi opartymi o silnik chromium. Wynika to z niemożności obsługi przez przestarzałe przeglądarki elementów HTML, CSS i JS powszechnie uważanych za standard.
+
+Zdecydowaliśmy się na wykonanie aplikacji webowej, ponieważ ważnym aspektem jest, aby produkt był dostępny w łatwy sposób na szerokiej gamie urządzeń.
+
+Ze względów prostoty budowy aplikacji i prywatności nie zdecydowaliśmy się na wdrożenie żadnych zewnętrznych sposobów autoryzacji.
+
+Interfejs użytkownika panelu administratora aplikacji został stworzony przy pomocy biblioteki gotowych elementów Bootstrap. Wynika to z ograniczonego czasu i chęci zbudowania szybkiego prototypu przez zespół.
+
+Wtyczka powinna działać niezawodnie również offline, łącznie z opcją zapisywania pliku wynikowego, jednak strona, na której zachodzą zmiany musi być w pełni załadowana. Dodatkowo, pozwala na edytowanie stron, w taki sposób, że zmiany będą działać również na urządzeniach mobilnych.
+
+Niektóre funkcjonalności nie zostaną wdrożone z uwagi na zmiany w podziale zadań w grupie w trakcie trwania projektu.
+
+
+
+-----
+
+#### **5. Mierzalne wskaźniki wdrożeniowe**
+
+Na koniec drugiego semestru klient otrzyma wersję beta systemu. W przypadku braku zastrzeżeń aplikacja zostanie udostępniona na potrzeby klienta i jego zakładu, a wtyczka udostępniona w Chrome Web Store.
+
+-----
+
+#### **6. Kryteria akceptacji projektu dla I semestru prac**
+
+* wymagane
+  
+  * generator szablonów
+    * sekcja panelu administratora umożliwiająca użytkownikowi wygenerowanie szablonu (tj. siatki na komponenty)
+    * opcjonalna możliwość dodania własnych styli i skryptów
+  * generator pojedynczej strony
+    * umożliwia wybranie szablonu (jednego z domyślnych lub stworzonych przez użytkownika) i uzupełnienia go o komponenty
+    * pozwala na finalne wygenerowanie strony do plików.
+    * zabezpieczenie panelu administratora przed nieautoryzowanym dostępem
+  * edytor wyglądu stron z naciskiem na edycję wyglądu całych znaczników, a nie poszczególnych elementów
+
+* oczekiwane
+  
+  * wygenerowanie responsywnego prototypu strony przy użyciu aplikacji
+
+* planowane
+  
+  * ukierunkowanie przygotowanych komponentów ściśle pod stronę konferencyjną
+
+-----
+
+#### **7. Kryteria akceptacji projektu dla II semestru prac**
+
+* wymagane
+  
+  * rozbudowanie panelu administratora o kolejne zakładki umożliwiające konfigurację danych na temat konferencji
+  
+  * uzupełnienie bazy komponentów o te, które zostały opisane w wizji projektu
+  
+  * dodanie możliwości tworzenia więcej niż jednej podstrony
+  
+  * rozszerzenie działania wtyczki o edycję pojedynczych elementów i zapisanie stanu strony
+
+* oczekiwane
+  
+  * dodanie zakładki do zarządzania uczestnikami konferencji
+  
+  * dodanie możliwości podglądu podstrony na różnych rozdzielczościach ekranu
+  
+  * przygotowanie wygenerowanej strony do publikacji
+  
+  * rozbudowanie edytora CSS, np. o możliwość wskazywania literówek
+
+* planowane
+  
+  * rozbudowanie procesu generowania strony o optymalizację plików wynikowych
+
+-----
+
+#### **8. Organizacja pracy zespołu**
+
+Nasz zespół został podzielone na trzy podgrupy:
+
+* część frontendowa
+  
+  * Konrad Pierzyński
+    
+    * sekcja generatora szablonów
+    * generator responsywnych szablonów
+    * funkcjonalność dodawania styli i skryptów
+    * szablony i komponenty
+    * UX/UI aplikacji
+  
+  * Michał Starski
+    
+    * konfiguracja środowiska frontendu
+    * sekcja tworzenia strony
+    * system ładowania komponentów i szablonów
+    * sekcja podglądu wygenerowanej strony
+    * autoryzacja użytkownika
+    * zarządzanie flow pracy GIT/JIRA
+
+* część backendowa
+  
+  * Maciej Więcek
+    * baza danych i logika aplikacji
+    * generowanie stron
+    * zabezpieczenie API
+    * autoryzacja użytkownika
+    * deployment usługi
+
+* wtyczka
+    * Patrycja Łaźna
+        * wszystkie działania związane ze stworzeniem wtyczki
+        * UX/UI
+        * testowanie wtyczki
+        * deployment 
+
+Komunikacją z klientem zajmuje się cały zespół z wykorzystaniem MS Teams.
+
+Zespół przyjął metodykę kanban. Rozważany był również scrum, ale z uwagi na zbyt dużą asynchroniczność prac spowodowaną czynnikami zewnętrznymi finalnie został odrzucony.
+
+Do zarządzania pracą i kodem, zespół korzysta z dwóch narzędzi:
+
+* JIRA - organizacja zadań
+* GIT - kontrola kodu
+* Trello - organizacja zadań (zadania dot. wtyczki, tylko w I semestrze)
+
+#### *Cykl życia zadania w projekcie*
+
+Zadanie powstaje podczas cotygodniowego spotkania, podczas którego członkowie zespołu omawiają kolejne kroki budowy aplikacji i ustalają ich priorytety. W momencie gdy zadanie jest gotowe do realizacji, trafia ono do puli zadań do zrobienia w Jirze.
+
+| Nazwa etapu zadania | Do zrobienia                                                            | W trakcie                                                                                            | Zrobione                              |
+| ------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------- |
+| Opis etapu          | Po uzgodnieniu z zespołym nowo zaplanowane zadanie trafia w to miejsce. | Deklaracja członka zespołu, że pracuje nad zadaniem. Ewentualnie zadanie jest w trakcie sprawdzania. | Zadanie zostaje uznane za zakończone. |
+
+-----
+
+#### **9.  Ryzyka projektowe**
+
+Ze względu na mały zespół i ograniczony czas, funkcjonalności mogą okazać się niedopracowane. Ponadto jednorodny wygląd komponentów może odpychać niektórych klientów.
+Podzielenie systemu na aplikację i wtyczkę może wydawać się nieintuicyjne.
+
+-----
+
+#### **10. Kamienie milowe**
+
+* koniec marca
+  * Przygotowanie infrastruktury projektu, rozmowa z klientem
+* początek kwietnia
+  * Stworzenie podstawowego panelu administratora z możliwością wyboru szablonu i umieszczenie w nim komponentów
+* środek kwietnia
+  * Komunikacja prototypu panelu adminstratora z serwerem
+* koniec kwietnia
+  * Stworzenie minimalnej wersji aplikacji
+* początek maja
+  * Dodanie autoryzacji administratorów, przerobienie interfejsu tworzenia i umieszczania komponentów
+* czerwiec
+  * Mechanizm generowania pojedynczej strony
+  * Dodanie modułów do edycji elementów we wtyczce i mechanizmu generowania kodu CSS
+* lipiec - sierpień
+  * Dodanie prostego edytora CSS
+  * Stworzenie działającego prototypu wtyczki
+* październik - listopad
+  * Konfiguracja danych odnoście konferencji i umożliwienie komponentom korzystanie z nich
+* listopad - grudzień
+  * Łączenie wielu podstron w jedną całość
+  * Rozbudowanie działania pickera o pojedyncze elementy
+* styczeń - luty
+  * Rozszerzenie możliwości edytora CSS
+  * Optymalizacja procesu budowania strony wynikowej
+  * Przygotowanie produkcyjnych komponentów

Zywica/car-pool/README.md

@@ -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")

Zywica/car-pool/docs/project_requirements.md

@@ -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