IS480 Team wiki: 2016T2 Remix midterm wiki
Home | Midterm | Final |
---|
Contents
Project Progress Summary
Mid-term Presentation
Project Proposal
Progress based on Function:
Completion:
- Overall progress: 90% (36/49)
- Completion of CORE functions: 93.1% (27/29)
- Completion of SECONDARY functions: 100% (9/9)
- Completion of GOOD-TO-HAVE functions: 0% (0/2)
Change in Scope:
- During the December, our sponsor raised the requirement for 5 additional functions.
- After re-design the analytics module:
- "Resource Utilization Report" is replaced by "View Dashboard" and "View Historical Statistics report"
- "View urgency score" solved the problem of "Issue priority index" and "Dead-in-water Aler"
- Due to the effort re-arrangement and technique difficulty, "Search chat message" is delayed
Progress based on Schedule:
- We are currently at Iteration 11
- Significant Events
- One last development iteration Ending on 14 Feb 2016
- User Acceptance Test: 2 Feb to 4 Feb 2016
Project Highlights:
What unexpected events occurred?
- Extremely high bug metrics happened in Iteration 4
- List of requirement changes - As shown above in "Process based on Functions --> Change in Scope"
Project Management
Project Status:
Highlight changes to modules, the completion status (implemented, user testing done, client approved, deployed, etc), the confidence level (0-1 where 0 is no confident of getting it done, 1 is 100% confident in getting it done) and comments (who has been assigned to do it, new scope, removed scoped, etc). Please use a table format to summarize with links to function details.
Functions achieved
Iteration | Module | Function | Status | Confidence | Comments |
---|---|---|---|---|---|
1 | |||||
Project Module | Create project and initiate timeline | Fully deployed and tested 100% | 1 | Chengzhen | |
View project timeline | Fully deployed and tested 100% | 1 | Chengzhen | ||
View/Update project details | Fully deployed and tested 100% | 1 | Chengzhen | ||
Create/view/update milestones | Fully deployed and tested 100% | 1 | Chengzhen | ||
Create/view/update project updates | Fully deployed and tested 100% | 1 | Chengzhen | ||
2 | |||||
Accounts Module | Login / logout | Fully deployed and tested 100% | 1 | Tiantong | |
Create client account | Fully deployed and tested 100% | 1 | Tiantong | ||
Create PM/Developer account | Fully deployed and tested 100% | 1 | Tiantong | ||
Change password | Fully deployed and tested 100% | 1 | Tiantong | ||
Update personal details | Fully deployed and tested 100% | 1 | Tiantong | ||
3 | Chat Module | Send chat messages | Fully deployed and tested 100% | 1 | Anyu |
Issue Module | Send chat messages | Fully deployed and tested 100% | 1 | Lu Ning | |
4 | Chat Module | Receive chat messages | Fully deployed and tested 100% | 1 | Anyu |
Issue Module | Search issues | Fully deployed and tested 100% | 1 | Lu Ning | |
Filter issues | Fully deployed and tested 100% | 1 | Lu Ning | ||
Accounts issues | Rest password | Fully deployed and tested 100% | 1 | Chengzhen | |
7 | Accounts Module | Search account | Fully deployed and tested 100% | 1 | Tiantong |
Use Case Module | Create/update use cases | Fully deployed and tested 100% | 1 | Chengzhen, New Requirement | |
Search use case | Fully deployed and tested 100% | 1 | Chengzhen, New Requirement | ||
Delete use cases | Fully deployed and tested 100% | 1 | Chengzhen, New Requirement | ||
Issue Module | View/create issue comments | Fully deployed and tested 100% | 1 | Lu Ning | |
8 | |||||
File Module | Attach file in chat | Fully deployed and tested 100% | 1 | Anyu | |
Search file | Fully deployed and tested 100% | 1 | Foong Wai | ||
Rename file in repository | Fully deployed and tested 100% | 1 | Foong Wai | ||
Upload/download files | Fully deployed and tested 100% | 1 | Foong Wai | ||
View file repository | Fully deployed and tested 100% | 1 | Foong Wai | ||
PM Task Module | Create tasks | Fully deployed and tested 100% | 1 | Tiantong | |
View tasks for individual project | Fully deployed and tested 100% | 1 | Tiantong | ||
9 | Analytics Module | View Dashboard | Testing pending 80% | 1 | Yuxuan, modified function |
View Historical Statistics Report | Testing pending and time filter pending 70% | 1 | Yuxuan, modified function | ||
Notification Module | Receive notifications on new updates | Fully deployed and tested 100% | 1 | Tiantong | |
View notification item | Fully deployed and tested 100% | 1 | Tiantong | ||
10 | PM Tasks Module | View all tasks on Eisenhower Matrix | Fully deployed and tested 100% | 1 | Chengzhen |
Analytics Module | View Urgency Score | Fully deployed and tested 100% | 1 | Yuxuan, new function |
Functions To Be Achieved
Iteration | Module | Function | Confidence | Comment |
---|---|---|---|---|
Iteration 11 | Chat Module | Search chat message | 0.5 | Anyu |
Offline Notification | 1 | Anyu | ||
Analytics Module | Overload Alert | 0.9 | Yuxuan | |
Iteration 12 | Smart analyst assistant Module | Recommend project deadline | 0.9 | Yuxuan |
Project Schedule (Plan Vs Actual):
Compare the project plan during acceptance 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.
Plan:
Actual:
Iteration | Comment |
---|---|
1 | Everything went as plan |
2 | Everything went as plan |
3 | Everything went as plan |
4 | "Search Chat Message" function delayed due to technique difficulty |
5 | Non-coding plan |
6 | Everything has changed, and the team was focus on debugging. |
7 | Everything has changed and the team is working on urgent new requirements raised by sponsor. |
8 | Extra work done to catch up the schedule |
9 | Extra work done to catch up the schedule |
10 | Extra work done |
Project Metrics:
Schedule Metrics:
Not applicable because Time Boxing is used.
Bug Metrics:
Project Risks:
Update the proposal assumptions and risks. Describe what you learn from the risk update and mitigation steps taken.
Description | Likelihood | Impact | Mitigation |
---|---|---|---|
The sponsors have only a vague idea of the application that they want built. This could lead to situations where there is mismatch between the built product and their expectations. | High | High | - Using agile development process to keep continuous testing and regular communication with sponsors. |
The team needs to utilize libraries that have only been released recently such as ReactJS. Support for the library and the information that can be found online regarding the library is little. Hence, learning the libraries will be even more challenging than usual. | Medium-High | High | - Regular communication and interaction with mentors/sponsors to slowly ramp up familiarity with the library.
- Self-study and experimentation with the library to better understand and utilize it |
Analytics requires strong understanding of business model and data structure while the team is not sure about the accessibility of such data, and fine-tuning the analytics models may take long time. | Medium | Medium | - Interviews and observation studies with sponsor to determine the data that they need for project management analysis
- Familiarize ourselves with the latest research on analytics for project management |
As our application is in the beta stage (deployed for use by real clients), we have to consider security risks that emerge from external users. | Low | High | - Explicitly setting the character encoding and sanitizing client-side form fields for malicious content |
Third-party service such as Bitbucket API maybe unstable | Low | High | - Constantly check the system, and moderate our system. |
Technical Complexity:
Message notification and updates
To handle complicated components that are:
- Ajax enabled
- have multiple states
- have multiple data sources
- responsible for computing data and rendering its own UI independently
- responsible for distributing data to other components that require it
The nodes on the graph above represent components from our messaging services. There is a total of 10 different data flows. Additionally, depending on the data received or computed, nodes can have multiple states.
(e.g. File upload component with file attached or no files attached)
This was a big problem as it caused our UI to be unresponsibe and our code to be unmaintainable.
Bitbucket Oauth 2.0 authentication
We integrated Bitbucket into application. For this, we have to help developers and project managers log in to Bitbucket from our application.
This is difficult as we not only have to manage an extra level of authentication but also also synchronize both sessions (TSPMS and Bitbucket). Synchronization of the sessions was crucial for the user interface to be rendered correctly.
We felt that an additional complexity of managing and storing the API keys was that the keys have short lifespans; they expire after 30 minutes to an hour.
Scheduled events
We collect data from multiple sources for our custom Remix Analytics module. This process is tedious as we need to be precise for the calculation of accurate metrics. Additionally, the process is computationally intensive as well.
Quality of product
Intermediate Deliverables:
There should be some evidence of work in progress.
Stage | Specification | Modules |
---|---|---|
Project Management | Minutes | Minutes Documents |
Metrics | Bug Metrics | |
Analysis | Use case | Use Cases |
Business Process Diagram | Here | |
Design | ER Diagram | Here |
Class Diagram | Here | |
Testing | Testing plan | Here |
User testing | UT1 | |
UAT | Here | |
Handover | Manuals | Instruction on connecting to Bitbucket |
Deployment:
- Internal Users: http://52.76.235.20/
- Username: ttwang
- Password: password
- External Users: http://52.76.235.20/customer_authentication
Testing:
User Testing:
Each week, we will hold a meeting with our sponsors where we run through our application to garner feedback from the end-users of the application on both the usability and functionality of the currently developed application. This allows us to continuously align our application with the business needs of our sponsors.
On top of this, we have held 3 user testing sessions and 1 user acceptance test session thus far.
The main purpose of user testing sessions was to obtain pointers on how to improve the look and feel of our application. Further, the sessions allow us to test our newly developed functions over the past few interations. To that end, we recruited SMU SIS students to take on the role of project managers and cast a critical look over our application.
User Test 1
Date: 23 October 2015
User Test 2
Date: 18 December 2015
User Test 3
Date: 8 January 2015
UAT:
We also conducted a user acceptance test to test our application in its totality. The focus of our UAT was to determine whether our application is able to satisfy the needs of our users - both the project managers as well as the clients. As such, the UAT has a larger scope as compared to our user testing sessions. In our UAT, we've recruited SMU SIS students to assume the role of project managers while we recruited the real clients of The Shipyard to gain feedback on the client-side application.
User Acceptance Test
Date: 3 February 2015, 5 February 2015
Reflection
Team Reflection:
Benjamin Gan Reflection:
- Waiting for the feedback from prof.*