dokument wymagan projektowych
This commit is contained in:
parent
6685dbf52b
commit
2642c20cc6
290
Witkowski/conference-page/dokument-wymagan-projektowych-2a.md
Normal file
290
Witkowski/conference-page/dokument-wymagan-projektowych-2a.md
Normal 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 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
|
Loading…
Reference in New Issue
Block a user