Upload
doandan
View
216
Download
2
Embed Size (px)
Citation preview
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
Requirement Engineering
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
Requirement Engineering
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
Requirement Engineering
Factor/Criteria/Metric Paradigm
Software Quality Models
Some Quality Standards
18
Factor/Criteria/Metric Paradigm
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
Requirement Engineering
Factor/Criteria/Metric Paradigm
Software Quality Models
Some Quality Standards
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
Quality Models (cont.)
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 Models (cont.)
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)
41
Overview
Requirement Engineering
Factor/Criteria/Metric Paradigm
Software Quality Models
Some Quality Standards
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
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