Projekt konceptualny

1. Sformułowanie zadania projektowego:

Tematem niniejszego projektu jest stworzenie portalu służącego do optymalizacji rozliczania należności finansowych wśród grup osób. Optymalizacja ta polega między innymi na zmniejszeniu operacji „spłacania długów” pomiędzy osobami w grupie rozliczeniowej oraz minimalizacji przepływu gotówkowego. Motywacją do podjęcia projektu jest zaobserwowanie potencjalnego zainteresowania wśród społeczności młodych internautów. Rozliczanie należności finansowych pośród grup młodych ludzi nierzadko wiąże się z problemami dotyczącymi:

  • Pamiętania o zobowiązaniu finansowym wobec osób w grupie;
  • Wygody w przekazywaniu gotówki (ilość wierzycieli, wielkość przezywanych kwot);
  • Rozliczeń gotówkowych (wydawania reszty, posiadania odpowiedniej ilości gotówki przy sobie).

Rozwiązanie przedstawione w projekcie ma szansę na komercyjne zastosowanie, dzięki nowatorskiemu podejściu do aspektu rozliczania się. W toku poszukiwań podobnych portali internetowych o zbliżonej tematyce, nie udało się znaleźć aplikacji o choćby zbliżonym działaniu. Należy również zauważyć, że proponowane narzędzie może być niezwykle przydatne dla grup znajomych, rodziny, itp. Docelowo korzystanie z portalu będzie całkowicie bezpłatne. Po osiągnięciu rozpoznawalnej marki, zyski będą czerpane z umieszczanych na portalu reklam.

2. Analiza stanu wyjściowego

Poszukiwania portalu internetowego, który realizowałby zagadnienia rozliczeń grupowych, nie przyniosły rezultatów. Jedynymi aplikacjami o zbliżonej tematyce są portale udostępniające narzędzia rozliczeń finansowych dotyczących rozliczania podatków, faktur, itp. Należy jednak zauważyć, że temat poniższego projektu nie jest związany z aplikacjami księgowymi.

3. Analiza wymagań użytkownika (wstępna)

Ułatwienie rozliczeń grupowych:

  • Tworzenie, anulowanie i potwierdzanie zobowiązań finansowych (M);
  • Baza zawartych zobowiązań finansowych (M);
  • Algorytm optymalizowania przepływu należności finansowych wewnątrz grup (M);
  • Informacyjne powiadomienia mailowe (S);
  • Rozróżnienie dwóch poziomów grup użytkowników: (S)
    • grupy rozliczeniowe z optymalizacją automatyczną,
    • grupy rozliczeniowe z optymalizacją wymuszaną każdorazowo;
  • Nadawanie priorytetów kierunkowi przepływu zobowiązań (C);

Społecznościowy charakter portalu:

  • Konta użytkowników (M);
  • Grupy rozliczeniowe (M);
  • Profile użytkowników widoczne wewnątrz grup (S);
  • System komunikacji pomiędzy użytkownikami (wiadomości prywatne, itp.) (C).

Wygoda obsługi aplikacji:

  • Czytelny i przejrzysty interfejs użytkownika (M);
  • Atrakcyjny wygląd graficzny (M);
  • Łatwa nawigacja w serwisie (M);
  • System pomocy (C);
  • Przenośność aplikacji pod kątem urządzeń mobilnych (W).

4. Określenie scenariuszy użycia.

  • Rejestracja;
  • Logowanie;
  • Dodawanie zobowiązania finansowego:
    • Wybór osoby;
    • Podanie kwoty zobowiązania;
    • Wprowadzenie komentarza do zobowiązania (opcjonalnie);
    • Wysłanie zobowiązania.
  • Potwierdzenie przyjęcia / odrzucenie zobowiązania;
  • Zakańczanie zobowiązania;
  • Edycja profilu użytkownika;
  • Obsługa grup użytkowników:
    • Tworzenie grupy,
    • Zapraszanie użytkowników do grupy,
    • Potwierdzanie członkostwa w grupie,
    • Usuwanie użytkownika z grupy,
    • Usuwanie grupy.
  • Przeglądanie zobowiązań finansowych.

5. Identyfikacja funkcji.

  • Rejestracja: dodanie nazwy użytkownika, zakodowanego hasła oraz podstawowych danych użytkownika do bazy danych;
  • Logowanie: wyszukanie zadanego użytkownika w bazie danych oraz porównanie wprowadzonego hasła z przechowywanym hashem;
  • Dodawanie zobowiązania finansowego: dodanie odpowiedniego rekordu do bazy danych;
  • Potwierdzenie przyjęcia / odrzucenie zobowiązania: modyfikacja atrybutu zobowiązania finansowego w bazie danych;
  • Zakańczanie zobowiązania: usunięcie odpowiedniego rekordu z bazy danych;
  • Edycja profilu użytkownika: modyfikacja rekordu związanego z użytkownikiem;
  • Obsługa grup użytkowników: dodawanie, usuwanie, modyfikacja rekordów związanych z grupą użytkowników;
  • Przeglądanie zobowiązań finansowych: pobranie danych z odpowiednich rekordów z bazy danych.

6. Analiza hierarchii funkcji projektowanej aplikacji

(FHD – Functional Hierarchy Diagram); określenie struktury zależności hierarchicznych pomiędzy jednostkami analizowanego systemu, zwłaszcza w zakresie specyfikacji wymagań funkcjonalnych. Specyfikacja funkcji (funkcjonalności) projektowanego systemu.

7. Budowa i analiza diagramu przepływu danych

8. Wybór encji (obiektów) i ich atrybutów.

  • user:
    • login,
    • password,
    • name,
    • surname,
    • email,
    • birthdate,
    • logdate,
    • regdate.
  • groups:
    • groupID,
    • groupname,
    • groupowner,
    • autooptymalization.
  • groupmembers:
    • login,
    • groupID.
  • commitments:
    • commitmentID,
    • commitmentname,
    • obligor,
    • obligee,
    • groupID,
    • commitmentowner,
    • sum,
    • comment,
    • commitmentdate,
    • status.
  • groupjoin:
    • groupjoinID,
    • groupjoinowner,
    • groupID,
    • login,
    • invitation.
  • sessions:
    • sessionID,
    • login,
    • userIP,
    • rememberme.

9. Projektowanie powiązań (relacji) pomiędzy encjami.

10. Projekt diagramów STD.

pl/dydaktyka/ztb/2011/projekty/rozliczenia/start/projekt_konceptualny.txt · ostatnio zmienione: 2019/06/27 15:50 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0