forked from bikol/DPRI_doc_20-21
290 lines
11 KiB
Markdown
290 lines
11 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.
|
|||
|
|
|||
|
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
|