CSCI 630 - Software Engineering
Process & Project Metrics
- quantitative measures
- give software engineers insight into the efficacy of
- the software process, and
- the projects conducted using the process
- measuring allows the organization & team to
- characterize
- evaluate
- predict
- improve
- quantitative measures are objective rather than subjective
- the same measures & metrics may serve two purposes
- organizational process improvement happens over a long period
of time
- project management is largely concerned with productivity
and quality metrics

- terminology
- measure - provides a quantitative indication of the size of some
product or process attribute
- measurement - is the act of obtaining a measure
- metric - is a quantitative measure of the degree to which a system,
component, or process possesses a given attribute
- error - a mistake found and corrected before release
- defect - a mistake found by the user after release

- data should be collected so that process and product indicators can be
ascertained

- over a long period of time we can use these metrics to improve the
process
- process metrics
- private process metrics (e.g. defect rates by individual or module)
are only known to by the individual or team concerned
- public process metrics (aggregation of private process metrics) enable
organizations to make strategic changes to improve the software process
- statistical software process improvement helps an organization
to discover where they are strong and where they are weak

- statistical process control
- errors are categorized by their origin
- record cost to correct each error and defect
- count number of errors and defects in each category
- overall cost of errors and defects computed for each category
- identify category with greatest cost to organization
- develop plans to eliminate the most costly class of errors and defects
or at least reduce their frequency
- project metrics
- the team can use software project metrics to
- adapt project workflow and technical activities
- avoid development schedule delays
- mitigate potential risks
- assess product quality on an ongoing basis



- software measurement
- integrating metrics with software process
- many software developers do not collect measures
- without measurement it is impossible to determine whether a process
is improving or not
- baseline metrics data should be collected from a large, representative
sampling of past software projects
- getting this historic project data is very difficult, if the previous
developers did not collect data in an ongoing manner
- it has been estimated that up to three years are required before useful
process indicators are available
- metrics for small organizations
- most software organizations have fewer than 20 software engineers
- choose simple metrics that provide value to the organization and don't
require a lot of effort to collect
- even small groups can expect a significant return on the investment
required to collect metrics, if this activity leads to process improvement
Notes and figures from:
- Software Engineering: A Practitioner's Approach, 6th Edition, by Roger S
Pressman, R.S. Pressman & Associates, McGraw-Hill, 2005