W oparciu o diagram DFD wyszczególniamy cztery rodzaje interfejsów :
Interfejs użytkownika niezalogowanego pozwala na przeglądanie zagrożeń naniesionych na mapę oraz proste wyszukiwanie zagrożeń według rodzaju lub stopnia zagrożenia. Dostęp do większej funkcjonalności uzyskać może poprzez dokonanie procesu rejestracji. Proces rejestracji pozwala na natychmiastowe utworzenie konta.
Użytkownik po zalogowaniu otrzymuje dostęp do wszystkich funkcjonalności użytkownika niezalogowanego. Uzyskuje możliwość administracji swoim kontem, poprzez możliwość obejrzenia swoich danych wprowadzonych podczas rejestracji. Rozbudowana została możliwość wyszukiwania o przeszukiwanie zagrożeń względem horyzontu czasowego. Użytkownik dysponuje możliwością ręcznego dodania zagrożenia.
Prototyp interfejsu moderatora zawiera wszystkie funkcjonalności użytkownika zalogowanego.
Administrator otrzymuje, oprócz wszystkich wymienionych wcześniej funkcjonalności, możliwości zarządzania kontami użytkowników. Dysponuje narzędziem do przeglądania wszystkich założonych kont, oraz możliwością ich manualnego założenia oraz usunięcia. Administrator może dokonać usunięcia zagrożenia.
Panel sterowania aplikacją jest w zasadzie zgodny z interfejsami wszystkich użytkowników (zalogowanego, moderatora oraz administratora). Patrząc pod kątem aplikacji potrzebne funkcje wyszczególnione w diagramie STD zostały ujętne w panelach użytkownika zalogowanego, moderatora oraz administratora.
Aplikacja uruchamiana i testowana jest na serwerze lokalnym. Podczas procesu testowaniu uwzględniliśmy :
Dane w postaci mapy Krakowa wprowadzane sa on-line przy pomocy API do google - maps. Znajdują się one na zewnętrznych serwerach należących do Google. Ręcznie wprowadzane są dane opisujące zagrożenia. Proces rejestracji użytkownika odbywa się w dwojaki sposób. Administrator dysponuje możliwością recznego założenia konta. Dodatkowo każdy niezalogowany użytkownik ma możliwość automatycznej rejestracji.
W obecnej chwili projektu jest na etapie „development”, wymaga wdrożenia po pełnym ukończeniu.
Projekt tworzony jest etapami:
W celu użytkowania serwisu konieczne jest zapoznanie się z metodami:
Rolę dokumentacji technicznej pełni czytany właśnie raport końcowy. Składa się on z trzech części, będący rówocześnie poszczególnymi etapami realizacji projektu:
Dodatkowo informacje zawarte w raporcie zostały zamieszczone w systemie wiki.
W projekcie zaimplementowano szkielet kompletnego portalu społecznościowego opartego o diagram hierarchi funkcji. W celu uzyskania pełnej zakładanej funkcjonalności należy dokonać utworzenia ciała funkcji realizujących:
Po dokonaniu tego procesu należy dokonać wdrożenia systemu opisane w wcześniejszych rozdziałach.
Panel sterowania aplikacji wymaga uzupełnienia działów:
Również istotną rzeczą jest dodanie obsługi wielojęzykowości. W obecnej chwili aplikacja stworzona jest jedynie z myślą o użytkownikach dysponujących podstawową znajomością języka angielskiego.
W kwestii technicznej istnieje możliwość ukierunkowania serwisu w stronę technologii Ajax, która mogłaby być jeszcze mocniej wykorzystywana w celu ułatwienia obsługi systemu przez użytkownika. Dodatkowo proces rejestracji należy wyposażyć w system potwierdzenia dokonania rejestracji przez konkretnego użytkownika. Można zrealizować to poprzez wysyłanie wiadomości e-mail weryfikującej prawdziwość podanej poczty elektronicznej.
Całkowity czas realizacji prototypu wyniósł 5 miesięcy. W początkowej fazie projektu związany był on z potrzebą zapoznania się z wiedzą teoretyczną dotyczącą realizowanego zagadnienia. Po dokonaniu wyboru technologii kolejny okres czasu został przeznaczony na dogłębne zapoznanie się z wybranymi narzędziami. Najdłuższy okres czasu został poświęcony na realizację właściwej aplikacji.
Koszty projektu były zerowe. Wynika to z dużej dostępności materiałów pomocnicznych na darmowych serwisach. Niestety, brak opłat za korzystanie z materiałów często odbijał się na jakości prezentowanych rozwiązań. Podczas realizacji aplikacji bardzo często zmuszeni byliśmy do przywracania starszych wersji projektów. Spowodowane to było faktem, że część rozwiązań działała w sposób odmienny niż prezentowano to w materiałach dydaktycznych.
W przypadku wdrożenia systemu do czasu realizacji projektu należałoby dodać czas potrzebny na przeprowadzenie dogłębnych testów aplikacji na serwerze globalnym, przy znacznym obciążeniu ze strony użytkowników. W przypadku zrealizowanego prototypu dokonano jedynie testów na serwerach lokalnych.
Projekt został oparty o następujące technologie:
