HeaderSIS.jpg

IS480 Team wiki: 2016T1 Potato Midterm Wiki

From IS480
Jump to navigation Jump to search
Sirpotato.png


Project Progress Summary

Midterm slides: File:Midterm Presentation 04102016.pptx
Deployed site: deployment


Project Highlights:

  • Took 2 weeks to familiarize with Python and Django
  • Took 3 full days to familiarize with Ruby on Rails
  • Change in data structure, resulting in major modification of code
  • Change in platform used to develop MVP by client's external IT team from Django to Ruby on Rails
  • Additional criteria (surplus and liquidity calculation) added in for matching algorithm
  • After matching is performed, users will not be notified of the match until admin confirms the match. This functionality is requested by the sponsor.

Project Management

Project Status:

Modules Status Confidence Level Comment
Transfers Module 100% Implemented, Tested, Deployed on staging server 1 Added Transfer function as we have to integrate Ruby on Rails with Django
Payee Module 100% Implemented, Tested, Deployed on staging server 1 -
Liquidity Module 75% Implemented, Tested, Deployed on staging server 0.5 Predict safe operational amount is highly likely to be removed from the scope due to insufficient transfers data.
Requests Module 0% Not yet started 0.8 This module is to be done after mid-term presentation
Matching Module 100% Implemented, Tested, Deployed on staging server 1 Added calculate measurement functions to provide information for sponsor to make informed decisions
Admin Module 100% Implemented, Testing & debugging in progress 1 Added 6 new functions to support business process
Currency Extractor Module 0% Not yet started 0.9 This module is to be done after mid-term presentation

Project Schedule (Plan Vs Actual):

Scope

Potato-project-scope midterm.png

Schedule

Project timeline midterm.png

Project Metrics:

We collected 3 metrics: task, burndown, and bug metrics. Task metric is used to measure completeness of the iteration. Burndown is used to gauge the progress during the iteration. Bug metric is used to ensure the quality of the system.

Task Metric

IS480-potato-TM.jpg

The task metrics is used as an overview to measure the team’s efficiency in terms of completing tasks. This is used to indicate the overview of the team if we have overestimated or underestimated available time of the team and the complexity of the tasks in each iteration. This metric is measured at the end of each iteration.

Burndown

The burndown is a chart that shows work left to do against time in each iteration. It consists of planned tasks left to do and actual tasks left to do. PM uses burndown to gauge how quickly or slowly the team progresses through an iteration. Burndown is updated every day. This allows PM to readjust the schedule or re-allocation of manpower accordingly.

IS480-potato-burndown-iteration3.jpg

This burndown shows the PM that the team is on-track and need not make any adjustments to schedule or manpower. Since the actual-tasks-left line chart goes below the planned-tasks-left line chart, PM might want to consider adding new task in. For this iteration, the team decided not to make any changes.

Is480-potato-iteration5-midterm.png

The first portion of the burndown shows that the team's development progress is faster than expected. At the same time, there were changes (development of bruteforce matching algorithm, used to compare with heuristic matching algorithm) proposed to the team. Since the team is early, the PM decided to accept and add new changes into the iteration as results from bruteforce would allow the team to measure effectiveness of and improve the matching algorithm that we were developing. After adding tasks related to the bruteforce matching algorithm, coupled with preparation for acceptance presentation, the team's progress slowed more than expected. Thus the PM decided to re-allocate manpower resources according to the members' availability to ensure the timeline is adhered to. As a result, the team was back on track.

Bug Metric

Testing and debuging time are allocated within each iteration to ensure the quality of functions developed. We calculate the bug score after testing is completed.

Bm iter2.PNG

In iteration 9, our team saw a spike in bug score. This is because during the UAT with sponsors, we found several functional and cosmetic bugs.

Project Risks:

During the acceptance phase, the team identified 6 probable risks. The risks were addressed by implementing mitigation plans and the likelihood of them occurring were reduced. However, we identified an additional risk upon discovery of the change in framework.

Risk Type Risk Description Likelihood Impact Mitigation Plan Remarks & Learning points
Technical Risk The MVP developed by an external IT team was built using Ruby on Rails instead of Django. The change in framework affects the integration of our system and was potentially a major delay in our schedule as we needed time to learn the new framework (Rails) and refresh our knowledge of Ruby. High High PM to revise the scope and reschedule the entire project. Also, the PM is to engage the external IT team to do a proper handover and find ways to help the FYP team progress as quickly as possible. There was a communication gap within TranSwap. The FYP point of contact from TranSwap did not know about this change until a relatively late stage. Due to time constraints, we decided to stick with Ruby on Rails for the client-facing modules, and Django for the admin modules. We felt that learning Ruby on Rails would be more efficient than 'translating' the MVP from Rails to Django. Furthermore, we can take this opportunity to learn a new framework. Currently, there is a close working relationship with the external IT team.
Technical Risk Change in the matching algorithm requirements, resulting in a delay in project schedule due to the need to re-implement the algorithm. Medium High Head of Quality Assurance to work closely with PM and sponsor to ensure that the matching algorithm and project scope is up to the sponsor's expectations from the start to prevent unnecessary changes. We also need to keep the business users, not just the POC and IT team, from TranSwap in the loop of what we are doing. A mitigation plan might help but requirements are expected to change and evolve in projects. Our team have decided to meet our sponsors at least once every iteration and demonstrate the application we have built up to that point. Sponsors are also provided the link to access our application so they can provide feedback through a Whatsapp group we have also created for more efficient communication as compared to email previously.
Project Management Risk Lack of domain knowledge in foreign currency exchange and matching algorithms. We might not be able to meet our client's expectations.

May result in incorrect estimation of tasks and time required, affecting project schedule.
Low Medium PM to ensure alignment between the team and client by involving client in the development process. PM also plans to have client meetings at the start and end of each iteration.

Lead developer is to research on the domain and break down the tasks in as much detail as possible so that the client will be able to easily identify any misinterpretations from the FYP team's side if any.
We felt that the likelihood of this risk reduces over time. As we are developing the application, we learnt more about the foreign currency exchange market and how we can match the data provided better. However, the effectiveness of matching algorithms is largely dependent on the characteristic and nature of the data. Thus, we felt that despite our gain in knowledge, there are still areas which might have an impact we have yet to discover.
Project Management Risk Lack of testers for user testing. TranSwap's target market is businesses. Thus, testers for user testing should be from business where the exchange and transferring of money are related to business transactions

However, business users are generally busy and more reluctant to switch to a new platform/service. This may result in inaccurate user testing results.
Medium Low The team will need commitment from sponsors to find testers. The team will provide the UT period in advance. Allow flexible UT timing and location to suit tester's schedule. It is less likely for the team not to have testers as our sponsors have agreed to provide testers for user testing. However, based on UT1, it was hard getting them to come down and not all of them followed the test plan strictly.
Technical Risk Computational time exceed server capacity. Application is unable to utilize the matching algorithm to match client transfer amounts. High High Lead Developer and the team work together to ensure that the algorithm is time-efficient. Head of Quality Assurance to work closely with PM and sponsors to ensure that the team has a larger data set with possible outliers or real currency booking information to be used for testing the algorithm. This is no longer a risk as the number of transfer requests per day is less than 10. For the next one year, the transfer requests per day is going to be less than 40. We have tested the algorithm with 40 transfer requests.
Project Management Risk Delay in getting necessary information due to sponsor's busy schedule or insufficient planning. The necessary information includes data points for testing and backend API for integration. Project schedule might be affected and delayed as a result. Medium High PM to have regular communication with sponsors.

PM to plan ahead with the team to find out if we need any information from the client in advance.
A script was implemented to do data-pushing every day to our staging servers. Also, we were given access to our client's (Ruby on Rails) code repository. Thus, new changes are reflected within the day itself. However, there is a small chance of the script malfunctioning. Hence, there is a need for us to monitor the data.
Technical Risk Limited or unrealistic data points used for assessing the performance of the matching algorithm. The algorithm might not be optimized for a data sets with certain characteristics. Medium High Head of Quality Assurance to work closely with PM and client to ensure that the team has a larger data set with possible outliers or real currency bookings information to be used for testing the algorithm. This is no longer a risk as we have real data from production server copied to our staging server everyday. The algorithm was developed with the possibility of a large data set kept in mind. Regardless, TranSwap's business development plan is to grow the number of transfer requests per day gradually for the next few years and our matching algorithm is able to support this change.

Technical Complexity:

Is480-potato-technical-complexity.jpg

Quality of product

Intermediate Deliverables:

Specification Modules
Minutes Sponsor iterations - 0, 1, 2, 4, 7, 8, 9 Supervisor weeks - 4, 5, 7, 8, 9
Metrics Burndown, Task Metrics, Bug Metrics
Testing User Testings

Deployment:

We have 3 instances for different purposes

  1. Production server: used by sponsors for side-by-side application
    Client site: http://52.24.204.197:3000/
    Admin site: http://52.24.204.197:8000/adminPanel/main/
  2. Staging server: used by the team for development, QA, UT and UAT
    Client site: http://52.221.229.151:3000/
    Admin site: http://52.221.229.151:8000/adminPanel/main/
  3. Demo server: opened to public to play around with our application.
    Client site: http://52.43.59.234:3000/
    Username: potatoclient, Password: potatoclient
    Admin site: http://52.43.59.234:8000/adminPanel/main/
    Username: potatoadmin, Password: potatoadmin

In the setting page, flexibility is given to the admin to run different algorithms, calculate the measurements for their own manual matching, and set the interval period for the selected matching algorithm to run automatically. Admin can also run the algorithm at any time which he desires out of the designated time interval.

Testing:

User Testing 1

Users: 3 business users
Scope: Feedback regarding existing functions on MVP
Main Results: Making a transfer request is confusing and TranSwap is not being transparent enough. We re-organized the transfer request process and made the TranSwap's fee and comparison to bank's fee more prominent.

User Acceptance Testing

Users: 2 sponsors
Scope: Feedback regarding the entire application
Main Results: 5 cosmetic issues and 3 functional issues out of 30 functions

Reflection

Team Reflection:

  1. Proper stakeholder management and the presence of a communication plan is vital because the success of a project highly depends on it.
  2. In a real life project, the only constant is change. We need to be quick and in learning and adapt to any changes encountered.
  3. The team members are overloaded sometimes due to the constant changes but we could not reject changes as those changes are either infrastructural or pertaining to core functions. Hence, we need to manage our time more effectively. Project's scope have to be properly managed to prevent scope creep.
  4. Taking over an application from other developers can be challenging if there is no proper documentation. Hence, we are going to do a proper handover documentation for TranSwap.

Sponsors' comment

"We are impressed by Team Potato’s technical knowledge and their ability to work together as a team. They were able to understand our unique business model and went the extra mile to enhance the original requested system. I believe the completed system will significantly reduce human error and save time due to the automation of certain processes.”