Information Technology Reference
In-Depth Information
5. Collect, validate, and analyze the data in real time to provide feedback to
projects for corrective action.
6. Analyze the data in a post mortem fashion to assess conformance to the goals
and to make recommendations for future improvements.
5.5
SOFTWARE QUALITY METRICS
Software quality metrics are associated more closely with process and product metrics
than with project metrics. Software quality metrics can be divided further into end-
product quality metrics and into in-process quality metrics. The essence of software
quality is to investigate the relationships among in-process metrics, project character-
istics, and end-product quality and, based on the findings, to engineer improvements
in both process and product quality.
Software quality is a multidimensional concept. It has levels of abstraction be-
yond even the viewpoints of the developer or user. Crosby, (1979) among many
others, has defined software quality as conformance to specification. Very few end
users will agree that a program that perfectly implements a flawed specification is a
quality product. Of course, when we talk about software architecture, we are talk-
ing about a design stage well upstream from the program's specification. Juran and
Fryna (1970) proposed a generic definition of quality. He said products must possess
multiple elements of fitness for use. Two of his parameters of interest for software
products were quality of design and quality of conformance. These are separate de-
signs from implementation and may even accommodate the differing viewpoints of
developer and user in each area. Moreover, we should view quality from the en-
tire software life-cycle perspective, and in this regard, we should include metrics
that measure the quality level of the maintenance process as another category of
software quality metrics (Kan, 2002). Kan (2002) discussed several metrics in each
of three groups of software quality metrics: product quality, in-process quality, and
maintenance quality by several major software developers (HP, Motorola, and IBM)
and discussed software metrics data collection. For example, by following the GQM
method (Section 5.4), Motorola identified goals, formulated questions in quantifi-
able terms, and established metrics. For each goal, the questions to be asked and
the corresponding metrics also were formulated. For example, the questions and
metrics for “Improve Project Planning” goal (Daskalantonakis, 1992) are as follows:
Question 1: What was the accuracy of estimating the actual value of project schedule?
Metric 1: Schedule Estimation Accuracy (SEA)
Actual Project Duration
Estimated Project Duration
SEA
=
(5.11)
Question 2: What was the accuracy of estimating the actual value of project effort?
Metric 2: Effort Estimation Accuracy (EEA)
Actual Project Effort
Estimated Project Effort
EEA
=
(5.12)
 
Search WWH ::




Custom Search