Difference between revisions of "IS480 Team wiki:2017T2 Zenith Midterm Wiki"
(mid term risk) |
m |
||
Line 195: | Line 195: | ||
===Project Risks:=== | ===Project Risks:=== | ||
<div style="font-family: Verdana;"> | <div style="font-family: Verdana;"> | ||
− | |||
− | |||
− | |||
[[File:Zenith risk metric.png|center|600px]] | [[File:Zenith risk metric.png|center|600px]] |
Revision as of 11:48, 21 February 2018
Midterm Wiki | Final Wiki |
Project Progress Summary
Midterm Slides
(insert link here)
Deployed site link
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.
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 | 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 | External | Future developers unfamiliar with technologies used | Medium | Medium | B | Provide proper documentation such as deployment guide and include comments in the codes. |
4 | 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 | Low | Medium | C | 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.
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.
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.
Game development
Together with the NUS team, we developed a few basic game rules.
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.
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:
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 and linked here.
Individual Reflections:
Amelia:
Chin Rui:
Ervin:
Ming Rui:
Qimin:
Ricky: