Difference between revisions of "IS480 Team wiki:2017T1 Ducky King Finals"
Line 184: | Line 184: | ||
::5. '''Encryption & Privacy''' | ::5. '''Encryption & Privacy''' | ||
[[File:Ducky King Encryption.PNG|800px|center]] | [[File:Ducky King Encryption.PNG|800px|center]] | ||
+ | <br> | ||
+ | <br> | ||
+ | ::6. '''Flow Admin''' | ||
+ | [[File:Ducky King System health.PNG|800px|center]] | ||
+ | <br> | ||
+ | <br> | ||
+ | [[File:Ducky King Logging.PNG|800px|center]] | ||
+ | <br> | ||
+ | <br> | ||
+ | [[File:Ducky King Peer managment.PNG|800px|center]] | ||
+ | <br> | ||
+ | <br> | ||
+ | ::7. '''Logging''' | ||
+ | [[File:Ducky King Kibana.PNG|800px|center]] | ||
<br> | <br> | ||
<br> | <br> |
Revision as of 03:23, 21 November 2017
Project Progress Summary
Project Highlights
X-Factor
Overall Project Scope
Project Management
Project Schedule
*Changes to our schedule have been denoted in red
Project Metrics
The development of all functionalities has been completed. Thus, we have completed the sprint points for the final Sprint 14. However, what is left is the official handover and documentation on our solution.
Release Burndown Chart
The release burndown shows the state of work burn, during the entire period. However due to the continuous request feature request, additional sprint points are continuously added to the product backlog and the sprints.
Thus, if the features are defined much earlier and clearly, the burndown chart would look like this.
Sprint Velocity Chart
Scrum Sprint Backlogs Chart
As mentioned in the earlier section, all functions has been completed. The reason why Sprint 14 still exist is because of the uncertainty of the milestone dates (Finals) and also to cater time for documentation and handover.
Bus Factor
A project’s bus factor (or truck factor) is a number equal to the number of team members who, if run over by a bus, would put the project in jeopardy. The smallest bus factor is 1. Larger numbers are preferable. In order to increase our project’s bus factor, our team has tried our best to maintain collective code ownership and ensure frequent communication among team members. Our final bus factor is 4.
Production Ready Metrics
Bug Metrics
The Bug Found shows how many bugs there are in each sprint, the Bug Score shows the overall bug score for each sprint and the Total Test Cases shows the number of test cases that are created for testing. The testing is separated to 2 kinds of testing, automated and manual testing. The automated testing is done through testing libraries such as Mocha, Chai and Truffle. The team aims to resolve the bugs before the sprint ends and carry as few bug as possible to the next sprint. If there are unresolved bugs, the team will assess the bug's severity and resolve the bugs that are more severe first. The team will also follow the mitigation plan in place when fixing the bugs. If the bug score is 10 and below, the bugs can be fixed during the buffer time. If the score is more than 10 and less than 20, the team will use the planned debugging time in the sprint to resolve the bugs. If the bug score is higher than 20, the scrum master will allocate additional manpower to resolve the bugs immediately. The scrum master reschedules the project if necessary.
Automated Testing
Our team firmly believes that automated testing is essential in development and especially so for new technologies such as ours. As such, we used 2 automated testing, 1 for the solidity contracts and another for the middleware. For the middleware, we use Mocha and Chai, a Javascript unit testing library. For the solidity contracts, we used the Truffle unit testing library. The automated test cases allows us to easily find out where the errors are in development. Below is an example of how Mocha and Chai testing is done on the middleware.
Project Risks
Technical Complexity
- 1. Deployment Architecture
- The following shows FlowLabs deployment architecture. We set up multiple servers to simulate how different Flow Nodes interact with each other.
- 2. Job Queue Mechanism
- 3. Smart Contracts
- 4. Solidity
- 5. Encryption & Privacy
- 6. Flow Admin
- 7. Logging
- 6. Internal Testing
- Our team has come up with the following testing lifecycle for our internal testing process. More details can be found on out internal testing wiki page here
Project Deliverables
Component | Description | Specification |
---|---|---|
Project Management | Project Schedule | Project Schedule |
Meeting Minutes | Meeting Minutes | |
Metrics | Metrics | |
Risk Management | Risk Management | |
Change Management | Change Management | |
Requirements | Project Overview | Project Overview |
Project Scope | Project Scope | |
Analysis | Personas and Scenarios | Personas & Scenarios |
Diagrams | Diagrams | |
Project Implementation | Technology | Technology |
Testing (Documents and Results) | Internal Testing | Internal Testing |
FlowLabs Middleware User Testing | FlowLabs Middleware | |
FlowAdmin User Testing | FlowAdmin | |
UAT 1 (Middleware & FlowAdmin) | UAT 1 | |
UAT 2 (Middleware & FlowAdmin) | UAT 2 | |
UAT 3 (Middleware & FlowAdmin) | UAT 3 | |
Handover Documentation | FlowLabs Handover Documentation | Documentation |
Reflections
Sponsor's Feedback
Team Reflections