niezbednikstudenta_docs/Witkowski/aport-me/dokument_wymagan_projektowych.md

216 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 Googlea 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