Difference between revisions of "IS480 Team wiki:2017T1 Ducky King Finals"
|Line 253:||Line 253:|
|| User Testing
|| [[IS480_Team_wiki:2017T1 Ducky King User Testing| User Testing]]
|| User Testing
|| [[IS480_Team_wiki:2017T1 Ducky King User Testing
| User Testing ]]
Revision as of 02:04, 21 November 2017
- 1 Project Progress Summary
- 2 Project Management
- 3 Quality of Product
- 4 Reflections
Project Progress Summary
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.
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.
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.
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.
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.
Quality of Product
- 1. Coding Standards
- As with all freelance project, developers often take the path of least resistance and develop applications that are not compliant with industry best practices. This usually takes place because the project manager does not take a hard stance right at the start of the project about the coding standards to use. Even after setting the coding standards, there is usually no one to ensure the adherence to the standards.
- This is to ensure consistent coding styles among the developers. Such as the number of spaces, the use of double quotes, single quotes and backticks. This will allow for greater maintainability of the codes and ensures the code base remain adaptable to changes.
- 2. Git Workflow
- Our team adopts the Git Workflow. The main reason behind it is because it provides a robust framework for managing project of this scale. This is because at any point in time, there may be multiple developers working on different features at the same time. Git Workflow allows multiple feature developments to carried out in parallel.
- This workflow is very similar to that of the Feature Branch Workflow. The main difference is that it assigns very specific roles to different branches and defines how and when they should interact with each other. It also uses individual branches for preparing, maintaining, and recording releases.
- 3. Usage of Adapter Pattern
- The middleware has to return responses in appropriate structure so that it is easier for the for the consuming application to extract the relevant information from the request. As described, the middleware has to communicate with other system as such the database and the ethereum node. The data used in the communication is of various format and it is the responsibility of the middleware to ensure that it conforms to the required format when communicating with other subsystems within the FlowNode. As this project is undergoing continuous development, one of the main design consideration is to ensure the design of codes is loosely coupled. One of the approach to resolve this challenge is to use Adapter pattern in designing software components.
- Adapter pattern is a software design pattern (Wrapper) that allows the interface of an existing class to be used as another interface. Through adapter pattern, we can encourage a high level of consistency of the response outputs. Furthermore, it helps to decouple the classes and allow us to reuse existing codes.
- 4. Object Relational Mapping (ORM)
- ORM is a programming technique that allows for the conversion of incompatible types in object-oriented programming languages, especially between a data store and programming objects.
- SQL codes and related wrapper classes requires a significant amount of effort to develop. Furthermore, a prior design of the database is required as well. When using ORM libraries/tools, it will reduce the need of the database design as the tool is able to create the relational model within the database based upon the declared models within the codebase. Additionally, the query is done at the model level. ORM libraries/tools provide functional calls to allow for Create-Read-Update-Delete (CRUD) operation and allows the queries to be done at the host object-oriented programming language level. This means that there is no need for any SQL code to be written.
- By leveraging upon ORM libraries/tools, the code base is reduced and it allows for greater degree of code reuse by leveraging upon existing ORM libraries/tools.
- 5. Logging
- Logging is the recording of implementation level events that happen as the program is running (methods get called, objects are created, etc.). From a maintenance perspective, the logs serves as an important record of events which occurred before the application encounters an error. It gives a greater degree of visibility of the workings of the application, thus, it allows errors/issues to be identified and isolated quickly.
- The logs is configured to captured all domain-related events. For example, a “Create Auction” transaction is logged and stored. In the event of potential misuse or incident, the logs forms an audit trail of the sequence of events. This will greatly assist any investigation efforts for any potential breach or malicious behavior by users.
- 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 Management||Project Schedule||Project Schedule|
|Meeting Minutes||Meeting Minutes|
|Risk Management||Risk Management|
|Change Management||Change Management|
|Requirements||Project Overview||Project Overview|
|Project Scope||Project Scope|
|Analysis||Personas and Scenarios||Personas & Scenarios|
|Testing (Documents and Results)||Internal Testing||Internal Testing|
|FlowLabs Middleware User Testing||FlowLabs Middleware|
|FlowAdmin User Testing||FlowAdmin|