IS480 Team wiki: 2015T1 4Sight Mid Term Wiki

From IS480
Jump to navigation Jump to search
4Sight team logo.png
4Sight Home.png HOME   4Sight Team.png ABOUT US   4Sight Project overview.png PROJECT OVERVIEW   4Sight Project management.png PROJECT MANAGEMENT   4Sight Documentation.png DOCUMENTATION  
Main Wiki Midterm Wiki Final Wiki

Project Progress Summary

Midterm Slides

Click here to download our midterm presentation slides!

Deployed Website Link

Deployed Link: https://clearvision.herokuapp.com/Clearvision/login/

Development Progress

Current Sprint: 10
Sprint Duration: 05 Oct 2015 - 16 Oct 2015
Major Milestone: Midterm Presentation
Features Involved:

  • Administrative Module
  • Mobile Calendar Module

Project Highlights

  • Deployed application to heroku on 28 September 2015
  • Completed 90% of our development work as of 07 Oct 2015
  • 3 features removed from scope since acceptance (see below)
  • Added 4 new features to our scope since acceptance (see below)
  • No delay in project schedule. Team is progressing as planned.
  • Completed 2 user testings with actual users before acceptance and midterm
  • Collected 174 appointment records in our user tracking module

Milestone Status

4Sight Milestone Updates.png

Project Management

Project Status

  • The team is confident of completing the project and delivering the application on time.
4Sight Development Progress.png

Planned VS Actual Project Scope

Planned Actual

4Sight PlannedScope.png

4Sight ActualScope.png

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

4Sight PlannedSchedule.png

4Sight ActualSchedule.png

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!

4Sight ScheduleMetricScore.JPG

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

View our Tasks Metrics Here!

4Sight TaskMetricScore.JPG

Tasks Metric Highlights

Sprint Planned Hours/hrs Actual Hours/hrs Task Metric Score Description Action Taken Status
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

View our Bug Metrics Here!

4Sight BugMetricScore.JPG

Bug Distribution based on Priority

4Sight BugsByPriority.JPG

Bug distribution based on Severity

4Sight BugsBySeverity.JPG

Bug Metrics Highlights

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 Most of the bugs found were from the analytics module. It derived from the complexity in the combination of charts we could have as well as the corner cases that we have not addressed in the analytics module. 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 Unable to get actual users to conduct testing due to busy schedule Unable to get genuine feedback from actual users and hence affecting usability of system 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

Architecture Diagram


Technical Complexity 1: Handling concurrent requests and slow clients


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


  • 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


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


  • 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: Patient Volume Visualization


Often with the manual means of booking appointments, the admin assistant that actually executes the booking has to look though the appointment book, and count how many patients are on that particular appointment requested by the patient(on the call) before scheduling the patient. If the admin assistant feels that the appointment is approaching maximum capacity, she then decides to look for another appointment timing that has a lower patient count. The process then repeats; manually scanning through the dates(and weeks), just to look for a suitable timeslot to schedule the patient. 

This results in scheduled appointments that are not well spread out, leaving the clinic too busy - or too empty.


A consolidated view of appointment timeslot capacities deeply integrated with the main calendar to display scheduled applications. With this functionality, the user can, at a short glance, zoom in on appointment timeslots that are relatively empty - or full.

Upon initiating to schedule a new appointment, the admin assistant opens the "Add Appointment" drawer. Upon selecting the doctor and appointment type, the user is greeted with a plethora of timeslots from today onwards, colour coded to reflect how full(or empty) a particular timeslot is. 

Implementation Challenges

From a database perspective, appointments shown on the main calendar consists of appointments objects that exist with columns(date, time, doctor, patients, etc) - that is, appointments that have patients tied to it. 

In this case, how could we retrieve a list of appointments in the future that have no patients tied to the appointments? We figured that additional objects has to exist before the creation of appointments, and appointments had to reference these objects. This means that the additional objects not tied to any appointments are free(no patients).


To tackle this issue, we broke up the appointment model’s columns(date, time, doctor, patients, etc) , to reference another table, namely Timeslots. Timeslot objects are configured upon load of the database, for a configurable duration (years), timing per appointment type and timing per doctor. In this way, appointment objects need not exist for us to recognise that there are no appointments tied to that particular Timeslot

For further customisation, the administrator has the ability to tweak the colours of the heatmap visualisation, according to the number of patients in the appointment timeslot.

In essence, a combination of timeslots that are tied to appointments and the timeslots that are not, form our heat map visualization.

Technical Complexity 3: Web Sockets


Despite having a relatively low rate of users using the application and executing the same action at the same time(think race conditions), we want to ensure that users are looking at the the most updated version of the calendar, enabling greater strategic decisions when scheduling an appointment.

When actions are done on one web instance, the same web instance updates the database with the new information. Technically, all clients have the latest information - but not until they force a refresh of the web page. To deliver a greater user experience, we want the web application to be self aware such that if one client makes changes to the database after a particular action, all other clients are aware of the change, and in turn update their respective pages, in real time


Websockets provide this functionality. Upon every action, the application sends out notifcations to all clients, and these notifications can be broken down into channels and events. In this way, our frontend client can listen on a specific channel and only update a certain part of the UI if its broadcasted on a particular event. For example, the frontend client can be listening on “AppointmentChanges” channel, but would only call the function to remove an appointment from the calendar when its received on the “RemoveAppointment” event.

Implementation Challenges

Although Django is a relatively old framework with the lack of websockets functionality built-in, its outstanding ORM and extensive documentation still made us choose to continue developing with it. Hence, we started our search for websocket libraries that provided tight integration with the Django ORM. 

We thought that SwampDragon was the answer. The library was working great in development. When database rows were changed, messages were pushed to all other clients through a dedicated SwampDragon server, over a redis broker.

Then we tried to deploy it on our deployment server, Heroku, and that when a lot of time was spent trying to make our real time application work. 

To cut the long story short, the Choot Jail Heroku architecture disallowed running a server process alongside the main web process. Even if SwampDragon was running on another web application, it would further complicate matters because we had to decide which dyno should be running the redis broker process, and it may introduce cross domain problems. We went further to attempt a workaround to run two processes(web and SwampDragon server) on one dyno, and using Nginx as a reverse proxy to route requests from a subdomain of our application to the SwampDragon server, to no avail.

Reasons for implementation

After countless attempts and time spent trying to solve the issue, we finally chose the Pusher API as the framework to deliver this functionality. With a allotment of 100,000 messages per 24 hour period on the free tier, it is more than sufficient for our application’s scale.

Methods in the backend are configured to trigger notifications to the Pusher server, and in turn the Pusher server pushes the notifications in the channel-event standard to all other clients. AngularJS in the front end then listens on the specific channel-event standards, and updates the calendar/queue accordingly.

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


View our architecture diagram for deployment here!


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

View our User Testing 1 Here!

User Testing 2

Location: Clearvision @ 6 Nutmeg Road
Date & Time: 16 September 2015, 15:00pm
No. of Participants: 8
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

View our User Testing 2 Here!


Team's Reflection

What have we done well so far?

  • Focused a lot on providing business value to our client when we design and build the app
  • As a result, both our client and the actual application users like the product and gave us positive feedbacks

What can be improved?

  • Do more in-depth research before going ahead with a technical implementation

How will we do better?

  • Consistently gathering and collating feedbacks from the users as the use the application on a day-to-day basis
  • For any technical implementations that we are unfamiliar with, must come up with a proof of concept

Member's Reflection

4Sight Midterm LearningOutcome.png