Product revision quality actors

• 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. Product 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.

Look at McCall's list of quality factors. Identify examples of pairs that are Exercise 12.2 (a) indifferent, (b) complementary and (c) conflicting.

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

Table 12.1 Software quality criteria

Quality factor

Software 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 l he same software quality criterion can apply to more than one of the software quality factors.

Exercise 12.3

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

Measures can be:

• relative quantity measures where an attempt is made to quantify 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.

IX'fining quality is not enough. If we are to judge whether a system meets our requirements we need to be able to measure its qualities. For 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 while the developers would be concerned with quality criteria. The follow ing should be laid dow n 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 carry out some function. Another aspect of communicativeness w ould be how informative the error messages w ere, w hile 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 he conducted.

12.5 ISO 9126

Over the years, various lists of software quality characteristics have been put forward, such as those of McCall, described above, and of Boehm. A difficulty has been the lack of agreed definitions of the qualities of good software. The term 'maintainability' has been used, for example, to refer to the ease with which an error can be located and corrected in a piece of software, and also in a wider sense to includc the ease of making any changes. For some, 'robustness' has meant the software's tolerance of incorrect input, while for others it has meant the ability to change program code w ithout introducing unexpected errors. ISO 9126 standard was published in 1991 to tackle the question of the definition of software quality. This 13 page document was designed as a foundation upon which further, more detailed, standards could be built.

ISO 9126 identifies six softw are quality characteristics:

• functionality, which covers the functions that a software product provides to satisfy user needs;

• reliability, w hich relates to the capability of the software to maintain its level of performance;

• usability, which relates to the effort needed to use the softw are;

• efficiency, which relates to the physical resources used when the software is executed;

• maintainability, which relates to the effort needed to the make changes to the software;

• portability, which relates to the ability of the software to be transferred to a different environment.

ISO 9126 suggests sub-characteristics for each of the primary characteristics. It is perhaps indicativ e of the difficulties of gaining w idespread agreement that these sub-characteristics are outside the main standard and are given in the document for information only. They are useful as they clarify what is meant by the main characteristics.

Characteristic Sub-characteristics

Functionality Suitability

Accuracy Interoperability Compliance Security

Compliance refers to the degree to which the software adheres to application-related standards or legal requirements. Typically, these could he auditing requirements.

Interoperability and security are good illustrations of the efforts of ISO 9126 to clarify terminology. Interoperability refers to the ability of the software to interact with other systems. The framers of ISO 9126 have chosen this word rather than compatibility because the latter causes confusion with the characteristic referred to by ISO 9126 as replaceability (see below).

Characteristic Sub-characteristics

Reliability Maturity

Fault tolerance Recoverability

Maturity refers to the frequency of failure due to faults in a software product, the implication being that the more the software has been used, the more faults will have been uncovered and removed. It is also interesting to note that recoverability has been clearly distinguished from security, which describes the control of access to a system.

Characteristic Sub-characteristics

Usability Undcrstandability

Learnability Operability

Understandability is a clear quality to grasp, although the definition 'attributes that bear on the users' efforts for recognizing the logical concept and its applicability' in our view actually makes it less clear!

Note how learnability has been distinguished from operability. A software tool might be easy to learn but time-consuming to use because, say. it uses a large number of nested menus. This is fine for a package that is used only intermittently, but not where the system is used for several hours each day by the end user. In this case, learnability has been incorporated at the expense of operability.

Characteristic Sub-characteristics

Efficiency Time behaviour

Resource behaviour

Maintainability Analysability Changeability Stability Testability

Analysability is the quality that McCall called diagnosability, the ease with which the cause of a failure can be determined. Changeability is the quality that others have called flexibility, the latter name is perhaps a better one as changeability has a slightly different connotation in plain English - it implies that the suppliers of the software are always changing it!

Stability, on the other hand, does not mean that the software never changes: it means that there is a low risk of a modification to the software hav ing unexpected effects.

Characteristic Sub-characteristic Portability Adaptability

Conformance, as distinguished from compliance, relates to those standards that have a bearing on portability. The use of a standard programming language common to many software/hardware environments is an example of conformance. Replaceability refers to the factors that give 'upwards compatibility' between old software components and the new ones, 'downwards compatibility' is specifically excluded from the definition.

ISO 9126 prov ides some guidelines for the use of the quality characteristics. The fact that the relative importance of different quality characteristics will depend on the type of product under examination is stressed. Thus reliability will be of particular concern with safety-critical systems while efficiency will be crucial for some real-time systems. Eor interactive end user systems, the key quality might be usability. Once the requirements for the software product have been established, the following steps are laid down:

Quality metrics selection Measurements that correlate to the characteristics of each quality have to be identified. No specific guidance is given by the ISO 9126 standard on the applicability of the various measurements that might be used.

Ratings level definition The metrics used must be mapped onto scales that indicate the degree to which the requirements have been satisfied. For example, in one application 'time behaviour' in the sense of response lime might be important. For a key transaction, actual response times might be mapped onto quality scores:

response time (seconds) quality score

Upwards compatibility means the capability tor files created by the old version of the software to be used by newer versions.

lnstallability

Conformance

Replaceability

Assessment criteria definition The way that the quality scores are combined or summarized to give an overall view of the product has to he defined. The software product has now to he evaluated hy measuring its qualities, converting them to quality scores or ratings, and summarising the ratings to obtain an overall judgement. ISO 9126 does not specify how this has to be done, only that some method must be devised.

One approach, for example, recognizes that some quality rating levels will be mandatory. If a product fails to reach any of the mandator) rating levels it must be rejected regardless of how good it might be in other ways. Other characteristics can he desirable but not essential. For these desirable characteristics it is possible to give a rating in the range 1-5, say. reflecting how important they are. Above we have shown in the case of time behaviour how its quality in a particular product can be awarded a quality score on a scale 0 to 5. The scores for the more or less important qualities can be given due weight by multiplying each one by its importance weighting. These weighted scores can then be summed to obtain an overall score for the product. The scores for various products can then be compared to get a first cut order of preference. For example, the quality of two products might need to be compared on the grounds of usability, efficiency and maintainability. The importance of each of these qualities might be rated as 3. 4 and 2 respectively, out of a possible maximum of 5. Quality tests could result in the scores shown in fable 12.2.

Table 12.2 Quality rating scores

pnuluct quality

importance rating (a)

product A

prtnluct H

quality score (b)

weighted score (a xb)

quality weighted score (c) score (axe)

usability

3

1

3

3 9

efficiency

4

f ém

8

2 8

maintainability

2

3

6

1 2

overall

17

19

An attempt was made to use the ISO 9126 standard to define the qualities needed in the software to control systems in an unmanned station in the Antarctic that was to perform scientific experiments that were to be monitored and controlled by satellite link from Italy. Useful advice that came out of this was that the qualities required can vary from component to component within the system and that therefore quality definition at the level of the overall system is not always appropriate. The researchers also found that the most important quality for this application was availability, which was a mixture of the ISO 9126 top level qualities of reliability and maintainability - separating the two elements was in practice very difficult.

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