Product Vision Statement » Historie » Verze 32
Alex Konig, 2021-05-02 16:37
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 | 32 | Alex Konig | - Date (or system date) - dd:mm:yyyy |
16 | - Weather (predictions from official weather server prediction with possibility to manually input custom values) - temperature, wind, rain, |
||
17 | - Building or classroom number (will be interpreted as building the classroom is in) |
||
18 | - Time - hh |
||
19 | - optional end date (weather prediction will be used for times in between) |
||
20 | 1 | Roman Kalivoda | |
21 | 6 | Alex Konig | h3. Output |
22 | 8 | Alex Konig | |
23 | 1 | Roman Kalivoda | - Rush level (very calm, calm, average, busy, very busy) |
24 | 32 | Alex Konig | - Visualization as a "heatmap" showing rush across the campus |
25 | - If user put end date an animation of changes in rush level |
||
26 | 25 | Alex Konig | |
27 | 1 | Roman Kalivoda | h3. Happy Day use-case |
28 | 25 | Alex Konig | |
29 | 32 | Alex Konig | The user will specify a date and classroom (e.g. UC-336) 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). |
30 | 25 | Alex Konig | |
31 | 14 | Zuzana Káčereková | h3. Key factors to judge application quality |
32 | 1 | Roman Kalivoda | |
33 | 14 | Zuzana Káčereková | * Application response time |
34 | 32 | Alex Konig | * UI design appeals to the customer |
35 | 14 | Zuzana Káčereková | * Maintainability (as a measure of effort required to update the model with new data) |
36 | 10 | Alex Konig | |
37 | 1 | Roman Kalivoda | 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 UWB. |
38 | |||
39 | 25 | Alex Konig | h3. Key product features |
40 | 17 | Zuzana Káčereková | |
41 | 25 | Alex Konig | Server - administrative part |
42 | 17 | Zuzana Káčereková | * Capable of being updated at admin request |
43 | * Capable of extending the model/updating it with new data/changing the model entirely (software designed to support smooth model transition) |
||
44 | 1 | Roman Kalivoda | |
45 | 25 | Alex Konig | Client - end user part |
46 | 17 | Zuzana Káčereková | * Able to access prediction using the earlier specified input parameters |
47 | * Able to specify input parameters |
||
48 | 25 | Alex Konig | * Heat map type visualisation |
49 | 17 | Zuzana Káčereková | * Able to easily browse prediction across a greater range of time |
50 | 25 | Alex Konig | * Has a web interface and/or mobile interface |
51 | 5 | Roman Kalivoda | |
52 | h3. System parts & technologies |
||
53 | |||
54 | h4. Server (backend) part |
||
55 | |||
56 | 16 | Zuzana Káčereková | There will be a server application which: |
57 | 5 | Roman Kalivoda | * will retrain prediction model when new data is available (or when a new model is defined by an administrator/maintainer), |
58 | * will run predictions based on client app requests and send the response once it is ready. |
||
59 | |||
60 | We decided that the backend will be developed in C# and .NET platform. |
||
61 | |||
62 | h4. Web frontend app |
||
63 | |||
64 | There will be a WebGL application: |
||
65 | * user will be able to specify arbitrary weather conditions (e.g. temperature, precipitation) or use an automatic weather forecast, |
||
66 | * user will be able to specify an arbitrary classroom at UWB, |
||
67 | * these input data will be made into a web request and sent to the server, |
||
68 | * The prediction result will be shown to the user when the response is received. |
||
69 | |||
70 | 18 | Zuzana Káčereková | The app will be written in C# and Unity framework. |
71 | 1 | Roman Kalivoda | |
72 | 3 | Eliška Mourycová | h4. Android app |
73 | |||
74 | There will be an android app with functionality similar to the web frontend. The app will also be developed with C# and Unity. |
||
75 | |||
76 | 1 | Roman Kalivoda | |
77 | h2. Project Plan |
||
78 | |||
79 | |||
80 | h2. Stakeholders |
||
81 | |||
82 | * Development Team |
||
83 | * Project Sponsor |
||
84 | 24 | Alex Konig | * Project Mentor |
85 | * Users: lecturers teaching classes at ZČU |
||
86 | 1 | Roman Kalivoda | * Users: students attending classes at ZČU |
87 | |||
88 | h2. Risks |
||
89 | 22 | Zuzana Káčereková | |
90 | 4 | Roman Kalivoda | h3. Available data is too crude |
91 | 23 | Zuzana Káčereková | |
92 | 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. |
93 | 21 | Zuzana Káčereková | |
94 | 4 | Roman Kalivoda | h3. Our effort estimation may be grossly underestimated |
95 | |||
96 | We should define/negotiate a minimum viable product and prioritize individual features. |
||
97 | |||
98 | h3. We proposed an unsuitable technological stack |
||
99 | 21 | Zuzana Káčereková | |
100 | 1 | Roman Kalivoda | 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. |
101 | 26 | Alex Konig | |
102 | h2. Solution |
||
103 | |||
104 | 27 | Alex Konig | [[Minimum viable product]] |
105 | 29 | Alex Konig | |
106 | h2. Details |
||
107 | |||
108 | 30 | Alex Konig | For more details about implementation and processed data consult [[Project details]] |