Product revision quality factors

• Maintainability The effort required to locate and fix an error in an operational program.

• Testability The effort required to test a program to ensure it performs its intended function.

• Flexibility The effort required to modify an operational program. Prcxiuct transition quality factors

• Portability The effort required to transfer a program from one hardware configuration and/or software system environment to another.

• Reusability The extent to which a program can be used in other applications.

• Interoperability The effort required to couple one system to another.

Ix)ok at McCalPs list of quality factors. Identify examples of pairs that are Exercise 12.2 (a) indifferent, (b) complementary and (c) conflicting.

McCall's software quality factors reflect the external view of software that users w ould have. For instance, usability w ould be a key concern of users. These quality factors have to be translated into internal factors of which the developers would be aware - software quality criteria (Table 12.1).

Table 12.1 Software quality criteria

Quality factor

Soft wan* quality criteria

Correctness

Reliability

Efficiency

Integrity

Usability

Maintainability

Testability Flexibility Portability

Reusability

Interoperability traceability, consistency, completeness error tolerance, consistency, accuracy, simplicity execution efficiency, storage efficiency access control, access audit operability, training, communicativeness, input/output volume, input/output rate consistency, simplicity, conciseness, modularity, self-descriptiveness simplicity, modularity, instrumentation, self-descriptiveness modularity, generality, expandability, self-descriptiveness modularity, self-descriptiveness, machine independence, software system independence generality, modularity, software system independence, machine independence, self-descriptiveness modularity, communications commonality, data commonality

I he same sottware quality criterion can apply to more than one of the software quality factors.

Exercise 12.3

Measures can be:

• relative quantity measures where an attempt is made to quantity the presence of the quality, or

• binary measures where the quality is deemed either to be present or not present.

Some writers use the term metric interchangeably with measure. Software measurement specialists would, however, maintain that there is a technical difference between the two terms.

The same software quality criteria often appear for more than one software quality factor. What is the significance of this?

Defining quality is not enough. If we are to judge whether a system meets our requirements we need to be able to measure its qualities. F;or each criterion, one or more measures have to be invented to assess the degree to which the quality is present.

Any good relative measure must be able to relate the number of units to the maximum possible in the circumstances. The maximum number of faults in a program, for example, is going to be related to the size of the program, so a measure of 'faults per thousand lines of code' is more helpful than 'total faults in a program' as a means of judging the quality of a program.

Trying to find measures for a particular quality helps to clarify ideas about what that quality really is. What is being asked is, in effect, 'how do we know when we have been successful?' An answer to this is essential if the quality objectives are to be communicated to a large number of people.

In some cases we can measure the quality directly w hile in other cases the thing being measured is not the quality itself but an indicator of the degree to w hich the quality is present. By identifying measures, management are setting targets for project team members so care has to be taken that an improvement in the measured attribute is always going to be valid. For example, the number of errors found in program inspections could be counted. This count could, of course, be improved by allowing more errors to go through to the inspection stage rather than eradicating them earlier - which is not quite the point!

In general, the user of software would be concerned with measuring what McCall called quality factors w hile the developers would be concerned w iih quality criteria. The following should be laid down for each quality:

• test - the practical test of the extent to w hich the attribute quality exists;

• worst - the worst acceptable value;

• plan - the value that it is planned to achieve;

• best - the best value that appears to be feasible (the 'state of the art' limit); this would be a level that is know n to have been achieved elsewhere;

• now - the value that applies currently.

In order to derive these quality specifications it is often necessary to break dow n a quality criterion into further sub-criteria. Take the quality criterion 'communicativeness', which contributes to the quality factor •usability*. One aspect of this might be the ease of understanding of the menu structure, in particular, how easy it is to find the command to cany out some function. Another aspect of communicativeness would be how informative the error messages were, while yet another would be the clarity of the 'help' pages.

Suggest quality specifications for a word processing package. Give particular Exercise 12.4 attention to the way that practical tests of these attributes could be conducted.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment