Zaktualizuj 'Witkowski/aport-me/dokument_wymagan_projektowych.md'
This commit is contained in:
parent
f7091f82f0
commit
907659e28a
@ -1,215 +1,216 @@
|
||||
# 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
|
||||
# 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.1 | 16.01.2021r. | Poprawka opisu organizacji pracy zespołu |
|
||||
|
||||
## **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:** DBeaver, Jira, Postman, Swagger, ESlint + Prettier, Husky<br/>
|
||||
**Zarządzanie kodem:** Git, Github, wzajemny Code Review członków zespołu<br/>
|
||||
**CI\CD:** Docker, GitHub Actions<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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user