DPRI_doc_20-21/Witkowski/aport-me/dokument_wymagan_projektowych.md

14 KiB
Raw Permalink Blame History

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?
    Narzędzia: Git, Github, Jira, Postman, Swagger, ESlint + Prettier, Husky
    Zarządzanie kodem: Wzajemny Code Review członków zespołu
    Ci\CD: Brak
    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