HeaderSIS.jpg

IS480 Team wiki: 2015T2 Starteur Final Wiki

From IS480
Jump to navigation Jump to search
Starteur.jpg


HOME

ABOUT US

PROJECT OVERVIEW

PROJECT MANAGEMENT

DOCUMENTATION

Main Wiki Midterm Wiki Final Wiki

Project Progress Summary

Final Slides

Click here to download our final presentation slides!

Deployed Website Link

Click here to explore our deployed site!

Project Highlights

Project summary.jpg

Project Challenges

Project challenges.jpg

Project Management

Project Scope

Planned Actual
Actual scope(starteur).png
Scope(finals).jpg

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 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.
Group Report Secondary Removed multiple report - Post mid-term feedback: group would like to focus on functionalities that give the client most amount of value.
Client Administrator Tertiary Added Audit Log & Search Functionalities - These 2 functions were requested by client after mid-terms. After evaluation, team agreed that it is feasible and valuable to client's business needs.


View our Change Management Here!

Project Schedule

Planned Schedule


Actual Schedule
Scheduleforfinals.jpg

Schedule Highlights

There were 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.

There were no major changes to the project schedule. Functions were added and removed within the schedule. Schedule was adjusted according to changes in scope. UAT 4 was removed as Client's management team was unable to make it for the testing due to their busy schedule.

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.
10 4 4 low bugs found. Alignment of elements in form to generate access codes, promotion code and discount code. 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

Activated Risks

Type of Risk Description Risk Level Mitigation
Development Risk Starteur for Educators will require results from Starteur and is sharing same database as Starteur. Delays in Starteur may impact Starteur for Educators and may delay progress. Inconsistencies will compromise on user experience. C Starteur for Educators to specify their needs early to Starteur and client. Constant communication and updates from both sides. Schedule planned ahead with possible changes in mind as well as Starteur’s development schedule. Cut-off time to pull changes from Starteur development branch.
Technical Risk RubyonRails is a new framework for development team other than Kia Yong who has experience working with it. As such, inexperience with the framework and insufficient learning time will delay development schedule and will affect quality of work produced. C Team started learning RubyOnRails once project and technology has been confirmed. Daily updates on learning with screenshots of Codeacademy progress. Highly useful reference materials identified: Rails tutorial and Rails Casts. Kia Yong acting as a mentor for team and to implement best practices for coding
Communication Risk Sponsor is juggling multiple roles and will be travelling for business trips and is participating in many projects and events. As such, Sponsor may not be available when needed and may cause a delay and be a bottleneck in communication and feedback from end-users. This will impact project development as well as UATs. B Slack communication tool setup between Starteur and Starteur for Educators development team. So that team has alternative contact if Sponsor is not available. UATs to be scheduled in advance and team will contact end-users themselves and arrange for UAT while keeping Sponsor in the loop.


Potential Risks

Type of Risk Description Risk Level Mitigation
Manpower Risk Pre-acceptance: 2 out of 4 members are on Leave of Absence for internships, thus meeting times are limited to evenings and weekends. 4 member FYP team as such manpower is limited as compared to teams with 6 members. C Team have been meeting for 2 weeknights/week and if required, weekend afternoons. Team to commit to at least 12hours/week for FYP. Ensure that project scope is reasonable within limits and tasks are also covered by another member to eliminate dependencies. Daily updates on work completed and remaining.


Scope Risk Sponsor may have difficulties pointing out what he wants due to this being a new project for him and for his company’s team. As such, sponsor may add possible functions according to his own reviews and needs. Scope creep will affect development schedule. B Transparent communication with sponsor on team’s development progress and capability. All changes to go through change management before making any decision. Expectations of client to be managed through meetings.

Technical Complexity

Architecture Diagram

Midterm archi.jpg

View our architecture diagram for deployment to staging server here!

Technical Complexity 1: Assigning Code Usage

Issue

Midterm complexity1(starteur).jpg

  • A Starteur user (student) can have different states.
  • An Educator can potentially have users of mixed states
  • Every time an educator takes an action, e.g. Assign access codes, the logic has to take into account all possible relevant states the user might be at.
  • Compounded when your actions involve more than 1 such modal with multiple states.


Solution Important to figure out all the possible combinations and relevant actions to take.

Implementation

Technical Complexity 2: Generating PDF

Issue

  • Multiple pages with variable content length, headers and footers.
  • A need to have a template to have a consistent look for all reports and to control how each page is rendered.
  • Displaying of dynamic content and setting a template for content.

Solution


Tech complex1.png

  • Use of Prawn. Prawn is a full-featured gem with a nice DSL for creating PDF documents and integrating Prawn with Rails is straightforward.
  • Highly flexible PDF document generation system that allows us to specify where we want to display our content.


Outcomes
Using a library like Prawn, content styling and positioning have to be done on our own using Prawn’s DSL. We would more control over how things are displayed and where pages break.
Prawn supports image embedding and table drawing which will prove beneficial for the future Group Report Module should be there be a need for images and tables.

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

Deployment

Click here to explore our deployed site!

Testing

User Testing 1

Locations: CHIJ St Nicholas Girls' School, SMU, 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

Click here to view our User Testing 1!

User Testing 2

Location: SMU
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

Click here to view our User Testing 2!!

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.
  • Development rules with Starteur's developer and strict enforcements.
  • 1 month before our final presentation, we will halt all development from Starteur's side so that we are given ample time to deal with their changes and to prevent any last minute changes on their end.
  • 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.

Individual Reflections


Midterm reflections (starteur).jpg