Difference between revisions of "IS480 Team wiki: 2012T2 box.us Project Management"

From IS480
Jump to navigation Jump to search
Line 297: Line 297:
Check out our Change Log:
Check out our Change Log:
* [https://docs.google.com/spreadsheet/ccc?key=0AuLeuwqZi7r9dGtXSFdJVVhFbUx3TEpmSzlQRzZjdEE#gid=0 Change Log(Google Docs)]
* [https://docs.google.com/spreadsheet/ccc?key=0AuLeuwqZi7r9dGtXSFdJVVhFbUx3TEpmSzlQRzZjdEE#gid=0 Change Log(Google Docs)]
* [https://wiki.smu.edu.sg/is480/Image:Change_Log_v1.0.xlsx Change Log v1.0]
Check out how the Change Log was used:
* [https://wiki.smu.edu.sg/is480/Image:Change003.xlsx Change ID 003]
* [https://wiki.smu.edu.sg/is480/Image:Change005.xlsx Change ID 005]
== Issues ==
== Issues ==

Revision as of 09:31, 22 April 2013


Kevin.jpg Sherrie.jpg Boonkheng.jpg Jenzus.jpg Waimun.jpg Jervenne.jpg

Project Milestones

Project Gantt Chart(For Empact)

Project Schedule

Iteration Reports
The iteration reports covers the bug ratios and schedule ratios for each iteration.

Overall Project Metrics:

Overall Bug Metrics

Boxus BugMetricsFinals.png

Iteration Bug Score Any Actions Taken
11 31

Increase in Bug Score due to bugs that were recorded from User Testing 2

  • 2 days allocated to fix bugs from User Testing 2
12 16

New features of the system(Statistics, Dashboard and Notifications) were being released

  • Allow Empact to have a full picture of the entire system for testing
  • Resulted in an overall increase in bugs being reported
  • Scheduled additional time during bug fixing to fix up bugs within the system
  • All bugs were fixed by the end of the iteration
13 58

More thorough testing was being performed for the UAT

  • Resulted in an overall increase in bugs being reported
  • Scheduled additional time during bug fixing to fix up bugs within the system
  • All bugs were fixed by the end of the iteration

Overall Schedule Metrics

Boxus Schedulemetricsfinals.png



  • To ensure that all project tasks are completed on time and milestones are met.

Schedule Ratio = Actual Duration / Planned Duration

Schedule Ratio Description Response
< 0.8 Team is ahead of schedule Proceed to embark on the next task if possible
0.8 - 1.2 Within healthy schedule range No actions required for ratio below 1.
Keep close monitor on tasks that have a ratio of more than one.
Project Manager to review schedule to see which tasks have gone over time. If necessary, review time estimations for tasks in the next iteration.
> 1.2 Team is behind schedule Team is behind schedule. Project Manager identifies root cause of the delay. Project Manager would increase the velocity of the team in the upcoming iteration to complete the tasks on time.

Schedule Metrics are captured within the Iteration Reports. Look above for the Iteration Reports.



  • To minimize the number of bugs that surface during the duration of a sprint and thus ensuring the quality of the application.
  • A bug is defined as errors in code that causes system to behave differently from expected.


Bug Score = (1 X Total No. of Low Severity) + (2 X Total No. of Medium Severity Bug) + (10 X Total No. of High Severity Bug)

Severity Score Severity Level Description
1 LOW System is able to function as per normal. Minor issues in expected output or user interface alignment
2 MEDIUM System is able to function but with runtime errors. Some non-critical functionalities may not work as expected
10 HIGH System has some compilation error and unable to run or unusable for a period of time. Core functionalities may be affected
Bug Score Action Plan
6 and below Developers resolve issues within the iteration
7 - 9 Schedule debugging in the buffer of the iteration.
10 and above Priority goes to resolving bug. Project Manager reallocates task for debugging team to focus on debugging.

Bug Log

Resources for Bug Metrics

There are few sources of change for the project itself. Depending on the initiator of the project change, change control processes would have to be taken into consideration.


Requirement Change

Requirement changes are modifications, additions, deletions of requirements stated in the latest version of requirements documentation. In this case, sponsor and supervisor would be noted. Response from supervisor and sponsor would be sought before decision is sealed.

System Design Change

System changes are modification, additions, deletions to the system architecture and detail system design as stated in the latest versions of system architectural documentations and technical infrastructure documentations. Depending on severity, response from supervisor might be sought before decision is sealed.

Business Process Change

Business Process changes are modifications, additions, deletions to the existing business processes as stated in the latest versions of process analysis documentation.


Following the feedback given by our supervisor, we have come up with the revised change process:

  1. Change initiated by external party
  2. Project Manager informed of change
  3. Project Manager makes decision of change and decides if team meeting is needed
  4. Project Manager informs team supervisor and sponsor(only if necessary)
  5. If team meeting is needed, meeting is scheduled, else team would be informed of change once decision made
  6. Change would be analyzed and decision reached by team to make it known.
  7. Change decision is being made known to supervisor
  8. Change implemented and decision is made known to team, supervisor and sponsor(if necessary)

Major Changes


Changes that are formalized and agreed upon by team, and stakeholders if necessary, would be recorded in the respective documentation by Project Manager/Deputy Project Manager. Followup actions of changes made to project and team would be tracked by the Deputy Project Manager.

Check out our Change Log:



Issues consists of items that are small changes that do not significantly impact the project schedule or project scope. Our team adopts an issue list in order to keep track of outstanding issues.

Check out our Issue Log:


Our team's risk management approach is in constant monitoring and reviewing risk at the start and end of each milestone.

Risk matrix.gif

Our Top 3 Risks

Priority Type Risk Consequence Likelihood Impact Level Risk Assessment Level Mitigation Strategy


Underestimation of time taken to complete a module

  1. Delay in project schedule




  1. Buffer at the end of every iteration
  2. More buffer towards the end to act as contingency buffer in between iterations


Higher than expected number of issues raised during testing(s)

  1. Delay in project schedule
  2. Changes may affect the system or scope"




  1. Change Management process to help evaluate whether the change is necessary


Business process of client is not clearly defined, leading to constant changes in the business process and design of the system

  1. Re-doing of system design that leads to unnecessary work
  2. Delay in Schedule




  1. Client meeting at the start of iteration to be adopted and it would be able to include the review for the next iteration
  2. Require client to do up the business process diagram in order to allow client to think through the entire process.
  3. Prototyping process to let the client have a better idea of the end-product and what are the fields that would be necessary to capture within the system

Risk Management Plan Resources

Check our our Risk Management Plans for more information:


Team Box.us would be responsible for the deployment of the system onto the client's servers and to ensure that the application is able to function smoothly and integrate into their current workflow processes.

Deployment Plan Slide1 Boxus.jpg

Server Migration

Date: 08/02/2012

Box.us was tasked to do an urgent migration for Empact because their servers were going to expire. After considering our scope, we decided that it would be possible to continue on with doing the migration for Empact. Our team decided to move forward with the server migration for the following reasons:

  • Did not affect the current schedule much
  • Had previously done research on the list of possible hosts for Empact
  • Gives the team greater control over the development environment
  • Ensures Empact's business continuity

Resources for Server Migration