HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2013T1 ThunderBolt Mid Term wiki"

From IS480
Jump to navigation Jump to search
 
(32 intermediate revisions by 2 users not shown)
Line 26: Line 26:
 
==<div style="background: #d5a10d; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Project Progress Summary</font></div>==
 
==<div style="background: #d5a10d; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Project Progress Summary</font></div>==
 
===Immediate Deliverable===
 
===Immediate Deliverable===
Click here to download our mid-term presentation slides!<br>
+
Click here [https://www.dropbox.com/s/w9o0v8jb8bgykqf/Team%20Thunderbolt_Midterm%20Presentation.pdf] to view our mid-term presentation slides in PDF format<br>
 +
Click here [https://www.dropbox.com/s/2v66rm5poxw63t2/Team%20Thunderbolt_Midterm%20Presentation.pptx]to download PPT version<br>
 
Link to deployment server: http://bit.ly/is480-ss <br>
 
Link to deployment server: http://bit.ly/is480-ss <br>
 
Link to live server (using by 2013/14 Term 2 students and supervisors): http://202.161.45.168/is480-scheduling/login.jsp <br>
 
Link to live server (using by 2013/14 Term 2 students and supervisors): http://202.161.45.168/is480-scheduling/login.jsp <br>
Line 35: Line 36:
 
- 70% of the project completed<br>
 
- 70% of the project completed<br>
 
- Completed 8 iterations (out of 12 iterations in total)<br>
 
- Completed 8 iterations (out of 12 iterations in total)<br>
- Conducted 2 User Testings with key users<br>
+
- Conducted 2 User Tests with key users<br>
 
- Live system deployed on 30 September<br>
 
- Live system deployed on 30 September<br>
 
|}
 
|}
 +
 
===Project timeline overview===
 
===Project timeline overview===
 
[[Image:midterm timeline.png.PNG|1000px|center]]<br>
 
[[Image:midterm timeline.png.PNG|1000px|center]]<br>
 +
Click [[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Management#Project_Status|here]] to see more detail of our iteration plan.
  
Place your Midterm slides link and deployed site link here
+
===Project Highlights===
For proposal, please see Requrements at the Project Deliverables. This will help us understand your scope. Note wiki policy here.
+
'''#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<br>
This page should NOT be too long. It should link to other pages in the IS480 team wiki. Do not repeat the proposal or other wiki information here. However, keep a snapshot of the midterm state. Highlight changes since project acceptance.
 
Describe the project progress briefly here. Have the project continued as planned? If not, is the team confident to complete? This is a crossroad for the team to make a decision. Proceed with confident or file an incomplete.
 
  
===Project Highlights===
+
'''#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.<br>
What unexpected events occurred?
 
Team members too busy with other work
 
List of requirement changes
 
CRUD items replaced with CU/Sync/Archive items
 
Business analytics replaced with iPad client
 
Took 8 weeks to learn Ruby on Rails
 
etc.
 
Be brief.
 
  
 
==<div style="background: #d5a10d; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Project Management</font></div>==
 
==<div style="background: #d5a10d; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Project Management</font></div>==
Line 147: Line 140:
  
 
|}
 
|}
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
+
 
 +
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
 +
'''In Summary'''<br>
 +
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. <br>
  
 
===Project Schedule (Plan Vs Actual)===
 
===Project Schedule (Plan Vs Actual)===
Compare the project plan during acceptance with the actual work done at this point. Briefly describe a summary here. Everything went as plan, everything has changed and the team is working on a new project with new sponsors or the supervisor is missing. A good source for this section comes from the project weekly report.
+
[[Image:ThunderBoltPlannedVSActual.PNG|1000px|left]]
Provide a comparison of the plan and actual schedule. Has the project scope expanded or reduced? You can use the table below or your own gantt charts.
+
 
 +
{| class="wikitable" style="text-align: center; height:50px"
 +
|+
 +
|-
 +
! scope="col" width="20" style="background-color:#800000"| <font color="#ffffff">Iteration</font>
 +
! scope="col" width="130" style="background-color:#800000"| <font color="#ffffff">Task Name</font>
 +
! scope="col" width="50" style="background-color:#800000"| <font color="#ffffff">Reason for the delay/push back</font>
 +
! scope="col" width="50" style="background-color:#800000"| <font color="#ffffff">Mitigation</font>
 +
|-
 +
! scope="row" style="background-color:#eeeeee"|5
 +
|style="text-align: center;"|'''Manage Milestone Configuration'''
 +
|style="text-align: left;"|This back-end side of this functionality was more complex than expected
 +
|style="text-align: left;"|The owner of this task continue to work on it while others start new iteration to work on other functionality
 +
|-
 +
! scope="row" style="background-color:#eeeeee"|8
 +
|style="text-align: center;"|'''- Manage User Roles <br> - Delete team'''
 +
|style="text-align: left;"|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.  
 +
|style="text-align: left;"|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.
 +
|-
 +
! scope="row" style="background-color:#eeeeee"|8
 +
|style="text-align: center;"|'''- CSV file upload'''
 +
|style="text-align: left;"|CSV file upload function was more complex than expected
 +
|style="text-align: left;"|Used up 2 buffer days to complete the task
 +
|}
 +
 
 
===Project Metrics===
 
===Project Metrics===
 
====Schedule metrics====
 
====Schedule metrics====
Line 169: Line 189:
 
[[Image:bug distribution_midterm.PNG|200px]][[Image:bug distribution over iteration_midterm.PNG|350px]][[Image:bug score_midterm.PNG|500px]]<br>
 
[[Image:bug distribution_midterm.PNG|200px]][[Image:bug distribution over iteration_midterm.PNG|350px]][[Image:bug score_midterm.PNG|500px]]<br>
 
'''Highlights:'''<br>
 
'''Highlights:'''<br>
Bugs logged here were discovered during internal testing which carried out at end of each iteration based on the test cases we created.Regressive testing methodology was used to conduct internal testing.<br>
+
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.<br>
 
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.<br><br>
 
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.<br><br>
  
Line 182: Line 202:
  
 
===Technical Complexity===
 
===Technical Complexity===
Describe and list the technical complexity of your project in order of highest complexity first. For example, deploying on iPhone using Objective-C, customizing Drupal with own database, quick search for shortest flight path, database structure, etc.
+
====Usability====
 +
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.<br><br>
 +
'''Single Calendar View'''<br>
 +
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:<br><br>
 +
''Administrator''<br>
 +
They can create bookings for currently pending teams, change venues, and update bookings by drag-and-drop<br>
 +
[[Image:Admin View.png|300px]]<br><br>
 +
''Faculty''<br>
 +
They can set their availability for any timeslot on the FYP schedule, and view only bookings that matter to them<br>
 +
[[Image:Faculty View 2.png|300px]]<br><br>
 +
''Student''<br>
 +
They can create bookings with a single-click, invite others like their sponsors and peers, and have a visual trail of their booking history<br>
 +
[[Image:Student View.png|300px]]<br><br>
 +
''TA''<br>
 +
They can indicate the timeslots they want to film for, and can view only bookings that matter to them<br>
 +
[[Image:TA View.png|300px]]<br><br>
 +
 
 +
'''Multi-Functional Calendar Interface'''<br>
 +
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.<br><br>
 +
We have developed various functionalities for every type of user, to minimize the amount of input required from the user:<br>
 +
'''- 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.<br>
 +
'''- 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.<br>
 +
'''- 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.<br>
 +
'''- 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).<br>
 +
[[Image:multifunctionalcalendar.PNG|300px]]<br><br>
 +
 
 +
'''Schedule Dates Selector'''<br>
 +
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.<br>
 +
 
 +
[[Image:Schedule Date Selector.png|300px]]<br><br>
 +
'''Complete information in one view'''<br>
 +
Microsoft Outlook and Google Calendar both DO have the functionality to do what our system does. What they both lack together though are: <br>
 +
A simple calendar view is separated from the more detailed event view so users have to manage two separate windows and pages respectively <br>
 +
Attendees for any event are unknown and have to be manually searched for <br>
 +
The approvers for any bookings are unknown and have to be inquired beforehand <br>
 +
There is a lot of unnecessary information present in creating bookings, like a field for video calls and settings colors for bookings <br>
 +
[[Image:Outlook Google IS480.png|300px]]<br>
 +
 
 +
====Performance & Scalability====
 +
'''Hibernate Optimization'''<br>
 +
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.<br><br>
 +
''Before Lazy Fetch''<br>
 +
[[Image:Before Lazy Fetch.PNG|300px]]<br>
 +
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.<br><br>
 +
''After Lazy Fetch''<br>
 +
[[Image:After Lazy.PNG|300px]]<br>
 +
'''Concurrent Users'''<br>
 +
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.<br>
 +
====Flexibility====
 +
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.<br>
 +
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:<br>
 +
'''- Milestone Configuration:''' Administrators can create and edit the details for the different milestones in the system such as their name, order and required attendees.<br>
 +
'''- 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.<br>
 +
'''- 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.<br>
 +
'''- 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. <br>
  
 
==<div style="background: #d5a10d; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Quality of product</font></div>==
 
==<div style="background: #d5a10d; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Quality of product</font></div>==
 
===Intermediate Deliverables===
 
===Intermediate Deliverables===
There should be some evidence of work in progress.
+
{| class="wikitable" style="text-align: center; height:350px"
 +
|+
 +
|-
 +
! scope="col" width="100" style="background-color:#200772"| <font color="#ffffff">Stage</font>
 +
! scope="col" width="150" style="background-color:#200772"| <font color="#ffffff">Specification</font>
 +
! scope="col" width="300" style="background-color:#200772"| <font color="#ffffff">Links</font>
 +
|-
 +
 
 +
! scope="row" rowspan="2" style="background: #eeeeee"|Project Management
 +
|style="text-align: center;"|Metrics
 +
|style="text-align: left;"|
 +
*[[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Management_Metrics#Schedule Metrics|Schedule Metric]]
 +
*[[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Management_Metrics#Bug Metrics|Bug Metric]]
 +
|-
 +
 
 +
|style="text-align: center;"|Minutes
 +
|style="text-align: left;"|
 +
*[[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Documentation_Meeting_Minutes#Internal Meeting Minutes|Internal Meeting Minutes]]
 +
*[[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Documentation_Meeting_Minutes#Supervisor Meeting Minutes|Supervisor Meeting Minutes]]
 +
*[[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Documentation_Meeting_Minutes#Sponsor Meeting Minutes|Sponsor Meeting Minutes]]
 +
 
 +
|-
 +
 
 +
 
 +
! scope="row" rowspan="2" style="background: #eeeeee"|Requirements
 +
 
 +
|style="text-align: center;"|Change Requests Log
 +
|style="text-align: left;"|
 +
*[https://www.dropbox.com/s/vd3tbyv8fsk4mkc/Change%20Request%20Log.xlsx]
 +
|-
 +
 
 +
|style="text-align: center;"|Prototype
 +
|style="text-align: left;"|
 +
*[[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Documentation_Prototype|UI prototype]]
 +
|-
 +
 
 +
! scope="row" rowspan="1" style="background: #eeeeee"|Analysis
 +
|style="text-align: center;"|Use Case
 +
|style="text-align: left;"|
 +
*[[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Documentation#Use Case Diagram|Use case]]
 +
|-
 +
 
 +
! scope="row" rowspan="1" style="background: #eeeeee"|Design
 +
|style="text-align: center;"|System Architecture Diagram
 +
|style="text-align: left;"|
 +
*[[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Documentation#System Architecture Diagram|System Architecture Diagram]]
 +
|-
 +
 
 +
! scope="row" rowspan="3" style="background: #eeeeee"|Testing
 +
|style="text-align: center;"|Internal Test Plan
 +
|style="text-align: left;"|
 +
*[https://www.dropbox.com/s/7o3heujyzj23na2/test_plan.docx]
 +
|-
 +
|style="text-align: center;"|Test cases and results
 +
|style="text-align: left;"|
 +
*[https://www.dropbox.com/s/f6prulqjh3n3f6p/Test%20cases%20and%20results.xlsx]
 +
 
 +
|-
 +
|style="text-align: center;"|User Testing 1 and User Testing 2
 +
|style="text-align: left;"|
 +
*[[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Documentation_Usability_Test|User Testing documentations]]
 +
 
 +
|}
 
===Deployment===
 
===Deployment===
 +
'''System deployed to live server on 30 September.'''<br>
 +
'''Link to live server:'''[http://202.161.45.168/is480-scheduling/login.jsp]<br>
 +
'''System Activity/Statistics'''<br>
 +
- 19 teams(out of 30 teams from IS480 2013/14 Term 2 ) have used our system to make their acceptance presentation booking.<br>
 +
- ALL supervisors have used our system to interact with their teams<br>
 +
- ALL 19 teams managed to confirm their acceptance presentation slot in less than 5 days<br>
 +
 
===Testing===
 
===Testing===
 +
'''2 User Tests conducted''' <br>
 +
'''User Test 1''' - 2 Sep 2013 -> click [[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Documentation_Usability_Test#Usability Test 1|here]] to check out our UT1 documentation and test results<br>
 +
'''User Test 2''' - 4 October 2013-> click [[IS480_Team_wiki:_2013T1_ThunderBolt_Project_Documentation_Usability_Test#Usability Test 2|here]] to check out our UT2 documentation and test results<br>
 +
 
==<div style="background: #d5a10d; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Reflection</font></div>==
 
==<div style="background: #d5a10d; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Reflection</font></div>==
In this section, describe what have the team learn? Be brief. Sometimes, the client writes a report to feedback on the system; this sponsor report can be included or linked from here.
 
 
===Team Reflection===
 
===Team Reflection===
Any training and lesson learn? What are the take-away so far? It would be very convincing if the knowledge is share at the wiki knowledge base and linked here.
+
[[Image:teamreflection1.PNG|500px]][[Image:teamreflection2.PNG|500px]]<br>
 +
[[Image:teamreflection3.PNG|500px]]

Latest revision as of 00:42, 25 November 2013

Wikiprofilepic.png

Home

  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): http://202.161.45.168/is480-scheduling/login.jsp

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
Transparent-green-checkmark.png
Role Switching Completed UT1 & UT2
Transparent-green-checkmark.png
Create Schedule Completed UT1 & UT2
Transparent-green-checkmark.png
View Schedule Completed UT1 & UT2
Transparent-green-checkmark.png
Edit Schedule Completed UT2
Transparent-green-checkmark.png
Archive Schedule Completed UT2
Transparent-green-checkmark.png
Create Booking Completed UT1 & UT2
Transparent-green-checkmark.png
View Booking Completed UT1 & UT2
Transparent-green-checkmark.png
Edit Booking Completed UT1 & UT2
Transparent-green-checkmark.png
Delete Booking Completed UT1 & UT2
Transparent-green-checkmark.png
Approve/Reject Booking Completed UT1 & UT2
Transparent-green-checkmark.png
Supervisor Availability Completed UT1 & UT2
Transparent-green-checkmark.png
Manage Milestone Configuration Completed UT1 & UT2
Transparent-green-checkmark.png
Email Notification Completed UT1 & UT2
Transparent-green-checkmark.png
TA sign up for filming Completed UT2
Transparent-green-checkmark.png
CSV file upload Completed -
Transparent-green-checkmark.png
SMS Subscription Completed -
Transparent-green-checkmark.png
Manage Reminder Systems Completed -
Transparent-green-checkmark.png


SMS Notification Completed -
Transparent-green-checkmark.png
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)

ThunderBoltPlannedVSActual.PNG
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
Highlights:
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:
Outstandingbugs.PNG
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

Top3risks.PNG

Click here to see complete list of risks

Technical Complexity

Usability

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:

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

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

Student
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

TA
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).
Multifunctionalcalendar.PNG

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.

Flexibility

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
Minutes
Requirements Change Requests Log
Prototype
Analysis Use Case
Design System Architecture Diagram
Testing Internal Test Plan
Test cases and results
User Testing 1 and User Testing 2

Deployment

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

Testing

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

Reflection

Team Reflection

Teamreflection1.PNGTeamreflection2.PNG
Teamreflection3.PNG