Chapter 24

Three principal concerns of Software quality management for software systems

- At the organizational level, quality management is concerned with establishing a framework of organizational processes and standards that will lead to high-quality software. This means that the quality management team should take responsibility for defining the software development processes to be used and standards that should apply to the software and related documentation, including the system requirements, design, and code. - At the project level, quality management involves the application of specific quality processes, checking that these planned processes have been followed, and ensuring that the project outputs are conformant with the standards that are applicable to that project. - Quality management at the project level is also concerned with establishing a quality plan for a project. The quality plan should set out the quality goals for the project and define what processes and standards are to be used.

The quality management team has to consider whether or not the software is fit for its intended purpose. It involves answering questions:

- Have programming and documentation standards been followed in the development process? - Has the software been properly tested? - Is the software sufficiently dependable to be put into use? - Is the performance of the software acceptable for normal use? - Is the software usable? - Is the software well structured and understandable?

The review process is normally structured into three phases:

- Pre-review activities: These are preparatory activities that are essential for the review to be effective. During review preparation, the team may meet to get an overview of the software to be reviewed. - The review meeting: During the review meeting, an author of the document or program being reviewed should 'walk through' the document with the review team. The review chair should sign a record of comments and actions agreed during the review. - Post-review activities: After a review meeting has finished, the issues and problems raised during the review must be addressed. This may involve fixing software bugs, refactoring software so that it conforms to quality standards, or rewriting documents. After changes have been made, the review chair may check that the review comments have all be taken into account.

If an organization is to be ISO 9001 conformant, it must document how its processes relate to these core processes:

Product Delivery Processes • Business Acquisition • Design and Development • Test • Production and Delivery • Service and Support Supporting Processes • Business Management • Supplier Management • Inventory Management • Configuration Management

Quality plan outline made by Humphrey

Product introduction: A description of the product, its intended market, and the quality expectations for the product Product plans: The critical release dates and responsibilities for the product, along with plans for distribution and product servicing. Process descriptions: The development and service processes and standards that should be used for product development and management. Quality Goals: The quality goals and plans for a product, including an identification and justification of a critical product quality attributes. Risks and Risk Management: The key risks that might affect product quality and the actions to be taken to address these risks.

Quality control

The application of quality processes to weed out products that are not of the required level of quality.

Quality assurance (QA)

The definition of processes and standards that should lead to high-quality products and the introduction of quality processes into the manufacturing process.

Quality planning

The process of developing a quality plan for a project. The quality plan should set out the desired software qualities and describe how theses are to be assessed. Formalized quality planning is an integral part of plan-based development processes. Agile methods, adopt a less formal approach to quality management.

ISO 9001.

There is an international set of standards that can be used in the development of quality management systems in all industries

Process standards

These define the processes that should be followed during the software development. They should encapsulate good development practice. Process standards may include definitions of specification, design and validation processes.

A software metric

a characteristic of a software system, system documentation, or development process that can be objectively measured.

Software measurement

concerned with deriving a numeric value or profile for an attribute of a software component, system, or process.

Predictor metrics

help you predict characteristics of the software. Their associated with the software itself and are sometimes known as 'product metrics'

The key stages in this components measurement process are:

o Choose measurements to be made: The questions that the measurement is intended to answer should be formulated and the measurements required to answer these questions defined. o Select components to be assessed: You may not need to assess metric values for all of the components in a software system. o Measure component characteristics: The selected components are measured and the associated metric values computed. o Identify anomalous measurements: After the component measurements have been made, you them compare them with each other and to previous measurements that have been recorded in a measurement database. o Analyze anomalous components: When you have identified components that have anomalous values for your chosen metrics, you should examine them to decide whether or not these anomalous metrics values mean that the quality of the component is compromised.

Possible checks made during an inspection process include:

o Data faults o Control faults o Input/output faults o Interface faults o Storage management faults o Exception management faults

Product metrics fall into two classes

o Dynamic metrics, which are collected by measurements made of a program in execution. An example might be the number of bug reports or the time taken to complete a computation. o Static metrics, which are collected by measurements made of representations of the system, such as the design, program, or documentation. Examples of static metrics are the code size and the average length of identifiers used.

List of static software product metrics:

o Fan-in/Fan-out o Length of Code o Cyclomatic complexity: This is a measure of the control complexity of a program. This control complexity may be related to program understandability. o Length of identifiers: This is a measure of the average length of identifiers (names of variable, classes, methods, etc.) in a program. o Depth of conditional nesting o Fog index

Boehm suggested that there were 15 important quality attributes:

o Safety o Security o Reliability o Resilience o Robustness o Understandability o Testability o Adaptability o Modularity o Complexity o Portability o Usability o Reusability o Efficiency o Learnability

Software standards are important for three reasons:

o Standards capture wisdom that is of value to the organization. They are based on knowledge about the best or most appropriate practice for the company. This knowledge of often only acquired after a great deal of trial and error. o Standards provide a framework for defining what 'quality' means in a particular setting. o Standards assist continuity when work carried out by one person is taken up and continued by another.

Product metrics

predictor metrics that are used to measure internal attributes of a software system.

Control metrics

support process management

Product standards

these apply to the software product being developed. They included document standards, such as the structure of requirements documents, documentation standards, such as a standard comment header for an object class definition, and coding standards, which define how a programming language should be used.