HeaderSIS.jpg

IS480 Team wiki: 2013T1 ThunderBolt Project Management Metrics

From IS480
Jump to navigation Jump to search
Wikiprofilepic.jpg

Home

  About Us   Project Overview   Project Management   Project Documentation
Project Schedule Risks Metrics Resources and References Learning Outcomes

Schedule Metrics

The objective of Schedule Metrics is to help the team to keep track of the progress of our project development.
The Schedule Metrics will be tracked by the Project Manager on per Iteration basis.

The following formula is used by the team to calculate Schedule Metrics (SM):
Schedule Metrics (SM) = Estimated time / Actual time
*time is measured in Days

Score(%) Description Action
SM < 50

Team is way behind schedule

Inform supervisor/sponsor immediately about the slip and consider dropping functionalities

50<SM<=90

Team is behind schedule

- PM to re-estimate the time required for similar tasks for the future iterations
- Deduct the number of days behind schedule from buffer days
- If no more buffer day(s) left, inform supervisor/sponsor and decide to drop functionalities

90<SM<=110

Team is on track

Our estimates are fairly accurate, keep up the good work

110<SM<=150

Team is ahead of schedule

- Start on next task earlier
- PM to re-estimate the time required for similar tasks for the future iterations
- Add the number of days gained to buffer days

150 < SM

Team is way ahead of schedule

- Project Manager to find out from developers on why tasks are completed earlier than expected and ensure that quality of the application is not compromised
- Start on next task earlier
- PM to reduce the time required for similar tasks for the future iterations
- Add the number of days gained to buffer days













Schedule metric chart.PNG






























Bug Metrics

The objective of Bug Metrics is to keep track of the bug occurrence in each iterations of our project development and to ensure the quality of our system.
The Bug Metrics will be tracked by the Business Analyst (business analyst is also our quality assurance analyst) on per Iteration basis.

The following formula is used by the team to calculate Bug Metrics:
1 x num (low) + 5 x num (high) + 10 x num (critical)

Severity Description
Low Impact (1 points)

Typo error or small user interface alignment issues

High Impact (5 points)

The application runs. However, some non-critical functionalities are not working

Critical Impact(10 points)

The application is down or is un-usable after a short period of time. The team must stop development and fix the bugs immediately










Mitigation Plan

Points in Iteration Action
Points < 10

Use the planned debugging time in the iteration

Points >= 10

- Stop current development and resolve the bug immediately
- Project Manager reschedules the project









Overall bug severity distribution.PNGBug severity distribution over iteration.PNGBug score.PNG

Click here for our test plan:[1]
Click here for our test cases by iterations: [2]
Click here for detailed bug document: [3]