27
Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Somme rville 1 CSC-3325: Chapter 6 Title : The Software Quality Reading: I. Sommerville, Chap: 24

Soft. Eng. II, Spr. 02Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 6 Title : The Software Quality Reading: I. Sommerville, Chap: 24

  • View
    217

  • Download
    2

Embed Size (px)

Citation preview

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 1

CSC-3325: Chapter 6

Title : The Software Quality

Reading: I. Sommerville, Chap: 24

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 2

Topics covered

Software Quality management Process of quality assurance Quality reviews Software standards Software metrics Product quality metrics

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 3

Software quality management

Concerned with ensuring that the required level

of quality is achieved in a software product

Involves defining appropriate quality standards

and procedures and ensuring that these are

followed

Should aim to develop a ‘quality culture’ where

quality is seen as everyone’s responsibility

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 4

What is quality? In its simple understanding, Quality means

that a product should meet its specification This is problematical for software systems

Tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.)

Some quality requirements are difficult to specify in an unambiguous way

Software specifications are usually incomplete and often inconsistent

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 5

Software quality attributes

Safety Understandability PortabilitySecurity Testability UsabilityReliability Adaptability ReusabilityResilience Modularity EfficiencyRobustness Complexity Learnability

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 6

Quality management activities

Quality assurance Establish organizational procedures and

standards for quality Quality planning

Select applicable procedures and standards for a particular project and modify these as required

Quality control Ensure that procedures and standards are

followed by the software development team

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 7

ISO 9000 ISO 9000 is an iinternational set of standards for

quality management in all industries … Applicable to a range of organizations from

manufacturing to service industries… Each country has its own version… ISO 9001 applicable to organizations which design,

develop and maintain products… It is a generic model of the quality process… Must be

instantiated for each organization… ISO 9000-3 interprets ISO 9000 for software

engineering…

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 8

ISO 9000 certification

Quality standards and procedures should be

documented in an organizational quality

manual

External body may certify that an organisation’s

quality manual conforms to ISO 9000 standards

Customers are, increasingly, demanding that

suppliers are ISO 9000 certified

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 9

ISO 9000 and quality management

Project 1quality plan

Project 2quality plan

Project 3quality plan

Project qualitymanagement

Organizationquality manual

ISO 9000quality models

Organiza tionquality process

is used to develop instantiated as

instantiated as

documents

Supports

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 10

The quality of a developed product is influenced by the quality of the production process

Particularly important in software development as some product quality attributes are hard to assess

However, there is a very complex and poorly understood relation between software processes and product quality…

Process quality assurance

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 11

Quality reviews The principal method of validating the quality of a

process or of a product Group examined part or all of a process or system

and its documentation to find potential problems There are different types of review with different

objectives Inspections for defect removal (product) Reviews for progress assessment (product and process) Quality reviews (product and standards)

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 12

Quality reviews Objective is the discovery of system

defects and inconsistencies Any documents produced in the

process may be reviewed Review teams should be relatively

small and reviews should be fairly short Review should be recorded and records

maintained

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 13

Comments made during the review should be documented and classified:

No action. No change to the software or documentation is required.

Refer for repair. Designer or programmer should correct an identified fault.

Reconsider overall design. The problem identified in the review impacts other parts of the design. Some overall judgement must be made about the most cost-effective way of solving the problem.

Review results

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 14

Key to effective quality management May be international, national,

organizational or project Product standards define

characteristics that all components should exhibit e.g. a common programming style

Process standards define how the software process should be conducted

Software standards

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 15

Encapsulation of best practice. Avoids repetition of past mistakes

Framework for QA process - it involves checking standard compliance

Provide continuity. New staff can understand the organisation by understand the standards applied

Importance of standards

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 16

Problems with standards

Not seen as relevant and up-to-date by software engineers

Involve too much bureaucratic form filling

Unsupported by software tools and manual work is involved to maintain standards

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 17

Involve practitioners in development Engineers should understand the rationale

underlying a standard Review standards and their usage regularly.

Standards can quickly become outdated and this reduces their credibility amongst practitioners

Detailed standards should have associated tool support. Excessive clerical work is the most significant complaint against standards

Standards development

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 18

Any type of measurement which relates to a software system, process or related documentation

Lines of code in a program, number of person-days required to develop a component, the number of errors per module…

Allow the software and the software process to be quantified

Measures of the software process or product Should be captured automatically if possible

Software metrics

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 19

A software property can be measured

It is difficult to relate what can be measured to

desirable quality attributes

There is a relationship between what we can

measure and what we want to know

This relationship has been formalized and validated

Metrics assumptions

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 20

Internal and external attributes

Reliability

Number of procedureparameters

Cyclomatic complexity

Program size in linesof code

Number of errormessages

Length of user manual

Maintainability

Usability

Portability

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 21

Design Metrics Cohesion

How closely are the parts of a component related

Coupling How independent is a component

Understandability How easy is it to understand a component’s

function Adaptability

How easy is to change a component

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 22

The whole area is still a research area rather than practically applicable.

Validation of quality metrics

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 23

Programs quality metrics Design metrics also applicable to programs Other metrics include

Length. The size of the program source code Cyclomatic complexity. The complexity of program control Length of identifiers Depth of conditional nesting

Anomalous metric values suggest a component may contain an above average number of defects or may be difficult to understand

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 24

Common Metrics for programs

Length of code is simple but experiments have

suggested it is a good predictor of problems

Cyclomatic complexity can be misleading

Long names should increase program

understandability

Deeply nested conditionals are hard to

understand. May be a contributor to an

understandability index

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 25

Metrics still have a limited value and are not widely collected

Relationships between what we can measure and what we want to know are not well-understood

Lack of commonality across software process between organizations makes universal metrics difficult to develop

Problems with Metrics

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 26

Key points Software quality management is

concerned with ensuring that software meets its required standards

Quality assurance procedures should be documented in an organisational quality manual

A project quality plan should identify project-specific quality requirements

Software standards are an encapsulation of best practice

Soft. Eng. II, Spr. 02 Dr Driss Kettani, from I. Sommerville 27

Key points Reviews are the principal means of

implementing quality assurance Metrics gather information about both

process and product Control metrics provide management

information about the software project. Predictor metrics allow product attributes to be estimated

Quality metrics should be used to identify potentially problematical components