HeaderSIS.jpg

IS480 Team wiki: 2016T1 IPMAN Final Wiki

From IS480
Revision as of 11:41, 14 November 2016 by Xhchaung.2013 (talk | contribs)
Jump to navigation Jump to search
Team IPMAN Logo 1200x960.png


Team IPMAN Icon Home.png   HOME

 

Team IPMAN Icon AboutUs.png   ABOUT US

 

Team IPMAN Icon ProjectOverview.png   PROJECT OVERVIEW

 

Team IPMAN Icon ProjectManagement.png   PROJECT MANAGEMENT

 

Team IPMAN Icon ProjectDocumentation.png   DOCUMENTATION

 


IPMAN FinalsWiki Title.png


Project Progress Summary


IPMAN Dashboard Final.png


IPMAN FinalsSlides Icon.png IPMAN MidTermDeployedSite Icon.png IPMAN Finals Pitch Video Icon.png IPMAN Poster Icon.png

Note: We have deployed live on Hook Coffee's existing application. However, as Team IPMAN has signed an NDA with Hook Coffee, the above link to the deployed site is only available to existing administrators in Hook Coffee. To view the application, we have created a staging server in which the credentials are available in the deployment section below.


Project Highlights


Project Challenges


Project Achievements


Project Management


Project Status

IPMAN Progress Overview Final.png


Project Schedule (Plan vs. Actual)

No major changes were made to the project schedule since IPMAN's Mid-Term presentation. Firstly, the team shifted our user testing 3 from 18 October 2016 to 3 November 2016. The team settled on this decision as we wanted to ensure that all functions of our platform would be covered and tested. As such, it was pushed forward from Sprint 11 to 12 when all functions would have been completed. Next, Team IPMAN added in new function in sprint 13 which is the integration of gifts tab because it was a new feature that the freelancer developers have built on the old application. In order for sponsors to be using the new application that Team IPMAN has built, Team IPMAN ported over the entire code that the freelancer developers have created onto the new application as soon as they were built. Lastly. the team also added in the project handover procedure and implementation as a new task in sprint 14 to ensure that there would be a proper handover timeline that the team would adhere closely to. This will allow all documentations to be properly handed over to the sponsors and freelancer developers. We believe proper documentation and instructions is vital for our sponsors and their freelance developers now and also, in the future.

Planned Project Schedule

The planned project schedule shows the Team IPMAN's timeline during Mid-Term presentation:

IPMAN Timeline MidTerm Planned.png


Actual Project Schedule

The actual project schedule reflects the changes made to Team IPMAN's timeline between Mid-Term presentation and Final presentation:

IPMAN Timeline Final Actual.png


Project Metrics


Project Risks

From the period of Mid-Terms till Final Presentation, we will like to highlight that our concerns were 1) Technical Risk and 2) Stakeholder Management Risk as described below:

S/N Risk Type Risk Event Likelihood Impact Level Category Strategy Adopted Actions
11 Technical Risk Team IPMAN had the risk to reformulate the analysis models because of sparse data sets. High High A Mitigate Team IPMAN consulted one of our Professors for the feasibility of the models created and also did a lot of prior research before the implementation of analysis modules. Subsequently, the team created a quick mock up for the prototype so that changes can be made easily.
12 Stakeholder Management Risk Freelancer developer created new feature on the old dashboard. Sponsors were inclined to use the old dashboard if the codes were not ported over to the new application. High High A Mitigate Team IPMAN ported over the entire code that the freelancer developers have created onto the new application as soon as they were built. Team IPMAN will schedule for a handover ceremony to present to the freelancer developers all the proper documentation we have created and assist any questions from them so as to ensure the continuity of the application.



We also foresee a potential integration risk that can occur post-handover of our project, hence planning our mitigation plan in advance:

S/N Risk Type Risk Event Likelihood Impact Level Category Mitigation
13 Integration Risk The new application that we have built is using the database models. If the database models change (such as when the internationalization functionality was built by the freelancers), these changes would impact our system. Low High B Team IPMAN took the initiative to understand what changes have been made and whether the changes are necessary by discussing with the freelancers early on. We also work to communicate with freelancers to modify models in a way such that any impact is minimized, e.g. adding fields instead of changing fields in the model.



Technical Complexity




Quality of Product


Project Deliverables

Stage Specification Modules
Project Management Project Schedule Project Schedule
Meeting Minutes Internal, Sponsor and Supervisor Meeting Minutes
Metrics Project Metrics
Risk Management Risk Management
Change Management Change Management
Requirements Project Overview Project Overview
Team's Motivation Team's Motivation
Project Scope Project Scope
User Stories User Stories
Analysis Personas and Scenarios Personas & Scenarios
Diagrams Diagrams
Design Prototypes Low & Mid Fidelity Prototypes
Project Implementation Technologies Used Technologies Implemented
Testing User Test Plan and Results Testing Documentation
Handover Handover Procedure Timeline See project handover timeline below
User Manual Delivered via Private Folder on Dropbox
Developers Manual Delivered via Private Folder on Dropbox
Setup Manual Delivered via Private Folder on Dropbox


Quality

Performance:
Because we cannot optimize the Python libraries (after trying both PyPDF and pdfrw), we had to render the labels with customer information, in .pdf format, in a way that ensured high performance during the regular business hours. We generated new tasks for every order to pre-process the PDFs using a task scheduler that was built on top of Python (Celery) so that new orders would have their order label pdfs ready by the time they must be printed. This sped up the process for each label from 0.47s to 0.05s for our experiment with one label, and led to an overall reduction for printing all labels by 68.09%.

In pages that require extended or large use of data, long page loading times are expected. Asynchronous calls help to alleviate this issue, rendering the longest-loading endpoint to be the page-load critical path. Also, to minimise the user’s idle time, we display data as they load, without waiting for the other endpoints. This allows the user to start using parts of the page first while waiting for other endpoints with longer loading times to be returned. Apart from improved user experience, this methodology also builds fault-tolerance into each page. This way, even if a particular endpoint fails to load, other parts of the page can continue to function.

With constant communication between our front-and-back end developers, we have also managed to minimise the use of promises/callbacks on the frontend to process data. Our endpoints allow for batch-updates, where foreseen, to allow at most one HTTP call to process each user action. This reduces the amount of round-trip time (RTT) for communication between the client and server, saving bandwidth and loading times for both parties.

Maintainability:
We ensure high maintainability for our code base through various ways. For example, we maximize the use of functionalities that are built into Django itself, from the Role-Based Access Control System to the Decorator functionalities that we use for each endpoint. This is as our code would have to be maintained by a third party in the future, so following conventions would enable them to easily take over our work. We also configured PyCharm to use PEP8, a style guide for Python, and ensured that the majority of our code is PEP8-compliant. We have documentation for each API-endpoint so that they can be easily reused, and that is documented in the developer’s manual. We also ensure that both the development branch and production branches are separate during our development so that any urgent bug changes in the production branch can be quickly rectified and redeployed, as we are deploying live and running it for the system. We also made sure that messages in the each of the commits were succinct and documented what changes were made to the codebase, and isolated each change to each commit, so that it is easy to refer to later on by any party.

Usability:
For every functionality that we build, we have ensured maximum usability by using the following design methodology:

[diagram to be inserted here]

We improved the usability of their system, for instance in the resend order functionality - from 20 clicks down to 4 clicks - an 80% improvement.

We meet our sponsor at the start and end of every sprint for the following reviews, meeting every fortnight to ensure that any problems with our system can be made known to us immediately. We also communicate remotely via Telegram to validate our work and to communicate urgent matters to our sponsor. This is also a medium for us to gather feedback on our system if our sponsor is not available to meet physically, so that we still have timely feedback to continue our work that will also meet his business needs.

Deployment

Note: Facebook login will not work as it is tied to the hostname: hookcoffee.com.sg
To view application, visit: http://128.199.107.26/manager
Username: temp@supertemp.temp
Password: supersecurepassword

Testing



Reflection

Team Reflection


Individual Reflection


Sponsors' Testimonial



Silhouettes wiki background IPMAN.png