dokument wymagan projektowych

This commit is contained in:
Patrycja Łaźna 2020-11-20 19:17:05 +01:00
parent 6685dbf52b
commit 2642c20cc6
1 changed files with 290 additions and 0 deletions

View File

@ -0,0 +1,290 @@
# 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.
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