IS480 Team wiki: 2016T2 Team VI Midterm Wiki

From IS480
Jump to navigation Jump to search
Team VI Logo.PNG












Mid Terms Slides


Deployment Link

: https://is480z-lin9z.rhcloud.com/VI/

Project Highlights

  • Our team spent a large amount of time dissecting the database to fit the business rules of the enrichment centre.
  • Site went live and has been deployed to the enrichment center.
  • Our team's AWS account was being compromised and we were charged $3186.86, but we managed to gained approval for our concession.
  • Able to successfully send SMS and email notification to parents upon successfully marking student's attendance.
  • Conducted A/B Testing which gave us the go ahead to choose Version B as our user interface for parents portal.
  • Conducted 2 user testings.
  • Embarked on Gamification and Analytics for the enrichment center.


    About our Project

    Our team aims to provide a web-based student monitoring system and business analysis tool for an enrichment centre, Explore and Learn Pte Ltd. Our project also aims to engage the students through gamification and encourage learning.

    Summary of Project Progress

    Our project iteration has 15 iterations. As at 18 February 2015, we are currently in Iteration 11 of the project. We have completed 70% of our functionalities.

    Project Status

    Task/Function/Feature Status Confidence Level (0-1) Comment
    Deploy onto Digital Ocean Our application is currenly deployed on OpenShift and our team is exploring on how to deploy the application onto the DigitalOcean Server after the MId Terms. 0.9 Sponsor requested for the team to deploy the application to Digital Ocean instead of the original Amazon Web Service (AWS). This is because our sponsor has the relevant experience and it would facilitate the process of future updates of the system.

    Project Schedule

    Planned Actual
    Team VI Project Schedule.png Actualschedule.png

    Project Scope

    For Acceptance For MidTerms
    Team VI Project Scope Before.png Team VI Scope 4.0.png

    The full Change Management Log can be found here.


    Schedule Metric

    Team VI Schedule Metrics Graph.png

    Highlights of Schedule Metrics

    Iteration Planned (Days) Actual (Days) SM Score Action Status
    14 18 78% Underestimated time required, PM to re-estimate tasks for future iterations. Delayed due to bugs found. Team was unfamiliar with QR code scanning and email notification. Reduced 4 Days of Finals Break Completed
    14 20 70% Underestimated time required, PM to re-estimate tasks for future iterations. Delayed due to the database changes required to mimic the business rules, wherey timeslot is not course unique and a teacher is able to teach more than 1 courses at the same time. Use 6 buffer days. Completed

    Bug Metrics

    Bug Metrics Bug Count by Category
    Screen Shot 2016-02-14 at 2.09.58 pm.png
    Team VI Bug Count By Category.png

    Highlights of Bug Metrics

    Iteration Bug Score Number of Issues Summary of Bugs and Issues Action Taken
    20 Low Impact Bugs & 2 High Impact Bugs Most bugs are due to validation errors. Developers stopped all current development and resolve the bugs.

    Project Risks

    Category Description Likelihood Impact Mitigation
    Client Management Changing functional requirements High High Project Manager adjust schedule according to the client's requiremtns and apply change management controls. Developers to update the PM if the changes in requirements affact the project schedule.
    Technology Lack of experience in new technologies High High Research on the technologies used and designate members to share the knowledge and risks of using the technologies.
    Project Management Hard to estimate the amount of time required for tasks Medium Medium Project Manager and developers to discuss the amount of time required before each iteration. Project Manager to constantly review and re-estimate the time required to complete each functionality.

    The risks above have been managed and mitigated.

    Technical Complexity

    Technical Complexity 1: Rescheduling

    Team VI Technical Complexity 1.png
    Team VI Technical Complexity 2.png
    Team VI Technical Complexity 3.png

    Currently, we are using the a frontend library called FullCalendar.io to display our schedules and classes. FullCalender.io has many API methods, but we are focusing on the recursive rendering method. Due to the business requirement for temporarily rescheduling, the recursive rerendering method in FullCalender.io cannot be used to fulfill the requirement. If a student wishes to temporary reschedule to another class, the student will be shifted to another date and the student will be rendered recursively on the changed date range instead due to its repeated schedule ID.

    The team has came up with our own methods of generating schedule events that is linked to a particular schedule. These schedule events will instead contain the students that belong to this class, and each schedule event id will be unique. In this case, the student can then make a temporary reschedule of classes.

    Technical Complexity 2: Database Structure

    Before After
    Team VI Technical Complexity 4.png
    Team VI Technical Complexity 5.png

    In order to cater to temporary rescheduling, the database has to be design such in a way that stores each lesson as a unique event together with the attendances. It has differed a lot to our initial understanding and design to the database. Hence we have to rework on the entire data structure and auto create multiple schedule events in the backend according to the schedule. Furthermore, we also learnt that the tuition center has their unique set of course workbook for their students. It requires the system to keep track of the performance of each student on each work book. We used to link the result with the schedule as we define our schedule to be a joint table of teacher, student and course. However, since we made the change to allowed temporary reschedule, the result will have no correct table to join. Hence we purposely create a TeacherStudentCourse (TSC) table for the reporting module. We also included two attributes in the TSC table to keep track of the student current progress level for fast retrieval. And we also realize this data structure has the capability of tracking the results for multiple schedules for the same teacher, student and course.


    Type Description Documentation
    Requirement Gathering Market Research Market Research
    Project Management Minutes, Metrics, Risks, Change

    Meeting Minutes
    Schedule & Effort Metrics
    Bug Metrics
    Risk Management
    Change Management

    Analysis and Design Use Case, ER Diagram Use Case & ER Diagram
    Analysis and Design Architectural Diagram, Technology and Tools Used Architectural Diagram & Technology and Tools Used
    Testing User Test Plan Test Plan


    User Testing 1


    • Gather feedback regarding the user interface from existing users
    • Identify usability issues based on observations
    • Improve web application based on user testing results
    • Identify potential bugs that was not found during testing phase

    Users: Wong Bing Xiang (Sponsor), Teacher
    Venue: Upper Thomson
    Date: 26/10/2015
    Duration: 25 Minutes / User

    Find out more about our User Testing 1 here

    User Testing 2


    • Gather feedback from students in SMU
    • Identify usability issues based on observations
    • Improve web application based on user testing results
    • Identify potential bugs that was not found during testing phase
    • Testing of functionality

    Users: 15 SMU Students, 4 IT Consultant, 1 Digital Marketing Consultant
    Venue: SMU , FYP Labs, Starbucks at Parkway
    Date: 4,5,6 Feb 2016
    Duration: 20 Minutes / User

    Scope of User Testing 2

    • Branch Manager to successfully create a Parent and Student.
    • Branch Manager to create a schedule, and assign the student into a class
    • Teacher to mark the attendance of a student using the QR code
    • Teacher to create a feedback for the student
    • Parents to edit their own and child's information
    • Parents to successfully receive an SMS, Email when their children has attended lesson
    • Parents to view the feedback given to their children by their teachers

    User Testing 2 Focus Group:

    • Branch Manager
    • Parent
    • Teacher

    User Testing 2 Results

    Likes Dislikes
    User Interface
    • Easy to Navigate
    • Users found it intuitive and could know exactly where to click
    • Application is useful for business owner
    • Yellow Colour theme too bright for some users
    • Creating of respective users are straightforward
    • Viewing of users are easily accessible by users
    • Creation of schedule is useful and easy for administrator and teacher
    • Marking Attendance with QR code is very interesting
    • SMS and email idea are very parent-centric, and parents will be more involved and aware of what is happening in the enrichment enter
    • Editing of parent details are easy
    • Should have a dropdown of NRIC for the administrator to choose from
    • Didn't like how we must create a diagnostic record in order to assign the student to a schedule
    • Results should be in A,B,C format instead of numerical
    • Have to remember the exact schedule event to assign the student to the schedule

    AB Testing


    • Compare two version of the web portal and identify the preferred version
    • Users to perform the task of viewing the students feedback
    • Improve aesthetics of web application
    • Participants Demographics:
    • 10 Actual Parents from the center
    • Experiment Design :
      Version A Version B
      Feedback is appended at the bottom after selection of each feedback. Users have to scroll up and down to view the feedback. Feedback is displayed in tabs. Can only view one feedback at a time

      Results For AB Testing can available at: AB Testing Results


      Team VI Mid Term Reflections.png