Difference between revisions of "IS480 Team wiki: 2015T1 4Sight Mid Term Wiki"
Jump to navigation
Jump to search
Line 295: | Line 295: | ||
|- | |- | ||
|align=center| Client Management Risk | |align=center| 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 | + | || 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 | || Incur higher development cost with increase change requests | ||
|align=center| Medium | |align=center| Medium |
Revision as of 17:18, 3 October 2015
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
Bug Metrics
Bug Distribution based on Priority
Bug distribution based on Severity
Sprint | Bug Score | Summary of bug | Action Taken |
---|---|---|---|
5 | 60 | Bugs found are mainly from ... | Stop current development and resolve the bug immediately. Project Manager reschedules the project. |
8 | 57 | 0.92 |
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 phone models. Current provider, infobip might not work for iPhone. | Team has to source for other providers that provide 2 way SMS service suitable for all phone models. 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 phone models. |
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 | User Testing 1 |
User Testing 2 |