Difference between revisions of "IS480 Team wiki: 2016T2 ProgneSIS FinalWiki"
(16 intermediate revisions by the same user not shown) | |||
Line 47: | Line 47: | ||
<h3>Project Highlights</h3> | <h3>Project Highlights</h3> | ||
− | Our project schedule is divided into | + | Our project schedule is divided into 12 iterations |
* 4 user testing, 2 with actual users & 2 with potential users | * 4 user testing, 2 with actual users & 2 with potential users | ||
* Current iteration: 12 | * Current iteration: 12 | ||
− | * Iteration 12: 03 April 2016 - | + | * Iteration 12: 03 April 2016 - 11 April 2016 |
*Major changes in requirements resulted in re-scoping in iteration 3-4 and hence major changes in schedule | *Major changes in requirements resulted in re-scoping in iteration 3-4 and hence major changes in schedule | ||
*User Testing 1 was delayed by a month as a result of re-scoping | *User Testing 1 was delayed by a month as a result of re-scoping | ||
Line 176: | Line 176: | ||
|Claudia | |Claudia | ||
|- | |- | ||
− | | | + | |Setting of threshold by customers |
|Dropped | |Dropped | ||
|0 | |0 | ||
Line 203: | Line 203: | ||
* On the trip level (lowest level), users can choose to view total/on time/late deliveries by days/weeks/months. | * On the trip level (lowest level), users can choose to view total/on time/late deliveries by days/weeks/months. | ||
* Dynamic date picker allows user to view data from specific dates | * Dynamic date picker allows user to view data from specific dates | ||
+ | * On 02 March 2016, upon confirming that our app is only a Proof of Concept, Notification Module becomes a good to have module as it was more important to conduct extensive user testings to strengthen this Proof of Concept | ||
+ | * So by 08 March 2016 if Notification Module is not completed, we would drop it and focus on user testings | ||
Full documentation of our scope changes can be found in our Change Management [[IS480_Team_wiki:_2016T2_ProgneSIS_Change_Management#Change_Log|here]]! | Full documentation of our scope changes can be found in our Change Management [[IS480_Team_wiki:_2016T2_ProgneSIS_Change_Management#Change_Log|here]]! | ||
<br> | <br> | ||
Line 242: | Line 244: | ||
|Completed | |Completed | ||
|- | |- | ||
+ | |9 | ||
+ | |14 | ||
+ | |15 | ||
+ | |93.3333% | ||
+ | |Estimates are generally accurate and on track. Proceed as per normal. | ||
+ | Slight delay due to the need to complete the implementation of changes/improvements before subsequent user testings can be scheduled. | ||
+ | |||
+ | Follow up action: Iteration 9 was delayed by a day with the immediate subsequent iteration shortened by a day. No buffer day is used. | ||
+ | |Completed | ||
+ | |- | ||
+ | |10 | ||
+ | |14 | ||
+ | |13 | ||
+ | |107.6923% | ||
+ | |Estimates are generally accurate and on track. Proceed as per normal. | ||
+ | Delay in previous iteration resulted the need to shorten this iteration by a day so that no buffer day is used. | ||
+ | Follow up action: User testings were scheduled earlier for Iteration 10 so that team is on schedule. | ||
+ | |Completed | ||
+ | |- | ||
|} | |} | ||
− | |||
− | |||
<br> | <br> | ||
Line 272: | Line 291: | ||
|<b>10</b> <br> 2 High <br> | |<b>10</b> <br> 2 High <br> | ||
|All of the bugs in this iteration are backend related and are only detected when the developers test and check the algorithms. | |All of the bugs in this iteration are backend related and are only detected when the developers test and check the algorithms. | ||
+ | |The team has to stop all current development and resolve the bug immediately. No rescheduling needed as debugging was relatively straightforward. | ||
+ | |- | ||
+ | |10 | ||
+ | |<b>10</b> <br> 1 Critical <br> | ||
+ | |Screen scrape wasn't working due to "nightmare.js" consuming too much memory. | ||
|The team has to stop all current development and resolve the bug immediately. No rescheduling needed as debugging was relatively straightforward. | |The team has to stop all current development and resolve the bug immediately. No rescheduling needed as debugging was relatively straightforward. | ||
|- | |- | ||
Line 328: | Line 352: | ||
<h3>Technologies that we have used</h3> | <h3>Technologies that we have used</h3> | ||
[[File:Team_ProgneSIS_Technologies.png|700px|centre]] | [[File:Team_ProgneSIS_Technologies.png|700px|centre]] | ||
+ | <br> | ||
+ | |||
+ | <b>Custom Build Process</b> | ||
+ | [[Image:Team_ProgneSIS_Webpack.png|700px|centre]] | ||
+ | *We create our custom build process by using Webpack tool. It creates a bundle that is attached to the HTML that runs the application, in its bundling it binds all the files together, transpiles code from ES6 to ES5, optimizes the modules import and export, and compiles all the SCSS files. | ||
+ | *We also automate tedious development tasks by using Gulp such as running server, running bundler and preprocessing files. | ||
+ | <b>Benefit:</b> | ||
+ | *Webpack allows us to code easily in ES6 which is richer in features | ||
+ | *Coding in CSS is made easier and faster | ||
+ | *javascript files are compressed thereby enabling faster load | ||
+ | *Modules make code more maintainable | ||
+ | <br> | ||
+ | |||
+ | <b>Parallelism and Asynchronous Programming via Promises</b> | ||
+ | [[Image: Team_ProgneSIS_Asynchronous.png|700px|centre]] | ||
+ | *Makes full use of server’s CPU | ||
+ | **Returns results faster than synchronous functions | ||
+ | **Performance scales together with cloud infrastructure | ||
+ | *Non-blocking code | ||
+ | *Avoids callback hell | ||
<br> | <br> | ||
<b>Single Page Application(SPA)</b> | <b>Single Page Application(SPA)</b> | ||
− | * | + | *React allows us to create SPA more efficiently |
− | * | + | *Redux manages the data/state(i.e. components of page) of application |
+ | *Allows asynchronous data fetching without reloading the whole page i.e when date is changed, new set of data is fetched from the backend, only the graph and table will have to be loaded, not the whole page | ||
*Benefit: Better user experience, fast application. <br><br> | *Benefit: Better user experience, fast application. <br><br> | ||
− | <b> | + | <b>d3.js for Data Visualisation</b> |
− | + | [[Image:Team_ProgneSIS_d3.png|700px|centre]] | |
− | * | + | *Full range of flexibility that allows us to customise the granularity needed for our application <br><br> |
− | <b> | + | |
− | * | + | <b>Gulp.js</b> |
− | * | + | *Optimises development environment |
+ | *Automatically rebuild application on change and save aka Hot Reloading | ||
+ | *Allows syncing of browsers to test application on different browsers at the same time <br><br> | ||
− | <b> | + | <b>Node.js Server with Express Framework - Backend</b> |
− | |||
− | |||
<b>Benefit:</b> | <b>Benefit:</b> | ||
− | * | + | *Backend services are exposed as RESTful APIs |
− | * | + | *Secured with an authentication middleware |
+ | *Uses JSON Web Token for authentication <br><br> | ||
− | <b> | + | <b>MongoDB</b> |
− | * | + | *Data is stored as JSON based documents |
− | + | *Makes access convenient when used with javascript | |
− | + | *Each Document belongs to one user and thus allows ad-hoc addition or removal of attributes for users<br><br> | |
− | * | ||
− | * | ||
− | |||
− | <br> | ||
==<div style="background: #7f7f7f; padding: 15px; font-weight: bold; line-height: 0.3em; text-indent: 15px;letter-spacing:-0.08em;font-size:20px"><font color=#FFFFF>Quality of Product</font></div>== | ==<div style="background: #7f7f7f; padding: 15px; font-weight: bold; line-height: 0.3em; text-indent: 15px;letter-spacing:-0.08em;font-size:20px"><font color=#FFFFF>Quality of Product</font></div>== | ||
Line 369: | Line 411: | ||
|rowspan="2"| Project Management | |rowspan="2"| Project Management | ||
|| Minutes | || Minutes | ||
− | || Sponsor weeks -19, -14, -13, -10, -5, -4, 1 Supervisor weeks -11, -9, 4, 5, 7 | + | || Sponsor weeks -19, -14, -13, -10, -5, -4, 1, 10 Supervisor weeks -11, -9, 4, 5, 7, 9, 10, 12, 13, 14 |
|- | |- | ||
Line 409: | Line 451: | ||
|| Testing | || Testing | ||
|| User testing design | || User testing design | ||
− | || [https://wiki.smu.edu.sg/is480/ | + | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_ProgneSIS_User_Testing_1], |
− | [https://wiki.smu.edu.sg/is480/ | + | [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_ProgneSIS_User_Testing_2], |
− | [https://wiki.smu.edu.sg/is480/ | + | [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_ProgneSIS_User_Testing_3], |
− | [https://wiki.smu.edu.sg/is480/ | + | [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_ProgneSIS_User_Testing_4] |
|- | |- | ||
||Handover | ||Handover | ||
|| Manuals | || Manuals | ||
− | || [ | + | || [[Media:Team ProgneSIS Deployment Guide.pdf| Deployment Guide]], |
− | [ | + | [[Media:Team ProgneSIS User Manual.pdf| User Manual]], |
+ | [[Media:Team ProgneSIS API.pdf | API]], | ||
+ | [[Media:Team ProgneSIS Handover Form.pdf| Handover Form]] | ||
|} | |} | ||
<br> | <br> | ||
Line 424: | Line 468: | ||
<h3>Quality</h3> | <h3>Quality</h3> | ||
+ | <h4>Architecture</h4> | ||
+ | Our application consists of two separate applications (backend and frontend) with two separate architectures, but both applications work together. | ||
+ | |||
+ | For our frontend, we have adapted a Flux design pattern, which means that the data that goes through the application flows unidirectionally - one direction. A change in the view, will rerender the whole application with the most updated state. | ||
+ | |||
+ | For the backend, we have adopted an immortal MVC design pattern without the ‘View’, since our frontend application makes up that portion. The Model and Controllers have helped us in developing the REST API endpoints, for consumption by our frontend application. | ||
+ | |||
+ | <h4>Maintainability</h4> | ||
+ | For all of our application we have adopted the Module Pattern which means that our application is built with numerous modules that comprises other modules. We adopted functional programming for our backend by chaining and composing different functions to output a desired request. | ||
+ | |||
+ | <h4>Availability and reliability</h4> | ||
+ | Our backend layer is built with Node.js which supports clustering of processes. This means that we spin up multiple instances of our application, and if one of our server dies, there will be a fallback to another forked process. This ensures that our application will always be available, even when a fault happens on our server. | ||
+ | |||
+ | <h4>Performance</h4> | ||
+ | We work on a single threaded environment which is crucial in avoiding the blocking of codes. With that in mind, we have wrapped all business logic handling function using Promises, which make them asynchronous. This not only ensures that users’ function calls will not be blocked by another, it also allows the application’s performance to scale together with the cloud infrastructure. | ||
+ | |||
+ | <h4>Configurability</h4> | ||
+ | Our system relies on MongoDB, and we have adopted cloud service MongoLab. It is very easy to configure it to connect a different instance of MongoDB by just specifying a different connection. We also have built in checkers, for different deployment purposes. | ||
<h3>Deployment</h3> | <h3>Deployment</h3> |
Latest revision as of 15:20, 11 April 2016
Main Wiki | Mid Term Wiki | Final Wiki |
Contents
|
Task/Function/Features | Status | Confident Level (0-1) | Comment |
---|---|---|---|
Login/Logout/Registration | Fully deployed and tested 100% | 1 | Minh & Yi Xuan |
Accounts Settings (User Module) | Fully deployed and tested 100% | 1 | Claudia, Minh & Yi Xuan |
Customer Settings (User Module) | Fully deployed and tested 100% | 1 | Claudia, Minh & Yi Xuan |
Integrate with VersaFleet (Improvement: Screen Scape) | Fully deployed and tested 100% | 1 | Minh, Yi Xuan & Jason |
Overall Delivery Fulfilment Rate(DFR) | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
DFR by drivers | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
DFR for customers | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
DFR by pickup region | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
DFR by delivery region | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
DFR by volume | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
DFR by drivers | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
Customer view DFR | Fully deployed and tested 100% | 1 | Minh, Yi Xuan & Jason |
Trips by each driver (Improvement: Accurate calculation method) | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
Trips for each customer (Improvement: Accurate calculation method) | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
Trips for each pickup region (Improvement: Accurate calculation method) | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
Trips by each delivery region (Improvement: Accurate calculation method) | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
Trips by each volume (range) (Improvement: Accurate calculation method) | Fully deployed and tested 100% | 1 | Claudia, Minh, Yi Xuan & Jason |
Feedback and enquiry | Fully deployed and tested 100% | 1 | Yi Xuan |
Help Page | Fully deployed and tested 100% | 1 | Claudia |
Setting of threshold by customers | Dropped | 0 | Claudia, Minh, Yi Xuan & Jason |
Project Schedule (Planned vs Actual)
Planned |
---|
Actual |
---|
Highlights of Changes Made to Scope
- Rather than having many metrics on a single, our client felt that it would be more meaningful to have a single metric on different levels with different dimensions
- On the trip level (lowest level), users can choose to view total/on time/late deliveries by days/weeks/months.
- Dynamic date picker allows user to view data from specific dates
- On 02 March 2016, upon confirming that our app is only a Proof of Concept, Notification Module becomes a good to have module as it was more important to conduct extensive user testings to strengthen this Proof of Concept
- So by 08 March 2016 if Notification Module is not completed, we would drop it and focus on user testings
Full documentation of our scope changes can be found in our Change Management here!
Project Schedule
Planned
Actual
Highlights of Changes Made in Schedule
- User Testing 1 shifted from Iter 5 to Iter 7 due to major changes in scope thereby affecting User Testing 2, which shifted from Iter 6 to 8.
- User Testing 3 was shifted from Iter 8 to Iter 10 and Iter 11 as user testing was conducted with not actual users but logistics business owners who are potential users thus, taking more time to schedule a meetup.
- User Testing 4 was shifted from Iter 11 to Iter 12 as actual users are only available then.
Project Metrics
Schedule Metrics
View our Schedule Metrics Here!
Schedule Metrics Highlights
Iteration | Planned Duration (Days) | Actual Duration (Days) | Schedule Metric Score | Action | Status |
---|---|---|---|---|---|
1 | 21 | 22 | 95.2381% | Estimates are generally accurate and on track. Proceed as per normal.
Slight delay due to the need to integrate with 3rd party accounting software, Xero. Team had to spend more time than planned in integration and understanding what revenue and costs comprise. Follow up action: Iteration 2 was delayed by a day. However, the subsequent iterations are shortened with modules broken down into more manageable parts. No buffer day is used. |
Completed |
9 | 14 | 15 | 93.3333% | Estimates are generally accurate and on track. Proceed as per normal.
Slight delay due to the need to complete the implementation of changes/improvements before subsequent user testings can be scheduled. Follow up action: Iteration 9 was delayed by a day with the immediate subsequent iteration shortened by a day. No buffer day is used. |
Completed |
10 | 14 | 13 | 107.6923% | Estimates are generally accurate and on track. Proceed as per normal.
Delay in previous iteration resulted the need to shorten this iteration by a day so that no buffer day is used. Follow up action: User testings were scheduled earlier for Iteration 10 so that team is on schedule. |
Completed |
Bug Metrics
Bug Score
Bug Distribution based on Severity
Bug Metrics Highlights
Iteration | Bug Score | Summary of bugs | Action Taken |
---|---|---|---|
1 | 26 1 Critical 3 High 1 Low |
Most of the bugs in this iteration were due to incorrect logic to get accurate figures. | The team has to stop all current development and resolve the bug immediately. Project Manager reschedules project. |
8 | 10 2 High |
All of the bugs in this iteration are backend related and are only detected when the developers test and check the algorithms. | The team has to stop all current development and resolve the bug immediately. No rescheduling needed as debugging was relatively straightforward. |
10 | 10 1 Critical |
Screen scrape wasn't working due to "nightmare.js" consuming too much memory. | The team has to stop all current development and resolve the bug immediately. No rescheduling needed as debugging was relatively straightforward. |
Project Risks
View our risk management here!
Risk Type | Risk Description | Impact | Likelihood | Impact | Category | Mitigation Plan |
---|---|---|---|---|---|---|
Project Management Risk | Unable to get VersaFleet users to test our application due to their packed schedule. | Unable to get feedback from actual users and hence affect the usability of the system. | High | High | A | By 6 March 2016, if we're unable to get confirmation on user testing with actual users, PM will source for logistics companies that we can conduct user testings with. |
The above risk has been mitigated.
- PM sourced for logistics companies to conduct user testing with from her contacts and contacts found online.
Future Risks
View our risk management here!
Risk Type | Risk Description | Impact | Likelihood | Impact | Category | Mitigation Plan |
---|---|---|---|---|---|---|
Technology | Developers from sponsor's company would not understand the codes provided to them. | Time needs to be spent on understanding the codes for future expansion. Inefficient use of time. | High | Medium | A | Team to provide proper documentation for codes to be handed over. Since technologies used are in line with what sponsor's company is currently using, there will not be a problem in maintaining the application or debugging but rather understanding our team's coding style. |
The above risk have did not occur but our team anticipate and managed this risk.
Technical Complexity
Our Architecture Design
Technologies that we have used
Custom Build Process
- We create our custom build process by using Webpack tool. It creates a bundle that is attached to the HTML that runs the application, in its bundling it binds all the files together, transpiles code from ES6 to ES5, optimizes the modules import and export, and compiles all the SCSS files.
- We also automate tedious development tasks by using Gulp such as running server, running bundler and preprocessing files.
Benefit:
- Webpack allows us to code easily in ES6 which is richer in features
- Coding in CSS is made easier and faster
- javascript files are compressed thereby enabling faster load
- Modules make code more maintainable
Parallelism and Asynchronous Programming via Promises
- Makes full use of server’s CPU
- Returns results faster than synchronous functions
- Performance scales together with cloud infrastructure
- Non-blocking code
- Avoids callback hell
Single Page Application(SPA)
- React allows us to create SPA more efficiently
- Redux manages the data/state(i.e. components of page) of application
- Allows asynchronous data fetching without reloading the whole page i.e when date is changed, new set of data is fetched from the backend, only the graph and table will have to be loaded, not the whole page
- Benefit: Better user experience, fast application.
d3.js for Data Visualisation
- Full range of flexibility that allows us to customise the granularity needed for our application
Gulp.js
- Optimises development environment
- Automatically rebuild application on change and save aka Hot Reloading
- Allows syncing of browsers to test application on different browsers at the same time
Node.js Server with Express Framework - Backend Benefit:
- Backend services are exposed as RESTful APIs
- Secured with an authentication middleware
- Uses JSON Web Token for authentication
MongoDB
- Data is stored as JSON based documents
- Makes access convenient when used with javascript
- Each Document belongs to one user and thus allows ad-hoc addition or removal of attributes for users
Quality of Product
Project Deliverables
Stage | Specification | Modules |
Project Management | Minutes | Sponsor weeks -19, -14, -13, -10, -5, -4, 1, 10 Supervisor weeks -11, -9, 4, 5, 7, 9, 10, 12, 13, 14 |
Metrics | Schedule metrics, Task metrics & Bug metrics | |
Requirements | Storyboards and User Study | [1], [2] |
Analysis | Use case | [3] |
Sequence Diagram | [4] | |
Business Process Diagram | [5], [6] | |
Screen Shots | CRUD Customer, Trend Analysis | |
Design | Frontend Component Design | [7] |
Backend API Design | [8] | |
Testing | User testing design | [9], |
Handover | Manuals | Deployment Guide, |
Quality
Architecture
Our application consists of two separate applications (backend and frontend) with two separate architectures, but both applications work together.
For our frontend, we have adapted a Flux design pattern, which means that the data that goes through the application flows unidirectionally - one direction. A change in the view, will rerender the whole application with the most updated state.
For the backend, we have adopted an immortal MVC design pattern without the ‘View’, since our frontend application makes up that portion. The Model and Controllers have helped us in developing the REST API endpoints, for consumption by our frontend application.
Maintainability
For all of our application we have adopted the Module Pattern which means that our application is built with numerous modules that comprises other modules. We adopted functional programming for our backend by chaining and composing different functions to output a desired request.
Availability and reliability
Our backend layer is built with Node.js which supports clustering of processes. This means that we spin up multiple instances of our application, and if one of our server dies, there will be a fallback to another forked process. This ensures that our application will always be available, even when a fault happens on our server.
Performance
We work on a single threaded environment which is crucial in avoiding the blocking of codes. With that in mind, we have wrapped all business logic handling function using Promises, which make them asynchronous. This not only ensures that users’ function calls will not be blocked by another, it also allows the application’s performance to scale together with the cloud infrastructure.
Configurability
Our system relies on MongoDB, and we have adopted cloud service MongoLab. It is very easy to configure it to connect a different instance of MongoDB by just specifying a different connection. We also have built in checkers, for different deployment purposes.
Deployment
Deployed Link: http://versafleet-analytics.herokuapp.com/
Testing
We have conducted 3 user testing, 1 user study and 1 heuristic evaluation.
Heuristic Evaluation
- Venue: At participant's convenience
- Participants: 5 participants
- We conducted a Heuristic Evaluation using a paper prototype to learn about the usability of our current design of VersaFleet Analytics. We used a paper prototype as changes can be made easily before we develop the actual application. This HE will help us discover possible improvements in the design of our application to improve its usability.
View our detailed Heuristics Evaluation here!
User Study
- Date: 12 October 2015
- Venue: Respective offices of our potential users
- Participants: 1 logistics SME business owner and 1 logistics SME operations manager
- Objectives:
- Find out if user interface is intuitive
- Find out if the metrics are what they look at
- Find out which metric(s) they look at more frequently
- Identify usability problem(s) which users might face
View our detailed User Study here!
User Testing 1
- Date: 30-31 January 2016
- Venue: Respective offices of our potential users
- Participants: 5 VersaFleet users
- Objectives:
- Find out if user interface is intuitive
- Identify usability problem(s) which users might face
View our detailed User Testing 1 here!
User Testing 2
- Date: 10 February 2016
- Venue: Respective offices of logistics-field experts
- Participants: 3 logistics SME business owners
- Objectives:
- Find out if user interface is intuitive
- Identify usability problem(s) which users might face
View our detailed User Testing 2 here!
User Testing 3
- Date: 10, 17, 24, 31 March 2016
- Venue: Respective offices of logistics companies
- Participants: 5 logistics SME business owners
- Objectives:
- Reaffirm the user-friendliness of our application
- Reaffirm the usefulness our of application to logistics users
- Reaffirm the applicability of our application to logistics users
View our detailed User Testing 3 here!
User Testing 4
- Date: 7 April 2016
- Venue: JTC Launchpad - The Meeting Point
- Participants: X VersaFleet users
- Objectives:
- Reaffirm the user-friendliness of our application
- Reaffirm the usefulness our of application to logistics users
- Reaffirm the applicability of our application to logistics users
View our detailed User Testing 4 here!
Reflection