Ads by TechWords

See your link here
Receive the latest technology news and information.
Application/Web Development
Computerworld Daily News (First Look and Wrap-Up)
Computerworld Blogs Newsletter
The Weekly Top 10
Cloud Computing
View all newsletters




Privacy Policy
 

What's Your Fault Feedback Ratio?

November 4, 2002 12:00 PM ET

Computerworld - Most of us track faults (also called defects, problems, issues, bugs) during the system test part of the project. However, many project managers don't track how many of our fixes are successful and how many fixes are bad -- either introducing a new defect or not completely fixing the original defect. If you're looking for better scheduling of your system test and project completion, start measuring your Fault Feedback Ratio, the FFR.
Here's how to calculate your fault feedback ratio:

Fault Feedback Ratio = Fixes that require more work

All the fixes


When I've measured successful projects, the FFR stays under 10% throughout the project, meaning that no more than one in 10 fixes are problematic as the work progresses. (Don't be deceived by a low FFR and a high overall fault count. With a large total count, the defects can be too overwhelming to successfully manage.) A low FFR and a not-too-high overall defect count also implies that the developers have a relatively easy time finding and fixing the problems. The testers don't have too much trouble keeping up with testing the fixes, because the fixes haven't broken other pieces of the software. The project team is progressing.
On the other hand, an FFR of 15% or higher means that people are spending significant time finding and fixing problems. A higher FFR and a low defect count may mean that the problematic fixes are in the same part of the code base. A higher FFR and normal or high defect counts, may mean the developers may have trouble detecting where to fix the problems, and the testers may have trouble verifying the fixes are good.
Once the FFR hits 20%, you're making dubious progress on the project because your team is spending too much time re-fixing problems they thought were already fixed and retesting those fixes.
DevTalk
Johanna Rothman
Johanna Rothman consults on managing high technology product development, focusing on project management, risk management and people management.
Join the online discussion about this column.
On one project, the FFR started at 18% in the implementation phase, when the project team started to track their defects. Because the developers had completed the design before they started coding, they had trouble fixing the defects quickly. To make up the time, they took shortcuts for fixing the defects, and stopped doing peer reviews on the new code.
By the time the project was supposed to start system test, the FFR was up to 23%. The project had met its previous milestones, but the team was unable to predict the


Development

Additional Resources

Microsoft
Here are some of the key reasons why you would want to run Unified Access Gateway with DirectAccess.
Microsoft
Review how one energy firm tightened protection and simplified IT work using business-ready security solutions.
Sybase
In this white paper, IDC analyzes the role of next-generation mobile enterprise platforms as organizations seek a more strategic deployment of mobile solutions.

Learn the important issues you must consider before starting your next mobility initiative. Get your mobility white paper from IDC now, compliments of Sybase.

White Papers & Webcasts

Extend, Replace, or Convert; which is the best way forward for COBOL Applications?
Download this white paper, free, compliments of Micro Focus!  

The Workday User Experience Video
Watch Workday's Creative Director, Scott Lietzke, discuss the business-centered design philosophy at Workday.

Business Process Framework Demo
Learn about Configurable Business Processes and Calculated Fields. Watch Now!

Manager Experience Demo
Go beyond self-service solutions to perform more effectively. Watch Now.


IT Jobs