Difference between revisions of "IS480 Team wiki:2017T1 Ravenous Mid Term Wiki"
(4 intermediate revisions by the same user not shown) | |||
Line 34: | Line 34: | ||
== Project Progress Summary == | == Project Progress Summary == | ||
− | [[Image: Ravenous - Midterm Project About.png|720px|center]] | + | [[Image: Ravenous - Midterm Project About.png|720px|center]]<br> |
− | + | As of 9th October 2017, we have completed 85% of iteration 7 and we have 2 more iterations to go.<br><br> | |
To view midterm slides, click [[Media:Ravenous - MidTermSlides.pdf| here]] | To view midterm slides, click [[Media:Ravenous - MidTermSlides.pdf| here]] | ||
<br> | <br> | ||
Line 361: | Line 361: | ||
| Advanced NLP | | Advanced NLP | ||
| Yes | | Yes | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 368: | Line 368: | ||
| View room host details on workplace and have the ability to contact host | | View room host details on workplace and have the ability to contact host | ||
| No | | No | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 375: | Line 375: | ||
| Re-prompt user with other room to book in case of clash in booking | | Re-prompt user with other room to book in case of clash in booking | ||
| Yes | | Yes | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 382: | Line 382: | ||
| Expose EvBot Event report | | Expose EvBot Event report | ||
| Yes | | Yes | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 389: | Line 389: | ||
| Dashy displays event statistics for event organisers | | Dashy displays event statistics for event organisers | ||
| Yes | | Yes | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 403: | Line 403: | ||
| Expose EvBot usage metrics | | Expose EvBot usage metrics | ||
| Yes | | Yes | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 417: | Line 417: | ||
| View EvBot usage metrics for workplace managers | | View EvBot usage metrics for workplace managers | ||
| Yes | | Yes | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 424: | Line 424: | ||
| Display attendee that didn't turn up | | Display attendee that didn't turn up | ||
| No | | No | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 431: | Line 431: | ||
| Organisers message broadcast | | Organisers message broadcast | ||
| No | | No | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 438: | Line 438: | ||
| Organisers trigger prompt for participants to check in | | Organisers trigger prompt for participants to check in | ||
| Yes | | Yes | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 445: | Line 445: | ||
| Display attendees yet to complete survey | | Display attendees yet to complete survey | ||
| Yes | | Yes | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 452: | Line 452: | ||
| Optimize web pages | | Optimize web pages | ||
| Yes | | Yes | ||
− | | | + | | Fully deployed and 100% Tested; On production server |
| 1.0 | | 1.0 | ||
| style="color: #008000;" | Completed | | style="color: #008000;" | Completed | ||
Line 716: | Line 716: | ||
|| [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_Project_Schedule Schedule & Functionalities] | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_Project_Schedule Schedule & Functionalities] | ||
|- | |- | ||
− | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A2017T1_Ravenous_Metrics | + | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A2017T1_Ravenous_Metrics Metrics] |
|- | |- | ||
|| [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_Risk_Management Risk Management] | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_Risk_Management Risk Management] | ||
Line 733: | Line 733: | ||
|- | |- | ||
− | |rowspan=" | + | |rowspan="4"| Testing |
|| [https://www.dropbox.com/s/ca2rqe23w4px2lv/Bug%20Log.xlsx?dl=0 Bug Log] | || [https://www.dropbox.com/s/ca2rqe23w4px2lv/Bug%20Log.xlsx?dl=0 Bug Log] | ||
|- | |- | ||
|| [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_Internal_Testing Internal Testing & Test Cases] | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_Internal_Testing Internal Testing & Test Cases] | ||
+ | |- | ||
+ | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_User_Testing_1 UT1] | ||
+ | |- | ||
+ | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_User_Testing_2 UT2] | ||
|- | |- | ||
|} | |} | ||
Line 772: | Line 776: | ||
The results of UT1 can be found [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_User_Testing_1 here]<br> | The results of UT1 can be found [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_User_Testing_1 here]<br> | ||
− | The results of UT2 can be found [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_User_Testing_2 here] | + | The results of UT2 can be found [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T1_Ravenous_User_Testing_2 here]<br><br> |
+ | |||
+ | Details of internal testing can be found in the deliverable table above. | ||
== Reflection == | == Reflection == | ||
Line 781: | Line 787: | ||
=== Individual Reflection === | === Individual Reflection === | ||
− | [[File: Ravenous - Midterm learning 1.png| | + | [[File: Ravenous - Midterm learning 1.png|720px|center]] |
− | [[File: Ravenous - Midterm learning 2.png| | + | [[File: Ravenous - Midterm learning 2.png|720px|center]] |
− | [[File: Ravenous - Midterm learning 3.png| | + | [[File: Ravenous - Midterm learning 3.png|720px|center]] |
<!--/Content--> | <!--/Content--> |
Latest revision as of 01:25, 9 October 2017
Project Progress Summary
As of 9th October 2017, we have completed 85% of iteration 7 and we have 2 more iterations to go.
To view midterm slides, click here
To access EvBot & FaBot, login to Workplace@Facebook instance by clicking here
To access Dashy, click here
For more information on how to access our applications, please view Quality of Product > Deployment Section
Project Highlights & Snapshots
Project Management
Project Status
The three diagrams below show the progress of our project, a high level overview of completion of project modules and a high level overview of change in scope to our project modules respectively.
Scope: Core
Module | Task | New Feature? | Status | Confidence level | Comments |
Event ChatBot (Organiser) | Register an event | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organiser) | Remove event | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organiser) | Close event | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organiser) | Add & Remove questions | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organiser) | Send Survey Questions | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organiser) | Send Survey Reminder to participants | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organiser) | View Survey Questions | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organiser) | View Event Snapshot | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organiser) | About EvBot | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Participants) | Check-in Event Attendance | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Participants) | View Surveys | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Participants) | About EvBot | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Facility Booking ChatBot & FMS Module I | Search available facilities | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Facility Booking ChatBot & FMS Module I | Book available facilities | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Facility Booking ChatBot & FMS Module I | View booked facilities | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Facility Booking ChatBot & FMS Module I | Cancel booked facilities | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module I | View claim rate vs active rate for all agencies and specific agency chart | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module I | View aggregated engagement scores of groups within an agency | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module I | View breakdown of engagement scores of groups within an agency | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module I | View Pc vs Mobile Graph | No | Delivered | 1.0 | Completed |
Analytics Dashboard Module II | View group privacy setting across specific group charts | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module II | View group activity charts | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module II | View interaction analysis of specific agency | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module III | View number of active users charts | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module III | View content on workplace chart | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module III | View word cloud chart | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Module III | View post-time & comment-time chart | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Authentication & Security Module | Register account on Dashy OTP Bot | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Authentication & Security Module | OTP Bot | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Authentication & Security Module | Login/Logout on Dashy | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Authentication & Security Module | Forget password | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Authentication & Security Module | Secure all API Calls with JWT Token | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Scope: Secondary
Module | Task | New Feature? | Status | Confidence level | Comments |
Analytics Dashboard Module IV | Export dashboard to CSV File | Yes | To be completed in iteration 8 | 1.0 | To be completed in iteration 8 |
Analytics Dashboard Module IV | List of activated and deactivated accounts of each agency in past 7 days | No | In Progress | 1.0 | In Progress |
Analytics Dashboard Module IV | Filtering options based on user activity/profile | No | In Progress | 1.0 | In Progress |
Analytics Dashboard Module IV | Dashy additional metrics: Overview | Yes | In Progress | 1.0 | In Progress |
Analytics Dashboard Module IV | Dashy additional metrics: Group | Yes | To be completed in iteration 8 | 1.0 | To be completed in iteration 8 |
FMS Module II | Release a booking that has begun | Yes | In Progress | 1.0 | In Progress |
FMS Module II | Extend a booking that has begun | Yes | In Progress | 1.0 | In Progress |
FMS Module II | Modify make, delete, view and search facilities to replicate GovTech's System | Yes | In Progress | 1.0 | In Progress |
Facility Booking ChatBot Module II | Advanced NLP | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Facility Booking ChatBot Module II | View room host details on workplace and have the ability to contact host | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Facility Booking ChatBot Module II | Re-prompt user with other room to book in case of clash in booking | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard and Bots Integration Module | Expose EvBot Event report | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard and Bots Integration Module | Dashy displays event statistics for event organisers | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard and Bots Integration Module | Expose FaBot usage metrics | Yes | In Progress | 1.0 | In Progress |
Analytics Dashboard and Bots Integration Module | Expose EvBot usage metrics | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard and Bots Integration Module | View FaBot usage metrics for workplace managers | Yes | In Progress | 1.0 | In Progress |
Analytics Dashboard and Bots Integration Module | View EvBot usage metrics for workplace managers | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organisers) II | Display attendee that didn't turn up | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organisers) II | Organisers message broadcast | No | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organisers) II | Organisers trigger prompt for participants to check in | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Event ChatBot (Organisers) II | Display attendees yet to complete survey | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Analytics Dashboard Mobile Responsiveness | Optimize web pages | Yes | Fully deployed and 100% Tested; On production server | 1.0 | Completed |
Scope: Good to have
Module | Task | New Feature? | Status | Confidence level | Comments |
Database Optimization Module | Optimize syncing of new data from Workplace@FB with Crunchy's database | Yes | To be completed in iteration 8 | 1.0 | To be completed in iteration 8 |
Database Optimization Module | Separate Database into transactional and analytical for all applications | Yes | To be completed in iteration 8 | 1.0 | To be completed in iteration 8 |
Event ChatBot (Organisers) III | Word cloud on survey results | Yes | To be completed in iteration 8 | 1.0 | To be completed in iteration 8 |
Event ChatBot (Organisers) III | Export Event Report as CSV | Yes | To be completed in iteration 8 | 1.0 | To be completed in iteration 8 |
Project Schedule
This section shows a low level overview of our tasks in each iteration before acceptance and current point (mid term)
Planned
Actual
Project Metrics
The chart shows the number of completed tasks against number of assigned tasks for all our iterations so far. The bigger the circle, the higher the percentage of task metrics
From Iteration 0 to 5, we keep track of task assignment date, expected due date and actual completion date. From there, we carry out task completion date analysis, individual task assignment analysis and group task assignment analysis. However, from iteration 6 onward, we made an improvement to our project management and keep track of expected time spent per task as well as actual time spent per task.
The charts below show Total Bug Score per iteration, Total Number of Bugs per iteration and Average Bug Score per Bug per iteration respectively.
Project Risks
From the period of Acceptance (18/8/2016) to Mid-Term presentation, we would like to highlight these two risks as area of concerns.
S/N | Risk Type | Risk Description | Likelihood | Impact Level | Risk Grade | Strategy Adopted | Action |
8 | Technical Risk | Our project is heavily dependent on Facebook API that we have no control over. | High | High | A | Mitigation | Our team is part of the Multi-Company Group with PSD, MOE and Facebook. We are in touch with Rohan who we can approach if we have any problem with the Workplace instance |
10 | Project Management Risk | GovTech is keen to share their API with us for us to explore the potential of our applications on government platform. However, the API from GovTech is only available in late Oct/early Nov | High | High | A | Mitigation | We are intending to replicate some of the functions that GovTech applications have. This can not only prepare us for possible integration but also tap on their knowledge to create functions that users want. |
From the period of Acceptance (18/8/2016) to Mid-Term presentation, we have a total of 29 change requests. Out of the 29 change requests, 13 changes proposed by the team based on results from UT2 and majority of them are UX/UI changes. We would like to list 3 interesting/impactful change requests.
S/N | Application, Requested by | Change description | Impact on Schedule | Technical Complexity | Business Value/Reason for Request | Score | Action Taken | Status of Request |
11 | Dashy, Sponsor | Mobile Responsiveness | 2 | 2 | High, Allow people to use it on the go | 4, High | Accept change request and team discuss the most appropriate iteration to implement the change request | Closed |
25 | FaBot, Team Ravenous | Input format for date/time too rigid. Require advanced NLP. | 2 | 2 | High, This will improve user experience by giving users more options to type | 4, High | Accept change request and team discuss the most appropriate iteration to implement the change request | Closed |
36 | EvBot, Team Ravenous | EvBot will automatically prompt user to link event the moment it detected user has created an event | 2 | 2 | High, It will guide the users in using EvBot to link events | 4, High | Accept change request and team discuss the most appropriate iteration to implement the change request | Closed |
Technical Complexity
Asynchronous Nature of NodeJS
SetTimeout
To stop the asynchronous calls initially, setTimeout was used. This was used via trial and error basis to see how long a previous request call would take, and run the next block of codes after the elapsed time.
This is easy to implement however, this comes with many disadvantages. For one, this is a highly unreliable method. Although a request call to Graph/Messenger API would usually take less than second, there could be instances where FB’s server slow down and exceed a second. This would cause our app to crash since there would still be many variables not instantiated yet. This method is essentially hardcoding.
Secondly, it causes the code to be very hard to read for other developers. With each setTimeout, the next block of codes has to be indented in. With the nature of our code, we will be affected by asynchronous calls many times, causing our codes to be unnecessarily heavily indented to the right.
Callbacks
Callback was a better method than hardcoding timeouts. This guarantees a request call is completed before proceeding to the next block of codes for most cases. Callbacks can solve most problems but not all. For example, getting multiple values from request calls first, before proceeding and making multiple request calls in order.
Another drawback to using callbacks, is that the indentation problem is not solved. With every callback function, the next block of code is indented, making it difficult for other developers to read.
Recursion
To make multiple calls in order, Promises was also explored but it did not work. This could also be due to the lack of understanding the Promise concept at that period. Since timeouts, callbacks and promises weren’t working, we explored the use of Recursion to send messages in guaranteed order to users.
Promises
Promises required some reading up and researching before actual implementation as this is a new asynchronous concept with little examples online as compared to callbacks and setTimeout. Promises solves all of our problems. It guarantees the request is done before moving on, it can make multiple request calls and storing the values synchronously and lastly, do all these while maintaining clean code.
This is a really clean way of sending multiple messages and performing other calls within the function. Imagine using callbacks or timeouts, after each sendMessage and delay function, all subsequent codes has to be indented. For the example, the code would have had to be indented more than 10 times!
We used Promise.all to collect all contents of the resolved body from the promise methods. In the above example, a request is made to Graph API to retrieve the Event Image URL for a list of Events. Thereafter, we use a Promise.all to retrieve all the URLs obtained previously. This is done synchronously.
Async/Await – Node Version >= 7.6.0
Async/await has recently been shipped with official support in Node 7.6 (released in early 2017). It is built on top of promises and needs to be used in conjunction with them. While Promises keeps code cleaner in comparison to using callbacks, async/await is even more concise.
In this example, we used the await keyword before calling asynchronous functions (that must return promises). If this were written with standard promises, there would need to be a chain of then blocks and return statements. Async/await makes code look synchronous and improves readability significantly.
ChatBot Sessions
Messenger platform, the platform the team is developing the bots on, does not support sessions out of the box.
E.g.
Bot: Can I take your order?
User: I want a Hamburger.
Bot: What? Why?
Sessions in our chatbots is crucial as our use case requires many user inputs. Even so, user input alone is not enough. Our chatbots will have to take in multiple user inputs in order, and perform validation on those user inputs. When the inputs are invalid, the bot needs to recognize and re-prompt the user for a valid input.
To overcome this problem, we implemented our own ‘sessions framework’. Firstly, we made use of a database to store a user’s session.
We also implemented a set of codes in a session.js file to manipulate and access the session variables. The way the code works, is that it’ll query the database with every user call to the bot to check for any existing session (e.g. bot is in the middle of prompting Booking Date). If an existing session exists, it needs to listen to the relevant call. E.g. If bot is prompting for a booking date, a bot must expect a booking date, and not a booking time.
The advantage of a self-implemented session framework, is that we can control validations tightly. When an invalid input is entered, the bot will recognize it, and immediately prompt for a valid input.
However, there are disadvantages to it as well. Firstly, with every user message to the bot, a query to the DB is made to check for any existing session. Even when a user is ‘chatting’ with the bot saying ‘Hello!’, a DB query is made. This will slow the DB down significantly when multiple users are using the bot at the same time, or when a user spams the bot with messages. This caused numerous bugs when the bot did not reply on the first input. When the user enters his input the second time, the bot responds.
Secondly, to have instant validation, users must input in their date and time in a specific format. Any deviations from the format will render it an invalid input. The rigidity was not liked by most users.
To overcome the UX and performance issue, we made use of an external API (apiai) on top of our codes. We used apiai to parse a user’s message into intents and entities. For example, 11/12/2017, 11-12-17 and even 11 Dec 2017 are all recognized as date formats. This is the same for time periods.
However, this is lacking in terms of validation. If a user enters a date that is before today e.g. 11/01/2001, APIAI will accept as it is still a ‘valid’ date to them. For the bot’s use case, this date is invalid as there is no way a user can book a facility before today. Similarly, if a user types a booking time of 3pm to 1pm, it should be invalid.
To overcome this, we added our set of validation codes.
Another challenge we faced while using apiai is to allow the user to only fill up the invalid fields e.g. User only needs to fill up booking date instead of booking date + booking time + booking room again in an event of an initial invalid input.
This was difficult as apiai does not allow us to reset the session context on the fly as this is tightly controlled by them. For example, as soon as a booking date is invalid, we tried to send a POST request to apiai to reset the context, causing it to re-prompt user for a booking date. But apiai rejected the call, and will continue asking for the remaining prompts.
A workaround we found, is to manually store all invalid input a user has. With these errors, we’ll make a new call to the API, leaving out those errors. Once these fields are left out, APIAI will only prompt those fields.
Finally, since session is not supported, it was difficult to pass variables around in our code. We were used to storing variables in a session, and retrieving the variables from the session in another file. Since this was not supported, we coded out a custom function such that we were able to pass variables around using the messenger platform’s Postback/payload system, following the URL query parameters format.
Quality of Product
Intermediate Deliverables
Topic of Interest | Link |
---|---|
Project Management | Schedule & Functionalities |
Metrics | |
Risk Management | |
Change Management | |
Minutes | |
Project Documentation | Technical Diagrams |
Prototype | |
Persona & Scenario | |
Testing | Bug Log |
Internal Testing & Test Cases | |
UT1 | |
UT2 |
Deployment
The deployment links are as follow:
We have 2 versions of Dashy for different purposes. Staging refers to application in the development phase and production refers to applications are that production ready. Only these two applications have a user interface.
These are the backend servers that support our applications on Workplace@FB. They do not have a user interface.
- Crunchy (Data crunching for Dashy)
- EvBot (Event ChatBot, Available on our workplace@FB instance)
- EvBot (Facility ChatBot, Available on our workplace@FB instance)
- OttoBot (OTP ChatBot, Available on our workplace@FB instance)
- FMS (Facility Management System)
Our Workplace@FB instance can be found here: https://psd-test.facebook.com/
- Please note that by logging into our Workplace@FB instance, you will have access to EvBot and FaBot.
- You will need to use the production link above to access Dashy.
You may login to our Workplace@FB instance using the credentials below. You may also login to Dashy using the same credentials
Email login id: wiki_user@test.sis.smu.edu.sg
Password: wiki_user123
Testing
Team Ravenous has conducted a total of 2 User Testings.
The first user testing placed emphasize on whether users know how to use our applications, whether they understand the flow of tasks and observe how they interact with our ChatBots.
The second user test is about the usability improvement that we have made since user testing 1.
The results of UT1 can be found here
The results of UT2 can be found here
Details of internal testing can be found in the deliverable table above.
Reflection
Team Reflection
This project was an exciting and enriching journey for Team Ravenous. Collectively, we not only gain new knowledge and skills about our roles, we also get to expand our professional network. Through this project, we get to meet and interact with PSD Technical Team, GovTech Team as well as business & IT professionals from 6 different government agencies. Through the interactions, we know why are certain processes carried out this way, why they are doing this and so on.