Software Metric

A software metric is a measure of some property of a piece of software or its specification. Since quantitative methods have proved so powerful in the other sciences, computer science practitioners and theoreticians have worked hard to bring similar approaches to software development. Tom DeMarco stated, You cannot control what you cannot measure in Controlling Software Development(?). Common software metrics include: Software metrics can be used to
  • estimate project budget and schedule
  • evaluate individual productivity and quality
  • evaluate project productivity and quality.
  • evaluate software quality

Limitations

The assessment of "how much" software there is in a program, especially making prediction of such prior to the detail design, is very difficult to satisfactorily define or measure. The practical utility of software metrics has thus been limited to narrow domains where the measurement process can be stabilised. Management methodologies such as the Capability Maturity Model or ISO 9000 have therefore focused more on process metrics which assist in monitoring and controlling the processes that produce the software. Examples of process metrics affecting software:
  • Number of times the program failed to rebuild overnight
  • Number of defects introduced per developer hour
  • Number of changes to requirements
  • Hours of programmer time available and spent per week
  • Number of patch releases required after first product ship.

Criticisms

Potential weaknesses and criticism of the metrics approach:
  • Unethical: It is said to be unethical to reduce a persons performance to a small number of numerical variables and then judge them by that measure. A supervisor may assign the most talented programmer to the hardest tasks on the project; they then take the longest and generate the most defects. Uninformed managers overseeing the project might then judge the programmer as performing poorly without consulting the supervisor who has the full picture.
  • Demeaning: 'Management by numbers' without regard to the quality of experience of the employees, instead of 'managing people'.
  • Skewing: The measurement process is biased by the act of measurement by employees seeking to maximise management's perception of their performance. For example, if lines of code is used to judge performance, then employees will write as many separate lines of code as possible, and if they find a way to shorten their code, they may not use it.
  • Inaccurate: No known metrics are both meaningful and accurate. Lines of code measure exactly what is typed, but not of the difficulty of the problem. Function points were developed to better measure the complexity of the code or specification, but they require personal judgement to use well. Different estimators will produce different results. This makes function points hard to use fairly and unlikely to used well by everyone.

See also

External links

  • http://www.literateprogramming.com/fmetrics.html
  • http://www.SoftwareMetrics.Com (includes free function Point Manual and other articles)

 

<< PreviousWord BrowserNext >>
toga
lappet faced vulture
egyptian vulture
george i of greece
stardust (spacecraft)
white backed vulture
may ball
wild
woodstock 1999
list of portmanteaux
anapaest
genesis (spacecraft)
self adjoint operator
lamos of the laestrygonians
telepylos
glise de la madeleine
iamb
secret affair
spondee
amphibrach
imperial war museum
calypso (moon)
bert williams
edward of westminster
gorsafawddacha'idraigodanheddogleddollnpenrhynareurdraethceredigion
dildo, newfoundland and labrador
the haydn quartet
orientability
mythology in literature
london, midland and scottish railway
grnet
gustave caillebotte
lenz's law
sex in advertising
madras (cloth)
america's promise
certified public accountant
joseph henry
one foot in the north
life magazine
lost cause
advanced packaging tool
mci communications
dpkg