HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2016T2 ProgneSIS FinalWiki"

From IS480
Jump to navigation Jump to search
Line 434: Line 434:
 
||Handover
 
||Handover
 
|| Manuals
 
|| Manuals
|| [https://wiki.smu.edu.sg/is480/img_auth.php/1/15/Team_ProgneSIS_Deployment_Guide.pdf| Deployment Guide],[https://wiki.smu.edu.sg/is480/img_auth.php/9/95/Team_ProgneSIS_User_Manual.pdf| User Manual],
+
|| [[File:Team ProgneSIS Deployment Guide.pdf| Deployment Guide]],
[https://wiki.smu.edu.sg/is480/img_auth.php/c/c4/Team_ProgneSIS_API.pdf| API],
+
[[File:Team ProgneSIS User Manual.pdf| User Manual],
[https://wiki.smu.edu.sg/is480/img_auth.php/e/e5/Team_ProgneSIS_Handover_Form.pdf| Handover Form],
+
[[File:Team ProgneSIS API.pdf | API]],
 +
[[File:Team ProgneSIS Handover Form.pdf| Handover Form]]
 
|}
 
|}
 
<br>
 
<br>

Revision as of 15:19, 10 April 2016

Progensis.png
Team Prognesis Icon Home.png

HOME

  Team Prognesis Icon AboutUs.png

ABOUT US

  Team Prognesis Icon Overview.png

PROJECT OVERVIEW

  Team Prognesis Icon ProjectManagement.png

PROJECT MANAGEMENT

  Team Prognesis Icon Documentation.png

DOCUMENTATION

 
Main Wiki Mid Term Wiki Final Wiki


Project Progress Summary

Finals slides

Deployed Link: http://versafleet-analytics.herokuapp.com/

Project Highlights

Our project schedule is divided into 13 iterations

  • 4 user testing, 2 with actual users & 2 with potential users
  • Current iteration: 12
  • Iteration 12: 03 April 2016 - 16 April 2016
  • 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
  • List of requirement changes
    • Different metrics was replaced with different dimensions and granularity levels for Delivery Fulfilment Rate
  • Working very closely with our client to help us better design our calculations algorithm
  • To even out the workload, members who contributed lesser (in terms of hours) made up during later iterations
  • User Testing 3 was delayed so that improvements can be made prior to UT3 and UT4
    • Improvements: 1) Screen scraping, 2) Inclusion of mean for Delivery Fulfilment Rate, 3) Change in calculation method for graph to better represent data


Project Challenges

  • User testing with actual users are particularly difficult to schedule, thus, we looked for other logistics SMEs to hold certain user testings with.
  • Scheduling user testings that are within our timeline.


Project Achievements

  • Developing the web application in JavaScript although most members do not have prior knowledge
  • Successfully implement react.js as a front-end framework
  • Collaborating with actual companies for user requirements gathering and user testings

Project Management

Project Status

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
Daily Report Dropped 0 Claudia, Minh, Yi Xuan & Jason


Project Schedule (Planned vs Actual)

Planned
Team ProgneSIS Scope V3.png
Actual
Team ProgneSIS Scope V5 Finals.png


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

Full documentation of our scope changes can be found in our Change Management here!

Project Schedule

Planned

Team ProgneSIS Planned Timeline.png

Actual

Team ProgneSIS Actual Finals Timeline.png

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!

Team ProgneSIS Schedule Metrics Score Graph.png

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

View our Bug Metrics here!

Bug Score

Team ProgneSIS Bug Metrics Score Graph.png

Bug Distribution based on Severity

Team ProgneSIS Bugs by Category Graph.png

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.


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.

  1. 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

Team ProgneSIS Architecture Diagram.png


Technologies that we have used

Team ProgneSIS Technologies.png


Single Page Application(SPA)

  • The whole application loads only once, and never has to reload.
  • All the data fetching is done through AJAX and the application state is kept on the client
  • Benefit: Better user experience, fast application.

JSON Web Tokens

  • A modern standard to authenticate users.
  • On login a JWT is created for the user, which he then uses to authenticate his subsequent requests for data.

Benefit:

  • Each request is stateless so it does not rely on the running server.
  • Ease of processing on the client-side and backend.

Flux (Redux)

  • A new approach for client-side applications to manage their data flow.
  • Unlike MVC it uses uni-directional data flow on the client-side.

Benefit:

  • One change by user propagates the change to the whole application. This helps to keep the state to be most updated and also improves developer experience.
  • Also, it is less error-prone.

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:

  • Ability to use the latest standard that is compliant with the browser.
  • Provides freedom of how we want to create our files and allow its usage on the browser.
  • Automates tedious tasks such as automatic reloading, running on different browsers simultaneously, and more.


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],

[10], [11], [12]

Handover Manuals File:Team ProgneSIS Deployment Guide.pdf,

[[File:Team ProgneSIS User Manual.pdf| User Manual], File:Team ProgneSIS API.pdf, File:Team ProgneSIS Handover Form.pdf



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:
  1. Find out if user interface is intuitive
  2. Find out if the metrics are what they look at
  3. Find out which metric(s) they look at more frequently
  4. 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:
  1. Find out if user interface is intuitive
  2. 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:
  1. Find out if user interface is intuitive
  2. 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:
  1. Reaffirm the user-friendliness of our application
  2. Reaffirm the usefulness our of application to logistics users
  3. 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:
  1. Reaffirm the user-friendliness of our application
  2. Reaffirm the usefulness our of application to logistics users
  3. Reaffirm the applicability of our application to logistics users

View our detailed User Testing 4 here!


Reflection

Team Reflection
Team ProgneSIS Karen.jpg "Always plan ahead and be prepared for changes. Interpersonal skills are vital in getting the help you need."
Team ProgneSIS Minh.jpg "Designing a comprehensive architecture requires a great deal of thoughts. It is a great learning experience to design a front-end application and back-end application, and for them to work together flawlessly brings out the beauty of IT systems and design. I will strive to design most maintainable and optimal front-end using latest standard."
Team ProgneSIS Claudia.jpg "Beyond the vast amount of new knowledge I have gained on the technicalities of coding the front-end, I have also learnt the importance of understanding your users. Companies have different requirements and varying purposes when utilising our application. It was thus crucial to be able to find a middle ground that is comprehensible by at least the vast majority."
Team ProgneSIS Eva.jpg "Due to the nature of our web application, gathering users has been a huge challenge. Hence, it is necessary to have a contingency plan when users are unavailable."
Team ProgneSIS Yixuan.jpg "The tasks as a backend developer isn't as straightforward as simply coding function, it is important to understand the even the company's standard, mission and how their business function as a whole."
Team ProgneSIS Jason.jpg "Understanding the architecture system as a whole and how different components work together is crucial to the development process as a backend developer."