HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2015T2 Starteur Midterm Wiki"

From IS480
Jump to navigation Jump to search
Line 242: Line 242:
  
 
==Technical Complexity==
 
==Technical Complexity==
 +
===Architecture Diagram===
 +
Put architecture diagram here
 +
 +
 +
===Technical Complexity 1: Handling concurrent requests and slow clients===
 +
<font size=2><b><u>Issue</u></b></font>
 +
 +
<font size=2><b><u>Reasons</u></b></font>
 +
 +
<font size=2><b><u>Outcomes</u></b></font>
 +
 +
<br/>
 +
 +
===Technical Complexity 2: Patient Volume Visualization ===
 +
 +
<font size=2><b><u>Issue</u></b></font>
 +
 +
<font size=2><b><u>Solution</u></b></font>
 +
 +
<font size=2><b><u>Implementation Challenges</u></b></font>
 +
 +
<font size=2><b><u>Implementation</u></b></font>
 +
 +
 +
 +
<br/>
  
 
=<div style="background: #00cdcd; padding: 15px; font-weight: bold; line-height: 0.3em; text-indent: 15px;letter-spacing:-0.08em"><font color=#ffffff>Quality of Product</font></div>=
 
=<div style="background: #00cdcd; padding: 15px; font-weight: bold; line-height: 0.3em; text-indent: 15px;letter-spacing:-0.08em"><font color=#ffffff>Quality of Product</font></div>=

Revision as of 19:00, 14 February 2016

Starteur.jpg


HOME

ABOUT US

PROJECT OVERVIEW

PROJECT MANAGEMENT

DOCUMENTATION

Main Wiki Midterm Wiki Final Wiki

Project Progress Summary

Project Status

  • The team is confident of completing the project and delivering the application on time.
(starteur)dev progress.JPG

Midterm Slides

Deployed Website Link

Project Highlights

  • Deployed application to production server on 15 February 2016
  • Completed 79% of our development work as of 17 February 2016
  • Added and removed features to our scope since acceptance (see below)
  • Change in schedule since acceptance (see below)
  • Completed 2 user testings with actual users before midterm
  • Confirmed 2 educators and 50 students for UAT 3

Development Progress

Current Sprint: 11
Sprint Duration: 10 Feb 2016 - 17 Feb 2016
Major Milestone: Midterm Presentation, Integration with Starteur

Upcoming Sprint: 12
Sprint Duration: 20 Feb 2016 - 7 Mar 2016
Features Involved:

  • Group Report
  • Payment Gateway


Project Management

Project Scope

Planned Actual
Scope(v1)031115.jpg
Scope(17thOct).png

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

Planned Schedule
Schedule(v1)031115.jpg


Actual Schedule
Schedule(v2)31012016.jpg

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!

Schedulemetric(chart).PNG

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

View our Bug Metrics Here!

(starteur)Bug metric chart.JPG

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


Starteur(midterm)Risk Table.jpg

Technical Complexity

Architecture Diagram

Put architecture diagram 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

Deployment

View our architecture diagram for deployment to production server 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

  1. 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.
  2. 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.

Client's Reflection