HeaderSIS.jpg

IS480 Team wiki: 2015T2 6Sigma Issues Faced

From IS480
Jump to navigation Jump to search
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
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.

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.

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