Projekt

Obecné

Profil

Product Vision Statement » Historie » Verze 47

Alex Konig, 2021-05-06 08:21

1 31 Alex Konig
h1. Product Vision Statement
2 1 Roman Kalivoda
3
h2. Project Goals
4
5 11 Zuzana Káčereková
Creating an application that will based on weather input, predict the attendance in class. User will be able to input their own weather information or choose a prediction based on current weather information or prediction for future days.
6 5 Roman Kalivoda
7 10 Alex Konig
h3. Customers and benefits
8
9 11 Zuzana Káčereková
Can be useful for teachers when planning for activities that require higher attendance. For example, if the teacher wants to give their students a pop quiz about their current knowledge from lectures, to get a better idea of the class's general understanding it would be good to have as many answers as possible. This app would enable to predict the attendance for a class, and therefore to decide if it is worth it to plan a 30min window in the lecture for a quiz or to rather plan something else.
10 6 Alex Konig
11 11 Zuzana Káčereková
It could also be useful for students to decide how early to get to class to get the best seats. Many classrooms only have a limited number of plugs, and since a lot of students write notes on their laptops, the seats near these plugs are highly valuable. This app would enable the students to look how at how populated the building will be and decide if coming early to the lecture will be necessary to get those good seats.
12 6 Alex Konig
13 12 Zuzana Káčereková
h3. User input
14 1 Roman Kalivoda
15 35 Alex Konig
* Date (or system date) - dd:mm:yyyy + Time - hh
16
** Start and end dateTime for prediction of rush level over a timespan, or just start dateTime for prediction at one specific time
17
* Weather
18
** automatic prediction from official weather server prediction 
19
** possibility to manually input custom values - temperature, wind, rain probability, weather conditions (sunny/cloudy/overcast/dark)  
20
* classroom prefix (-> will be interpreted as building the classroom is in)
21 1 Roman Kalivoda
22 6 Alex Konig
h3. Output
23 8 Alex Konig
24 36 Alex Konig
* Rush level (very calm, calm, average, busy, very busy)
25
** Visualization as a "heatmap" showing rush across the campus
26
** If user put end date an animation of changes in rush level
27 25 Alex Konig
28 44 Alex Konig
Prediction is made on the level of buildings, potentially groups of buildings in the city centre, as divided in [[Data sources]]. Rush level is relative to the building it is related to. 50% on FAV does not have to mean the same predicted value of activity as 50% on FST, it depends on usual amount of activity read from data for each specific building
29 37 Alex Konig
30 1 Roman Kalivoda
h3. Happy Day use-case
31 25 Alex Konig
32 45 Alex Konig
The user will specify a date, time and classroom (e.g. UC, 23.6.2021 7am) for which they wish to get the prediction of attendance. It will be possible to choose to have the weather forecast data for the given day downloaded automatically or user has to option to input custom weather manually. The output of the app will be a text field and a heatmap saying the rush level the model predicts (e.g. very high and a brightly lit up building).
33 25 Alex Konig
34 14 Zuzana Káčereková
h3. Key factors to judge application quality
35 1 Roman Kalivoda
36 14 Zuzana Káčereková
* Application response time
37 32 Alex Konig
* UI design appeals to the customer
38 14 Zuzana Káčereková
* Maintainability (as a measure of effort required to update the model with new data)
39 10 Alex Konig
40 39 Alex Konig
Prediction quality is not guaranteed at this stage as data quality is out of our control and hugely impacts the output. Quality should also improve over time as more data is collected by ZČU.
41 1 Roman Kalivoda
42 25 Alex Konig
h3. Key product features
43 17 Zuzana Káčereková
44 1 Roman Kalivoda
h4. Server (backend) part
45 17 Zuzana Káčereková
46 1 Roman Kalivoda
There will be a server application which:
47 46 Alex Konig
* *Runs on linux*
48
* *Will run predictions based on client app requests and send the response once it is ready.*
49 1 Roman Kalivoda
* Software designed to support smooth model transition
50 46 Alex Konig
** *Modular application*, easy to swap parts (for ex. spap for different data parser or data loader or possibly in the future for different data)
51
* Configuration file read upon launch
52
** *Modifies local data folder path* 
53
** Modifies link to online directory open data
54
* Admin requests
55
*** Capable of checking for new data in online files directory
56
** *Capable of updating data at admin request* - download new files from online directory
57
** *Capable of retraining prediction model on admin request*
58
*** Capable of rollback
59
* Capable of fullfiling requests and send answers to more than one client applications.
60 1 Roman Kalivoda
61
We decided that the backend will be developed in C# and .NET platform.
62
63
h4. Frontend app
64 34 Alex Konig
65 5 Roman Kalivoda
* Able to specify input parameters
66 46 Alex Konig
** *User will be able to specify an arbitrary classroom prefix at ZCU*
67
** *User has the option to use an automatic weather forecast*
68
** *User will be able to specify arbitrary weather conditions (e.g. temperature, precipitation)*
69
** *These input data will be made into a web request and sent to the server*
70 34 Alex Konig
* Able to access and visualize prediction using the earlier specified input parameters
71 46 Alex Konig
** *Heat map type visualisation*
72
** *Able to easily browse prediction across a greater range of time* - rewind, play, move step-by-step
73
* User interface
74
** *Web application - WebGL*
75
** Mobile application - Android
76 1 Roman Kalivoda
77
The app will be written in C# and Unity framework.
78
79 33 Alex Konig
h2. Project Plan
80
81 1 Roman Kalivoda
See Redmine tab Roadmap.
82
83
84
h2. Stakeholders
85
86 24 Alex Konig
* Development Team
87
* Project Sponsor
88 1 Roman Kalivoda
* Project Mentor
89
* Users: lecturers teaching classes at ZČU
90
* Users: students attending classes at ZČU
91 22 Zuzana Káčereková
92 4 Roman Kalivoda
h2. Risks
93 23 Zuzana Káčereková
94 4 Roman Kalivoda
h3. Available data is too crude
95 21 Zuzana Káčereková
96 4 Roman Kalivoda
Chances are that the data is not specific enough to make proper predictions for some buildings, much less single classrooms. Hopefully, the model could be improved gradually when there is more data available. In the meantime, the granularity will be selected based on the model quality we achieve.
97
98
h3. Our effort estimation may be grossly underestimated
99
100
We should define/negotiate a minimum viable product and prioritize individual features.
101 21 Zuzana Káčereková
102 1 Roman Kalivoda
h3. We proposed an unsuitable technological stack
103 26 Alex Konig
104
Due to our unfamiliarity with web programming we've chosen to use technologies closer to our previous experience. These limit us in that the web application will not be easily compatible with mobile platforms. However, in turn, we can easily implement more complex UI and visualizations, and with some extra effort produce both a web and a mobile application using the same components.
105
106 27 Alex Konig
h2. Solution
107 29 Alex Konig
108
[[Minimum viable product]]
109
110 30 Alex Konig
h2. Details
111 1 Roman Kalivoda
112
For more details about implementation and processed data consult [[Project details]]