+ Create project requirements document. Update README.md

Zywica/car-pool/README.md

@@ -1,3 +1,3 @@
-# Instrukcja
+# CARPOOL
 
-W tym katalogu należy umieścić dokumenty wizji systemu oraz wymagań projektowych zgodnie z szablonami.
+[Dokument wymagań projektu](docs/project_requirements.md)

Zywica/car-pool/docs/project_requirements.md

@@ -0,0 +1,207 @@
+# 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 w Apple AppStore – ze względu na ograniczenia budżetowe projektu, nie zdecydowaliśmy się na umieszczenie aplikacji w AppStore.
+- 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ń.
+
+### 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ń funcjonalnych
+
+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
+4. Aplikacja webowa dostępna dla przeglądarek mobilnych oraz desktopowych
+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
+- Udostępnienie aplikacji mobilnej w Google Play
+- Pozytywne zakończenie testów obciążeniowych REST API
+
+#### 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
+
+#### 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.
+
+### 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