HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2015T2 6Sigma Issues Faced"

From IS480
Jump to navigation Jump to search
Line 80: Line 80:
 
! style="font-weight: bold;background: #16a085;color:#ecf0f1; width: 300px" | Mitigation towards schedule
 
! style="font-weight: bold;background: #16a085;color:#ecf0f1; width: 300px" | Mitigation towards schedule
 
|-
 
|-
| After discussion with our sponsors, the sponsors felt that the basic functionalities of our application was still not up to standard, and the basic functionalities require more work to be added on. Apart from that, the user test was to be conducted 2 week's time. <br>
+
| Currently, our team has looked into the viability of implementing learning analytics, and we felt that it  would be too challenging to properly implement a fully functional learning analytics modulate within the short duration of 2 months
 +
| As such, our team would like to replace this Good to have functionality, and improve on the existing secondary functionalities (Audit Trail, View Statistics, and Manipulate Statistics) for the rest of the iterations.
 +
| rowspan='2' | <b> Audit Trail, View Statistics </b>(Previously scheduled in iteration 8) and <b>Manipulate Statistics</b> (Scheduled in Iteration 7) would be spread across the remaining iterations with learning analytics removed from the scope. Also, the extra 5 days of buffer would be used, if there's a need.
 +
|-
 +
| After the last sponsor meeting which was held on 16th Jan 2015, it was evident that the basic core functionalities of our application was still not up to standard, and the basic functionalities require more work to be added on. Apart from that, the user test was to be conducted 2 weeks’ time, on Jan 30th. <br>
 
<b>Our team felt that it would be wiser to prioritize on fixing the basic core functionalities of our application before moving on to tackle secondary functionalities. </b>  
 
<b>Our team felt that it would be wiser to prioritize on fixing the basic core functionalities of our application before moving on to tackle secondary functionalities. </b>  
| It was decided that the "manipulate statistics" function is to be shifted to iteration 8, such that we can allocate more time for improving our basic core functionalities.
+
| Therefore, our team felt that more effort should be dedicated to the core functionalities to ensure the application is stable enough for user testing on 30th Jan. As a result, our team has decided to postpone manipulate statistics to further iterations.
| <b> Audit Trail, View Statistics (Scheduled in iteration 8) would be spread across iteration 8 and 9, such that the team has more time to implement these functionalities. Also, the extra 5 days of buffer would be used, if there's a need. </b>
 
 
|}
 
|}

Revision as of 03:26, 24 January 2015

6Sigma Logo.png

Home

About Us

IS480 Management System

Project Management

Project Documentation

Schedule Metrics Task List Risks Issues Faced


Iteration 5


Iteration 5 : 8 December 2014 to 23 December 2014
Issues Solution Mitigation towards schedule
Previously, we had resource files (File containing end points) which groups all business functions together, regardless of the role of the executor.

This resulted in each resource file extending up to 500 lines, and it was difficult to trace code and fix bugs, resulting in delay. This has also frustrated a lot of teammates.
Our team foresaw that maintainability was going to be a problem in the long run.

It was decided for individual resource / endpoint files to be developed for each function for each particular role. Eg: Functionalities involving teams for the Faculty role would be classified under facultyteam resources. This resulted in a delay of 2 days. As we previously had an increase in buffer day from iteration 3, this resulted in a deduction of 1 day from our buffer.
Our team was still new to the technology of JPA, and we developed our business logics in the resource files.
This resulted in repeated codes.
After researching on the best practices online, we discovered that business logics were best to be encapsulated in the service files, in order to achieve a Service Oriented Architecture. This resulted in refactoring of business logics into the service files.

Iteration 7


Iteration 7 : 9 Jan 2015 to 24 Jan 2015
Issues Solution Mitigation towards schedule
Currently, our team has looked into the viability of implementing learning analytics, and we felt that it would be too challenging to properly implement a fully functional learning analytics modulate within the short duration of 2 months As such, our team would like to replace this Good to have functionality, and improve on the existing secondary functionalities (Audit Trail, View Statistics, and Manipulate Statistics) for the rest of the iterations. Audit Trail, View Statistics (Previously scheduled in iteration 8) and Manipulate Statistics (Scheduled in Iteration 7) would be spread across the remaining iterations with learning analytics removed from the scope. Also, the extra 5 days of buffer would be used, if there's a need.
After the last sponsor meeting which was held on 16th Jan 2015, it was evident that the basic core functionalities of our application was still not up to standard, and the basic functionalities require more work to be added on. Apart from that, the user test was to be conducted 2 weeks’ time, on Jan 30th.

Our team felt that it would be wiser to prioritize on fixing the basic core functionalities of our application before moving on to tackle secondary functionalities.

Therefore, our team felt that more effort should be dedicated to the core functionalities to ensure the application is stable enough for user testing on 30th Jan. As a result, our team has decided to postpone manipulate statistics to further iterations.