IS480 Team wiki: 2013T1 ThunderBolt Mid Term wiki

From IS480
Jump to navigation Jump to search


  Mid-Term Wiki   Final Wiki

Project Progress Summary

Immediate Deliverable

Click here [1] to view our mid-term presentation slides in PDF format
Click here [2]to download PPT version
Link to deployment server: http://bit.ly/is480-ss
Link to live server (using by 2013/14 Term 2 students and supervisors):

Our Key Accomplishments

- 70% of the project completed
- Completed 8 iterations (out of 12 iterations in total)
- Conducted 2 User Tests with key users
- Live system deployed on 30 September

Project timeline overview

Midterm timeline.png.PNG

Click here to see more detail of our iteration plan.

Project Highlights

#1 - User Testing 1 was planned on 27 August 2013 for sponsors to test only, however, our sponsors requested to invite other stakeholders to the test as, thus, we have to shift the testing to 2 September to prepare for the change

#2 - In Iteration 7, sponsor requested to deploy our system for upcoming (2013/14 Term 2) FYP teams to book their acceptance presentation, we didn't expect live deployment to come so soon, thus, extra time were put in to clean up and set up the system to prepare for live deployment.

Project Management

Click here to see description of the funtionality
Click [3] to view our full project schedule.

Project Status

Feature Status User Testing Status Deployment Status
Single-Sign On Completed UT1 & UT2
Role Switching Completed UT1 & UT2
Create Schedule Completed UT1 & UT2
View Schedule Completed UT1 & UT2
Edit Schedule Completed UT2
Archive Schedule Completed UT2
Create Booking Completed UT1 & UT2
View Booking Completed UT1 & UT2
Edit Booking Completed UT1 & UT2
Delete Booking Completed UT1 & UT2
Approve/Reject Booking Completed UT1 & UT2
Supervisor Availability Completed UT1 & UT2
Manage Milestone Configuration Completed UT1 & UT2
Email Notification Completed UT1 & UT2
TA sign up for filming Completed UT2
CSV file upload Completed -
SMS Subscription Completed -
Manage Reminder Systems Completed -

SMS Notification Completed -
Manage User Roles Not started - -
Manage Teams - Delete team Not started - -
Export Calendar Not started - -
Report Generation Not started - -
Presentation Subscription Not started - -
Facebook Integration Not started - -
Facility Booking Not started - -
Video Server Integration Not started - -

In Summary
We have 4 more iterations to go before our final presentation. We are currently on schedule and we are confident that the project will progress as planned.

Project Schedule (Plan Vs Actual)

Iteration Task Name Reason for the delay/push back Mitigation
5 Manage Milestone Configuration This back-end side of this functionality was more complex than expected The owner of this task continue to work on it while others start new iteration to work on other functionality
8 - Manage User Roles
- Delete team
These two functionality were scheduled in Iteration 8, however, we pushed back to Iteration 9. The reason for that is because we plan to launch our system to allow 2013/14 Term 2 FYP teams to book their presentations. Therefore, we felt that it is necessary to ensure system readiness by doing some clean ups instead of working on new functionality. No impact to current Iteration. Switch some of the functionality (based on their difficulty level and importance) in iteration 10 and 11 to accommodate this change.
8 - CSV file upload CSV file upload function was more complex than expected Used up 2 buffer days to complete the task

Project Metrics

Schedule metrics

The chart below shows the overview of schedule metrics we collected over past 8 iterations.
Click here to understand how we derive our metrics and what are the action plans to each metric.

Schedule metric chart midterm.PNG
Key issues
Iteration 4 (before acceptance): There was a delay in this iteration. Planned for 10 days, but we took 12 days to complete the tasks. This is because edit schedule and edit booking task was more complex than expected, mitigation was to use buffer days we have to complete them.

Iteration 5: There was another delay in this iteration. Planned for 11 days, but actual was 14 days. The reason being manage milestone configuration back-end logic was more complicated than expected. Our action plan was that the owner of the task continue to work on the task while others continue with other tasks in next iteration.

Iteration 8: CSV file upload function was delayed because there were alot of validations required to check the format and content of the file. And also we were busy with cleaning up the system to prepare for live deployment which was on 30 September. The action we took to overcome this was to use 2 buffer days we have.

Bug metrics

Click here to find out how we calculate our bug score and what are the respective action plans for different category of score.
Figure 1 shows the distribution of bug severity
Figure 2 further elaborate figure 1 by breaking down bug severity distribution over iteration
Figure 3 shows an overall bug score for our system as of now
Bug distribution midterm.PNGBug distribution over iteration midterm.PNGBug score midterm.PNG
Bugs logged here were discovered during internal testing which carried out at end of each iteration based on the test cases we created.Regression testing methodology was used to conduct internal testing.
There was a spike in the bug score in Iteration 4, this was due to more complex tasks were developed during this iteration and also more rigorous testing conducted in our system in preparation for Acceptance presentation.

Outstanding bugs:
Bug No. 1 was only discovered when we deployed our system to live server, we are currently working on it and should be solved after midterm
Bug No. 2 is a minor bug that we will be fixing it after midterm

Project Risks


Click here to see complete list of risks

Technical Complexity


One of our goals that we identified in the beginning of the project was to build a polished and seamless user interface, as we felt that was critical to the adoption of our system to replace the Wiki.

Single Calendar View
As soon as a student logs in to the system, they are directed to a calendar view, where they can manage their team's bookings. The functions they have are quite different from those of the administrator's, faculty's and TA's. This All-In-One calendar therefore provides every stakeholder a single source of truth for their FYP presentation schedules. Some of the interesting functions of each role are as follows:

They can create bookings for currently pending teams, change venues, and update bookings by drag-and-drop
Admin View.png

They can set their availability for any timeslot on the FYP schedule, and view only bookings that matter to them
Faculty View 2.png

They can create bookings with a single-click, invite others like their sponsors and peers, and have a visual trail of their booking history
Student View.png

They can indicate the timeslots they want to film for, and can view only bookings that matter to them
TA View.png

Multi-Functional Calendar Interface
We have built a multi-functional calendar interface from scratch to power the user interface in our system. This is the component that the most number of users interact with in our system.

We have developed various functionalities for every type of user, to minimize the amount of input required from the user:
- Administrator/Course Coordinator: Administrators can create bookings for all teams in the system. So to make it convenient for them, our application pre-loads all of the teams that still don’t have a booking to let the user simply pick one from the list. Also, shifting a booking from one time to another is even simpler, by just dragging and dropping the booking onto the suitable time slot.
- Faculty: All faculty members can mark their availability on the system, to make it easier for students to find a suitable presentation slot. Our interface for marking the availability gives the faculty members clear visual indications of possible scheduling conflicts by color-coding different slots. Also, we have convenient popups on the index page for the faculty to update their availability from there as well.
- Student: Students can create bookings for the teams with just a single click of a button. They do not need to key in their team details or the timings of the slot that they are interested in choosing. Our system pre-loads that content and also the required attendees (faculty) for the presentation.
- TA: Similar to the availability page shown to faculty members, TAs have a page to sign-up for slots. The index page automatically highlights the presentations that are of interest to them (the presentations that they are filming for).

Schedule Dates Selector
The problem of setting FYP dates is quite unique because there are multiple milestones, and numerous validation checks must ensure dates do not get overlapped or be disorderly for any milestone. Therefore, we have built a user interface comprising of 6 different plugins and programmed it in such a way that the plugins trigger interactaction with each other on every click and every keystroke so validation is more more efficient.

Schedule Date Selector.png

Complete information in one view
Microsoft Outlook and Google Calendar both DO have the functionality to do what our system does. What they both lack together though are:
A simple calendar view is separated from the more detailed event view so users have to manage two separate windows and pages respectively
Attendees for any event are unknown and have to be manually searched for
The approvers for any bookings are unknown and have to be inquired beforehand
There is a lot of unnecessary information present in creating bookings, like a field for video calls and settings colors for bookings
Outlook Google IS480.png

Performance & Scalability

Hibernate Optimization
All database interactions in our application are powered by JPA, with Hibernate as our JPA Provider. However, the default setting in Hibernate is configured such that when an object is retrieved from a database, all other objects linked objects are also retrieved. For example, if we want to retrieve a single term object from the database, all the linked objects (e.g. schedules, time slots etc.) will get retrieved. In certain cases, this can lead to the entire object graph being loaded into the memory of the application.

Before Lazy Fetch
Before Lazy Fetch.PNG
To counter this problem, we have used the Lazy Fetching strategy, which is one of the best practices for implementing Hibernate. This strategy retrieves objects from the database on an “on-demand” basis. So now, when we retrieve a single object such as a term from the database, all the linked objects (e.g. schedules) will not get retrieved unless they are explicitly called for. For e.g., when we retrieve a term object, we are only returned the term object from the database. The schedule object and all its related time slots are only retrieved when they are explicitly accessed in the Java code.

After Lazy Fetch
After Lazy.PNG
Concurrent Users
During User Testing 1, our application froze during frequent intervals as the number of database connections that could be created by our application was breached. We traced this problem to the use of the default connection pool provided as part of Hibernate, which is heavily discouraged for production use. To prevent this issue, we have implemented a production-ready connection pool that will enable our application to reuse connection objects across the application and allow up to a 150 connections to the database. Although such a large number is not required, this comfortably prevents connections to the database from becoming a limiting constraint for system performance.


After our initial client meetings, we came to realize that keeping things flexible is hugely beneficial to the system. Since then, one of our goals while building this system has been to minimize hard coding throughout the system.
Over the last few iterations, we have put in significant effort into making various parts of our system customizable as per our client’s requirements. Here is summary of the customizable components:
- Milestone Configuration: Administrators can create and edit the details for the different milestones in the system such as their name, order and required attendees.
- Schedule Constraints: For each milestone, the duration of the presentation can be set. In addition to this, the start and end times of days can be set for each schedule being configured. Lastly, the visibility of terms and individual milestone schedules can be controlled to prevent unwanted user activity.
- Faculty Booking Response Time: In order to be fair to all users, our system follows a system of automatic rejection to clear out bookings that haven’t been responded to in time.
- Email & SMS Reminders: Our system sends emails to faculty to remind them of their pending tasks and SMSs to all attendees before the presentation. The administrator can control the timing of these notifications.

Quality of product

Intermediate Deliverables

Stage Specification Links
Project Management Metrics
Requirements Change Requests Log
Analysis Use Case
Design System Architecture Diagram
Testing Internal Test Plan
Test cases and results
User Testing 1 and User Testing 2


System deployed to live server on 30 September.
Link to live server:[7]
System Activity/Statistics
- 19 teams(out of 30 teams from IS480 2013/14 Term 2 ) have used our system to make their acceptance presentation booking.
- ALL supervisors have used our system to interact with their teams
- ALL 19 teams managed to confirm their acceptance presentation slot in less than 5 days


2 User Tests conducted
User Test 1 - 2 Sep 2013 -> click here to check out our UT1 documentation and test results
User Test 2 - 4 October 2013-> click here to check out our UT2 documentation and test results


Team Reflection