Software Quality Index is a concept that is made up of different areas. Some
are common to all industries and some are specific to the vertical market they
represent. However they all seem to converge on five basic areas:
-
Requirements implemented
-
Adherence to a pre-defined process
-
Number of passed test cases
-
Severity of bugs generated
-
Customer satisfaction survey
For
each of the areas listed above, and any extra your company defines as
necessary, you need to create a way to merge the measurements you collect for
each of those areas. This poses an interesting problem since they are
not all measured the same way.
Items 1, 2 & 3 are similar in that they both are boolean types; yes/no and
pass/fail. You can easily identify what positively affects your quality
index.
-
The
key value for item #1 is the number of requirements implemented. If
your project starts with 100 requirements and only 70 were implemented, then
you have a 70% success rate or .7
-
The
key value for item #2 is whether the deliverables in the build followed the
defined quality path.
-
Was there a Requirements document?
-
Was the document peered reviewed?
-
Were there Code Review Meetings?
-
Were there Unit Test executed?
-
etc.
The answer to all of these questions is either yes or no. Once again,
you measure what was done against what was intended.
-
The
key value for item #3 is similar to #1. You measure whether a
specified test case passes or fails.
-
The
key value for item #4 is a little trickier since the very existence of a bug
signifies a deviation from quality. So you no longer measure whether
the bug exists, but rather how much it affects the quality of the software.
-
The
key value for item #5 is even trickier since in your customer satisfaction
survey, you may have items that may or may not adversely affect the quality
of the software.
Your customer satisfaction survey may contain questions such as:
In that example, a score of 1 (bad) severely affects the quality while a
score of 5 (good) enhances it.