Witkowski/aport-me/dokument_wymagan_projektowych.md

@@ -0,0 +1,215 @@
+# Dokument wymagań projektowych
+
+## Nazwa projektu: **AportMe**
+
+## Autorzy: _Dawid Wietrzych, Jacek Krakowski, Matusz Lesiecki, Wojciech Jarmosz_
+
+## Data: 13.11.2020r.
+
+## **0. Wersje dokumentu**
+
+| Wersja |     Data     |                  Zmiany                   |
+| :----: | :----------: | :---------------------------------------: |
+|  1.0   | 13.11.2020r. | Utworzenie dokumentu wymagań projektowych |
+
+## **1. Elementy składowe projektu (produkty projektu)**
+
+#### **Programistyczne:**
+
+- Aplikacja webowa oparta o framework Vue.js.
+- Aplikacja mobilna dla systemów Android 16+ i iOS 9+.
+- Instancja serwera bazodanowego oparta o silnik PostgreSQL.
+- Aplikacja serwerowa w języku Java oparta o framework Spring Boot.
+
+#### **Nieprogramistyczne:**
+
+- Zbieranie wymagań projektowych przy współpracy z przedstawicielem fundacji.
+- Stworzenie dokumentu wizji projektu.
+- Dokument wymagań projektowych.
+- Dokumentacja techniczna.
+- Diagram UML, obrazujący schemat bazy danych.
+- Ankieta użyteczności/wrażeń użytkownika projektu.
+
+## **2. Granice projektu**
+
+- **Dlaczego aplikacja nie zostanie udostępniona w Apple Store?**
+  Produkt na urządzenia marki Apple, wymagają posiadania sprzętu tego producenta. Zespół nie dysponuje obecnie wystarczającą ilością sprzętu umożliwiającą przetestowanie aplikacji w stopniu umożliwiającym jej bezpieczne i pewne wdrożenie. Projekt zakłada wydanie wersji oraz rozwój na platformę iOS w przypadku sukcesu aplikacji na platformę Android. Cały proces wiąże się z kosztami, których w obecnej chwili nie jesteśmy w stanie pokryć.
+
+- **Dlaczego funkcjonalność płatności nie została wdrożona?**
+  Obecnie większość systemów do płatności online wymaga przesłania pieniędzy na nasze konto, a my bezpośrednio przelewamy na konto fundacji. Obecnie posiadamy za mało wiedzy żeby móc działać w tym zakresie w pełni legalnie. Rozważamy założenie fundacji która pozwoli nam na legalne obsługiwanie tej funkcjonalności, bez ryzyka problem ze strony Urzędu Skarbowego.
+
+- **Dlaczego konta dla fundacji są tworzone na bazie po stronie naszego zespołu?**
+  Nasza aplikacja zakłada rejestrację fundacji za pośrednictwem naszego zespołu, ze względów bezpieczeństwa i ograniczenia do minimum podszywania się zwykłych użytkowników pod konta fundacji. Po naszej stronie leży sprawdzenie wiarygodności fundacji, która zechce u nas założyć konto i takowe konto przekazać z hasłem tymczasowym, które potem fundacja może zmienić w panelu użytkownika.
+
+- **Dlaczego nie zdecydowano się na integrację z zewnętrznymi systemami (np. systemami autoryzacji)?**
+  Nie zdecydowaliśmy się na wykorzystanie usługi Keycloak (rozważaliśmy taką opcję autoryzacji użytkowników) z powodu braku doświadczenia w jej wykorzystaniu. Braliśmy również pod uwagę zintegrowanie aplikacji z usługą Firebase, jednak wymagał on zbyt dużej (jak nie całkowitej) integracji naszego projektu z usługami Google’a czego nie chcieliśmy robić.
+
+- **Dlaczego niektóre funkcjonalności nie zostały (lub nie zostaną) wdrożone, chociaż nie wymagają istotnego nakładu prac?**
+  Staramy się na ten moment wypuścić produkt spełniający minimalne wymagania fundacji i użytkowników (model MVP). Umożliwi to wcześniejsze zebranie opinii na temat przyszłych funkcjonalności projektu i dalszego rozwoju. Pozwoli też na uniknięcie wprowadzania niepotrzebnych modułów. Projekt wymaga również większego nakładu prac (z racji używanych technologii i platform - mobilna oraz webowa).
+
+## **3. Lista wymagań funkcjonalnych**
+
+#### **Aplikacja mobilna**
+
+- Użytkownik loguje się do aplikacji mobilnej.
+- Użytkownik rejestruje się loguje do aplikacji mobilnej.
+- Użytkownik może przejść do aplikacji bez autoryzacji.
+- Użytkownik może wysłać email z linkiem do resetu hasła.
+- Użytkownik przegląda listę zwierząt dostępnych w systemie.
+- Użytkownik przegląda listę fundacji dostępnych w systemie.
+- Użytkownik może przejrzeć szczegółowy opis zwierzęcia.
+- Użytkownik może skontaktować się z fundacją za pośrednictwem telefonu lub maila (przekierowanie do dedykowanej aplikacji).
+- Zalogowany użytkownik może dodać zwierzęta do ulubionych.
+- Zalogowany użytkownik może dodać fundacje do ulubionych.
+- Zalogowany użytkownik może przeglądać polubione zwierzęta i fundacje.
+- Zalogowany użytkownik może się wylogować.
+- Zalogowany użytkownik może utworzyć ankietę adopcyjną.
+- Zalogowany użytkownik może przeglądać swoje ankiety adopcyjne.
+- Możliwość filtrowania, wyszukiwania określonych zwierząt według kryteriów określonych przez fundacje..
+- Możliwość wsparcia finansowego zwierząt/schronisk.
+- Możliwość wyrażenia chęci adopcji wybranego zwierzaka.
+- Możliwość zmiany hasła.
+- Dodawanie do polubionych fundacji i zwierząt.
+- Obliczanie odległości od schroniska na podstawie lokalizacji użytkownika.
+- Optymalizacja pobierania wpisów.
+- Autoryzacja.
+
+#### **Aplikacja webowa**
+
+- Pozwala zalogować się fundacji.
+- Pozwala zarządzać ogłoszeniami zwierząt fundacji.
+- Pozwala aktualizować dane fundacji.
+- Fundacja ma wgląd w ankiety adopcyjne.
+- Dodanie kreatora ankiet, które użytkownicy będą wypełniać w celu złożenia wniosku o adopcję danego zwierzęcia.
+- Dodanie możliwości przeglądania nadesłanych wniosków z poziomu aplikacji.
+- Dodanie małego workflow obiegu wniosków (zaakceptowany/odrzucony etc.).
+- Przystosowanie aplikacji webowej również dla urządzeń mobilnych (breakpointy).
+- Podpięcie api związanego z logowaniem zmianą hasła użytkowników.
+- Panel umożliwiający prezentację płatności, które zostały przekazane na rzecz zwierząt z określonej fundacji.
+- Zrealizowanie poprawek przekazanych przez komisję na pierwszej obronie projektu.
+
+#### **Serwer**
+
+- Wdrożenie modułu płatności umożliwiającego datkowanie zwierząt.
+- Tworzenie logiki biznesowej do ankiet adopcyjnych.
+- Pokrycie testami.
+- Autoryzacja.
+
+## **4. Lista wymagań niefunkcjonalnych**
+
+- Aplikacja webowa, powinna posiadać interfejs wielojęzyczny (język angielski oraz polski).
+- Maksymalny czas ładowania się aplikacji webowej powinien wynosić maksymalnie 10s.
+- Aplikacja webowa będzie wspierać wszystkie najpopularniejsze przeglądarki (tj. Google Chrome, Mozilla Firefox, Opera, Microsoft Edge, Safari) z wyłączeniem Internet Explorer z racji zapowiedzianego przez firmę Microsoft braku dalszego wsparcia oraz ewentualnych problemów z wczytywaniem paczek npm.
+
+## **5. Mierzalne wskaźniki wdrożeniowe**
+
+- Aplikacja mobilna zostanie wdrożona w sklepie Google Play.
+- System do zarządzania ogłoszeniami zwierząt dla fundacji zostanie wdrożony na domenie publicznej. Ogłoszenia zostaną dodane przez przynajmniej jedną współpracującą fundację.
+- Pod koniec pierwszego semestru wersja testowa zostanie przedstawiona współpracującej fundacji oraz zostaną zebrane informacje zwrotne o tym co należy poprawić.
+- Pod koniec drugiego semestru system zostanie przedstawiony potencjalnym użytkownikom względem zebrania informacji o konwersji aplikacji.
+- System backendowy zostanie wdrożony na dedykowany serwer.
+
+## **6. Kryteria akceptacji projektu dla I semestru prac**
+
+#### **Aplikacja mobilna:**
+
+- Główna lista zwierzaków do adopcji i podgląd profilu wraz ze szczegółami o danych zwierzęciu. - **wymagane**
+- Lista fundacji występująca w aplikacji i podgląd szczegółowych informacji. - **wymagane**
+- Ekrany logowania i rejestracji użytkowników. - **oczekiwane**
+- Zakładka “ulubione” z fundacjami i zwierzętami. - **planowane**
+- Ekran profilu użytkownika. - **oczekiwane**
+- Intro slider. - **oczekiwane**
+
+#### **Aplikacja webowa:**
+
+- Stworzenie interfejsu zarządzania profilami tj. główna lista dodanych profili, a także ich podgląd oraz edycja (CRUD). - **wymagane**
+- Stworzenie panelu edycji profilu fundacji oraz ustawień konta. - **wymagane**
+- Wdrożenie możliwości kadrowania oraz dodawania zdjęć do profili zwierząt. - **oczekiwane**
+- Stworzenie podstron: “Strony głównej”, “O nas”, “Kontakt”. - **oczekiwane**
+- Stworzenie interfejsu logowania użytkowników. - **oczekiwane**
+
+#### **Aplikacja backendowa:**
+
+- Stworzenie encji ORM fundacji, użytkownika, profili zwierząt oraz danych użytkownika. - **wymagane**
+- Stworzenie REST API dla profili, danych użytkownika, a także profili fundacji. - **wymagane**
+- Stworzenie podstawowego modelu autoryzacji użytkowników. - **wymagane**
+- Zgodność aplikacji z polityką RODO. - **wymagane**
+- Testy obciążeniowe aplikacji. - **oczekiwane**
+  - zdajemy sobie sprawę z ryzyka dużej liczebności użytkowników naszej aplikacji, co za tym idzie ze zwiększonego “ruchu” i obciążenia serwera. Dołożymy wszelkich starań aby aplikacja była jak najbardziej wydajna w stosunku do liczby korzystających z niej osób.
+
+## **7. Kryteria akceptacji projektu dla II semestru prac**
+
+#### **Aplikacja mobilna:**
+
+- Możliwość filtrowania, wyszukiwania określonych zwierząt według kryteriów określonych przez fundacje. - **wymagane**
+- Możliwość wsparcia finansowego zwierząt/schronisk. - **planowane**
+- Możliwość wyrażenia chęci adopcji wybranego zwierzaka. - **wymagane**
+- Dodawanie do polubionych fundacji i zwierząt. - **oczekiwane**
+- Możliwość zmiany hasła. - **wymagane**
+- Obliczanie odległości od schroniska na podstawie lokalizacji użytkownika. - **planowane**
+- Optymalizacja pobierania wpisów. - **wymagane**
+- Autoryzacja. - **wymagane**
+
+#### **Aplikacja webowa:**
+
+- Dodanie kreatora ankiet, które użytkownicy będą wypełniać w celu złożenia wniosku o adopcję danego zwierzęcia. - **wymagane**
+- Dodanie możliwości przeglądania nadesłanych wniosków z poziomu aplikacji. - **wymagane**
+- Dodanie małego workflow obiegu wniosków (zaakceptowany/odrzucony etc.). - **oczekiwane**
+- Przystosowanie aplikacji webowej również dla urządzeń mobilnych (breakpointy). - **oczekiwane**
+- Podpięcie api związanego z logowaniem zmianą hasła użytkowników. - **wymagane**
+- Panel umożliwiający prezentację płatności, które zostały przekazane na rzecz zwierząt z określonej fundacji. - **planowane**
+- Zrealizowanie poprawek przekazanych przez komisję na pierwszej obronie projektu. - **wymagane**
+
+#### **Aplikacja backendowa:**
+
+- Wdrożenie modułu płatności umożliwiającego datkowanie zwierząt. - **planowane**
+- Pokrycie testami. - **oczekiwane**
+- Tworzenie logiki biznesowej do ankiet adopcyjnych. - **wymagane**
+- Autoryzacja. - **wymagane**
+
+## **8. Organizacja pracy zespołu**
+
+- Komunikacją z klientem zajmował się Mateusz Lesiecki, polegała ona na wykonywaniu wideokonferencji z klientem oraz zespołem AportMe po ukończonym sprincie i prezentacji aktualnego stanu projektu. Klient oceniał funkcje projektu oraz ich UX. Głównym interesariuszem projektu jest TTB Poznań - fundacja zajmująca się pomocą Bulterierom. Fundacja ta jest również przyszłym klientem korzystającym z aplikacji w roli fundacji/schroniska.
+  Podział zespołu ze względu na technologię przedstawia się następująco:
+- _Dawid Wietrzych_ - Frontend
+- _Wojciech Jarmosz_ - Frontend, Backend
+- _Mateusz Lesiecki_ - Backend, Mobile
+- _Jacek Krakowski_ - Backend, Mobile
+
+- Z racji chęci ścisłej współpracy z fundacją pod kątem użyteczności funkcji w aplikacji, zdecydowaliśmy się na metodykę zwinną, opartą o kilkutygodniowe sprinty, po których następowała konsultacja z klientem.
+- Jakie narzędzia wspomagające prace projektowe wykorzystuje zespół? W jaki sposób zespół zarządza kodami źródłowymi? W jaki sposób zarządza przebiegiem projektu? Czy wykorzystuje się narzędzia CI/CD? Czy stosowane narzędzia są ze sobą zintegrowane? Jeśli tak, to w jaki sposób?<br/>
+  **Narzędzia:** Git, Github, Jira, Postman, Swagger, ESlint + Prettier, Husky<br/>
+  **Zarządzanie kodem:** Wzajemny Code Review członków zespołu<br/>
+  **Ci\CD:** Brak<br/>
+  **Czy zintegrowane:** Tak, w postaci zdalnego repozytorium, korzystanie z jego funkcji (PR,CR)
+- Cykl życia oprogramowania zaczyna się od dodania zadania do backlogu, programista przypisuje się do zadania, a następnie przystępuje do jego realizacji, każda nowa funkcjonalność jest tworzona na osobnym branchu na gicie. Co 3 dni odbywają się spotkania (na wzór daily) gdzie omawiamy problemy i ewentualne ich rozwiązania. Po skończeniu pracy nad funkcjonalnością, wystawiany jest pull request, a następnie przeprowadzanie Code Review. Po poprawkach w Code Review branch jest mergowany do głównego brancha - _develop_.
+
+## **9. Ryzyka projektowe**
+
+Z uwagi na złożoność niektórych funkcjonalności i ograniczenia technologiczne/sprzętowe, wdrożenie ich może okazać się niemożliwe lub znacznie utrudnione, do takich elementów należą:
+
+- Obsługa datkowania fundacji - rozwiązanie aspektów prawnych i bezpieczeństwa danych.
+- Obsługa lokalizacji użytkownika względem lokalizacji schroniska
+- Wdrożenie aplikacji mobilnej na system IOS.
+- Odpowiednie przetestowanie aplikacji pod kątem wydajności i bezpieczeństwa.
+- Integracja z systemami obsługi płatności - Dotpay, Przelewy24, lub innym.
+
+## **10. Kamienie milowe**
+
+#### **Listopad**
+
+- Stworzenie systemu do zarządzania ogłoszeniami przez fundacje.
+- Stworzenie kreatora ankiet adopcyjnych.
+- Stworzenie końcowego szkieletu REST API.
+
+#### **Grudzień**
+
+- Usprawnienie modułu Autoryzacji
+- Dodanie możliwości wypełnienia ankiety w aplikacji mobilnej.
+- Próba deploy'u aplikacji na serwer oraz wystawienie aplikacji mobilnej w Google Play
+
+#### **Styczeń**
+
+- Stworzenie wszystkich ekranów w aplikacji mobilnej
+- Testy i ewentualne poprawki REST API
+- Testy użytkowe aplikacji webowej i mobilnej

Witkowski/conference-page/dokument-wymagan-projektowych-2a.md

@@ -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. 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

Zywica/car-pool/README.md

@@ -1,3 +1,7 @@
-# Instrukcja
+# CARPOOL
 
-W tym katalogu należy umieścić dokumenty wizji systemu oraz wymagań projektowych zgodnie z szablonami.
+## Dokumenty 
+- [Dokument wymagań projektu](docs/project_requirements.md)
+---
+## Linki zewnętrzne
+- [GitHub]("https://github.com/carpool-team/carpool")

Zywica/car-pool/docs/project_requirements.md

@@ -0,0 +1,216 @@
+# Dokument wymagań projektowych
+
+## Nazwa projektu: Carpool
+
+## Autorzy: Michał Dulski, Julian Kobryński, Norbert Litkowski, Maciej Sobkowiak
+
+### 1. Elementy składowe projektu
+
+#### 1.1 Elementy programistyczne:
+
+- Aplikacja mobilna dla systemów Android stworzona przy pomocy biblioteki React Native.
+- Aplikacja mobilna dla systemów iOS stworzona przy pomocy biblioteki React Native.
+- REST API w języku C# oparty na frameworku .NET 5.
+- Identity Provider w języku C# i frameworku .NET 5.
+- Aplikacja webowa w języku TypeScript oparta na frameworku React.
+- Instancja bazy danych oparta o silnik MSSQL.
+
+#### 1.2 Elementy nieprogramistyczne:
+
+- Prototyp aplikacji webowej wykonany przy użyciu Adobe XD,
+- Prototyp aplikacji mobilnej wykonany przy użyciu Adobe XD,
+- Opis interfejsu API wykonany przy użyciu Swaggera,
+- Event Storming wykonany przy użyciu tablicy Miro.
+
+### 2. Granice projektu
+
+- Aplikacja mobilna w Apple AppStore – ze względu na ograniczenia budżetowe projektu, nie zdecydowaliśmy się na umieszczenie aplikacji w AppStore. Aplikacja będzie dostępna na platformie Google Play
+- Chat wewnątrz aplikacji – chcemy, aby aplikacja była jak najbardziej wyspecjalizowana. Ze względu, że użytkownicy korzystający z przejazdów wewnątrz jednej grupy najczęściej znają się, mają też prawdopodobnie kontakt w innej aplikacji do komunikacji tekstowej.
+- Przejazdy poza grupami – aplikacja skierowana jest do grup znajomych lub pracowników z jednej firmy. Zdecydowaliśmy, że przejazdy będą możliwe jedynie wewnątrz takich grup, gdyż do przejazdów między obcymi ludźmi istnieje wiele konkurencyjnych rozwiązań.
+- Aplikacja nie przewiduje rejestracji korporacyjnych lub grupowych. Każdy z użytkowników tworzy konto samodzielnie. Może natomiast zostać po rejestracji dodany do firmowej grupy. 
+- System nie będzie obsługiwał rozliczeń między uczestnikami przejazdów. Będą one z założenia dokonywane między zainteresowanymi.
+
+### 3. Lista wymagań funcjonalnych
+
+1. Jako użytkownik mogę stworzyć konto w aplikacji,
+2. Jako użytkownik mogę zalogować się do aplikacji używając loginu i hasła,
+3. Jako użytkownik mogę wylogować się z aplikacji,
+4. Jako użytkownik mogę usunąć swoje konto,
+5. Jako użytkownik mogę edytować swoje dane w aplikacji,
+6. Jako użytkownik mogę łatwo przełączać tryby aplikacji (tryb pasażera lub kierowcy),
+7. Jako użytkownik mogę przeglądać otrzymane zaproszenia do grup,
+8. Jako użytkownik mogę akceptować lub odrzucać zaproszenia do grup,
+9. Jako użytkownik mogę przeglądać grupy, do których należę,
+10. Jako użytkownik mogę wyświetlić szczegóły dowolnej grupy, do której należę,
+11. Jako użytkownik mogę opuścić grupę,
+12. Jako użytkownik mogę stworzyć nową grupę,
+13. Jako administrator mogę zapraszać użytkowników do grupy,
+14. Jako administrator mogę usuwać członków grupy,
+15. Jako administrator mogę przeglądać zaplanowane przejazdy w grupie,
+16. Jako administrator mogę przeglądać odbyte przejazdy w grupie,
+17. Jako administrator mogę edytować dane grupy,
+18. Jako administrator mogę usunąć grupę,
+19. Jako administrator mogę wygenerować raport działalności grupy w wybranym przedziale czasowym,
+20. Jako pasażer mogę przeglądać przejazdy w grupach,
+21. Jako pasażer mogę wysyłać prośby o dołączenie do przejazdu,
+22. Jako pasażer mogę przeglądać przejazdy, do których jestem zapisany,
+23. Jako pasażer mogę przeglądać przejazdy, w których uczestniczyłem,
+24. Jako pasażer mogę przeglądać szczegóły przejazdu,
+25. Jako pasażer mogę zrezygnować z przejazdu, na który się zapisałem,
+26. Jako kierowca mogę tworzyć przejazdy jednorazowe lub regularne,
+27. Jako kierowca mogę wyświetlać prośby o dołączenie do przejazdu,
+28. Jako kierowca mogę akceptować lub odrzucać prośby o dołączenie do przejazdu,
+29. Jako kierowca mogę wyświetlać zaplanowane przejazdy,
+30. Jako kierowca mogą wyświetlać odbyte przejazdy,
+31. Jako kierowca mogę wyświetlić szczegóły przejazdu,
+32. Jako kierowca mogę usuwać pasażerów z przejazdu,
+33. Jako kierowca mogę anulować przejazdy,
+
+### 4. Lista wymagań niefuncjonalnych
+
+1. Internacjonalizacja – system musi posiadać lokalizowane zasoby tekstowe
+2. Dostępność - aplikacja mobilna musi być dostępna dla systemów Android 4.4 (API 19+), ze względu na to, że wsparcie dla tej wersji wzwyż zapewnia obsługę większości użytkowników systemu Android
+3. Dostęp do repozytorium kodu - repozytorium kodu systemu będzie publicznie dostępne
+4. Aplikacja webowa dostępna dla przeglądarek mobilnych oraz desktopowych - MS Edge, Firefox, Chrome, Safari, Opera  
+5. Autoryzacja tradycyjna w oparciu o JWT
+
+### 5. Mierzalne wskaźniki wdrożeniowe
+
+- Aplikacja webowa zostanie udostępniona na domenie carpool.com.pl i za jej pomocą w systemie zostanie utworzone co najmniej 5 grup obejmujących co najmniej 25 użytkowników.
+- W obrębie każdej grupy zostanie wykonany co najmniej jeden przejazd.
+- Aplikacja mobilna zostanie udostępniona na Google Play i będzie z niej korzystać co najmniej 20 osób.
+- REST API zostanie poddane testom obciążeniowym, które zapewnią, że maksymalny czas odpowiedzi z serwera dla nie więcej niż 100 użytkowników jednoczenie nie przekroczy 2 sekund
+
+### 6. Kryteria akceptacji projektu dla I semestru prac
+
+#### 1. Wymagane
+
+- Prototyp aplikacji
+- Możliwość tworzenia grup z poziomu aplikacji webowej
+- Spójna stylistycznie z prototypem aplikacja webowa
+- Możliwość tworzenia przejazdów w aplikacji mobilnej
+- Możliwość zapisu na istniejące przejazdy w aplikacji mobilnej
+- Spójna stylistycznie z prototypem aplikacja mobilna
+- Serwer REST API obsługujący obie aplikacje
+- Zintegrowanie REST API z bazą danych
+
+#### 2. Oczekiwane
+
+- Wyświetlanie lokalizacji grup i punktów odbioru na mapie
+- Wdrożenie aplikacji webowej na Azure
+- Wdrożenie serwera REST API na Azure
+
+#### 3. Planowane
+
+- Zapraszanie użytkowników do dołączenia do grupy w aplikacji webowej
+- Wyświetlanie informacji o grupach w aplikacji mobilnej
+
+### 7. Kryteria akceptacji projektu dla II semestru prac
+
+#### 1. Wymagane
+
+- Możliwość tworzenia kont użytkowników z poziomu aplikacji mobilnej i webowej
+- Identity provider zapewniający dostęp do zasobów REST API
+- Zarządzanie grupami (edycja danych grupy, dodawanie/usuwanie użytkowników należących do grupy, wyświetlanie przejazdów odbywających się w danej grupie)
+- Możliwość wyświetlania danych o odbytych przejazdach w aplikacjach mobilnej i webowej
+- Możliwość tworzenia przejazdów i zarządzania nimi w aplikacjach mobilnej i webowej
+- Pozytywne zakończenie testów obciążeniowych REST API
+- Wymagania funkcjonalne: 1, 2, 3, 4, 6, 8, 11, 12, 13, 14, 17, 20, 21, 26, 27, 28, 31, 32, 33
+
+#### 2. Oczekiwane
+
+- Generowanie raportów podsumowujących przejazdy w danej grupie
+- Udostępnienie aplikacji webowej na domenie carpool.com.pl
+- Udostępnienie aplikacji mobilnej w sklepie Google Play
+- Testy akceptacyjne aplikacji mobilnej
+- Testy akceptacyjne aplikacji webowej
+- Wymagania funkcjonalne: 5, 7, 9, 10, 15, 17, 18, 19, 22, 23, 24, 25, 29, 30, 33
+
+#### 3. Planowane
+
+- Możliwość logowania się przy użyciu konta Google
+- Podział kosztów na uczestników przejazdu wewnątrz systemu
+- Identity provider ma umożliwić uwierzytelnianie przy użyciu zewnętrznych dostawców tożsamości (Google, Facebook)
+
+### 8. Organizacja pracy zespołu
+
+#### Zespół projektowy
+
+- Maciej Sobkowiak - Product Owner, Web Developer
+
+  - Zarządzanie zadaniami w projekcie
+  - Projektowanie prototypu aplikacji webowej
+  - Implementacja aplikacji webowej
+
+- Michał Dulski – Backend Developer
+
+  - Projektowanie architektury serwera REST API
+  - Implementacja aplikacji serwera REST API
+  - Implementacja identity provider’a
+  - Zarządzanie zasobami platformy chmurowej
+  - Kontakt z klientem
+
+- Norbert Litkowski – Web Developer
+
+  - Projektowanie architektury aplikacji webowej
+  - Implementacja aplikacji webowej
+  - Integracja aplikacji webowej z platformą chmurową
+
+- Julian Kobryński – Mobile Developer
+  - Projektowanie prototypu aplikacji mobilnej
+  - Implementacja aplikacji mobilnej
+  - Projektowanie architektury aplikacji mobilnej
+
+#### Kontakt z klientem
+
+Organizujemy regularne spotkania z klientem, na których przedstawiamy postępy, które poczyniliśmy od ostatniego spotkania i dyskutujemy o planach na dalszy rozwój aplikacji. Prezentujemy również nasze pomysły na zmiany lub usprawnienia w aplikacji oraz ewentualne problemy, które napotkaliśmy.
+
+#### Cykl życia zdania w projekcie
+
+Każde zadanie po powstaniu umieszczane jest w kolumnie “To Do”, a następnie jest przypisywane do osoby, która będzie odpowiedzialna za jego zrealizowanie. Kiedy programista rozpoczyna prace nad zadaniem przenosi je do kolumny “In Progress”. Wykonane zadanie trafia do kolumny “QA” (Quality Assurance) i tworzony jest Pull Request. Inny członek zespołu przygląda się zmianom wprowadzonym w związku z danym zadaniem i jeśli uważa, że zostało wykonane prawidłowo, akceptuje Pull Request i kod trafia na główną gałąź w repozytorium, a zadanie do kolumny “Done”.
+
+#### Metodyka pracy
+
+Metodyka pracy, według której realizujemy projekt od samego początku to klasyczny Scrum. W początkowej fazie projektu wypełniliśmy backlog i oszacowaliśmy wszystkie zadania. Organizujemy dwutygodniowe sprinty, do których przydzielamy kilka zadań z backlogu. Zdecydowaliśmy się na tę metodykę, ponieważ została ona nam zasugerowana oraz dokładnie wytłumaczona przez promotora projektu i uważamy, że jest najbardziej skuteczna.
+
+#### Narzędzia wspomagające
+
+- Aplikacja webowa – przy każdym commicie na główną gałąź w repozytorium uruchamiany aplikacja jest budowana w chmurze Azure. Jeśli build zakończy się sukcesem, uruchamia się release pipeline, który ten build umieszcza w odpowiednim folderze na serwerze
+- Aplikacja serwerowa – przy każdym commicie na główną gałąź repozytorium uruchamiany jest workflow w GitHub Actions, który najpierw buduje aplikację, a następnie publikuje aplikację webową w chmurze Azure oraz dodaje logi całej operacji w chmurze.
+
+- [Repozytorium kodu](https://github.com/carpool-team/carpool) - korzystamy z publicznego repozytorium na platformie GitHub 
+
+- [Jira](https://jira.wmi.amu.edu.pl/secure/RapidBoard.jspa?rapidView=281&projectKey=CARP&view=planning.nodetail) - służy nam do planowania pracy w oparciu o metodykę Agile
+
+### 9. Ryzyka projektowe
+
+- Określone ramy czasowe na stworzenie projektu okazały się nie wystarczające do całkowitego stworzenia aplikacji.
+- Brak osób zainteresowanych korzystaniem z aplikacji –wymagane samodzielne korzystanie i testowanie aplikacji przez członków zespołu.
+- Projekt jest o podwyższonym stopniu ryzyka ze względu na sytuację pandemiczną na świecie w związku z rozprzestrzenianiem się wirusa COVID-19. W związku z powyższym, testy z udziałem prawdziwych użytkowników mogą nie być możliwe do wykonania.
+- Nieporozumienia w zespole dotyczące rozwiązań implementacyjnych, architektury, funkcjonalności lub używanych technologii
+- Odejście członka zespołu - w zależności osoby, problem w ukończeniu składowej projektu.
+- Brak doświadczenia w wdrażaniu aplikacji serwerowej na platformy chmurowe.
+- Brak zaangażowania w projekt ze strony członków zespołu (niedostarczanie funkcjonalności na czas, brak komunikacji)
+- Nagły brak wsparcia jednej z wykorzystywanych technologii lub narzędzia –konieczność zmiany narzędzi/technologii i implementacja funkcjonalności od zera w oparciu o nowe rozwiązanie albo modyfikacja obecnie istniejących funkcjonalności, aby działały z nowo wybraną technologią/narzędziem.
+
+### 10. Kamienie milowe
+
+#### Faza 1 (I semestr), do czerwca 2020:
+
+- Przygotowanie prototypu aplikacji mobilnej
+- Wypełnienie backlogu w systemie Jira
+- Rozpoczęcie prac programistycznych nad aplikacją serwerową, webową i mobilną
+- Utworzenie zasobów do hostowania bazy danych, aplikacji webowej i aplikacji serwerowej na platformie Azure
+- Ukończenie MVP projektu
+- Wdrożenie MVP aplikacji serwerowej na platformę Azure
+
+#### Faza 2 (II semestr), do stycznia 2021:
+
+- Ukończenie zaplanowanych funkcjonalności w aplikacji mobilnej, webowej i serwerowej
+- Utworzenie zasobów do hostowania identity provider’a na platformie azure
+- Konfiguracja narzędzi ciągłej integracji (CI) dla aplikacji serwerowej REST API
+- Konfiguracja narzędzi ciągłej integracji (CI) dla identity provider’a
+- Konfiguracja narzędzi ciągłej integracji (CI) dla aplikacji webowej
+- Opublikowanie aplikacji mobilnej w Play Store
+- Stworzenie testów dla aplikacji webowej i serwerowej
+- Opublikowanie aplikacji webowej w domenie internetowej