IS480 Team wiki: 2015T1 4Sight Mid Term Wiki
HOME | ABOUT US | PROJECT OVERVIEW | PROJECT MANAGEMENT | DOCUMENTATION |
Main Wiki | Midterm Wiki | Final Wiki |
Contents
|
Planned | Actual |
---|---|
Major Scope Changes
What has been added?
Date | Module | Category | Feature | Description | Value to Client |
---|---|---|---|---|---|
12 Aug 2015 | Appointment | Primary | Block Appointment time slots | Allow users to block time slots that are unavailable for booking such as when the Doctor is away. | Reduced the probability of wrongly booking an appointment time slot that is unavailable. |
27 Aug 2015 | Notification | Secondary | Notification Backlog | Notify users of important updates such as possible swap and blocking of appointment time slots. | Always keep users updated of important changes made. |
28 Aug 2015 | Queue Management | Secondary | Archive no show patient records | Compile a list of no show patient records for admin clerks. | Reduced the amount of time spent on collating a list of no show patient records. |
16 Sep 2015 | Analytics | Primary | Marketing Expenditure Form | Allow marketing team to manage campaigns' expenses and do up their monthly report. | Reduced the amount of time spent on data entry as information is currently recorded on multiple locations such as Google doc, CMS, papers and their appointment book. |
What has been removed?
Date | Module | Category | Feature | Reason for Removal |
---|---|---|---|---|
12 Aug 2015 | Notification | Secondary | Send SMS Appointment Cancellation | Users require quick response from patients and hence prefer calling. |
28 Aug 2015 | Analytics | Primary | Survey Results Analysis | High risk and development cost involved. Sponsor has decided to do the analysis separately using the analytics feature provided by Google. |
16 Sep 2015 | Analytics | Primary | Dashboard Summary and Trending | Users do not require an overview across the different dashboards. Analysis at the individual dashboard level is sufficient for the marketing team to perform their tasks. |
For more details, please view our Change Management Here!
Planned VS Actual Project Schedule
Schedule Highlights
- There are no major changes to project milestones.
- Deployment was delayed by 2 days due to some technical difficulties faced. However, this did not affect the progress of the team.
- Features are added (highlighted in yellow) or removed (strikethrough) to/from project schedule after careful deliberation by the team.
Schedule Metrics
View our Schedule Metrics Here!
Schedule Metric Highlights
Sprint | Planned Duration/days | Actual Duration/days | Schedule Metric Score | Action | Status |
---|---|---|---|---|---|
5 | 12 | 13 | 0.92 | Estimates are generally accurate and team consumed 1 buffer day. Slight delay due to deployment as static files served by django server failed to be deployed onto heroku. Overall project schedule not affected. | Completed |
7 | 12 | 14 | 0.86 | Estimates deviate from planned and team consumed 2 buffer days. Slight delay due to issues faced in the implementation of the 2 way SMS function. Overall project schedule not affected. | Completed |
8 | 12 | 13 | 0.92 | Estimates are generally accurate and team consumed 1 buffer day. Slight delay due to web socket implementation. Overall project schedule not affected. | Completed |
Tasks Metrics
Tasks Metric Highlights
Sprint | Planned Hours/hrs | Actual Hours/hrs | Task Metric Score | Description | Action Taken | Status |
---|---|---|---|---|---|---|
6 | 67 | 56 | 1.20 | Estimation of tasks is not as accurate as planned. There is an over-estimation of time required to complete some of the tasks. These include tasks for the designing of the admin page and some of the angular interactions between the frontend and backend when implementing the manage account feature for the administrative module. | Team reviewed on the tasks' estimation for the upcoming sprint and made necessary adjustments to those of similar complexity as those tasks that have been over-estimated. | Completed |
7 | 69.5 | 60 | 1.16 | Estimation of tasks is not as accurate as planned. There is an over-estimation of time required to complete tasks related to the survey feature of the notification module due to some changes requested from the sponsor. | Team checked if the upcoming sprint's tasks will be affected by the new change requests from sponsor. | Completed |
Bug Metrics
Bug Distribution based on Priority
Bug distribution based on Severity
Sprint | Bug Score | Summary of bug | Action Taken |
---|---|---|---|
5 | 60 | Most of the bugs were found during our deployment to heroku. The rest come from the interactions of the CRUD of appointment with other modules such as waiting list and queue. | Team stopped all current development then and resolved the bugs immediately. All bugs were fixed within the scheduled time. |
8 | 57 | Team stopped all current development then and resolved the bugs immediately. All bugs were fixed within the scheduled time. |
Project Risks
View our Risk Management Here!
Risk Type | Risk Description | Consequence | Likelihood | Impact | Mitigation Strategy |
---|---|---|---|---|---|
Project Management Risk | Insufficient users to conduct testing | Potential problem of not being able to complete a full User Testing. Data collected might not be accurate due to small user pool | High | High | Coordinate in advance with Clearvision stakeholders so that they have ample time to gather relevant users for our User Testing, such as involving nurses and optometrists from other Clearvision clinics. |
Technical Risk | 2 way SMS might not work for all mobile device platforms (iPhone, Android etc.). Current provider, infobip might not work for iPhone. | Team has to source for other providers that provide 2 way SMS service suitable for all mobile device platforms. This might cause a delay in project schedule | Medium | High | Lead Developer to work closely with provider and check if 2 way SMS service is possible for iPhone. Meanwhile team has to look for alternative providers and ensure that it works well with all mobile device platforms. |
Client Management Risk | As the team is doing early deployment, there might be more change requests along the way since users will be using the application on a day-to-day basis. These changes might not be easily picked up in our demo done every sprints as well as the user testing we have conducted because it does not cover all possible scenarios. | Incur higher development cost with increase change requests | Medium | High | 1. Any proposed change request is to go through the change management process. 2. Inform Supervisor of any major change request. |
Technical Complexities
Technical Complexity 1: Handling concurrent requests and slow clients
Issue
- In prod, server of choice would be Gunicorn, adapted from unicorn from Ruby. Written in pure python, enabling quick deployment and ease of use with the Django framework.
- However, Gunicorn as a Web Server Gateway Interface(WSGI) with a relatively small pool of workers (2x CPU Cores), can only handle a small number of concurrent requests.
- If there is no buffering solution in front of Gunicorn serving static files, under large number of users, the Gunicorn WSGI will suffer from considerable lag, impacting usability.
- Despite Heroku providing limited buffering functionality, large number of requests/responses will allow the Clearvision site to be susceptible to accidental/deliberate DDOS attacks.
Solution
- A buffering reverse proxy needs to be used in front of Gunicorn to buffer requests and responses from the outside web to the Gunicorn WSGI.
- Nginx is excellent at buffering slow clients
- Nginx Architecture:
- Heroku does not support Nginx implementation out of the box. Therefore, we utilized a custom Nginx-Gunicorn buildpack for heroku deployment, instead of the regular python buildpack that Heroku uses for generic Python applications
Reasons
- Gunicorn documentation strongly recommends Nginx in front of Gunicorn when in prod.
- Fast serving of static content. Nginx forwards requests for dynamic content to Gunicorn WSGI when it is needed.
Outcome
- Application is now more resistant to DDOS.
- When only static content is needed, application is faster than before.
- Slow clients over the network are buffered, resulting in a more responsive application with multiple users.
Technical Complexity 2: Appointment Heat Map
Issue
- Patients appointments are not well spread
- Clinic is at times very crowded or very empty
Solution
- Build a heat map view
Implementation
- Write a native python run file to create a list of future dated appointments
- Tie the time buckets to the respective doctors
Reasons for implementation
- Admin Clerks will have a visual representation of how packed the appointments are
- Enable Admin Clerks to effectively schedule and spread out patient appointments
Technical Complexity 3: Websockets
Issue
- Admin Clerks might be seeing an outdated view of the appointment calendar
Solution
- Build a real time web application using web sockets
Implementation
- Using pusher SaaS
- Sets all machine instances to listen on socket channels
- Partition the channels to push updates to the respective sockets
- Any change in the database will trigger the backend server to push updates to all listeners
Reasons for implementation
- Ensure accuracy in scheduling decisions
- Mitigate duplication of actions when adding patients to the queue
Quality of Product
Intermediate Deliverable
Stage | Specification | Module |
---|---|---|
Project Management | Minutes | Meeting Minutes |
Project Timeline | Project Timeline | |
Project Scope | Project Scope | |
Metrics | Schedule Metric | |
Task Metric | ||
Bug Metric | ||
Risks & Mitigations | Risk Management | |
Sponsor Change Requests | Change Management | |
Requirements | User Stories | Link to all user stories |
Analysis | Diagrams | Use-case Diagram |
ER Diagram | ||
As-is Process | ||
To-be Process | ||
Market Research | Market Research | |
Design | Mid-Fidelity Prototype | Wireframe |
Testing | User Test Plan and Results & Analysis | User Testing 1 |
User Testing 2 |
Deployment
View our architecture diagram for deployment here!
Testing
Our team has conducted 2 user testing with the actual users of our application.
User Testing 1
Location: Clearvision @ 6 Nutmeg Road
Date & Time: 23 August 2015, 10:00am
No. of Participants: 3
Objectives:
1. Verify that functionalities built are in line with user requirements
2. Determine if the user interface is intuitive
3. Gather feedback on current functionalities
4. Identify usability problems
User Testing 2
Location: Clearvision @ 6 Nutmeg Road
Date & Time: 16 September 2015, 15:00pm
No. of Participants: 8
Objectives:
1. Verify that functionalities built are in line with user requirements
2. Determine if the user interface is intuitive
3. Gather feedback on current functionalities
4. Identify usability problems
Reflection
Team's Reflection
Member's Reflection