# ~~System wyboru przedmiotów i specjalizacji - opis funkcjonalności~~

# nieaktualne, trzeba zajrzeć na overleaf

### Role w systemie

- student
- administrator (np prof Hetmaniok)

### Dostęp do systemu
- ekran logowania: adres e-mail i hasło
- możliwość zmiany hasła w przypadku, gdy się go zapomniało
- możliwość zmiany hasła po zalogowaniu
- administrator ma możliwość tworzenia i usuwania kont dla administratorów oraz studentów
- domyślnie w systemie utworzone jest jedno konto użytkownika (administratora) z wygenerowanym hasłem

### Przygotowanie systemu:

- dotyczy momentu, gdy **studenci nie mają jeszcze dostępu do systemu**
- administratorzy wpisują do odpowiedniej tabeli osoby prowadzące zajęcia
- zapisywane dane osób prowadzących zajęcia obejmują:
- imię
- nazwisko
- stopień naukowy (dostępne są podpowiedzi)
- jest możliwość edycji oraz usuwania osób prowadzących zajęcia
- administratorzy wpisują do odpowiedniej tabeli kierunki studiów
- zapisywane dane kierunków studiów obejmują:
- nazwa (dostępne są podpowiedzi) (np *Informatyka*, *Matematyka*, itp)
- stopień (dostępne są podpowiedzi) (*Inżynierskie*, *Magisterskie*, *Jednolite magisterskie*, itp)
- tryb (dostępne są podpowiedzi) (*Dzienne*, *Zaoczne*, itp)
- rok rozpoczęcia (dostępne są podpowiedzi) (na wypadek, gdyby wybór przedmiotów odbywał się przykładowo i na drugim roku i na trzecim roku)
- jest możliwość edycji i usuwania kierunków studiów
- dla każdego kierunku studiów administratorzy importują dane studentów:
1. pobranie pliku *.xlsx* (*Excel*) zawierającego tabelę z odpowiednimi nagłówkami do wypełnienia
2. wypełnienie pobranego pliku danymi dotyczącymi studentów (wyszczególnione poniżej)
3. wysłanie wypełnionego arkusza do systemu
4. walidacja danych i zwrócenie informacji o jej przebiegu
5. zapisanie danych w bazie jeśli wszystkie wiersze przeszły walidację, w przeciwnym przypadku cały proces należy powtórzyć po poprawieniu błędów
- system rozpoznaje, czy studenci się powtarzają pomiędzy kierunkami studiów - jeśli ten sam student zostanie dodany dla wielu kierunków studiów, zostanie dla niegu utworzone tylko jedno konto użytkownika
- zapisywane dane studentów obejmują:
- adres email
- imię
- nazwisko
- numer albumu
- dla każdego kierunku studiów, który dotyczy studenta:
- nazwa kierunku studiów
- średnia ocen studenta
- jest możliwość dodawania i edycji studentów w odpowiedniej tabeli w systemie
- jest możliwość usuwania studentów
- dla każdego kierunku studiów administratorzy dodają kategorie przedmiotów przez formularz w systemie
- kategorie to przykładowo *Wykład monograficzny I*, *Przedmiot obieralny III* lub *Specjalność*
- w ramach każdej z kategorii studenci będą mieli wybór spośród dostępnych opcji (**dostępne *opcje* są przedmiotami lub specjalnościami**)
- docelowo w każdej kategorii muszą znajdować się co najmniej 2 opcje - studenci nie mogą dokonywać wyboru, jeśli ten warunek nie jest spełniony
- zapisywane dane kategorii obejmują:
- nazwa (dostępne są podpowiedzi) (np. *Przedmiot obieralny III* lub *Specjalność*)
- data i godzina, w której rozpocznie się wybór opcji (domyślnie wypełnione jako najbliższa północ)
- data i godzina, w której kończy się wybór opcji
- (nieobowiązkowe) numer semestru, którego dotyczy (dostępne są podpowiedzi)
- jest możliwość edycji i usuwania kategorii
- dla każdej z kategorii administratorzy dodają dostępne opcje w odpowiedniej tabeli w systemie
- **opcje do wyboru są przedmiotami lub specjalnościami**
- zapisywane dane opcji do wyboru to:
- nazwa (dostępne są podpowiedzi) (np. *Programowanie aplikacji mobilnych* lub *Representative topics of the optimization theory with practical realization*)
- zaangażowani prowadzący (wybór tylko z dostępnych podpowiedzi)
- język nauczania (dostępne są podpowiedzi)
- (nieobowiązkowe) link(i) do kart(y) przedmiotu(ów)
- (nieobowiązkowe, jeśli podano maksymalną ilość) minimalna ilość studentów
- (nieobowiązkowe, jeśli podano minimalną ilość) maksymalna ilość studentów
- jest możliwość edycji i usuwania opcji
- po poprawnym dodaniu danych, administratorzy mogą zakończyć fazę przygotowania systemu, wtedy:
- tworzone są konta dostępowe dla każdego ze studentów
- na adres e-mail każdego ze studentów wysyłana jest wiadomość z wygenerowanym hasłem dostępowym do systemu

### Fazy w systemie (dla każdej kategorii):

1. faza wyboru
2. faza zatwierdzania
3. faza prezentowania przydziałów

Każda z kategorii niezależnie od siebie przechodzi przez każdą z powyższych faz. Dzięki temu możliwa jest pełna elastyczność korzystania z systemu.

Wszystkie prezentowane poniżej funkcjonalności dotyczą jednej, konkretnej kategorii. Dla każdej z kategorii funkcjonalność jest dokładnie taka sama.

### Opis fazy wyboru dla danej kategorii:

- administrator nie ma możliwości dokonywania zmian w danych dotyczących tej kategorii i podlegających jej opcji
- studenci wybierają spośród dostępnych opcji
- wybór odbywa się przez **uporządkowywanie dostępnych opcji w kolejności od najbardziej pożądanego do najmniej pożądanego**
- jest możliwość edycji dokonanych wyborów
- jest możliwość wyświetlania swoich danych (e-mail, pozycje rankingowe itd)
- jeśli kończy się czas na wybór, a student nie dokonał wyboru w tej kategorii, wysyłane jest ostrzeżenie wiadomością e-mail oraz wyświetlany jest odpowiedni komunikat w systemie
- faza kończy się, gdy mija data deadline'u
- jeśli student nie dokonał wyboru w tej kategorii, przesuwany jest na ostatnią pozycję w liście rankingowej oraz przyjmowane jest założenie, że wybrał losową kolejność opcji

### Opis fazy zatwierdzania dla danej kategorii:

- studenci mają zablokowaną możliwość wyboru i edycji kolejności przedmiotów
- studenci mają możliwość wyświetlenia dokonanych wyborów (kolejności przedmiotów w każdej z kategorii)
- administratorzy mają zablokowaną możliwość edycji i usuwania danych dla tej kategorii (wliczając w to dodawanie, edycję i usuwanie dostępnych opcji)
- administratorom wyświetlane są wszystkie dostępne opcje, wraz z ilością studentów, którzy wybrali go z pierwszego wyboru
- administratorzy decydują, które z opcji zostaną otworzone, a które nie
- dla każdej z opcji, na którą zapisało się zbyt mało osób, administratorzy mają dostępne dwie akcje:
- odrzucenie otwarcia opcji
- zatwierdzenie otwarcia opcji
- za każdym razem przy odrzuceniu opcji, aktualizują się ilości studentów dla innych opcji (brane pod uwagę są wtedy drugie wybory tych studentów, którzy wybrali odrzuconą opcję jako swój pierwszy wybór)
- faza kończy się wtedy, gdy administrator tak zadecyduje
- administrator ma możliwość zakończenia tej fazy dla kilku kategorii jednocześnie
- faza nie może zostać zakończona, jeżeli istnieje choć jedna niezatwierdzona lub nieodrzucona opcja
- w momencie zakończenia tej fazy, wysyłane są wiadomości e-mail do każdego studenta z informacją o tym, która z opcji została mu przydzielona w tej kategorii (jeśli ta faza została zakończona w innych kategoriach w tym samym momencie, to dane dla wszystkich kategorii wysyłane są w jednej wiadomości e-mail)

### Opis fazy prezentowania przydziałów dla danej kategorii:
- studenci mogą zobaczyć swoje wyniki przydziałów:
- która z opcji została im przydzielona w tej kategorii
- które z opcji zostały rzeczywiście otwarte
- administratorzy mogą zobaczyć wyniki przydziałów wszystkich studentów:
- lista studentów wraz z przydzielonymi im opcjami w tej kategorii lub informacją o statusie wyboru
- lista opcji w tej kategorii wraz z przydzielonymi tam studentami i ich liczbą, lub informacją o statusie wyboru
- administratorzy mogą filtrować i sortować wyświetlane dane
- administratorzy mogą pobrać wyświetlane dane do pliku pdf

<!-- ### Docelowy produkt

- strona internetowa:
- wspiera najnowsze wersje najpopularniejszych przeglądarek
- nie wspiera przeglądarek *Internet Explorer*, *Opera Mini* oraz przeglądarek uznanych za martwe
- jest responsywna - da się wygodnie korzystać również na wąskich ekranach dotykowych
- interfejs oparty o Material Design
- aplikacja serwerowa
- baza danych -->

<!-- ### Funkcjonalność dodatkowa (jeśli wystarczy czasu na realizację):

- administratorzy mogą pobrać dane do arkusza z *Excel*a
- administratorzy mogą edytować wartości słownikowe
- administratorzy mogą zmienić kolejność wyświetlania kategorii
- studenci mogą zobaczyć, na której pozycji umieścili wcześniej opcje, który zostały im przydzielone oraz które inne opcje nie zostały otwarte
- tryby demonstracyjne systemu są dostępne bez logowania
- na urządzeniach mobilnych system może zostać przypięty do ekranu głównego (PWA) -->

<!-- - aplikacja mobilna (jeśli wystarczy czasu na realizację):
- PWA
- interfejs oparty o Material Design -->

<!-- ## Dobór technologii

- aplikacja serwerowa:
- REST API
- PostgreSQL
- Java
- SpringBoot
- aplikacja webowa:
- React
- MaterialUI
- Redux

Środowiska programistyczne: opcjonalny *Intellij IDEA* z wersjonowaniem jego konfiguracji projektu

W każdym przypadku dokładne testy automatyczne oraz systemy kontroli składni kodu.

Deploy dev: Aplikacja serwerowa deploy na Heroku, aplikacja webowa deploy gdziekolwiek

## Organizacja pracy

sprinty

#### Podział obowiązków:

- organizacja pracy - zadania, terminy i cele sprintów: Kamil B / Bartek / Kamil R
- pilnowanie przestrzegania terminów: Kamil R / Oliwia / ?
- weryfikacja wykonania zadań ze sprintów na środowisku deweloperskim: wszyscy
- komunikacja z promotorem: Bartek?
- komunikacja z osobą recenzującą:
-
- ---
backend: Oliwia, Kamil B, Kamil R(?), Bartek (?)
frontend: Kamil B, Kamil R, Bartek
- ---
- ogólny opis systemu w pracy inżynierskiej - zapotrzbowanie, specyfika, przyczyny decyzji itp: Bartek?
- opis organizacji pracy w pracy inżynierskiej: Kamil B?
- opis wspólny części klienckiej w pracy inżynierskej: ?
- opis bazy danych w pracy inżynierskiej: ?
- opis aplikacji serwerowej w pracy inżynierskiej: ?
- opis aplikacji webowej w pracy inżynierskiej: ?
- opis aplikacji moblinej w pracy inżynierskiej: ?
- ---
- zarządzanie bazą danych: ?
- tworzenie aplikacji serwerowej wraz z logiką biznesową: ?
- tworzenie aplikacji webowej: ?
- tworzenie aplikacji mobilnej: ?
- zarządzanie ewentualną współdzieloną strefą aplikacji mobilnej i webowej: ?
- zarządzanie akcjami API oraz pilnowanie przestrzegania REST: ?

#### Git flow:

- deweloperska gąłąź o nazwie `develop` - każdy może śmiało commitować co chce na tej gałązi (w ramach swojego obszaru), nie trzeba robić pull requestów
- główna gałąź o nazwie `master` (lub innej, jaka akurat będzie wtedy domyślna) - na koniec każdego sprintu gałąź `develop` będzie mergowana do tej gałęzi, a commity squashowane. Commity będzie się nazywać numerkami wersji, a nie będzie to powodować żadnych zmian na gałęzi `develop`

#### Pierwszy sprint: dwa tygodnie?

- wybór nazwy systemu
- utworzenie repozytorium projektu na *GitHub*ie
- utworzenie projektu pracy inżynierskiej na *Overleaf*
- utworzenie konspektu pracy inżynierskiej (sekcje, kategorie, podpunkty itp)
- utworzenie projektu UI
- przygotowanie środowisk deweloperskich:
- utworzenie inicjalnej struktury plików (frontend i backend)
- włączenie narzędzi do kontroli składni kodu (np *eslint* na frontendzie, np *checkstyle* na backendzie)
- utworzenie pierwszych funkcjonalności:
- utworzenie pierwszego ekranu na frontendzie, wyświetlającego nazwę systemu
- utworzenie pierwszego endpointu (przykładowo *GET* na `/api/students` zwracającego zmockowaną listę studentów, ale warto tam zaznaczyć w komentarzu, że docelowo ma to być dostępne tylko dla administratorów)
- utworzenie pierwszych testów:
- utworzenie pierwszych testów na frontendzie (sprawdzających, czy aplikacje się poprawnie uruchamiają oraz czy wyświetlane ekrany zawierają słowa kluczowe, w tym przypadku nazwę aplikacji)
- utworzenie pierwszych testów na backendzie (sprawdzających, czy wysyłanie zapytań na utworzony endpoint zwróci poprawny rezultat)
- testy jednostkowe???
- deploy do chmury:
- utworzenie deweloperskiej bazy danych w wybranej chmurze (np *Heroku*)
- deploy backendu do wybranej chmury (np *Heroku*)
- deploy strony internetowej do wybranej chmury
- deploy aplikacji mobilnej? w jaki sposób? zrobić research
- integracja z chmurą w taki sposób, aby zmiana kodu na gałęzi `develop` powodowała automatyczne odświeżenie zdeployowanych aplikacji
- zaplanowanie zadań na następny sprint
- wolny czas do końca sprintu warto przeznaczyć na refaktoryzację kodu lub dopisanie testów
-->