7/29/2019 Ch04 Process
1/24
within a Software Process
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 1
7/29/2019 Ch04 Process
2/24
development process u an overa p c ure o e qua y process
Identify the main characteristics of a quality
process visibility
anticipation of activities
feedback
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 2
7/29/2019 Ch04 Process
3/24
Quality results from a set of inter-dependent activities
Analysis and testing are crucial but far from sufficient.
Testing is not a phase, but a lifestyle Testing and analysis activities occur from early in requirements
engineering through delivery and subsequent evolution. Quality depends on every part of the software process
software test and analysis is thoroughly integrated and
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 3
7/29/2019 Ch04 Process
4/24
responsibilitiesdependability
usability
selecting and arranging activities
-important goals.
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 4
7/29/2019 Ch04 Process
5/24
high dependability vs. time to market
better to achieve a reasonably high degree of dependability on
a tight schedule than to achieve ultra-high dependability on a
much longer schedule Critical medical devices:
etter to ac eve u tra- g epen a ty on a muc ongerschedule than a reasonably high degree of dependability on a
tight schedule
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 5
7/29/2019 Ch04 Process
6/24
planned to detect each important class of.
Timeliness: Faults are detected at a point of
g everage as ear y as poss e Cost-effectiveness: Activities are chosen
depending on cost and effectiveness
cost must be considered over the wholedevelopment cycle and product life
the dominant factor is usually the cost of repeating
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 6
an ac v y roug many c ange cyc es.
7/29/2019 Ch04 Process
7/24
Balances several activities across the whole
Selects and arranges them to be as cost-effective as
Improves early visibility
careful planning
ann ng s n egra o e qua y process
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 7
7/29/2019 Ch04 Process
8/24
the question
How does our progress compare to our plan? Example: Are we on schedule? How far ahead or behind?
The quality process has not achieved adequate visibility
the software system before it reaches final testing quality activities are usually placed as early as possible
design test cases at the earliest opportunity (not ``just in time'')
uses analysis techniques on software artifacts produced before
actual code. motivates the use of proxy measures
Ex: the number of faults in design or code is not a true measure ofreliability, but we may count faults discovered in design
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 8
nspect ons as an ear y n cator o potent a qua ty pro ems
7/29/2019 Ch04 Process
9/24
- -
that must be satisfied , . .,certificates
documents that must be produced
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 9
7/29/2019 Ch04 Process
10/24
A com rehensive descri tion of the ualit rocess that
includes:
objectives and scope of A&T activities items to be tested features to be tested and not to be tested
staff involved in A&T constraints
pass an a cr ter a schedule
deliverables hardware and software requirements risks and contingencies
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 10
7/29/2019 Ch04 Process
11/24
,....
Product qualities internal qualities (maintainability,....)
usefulness qualities: , , , ,
interoperability
dependability correctness, reliability, safety, robustness
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 11
7/29/2019 Ch04 Process
12/24
A program is correct if it is consistent with its specification
seldom practical for non-trivial systems
Reliability: likelihood of correct function for some ``unit'' of behavior
relative to a specification and usage profile statistical approximation to correctness (100% reliable = correct)
preventing hazards
acceptable (degraded) behavior under extreme conditions
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 12
7/29/2019 Ch04 Process
13/24
,
let traffic pass according
to correct pattern andcentral scheduling
Robustness safet :
Provide degradedfunction when possible;never signal conflictinggreens.
Blinking red / blinkingyellow is better than nolights; no lights is better
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 13
t an con ct ng greens
7/29/2019 Ch04 Process
14/24
robust but notreliable but
safe: catastrophicfailures can occur
not correct:failures
occur rarel
Correct Safe
safe but not
correct:
correct butnot safe or
robust: theannoying
failures canoccu
specificationis inadequate
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 14
7/29/2019 Ch04 Process
15/24
manual inspection techniques au oma e ana yses
can be applied at any development stage
particularly well suited at the early stages ofspecifications an design
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 15
7/29/2019 Ch04 Process
16/24
can be a lied to essentiall an document requirements statements
architectural and detailed design documents program source code
may also have secondary benefits spreading good practices instilling shared standards of quality.
takes a considerable amount of time re-inspecting a changed component can be expensive
used primarily w ere ot er tec niques are inapp ica e where other techniques do not provide sufficient coverage
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 16
7/29/2019 Ch04 Process
17/24
can be applied to some formal representations of
not to natural language documents
substituting machine cycles for human effort makes- .
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 17
7/29/2019 Ch04 Process
18/24
Start as early as possible Early test generation has several advantages
Tests generated independently from code, when the
specifications are fresh in the mind of analysts The generation of test cases may highlight
ncons s enc es an ncomp e eness o ecorresponding specifications
specifications by the programmers
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 18
7/29/2019 Ch04 Process
19/24
It is important to structure the process for Identifying the most critical persistent faults
tracking them to frequent errors
adjusting the development and quality processes toeliminate errors
Feedback mechanisms are the main ingredient
of the quality process for identifying andremoving errors
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 19
7/29/2019 Ch04 Process
20/24
separate development and quality teams is common
indistinguishable roles is postulated by some
Different roles for development and quality?
mobility of people and roles by rotating engineers
projects is a possible option
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 20
7/29/2019 Ch04 Process
21/24
Example of Allocation of
Responsibilities
we can allocate
Unit testing to the development team (requires detailed knowledge of the
code)
but the quality team may control the results (structural coverage)
Integration, system and acceptance testing to the quality team
but the development team may produce scaffolding and oracles
Inspection and walk-through to mixed teams
to quality and maintenance teams
Process improvement related activities
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 21
o ex erna spec a s s n erac ng w a eams
7/29/2019 Ch04 Process
22/24
Allocation of Responsibilities and rewarding
mechanisms: case A allocation of res onsibilities
Development team responsible development m
easured with LOC per person month Quality team responsible for quality
possible effect
Development team tries to maximize productivity,without considering quality
ua y eam w no ave enoug resources or aquality products
product of bad quality and overall project failure
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 22
7/29/2019 Ch04 Process
23/24
Allocation of Responsibilities and rewarding
mechanisms: case B
Development team responsible for both
possible effect
e pro em o case s so ve
but the team may delay testing for development
result
e ivery o a not u y teste pro uct an overaproject failure
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 23
7/29/2019 Ch04 Process
24/24
must be sutiably planned and monitored
principles:
early activities feedback
aims at
reducin occurrences of faults assessing the product dependability before delivery
improving the process
(c) 2007 Mauro Pezz & Michal Young Ch 4, slide 24