HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki:2017T2 Zenith Midterm Wiki"

From IS480
Jump to navigation Jump to search
 
(48 intermediate revisions by 2 users not shown)
Line 41: Line 41:
 
==Project Progress Summary==
 
==Project Progress Summary==
 
===Midterm Slides===
 
===Midterm Slides===
(insert link here)
+
[[Media:Zenith_Midterm_slides.pdf‎|Zenith Midterm Slides]]
  
 
===Deployed site link===
 
===Deployed site link===
View our web application [http://www.themedsense.com here]!
+
<center>
 +
[[Image: Zenith deployment link.jpeg |600px|link=http://www.themedsense.com]]
 +
</center>
  
 
===Project Highlights===
 
===Project Highlights===
 
+
<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 9th iteration.  
+
* We are currently on our 9th iteration (12 Feb - 25 Feb 2018).
* Up till (date), we have completed (percentage)% of our development progress.  
+
* Up till 20 Feb 2018, we have completed <b>80.56</b>% of our development progress.  
* 1 user testing was conducted before midterms. The results are shown [[IS480_Team_wiki:2017T2 Zenith User Testing 1|here]].  
+
* 1 User Acceptance Test was conducted before Midterms. The results are shown [[IS480_Team_wiki:2017T2 Zenith User Testing 1|here]].
 +
* Achieved and exceeded [[IS480_Team_wiki:2017T2 Zenith_x-factor|Midterms X-factor]].  
  
  
 
Unexpected events:
 
Unexpected events:
* New team of clients  
+
* New team of clients.
* List of requirement changes can be viewed [[IS480_Team_wiki:2017T2_Zenith_change_management| here]].
+
* Cancellation of one User Acceptance Test by clients due to busy schedules.
 +
* List of requirement changes after Acceptance can be viewed [[IS480_Team_wiki:2017T2_Zenith_change_management#Change log (till Midterms)| here]].
 +
</div>
  
 
==Project Management==
 
==Project Management==
 +
<div style="font-family: Verdana;">
 +
<b>Iteration Progress:</b> 9 of 13<br/>
 +
<b>Features Completion:</b> 80.56% (29 out of 36 features)<br/>
 +
<b>Confidence Level:</b> 100%
 +
</div>
  
 +
===Project Status:===
  
===Project Status:===
+
<div style="font-family: Verdana;">
[[File:Zenith_midterm_scope.png|center|1000px]]
+
A breakdown of tasks is shown in our [[IS480_Team_wiki:2017T2 Zenith_project_scope|project scope]].
 +
</div>
 
<br>
 
<br>
 +
[[File:Zenith_midterm_scope.png|center|800px]]
 
<br>
 
<br>
  
 
===Project Schedule (Plan Vs Actual):===
 
===Project Schedule (Plan Vs Actual):===
  
 +
====Milestones Overview:====
 +
<div style="font-family: Verdana;">
 +
<center>
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Planned!! Actual
+
! Planned (Acceptance) !! Actual (Midterms)
 
|-
 
|-
 
|
 
|
[[File:Zenith_midterm_expected_schedule.png|500px]]
+
[[File:Zenith_midterm_planned_timeline.png|500px]]
 
  ||  
 
  ||  
[[File:Zenith_midterm_actual_schedule.png|500px]]
+
[[File:Zenith_midterm_actual_timeline.png|500px]]
 
|}
 
|}
 +
</center>
 +
</div>
 +
 +
====Project Schedule:====
 +
<div style="font-family: Verdana;">
 +
Planned Schedule (Acceptance)<br> <br>
 +
[[File:Zenith_midterm_expected_schedule.png|center|900px]]
  
 +
<br><br>
  
Major changes:  
+
Changes in planned schedule (Acceptance)<br> <br>
*Removal of UAT 1 at client's request. Client is unable to get NUS medical students for the user testing as it coincides with their exam period.  
+
[[File:Zenith_midterm_changed_schedule.png|center|900px]]
  
<br>
 
View our detailed schedule [[IS480 Team wiki: 2017T2_Zenith_Management| here]]!
 
 
<br><br>
 
<br><br>
 +
 +
Actual Schedule (Midterms)<br> <br>
 +
[[File:Zenith_midterm_actual_schedule.png|center|900px]]
 +
</div>
  
 
===Project Metrics:===
 
===Project Metrics:===
  
Summary of analysis for the metrics collected. You may refer to another page for the details about the metrics and how it is collected.
+
====Task metric====
 +
<div style="font-family: Verdana;">
 +
[[File:Zenith_midterms_task_metric.png|center|600px]]
 +
 
 +
<!--Task Metric Table Start-->
 +
{| class="wikitable" style=" background-color:#FFFFFF; width: 1000px"|+ '''Cells left-aligned, table centered'''
 +
|-
 +
 
 +
! style="color:#ecf0f1; background-color:#404040;" width="50pt" | Score
 +
|style="text-align: center;" width="20%" | TM <= 50
 +
|style="text-align: center;" width="20%" | 50 < TM <= 75
 +
|style="text-align: center;" width="20%" | 75 < TM <= 125
 +
|style="text-align: center;" width="20%" | 125 < TM <= 150
 +
|style="text-align: center;" width="20%" | 150 > TM
 +
|-
 +
 
 +
! style="color:#ecf0f1; background-color:#404040;" | Action
 +
|style="text-align: left;vertical-align: top"| 1. Inform supervisor within 24 hours. <br>  2. Re-estimate tasks for future iterations. <br>  3. Consider dropping Tasks.
 +
|style="text-align: left;vertical-align: top"| 1. Re-estimate tasks for future iterations. <br> 2. Deduct number of days behind from buffer days. <br>  3. If there are no more buffer days, decide the functionalities to drop.
 +
|style="text-align: left;vertical-align: top"| 1. Our estimates are fairly accurate, and are roughly on track. <br> 2. Add/deduct number of days ahead / behind from buffer days.
 +
|style="text-align: left;vertical-align: top"| 1. Re-estimate tasks for future iterations.  <br> 2. Add number of days ahead to buffer days.
 +
|style="text-align: left;vertical-align: top"| 1. Inform supervisor within 24 hours.  <br> 2. Re-estimate tasks for future iterations.
 +
|-
 +
|}
 +
<!--Task Metric Table End-->
 +
</div>
 +
 
 +
====Bug metric====
 +
<div style="font-family: Verdana;">
 +
 
 +
[[File:Zenith_midterm_bug_count.png|center|600px]]<br>
 +
[[File: Zenith_midterm_bug_score.png|center|600px]]
 +
 
 +
<center><b>Note:</b> There were no coding tasks for iteration 1. </center>
 +
 
 +
 
 +
<!--Bug Score Table Start-->
 +
{| class="wikitable" style="font-family:Garamond; background-color:#FFFFFF; width: 500px"|+ '''Cells left-aligned, table centered'''
 +
|-
 +
 
 +
! style="color:#ecf0f1; background-color:#404040;" width="10%" | Severity
 +
|style="text-align: center;" width="30%" | Low Impact
 +
|style="text-align: center;" width="30%" | High Impact
 +
|style="text-align: center;" width="30%"| Critical Impact
 +
|-
 +
 
 +
! style="color:#ecf0f1; background-color:#404040;" | Description
 +
|style="text-align: left;vertical-align: top"| 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.
 +
|style="text-align: left;vertical-align: top"| The system is functional with some non-critical functionalities are not working.
 +
|style="text-align: left;vertical-align: top"| The system is not functional.  
 +
Bugs have to be fixed before proceeding.
 +
|-
 +
|}
 +
<!--Bug Score Table End-->
 +
 
 +
 
 +
<!--Bug Metric Table Start-->
 +
{| class="wikitable" style="font-family:Garamond; background-color:#FFFFFF; width: 500px"|+ '''Cells left-aligned, table centered'''
 +
|-
 +
 
 +
! style="color:#ecf0f1; background-color:#404040;" width="10%" | Points
 +
|style="text-align: center;" width="30%" | BM <= 5
 +
|style="text-align: center;" width="30%" | 5 < BM < 10
 +
|style="text-align: center;" width="30%"| BM >= 10
 +
|-
 +
 
 +
! style="color:#ecf0f1; background-color:#404040;" | Description
 +
|style="text-align: left;vertical-align: top"| The system does not need immediate fixing, could be fixed during buffer time or during coding sessions
 +
|style="text-align: left;vertical-align: top"| Coders to use planned debugging time in the iteration to solve the bug
 +
|style="text-align: left;vertical-align: top"| The team has to stop all current development and resolve the bug immediately
 +
|-
 +
|}
 +
<!--Bug Metric Table End-->
 +
</div>
 +
 
 +
 
 +
<br>
  
 
===Project Risks:===
 
===Project Risks:===
 +
<div style="font-family: Verdana;">
  
Update the proposal assumptions and risks. Describe what you learn from the risk update and mitigation steps taken.  
+
[[File:Zenith risk metric.png|center|600px]]
  
Be sure to prioritize the risks.
+
{| class="wikitable" style="font-family:Garamond; background-color:#FFFFFF; width: 1000px"|+ '''Cells left-aligned, table centered'''
 +
|-
 +
 
 +
! style="color:#ecf0f1; background-color:#404040;" width="50pt" | S/N
 +
! style="color:#ecf0f1; background-color:#404040;" width="100pt" | Risk Type
 +
! style="color:#ecf0f1; background-color:#404040;" width="275pt" | Description
 +
! style="color:#ecf0f1; background-color:#404040;" width="100pt" | Likelihood
 +
! style="color:#ecf0f1; background-color:#404040;" width="100pt" | Impact Level
 +
! style="color:#ecf0f1; background-color:#404040;" width="100pt" | Threat Level
 +
! style="color:#ecf0f1; background-color:#404040;" width="275pt" | Mitigation Plan
 +
|-
 +
 
 +
|style="text-align: center;"| 1
 +
|style="text-align: center;"| Technical
 +
|style="text-align: left;vertical-align: center"| Ransomware attacks on Database
 +
|style="text-align: center;"| Low (but it happened)
 +
|style="text-align: center;"| High
 +
|style="text-align: center;"| B
 +
|style="text-align: left;vertical-align: top"| System Architect to improve database security 
 +
|-
 +
 
 +
|style="text-align: center;"| 2
 +
|style="text-align: center;"| Organizational
 +
|style="text-align: left;vertical-align: center"| New members in NUS MedSense Team
 +
|style="text-align: center;"| Medium
 +
|style="text-align: center;"| Medium
 +
|style="text-align: center;"| B
 +
|style="text-align: left;vertical-align: center"| Project Manager will be in constant communication with new members, and will regularly review the scope with them.
 +
|-
 +
 
 +
|style="text-align: center;"| 3
 +
|style="text-align: center;"| Project Management
 +
|style="text-align: left;vertical-align: center"| Members falling sick or going overseas doing school period, reducing team's available manpower. This can cause a potential delays in the project
 +
|style="text-align: center;"| Medium
 +
|style="text-align: center;"| Medium
 +
|style="text-align: center;"| B
 +
|style="text-align: left;vertical-align: center"| Team members should constantly check on the health and well-being of one another, as well as update the Project Manager of any overseas plans as early as possible
 +
|-
 +
|}
 +
<br>
 +
</div>
 +
<br>
  
 
===Technical Complexity:===
 
===Technical Complexity:===
 +
 
====Natural Language Processing====
 
====Natural Language Processing====
Natural Language Processing (NLP) was used for the automated marking of open-ended questions.  
+
<div style="font-family: Verdana;">
 +
Natural Language Processing, or NLP for short, is broadly defined as the automatic manipulation of natural language, like speech and text, by software. The study of natural language processing has been around for more than 50 years and grew out of the field of linguistics with the rise of computers.
 +
 
 +
Our team decided to employ NLP techniques to perform automated marking for open ended questions. This benefits the user as professors do not need to mark each answer and students can receive immediate feedback with regards to their answers.
 +
 
 +
Below are some of the techniques used:
 +
 
 +
<b>Tokenization</b>
 +
 
 +
Given a character sequence and a defined document unit, tokenization is the task of chopping it up into pieces, called tokens , perhaps at the same time throwing away certain characters, such as punctuation.
 +
 
 +
[[Image:Zenith tokenization.PNG|center|600px|link=]]
 +
<center><b>An example of tokenization. Library used: Natural for Nodejs</b> https://github.com/NaturalNode/natural#tokenizers</center>
 +
 
 +
<b>Removing Stopwords</b>
 +
 
 +
Sometimes, some extremely common words which would appear to be of little value in helping select documents matching a user need are excluded from the vocabulary entirely. In natural language processing, Stopwords are words that are so frequent that they can safely be removed from a text without altering its meaning. Hence, for automated marking, we removed all common words from the submitted answer. Doing this significantly reduces the number of tokens our system has to match and store.
 +
 
 +
 
 +
[[Image:Zenith stopwords.png|center|500px|link=]]
 +
<b><center>An example of a stop list of 25 semantically non-selective words</center></b>
 +
 
 +
<b>Stemming</b>
 +
 
 +
For grammatical reasons, answers are going to use different forms of a word, such as organize, organizes, and organizing. Additionally, there are families of derivationally related words with similar meanings, such as democracy, democratic, and democratization. In these situations, we have to treat these words to be the same, as they have the same root meaning.
 +
 
 +
The goal of both stemming is to reduce inflectional forms and sometimes derivationally related forms of a word to a common base form.
 +
 
 +
We decided to use the Porter Stemming Algorithm (https://tartarus.org/martin/PorterStemmer/index.html) as it is the most popular algorithm for stemming English and has shown to be empirically very effective.
 +
 
 +
Porter's algorithm consists of 5 phases of word reductions, applied sequentially. Within each phase there are various conventions to select rules, such as selecting the rule from each rule group that applies to the longest suffix.
 +
 
 +
[[Image:Zenith stemming.png|center|500px|link=]]
 +
<b><center>Example of a rule in the Porter Stemming Algorithm</center></b>
 +
</div>
 +
<br>
 +
 
 +
====Game development ====
 +
<div style="font-family: Verdana;">
 +
Together with the NUS team, we developed a few basic game rules.
 +
 
 +
<b>Leveling System</b>
 +
 
 +
For our application, we introduce a leveling system for student. In its simplest form, leveling up occurs through the process of gaining enough experience points until a target experience point total is reached. Once the target is met, the student's character "levels up," and a new target experience threshold is set. Students gains experience points (XP) by attempting a medical case. The amount of XP is dependent on how well the student scores.
 +
 
 +
Currently, the main selling point of the medical cases is to practice for their exams. By introducing the leveling system, we hope to further incentivise students to attempt  medical cases on our application.  The idea is to ensure that students will be playing the cases throughout the year rather than just during peak (exam) periods.
 +
[[Image:Zenith leveling formula.PNG|center|300px|link=]]
 +
<b><center>Formula for calculating Level</center></b>
 +
 
 +
<b>Anti Cheat Mechanism for MCQ Scoring</b>
 +
 
 +
There can be more than one correct answer for each MCQ questions. Hence we use multi-select MCQ questions in our game. However, the problem we face is that students can simply tick all the options to get the correct answer. Hence, we developed a rule that penalizes the student for every wrong option selected.
 +
 
 +
<b>Anti Cheat Mechanism for Repeating Cases</b>
 +
 
 +
Another rule we developed is to halve the total amount of experience points gained for each subsequent game play of the same case. This is to reduce the incentive of repeating the same case again and again for the sake of leveling up. Furthermore, students are already expected to score better after doing the case, as the answers are revealed at the end of each case.
 +
 
 +
</div>
 +
<br>
  
 
====Added security features====
 
====Added security features====
 +
<div style="font-family: Verdana;">
 
In December 2017, our MongoDB database was compromised and held hostage by ransomware. We were instructed to pay 0.1 bitcoin (USD $1594) for the return of our data. Fortunately, we had backed up the data so there was no need for us to pay the ransom. Since this incident, we have taken additional measures to ensure that this does not happen again.
 
In December 2017, our MongoDB database was compromised and held hostage by ransomware. We were instructed to pay 0.1 bitcoin (USD $1594) for the return of our data. Fortunately, we had backed up the data so there was no need for us to pay the ransom. Since this incident, we have taken additional measures to ensure that this does not happen again.
 +
 +
 +
We have implemented / will be implementing the following:
 +
*Firewall
 +
*SSH Tunnel
 +
*Automated backup
 +
*HTTPS protocol
 +
*Encrypt environment variables
 +
</div>
  
 
==Quality of product==
 
==Quality of product==
  
Provide more details about the quality of your work. For example, you designed a flexible configurable system using XML.config files, uses Strategy Design Pattern to allow plugging in different strategy, implement a regular expression parser to map a flexible formula editor, etc.
+
===Intermediate Deliverables:===
 +
 
 +
<div style="font-family: Verdana;">
 +
<center>
 +
{| class="wikitable" style="font-family:Verdana; background-color:#FFFFFF; width: 600px;" align="center"
 +
 
 +
! style="color:#ecf0f1; background-color:#565656;" width="300pt" | Stage
 +
! style="color:#ecf0f1; background-color:#565656;" width="400pt" | Specification
 +
|-
  
===Intermediate Deliverables:===
+
|rowspan="6"| Project Management
 +
|| [[IS480 Team wiki: 2017T2_Zenith_Management|Schedule]]
 +
|-
 +
|| [[IS480_Team_wiki:2017T2 Zenith_minutes|Minutes]]
 +
|-
 +
|| [[IS480_Team_wiki:2017T2 Zenith_metrics#Bug Metric|Bug metrics]]
 +
|-
 +
|| [[IS480_Team_wiki:2017T2 Zenith_metrics#Task Metric|Task metrics]]
 +
|-
 +
|| [[IS480_Team_wiki:2017T2 Zenith_risk_management|Risk management]]
 +
|-
 +
|| [[IS480_Team_wiki:2017T2 Zenith_change_management|Change management]]
 +
|-
 +
 
 +
 
 +
|rowspan="3"| Requirements
 +
|| [[IS480 Team wiki: 2017T2 Zenith Overview | Overview]]
 +
|-
 +
|| [[IS480_Team_wiki:2017T2 Zenith_project_scope | Scope]]
 +
|-
 +
|| [[IS480 Team wiki: 2017T2_Zenith_Documentation | Personas]]
 +
|-
  
There should be some evidence of work in progress. 
+
|rowspan="3"| Analysis
 +
|| [[IS480_Team_wiki:2017T2 Zenith_diagrams#Use Case Diagram | Use case diagram]]
 +
|-
 +
|| [[IS480_Team_wiki:2017T2 Zenith_diagrams#Architecture Diagram | Architecture diagram]]
 +
|-
 +
|| [[IS480_Team_wiki:2017T2 Zenith_technologies| Technologies used]]
 +
|-
  
Not all parts of the deliverables are necessary but the evidence should be convincing of the progress. Try to include design deliverables that shows the quality of your project.
 
  
===Deployment:===
+
|rowspan="1"| Design
 +
|| [[IS480_Team_wiki:2017T2 Zenith_prototype |Prototypes]]
 +
|-
  
In an iterative approach, ready to use system should be available (deployed) for client and instructions to access the system described here (user name). If necessary, provide a [[IS480_Final_Wiki#Project_Deliverables: | deployment diagram link]].
+
|rowspan="1"| Testing
 +
|| [[IS480_Team_wiki:2017T2 Zenith User Testing 1 |User Acceptance Test 1 (11 - 13 Feb 2018)]]
 +
|-
 +
|}
 +
</center>
 +
</div>
  
 
===Testing:===
 
===Testing:===
  
Describe the testing done on your system. For example, the number of user testing, tester profile, test cases, survey results, issue tracker, bug reports, etc.
+
<div style="font-family: Verdana;">
  
==Reflection==
+
*Creation of test cases during development.
 +
*Functionality testing after completion of function.
 +
*Regression testing at the end of every iteration.
 +
*We expect to complete 2 UATs by the end of the project.
 +
*1 UAT has been completed before Midterms. To view the results of this UAT, [[IS480_Team_wiki:2017T2 Zenith User Testing 1|click here]]. 
  
In this section, describe what have the team learn? Be brief. Sometimes, the client writes a report to feedback on the system; this sponsor report can be included or linked from here.
+
</div>
 +
 
 +
==Reflections==
  
 
===Team Reflection:===
 
===Team Reflection:===
 +
<div style="font-family: Verdana;">
 +
 +
Our team has learnt the importance of working together closely with our clients, to ensure an ideal alignment between the client business requirements and our end-product. Throughout our development process, we are constantly plagued with minor hiccups and bugs. However, our team feels that our most valuable quality is resilience, as we tackle each and every problem with our ineffable tenacity and innovation.
 +
</div>
 +
 +
=== Individual Reflections: ===
 +
<div style="font-family: Verdana;">
 +
<b>Amelia: </b>
 +
 +
It has been a very experimental journey managing the team since the project started. New challenges are always popping up, and I have learnt to manage the workload of each member more carefully. I believe communication is today’s important skill, be it raising issues with the team or simple dissemination of information. That is why I ensure that there are no communication lapses in our team.
 +
<br>
 +
 +
<b>Chin Rui: </b>
 +
 +
It has been a challenging 7 weeks since our acceptance. The application architecture has undergone multiple major changes, especially our security configrations, to ensure better quality and continuity for our clients. The security breach incident was an eye-opening experience for me, and I have learnt to never take security for granted. I have realised that security should be a key consideration when planning an application's architecture because every implementation or change made could introduce a new vulnerability for potential attackers to take advantage of. Aside from the security enhancements, I have also discovered the difficulties in planning a software architecture after taking into account of budget, skill and technical constrains.
 +
<br>
 +
 +
<b>Ervin: </b>
 +
 +
Being the previous Business Analyst, it was an enriching and mind-boggling experience researching on various Natural Language Processing techniques and trying to appraise their adequacy and appropriateness for our application. Moving on as the Quality Assurance lead, I hope I do not offend everyone involved in development by scrutinizing every single corner case in the application.
 +
<br>
 +
 +
<b>Ming Rui: </b>
  
Any training and lesson learn? What are the take-away so far? It would be very convincing if the knowledge is share at the wiki [[Knowledge_base | knowledge base]] and linked here.
+
The opportunity to be able to apply the entire design thinking process from the creation of prototypes to the actual web development have been arduous but rewarding journey. The final designs of the application are a product of multiple revamps, each better compared to the previous. I have learnt the importance of gathering feedback from the clients as well as real users.
 +
<br>
  
===Benjamin Gan Reflection:===
+
<b>Qimin: </b>
  
You may include individual reflection if that make sense at this point. The team is uncooperative and did not follow my instructions.
+
Having to pick up Node.js and React.js in a short period of time really pushed me to learn and adapt at a much faster pace. There are many front-end and back-end considerations to factor in during the design process, such as the communication between parent-child components and the use of redux store versus a direct http request to the database. I believe that my technical skills have definitely improved over the past few weeks.
 +
<br>
 +
 
 +
<b>Ricky: </b>
 +
 
 +
It has been a great experience seeing how the project has grown from infancy to where it is today. 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. Throughout the past few months working on the project, I have learnt that what’s even more important than completing the work assigned to me is to help my team members with their tasks. This will enable smoother and faster progression as a team.
 +
<br>
 +
<div>

Latest revision as of 15:37, 23 February 2018

Zenith banner.png

Home

Team

Project Overview

Project Management

Documentation

Main Wiki

Midterm Wiki Final Wiki


Zenith midterm header.PNG


Project Progress Summary

Midterm Slides

Zenith Midterm Slides

Deployed site link

Zenith deployment link.jpeg

Project Highlights

Our project schedule is divided into 13 iterations.

  • We are currently on our 9th iteration (12 Feb - 25 Feb 2018).
  • Up till 20 Feb 2018, we have completed 80.56% of our development progress.
  • 1 User Acceptance Test was conducted before Midterms. The results are shown here.
  • Achieved and exceeded Midterms X-factor.


Unexpected events:

  • New team of clients.
  • Cancellation of one User Acceptance Test by clients due to busy schedules.
  • List of requirement changes after Acceptance can be viewed here.

Project Management

Iteration Progress: 9 of 13
Features Completion: 80.56% (29 out of 36 features)
Confidence Level: 100%

Project Status:

A breakdown of tasks is shown in our project scope.


Zenith midterm scope.png


Project Schedule (Plan Vs Actual):

Milestones Overview:

Planned (Acceptance) Actual (Midterms)

Zenith midterm planned timeline.png

Zenith midterm actual timeline.png

Project Schedule:

Planned Schedule (Acceptance)

Zenith midterm expected schedule.png



Changes in planned schedule (Acceptance)

Zenith midterm changed schedule.png



Actual Schedule (Midterms)

Zenith midterm actual schedule.png

Project Metrics:

Task metric

Zenith midterms task metric.png
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

Zenith midterm bug count.png

Zenith midterm bug score.png
Note: There were no coding tasks for iteration 1.


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:

Zenith risk metric.png
S/N Risk Type Description Likelihood Impact Level Threat Level Mitigation Plan
1 Technical Ransomware attacks on Database Low (but it happened) High B System Architect to improve database security
2 Organizational New members in NUS MedSense Team Medium Medium B Project Manager will be in constant communication with new members, and will regularly review the scope with them.
3 Project Management Members falling sick or going overseas doing school period, reducing team's available manpower. This can cause a potential delays in the project Medium Medium B Team members should constantly check on the health and well-being of one another, as well as update the Project Manager of any overseas plans as early as possible



Technical Complexity:

Natural Language Processing

Natural Language Processing, or NLP for short, is broadly defined as the automatic manipulation of natural language, like speech and text, by software. The study of natural language processing has been around for more than 50 years and grew out of the field of linguistics with the rise of computers.

Our team decided to employ NLP techniques to perform automated marking for open ended questions. This benefits the user as professors do not need to mark each answer and students can receive immediate feedback with regards to their answers.

Below are some of the techniques used:

Tokenization

Given a character sequence and a defined document unit, tokenization is the task of chopping it up into pieces, called tokens , perhaps at the same time throwing away certain characters, such as punctuation.

Zenith tokenization.PNG
An example of tokenization. Library used: Natural for Nodejs https://github.com/NaturalNode/natural#tokenizers

Removing Stopwords

Sometimes, some extremely common words which would appear to be of little value in helping select documents matching a user need are excluded from the vocabulary entirely. In natural language processing, Stopwords are words that are so frequent that they can safely be removed from a text without altering its meaning. Hence, for automated marking, we removed all common words from the submitted answer. Doing this significantly reduces the number of tokens our system has to match and store.


Zenith stopwords.png
An example of a stop list of 25 semantically non-selective words

Stemming

For grammatical reasons, answers are going to use different forms of a word, such as organize, organizes, and organizing. Additionally, there are families of derivationally related words with similar meanings, such as democracy, democratic, and democratization. In these situations, we have to treat these words to be the same, as they have the same root meaning.

The goal of both stemming is to reduce inflectional forms and sometimes derivationally related forms of a word to a common base form.

We decided to use the Porter Stemming Algorithm (https://tartarus.org/martin/PorterStemmer/index.html) as it is the most popular algorithm for stemming English and has shown to be empirically very effective.

Porter's algorithm consists of 5 phases of word reductions, applied sequentially. Within each phase there are various conventions to select rules, such as selecting the rule from each rule group that applies to the longest suffix.

Zenith stemming.png
Example of a rule in the Porter Stemming Algorithm


Game development

Together with the NUS team, we developed a few basic game rules.

Leveling System

For our application, we introduce a leveling system for student. In its simplest form, leveling up occurs through the process of gaining enough experience points until a target experience point total is reached. Once the target is met, the student's character "levels up," and a new target experience threshold is set. Students gains experience points (XP) by attempting a medical case. The amount of XP is dependent on how well the student scores.

Currently, the main selling point of the medical cases is to practice for their exams. By introducing the leveling system, we hope to further incentivise students to attempt medical cases on our application. The idea is to ensure that students will be playing the cases throughout the year rather than just during peak (exam) periods.

Zenith leveling formula.PNG
Formula for calculating Level

Anti Cheat Mechanism for MCQ Scoring

There can be more than one correct answer for each MCQ questions. Hence we use multi-select MCQ questions in our game. However, the problem we face is that students can simply tick all the options to get the correct answer. Hence, we developed a rule that penalizes the student for every wrong option selected.

Anti Cheat Mechanism for Repeating Cases

Another rule we developed is to halve the total amount of experience points gained for each subsequent game play of the same case. This is to reduce the incentive of repeating the same case again and again for the sake of leveling up. Furthermore, students are already expected to score better after doing the case, as the answers are revealed at the end of each case.


Added security features

In December 2017, our MongoDB database was compromised and held hostage by ransomware. We were instructed to pay 0.1 bitcoin (USD $1594) for the return of our data. Fortunately, we had backed up the data so there was no need for us to pay the ransom. Since this incident, we have taken additional measures to ensure that this does not happen again.


We have implemented / will be implementing the following:

  • Firewall
  • SSH Tunnel
  • Automated backup
  • HTTPS protocol
  • Encrypt environment variables

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)

Testing:

  • Creation of test cases during development.
  • Functionality testing after completion of function.
  • Regression testing at the end of every iteration.
  • We expect to complete 2 UATs by the end of the project.
  • 1 UAT has been completed before Midterms. To view the results of this UAT, click here.

Reflections

Team Reflection:

Our team has learnt the importance of working together closely with our clients, to ensure an ideal alignment between the client business requirements and our end-product. Throughout our development process, we are constantly plagued with minor hiccups and bugs. However, our team feels that our most valuable quality is resilience, as we tackle each and every problem with our ineffable tenacity and innovation.

Individual Reflections:

Amelia:

It has been a very experimental journey managing the team since the project started. New challenges are always popping up, and I have learnt to manage the workload of each member more carefully. I believe communication is today’s important skill, be it raising issues with the team or simple dissemination of information. That is why I ensure that there are no communication lapses in our team.

Chin Rui:

It has been a challenging 7 weeks since our acceptance. The application architecture has undergone multiple major changes, especially our security configrations, to ensure better quality and continuity for our clients. The security breach incident was an eye-opening experience for me, and I have learnt to never take security for granted. I have realised that security should be a key consideration when planning an application's architecture because every implementation or change made could introduce a new vulnerability for potential attackers to take advantage of. Aside from the security enhancements, I have also discovered the difficulties in planning a software architecture after taking into account of budget, skill and technical constrains.

Ervin:

Being the previous Business Analyst, it was an enriching and mind-boggling experience researching on various Natural Language Processing techniques and trying to appraise their adequacy and appropriateness for our application. Moving on as the Quality Assurance lead, I hope I do not offend everyone involved in development by scrutinizing every single corner case in the application.

Ming Rui:

The opportunity to be able to apply the entire design thinking process from the creation of prototypes to the actual web development have been arduous but rewarding journey. The final designs of the application are a product of multiple revamps, each better compared to the previous. I have learnt the importance of gathering feedback from the clients as well as real users.

Qimin:

Having to pick up Node.js and React.js in a short period of time really pushed me to learn and adapt at a much faster pace. There are many front-end and back-end considerations to factor in during the design process, such as the communication between parent-child components and the use of redux store versus a direct http request to the database. I believe that my technical skills have definitely improved over the past few weeks.

Ricky:

It has been a great experience seeing how the project has grown from infancy to where it is today. 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. Throughout the past few months working on the project, I have learnt that what’s even more important than completing the work assigned to me is to help my team members with their tasks. This will enable smoother and faster progression as a team.