SOFTWARE QUALITY ENGINEERING

LECTURE#7&8: SOFTWARE QUALITY ENGINEERING

 LECTURE OVERVIEW

 Software Quality Engineering

 Key SQE Activities
 SQE in Software Process
 QUALITY ENGINEERING
 From QA to SQE
 QA activities need additional support:
⁃ Planning and goal setting for quality
⁃ Measurement
⁃ Feedback
 QA + above =Software Quality Engineering (SQE)
 SQE activities in chronological order:
 Pre-QA activities
 In-QA activities
 Post-QA activities
 PRE-QA ACTIVITIES

 Quality Planning
 Set specific quality goals
 Form an overall QA strategy:
⁃ Select appropriate QA activities to perform
⁃ Choose appropriate quality measures and models to provide feedback,
quality assessment, and improvement
 IN-QA ACTIVITIES

 Executing planned QA activities

 Handling discovered defects
 Performing selected QA activities, an important part of this normal execution is to
deal with the discovered problems, already discussed in the last chapters
 POST-QA ACTIVITIES
 Quality measurement, assessment, and improvement
 Primary purpose of these activities is to provide quality assessment and feedback
so that various management decisions can be made and possible quality
improvement initiatives can be carried out
 QA ACTIVITIES

 Execution of selected QA activities usually consumes the most resources.

 QA strategies need to be selected, before specific QA activities, collect data,
perform analysis, and provide feedback
 Two kinds of feedback in this quality engineering process,
⁃ short-term direct feedback to the QA activities
⁃ long-term feedback to the overall quality engineering process
 ROLE OF FEEDBACK IN SQE
 The short term feedback to QA activities typically provides information for
progress tracking, activity scheduling, and identification of areas that need
special attentions.
 Various models and tools used to provide test effort tracking, reliability
monitoring, and identification of low-reliability areas for various software products
developed in the IBM Software Solutions Toronto Lab to manage their testing
process (Tian, 1996).
 ROLE OF FEEDBACK IN SQE

 Long term feedback

 To overall quality engineering process
 Two forms:
⁃ Feedback to quality planning: for adjustment of quality goals and QA strategies
⁃ Feedback to quality assessment and improvement activities: for tool selection, model
selection etc.
 Feedback to quality planning so that necessary adjustment can be made to
quality goals and QA strategies.
 If the current quality goals are unachievable, alternative goals need to be negotiated.
 If the selected QA strategy is inappropriate, a new or modified strategy needs to be
selected.
 Adjustments may also be applied to future projects instead of the current project.
 ROLE OF FEEDBACK IN SQE

 Feedback to the quality assessment and improvement activities. Modelling results may be highly
unstable, which may well be an indication of the model inappropriateness.
 New or modified models need to be used, probably on screened or pre-processed data.
 QUALITY PLANNING

 Goal setting:
 Match customer’s quality expectations with what can be economically achieved
⁃ Identify quality views/attributes meaningful to the customer
⁃ Select direct quality measurements to measure the selected quality
attributes from the customer’s perspective
⁃ Quantify these quality measures to set quality goals while considering the
market environment and the cost of achieving different quality goals.
 QUALITY PLANNING

 Quality planning needs close interaction with the customer

 Different customers/market segments have different quality requirements, and
reliability is the most common concern
– Safety is a requirement for safety critical systems
– Usability is demanded in mass-market products
– Interoperability by embedded software products
 QUALITY PLANNING
 Qualitative knowledge about customers’ quality expectations, we need to
quantify these quality expectations to set appropriate quality goals in two steps:
 1. We need to select or define the quality measurements and models
commonly accepted by the customers and in the software engineering
community.
⁃ Reliability and safety are examples of correctness-centered quality measures that are
meaningful to customers and users
 2. We need to find out the expected values or ranges of the
corresponding quality measurements.
⁃ Different market segments might have different reliability expectations. Such quality
expectations are also influenced by the general market conditions and competitive
pressure.
 QUALITY PLANNING

 Software vendors not only compete on quality alone, but also on cost, schedule,
innovation, flexibility, overall user experience, and other features and properties as well
 QUALITY PLANNING

 Practical concern with the proper setting of quality goals is the cost associated
with different levels of quality. This cost can be divided into two major
components, the failure cost, and the development cost.
 The customers typically care more about the total failure cost, Cf , which can be
estimated by the
⁃ average single failure cost, cf , and
⁃ failure probability, pf , over a pre-defined duration of operation as:

Cf =cf x pf
 QUALITY PLANNING

 Failure probability can be expressed in terms of reliability, R,

– as pf = 1 - R,
where R is defined to be the probability of failure-free operations for a specific
period of a given set of input.
 To minimize Cf , one can either try to minimize cf or pf
 However, cf is typically determined by the nature of software applications and the
overall environment the software is used in
 QUALITY PLANNING

 Forming a QA strategy:
 Map the above quality views, attributes, and quantitative goals to specific QA
activities
– Influence of quality perspectives and attributes: Different customers/market
segments. E.g. if functionality is required rather than usability, then system
testing will have preference over usability testing
– Influence of different quality levels: Is it desirable/feasible to incur the additional
costs of quality? E.g. fault tolerance is only required in highly dependable/safety
critical systems
 Select usable models for quality assessment and analysis
 Map the above external direct quality measures into internal indirect ones via
selected quality models
 QUALITY ASSESSMENT AND IMPROVEMENT
 Measurement:
 defect measurement as part of defect handling process
 other data to track QA activities
 Analysis and modeling:
 input: above data
 output/goal: feedback and follow-up
 focus on quantitative analysis and prediction of defect/risk/reliability
 QUALITY ASSESSMENT AND IMPROVEMENT
 Providing feedback and identifying improvement potentials:
 Results from analysis and modelling activities can provide feedback to the
quality engineering process to help us make project scheduling, resource
allocation, and other management decisions
 When problematic areas are identified by related models, appropriate remedial
actions can be applied for quality and process improvement
 QUALITY ASSESSMENT AND IMPROVEMENT
 Follow-up activities: The immediate use of analysis and modelling results and
follow-up activities can be carried out to affect the long-term quality and
organizational performance.
 If major changes are suggested for the quality engineering process or the
software development process, they typically need to wait until the current
process is finished to avoid unnecessary disturbance and risk to the current
project.
 SQE IN SOFTWARE PROCESSES

 Activity distribution and integration

 SQE process forms an integral part of the overall SE process
 QA activities can be integrated into the software activities (already seen)
 Pre-QA activities:
– quality planning as part of project planning
– Project planning phase in Waterfall process:
• Phase for market analysis, requirement gathering, and product
specification
• Also provides information about customer expectations
o Quality goals can be set accordingly
• Decision on language, tools, and technologies
o Can be expanded to include QE models and measures
 SQE IN SOFTWARE PROCESSES

 Activity distribution and integration

 In alternative software processes other than waterfall, such as in
incremental, iterative, spiral, and extreme programming processes, pre-QA
activities play an even more active role, because they are not only carried out
at the beginning of the whole project, but also at the beginning of each sub
part or iteration due to the nature that each subpart includes more or less all
the elements in the waterfall phases.
 We need to set specific quality goals for each subpart, and choose appropriate
QA activities, techniques, measurement, and models for each subpart.
 SQE IN SOFTWARE PROCESSES
 For normal project monitoring and management, appropriate measurement
activities need to be carried out to collect or extract data from the software
process and related artifacts;
 Analyses need to be performed on these data; and management decision can be
made accordingly.
 Measurement activity cannot be carried out without the involvement of the
software development team, either as part of the normal defect handling and
project tracking activities, or as added activity to provide specific input to related
analysis and modelling.
 SQE IN SOFTWARE PROCESSES

 Timely feedback based on the results from such analyses and models is needed to
make adjustments to the QA and to the development activities
 SQE IN SOFTWARE PROCESSES

 The specific analysis, feedback, and follow-up activities in the software quality
engineering process fit well into the normal software management activities.
 Quality planning at the start of the requirement analysis phase, followed by the
execution of the selected QA activities, and finally followed by the measurement
and analysis activities
SQE IN WATERFALL PROCESS