University of Zimbabwe

Department of Computer Science

HCT210: Software Engineering

Unit 4 : Software Quality

Lecturer: Aldrin Muramba

Acknowledgements: main course text: “Roger S. Pressman , Software engineering: A practitioner’s approach”, 7th edition, 2010

Page 1 of 103
 Unit 4: Software Quality

Unit Outline
• Software quality concepts
• Software Review techniques
• Software Quality Assurance (SQA)
• Software Testing
• Software Configuration Management

Page 2 of 103
 Unit 4: Software Quality

Software quality concepts

• Software quality is an effective software process
applied to in a manner that creates a useful product
that provides measurable value for those who produce
it and those who use it
• Of importance are the three (3) key aspects:
 Effective software process: involves the software
engineering practices, infrastructure, management aspects
that is used in the software process
 Useful product: encompasses the meeting of stakeholders’
functional and non-functional requirements
 Adding value to producers and users: better business
value to both in profitability, productivity, availability of
information
Page 3 of 103
 Unit 4: Software Quality

Software quality: dimensions

• There are various quality dimensions:
“viewpoints” from which quality is considered:
i. Performance quality: are content, functions and
features delivered in a way that add value to the
user?
ii. Feature quality: do features surprise and delight end
users?
iii. Reliability: are features and capability delivered
without failure & errors? Is it available when
needed?
iv. Conformance: does it conform to local and external
standards? (of design, coding, etc)

Page 4 of 103
 Unit 4: Software Quality

Software quality: dimensions (contd)

v. Durability: can it be maintained/changed or
corrected/debugged without unintended side
effects? Will changes reliability to degrade?
vi. Serviceability: can it be maintained/changed or
corrected/debugged within a short time? Can those
doing changes get the required information?
vii. Aesthetics: is the software beautiful? (even though
subjective)
viii. Perception: prejudice also influences perceptions of
quality, e.g. reputation, origin, etc of developers

Page 5 of 103
 Unit 4: Software Quality

Software quality factors

• ISO 9126 provides six (6) key software quality
attributes:
1. Functionality: degree to which requirements
are satisfied; with sub-attributes: suitability,
accuracy, interoperability, compliance, security
2. Reliability: amount of time the software is
available for use; with sub-attributes: maturity,
fault tolerance, recoverability
3. Usability: degree of ease of use; with sub-
attributes: understandability, learnability,
operability

Page 6 of 103
Unit 4: Software Quality

Software quality factors (contd)

4. Efficiency: degree to which software makes
optimal use of system resources; with sub-
attributes: time behaviour, resource behaviour
5. Maintainability: ease with which software may
be repaired; with sub-attributes: analysability,
changeability, stability, testability
6. Portability: ease with which the software can be
transported from one environment to another;
with sub-attributes: adaptability, installability,
conformance, replaceability.

Page 7 of 103
 Unit 4: Software Quality

Software quality concepts

1. Quality / cost dilemma
• In real life; organisations are faced with two
choices: “good enough” software that works and
has some imperfections; versus perfect software
which has all imperfections eliminated
• The “good enough” software allows the software
to be delivered on time and be used to deliver
“most” of the value; which “perfect software”
takes so much time that it may be delivered too
late when the business opportunity is gone
• The balance between the two is a dilemma; and
can be adjusted depending on various factors,
e.g. business domain, criticality, etc
Page 8 of 103
 Unit 4: Software Quality

Software quality concepts

2. The Cost of Quality
• Achieving quality software is costly; but software that lacks quality will
also be (even more) costly
• Cost of quality can be categorised into prevention, appraisal and
failure:
1. Prevention costs: Quality control & assurance planning, design
reviews, test planning, training
2. Appraisal costs: technical reviews, equipment calibration and
maintenance, testing and debugging
3. Failure costs: subdivided into internal failure costs (before shipping to
client) and external failure costs (after shipping)
1. Internal failure costs: Include rework, repair, metrics collection for analysis,
rework caused by side-effects of fixing other errors.
2. External failure costs: Include complaint resolution, product return and
replacement, help line support, and warranty work
• Many researches have shown that the average cost of defect fixing
exponentially increases from requirements, to design, to coding, to
testing, and finally to maintenance

Page 9 of 103
 Unit 4: Software Quality

Software quality concepts

3. Risks
• Developers should keep in mind the risk of
failure of the software; which may include:
Loss of business
Reputational damage
Loss of life
Litigation and its implications: claims, imprisonment

Page 10 of 103
 Unit 4: Software Quality

Software quality concepts

4. Quality and Security
• Security is also part of good quality software
• Web-based systems (being accessible over the
public Internet) are most vulnerable; and they
continue to play a critical part of modern life
• Software security thus be carefully considered
at every stage and level: analysis, design,
architecture, coding, infrastructure in order to
prevent hacking
• Thus software must exhibit high quality in terms
of security
Page 11 of 103
 Unit 4: Software Quality

Software quality concepts

5. Effect of Management Actions
• Software quality is not only affected by
technical decisions; but also by management
decisions
• The best technical practices can be subverted by
poor management decisions and practices:
i. Unrealistic deadlines and estimates
ii. Scheduling may be changed when time is short
(e.g. by testing a component without its
dependencies)
iii. Poor (or non-existent) risk management practices

Page 12 of 103
 Unit 4: Software Quality

Achieving Software quality

• There are four (4) broad categories that help in
achieving software quality”
1. Software engineering methods
 Analysis and design techniques and methodologies
2. Project management techniques
 Estimation, scheduling, and risk management
3. Quality control
 Activities that analyse when quality is not met; and
corrective action is taken
4. Quality Assurance
 Establishes the infrastructure that supports solid software
engineering methods, rational project management and
quality control
Page 13 of 103
 Unit 4: Software Quality

Software Review Techniques

• Software review act as a “filter” for the software
process: applied at various stages to “purify”
software engineering work products.
• Reviews are used to:
Uncover errors that can then be removed early
Purify the software analysis, design, coding, and testing
activities
Catch large classes of errors that escape the originator
more than other practitioners
Have been known to 70% effective in uncovering design
flaws (which constitute 50-65% errors in software)
• Reviews can be informal or formal

Page 14 of 103
 Unit 4: Software Quality

Technical Review Model

• The basic model for any technical review
involves; and the extent to which each is done
determines the formality of the review:
1. Planning and preparation
2. Meeting structure
3. Roles individuals play
4. Correction and Validation
• Degree of formality depends on product type,
project timelines, the people involved, etc

Page 15 of 103
 Unit 4: Software Quality

Informal Review
• Usually involve “desk checks” and casual
meetings
• Can be applied to any work product; where
team members just sit to review / walkthrough
work products without strict prior meeting
agenda or format
• Errors are noted that then corrected
• Another example is pair programming as
advocated by XP
Page 16 of 103
 Unit 4: Software Quality

Formal Technical Review (FTR)

• A quality control activity performed by the project
team
• Objectives are
To uncover errors in function, logic, or implementation
for any representation of the software
To verify that the software under review meets its
requirements
To ensure that the software has been represented
according to predefined standards
To achieve software that is developed in a uniform
manner
To make projects more manageable
• Also serves as a training ground for junior software
engineers to observe different approaches to
software analysis, design, and construction
Page 17 of 103
 Unit 4: Software Quality

Formal Technical Review (FTR)

• Promotes backup and continuity because a
number of people become familiar with other
parts of the software
• May sometimes be a sample-driven review
Project managers must quantify those work
products that are the primary targets for formal
technical reviews
The sample of products that are reviewed must be
representative of the products as a whole
• Conducted using FTR Meetings
Page 18 of 103
 Unit 4: Software Quality

FTR Meeting
• Has the following constraints
 3-5 people should be involved
 Advance preparation (i.e., reading) should occur for each participant but
should require no more than two hours a piece and involve only a small
subset of components
 The duration of the meeting should be less than two hours
• Focuses on a specific work product (a software requirements
specification, a detailed design, a source code listing)
• Activities before the meeting
 The producer informs the project manager that a work product is
complete and ready for review
 The project manager contacts a review leader, who evaluates the product
for readiness, generates copies of product materials, and distributes
them to the reviewers for advance preparation
 Each reviewer spends one to two hours reviewing the product and
making notes before the actual review meeting
 The review leader establishes an agenda for the review meeting and
schedules the time and location
Page 19 of 103
 Unit 4: Software Quality

FTR Meeting (contd.)

• Activities during the meeting
 The meeting is attended by the review leader, all reviewers, and the producer
 One of the reviewers also serves as the recorder for all issues and decisions
concerning the product
 After a brief introduction by the review leader, the producer proceeds to "walk
through" the work product while reviewers ask questions and raise issues
 The recorder notes any valid problems or errors that are discovered; no time or
effort is spent in this meeting to solve any of these problems or errors

• Activities at the conclusion of the meeting

 All attendees must decide whether to
 Accept the product without further modification
 Reject the product due to severe errors (After these errors are corrected, another review will
then occur)
 Accept the product provisionally (Minor errors need to be corrected but no additional review
is required)
 All attendees then complete a sign-off in which they indicate that they took part
in the review and that they concur with the findings

Page 20 of 103
 Unit 4: Software Quality

FTR Meeting (contd.)

• Activities after the meeting
The recorder produces a list of review issues that
 Identifies problem areas within the product
 Serves as an action item checklist to guide the producer in
making corrections
The recorder includes the list in an FTR summary report
 This one to two-page report describes what was reviewed, who
reviewed it, and what were the findings and conclusions
The review leader follows up on the findings to ensure
that the producer makes the requested corrections

Page 21 of 103
 Unit 4: Software Quality

FTR Meeting (contd.)

1. Review the product, not the producer
2. Set an agenda and maintain it
3. Limit debate and rebuttal; conduct in-depth discussions off-line
4. Enunciate problem areas, but don't attempt to solve the problem
noted
5. Take written notes; utilize a wallboard to capture comments
6. Limit the number of participants and insist upon advance
preparation
7. Develop a checklist for each product in order to structure and focus
the review
8. Allocate resources and schedule time for FTRs
9. Conduct meaningful training for all reviewers
10. Review your earlier reviews to improve the overall review process

Page 22 of 103
 Unit 4: Software Quality

Software Quality Assurance (SQA)

• Software quality assurance (also called quality
management) is “Conformance to explicitly stated
functional and performance requirements, explicitly
documented development standards, and implicit
characteristics that are expected of all professionally
developed software"
• SQA encompasses:
1. An SQA process
2. SQA and quality control tasks (including technical reviews & testing
strategies)
3. Effective software engineering practice (methods & tools)
4. Control of all software work products and changes made to them
5. Procedures to ensure compliance with software development
standards
6. Measurement and reporting mechanisms
Page 23 of 103
 Unit 4: Software Quality

SQA Group
• Need for a formation of an SQA group composed of
stakeholders from different departments
• It serves as the customer's in-house representative
• Assists the software team in achieving a high-quality product
• Views the software from the customer's point of view
 Does the software adequately meet quality factors?
 Has software development been conducted according to pre-established
standards?
 Have technical disciplines properly performed their roles as part of the SQA
activity?
• Performs a set of activities that address quality assurance planning,
oversight, record keeping, analysis, and reporting

Page 24 of 103
 Unit 4: Software Quality

SQA Tasks / Activities

• Prepares an SQA plan for a project
• Participates in the development of the project's software
process description
• Reviews software engineering activities to verify compliance
with the defined software process
• Audits designated software work products to verify compliance
with those defined as part of the software process
• Ensures that deviations in software work and work products
are documented and handled according to a documented
procedure
• Records any non-compliance and reports to senior
management
• Coordinates the control and management of change
• Helps to collect and analyze software metrics
Page 25 of 103
 Unit 4: Software Quality

SQA Goals
• The ultimate goals for SQA activities are:
i. Requirements quality
ii. Design quality
iii. Code quality
iv. Quality control effectiveness

• All the above have attributes and metrics that

measure them

Page 26 of 103
 Unit 4: Software Quality

The SQA Plan

• Provides a road map for instituting software quality assurance in an
organization
• Developed by the SQA group to serve as a template for SQA activities
that are instituted for each software project in an organization
• Structured as follows:
 The purpose and scope of the plan
 A description of all software engineering work products that fall within
the purview of SQA
 All applicable standards and practices that are applied during the
software process
 SQA actions and tasks (including reviews and audits) and their
placement throughout the software process
 The tools and methods that support SQA actions and tasks
 Methods for assembling, safeguarding, and maintaining all SQA-related
records
 Organisational roles and responsibilities relative to product quality

Page 27 of 103
 Unit 4: Software Quality

SQA : Possible causes of defects

• Incomplete or erroneous specifications
• Misinterpretation of customer communication
• Intentional deviation from specifications
• Violation of programming standards
• Errors in data representation
• Inconsistent component interface
• Errors in design logic
• Incomplete or erroneous testing
• Inaccurate or incomplete documentation
• Errors in programming language translation of design
• Ambiguous or inconsistent human/computer interface
Page 28 of 103
 Unit 4: Software Quality

The Statistical SQA Process

• The key steps are:
1. Collect and categorize information (i.e., causes)
about software defects that occur
2. Attempt to trace each defect to its underlying
cause (e.g., non-conformance to specifications,
design error, violation of standards, poor
communication with the customer)
3. Using the Pareto principle (80% of defects can be
traced to 20% of all causes), isolate the vital 20%
4. For the vital causes (20%), correct the problems
that caused those errors and defects
Page 29 of 103
 Unit 4: Software Quality

The Statistical SQA Process

Six Sigma strategy
• Is the most widely used strategy for statistical
quality assurance
• Popularized by Motorola in the 1980s
• Uses data and statistical analysis to measure and
improve a company's operational performance
• Identifies and eliminates defects in manufacturing
and service-related processes
• The "Six Sigma" refers to six standard deviations
(3.4 defects per a million occurrences)
Page 30 of 103
 Unit 4: Software Quality

The Statistical SQA Process

Six Sigma strategy
• It has three (3) core steps:
1. Define customer requirements, deliverables, and project
goals via well-defined methods of customer
communication
2. Measure the existing process and its output to determine
current quality performance (collect defect metrics)
3. Analyze defect metrics and determine the vital few causes
(the 20%)
• Two additional steps are added for existing processes
(and can be done in parallel)
4. Improve the process by eliminating the root causes of
defects
5. Control the process to ensure that future work does not
reintroduce the causes of defects
• These steps are also referred to as DMAIC
Page 31 of 103
 Unit 4: Software Quality

Software Reliability
• Software reliability is the probability of
failure-free operation of a software application
in a specified environment for a specified time
• It is estimated using historical and
development data
• Failure is defined as “non-conformance to
software requirements”
• Given a set of valid requirements, all software
failures can be traced to design or
implementation problems because software
does not wears out like hardware
Page 32 of 103
 Unit 4: Software Quality

Software Reliability:
Measuring reliability (MTBF)
• Reliability is measured by mean-time-between-
failure (MTBF):

MTBF = MTTF + MTTR

where:
 MTTR : mean-time-to-failure [“uptime”]
 MTTR : mean-time-to-repair [“downtime”]

• E.g.: if system is up for 68 days on average, and

down for an average of 3 days; then MTBF = 68+3
= 71 days. Failures per 100 days would be (100/70)
= 1.4
Page 33 of 103
 Unit 4: Software Quality

Software Reliability:
Measuring availability
• Availability is the probability that a program is
operating according to requirements at a given
point in time
MTTF x 100%
Availability =
MTTF + MTTR
• E.g.: from previous example; availability = (68 / (68
+ 3)) x 100% = 96%
• This is also referred in terms of “nines”, i.e. 90% is
“1 nine” while 99% is “2 nines” and 99.9% is called
“3 nines”
• It basically measures “uptime rate”
Page 34 of 103
 Unit 4: Software Quality

Software Reliability:
Measuring availability
• One of the major criticisms of MTBF is that it
does not provide the projected failure rate
• This can be done using the failures-in-time
(FIT) : a statistical measure of how many
failures a program will have over a billion hours
of operation, i.e. 1 FIT = 1 failure per billion
hours of program operation

Page 35 of 103
 Unit 4: Software Quality

Software Reliability:
Software Safety
• Software safety focuses on identification and
assessment of potential hazards that may affect
software negatively and cause an entire system to fail
• It differs from software reliability
 Software reliability uses statistical analysis to determine the
likelihood that a software failure will occur; however, the
failure may not necessarily result in a hazard or mishap
 Software safety examines the ways in which failures result
in conditions that can lead to a hazard or mishap; it
identifies faults that may lead to failures
• Software failures are evaluated in the context of an
entire computer-based system and its environment
through the process of fault tree analysis or hazard
analysis

Page 36 of 103
 Unit 4: Software Quality

Software Testing Strategies

• The following will be covered:
 Test strategies for conventional software
 Test strategies for object-oriented software
 Validation testing
 System testing
 Debugging

Page 37 of 103
 Unit 4: Software Quality

Software Testing Strategies

• A testing strategy is a planned series of steps to
carry out the tests
• The strategy provides a road map that describes
the steps to be taken, when, and how much effort,
time, and resources will be required
• The strategy incorporates test planning, test case
design, test execution, and test result collection
and evaluation
• The strategy provides guidance for the
practitioners and a set of milestones for the
manager
• Progress must be measurable and problems must
surface as early as possible
Page 38 of 103
 Unit 4: Software Quality

Software Testing: Characteristics

• To perform effective testing, a software team
should conduct effective formal technical reviews
• Testing begins at the component level and work
outward toward the integration of the entire
computer-based system
• Different testing techniques are appropriate at
different points in time
• Testing is conducted by the developer of the
software and (for large projects) by an
independent test group
• Testing and debugging are different activities, but
debugging must be accommodated in any testing
strategy
Page 39 of 103
 Unit 4: Software Quality

Planning for Software Testing

• Testing should aim at "breaking" the software
• Common misconceptions
 The developer of software should do no testing at all
 The software should be given to a secret team of testers who will test it
unmercifully
 The testers get involved with the project only when the testing steps
are about to begin
• Consider an independent test group
 Removes the inherent problems associated with letting the builder test
the software that has been built
 Removes the conflict of interest that may otherwise be present
 Works closely with the software developer during analysis and design
to ensure that thorough testing occurs

Page 40 of 103
 Unit 4: Software Quality

Testing Conventional Software

• Summary of steps and testing strategies

Design level Testing type

Code Unit testing

Design (& architecture) Integration testing

Requirements Validation testing

System engineering System testing

Page 41 of 103
 Unit 4: Software Quality

Testing Conventional Software:

Strategies for various Levels
• Unit testing
 Exercises specific paths in a component's control structure to ensure
complete coverage and maximum error detection
 Components are then assembled and integrated
• Integration testing
 Focuses on inputs and outputs, and how well the components fit
together and work together
• Validation testing
 Provides final assurance that the software meets all functional,
behavioral, and performance requirements
• System testing
 Verifies that all system elements (software, hardware, people, databases)
mesh properly and that overall system function and performance is
achieved

Page 42 of 103
 Unit 4: Software Quality

Testing Object-oriented Software:

Strategies
• Must broaden testing to include detections of errors in analysis and design
models
• Unit testing loses some of its meaning and integration testing changes
significantly
• Use the same philosophy but different approach as in conventional software
testing
• Test "in the small" and then work out to testing "in the large"
 Testing in the small involves class attributes and operations; the main
focus is on communication and collaboration within the class
 Testing in the large involves a series of regression tests to uncover errors
due to communication and collaboration among classes
• Finally, the system as a whole is tested to detect errors in fulfilling
requirements

Page 43 of 103
 Unit 4: Software Quality

Software Testing:
When is it completed?
• Every time a user executes the software, the program is being
tested
• Testing usually stops when a project is running out of time,
money, or both
• One approach is to divide the test results into various severity
levels
 Then consider testing to be complete when certain levels of
errors no longer occur or have been repaired or eliminated

Page 44 of 103
 Unit 4: Software Quality

Ensuring Successful Software Testing

• Specify product requirements in a quantifiable manner long before testing
commences
• State testing objectives explicitly in measurable terms
• Understand the user of the software (through use cases) and develop a
profile for each user category
• Develop a testing plan that emphasizes rapid cycle testing to get quick
feedback to control quality levels and adjust the test strategy
• Build robust software that is designed to test itself and can diagnose certain
kinds of errors
• Use effective formal technical reviews as a filter prior to testing to reduce the
amount of testing required
• Conduct formal technical reviews to assess the test strategy and test cases
themselves
• Develop a continuous improvement approach for the testing process through
the gathering of metrics

Page 45 of 103
 Unit 4: Software Quality

Testing Strategies for Conventional

Software: Unit Testing
• Focuses testing on the function or software module
• Concentrates on the internal processing logic and data
structures
• Is simplified when a module is designed with high
cohesion
Reduces the number of test cases
Allows errors to be more easily predicted and
uncovered
• Concentrates on critical modules and those with high
complexity when testing resources are limited
Page 46 of 103
 Unit 4: Software Quality

Testing Strategies for Conventional

Software: Unit Testing targets
• Module interface
 Ensure that information flows properly into and out of the module
• Local data structures
 Ensure that data stored temporarily maintains its integrity during all steps in an
algorithm execution
• Boundary conditions
 Ensure that the module operates properly at boundary values established to limit
or restrict processing
• Independent paths (basis paths)
 Paths are exercised to ensure that all statements in a module have been executed
at least once
• Error handling paths
 Ensure that the algorithms respond correctly to specific error conditions

Page 47 of 103
 Unit 4: Software Quality

Unit Testing: Common errors

• Computational
 Misunderstood or incorrect arithmetic precedence
 Mixed mode operations (e.g., int, float, char)
 Incorrect initialization of values
 Precision inaccuracy and round-off errors
 Incorrect symbolic representation of an expression (int vs. float)

• Other common errors

 Comparison of different data types
 Incorrect logical operators or precedence
 Expectation of equality when precision error makes equality unlikely (using
== with float types)
 Incorrect comparison of variables
 Improper or nonexistent loop termination
 Failure to exit when divergent iteration is encountered
 Improperly modified loop variables
 Boundary value violations

Page 48 of 103
 Unit 4: Software Quality

Unit Testing: Drivers & Stubs

• Driver
 A simple main program that accepts test case data, passes
such data to the component being tested, and prints the
returned results
• Stubs
 Serve to replace modules that are subordinate to (called by)
the component to be tested
 It uses the module’s exact interface, may do minimal data
manipulation, provides verification of entry, and returns
control to the module undergoing testing
• Drivers and stubs both represent overhead
 Both must be written but don’t constitute part of the
installed software product
Page 49 of 103
 Unit 4: Software Quality

Testing Strategies for Conventional

Software: Integration Testing
• Defined as a systematic technique for constructing the software
architecture
 At the same time integration is occurring, conduct tests to
uncover errors associated with interfaces
• Objective is to take unit tested modules and build a program
structure based on the prescribed design
• Two Approaches
 Non-incremental Integration Testing
 Incremental Integration Testing

Page 50 of 103
 Unit 4: Software Quality
Testing Strategies for Conventional
Software: Integration Testing
(Non-Incremental)

• Commonly called the “Big Bang” approach

• All components are combined in advance
• The entire program is tested as a whole
• Chaos results
• Many seemingly-unrelated errors are encountered
• Correction is difficult because isolation of causes is complicated
• Once a set of errors are corrected, more errors occur, and testing appears to
enter an endless loop

Page 51 of 103
 Unit 4: Software Quality
Testing Strategies for Conventional
Software: Integration Testing
(Incremental)
• More modular and more planned
• Three kinds
i. Top-down integration
ii. Bottom-up integration
iii. Sandwich integration
• The program is constructed and tested in small increments
• Errors are easier to isolate and correct
• Interfaces are more likely to be tested completely
• A systematic test approach is applied

Page 52 of 103
 Unit 4: Software Quality
Testing Strategies for Conventional
Software: Integration Testing
(Incremental)
1. Top-down
• Modules are integrated by moving downward through the control hierarchy,
beginning with the main module
• Subordinate modules are incorporated in either a depth-first or breadth-first
fashion
 Depth-First: All modules on a major control path are integrated
 Breadth-First: All modules directly subordinate at each level are integrated
• Advantages
– This approach verifies major control or decision points early in the test process
• Disadvantages
 Stubs need to be created to substitute for modules that have not been built or
tested yet; this code is later discarded
 Because stubs are used to replace lower level modules, no significant data flow
can occur until much later in the integration/testing process
Page 53 of 103
 Unit 4: Software Quality
Testing Strategies for Conventional
Software: Integration Testing
(Incremental)
2. Bottom-up
• Integration and testing starts with the most atomic modules in the control
hierarchy
• Advantages
 This approach verifies low-level data processing early in the testing process
 Need for stubs is eliminated
• Disadvantages
 Driver modules need to be built to test the lower-level modules; this code is later
discarded or expanded into a full-featured version
 Drivers inherently do not contain the complete algorithms that will eventually use
the services of the lower-level modules; consequently, testing may be incomplete
or more testing may be needed later when the upper level modules are available

Page 54 of 103
 Unit 4: Software Quality
Testing Strategies for Conventional
Software: Integration Testing
(Incremental)
3. Sandwich
• Consists of a combination of both top-down and bottom-up integration
• Occurs both at the highest level modules and also at the lowest level
modules
• Proceeds using functional groups of modules, with each group completed
before the next
 High and low-level modules are grouped based on the control and data
processing they provide for a specific program feature
 Integration within the group progresses in alternating steps between the high and
low level modules of the group
 When integration for a certain functional group is complete, integration and
testing moves onto the next group
• Reaps the advantages of both types of integration while minimizing the need
for drivers and stubs
• Requires a disciplined approach so that integration doesn’t tend towards the
“big bang” scenario
Page 55 of 103
 Unit 4: Software Quality

Testing Strategies for Conventional

Software: Regression Testing
• Each new addition or change to baselined software may cause problems with
functions that previously worked flawlessly
• Regression testing re-executes a small subset of tests that have already been
conducted
 Ensures that changes have not propagated unintended side effects
 Helps to ensure that changes do not introduce unintended behavior or
additional errors
 May be done manually or through the use of automated
capture/playback tools
• Regression test suite contains three different classes of test cases
 A representative sample of tests that will exercise all software functions
 Additional tests that focus on software functions that are likely to be
affected by the change
 Tests that focus on the actual software components that have been
changed

Page 56 of 103
 Unit 4: Software Quality

Testing Strategies for Conventional

Software: Smoke Testing
• Adapted from the world of hardware
 Power is applied and a technician checks for sparks, smoke, or other dramatic
signs of fundamental failure
• Designed as a pacing mechanism for time-critical projects
 Allows the software team to assess its project on a frequent basis
• Includes the following activities
 The software is compiled and linked into a build
 A series of breadth tests is designed to expose errors that will keep the build from
properly performing its function
 The goal is to uncover “show stopper” errors that have the highest likelihood of
throwing the software project behind schedule
 The build is integrated with other builds and the entire product is smoke tested
daily
 Daily testing gives managers and practitioners a realistic assessment of the progress of
the integration testing
 After a smoke test is completed, detailed test scripts are executed

Page 57 of 103
 Unit 4: Software Quality

Testing Strategies for Conventional

Software: Smoke Testing: benefits
• Integration risk is minimized
 Daily testing uncovers incompatibilities and show-stoppers
early in the testing process, thereby reducing schedule
impact
• The quality of the end-product is improved
 Smoke testing is likely to uncover both functional errors and
architectural and component-level design errors
• Error diagnosis and correction are simplified
 Smoke testing will probably uncover errors in the newest
components that were integrated
• Progress is easier to assess
 As integration testing progresses, more software has been
integrated and more has been demonstrated to work
 Managers get a good indication that progress is being made
Page 58 of 103
 Unit 4: Software Quality

Testing Strategies for

Object-oriented Software
• With object-oriented software, you can no longer test a single operation in
isolation (conventional thinking)
• Traditional top-down or bottom-up integration testing has little meaning
• Class testing for object-oriented software is the equivalent of unit testing for
conventional software
 Focuses on operations encapsulated by the class and the state behavior
of the class
• Drivers can be used
 To test operations at the lowest level and for testing whole groups of
classes
 To replace the user interface so that tests of system functionality can be
conducted prior to implementation of the actual interface
• Stubs can be used
 In situations in which collaboration between classes is required but one
or more of the collaborating classes has not yet been fully implemented

Page 59 of 103
 Unit 4: Software Quality

Testing Strategies for

Object-oriented Software
• There are two different object-oriented testing strategies
 Thread-based testing
 Integrates the set of classes required to respond to one input or
event for the system
 Each thread is integrated and tested individually
 Regression testing is applied to ensure that no side effects occur
 Use-based testing
 First tests the independent classes that use very few, if any, server
classes
 Then the next layer of classes, called dependent classes, are
integrated
 This sequence of testing layer of dependent classes continues until
the entire system is constructed

Page 60 of 103
 Unit 4: Software Quality

Validation Testing
• Validation testing follows integration testing
• The distinction between conventional and object-oriented software
disappears
• Focuses on user-visible actions and user-recognizable output from the system
• Demonstrates conformity with requirements
• Designed to ensure that
 All functional requirements are satisfied
 All behavioral characteristics are achieved
 All performance requirements are attained
 Documentation is correct
 Usability and other requirements are met (e.g., transportability, compatibility,
error recovery, maintainability)
• After each validation test
 The function or performance characteristic conforms to specification and is
accepted
 A deviation from specification is uncovered and a deficiency list is created
• A configuration review or audit ensures that all elements of the software
configuration have been properly developed, cataloged, and have the
necessary detail for entering the support phase of the software life cycle

Page 61 of 103
 Unit 4: Software Quality

Validation Testing:
Alpha & Beta Testing
• Alpha testing
 Conducted at the developer’s site by end users
 Software is used in a natural setting with developers watching intently
 Testing is conducted in a controlled environment
• Beta testing
 Conducted at end-user sites
 Developer is generally not present
 It serves as a live application of the software in an environment that
cannot be controlled by the developer
 The end-user records all problems that are encountered and reports
these to the developers at regular intervals
• After beta testing is complete, software engineers make software
modifications and prepare for release of the software product to the entire
customer base

Page 62 of 103
 Unit 4: Software Quality

System Testing
• Recovery testing
 Tests for recovery from system faults
 Forces the software to fail in a variety of ways and verifies that recovery is
properly performed
 Tests reinitialization, checkpointing mechanisms, data recovery, and restart for
correctness
• Security testing
 Verifies that protection mechanisms built into a system will, in fact, protect it
from improper access
• Stress testing
 Executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume
• Performance testing
 Tests the run-time performance of software within the context of an integrated
system
 Often coupled with stress testing and usually requires both hardware and
software instrumentation
 Can uncover situations that lead to degradation and possible system failure

Page 63 of 103
 Unit 4: Software Quality

Debugging
• Debugging occurs as a consequence of successful testing
• It is still very much an art rather than a science
• Good debugging ability may be an innate human trait
• Large variances in debugging ability exist
• The debugging process begins with the execution of a test case
• Results are assessed and the difference between expected and
actual performance is encountered
• This difference is a symptom of an underlying cause that lies
hidden
• The debugging process attempts to match symptom with cause,
thereby leading to error correction

Page 64 of 103
 Unit 4: Software Quality

Challenges of Debugging
• The symptom and the cause may be geographically remote
• The symptom may disappear (temporarily) when another error is
corrected
• The symptom may actually be caused by non-errors (e.g., round-off
accuracies)
• The symptom may be caused by human error that is not easily traced
• The symptom may be a result of timing problems, rather than
processing problems
• It may be difficult to accurately reproduce input conditions, such as
asynchronous real-time information
• The symptom may be intermittent such as in embedded systems
involving both hardware and software
• The symptom may be due to causes that are distributed across a
number of tasks running on different processes
Page 65 of 103
 Unit 4: Software Quality

Debugging: Strategies
• Objective of debugging is to find and correct the cause of a
software error
• Bugs are found by a combination of systematic evaluation,
intuition, and luck
• Debugging methods and tools are not a substitute for careful
evaluation based on a complete design model and clear source
code
• There are three main debugging strategies
i. Brute force
ii. Backtracking
iii. Cause elimination

Page 66 of 103
 Unit 4: Software Quality

Debugging: Strategies
1. Brute force
• Most commonly used and least efficient method
• Used when all else fails
• Involves the use of memory dumps, run-time traces, and output
statements
• Leads many times to wasted effort and time

Page 67 of 103
 Unit 4: Software Quality

Debugging: Strategies
2. Backtracking
• Can be used successfully in small programs
• The method starts at the location where a symptom has been
uncovered
• The source code is then traced backward (manually) until the
location of the cause is found
• In large programs, the number of potential backward paths may
become unmanageably large

Page 68 of 103
 Unit 4: Software Quality

Debugging: Strategies
3. Cause elimination
• Involves the use of induction or deduction and introduces the concept of
binary partitioning
 Induction (specific to general): Prove that a specific starting value is true;
then prove the general case is true
 Deduction (general to specific): Show that a specific conclusion follows
from a set of general premises
• Data related to the error occurrence are organized to isolate potential causes
• A cause hypothesis is devised, and the aforementioned data are used to
prove or disprove the hypothesis
• Alternatively, a list of all possible causes is developed, and tests are
conducted to eliminate each cause
• If initial tests indicate that a particular cause hypothesis shows promise, data
are refined in an attempt to isolate the bug

Page 69 of 103
 Unit 4: Software Quality

Questions to ask before Debugging

1. Is the cause of the bug reproduced in another part of the
program?
 Similar errors may be occurring in other parts of the program
2. What next bug might be introduced by the fix that I’m about to
make?
 The source code (and even the design) should be studied to assess the
coupling of logic and data structures related to the fix
3. What could we have done to prevent this bug in the first place?
 This is the first step toward software quality assurance
 By correcting the process as well as the product, the bug will be removed
from the current program and may be eliminated from all future
programs

Page 70 of 103
 Unit 4: Software Quality

Software Testing Techniques

• The following will be covered:
 Testing fundamentals
 White-box testing
 Black-box testing
 Object-oriented testing methods

Page 71 of 103
 Unit 4: Software Quality

Software Testing Techniques:

Characteristics of testable software
• Operable
 The better it works (i.e., better quality), the easier it is to test
• Observable
 Incorrect output is easily identified; internal errors are automatically detected
• Controllable
 The states and variables of the software can be controlled directly by the tester
• Decomposable
 The software is built from independent modules that can be tested independently
• Simple
 The program should exhibit functional, structural, and code simplicity
• Stable
 Changes to the software during testing are infrequent and do not invalidate existing
tests
• Understandable
 The architectural design is well understood; documentation is available and organized

Page 72 of 103
 Unit 4: Software Quality

Software Testing Techniques:

Characteristics of a Good Test
• A good test has a high probability of finding an error
 The tester must understand the software and how it might fail
• A good test is not redundant
 Testing time is limited; one test should not serve the same purpose as another
test
• A good test should be “best of breed”
 Tests that have the highest likelihood of uncovering a whole class of errors should
be used
• A good test should be neither too simple nor too complex
 Each test should be executed separately; combining a series of tests could cause
side effects and mask certain errors

Page 73 of 103
 Unit 4: Software Quality

Software Testing Techniques:

Unit Testing Techniques
• Black-box testing
 Knowing the specified function that a product has been designed to perform, test
to see if that function is fully operational and error free
 Includes tests that are conducted at the software interface
 Not concerned with internal logical structure of the software
• White-box testing
 Knowing the internal workings of a product, test that all internal operations are
performed according to specifications and all internal components have been
exercised
 Involves tests that concentrate on close examination of procedural detail
 Logical paths through the software are tested
 Test cases exercise specific sets of conditions and loops

Page 74 of 103
 Software Testing Techniques:
Unit 4: Software Quality

Unit Testing Techniques

1. White-box Testing
• Uses the control structure part of component-level design to derive the test
cases
• These test cases
 Guarantee that all independent paths within a module have been exercised at
least once
 Exercise all logical decisions on their true and false sides
 Execute all loops at their boundaries and within their operational bounds
 Exercise internal data structures to ensure their validity

Page 75 of 103
 Unit 4: Software Quality

Software Testing Techniques:

Unit Testing Techniques
2. Black-box Testing
• Complements white-box testing by uncovering different classes of errors
• Focuses on the functional requirements and the information domain of the
software
• Used during the later stages of testing after white box testing has been
performed
• The tester identifies a set of input conditions that will fully exercise all
functional requirements for a program
• The test cases satisfy the following:
 Reduce, by a count greater than one, the number of additional test cases that
must be designed to achieve reasonable testing
 Tell us something about the presence or absence of classes of errors, rather than
an error associated only with the specific task at hand

Page 76 of 103
 Unit 4: Software Quality
Software Testing Techniques:
Unit Testing Techniques
2. Black-box Testing: Categories
• Incorrect or missing functions
• Interface errors
• Errors in data structures or external data base access
• Behavior or performance errors
• Initialization and termination errors

Page 77 of 103
 Unit 4: Software Quality

Software Testing Techniques:

Unit Testing Techniques
2. Black-box Testing (contd.)
• The questions answered by black-box testing are:
 How is functional validity tested?
 How are system behavior and performance tested?
 What classes of input will make good test cases?
 Is the system particularly sensitive to certain input values?
 How are the boundary values of a data class isolated?
 What data rates and data volume can the system tolerate?
 What effect will specific combinations of data have on system
operation?

Page 78 of 103
 Unit 4: Software Quality

Software Testing Techniques

for Object-oriented software
• The goal is to uncover errors that may occur as classes collaborate with one
another and subsystems communicate across architectural layers
 Testing begins "in the small" on methods within a class and on
collaboration between classes
 As class integration occurs, use-based testing and fault-based testing are
applied
 Finally, use cases are used to uncover errors during the software
validation phase
• Conventional test case design is driven by an input-process-output view of
software
• Object-oriented testing focuses on designing appropriate sequences of
methods to exercise the states of a class

Page 79 of 103
 Unit 4: Software Quality

Software Testing Techniques

for Object-oriented software:
Challenges & Implications
• Because attributes and methods are encapsulated in a class, testing methods
from outside of a class is generally unproductive
• Testing requires reporting on the state of an object, yet encapsulation can make
this information somewhat difficult to obtain
• Built-in methods should be provided to report the values of class attributes in
order to get a snapshot of the state of an object
• Inheritance requires retesting of each new context of usage for a class
 If a subclass is used in an entirely different context than the super class, the
super class test cases will have little applicability and a new set of tests must
be designed

• Applicability of Conventional methods:

• White-box testing can be applied to the operations defined in a class
 Basis path testing and loop testing can help ensure that every statement in an method
has been tested
• Black-box testing methods are also appropriate
 Use cases can provide useful input in the design of black-box tests
Page 80 of 103
 Unit 4: Software Quality

Software Testing Techniques

for Object-oriented software:
Fault-based Testing
• The objective in fault-based testing is to design tests that have a high
likelihood of uncovering plausible faults
• Fault-based testing begins with the analysis model
 The tester looks for plausible faults (i.e., aspects of the implementation of the
system that may result in defects)
 To determine whether these faults exist, test cases are designed to exercise the
design or code
• If the analysis and design models can provide insight into what is likely to go
wrong, then fault-based testing can find a significant number of errors

Page 81 of 103
 Unit 4: Software Quality

Software Testing Techniques

for Object-oriented software:
Fault-based Testing (contd.)
• Integration testing looks for plausible faults in method calls or message
connections (i.e., client/server exchange)
• Three types of faults are encountered in this context
 Unexpected result
 Wrong method or message used
 Incorrect invocation
• The behavior of a method must be examined to determine the occurrence of
plausible faults as methods are invoked
• Testing should exercise the attributes of an object to determine whether
proper values occur for distinct types of object behavior
• The focus of integration testing is to determine whether errors exist in the
calling code, not the called code

Page 82 of 103
 Unit 4: Software Quality

Software Testing Techniques

for Object-oriented software:
Fault-based VS Scenario-based Testing
• Fault-based testing misses two main types of errors
 Incorrect specification: subsystem doesn't do what the user wants
 Interactions among subsystems: behavior of one subsystem creates
circumstances that cause another subsystem to fail
• A solution to this problem is scenario-based testing
 It concentrates on what the user does, not what the product does
 This means capturing the tasks (via use cases) that the user has to
perform, then applying them as tests
 Scenario-based testing tends to exercise multiple subsystems in a single
test

Page 83 of 103
 Unit 4: Software Quality

Software Configuration Management

(SCM)
• It is an umbrella activity that is applied throughout the
software process
• It's goal is to maximize productivity by minimizing
mistakes caused by confusion when coordinating
software development
• SCM identifies, organizes, and controls modifications to
the software being built by a software development team
• SCM activities are formulated to identify change, control
change, ensure that change is being properly
implemented, and report changes to others who may
have an interest
• SCM is initiated when the project begins and terminates
when the software is taken out of operation
Page 84 of 103
 Unit 4: Software Quality

SCM : Viewpoints
• There are different viewpoints of SCM from various roles:
 Project manager -> an auditing mechanism

 SCM manager -> a controlling, tracking, and policy making

mechanism

 Software engineer -> a changing, building, and access control

mechanism

 Customer -> a quality assurance and product identification

mechanism

Page 85 of 103
 Unit 4: Software Quality

SCM : Software Process Outputs

• The Output from the software process makes up the software configuration
 Computer programs (both source code files and executable files)
 Work products that describe the computer programs (documents
targeted at both technical practitioners and users)
 Data (contained within the programs themselves or in external files)

• Change is the major danger to a software configuration

 First Law of System Engineering: "No matter where you are in the system
life cycle, the system will change, and the desire to change it will persist
throughout the life cycle"

Page 86 of 103
 Unit 4: Software Quality

SCM : Sources of changes

• Errors detected in the software need to be corrected
• New business or market conditions dictate changes in product
requirements or business rules
• New customer needs demand modifications of data produced
by information systems, functionality delivered by products, or
services delivered by a computer-based system
• Reorganization or business growth/downsizing causes changes
in project priorities or software engineering team structure
• Budgetary or scheduling constraints cause a redefinition of the
system or product

HCT210: Software Engineering Gibson Mukarakate

Page 87 of 103 87
 Unit 4: Software Quality

Elements of a Software Configuration

Management (SCM) System
• Configuration elements
 A set of tools coupled with a file management (e.g., database) system that
enables access to and management of each software configuration item
• Process elements
 A collection of procedures and tasks that define an effective approach to change
management for all participants
• Construction elements
 A set of tools that automate the construction of software by ensuring that the
proper set of valid components (i.e., the correct version) is assembled
• Human elements
 A set of tools and process features used by a software team to implement
effective SCM

Page 88 of 103
 Unit 4: Software Quality

SCM : Baseline concept

• An SCM concept that helps practitioners to control change
without seriously impeding justifiable change
• IEEE Definition: A specification or product that has been
formally reviewed and agreed upon, and that thereafter serves
as the basis for further development, and that can be changed
only through formal change control procedures
• It is a milestone in the development of software and is marked
by the delivery of one or more computer software
configuration items (CSCIs) that have been approved as a
consequence of a formal technical review
• A CSCI may be such work products as a document (as listed in
MIL-STD-498), a test suite, or a software component

Page 89 of 103
 Unit 4: Software Quality

SCM : The Baseline process

1. A series of software engineering tasks produces a CSCI
2. The CSCI is reviewed and possibly approved
3. The approved CSCI is given a new version number and placed
in a project database (i.e., software repository)
4. A copy of the CSCI is taken from the project database and
examined/modified by a software engineer
5. The baselining of the modified CSCI goes back to Step 2

Page 90 of 103
 Unit 4: Software Quality

The SCM Repository

• Manual repositories are no longer commonly used
 Challenges: failure to manage complex relationships, difficult to search,
repository can be damaged or lost, etc.

• Automated SCM repositories:

 It is a set of mechanisms and data structures that allow a
software team to manage change in an effective manner
 It acts as the center for both accumulation and storage of
software engineering information
 Software engineers use tools integrated with the repository
to interact with it

Page 91 of 103
 Unit 4: Software Quality

The SCM Repository: Functions

• Data integrity
 Validates entries, ensures consistency, cascades modifications
• Information sharing
 Shares information among developers and tools, manages and controls multi-user
access
• Tool integration
 Establishes a data model that can be accessed by many software engineering
tools, controls access to the data
• Data integration
 Allows various SCM tasks to be performed on one or more CSCIs
• Methodology enforcement
 Defines an entity-relationship model for the repository that implies a specific
process model for software engineering
• Document standardization
 Defines objects in the repository to guarantee a standard approach for creation of
software engineering documents

Page 92 of 103
 Unit 4: Software Quality

The SCM Repository: Toolset

• Versioning
 Save and retrieve all repository objects based on version number
• Dependency tracking and change management
 Track and respond to the changes in the state and relationship of all objects in the
repository
• Requirements tracing
 (Forward tracing) Track the design and construction components and deliverables
that result from a specific requirements specification
 (Backward tracing) Identify which requirement generated any given work product
• Configuration management
 Track a series of configurations representing specific project milestones or
production releases
• Audit trails
 Establish information about when, why, and by whom changes are made in the
repository

Page 93 of 103
 Unit 4: Software Quality

The SCM Process

Key objectives of the process are:

• How does a software team identify the discrete elements of a
software configuration?
• How does an organization manage the many existing versions of
a program (and its documentation) in a manner that will enable
change to be accommodated efficiently?
• How does an organization control changes before and after
software is released to a customer?
• Who has responsibility for approving and ranking changes?
• How can we ensure that changes have been made properly?
• What mechanism is used to appraise others of changes that are
made?
Page 94 of 103
 Unit 4: Software Quality

The SCM Process: Key questions

Key questions are:
• How does a software team identify the discrete elements of a
software configuration?
• How does an organization manage the many existing versions of
a program (and its documentation) in a manner that will enable
change to be accommodated efficiently?
• How does an organization control changes before and after
software is released to a customer?
• Who has responsibility for approving and ranking changes?
• How can we ensure that changes have been made properly?
• What mechanism is used to appraise others of changes that are
made?

Page 95 of 103
 Unit 4: Software Quality

The SCM Process: Tasks

• Tasks summary:

Status reporting

Configuration auditing

Version control
Change control

Identification

CSCI CSCI
CSCI CSCI

Page 96 of 103
 Unit 4: Software Quality

The SCM Process: Tasks (contd.)

• Concentric layers (from inner to outer)
1. Identification
2. Change control
3. Version control
4. Configuration auditing
5. Status reporting
• CSCIs flow outward through these layers during their life cycle
• CSCIs ultimately become part of the configuration of one or
more versions of a software application or system

Page 97 of 103
 Unit 4: Software Quality

The SCM Process Tasks

1. Identification task
• Identification separately names each CSCI and then organizes it
in the SCM repository using an object-oriented approach
• Objects start out as basic objects and are then grouped into
aggregate objects
• Each object has a set of distinct features that identify it
 A name that is unambiguous to all other objects
 A description that contains the CSCI type, a project identifier,
and change and/or version information
 List of resources needed by the object
 The object realization (i.e., the document, the file, the model,
etc.)

Page 98 of 103
 Unit 4: Software Quality

The SCM Process Tasks

2. Change Control task
• Change control is a procedural activity that ensures quality and consistency
as changes are made to a configuration object
• A change request is submitted to a configuration control authority, which is
usually a change control board (CCB)
 The request is evaluated for technical merit, potential side effects, overall
impact on other configuration objects and system functions, and
projected cost in terms of money, time, and resources
• An engineering change order (ECO) is issued for each approved change
request
 Describes the change to be made, the constraints to follow, and the
criteria for review and audit
• The baselined CSCI is obtained from the SCM repository
 Access control governs which software engineers have the authority to
access and modify a particular configuration object
 Synchronization control helps to ensure that parallel changes performed
by two different people don't overwrite one another
Page 99 of 103
 Unit 4: Software Quality

The SCM Process Tasks

3. Version Control task
• Version control is a set of procedures and tools for managing the creation and use of
multiple occurrences of objects in the SCM repository
• Required version control capabilities
 An SCM repository that stores all relevant configuration objects
 A version management capability that stores all versions of a configuration object
(or enables any version to be constructed using differences from past versions)
 A make facility that enables the software engineer to collect all relevant
configuration objects and construct a specific version of the software
 Issues tracking (bug tracking) capability that enables the team to record and track
the status of all outstanding issues associated with each configuration object
• The SCM repository maintains a change set
 Serves as a collection of all changes made to a baseline configuration
 Used to create a specific version of the software
 Captures all changes to all files in the configuration along with the reason for
changes and details of who made the changes and when

Page 100 of 103

 Unit 4: Software Quality

The SCM Process Tasks

4. Configuration Auditing task
• Configuration auditing is an SQA activity that helps to ensure that quality is
maintained as changes are made
• It complements the formal technical review and is conducted by the SQA group
• It addresses the following questions
 Has the change specified in the ECO been made? Have any additional modifications been
incorporated?
 Has a formal technical review been conducted to assess technical correctness?
 Has the software process been followed, and have software engineering standards been
properly applied?
 Has the change been "highlighted" and "documented" in the CSCI? Have the change data
and change author been specified? Do the attributes of the configuration object reflect the
change?
 Have SCM procedures for noting the change, recording it, and reporting it been followed?
 Have all related CSCIs been properly updated?
• A configuration audit ensures that
 The correct CSCIs (by version) have been incorporated into a specific build
 That all documentation is up-to-date and consistent with the version that has been built

Page 101 of 103

 Unit 4: Software Quality

The SCM Process Tasks

5. Status Reporting task
• Configuration status reporting (CSR) is also called status accounting
• Provides information about each change to those personnel in an
organization with a need to know
• Answers what happened, who did it, when did it happen, and what else will
be affected?
• Sources of entries for configuration status reporting
 Each time a CSCI is assigned new or updated information
 Each time a change is approved by the CCB and an ECO is issued
 Each time a configuration audit is conducted
• The configuration status report
 Placed in an on-line database or on a website for software developers
and maintainers to read
 Given to management and practitioners to keep them appraised of
important changes to the project CSCIs

Page 102 of 103

Unit 4: Software Quality

END

Page 103 of 103