Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Example of a Metrics Program

Example of a Metrics Program



|Views: 763|Likes:
Published by Venkatesh.R

More info:

Published by: Venkatesh.R on Sep 08, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Example of a Metrics Program
The following is a fictional example illustrating a simple application of the 8-Step Metrics Progam thatwill yield short-term feedback. Before committing a major investment in time, it is often valuable tobecome familiar with a new program by applying it to a small project with a short time frame. Theexperience gained should be applicable to the implementation of a larger program with long-term goalsand a broader scope. Most software organizations can replicate this example to yield valuable informationwith a minimum of investment.
Integrated Software is a small company specializing in integrated CASE tools. It has fewformal procedures, and its software development process is best described as traditional.The company performs code inspections on an ad hoc basis, and a testing program isestablished. Management is considering a major upgrade to the main product that willinvolve significant re-engineering. Time is short, budgets are thin and experience withmetrics is non-existent.Integrated Software’s past experience shows that some projects have had serious costoverruns. The instability of a recent release resulted in a loss of customers. Projects thatare underestimated, over-budget, or that produce unstable products, have the potential todevastate the company. Accurate estimates, competitive productivity, and renewedconfidence in product quality are critical to the success of the company.Hoping to solve these problems as quickly as possible, the company managementembarks on the 8-Step Metrics Program by Software Productivity Centre Inc..
Step 1: Document the Software Development Process
Integrated Software does not have a defined development process. However, the newmetrics coordinator does a quick review of project status reports and finds that theactivities of requirements analysis, design, code, review, recode, test, and debuggingdescribe how the teams spend their time. The inputs, work performed, outputs andverification criteria for each activity have not been recorded. He decides to skip thesedetails for this "test" exercise. The recode activity includes only effort spent addressingsoftware action items (defects) identified in reviews.
Step 2: State the Goals
The metrics coordinator sets out to define the goals of the metrics program. The list of goals in Step 2 of the 8-Step Metrics Program are broader than (yet still related to) theimmediate concerns of Integrated Software. Discussion with development staff leads tosome good ideas on how to tailor these goals into specific goals for the company. Thecoordinator lists questions about each goal.
The development staff at Integrated Software considers past estimates to have beenunrealistic as they were established using “finger in the wind” techniques. They suggestthat current plans could benefit from past experience as the present project is very similarto past projects. The metrics coordinator narrows and restates Step 2, Goal 2 (Improvesoftware estimation):
Company Goal 1: Use previous project experience to improve estimations of productivity.
Questions asked about the goal:
What is the actual labor rate of past projects?
How complicated is the software being developed?
Does the labor rate vary for different types of software?
Discussions about the significant effort spent in debugging center on a comment by oneof the developers that defects found early on in reviews have been faster to repair thandefects discovered by the test group. It seems that both reviews and testing are needed,but the amount of effort to put into each is not clear. The metrics coordinator decides tofocus Step 2, Goal 8 (Improve staff productivity) around questions of rework.
Company Goal 2: Optimize defect detection and removal.
Questions asked about the goal:
How much effort is spent in testing versus reviews?
How many defects are discovered in testing versus reviews?
How much effort is spent repairing defects discovered in reviews?
How much effort is spent repairing defects discovered in testing?
How efficient are reviews in removing defects?
How efficient is testing in removing defects?
What is the optimal defect detection efficiency to achieve in reviews prior to testing?
The test group at the company argues for exhaustive testing. This however, isprohibitively expensive. Alternatively, they suggest looking at the trends of defectsdiscovered and repaired over time to better understand the probable number of defectsremaining.The coordinator limits Step2, Goal 6 (Improve software quality) to establishing aquantitative indication of stability at product release.
Company Goal 3: Ensure that the defect detection rate during testing is convergingtowards a level that indicates that less than five defects per KSLOC will bediscovered in the next year.
Questions asked about the goal:
How many defects have been discovered so far?
How many defects have been repaired so far?
What is the trend in number of defects discovered and repaired over time?
Step 3: Define Metrics Required to Reach Goals
Working from the Step 3 tables, the metrics coordinator chooses the following metrics forthe metrics program.
Company Goal 1: Improve Estimates
actual effort for each type of software in PH
size of each type of software in SLOC
software product complexity (type)

Activity (3)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
meetantoalphi liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->