DPRI_doc_20-21/Przybylski/sprawdziany/wymagania-projektowe.md

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