HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2017T2 Mavericks Finals Wiki"

From IS480
Jump to navigation Jump to search
Line 482: Line 482:
  
 
===Testing:===
 
===Testing:===
 +
 +
* Internal Testing is performed for every new function developed
 +
* Team Mavericks has scheduled for 5 User Testings in total
 +
** We have accomplished 3 User Testings as of Iteration 11
 +
 +
For more information regarding User Testing and view results, please click [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2017T2_Mavericks_User_Testing here].
  
 
Describe the testing done on your system. For example, the number of user testing, tester profile, test cases, survey results, issue tracker, bug reports, etc.
 
Describe the testing done on your system. For example, the number of user testing, tester profile, test cases, survey results, issue tracker, bug reports, etc.

Revision as of 10:50, 3 April 2018

MV-background.png


MV-home.png   HOME

 

MV-logo.png   ABOUT US

 

MV-overview.png   PROJECT OVERVIEW

 

MV-schedule.png   PROJECT MANAGEMENT

 

MV-documentation.png   DOCUMENTATION

Main Wiki

Midterms Wiki

Finals Wiki


Project Progress Summary

Place your Final slides link and deployed site link here

For proposal, please see Requrements at the Project Deliverables. This will help us understand your scope. Note wiki policy here.

This page should NOT be too long. It should link to other pages in the IS480 team wiki. Do not repeat the proposal, midterm or other wiki information here. Highlight changes since midterm.

Describe the project progress briefly here. Is the project completed? Link to the final presentation slides and videos.

Project Highlights:

What unexpected events occurred and how were they handled?

  • A team member left the project and dropped the course
  • List of requirement changes
    • CRUD items replaced with CU/Sync/Archive items
    • Business analytics replaced with iPad client
  • Took 8 weeks to learn Ruby on Rails
  • etc.

Be brief. A couple of sentences on the event and another couple on what was done is sufficient. Do not repeat the next sub sections. If there are no highlights, remove this section

Project Challenges:

Describe areas of the project that were particularly difficult and how they were dealt with, whether successfully or not. Again, a few sentences are enough. If there are no challenges, remove this section.

Project Achievements:

Methods, technologies, processes, teamwork, etc. which were particularly successful – highlight things which worked very well towards completing the project. A bulleted list of one to two sentences each will do. If there are no achievement, remove this section.

Project Management

Iteration Progress: 14 of 15
Features Completion: 100% (32 out of 32 features)
Confidence Level: 100%

Project Status:

Mv-iter-update-1.png


MV-scope-4.png
Iteration Scope Module Task Planned/New Feature Status Confidence Level Comments
2 Core Account Module Login/Logout Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
2 Core Customer Request Module - View Account Balance
- View Account Details
- Funds Transfer
- Add Payee
- View Payee
Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
2 Core Chat Module View Chat History Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
2 Core Dialog Flow Module Manage Entities & Intents Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
3 Core Security Module OTP Management Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
3 Core Dialog Flow Module Process User Requests
- AI Events & Exception Handling
Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
3 Core Chat Module Speech-to-text Processing Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
3 Core Admin Module I - Live Chat Takeover
- Receive Notifications
Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
4 Core Admin Module I View All Chats Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
5 Core Admin Module I Receive Notifications Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
5 Core Customer Request Module View Transaction History Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
6 Core Customer Request Module - Request Loan
- Agg. Expense View
- Loan Calculator
- Bill Payment
Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
7 Core Educational Module Assessment Quiz (Backend Logic) Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
8 Core Educational Module Glossary of Terms Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
8 Core Customer Request Module - View Standing Instructions
- Create Standing Instructions
Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
9 Core Educational Module - Assessment Quiz (Creation)
- Architecture View
Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
9 Core Admin Module II Live Scoreboard Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
11 Core Educational Module Request-Reply Details of API Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
11 Core Admin Module II Descriptive Analysis Planned Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
12 Core Educational Module Assessment Quiz (New Changes) New Fully deployed and tested 100% 1 Reviewed and accepted by sponsor
12 Core Admin Module II Live Support Analysis New Fully deployed and tested 100% 1 Reviewed and accepted by sponsor

Project Schedule (Plan Vs Actual):

Compare the project plan during midterm with the actual work done at this point. Briefly describe a summary here. Everything went as plan, everything has changed and the team is working on a new project with new sponsors or the supervisor is missing. A good source for this section comes from the project weekly report.

Provide a comparison of the plan and actual schedule. Has the project scope expanded or reduced? You can use the table below or your own gantt charts.

Planned Schedule

Mv-timeline-4.001.jpeg

Actual Schedule

Project Timeline.005.jpeg

Project Metrics:

MV-TaskMetrics.PNGMv-bugs.png
For more information on metrics collected, please refer here.

Technical Complexity:

1) Speech-to-text Speed Optimisation

(Left to Right, Version 1 to 3)
Mv-speech-1.png Mv-speech-2.png Mv-speech-3.png

  • Version 1
    • Duration Range: 8 to 26s
    • Task performed serially
    • User must be done with recording before voice uploaded
  • Version 2
    • Duration Range: 4 to 10s
    • Voice recording and voice data transmission done concurrently between client & server
    • Enabled by Websocket protocol implementation
    • Supports full duplex transmission
  • Version 3 (Work-in-Progress)
    • Duration Range: 100ms to 6s
    • Voice recording and voice data transmission done concurrently client, server & Google
    • Enabled by Websocket implementation
    • Supports full duplex transmission
    • Integrating Google-client gRPC lib to receive Websocket stream

2) Maintaining User-DialogFlow Conversation

  • Http requests are stateless
  • Maintain the state
    • Storing sessions in application variable
    • Pass user id as metadata when forwarding requests to DialogFlow

3) New technologies

  • Web Audio Recording
    • Cross browser compatibility and limitations
    • MediaRecorder API does not work on iOS
    • Instead, use Web Audio API, and we have to
      • Manually encode PCM audio samples.
    • AudioContext.createScriptProcessor buffer size inconsistent across browsers
      • Smaller buffer is faster
      • Larger buffer has better sound quality
      • After experimentation
        • 8192 is the most optimal for our use case
  • Google Speech
    • gRPC protocol
      • Learn and understand how to perform gRPC requests
    • Unclear Library dependencies
      • Too many JAR files to keep track
      • Repository in Alpha stage, SNAPSHOT fixes not published as releases
    • Invalid Server Authentication
      • Example shown does not integrate with tBuddy
  • DialogFlow
    • Unclear documentation
      • Follow up intents
      • Request lifespan and context
      • Resulting in repeated response.
    • Experimentations required
      • Query different request and determine if response is the expected response
      • Try multiple intents and ensure that follow up intents sticks to the correct intent

4) Deployment Configuration

  • Sponsor requirement to maintain dual deployment
    • Staging
    • Production
  • Limitations on Dialogflow’s Webhook Config
    • Webhook requests can only be forwarded to one address
    • Need to have maintain separate projects for each deployment
    • Each project a unique API key
  • Conventional Deployment Config
    • Read configurations from .properties
  • Dialogflow’s Java-client library compiled apikey variable as final constant
  • Not able to simply read from .properties file and override value
  • Non-trivial to insert overriding API keys
    • Lack of documentation
    • Usage of web.xml for parameter initialisation

Challenge comes where team has to continuously experiment and perform trial & error
Actual key name to override is apiaiKey

Quality of product

Provide more details about the quality of your work. For example, you designed a flexible configurable system using XML.config files, uses Strategy Design Pattern to allow plugging in different strategy, implement a regular expression parser to map a flexible formula editor, etc.

Project Deliverables:

Stage Specification Modules
Project Management Minutes
Schedule
Metrics Bug Metrics, Task Metrics
Risk Mitigation
Requirements Overview
Scope
Scenarios
Analysis System Architecture Diagram
Technologies Used
Design ER Diagram
Prototype Video of tBuddy Prototype
Testing User Testing 1 UT1 - 6 Nov 2017
User Testing 2 UT2 - 26 Jan 2018
User Testing 3 UT3 - 13 Feb 2018
User Testing 4
Handover Manuals User tutorial, Developer manual, Setup manual
Code client server
Deployment Diagram instructions

Quality:

Explain the quality attributes (non functional) of your project deliverables. Have you designed the architecture, use a design pattern, etc? Does your architecture address scalability, performance, reliability, availability, fault tolerance, usability, etc. Does your design address maintainability, flexibility, configurability, etc. Be brief here but you can link to diagrams or code detail pages. Do not repeat the technical complexity part, link to it if necessary.

Deployment:

In an iterative approach, ready to use system should be available (deployed) for client and instructions to access the system described here (user name). If necessary, provide a deployment diagram link.

Testing:

  • Internal Testing is performed for every new function developed
  • Team Mavericks has scheduled for 5 User Testings in total
    • We have accomplished 3 User Testings as of Iteration 11

For more information regarding User Testing and view results, please click here.

Describe the testing done on your system. For example, the number of user testing, tester profile, test cases, survey results, issue tracker, bug reports, etc.

Reflection

Team Reflection:

Key lessons learned – indicating where the team improved, or would do things differently next time. You may refer to the learning outcome summary in your proposal. A very short checklist style will suffice. It would be very convincing if the knowledge is share at the wiki knowledge base and linked here.

Individual Reflection:

Describe in a paragraph, the key areas of learning or improvement. These should be personal areas of growth or learning. Each individual should list his/her effort, responsibility, actual contributions and personal reflection. Do not repeat team project contributions or member roles. Link if necessary.

Jamie's Reflection
I have learnt the importance of my role in team and stakeholder management, as well as maintaining overall responsibility of the project. As much as communication is essential within a team, it is also important for me to recognise every member's strengths and weaknesses, so that everyone can achieve their fullest potential to accomplish a common goal.


Yi Xiang's Reflection

We should be open to change in order for us to improve. Even if we have a good idea, which we believe to be the best, we should be open to feedback and make necessary changes. The ones who decide whether if the idea is good or not are the target users. Thus, it is important to have proof of deploment and user testing to get users' feedback for improvements.


Gerald's Reflection
As the Tech Architect, there is always something new to learn, best practices that we ought to adopt. It’s important that I’m up to speed with the right implementation to ensure that the application performs according to expectation. I’ve learnt that other than implementing a feature, we ought to implement it well so that it is usable for the users.


Bertran's Reflection
What I have learnt is that in a software project, non-functional requirements are extremely important. In fact, it might even be more difficult to fulfil a non-functional requirement, and these are often overlooked or underestimated in project plans.


Yi An's Reflection
As the Quality Assurance Lead, I learnt that having attention to details is crucial in making a excellent product. Additionally, adapting to changes is the key to creating a holistic product.

Sometimes, the client writes a report to feedback on the system; this sponsor report can be included or linked from here.