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