s434741/niezbednikstudenta_docs
1
0
Fork 0
forked from bikol/DPRI_doc_20-21
Code Issues Pull Requests Releases Wiki Activity
cf8f5ea556
niezbednikstudenta_docs/Witkowski/conference-page/dokument-wymagan-projektowych-2a.md

10 KiB
Raw Blame History

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