forked from bikol/DPRI_doc_20-21
306 lines
9.8 KiB
Markdown
306 lines
9.8 KiB
Markdown
**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
|