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

# 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