Difference between revisions of "IS480 Team wiki:2017T2 Zenith FinalWiki"
(Created page with "<!--logo start--> center|1000px <!--logo end--> <!--header start--> {|style="background-color: #830303; color:#F5F5F5; padding: 10 0 10 0;" width="...") |
|||
(27 intermediate revisions by 2 users not shown) | |||
Line 28: | Line 28: | ||
[[IS480 Team wiki: 2017T2T Zenith | <font color="#000000"><b>Main Wiki</b></font>]] | [[IS480 Team wiki: 2017T2T Zenith | <font color="#000000"><b>Main Wiki</b></font>]] | ||
− | | style="font-size:100%; border-bottom: | + | | style="font-size:100%; border-bottom:1px solid #000000; border-left:20px solid #ffffff; border-right:20px solid #ffffff; text-align:center; background-color:#fffffff; " width="10%" | [[IS480_Team_wiki:2017T2 Zenith_Midterm Wiki | <font color="#000000"><b>Midterm Wiki</b></font>]] |
− | | style="font-size:100%; border-bottom: | + | | style="font-size:100%; border-bottom:5px solid #000000; border-left:20px solid #ffffff; border-right:20px solid #ffffff; text-align:center; background-color:#ffffff; " width="10%" | [[IS480_Team_wiki:2017T2 Zenith_FinalWiki| <font color="#000000"><b>Final Wiki</b></font>]] |
|} | |} | ||
<!--sub header end--> | <!--sub header end--> | ||
<br> | <br> | ||
− | [[File: | + | [[File:Zenith_final_header.PNG|center|1000px]] |
==Project Progress Summary== | ==Project Progress Summary== | ||
− | === | + | ===Finals Slides=== |
− | [[Media: | + | [[Media:Zenith_Finals_slides.pdf|Zenith Finals Slides]] |
===Deployed site link=== | ===Deployed site link=== | ||
<center> | <center> | ||
− | [[Image: Zenith deployment link.jpeg |600px|link= | + | [[Image: Zenith deployment link.jpeg |600px|link=https://themedsense.com/]] |
+ | |||
+ | Staging site: http://medsense-staging-env.ap-southeast-1.elasticbeanstalk.com/ | ||
</center> | </center> | ||
Line 51: | Line 53: | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
Our project schedule is divided into 13 iterations. | Our project schedule is divided into 13 iterations. | ||
− | * We are currently on our | + | * We are currently on our 12th iteration (26 Mar - 8 Apr 2018). |
− | * Up till | + | * Up till 4 Apr 2018, we have completed <b>100</b>% of our development progress. |
− | * | + | * 2 User Acceptance Tests were conducted before the Final Presentation. The results are shown [[IS480_Team_wiki:2017T2 Zenith_user_testing|here]]. |
− | * Achieved and exceeded [[IS480_Team_wiki:2017T2 Zenith_x-factor| | + | * Achieved and exceeded [[IS480_Team_wiki:2017T2 Zenith_x-factor|Finals X-factor]]. |
− | |||
Unexpected events: | Unexpected events: | ||
− | + | * List of requirement changes after Midterms can be viewed [[IS480_Team_wiki:2017T2_Zenith_change_management#Change log (till Finals)| here]]. | |
− | |||
− | * List of requirement changes after | ||
</div> | </div> | ||
==Project Management== | ==Project Management== | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | <b>Iteration Progress:</b> | + | <b>Iteration Progress:</b> 13 of 13<br/> |
− | <b>Features Completion:</b> | + | <b>Features Completion:</b> 100% (46 out of 46 features)<br/> |
<b>Confidence Level:</b> 100% | <b>Confidence Level:</b> 100% | ||
</div> | </div> | ||
Line 76: | Line 75: | ||
</div> | </div> | ||
<br> | <br> | ||
− | [[File: | + | [[File:Zenith_final_scope.JPG|center|800px]] |
<br> | <br> | ||
Line 89: | Line 88: | ||
|- | |- | ||
| | | | ||
− | [[File: | + | [[File:Zenith_midterm_actual_timeline.png|500px]] |
|| | || | ||
− | [[File: | + | [[File:Zenith_final_actual_timeline.png|500px]] |
|} | |} | ||
</center> | </center> | ||
Line 98: | Line 97: | ||
====Project Schedule:==== | ====Project Schedule:==== | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | Planned Schedule ( | + | Planned Schedule (Midterm)<br> <br> |
− | [[File: | + | [[File:Zenith_final_expected_schedule.png|center|900px]] |
<br><br> | <br><br> | ||
− | Changes in planned schedule ( | + | Changes in planned schedule (Midterm)<br> <br> |
− | [[File: | + | [[File:Zenith_final_changed_schedule.png|center|900px]] |
<br><br> | <br><br> | ||
− | Actual Schedule ( | + | Actual Schedule (Final)<br> <br> |
− | [[File: | + | [[File:Zenith_final_actual_schedule.png|center|900px]] |
</div> | </div> | ||
Line 116: | Line 115: | ||
====Task metric==== | ====Task metric==== | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | [[File: | + | [[File:Zenith task metric.png|center|600px]] |
<!--Task Metric Table Start--> | <!--Task Metric Table Start--> | ||
Line 144: | Line 143: | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | [[File: | + | [[File:Zenith bug count.png|center|600px]] <br> |
− | [[File: | + | [[File:Zenith bug score.png|center|600px]]<br> |
<center><b>Note:</b> There were no coding tasks for iteration 1. </center> | <center><b>Note:</b> There were no coding tasks for iteration 1. </center> | ||
Line 197: | Line 196: | ||
[[File:Zenith risk metric.png|center|600px]] | [[File:Zenith risk metric.png|center|600px]] | ||
− | |||
{| class="wikitable" style="font-family:Garamond; background-color:#FFFFFF; width: 1000px"|+ '''Cells left-aligned, table centered''' | {| class="wikitable" style="font-family:Garamond; background-color:#FFFFFF; width: 1000px"|+ '''Cells left-aligned, table centered''' | ||
|- | |- | ||
Line 211: | Line 209: | ||
|style="text-align: center;"| 1 | |style="text-align: center;"| 1 | ||
− | |style="text-align: center;"| | + | |style="text-align: center;"| Project Management |
− | |style="text-align: left;vertical-align: | + | |style="text-align: left;vertical-align: top"| The schedule is planned based on macro functionalities, so small coding tasks may have been left out / time is underestimated due to lack of experience. |
− | |style="text-align: center;"| | + | |style="text-align: center;"| Medium |
− | |style="text-align: center;"| High | + | |style="text-align: center;"| High |
− | |style="text-align: center;"| | + | |style="text-align: center;"| A |
− | |style="text-align: left;vertical-align: top"| | + | |style="text-align: left;vertical-align: top"|Project Manager will review the project schedule and the time needed for each task regularly, and make changes when necessary. |
|- | |- | ||
|style="text-align: center;"| 2 | |style="text-align: center;"| 2 | ||
− | |style="text-align: center;"| | + | |style="text-align: center;"| Client Management |
− | |style="text-align: left;vertical-align: | + | |style="text-align: left;vertical-align: top"| Client may request for changes to existing functionalities or request for new functionalities. These increases in scope may delay the project completion. |
|style="text-align: center;"| Medium | |style="text-align: center;"| Medium | ||
|style="text-align: center;"| Medium | |style="text-align: center;"| Medium | ||
|style="text-align: center;"| B | |style="text-align: center;"| B | ||
− | |style="text-align: left;vertical-align: | + | |style="text-align: left;vertical-align: top"| Team will have to consider expertise and time required. Project Manager will manage the expectations of the client. |
|- | |- | ||
|style="text-align: center;"| 3 | |style="text-align: center;"| 3 | ||
|style="text-align: center;"| Project Management | |style="text-align: center;"| Project Management | ||
− | |style="text-align: left;vertical-align: | + | |style="text-align: left;vertical-align: top"| Team members feel overwhelmed by the workload, and feel that they are increasingly burned out. |
|style="text-align: center;"| Medium | |style="text-align: center;"| Medium | ||
− | |style="text-align: center;"| | + | |style="text-align: center;"| Low |
− | |style="text-align: center;"| | + | |style="text-align: center;"| C |
− | |style="text-align: left;vertical-align: | + | |style="text-align: left;vertical-align: top"| Team members will limit the increases in scope, and prioritize functions in case functions need to be dropped. |
|- | |- | ||
|} | |} | ||
Line 243: | Line 241: | ||
===Technical Complexity:=== | ===Technical Complexity:=== | ||
− | |||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | Natural Language Processing | + | Our technical complexity comprises of: |
− | + | * Use of Natural Language Processing to mark open-ended questions. [[IS480 Team wiki:2017T2 Zenith Midterm Wiki#Natural Language Processing|(Discussed here during Midterms) ]] | |
− | + | * Development of game for students, including anti-cheating mechanisms. [[IS480 Team wiki:2017T2 Zenith Midterm Wiki#Game development|(Discussed here during Midterms)]] | |
− | + | * Security features: firewall, automated backup for database, HTTPS protocol, SSH tunnel, and encryption of environment variables. [[IS480 Team wiki:2017T2 Zenith Midterm Wiki#Added security features|(Discussed here during Midterms)]] | |
− | + | * Recommendation Models for Students and Professors. | |
− | + | </div> <br> | |
− | |||
− | |||
− | |||
− | |||
− | [[ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | [[ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | [[ | ||
− | |||
− | </div> | ||
− | <br> | ||
− | ==== | + | ====Recommendation Models ==== |
+ | =====Student Recommendation Model===== | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | + | We have implemented a recommendation model for students, to address their individual weaknesses.This model is guided by the following principles: <br> <br> | |
− | + | # Recommend beginner/advanced cases based on year of study: Medical students in their third year and below will be recommended beginner cases, while medical students who are in the fourth and fifth year of study will be recommended advanced cases. This is in accordance with their curriculum in school. <br> <br> | |
− | < | + | # Recommend most popular cases for new users: A new user might feel overwhelmed with the selection of cases. Hence, we will recommend the popular cases for them to familiarize themselves with the games. Their performance in these popular cases is a good gauge of their personal strengths and weaknesses, and will serve as a starting point for more targeted recommendations in the future. <br> <br> |
− | + | # Recommend cases in the sub-specialties they are weakest in, based on the cases they have previously done: Through our model, we aim to tailor instruction to individual learner's needs. By recommending students to practice on topics they are weaker in, we believe that the medical students will be able to learn in a more holistic manner. <br> <br> | |
− | + | </div> | |
− | + | =====Professor Recommendation Model===== | |
− | |||
− | |||
− | < | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | < | ||
− | |||
− | |||
− | |||
− | < | ||
− | <br> | ||
− | |||
− | ==== | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | + | For Professors, knowing which areas students are commonly weak in will assist them in their course planning. We would like to encourage Professors to upload more cases on the students' weaker topics. The recommendation model is guided by the following principles: <br> <br> | |
− | + | # The recommended sub-specialties are based on the overall cohort performances. <br> <br> | |
− | + | # Recommend sub-specialties with the least number of cases if there is insufficient data to determine the weaker topics: Professors will not be able to gauge students' performances in areas where there are no cases for students to try. The model will encourage them to upload cases in those sub-specialties, so that they can get a more accurate idea of the students' weaknesses. <br> <br> | |
− | + | # Recommend sub-specialties where the number of pending cases is above a certain threshold: Doing so will encourage Professors to vet the pending cases, which will increase the number of cases for students to practice on. <br> <br> | |
− | |||
− | |||
− | |||
− | |||
− | |||
</div> | </div> | ||
Line 365: | Line 313: | ||
|- | |- | ||
− | |rowspan=" | + | |rowspan="2"| Testing |
|| [[IS480_Team_wiki:2017T2 Zenith User Testing 1 |User Acceptance Test 1 (11 - 13 Feb 2018)]] | || [[IS480_Team_wiki:2017T2 Zenith User Testing 1 |User Acceptance Test 1 (11 - 13 Feb 2018)]] | ||
+ | |- | ||
+ | || [[IS480_Team_wiki:2017T2 Zenith User Testing 2 |User Acceptance Test 2 (4 - 10 Apr 2018)]] | ||
|- | |- | ||
|} | |} | ||
Line 379: | Line 329: | ||
*Functionality testing after completion of function. | *Functionality testing after completion of function. | ||
*Regression testing at the end of every iteration. | *Regression testing at the end of every iteration. | ||
− | * | + | *2 UATs completed by Final Presentation. |
− | *1 UAT has been completed | + | *1 UAT has been completed after Midterms. To view the results of this UAT, [[IS480_Team_wiki:2017T2 Zenith User Testing 2|click here]]. |
</div> | </div> | ||
Line 388: | Line 338: | ||
===Team Reflection:=== | ===Team Reflection:=== | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | + | Throughout our FYP journey, we have tried our best to implement the changes that our clients have requested, even if it meant additional coding hours or having to rework the project schedule multiple times. This is because we place emphasis on our project's value to the clients. However, as we approach the completion of our project, we had to scrutinize every change more closely. We had to find a balance between providing the best value to the clients, as well as our workload and confidence of completing the project in time. | |
− | |||
</div> | </div> | ||
=== Individual Reflections: === | === Individual Reflections: === | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | <b>Amelia: </b> | + | <b>Amelia: </b><br> |
− | + | Our stakeholders have been actively involved in our project right from the start. Apart from meeting our supervisor regularly, we have been in constant communication with our other stakeholders. Working with a team of 17 entails certain challenges. I have learnt to manage different perspectives and expectations, as well as balance the workload and priorities of my team. | |
− | + | <br> <br> | |
− | <br> | ||
− | |||
− | |||
− | It has been a challenging | + | <b>Chin Rui: </b> <br> |
− | <br> | + | It has been a challenging journey technically. The application architecture has undergone multiple major changes, especially our security configurations, to ensure better quality and continuity for our clients. I have also discovered the difficulties in planning a software architecture after taking into account budget, skill and technical constrains. |
+ | <br> <br> | ||
− | <b>Ervin: </b> | + | <b>Ervin: </b><br> |
− | + | As the Quality Assurance lead, I had to scrutinize every single corner case in the application, and constantly come up with more test cases. After our midterm presentation we conducted regression testing, a User Acceptance Test and load testing. I learnt that observing users during the UAT is imperative, as some users tend to not notice certain issues, or they do not voice them out. The UAT is also an opportunity for us to see if the functions are indeed useful for the users. | |
− | + | <br><br> | |
− | <br> | ||
− | <b>Ming Rui: </b> | + | <b>Ming Rui: </b><br> |
− | + | After our Midterm presentation, we completely changed the UI of our application. We went back to the paper and Axure prototypes, and thought of ways to improve the user experience. The final designs are a product of multiple revamps, each better compared to the previous. I have learnt the importance of gathering feedback from a larger group of users, instead of just the Medsense team from NUS. | |
− | + | <br> <br> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | <br> | ||
− | <b> | + | <b>Qimin: </b><br> |
+ | Due to the various changes we have made over the course of our project, we had to do some refactoring. I have learnt that regardless of the time and effort we put into getting the schema right at the start of the project, changes are inevitable during the development process. Being the Full-Stack Support has definitely challenged me to improve my technical skills and resilience as I dealt with the bug infestation that came with the refactoring. | ||
+ | <br> <br> | ||
− | + | <b>Ricky: </b><br> | |
+ | As a backend developer, I have realised that is important to have a seamless integration of the frontend components with the server side logic as well as designing and implementing data storage solutions. It has been a great experience being the technical lead, and I am glad that I could help my team members with the technical issues they faced. | ||
<br> | <br> | ||
<div> | <div> |
Latest revision as of 14:46, 16 April 2018
Midterm Wiki | Final Wiki |
Contents
Project Progress Summary
Finals Slides
Deployed site link
Staging site: http://medsense-staging-env.ap-southeast-1.elasticbeanstalk.com/
Project Highlights
Our project schedule is divided into 13 iterations.
- We are currently on our 12th iteration (26 Mar - 8 Apr 2018).
- Up till 4 Apr 2018, we have completed 100% of our development progress.
- 2 User Acceptance Tests were conducted before the Final Presentation. The results are shown here.
- Achieved and exceeded Finals X-factor.
Unexpected events:
- List of requirement changes after Midterms can be viewed here.
Project Management
Iteration Progress: 13 of 13
Features Completion: 100% (46 out of 46 features)
Confidence Level: 100%
Project Status:
A breakdown of tasks is shown in our project scope.
Project Schedule (Plan Vs Actual):
Milestones Overview:
Project Schedule:
Project Metrics:
Task metric
Score | TM <= 50 | 50 < TM <= 75 | 75 < TM <= 125 | 125 < TM <= 150 | 150 > TM |
---|---|---|---|---|---|
Action | 1. Inform supervisor within 24 hours. 2. Re-estimate tasks for future iterations. 3. Consider dropping Tasks. |
1. Re-estimate tasks for future iterations. 2. Deduct number of days behind from buffer days. 3. If there are no more buffer days, decide the functionalities to drop. |
1. Our estimates are fairly accurate, and are roughly on track. 2. Add/deduct number of days ahead / behind from buffer days. |
1. Re-estimate tasks for future iterations. 2. Add number of days ahead to buffer days. |
1. Inform supervisor within 24 hours. 2. Re-estimate tasks for future iterations. |
Bug metric
Severity | Low Impact | High Impact | Critical Impact |
---|---|---|---|
Description | User interface display errors, such as out of alignment, colour used is not according to theme.
It does not affect the functionality of the system. |
The system is functional with some non-critical functionalities are not working. | The system is not functional.
Bugs have to be fixed before proceeding. |
Points | BM <= 5 | 5 < BM < 10 | BM >= 10 |
---|---|---|---|
Description | The system does not need immediate fixing, could be fixed during buffer time or during coding sessions | Coders to use planned debugging time in the iteration to solve the bug | The team has to stop all current development and resolve the bug immediately |
Project Risks:
S/N | Risk Type | Description | Likelihood | Impact Level | Threat Level | Mitigation Plan |
---|---|---|---|---|---|---|
1 | Project Management | The schedule is planned based on macro functionalities, so small coding tasks may have been left out / time is underestimated due to lack of experience. | Medium | High | A | Project Manager will review the project schedule and the time needed for each task regularly, and make changes when necessary. |
2 | Client Management | Client may request for changes to existing functionalities or request for new functionalities. These increases in scope may delay the project completion. | Medium | Medium | B | Team will have to consider expertise and time required. Project Manager will manage the expectations of the client. |
3 | Project Management | Team members feel overwhelmed by the workload, and feel that they are increasingly burned out. | Medium | Low | C | Team members will limit the increases in scope, and prioritize functions in case functions need to be dropped. |
Technical Complexity:
Our technical complexity comprises of:
- Use of Natural Language Processing to mark open-ended questions. (Discussed here during Midterms)
- Development of game for students, including anti-cheating mechanisms. (Discussed here during Midterms)
- Security features: firewall, automated backup for database, HTTPS protocol, SSH tunnel, and encryption of environment variables. (Discussed here during Midterms)
- Recommendation Models for Students and Professors.
Recommendation Models
Student Recommendation Model
We have implemented a recommendation model for students, to address their individual weaknesses.This model is guided by the following principles:
- Recommend beginner/advanced cases based on year of study: Medical students in their third year and below will be recommended beginner cases, while medical students who are in the fourth and fifth year of study will be recommended advanced cases. This is in accordance with their curriculum in school.
- Recommend most popular cases for new users: A new user might feel overwhelmed with the selection of cases. Hence, we will recommend the popular cases for them to familiarize themselves with the games. Their performance in these popular cases is a good gauge of their personal strengths and weaknesses, and will serve as a starting point for more targeted recommendations in the future.
- Recommend cases in the sub-specialties they are weakest in, based on the cases they have previously done: Through our model, we aim to tailor instruction to individual learner's needs. By recommending students to practice on topics they are weaker in, we believe that the medical students will be able to learn in a more holistic manner.
Professor Recommendation Model
For Professors, knowing which areas students are commonly weak in will assist them in their course planning. We would like to encourage Professors to upload more cases on the students' weaker topics. The recommendation model is guided by the following principles:
- The recommended sub-specialties are based on the overall cohort performances.
- Recommend sub-specialties with the least number of cases if there is insufficient data to determine the weaker topics: Professors will not be able to gauge students' performances in areas where there are no cases for students to try. The model will encourage them to upload cases in those sub-specialties, so that they can get a more accurate idea of the students' weaknesses.
- Recommend sub-specialties where the number of pending cases is above a certain threshold: Doing so will encourage Professors to vet the pending cases, which will increase the number of cases for students to practice on.
Quality of product
Intermediate Deliverables:
Stage | Specification |
---|---|
Project Management | Schedule |
Minutes | |
Bug metrics | |
Task metrics | |
Risk management | |
Change management | |
Requirements | Overview |
Scope | |
Personas | |
Analysis | Use case diagram |
Architecture diagram | |
Technologies used | |
Design | Prototypes |
Testing | User Acceptance Test 1 (11 - 13 Feb 2018) |
User Acceptance Test 2 (4 - 10 Apr 2018) |
Testing:
- Creation of test cases during development.
- Functionality testing after completion of function.
- Regression testing at the end of every iteration.
- 2 UATs completed by Final Presentation.
- 1 UAT has been completed after Midterms. To view the results of this UAT, click here.
Reflections
Team Reflection:
Throughout our FYP journey, we have tried our best to implement the changes that our clients have requested, even if it meant additional coding hours or having to rework the project schedule multiple times. This is because we place emphasis on our project's value to the clients. However, as we approach the completion of our project, we had to scrutinize every change more closely. We had to find a balance between providing the best value to the clients, as well as our workload and confidence of completing the project in time.
Individual Reflections:
Amelia:
Our stakeholders have been actively involved in our project right from the start. Apart from meeting our supervisor regularly, we have been in constant communication with our other stakeholders. Working with a team of 17 entails certain challenges. I have learnt to manage different perspectives and expectations, as well as balance the workload and priorities of my team.
Chin Rui:
It has been a challenging journey technically. The application architecture has undergone multiple major changes, especially our security configurations, to ensure better quality and continuity for our clients. I have also discovered the difficulties in planning a software architecture after taking into account budget, skill and technical constrains.
Ervin:
As the Quality Assurance lead, I had to scrutinize every single corner case in the application, and constantly come up with more test cases. After our midterm presentation we conducted regression testing, a User Acceptance Test and load testing. I learnt that observing users during the UAT is imperative, as some users tend to not notice certain issues, or they do not voice them out. The UAT is also an opportunity for us to see if the functions are indeed useful for the users.
Ming Rui:
After our Midterm presentation, we completely changed the UI of our application. We went back to the paper and Axure prototypes, and thought of ways to improve the user experience. The final designs are a product of multiple revamps, each better compared to the previous. I have learnt the importance of gathering feedback from a larger group of users, instead of just the Medsense team from NUS.
Qimin:
Due to the various changes we have made over the course of our project, we had to do some refactoring. I have learnt that regardless of the time and effort we put into getting the schema right at the start of the project, changes are inevitable during the development process. Being the Full-Stack Support has definitely challenged me to improve my technical skills and resilience as I dealt with the bug infestation that came with the refactoring.
Ricky:
As a backend developer, I have realised that is important to have a seamless integration of the frontend components with the server side logic as well as designing and implementing data storage solutions. It has been a great experience being the technical lead, and I am glad that I could help my team members with the technical issues they faced.