forked from bikol/DPRI_doc_20-21
Merge pull request 'Generator Sprawdzianów - Dodanie Wizji Projektu i Wymagań Projektowych.' (#36) from s434735/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#36
This commit is contained in:
commit
68cb530d66
197
Przybylski/sprawdziany/wizja-projektu.md
Normal file
197
Przybylski/sprawdziany/wizja-projektu.md
Normal file
@ -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.
|
305
Przybylski/sprawdziany/wymagania-projektowe.md
Normal file
305
Przybylski/sprawdziany/wymagania-projektowe.md
Normal file
@ -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
|
Loading…
Reference in New Issue
Block a user