My company is currently in the midst of delivering software that will help revamp our enterprise measurement program. In a way, we are defining the standard to which our software development projects will be graded on.
Here are some of the measurements we are interested in:
Product fault density
Requirements volatility
Defect containment
Development productivity
Hours per defect
Software size growth
Engineering percent rework
Action item aging
Risk and opportunity tracking
Earned value management systems measurements such as cost performance indicator and schedule performance indicator
The benefit of having a set of common measures for our business is quality product deliveries--which translates into increased customer satisfaction and ultimately improves the bottom line.
Take for example the measure of fault density. This is a lagging indicator to measure the quality of the software product after the development effort has completed. This is measured in terms of 1,000 logical source lines of code (KSLOC). This measure is calculated as:
Number of Defects/ KSLOC
The data are compared against organizational thresholds. Root cause analysis on the variance can point to issues with software complexity and insufficient/ineffective test life cycle. Keep in mind that having meaningful thresholds calibrated for your organization is the key to ensure you don't waste your time with needless analysis.
With that said, what measures do you consider important to your business?
Here are some of the measurements we are interested in:
Product fault density
Requirements volatility
Defect containment
Development productivity
Hours per defect
Software size growth
Engineering percent rework
Action item aging
Risk and opportunity tracking
Earned value management systems measurements such as cost performance indicator and schedule performance indicator
The benefit of having a set of common measures for our business is quality product deliveries--which translates into increased customer satisfaction and ultimately improves the bottom line.
Take for example the measure of fault density. This is a lagging indicator to measure the quality of the software product after the development effort has completed. This is measured in terms of 1,000 logical source lines of code (KSLOC). This measure is calculated as:
Number of Defects/ KSLOC
The data are compared against organizational thresholds. Root cause analysis on the variance can point to issues with software complexity and insufficient/ineffective test life cycle. Keep in mind that having meaningful thresholds calibrated for your organization is the key to ensure you don't waste your time with needless analysis.
With that said, what measures do you consider important to your business?
Hi Neal,
Is your company a software/IT service provider (vendor/consultancy), Software Product Company or a core industry having software/IT department? Many things depend on this and measured keeping these aspects in mind...
Generally, we follow many different processes in different organization. To me, since I am firm believer of mission statement of Toyota - "If process does not add value, get rid of it", I would like to capture information about effectiveness of each and every phase our software development go through... below mentioned is list of some of the statistics I would like to capture in general working as software manager...
Module wise total Open defects
Module wise total new defects per period
Module wise defects closed per period
Developer wise new defects logged per period - this will help me in finding root cause and providing required training
Training effectiveness and this will be used with above mentioned one
Testing Effectiveness
Testing productivity
Defect Leakage
Review effectiveness
Best,
Apurv
Does anyone know of any classroom training that is available to teach metrics development and metrics validation? This is something I've been unable to find, but am very interested in having all of my Quality Assurance Personnel attend.
Thanks
I would add some metrics we could use to measure training effectiveness and user adoption.