DPRI_doc_20-21/Witkowski/conference-page/dokument-wymagan-projektowych-2a.md

290 lines
10 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 CMSy.
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