11 KiB
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:
-
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;
-
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;
-
Sekcja 'szablony'
a) umożliwia stworzenie niestandardowego szablonu (układu komponentów na stronie), nadanie mu nazwy i zapisanie w systemie;
-
Sekcja 'ustawienia'
a) pozwala na uzupełnienie danych o konferencji na podstawie których wypełniane będą komponenty;
-
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:
- 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;
- 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
- generator szablonó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
- Maciej Więcek
-
wtyczka
- Patrycja Łaźna
- wszystkie działania związane ze stworzeniem wtyczki
- UX/UI
- testowanie wtyczki
- deployment
- Patrycja Łaźna
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