forked from bikol/DPRI_doc_20-21
290 lines
10 KiB
Markdown
290 lines
10 KiB
Markdown
# Dokument wymagań projektowych
|
||
|
||
## Dokument wizji dla projektu Conference Web
|
||
|
||
### Autorzy: Konrad Pierzyński, Michał Starski, Maciej Więcek, Patrycja Łaźna
|
||
|
||
### Data: 14.11.2020r
|
||
|
||
-----
|
||
|
||
#### **0. Wersje dokumentu**
|
||
|
||
14.11.2020r - stworzenie dokumentu
|
||
|
||
18.11.2020r - poprawki według zaleceń prowadzącego
|
||
|
||
19.11.2020r - uzupełnienie dokumentu o elementy związane z wtyczką
|
||
|
||
-----
|
||
|
||
#### **1. Elementy składowe projektu**
|
||
|
||
* aplikacja webowa w języku JavaScript oparta o framework React;
|
||
|
||
* aplikacja serwerowa w języku Java oparta o framework Spring;
|
||
|
||
* instancja serwera bazy danych oparta o silnik PostgreSQL;
|
||
|
||
* wtyczka do edycji wyglądu strony działająca w przeglądarce;
|
||
|
||
* prototyp wtyczki wykonany w Adobe XD;
|
||
|
||
* dokumenty: "wizja projektu", "kryteria akceptacji", "dokumentacja techniczna", "dokument wymagań projektowych"
|
||
|
||
-----
|
||
|
||
#### **2. Granice projektu**
|
||
|
||
Z uwagi na uproszczenia, które stosujemy, aby aplikacja była przystępna dla osób nietechnicznych, jak i skupienie na jednym typie generowanych stron, produkt nie będzie tak rozwinięty, jak obecne na rynku inne rozbudowane i komercyjne CMS’y.
|
||
Do funkcjonalności, które nie znajdą się w aplikacji, należą między innymi:
|
||
|
||
- tworzenie treści wykraczających poza schemat strony konferencyjnej,
|
||
- obsługa płatności.
|
||
|
||
Dodatkowo, ze względu na podział prac w grupie, stworzony jest oddzielny moduł do edycji wyglądu stron, działający jedynie w przeglądarkach opartych o silnik chromium.
|
||
|
||
-----
|
||
|
||
#### **3. Lista wymagań funkcjonalnych**
|
||
|
||
Na panel administratora składają się następujące sekcje:
|
||
|
||
1. Strona główna
|
||
|
||
a) z tego poziomu można przejść na pozostałe sekcje,
|
||
|
||
b) służy jako ekran powitalny panelu administratora,
|
||
|
||
c) wyświetla stworzone przez użytkownika podstrony,
|
||
|
||
d) pozwala na pobranie stron;
|
||
|
||
2. Sekcja 'generowania strony'
|
||
|
||
a) pozwala użytkownikowi wygenerować pojedynczą podstronę o podanej nazwie,
|
||
|
||
b) umożliwia wybranie odpowiedniego szablonu,
|
||
|
||
c) pozwala wypełnić szablon komponentami;
|
||
|
||
3. Sekcja 'szablony'
|
||
|
||
a) umożliwia stworzenie niestandardowego szablonu (układu komponentów na stronie), nadanie mu nazwy i zapisanie w systemie;
|
||
|
||
4. Sekcja 'ustawienia'
|
||
|
||
a) pozwala na uzupełnienie danych o konferencji na podstawie których wypełniane będą komponenty;
|
||
|
||
5. Sekcja 'uczestnicy'
|
||
|
||
a) zawiera listę uczestników z możliwym poglądem, edycją i usunięciem
|
||
|
||
b) pozwala na manualne utworzenie uczestników
|
||
|
||
c) pozwala na powiadomienie uczestnika o zaakceptowaniu płatności (bez jej obsługi)
|
||
|
||
Oprócz tego, dążymy do tego, aby produkt końcowy umożliwiał wygenerowanie strony zawierającej:
|
||
|
||
* lista uczestników
|
||
* informacje o opłacie konferencyjnej
|
||
* informacje na temat miejsca organizacji konferencji
|
||
* zaproszeni mówcy
|
||
* plan konferencji
|
||
* dofinansowanie
|
||
* lista uczestników
|
||
* komitet ( programowy / naukowy )
|
||
* kontakt
|
||
* aktualności
|
||
* dojazd
|
||
* zakwaterowanie
|
||
* poprzednie konferencje
|
||
* zdjęcia
|
||
* publikacja
|
||
* konfigurowalna strona
|
||
* konfigurowalne pole menu
|
||
|
||
|
||
Na wtyczkę składają się dwa główne moduły:
|
||
1. Menu, z którego można wybrać elementy do edycji oraz własności elementów:
|
||
- kolor,
|
||
- krój czcionki i jej wielkość,
|
||
- marginesy i przestrzeń wokół elementu,
|
||
- wymiary,
|
||
- obramowanie,
|
||
- położenie elementu,
|
||
- widoczność elementu;
|
||
2. Podstrona wtyczki
|
||
- znajduje się tutaj edytor CSS, w którym dynamicznie jest generowany kod wynikowy oraz krótka instrukcja użytkowania wtyczki;
|
||
- pozwala na pobranie pliku CSS;
|
||
|
||
-----
|
||
|
||
#### **4. Lista wymagań niefunkcjonalnych**
|
||
|
||
Aplikacja jest przystosowana do pracy i działania z najpopularniejszymi przeglądarkami - tj. Mozilla Firefox i tymi opartymi o silnik chromium. Wynika to z niemożności obsługi przez przestarzałe przeglądarki elementów HTML, CSS i JS powszechnie uważanych za standard.
|
||
|
||
Zdecydowaliśmy się na wykonanie aplikacji webowej, ponieważ ważnym aspektem jest, aby produkt był dostępny w łatwy sposób na szerokiej gamie urządzeń.
|
||
|
||
Ze względów prostoty budowy aplikacji i prywatności nie zdecydowaliśmy się na wdrożenie żadnych zewnętrznych sposobów autoryzacji.
|
||
|
||
Interfejs użytkownika panelu administratora aplikacji został stworzony przy pomocy biblioteki gotowych elementów Bootstrap. Wynika to z ograniczonego czasu i chęci zbudowania szybkiego prototypu przez zespół.
|
||
|
||
Wtyczka powinna działać niezawodnie również offline, łącznie z opcją zapisywania pliku wynikowego, jednak strona, na której zachodzą zmiany musi być w pełni załadowana. Dodatkowo, pozwala na edytowanie stron, w taki sposób, że zmiany będą działać również na urządzeniach mobilnych.
|
||
|
||
Niektóre funkcjonalności nie zostaną wdrożone z uwagi na zmiany w podziale zadań w grupie w trakcie trwania projektu.
|
||
|
||
|
||
|
||
-----
|
||
|
||
#### **5. Mierzalne wskaźniki wdrożeniowe**
|
||
|
||
Na koniec drugiego semestru klient otrzyma wersję beta systemu. W przypadku braku zastrzeżeń aplikacja zostanie udostępniona na potrzeby klienta i jego zakładu, a wtyczka udostępniona w Chrome Web Store.
|
||
|
||
-----
|
||
|
||
#### **6. Kryteria akceptacji projektu dla I semestru prac**
|
||
|
||
* wymagane
|
||
|
||
* generator szablonów
|
||
* sekcja panelu administratora umożliwiająca użytkownikowi wygenerowanie szablonu (tj. siatki na komponenty)
|
||
* opcjonalna możliwość dodania własnych styli i skryptów
|
||
* generator pojedynczej strony
|
||
* umożliwia wybranie szablonu (jednego z domyślnych lub stworzonych przez użytkownika) i uzupełnienia go o komponenty
|
||
* pozwala na finalne wygenerowanie strony do plików.
|
||
* zabezpieczenie panelu administratora przed nieautoryzowanym dostępem
|
||
* edytor wyglądu stron z naciskiem na edycję wyglądu całych znaczników, a nie poszczególnych elementów
|
||
|
||
* oczekiwane
|
||
|
||
* wygenerowanie responsywnego prototypu strony przy użyciu aplikacji
|
||
|
||
* planowane
|
||
|
||
* ukierunkowanie przygotowanych komponentów ściśle pod stronę konferencyjną
|
||
|
||
-----
|
||
|
||
#### **7. Kryteria akceptacji projektu dla II semestru prac**
|
||
|
||
* wymagane
|
||
|
||
* rozbudowanie panelu administratora o kolejne zakładki umożliwiające konfigurację danych na temat konferencji
|
||
|
||
* uzupełnienie bazy komponentów o te, które zostały opisane w wizji projektu
|
||
|
||
* dodanie możliwości tworzenia więcej niż jednej podstrony
|
||
|
||
* rozszerzenie działania wtyczki o edycję pojedynczych elementów i zapisanie stanu strony
|
||
|
||
* oczekiwane
|
||
|
||
* dodanie zakładki do zarządzania uczestnikami konferencji
|
||
|
||
* dodanie możliwości podglądu podstrony na różnych rozdzielczościach ekranu
|
||
|
||
* przygotowanie wygenerowanej strony do publikacji
|
||
|
||
* rozbudowanie edytora CSS, np. o możliwość wskazywania literówek
|
||
|
||
* planowane
|
||
|
||
* rozbudowanie procesu generowania strony o optymalizację plików wynikowych
|
||
|
||
-----
|
||
|
||
#### **8. Organizacja pracy zespołu**
|
||
|
||
Nasz zespół został podzielone na trzy podgrupy:
|
||
|
||
* część frontendowa
|
||
|
||
* Konrad Pierzyński
|
||
|
||
* sekcja generatora szablonów
|
||
* generator responsywnych szablonów
|
||
* funkcjonalność dodawania styli i skryptów
|
||
* szablony i komponenty
|
||
* UX/UI aplikacji
|
||
|
||
* Michał Starski
|
||
|
||
* konfiguracja środowiska frontendu
|
||
* sekcja tworzenia strony
|
||
* system ładowania komponentów i szablonów
|
||
* sekcja podglądu wygenerowanej strony
|
||
* autoryzacja użytkownika
|
||
* zarządzanie flow pracy GIT/JIRA
|
||
|
||
* część backendowa
|
||
|
||
* Maciej Więcek
|
||
* baza danych i logika aplikacji
|
||
* generowanie stron
|
||
* zabezpieczenie API
|
||
* autoryzacja użytkownika
|
||
* deployment usługi
|
||
|
||
* wtyczka
|
||
* Patrycja Łaźna
|
||
* wszystkie działania związane ze stworzeniem wtyczki
|
||
* UX/UI
|
||
* testowanie wtyczki
|
||
* deployment
|
||
|
||
Komunikacją z klientem zajmuje się cały zespół z wykorzystaniem MS Teams.
|
||
|
||
Zespół przyjął metodykę kanban. Rozważany był również scrum, ale z uwagi na zbyt dużą asynchroniczność prac spowodowaną czynnikami zewnętrznymi finalnie został odrzucony.
|
||
|
||
Do zarządzania pracą i kodem, zespół korzysta z dwóch narzędzi:
|
||
|
||
* JIRA - organizacja zadań
|
||
* GIT - kontrola kodu
|
||
* Trello - organizacja zadań (zadania dot. wtyczki, tylko w I semestrze)
|
||
|
||
#### *Cykl życia zadania w projekcie*
|
||
|
||
Zadanie powstaje podczas cotygodniowego spotkania, podczas którego członkowie zespołu omawiają kolejne kroki budowy aplikacji i ustalają ich priorytety. W momencie gdy zadanie jest gotowe do realizacji, trafia ono do puli zadań do zrobienia w Jirze.
|
||
|
||
| Nazwa etapu zadania | Do zrobienia | W trakcie | Zrobione |
|
||
| ------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------- |
|
||
| Opis etapu | Po uzgodnieniu z zespołym nowo zaplanowane zadanie trafia w to miejsce. | Deklaracja członka zespołu, że pracuje nad zadaniem. Ewentualnie zadanie jest w trakcie sprawdzania. | Zadanie zostaje uznane za zakończone. |
|
||
|
||
-----
|
||
|
||
#### **9. Ryzyka projektowe**
|
||
|
||
Ze względu na mały zespół i ograniczony czas, funkcjonalności mogą okazać się niedopracowane. Ponadto jednorodny wygląd komponentów może odpychać niektórych klientów.
|
||
Podzielenie systemu na aplikację i wtyczkę może wydawać się nieintuicyjne.
|
||
|
||
-----
|
||
|
||
#### **10. Kamienie milowe**
|
||
|
||
* koniec marca
|
||
* Przygotowanie infrastruktury projektu, rozmowa z klientem
|
||
* początek kwietnia
|
||
* Stworzenie podstawowego panelu administratora z możliwością wyboru szablonu i umieszczenie w nim komponentów
|
||
* środek kwietnia
|
||
* Komunikacja prototypu panelu adminstratora z serwerem
|
||
* koniec kwietnia
|
||
* Stworzenie minimalnej wersji aplikacji
|
||
* początek maja
|
||
* Dodanie autoryzacji administratorów, przerobienie interfejsu tworzenia i umieszczania komponentów
|
||
* czerwiec
|
||
* Mechanizm generowania pojedynczej strony
|
||
* Dodanie modułów do edycji elementów we wtyczce i mechanizmu generowania kodu CSS
|
||
* lipiec - sierpień
|
||
* Dodanie prostego edytora CSS
|
||
* Stworzenie działającego prototypu wtyczki
|
||
* październik - listopad
|
||
* Konfiguracja danych odnoście konferencji i umożliwienie komponentom korzystanie z nich
|
||
* listopad - grudzień
|
||
* Łączenie wielu podstron w jedną całość
|
||
* Rozbudowanie działania pickera o pojedyncze elementy
|
||
* styczeń - luty
|
||
* Rozszerzenie możliwości edytora CSS
|
||
* Optymalizacja procesu budowania strony wynikowej
|
||
* Przygotowanie produkcyjnych komponentów |