# 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