lecture 2: software quality factors, models and...

Lecture 2: Software Quality

Factors, Models and Standards

Software Quality Assurance (INSE 6260/4-UU)

Winter 2016

2

INSE 6260/4-UU

Software Quality

Assurance

Software Quality

Factors and Models

Metrics

Quality Assurance

Inspection Testing

Techniques Reachability

Analysis

3

Overview

Requirement Engineering

Factor/Criteria/Metric Paradigm

Software Quality Models

Some Quality Standards

4

Some Software Development

Life Cycles

SDLC model (~waterfall)

Prototyping Model

Spiral Model

Evolutionary Models

5

The Prototyping Model

Req. determination By the costumer

Prototype Design

Prototype implementation

Prototype Evaluation By customer

Req. fulfilled?

System Tests & Acceptance tests

System Conversion

Demands for Corrections, Changes and additions

System Operation and maintenance

Yes

No

6

Spiral Model

An iterative process, at each iteration,

the following activities are performed:

Planning

Risk analysis and resolution

Engineering activities according to the

stage of the project: design, coding,

testing, installation and release

Customer evaluation, including comments,

changes and additional requirements, etc.

7

Spirale Cycle

Operational

Prototype

1 2 3

Risk analysis

1

2

3 Determine

objectives,

alternatives,

constraints

Requirements

Plan, life cycle

plan

I. II.

III.

IV.

Concept of

Operation Development

plan Validation of

requirements

Detailed

design

Coding

etc.

Simulation, models, benchmarks

review

Planning

Evaluation by the customer

Engineering

8

Evolutionary Models

Many variants available

Product development evolves through increments evolutionary prototype

Evolutionary process model (B. Boehm, 1988) "model whose stages consist of expanding

increments of an operational software product, with the direction of evolution being determined by operational experience"

9

Goal: determine the client’s desires

Requirements Elicitation, Capture

and Analysis

Complex task because of

What the client says

What the clients doesn't say

What the designer understands

What the designer interprets


10

Requirement List should be Described and reviewed

Approved by the client

Identifiable and verifiable

Requirements are the basis for the development process

TRACEABILITY is important


11

Requirement Engineering: TRAPS

Hidden Evidences

Implicit

Ambiguous

Imprecise

Incomplete

12

How to Avoid Traps

• Formalization

- Formal or Semi-formal methods

- Modeling

- Communication between the client and

designer

• Prototyping

- Use tools for rapid prototyping

- Simulations

• Audits and Reviews

13

Modeling: Engineer Act

Why Modeling?

• High Level Abstraction Reasoning

- Focus on important mechanisms only

- Don't get into implementation details (you will be

lost!)

• Design and requirements confrontation:

Traceability

• Test production guidance

14

A Model Works Under Hypothesis

• Hypothesis include

- System’s environment

- Limitations inherent to the language and tools

you are obliged to use

• A model worth nothing if not accompanied by

clearly stated hypothesis

15

Models and Properties

• Models are for:

- Documentation

- Verification

- Reference to subsequent implementations

- Reference to testing

• A model is meant to be checked against properties

- Think of properties first!

16

• Formal syntax and semantics

• V&V

- Qualitative vs. quantitative analysis

- Simulation

- Reachability analysis

• Model checking

• Verification by abstraction

• Automatic code generation

• Test sequence generation

Advantages of using Formalization

17

Overview





18


Factor

Criteria Criteria Criteria

Metrics Metrics Metrics

Management

oriented view

Quality

attributes

Quantitative

measures of

these

attributes

19

Software Measurement and Metrics

Software measurement is concerned with

deriving a numeric value for an attribute of a

software product or process

This allows for objective comparisons between

techniques and processes

Although some companies have introduced

measurement programmes, most organisations

still do not make systematic use of software

measurement

20

Software Metric

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

Used to quantify the software and the software

process

May be used to predict product attributes or to control

the software process

21

Classification of Attributes or

Software Qualities

Internal vs. external

External visible to users

Internal concern developers

Product vs. process

Our goal is to develop software products

The process is how we do it

Internal qualities affect external qualities

Process quality affects product quality

22

Internal and External Attributes

Reliability

Number of procedure

parameters

Cyclomatic tic complexity

Program size in lines

of code

Number of err or

messages

Length of user manual

Maintainability

Usability

Portability

23

Cyclomatic Complexity

Cyclomatic complexity is a software metric in

computational complexity theory

It was developed by Thomas McCabe and is used

to measure the complexity of a program

It directly measures the number of linearly

independent paths through a program's source

code

24

Cyclomatic Complexity

Cyclomatic complexity is computed using

a graph that describes the control flow of

the program. The nodes of the graph

correspond to the commands of a

program. A directed edge connects two

nodes if the second command might be

executed immediately after the first

command

C = E-N+2P

25

Overview





26

McCall’s Quality Model

Quality Software

Product operation factors

Product revision factors

Product transition factors

Correctness Reliability Efficiency Integrity Usability

Maintainability Flexibility Testability

Portability Reusability Interoperability

27

Quality Models

Product operation Correctness-Does it do what I want? Reliability -Does it do it accurately all the time? Efficiency -Will it run on my machine as well as it can? Integrity -Is it secure? Usability-Can I run it? Product revision Maintainability-Can I fix it? Flexibility-Can I change it? Testability-Can I test it? Product transition Portability-Will I be able to use on another machine? Reusability-Will I be able to reuse some of the software? Interoperability -Will I be able to interface it with another machine?

28

Quality Models (cont.)

Product revision includes

Maintainability (the effort required to locate and

fix a fault in the program within its operating

environment)

Flexibility (the ease of making changes

required by changes in the operating

environment) and

Testability (the ease of testing the program, to

ensure that it is error-free and meets its

specification)

29


Product transition is all about

Portability (the effort required to transfer a

program from one environment to another)

Reusability (the ease of reusing software in a

different context) and

Interoperability (the effort required to couple the

system to another system)

30


Quality of product operations depends on

Correctness (the extent to which a program

fulfils its specification)

Reliability (the systems ability not to fail)

Efficiency (further categorized into execution

efficiency and storage efficiency and generally

meaning the use of resources, e.g. processor

time, storage)

Integrity (the protection of the program from

unauthorized access) and

Usability (the ease of the software)

31

McCall’s Quality Model

11 Quality factors on the Right side 23 Quality criteria on the left side

32

11 Quality factors on the Right side 23 Quality criteria on the left side

33

Evans and Marciniak vs. Deutsch

and Willis

34

Evans and Marciniak vs. Deutsch

and Willis

35

Boehm's Software Quality

Tree

37

ISO/IEC 9126

39

Dromey's Quality Model

41

Overview





42

ISO 9000

A set of quality standards developed so that purchasers of

goods can have confidence that suppliers of these goods have

produced something of acceptable quality

ISO 9000 certification has become a widely required

international standard

Any supplier who is not ISO 9000 certified will find it difficult to

sell their goods

The ISO 9000-3 standard describes how to apply the general

ISO 9000 standard to the software industry

The ISO standard addresses design, development, production,

installation and maintenance issues

The emphasis in the ISO standard is on documentation of the

process and the managing of the process

43

ISO 9000-3 SQA Standard

Control of inspection and test equipment

Inspection and test status

Control of nonconforming product

Corrective action

Handling, storage, packaging and delivery

Control of quality records

Internal quality audits

Training

Servicing

Statistical techniques

44

Capability Maturity Model

Integration (CMMI)

45

Capability Maturity Model

Integration

The Capability Maturity Model for Software (CMMI) is a five level model laying out a generic path to process improvement for a software organization

1. Initial – ad hoc

2. Repeatable – basic management processes

3. Defined – management and engineering processes documented,

standardized, integrated, and actually used

4. Managed – measured and monitored and controlled using measurements

5. Optimizing – Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies

46

CMMI Levels and Key Process Areas

1. Initial level

• No formalized procedures, project plans, cost estimates

• Tools not adequately integrated

• Many problems overlooked/ignored

• Maintenance very difficult

• Generally ad-hoc processes

2. Repeatable level

• Requirements management

• Software Project planning

• Software project tracking and oversight

• Software subcontract management

• Software quality assurance

• Software configuration management

47

3. Defined level

• Organization process focus

• Organization process definition

• Training Program

• Integration software management

• Software product engineering

• Inter-group coordination

• Peer reviews

4. Managed level

• Quantitative process management

• Software Quality management

5. Optimizing level

• Defect prevention

• Technology change management

• Process change management

CMMI Levels and Key Process Areas

49

References

Chap 1, 2, 3 &4 of “Software Quality

Assurance” Daniel Galin

lecture 2: software quality factors, models and...

Documents