Difference between revisions of "IS480 Team wiki: 2015T2 Starteur Midterm Wiki"
Line 272: | Line 272: | ||
==Deliverables== | ==Deliverables== | ||
+ | |||
+ | {| class="wikitable" border="1" | ||
+ | |- style="background:#35404f; color:white" | ||
+ | ! style="text-align: center; bold;background: #00cdcd;color:white; width:20px; border:1px solid #999" | Stage | ||
+ | ! style="text-align: center; bold;background: #00cdcd;color:white; width:20px; border:1px solid #999" | Specification | ||
+ | ! style="text-align: center; bold;background: #00cdcd;color:white; width:20px; border:1px solid #999" | Module | ||
+ | |- | ||
+ | |rowspan="7"| Project Management | ||
+ | |||
+ | || Minutes | ||
+ | || [[IS480 Team wiki: 2015T2 Starteur Project Meeting Minutes| Meeting Minutes]] | ||
+ | |- | ||
+ | || Project Schedule | ||
+ | || [[IS480 Team wiki: 2015T2 Starteur Project Schedule|Project Schedule]] | ||
+ | |- | ||
+ | || Project Scope | ||
+ | || [[IS480 Team wiki: 2015T2 Starteur Project Scope|Project Scope]] | ||
+ | |- | ||
+ | |rowspan="2"| Metrics | ||
+ | || [[IS480 Team wiki: 2015T2 Starteur Project Schedule Metrics|Schedule Metrics]] | ||
+ | |- | ||
+ | || [[IS480 Team wiki: 2015T2 Starteur Project Bug Metrics|Bug Metrics]] | ||
+ | |- | ||
+ | || Risks & Mitigations | ||
+ | || [[IS480 Team wiki: 2015T2 Starteur Project Risk Management|Risk Management]] | ||
+ | |- | ||
+ | || Client & End-user Change Requests | ||
+ | || [[IS480 Team wiki: 2015T2 Starteur Project Change Management|Change Management]] | ||
+ | |- | ||
+ | |||
+ | |- | ||
+ | |rowspan="3"| Analysis | ||
+ | |rowspan="2"| Diagrams | ||
+ | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2015T2_Starteur_Project_Use_Cases Use-case Diagram] | ||
+ | |- | ||
+ | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2015T2_Starteur_Project_Technical_Diagrams ER Diagram] | ||
+ | |- | ||
+ | || Market Research | ||
+ | || [[IS480 Team wiki: 2015T2 Starteur Project Market Research|Market Research]] | ||
+ | |- | ||
+ | |||
+ | |- | ||
+ | |rowspan="1"| Design | ||
+ | ||Lo-Fidelity Prototype | ||
+ | || [[IS480 Team wiki: 2015T2 Starteur Project Design Documents|Lo-Fidelity Prototype]] | ||
+ | |- | ||
+ | |||
+ | |rowspan="2"| Testing | ||
+ | |rowspan="2"|User Test Plan and Results & Analysis | ||
+ | || inserts link to UAT 1 page | ||
+ | |- | ||
+ | || inserts link to UAT 2 page | ||
+ | |- | ||
+ | |} | ||
+ | |||
==Deployment== | ==Deployment== | ||
Deployment link here | Deployment link here |
Revision as of 19:35, 14 February 2016
Main Wiki | Midterm Wiki | Final Wiki |
---|
Contents
|
Planned | Actual |
---|---|
Major Changes
Module | Category | Change/Removal/Addition | Description | Reason for change/removal/addition |
---|---|---|---|---|
Educator Management | Primary | Change Track completion rate to Track status of access code | Instead of tracking the completion rate of the Starteur Test, we will be tracking if students have been assigned an access code to the test, used their access code and if they have completed the Starteur test. | Educators have reflected that they will need to know if their students have been assigned an access code to the test or not and if they have completed the test, so that they can send our test reminders. Knowing which part of the test the students are not, does not help them much or give them any information to work on. |
Notification | Secondary | Change of automated test reminder email to manual test reminder | Instead of the web application automatically sending out an email reminder to students who have to completed the Starteur test, according to a particular threshold (e.g. 5 days later), educators will now have to manually use the application to send out a reminder. | Educators prefer to have control over the frequency of sending out emails to their students and to control the threshold number of days. |
Group Report | Secondary | Removed Sort students in group and filter students in group | - | Educators have provided feedback during initial questionnaire that these 2 functions are of no relevance to them. They do not need to know the ranking of students as they are more broad-visioned and requires an overview of their students instead. They also prefer to see such results within the report instead. |
Payment Gateway | Secondary | Shifted View Payment History and Generate Invoice in Educator Management to Payment Gateway | - | These 2 functions will only be fully completed when 3rd party payment integration is up. As such, we have shifted them there. |
Group Report | Secondary | Added Multiple Group Report | Educators will now be able to view a report that consolidates results from more than 1 student group. | Educators have reflected that they would like to view results from student cohorts, which means that they want to be able to combine multiple student groups to see how each academic year's cohort would differ in behavior. |
Client Administrator | Tertiary | Added transfer Ownership | Administrator is able to transfer ownership of access code generated to another educator for promotion purposes. | After discussing in detail with client, team decided to implement this function to allow client to use this as a promotion too. |
View our Change Management Here!
Project Schedule
Schedule Highlights
There are no major changes to the project schedule. Functions were shifted around within the schedule due to difficulties faced at the middle of the project (Iteration 9), required inputs from Starteur developers were not provided in time. The team postponed testing for Student & Batch Report functions to after Mid Terms Presentation as User Testing 3 due to changes in project schedule. Focus of User Testing 2 was changed to Client Administrator Module, with Reactor Industries' management team as target end-users.
Project Metrics
Schedule Metrics
View our Schedule Metrics Here!
Schedule Metric Highlights
Iteration | Planned Duration/days | Actual Duration/days | Schedule Metric Score | Action | Status |
---|---|---|---|---|---|
5 | 10 | 11 | 0.91 | Our estimates are fairly accurate. Project schedule is on track. Difficulty in setting up email server for Starteur and it was exams period for SMU Term 1. As such, project was delayed. 1 buffer day used. | Completed |
9 | 14 | 11 | - | Group report module was pushed back due to client's inability to provide algorithm on time. Supervisor was informed of change in schedule. | Incomplete |
Bug Metrics
Bug Metric Highlights
Iteration | Bug Score | Summary of Bugs | Action Taken |
---|---|---|---|
2 | 2 | 2 low bugs found. Low bugs were related to displaying of individual batch page | Used the planned debugging time in the iteration. Team was able to fix all the bugs within the scheduled time. |
3 | 6 | 2 medium bugs and 2 low bugs found. Medium bugs found in functionality to purchase access codes for test. Low bugs found in displaying tests in test store for purchase | Used the planned debugging time in the iteration. Team was able to fix all the bugs within the scheduled time.
|
4 | 3 | 3 low bugs found. Low bugs found in displaying of student name in batch. | Used the planned debugging time in the iteration. Team was able to fix all the bugs within the scheduled time. |
5 | 18 | 2 high bugs found. High bugs found in functionality to send access code to students in student group. Logic to send different types of code usage to different types of students (students who have a Starteur account and students who don't). | 1 buffer day used for testing and debugging. |
8 | 10 | 2 low bugs found and 3 medium bugs found. Alignment of elements in individual student report and presenting all data on pdf generated. | 1 buffer day used for additional testing and debugging. |
9 | 6 | 6 low bugs found. Alignment of elements in group report visualization. Aesthetics. | Used the planned debugging time in the iteration. Team was able to fix all the bugs within the scheduled time. |
Project Risks
Technical Complexity
Architecture Diagram
Put architecture diagram here View our architecture diagram for deployment to production server here!
Technical Complexity 1: Handling concurrent requests and slow clients
Issue
Reasons
Outcomes
Technical Complexity 2: Patient Volume Visualization
Issue
Solution
Implementation Challenges
Implementation
Quality of Product
Deliverables
Stage | Specification | Module |
---|---|---|
Project Management | Minutes | Meeting Minutes |
Project Schedule | Project Schedule | |
Project Scope | Project Scope | |
Metrics | Schedule Metrics | |
Bug Metrics | ||
Risks & Mitigations | Risk Management | |
Client & End-user Change Requests | Change Management | |
Analysis | Diagrams | Use-case Diagram |
ER Diagram | ||
Market Research | Market Research | |
Design | Lo-Fidelity Prototype | Lo-Fidelity Prototype |
Testing | User Test Plan and Results & Analysis | inserts link to UAT 1 page |
inserts link to UAT 2 page |
Deployment
Deployment link here
Testing
User Testing 1
Locations: CHIJ St Nicholas Girls' School, SMU Admin Building, Raffles Institution
Date & Time: 1st week of December 2015
No. of Participants: 4
Objectives:
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
User Testing 2
Location: Reactor ARC
Date & Time: 13 February 2016
No. of Participants: 4
Objectives:
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
Reflections
Team's Reflections
Team Reflection
- Deeper insights of the behind-the-scenes in a learning management web application and the difficulties teachers and educators face when getting students to complete their assignments on time.
- Gained real-life experience of a commercial project from scratch
What have we done well so far?
- Focused a lot on providing convenience and ease of use to our end-users when we design and build the app
- As a result, both our client and the actual users like the product and gave us positive feedback
- Kept close and constant contact with our end-users. Resulting in most of them agreeing to be participants for our User Testings or recommending other educators to be a part of our User Testings.
What can be improved?
- Be more assertive when seeking understanding from Starteur developers when requesting for inputs and integration efforts.
- Do more in-depth research for front-end design and seek feedback from all stakeholders before moving ahead with changes.
How will we do better?
- Managing our schedule and Starteur's development schedule closely while constantly reminding everyone of the tasks at hand and ahead.
- For any design implementations that we are unsure of, must come up with a few design and seek approval and feedback from relevant stakeholders before moving ahead.