Product Vision Statement » Historie » Verze 70
Alex Konig, 2021-05-12 10:48
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 | 52 | Alex Konig | h3. Product features |
43 | 17 | Zuzana Káčereková | |
44 | 49 | Alex Konig | Bold parts are part of Minimum viable product. |
45 | |||
46 | 1 | Roman Kalivoda | h4. Server (backend) part |
47 | 17 | Zuzana Káčereková | |
48 | 1 | Roman Kalivoda | There will be a server application which: |
49 | 58 | Alex Konig | |
50 | 64 | Alex Konig | * *Command line application* |
51 | |||
52 | 46 | Alex Konig | * *Runs on linux* |
53 | 63 | Alex Konig | ** *Test on openNebula* |
54 | ** *OS: Debian GNU/Linux 10, version 10.9* |
||
55 | 62 | Eliška Mourycová | ** HW requiremnts: TBD (default settings when creating VM on OpenNebula seem to suffice) |
56 | 58 | Alex Konig | |
57 | 46 | Alex Konig | * *Will run predictions based on client app requests and send the response once it is ready.* |
58 | 58 | Alex Konig | |
59 | 1 | Roman Kalivoda | * Software designed to support smooth model transition |
60 | 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) |
61 | 58 | Alex Konig | |
62 | 66 | Alex Konig | * *Configuration file read upon launch* |
63 | 1 | Roman Kalivoda | ** *Modifies local data folder path* |
64 | 46 | Alex Konig | ** Modifies link to online directory open data |
65 | 1 | Roman Kalivoda | ** Link to weather prediction data |
66 | |||
67 | 64 | Alex Konig | * *Works with zču open data* |
68 | ** *Data in question: historic weather data, jis activity, computer activity* |
||
69 | 1 | Roman Kalivoda | ** *Can interpret as whole day* |
70 | 63 | Alex Konig | ** *Can interpret as hourly intervals* |
71 | 1 | Roman Kalivoda | |
72 | 64 | Alex Konig | * *Works with weeather prediction, always for today, tommorrow and the day after tommorow* |
73 | 1 | Roman Kalivoda | |
74 | * *Communication with Front end app* |
||
75 | 58 | Alex Konig | ** *HTTPS server implementation* |
76 | 63 | Alex Konig | |
77 | 65 | Alex Konig | * *Admin requests* |
78 | 51 | Alex Konig | ** Capable of checking for new open data in online files directory |
79 | 64 | Alex Konig | ** *Capable of writing out data that the current model was trained on* |
80 | 46 | Alex Konig | ** *Capable of updating data at admin request* - download new files from online directory |
81 | 58 | Alex Konig | *** Download for certain timespan |
82 | *** *Download for specific month* |
||
83 | 1 | Roman Kalivoda | |
84 | 58 | Alex Konig | ** *Capable of retraining prediction model on admin request* |
85 | *** Retraining for data from specific timespan -> filter out other files |
||
86 | 1 | Roman Kalivoda | *** *Can divide day into multiple intervals for which it will predict, or predict for day only* |
87 | *** *Capable of rollback* |
||
88 | 64 | Alex Konig | **** *No history preserved, capable of only switching to the "previous" used model* (only keeps in memory one previous model) |
89 | 1 | Roman Kalivoda | |
90 | * Capable of fullfiling requests and send answers to more than one client applications. |
||
91 | |||
92 | |||
93 | We decided that the backend will be developed in C# and .NET platform. |
||
94 | 64 | Alex Konig | |
95 | |||
96 | 1 | Roman Kalivoda | h4. Frontend app |
97 | 34 | Alex Konig | |
98 | 5 | Roman Kalivoda | * Able to specify input parameters |
99 | 67 | Alex Konig | ** *User able to specify either one speicfic time, or time interval (between today and the day after tommorrow) for which will be created rush prediction* |
100 | 46 | Alex Konig | ** *User will be able to specify an arbitrary classroom prefix at ZCU* |
101 | ** *User has the option to use an automatic weather forecast* |
||
102 | ** *User will be able to specify arbitrary weather conditions (e.g. temperature, precipitation)* |
||
103 | 53 | Alex Konig | |
104 | 34 | Alex Konig | * Able to access and visualize prediction using the earlier specified input parameters |
105 | 46 | Alex Konig | ** *Heat map type visualisation* |
106 | 54 | Alex Konig | *** *Navigation (zoom, pan)* |
107 | *** *Pngs for separate buildings* |
||
108 | 1 | Roman Kalivoda | *** *Animating colours representing rush level* |
109 | 68 | Alex Konig | ** *Center "camera" on selected building* (used when searching for a specific building, so user doesn't have to navigate manually) |
110 | ** *Able to easily browse prediction across a greater range of time* |
||
111 | *** *Rewind, play, move step-by-step* |
||
112 | 1 | Roman Kalivoda | |
113 | 68 | Alex Konig | * *Legend describing* |
114 | ** *Buildings* |
||
115 | ** *Rush level visualistaion* |
||
116 | ** *Work with application* (instead of tooltips) |
||
117 | 53 | Alex Konig | |
118 | 48 | Alex Konig | * Accessible design |
119 | 53 | Alex Konig | ** Tooltips |
120 | 60 | Alex Konig | ** Date picker / *tabs to change cells* |
121 | 54 | Alex Konig | ** *Visible checkboxes* |
122 | 53 | Alex Konig | ** Autocomplete |
123 | 60 | Alex Konig | ** *Date format always visible* |
124 | 1 | Roman Kalivoda | |
125 | 53 | Alex Konig | * User interface |
126 | 46 | Alex Konig | ** *Prevent illogical operations* |
127 | 54 | Alex Konig | ** *Web application - WebGL* |
128 | 69 | Alex Konig | *** *Works for multiple browsers (chrome and mozilla, on win and linux)* |
129 | 1 | Roman Kalivoda | ** Mobile application - Android |
130 | 53 | Alex Konig | *** Handling mobile specific events |
131 | *** Networking issues |
||
132 | *** Problems caused by file system incompatibility |
||
133 | *** Date picker |
||
134 | 1 | Roman Kalivoda | *** Different input system |
135 | *** Different layout |
||
136 | 53 | Alex Konig | **** New UI script connection |
137 | 1 | Roman Kalivoda | |
138 | 68 | Alex Konig | * *Able to download weather prediction* |
139 | |||
140 | 1 | Roman Kalivoda | * *Communication with server* |
141 | ** *Recieve rush level prediction* |
||
142 | *** *For one specific time* |
||
143 | *** *For time interval* |
||
144 | |||
145 | 68 | Alex Konig | * *Hosting on a webpage* |
146 | |||
147 | The app will be written in C# and Unity framework. |
||
148 | |||
149 | |||
150 | 33 | Alex Konig | h2. Project Plan |
151 | 1 | Roman Kalivoda | |
152 | See Redmine tab Roadmap. |
||
153 | |||
154 | |||
155 | h2. Stakeholders |
||
156 | 24 | Alex Konig | |
157 | * Development Team |
||
158 | 1 | Roman Kalivoda | * Project Sponsor |
159 | * Project Mentor |
||
160 | * Users: lecturers teaching classes at ZČU |
||
161 | * Users: students attending classes at ZČU |
||
162 | |||
163 | h2. Risks |
||
164 | |||
165 | h3. Available data is too crude |
||
166 | |||
167 | 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. |
||
168 | |||
169 | h3. Our effort estimation may be grossly underestimated |
||
170 | |||
171 | We should define/negotiate a minimum viable product and prioritize individual features. |
||
172 | |||
173 | h3. We proposed an unsuitable technological stack |
||
174 | |||
175 | 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. |
||
176 | |||
177 | h2. Solution |
||
178 | |||
179 | 70 | Alex Konig | MVP - see bold parts of *Key product features* |
180 | |||
181 | h3. Technical details |
||
182 | |||
183 | h4. Server application |
||
184 | |||
185 | * *Works with csv format of open data (as specified in [[Data sources]])* |
||
186 | * *Works with json format of weather prediction (as specified in [[Data sources]])* |
||
187 | * Communication - *Implementing protocol* (as specified in [[]]) |
||
188 | ** *Sends xml files (recieve, send, parse)* |
||
189 | * *Testing* |
||
190 | ** *Bugfixes* |
||
191 | |||
192 | h4. Front end application |
||
193 | |||
194 | ** Implements protocol - UnityWeb requests |
||
195 | * Pages hosting |
||
196 | ** *Github* |
||
197 | ** Gitlab |
||
198 | * *Testing* |
||
199 | ** *End user testing* |
||
200 | ** *Bugfixes according to tests* |
||
201 | |||
202 | 30 | Alex Konig | |
203 | 1 | Roman Kalivoda | h2. Details |
204 | |||
205 | For more details about implementation and processed data consult [[Project details]] |