PezzeYoung Ch20 Planning

Planning and Monitoring the Process
(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 1

Learning objectives
• Understand the purposes of planning and
monitoring
• Distinguish strategies from plans, and
understand their relation
• Understand the role of risks in planning
• Understand the potential role of tools in
monitoring a quality process
• Understand team organization as an integral
part of planning

What are Planning and Monitoring?
• Planning:
– Scheduling activities (what steps? in what order?)
– Allocating resources (who will do it?)
– Devising unambiguous milestones for monitoring
• Monitoring: Judging progress against the plan
– How are we doing?
• A good plan must have visibility :

– Ability to monitor each step, and to make objective
judgments of progress
– Counter wishful thinking and denial

Quality and Process
• Quality process: Set of activities and responsibilities
– focused primarily on ensuring adequate dependability
– concerned with project schedule or with product usability
• A framework for
– selecting and arranging activities
– considering interactions and trade-offs
• Follows the overall software process in which it is
embedded
– Example: waterfall software process ––> “V model”: unit
testing starts with implementation and finishes before
integration
– Example: XP and agile methods ––> emphasis on unit testing
and rapid iteration for acceptance testing by customers
Example Process: Cleanroom
Customer Requirements
Specification
Function Usage
Incremental
Functional specifications Usage specifications
Development
Planning
Formal Design Statistical test case
Correctness Verification generation
Source
Test cases
code
Statistical testing
Interfail times
Improvement Feedback
Quality Certification Model
MTTF statistics
Example Process: Cleanroom
Customer Requirements
Activities and Integrated into an
responsibilities overall development
Specification process
focused on quality
Function Usage
Incremental
Functional specifications Usage specifications
Development
Planning
Formal Design Statistical test case
Correctness Verification generation
Source
Test cases
code
Statistical testing
Interfail times
Improvement Feedback
Quality Certification Model
MTTF statistics
Example Process: Software Reliability
Engineering Testing (SRET)
Define “Necessary”
Reliability
Development
Operational Profiles
Prepare
for Testing
Interpret Failure
Execute Data
tests
Requirements and Design and System Test and

Architecture Implementation Acceptance Test

Software Reliability Engineering Testing
(SRET)
Define “Necessary” Activities and
Reliability responsibilities
focused on quality
Development
Operational Profiles
Prepare
Integrated into an for Testing
overall development
process Interpret Failure
Execute Data
tests
Requirements and Design and System Test and

Architecture Implementation Acceptance Test

Example Process: Extreme Programming
(XP)
Next version Incremental

Release
Review,
Refine,
prioritiz Passed all unit pass
e tests
Pair Passed all
Generate User Create Unit Acceptance
Programming unit tests
Stories Tests Testing
+ unit testing
Failed acceptance test
Create
Acceptance
Tests

Extreme Programming (XP)
Activities and
responsibilities Next version Incremental
focused on quality Release
Review,
Refine,
prioritiz Passed all unit pass
e tests
Pair Passed all
Generate User Create Unit Acceptance
Programming unit tests
Stories Tests Testing
+ unit testing
Failed acceptance test
Create
Acceptance Integrated into an
Tests overall development
process

Overall Organization
of a Quality Process
• Key principle of quality planning
– the cost of detecting and repairing a fault increases
as a function of time between committing an error
and detecting the resultant faults
• therefore ...
– an efficient quality plan includes matched sets of
intermediate validation and verification activities
that detect most faults within a short time of their
introduction
• and ...
– V&V steps depend on the intermediate work
products and on their anticipated defects

Verification Steps
for Intermediate Artifacts
• Internal consistency checks
– compliance with structuring rules that define “well-formed”
artifacts of that type
– a point of leverage: define syntactic and semantic rules
thoroughly and precisely enough that many common errors
result in detectable violations
• External consistency checks
– consistency with related artifacts
– Often: conformance to a “prior” or “higher-level” specification
• Generation of correctness conjectures
– Correctness conjectures: lay the groundwork for external
consistency checks of other work products
– Often: motivate refinement of the current product

Strategies vs Plans
Strategy Plan
Scope Organization Project
Structure Organization structure, Standard structure

and content experience and policy prescribed in
based on over several projects strategy
Evolves Slowly, with Quickly, adapting to
organization and policy project needs
changes

Test and Analysis Strategy
• Lessons of past experience
– an organizational asset built and refined over time
• Body of explicit knowledge
– more valuable than islands of individual competence
– amenable to improvement
– reduces vulnerability to organizational change (e.g.,
loss of key individuals)
• Essential for
– avoiding recurring errors
– maintaining consistency of the process
– increasing development efficiency

Considerations in Fitting a Strategy to
an Organization
• Structure and size
– example
• Distinct quality groups in large organizations, overlapping of roles in
smaller organizations
• greater reliance on documents in large than small organizations
• Overall process
– example
• Cleanroom requires statistical testing and forbids unit testing
– fits with tight, formal specs and emphasis on reliability
• XP prescribes “test first” and pair programming
– fits with fluid specifications and rapid evolution
• Application domain
– example
• Safety critical domains may impose particular quality objectives and
require documentation for certification (e.g,RTCA/DO-178B standard
requires MC/DC coverage)

Elements of a Strategy
• Common quality requirements that apply to all
or most products
– unambiguous definition and measures
• Set of documents normally produced during the
quality process
– contents and relationships
• Activities prescribed by the overall process
– standard tools and practices
• Guidelines for project staffing and assignment
of roles and responsibilities
Test and Analysis Plan
Answer the following questions:
• What quality activities will be carried out?
• What are the dependencies among the quality
activities and between quality and other
development activities?
• What resources are needed and how will they
be allocated?
• How will both the process and the product be
monitored?

Main Elements of a Plan
• Items and features to be verified
– Scope and target of the plan
• Activities and resources
– Constraints imposed by resources on activities
• Approaches to be followed
– Methods and tools
• Criteria for evaluating results

Quality Goals
• Expressed as properties satisfied by the product
– must include metrics to be monitored during the
project
– example: before entering acceptance testing, the
product must pass comprehensive system testing
with no critical or severe failures
– not all details are available in the early stages of
development
• Initial plan
– based on incomplete information
– incrementally refined

Task Schedule
• Initially based on
– quality strategy
– past experience
• Breaks large tasks into subtasks
– refine as process advances
• Includes dependencies
– among quality activities
– between quality and development activities
• Guidelines and objectives:
– schedule activities for steady effort and continuous progress
and evaluation without delaying development activities
– schedule activities as early as possible
– increase process visibility (how do we know we’re on track?)

Sample Schedule
1 st quarter 2nd quarter 3 rd quarter
ID Task N ame
1/7 2 /4
1 D evelopm ent fram ework
2 R equirements specifications
3 Architectural design
D etailed design of shopping
4
facility subsys .
D etailed design of
5
administrative biz logic
Shopping fac code and
6
integration (incl unit test )
Sync and stabilize shopping
7
fac .
8
Admin biz logic code and
integration (including unit test )
Sync and stabilize
9
administrative biz logic
10 D esign inspection
Inspection of requirements
11
specs .
Inspection of architectural
12
design
13
Inspection of det . D esign of
shop . facilities
14
Inspection of detailed design
of admin logic
15 C ode inspection
16
Inspection of shop . Fun . C ore
code and unit tests
17
Inspection of admin . Biz . Log .
C ode code and unit tests
18 D esign tests
19 D esign acceptance tests
20 D esign system tests

D esign shop fun subsystem
21
integration test
22
D esign admin bix log
subsystem integration tests
23 Test execution
24 Exec integration tests

25 Exec system tests
26 Exec acceptance tests

Schedule Risk
• critical path = chain of activities that must be
completed in sequence and that have maximum overall
duration
– Schedule critical tasks and tasks that depend on critical tasks
as early as possible to
• provide schedule slack
• prevent delay in starting critical tasks
• critical dependence = task on a critical path scheduled
immediately after some other task on the critical path
– May occur with tasks outside the quality plan
(part of the project plan)
– Reduce critical dependences by decomposing tasks on critical
path, factoring out subtasks that can be performed earlier

Reducing the Impact of Critical Paths
Task name January Febrary March April May
CRITICAL SCHEDULE
Project start
Analysis and design

Code and integration
Design and execute

subsystem tests
Design and execute

system tests
Produce user
documentation
Product delivery

UNLIMITED RESOURCES
Project start
Analysis and design

Design subsystem tests
Design system tests
Produce user
documentation
Execute subsystem
tests
Execute system tests
Product delivery

LIMITED RESOURCES
Project start
Analysis and design

Design subsystem tests
Design system tests
Produce user
documentation
Execute subsystem
tests
Execute system tests
Product delivery

Risk Planning
• Risks cannot be eliminated, but they can be
assessed, controlled, and monitored
• Generic management risk
– personnel
– technology
– schedule
• Quality risk
– development
– execution
– requirements

Personnel
Example Risks Control Strategies
• Loss of a staff • cross training to avoid over-
member dependence on individuals
• Staff member • continuous education
under-qualified for • identification of skills gaps
task early in project
• competitive compensation and
promotion policies and
rewarding work
• including training time in
project schedule

Technology
• High fault rate due • Anticipate and schedule extra
to unfamiliar COTS time for testing unfamiliar
interfaces.
component
interface • Invest training time for COTS
components and for training
• Test and analysis with new tools
automation tools do • Monitor, document, and
not meet publicize common errors and
expectations correct idioms.
• Introduce new tools in lower-
risk pilot projects or
prototyping exercises

Schedule
• Inadequate unit • Track and reward quality unit
testing leads to testing as evidenced by low
unanticipated fault densities in integration
expense and delays • Set aside times in a weekly
in integration schedule in which inspections
testing take precedence over other
• Difficulty of meetings and work
scheduling meetings • Try distributed and
makes inspection a asynchronous inspection
bottleneck in techniques, with a lower
development frequency of face-to-face
inspection meetings

Development
• Poor quality • Provide early warning and
software delivered feedback
to testing group • Schedule inspection of design,
• Inadequate unit code and test suites
test and analysis • Connect development and
before committing inspection to the reward
to the code base
system
• Increase training through
inspection
• Require coverage or other
criteria at unit test level

Test Execution
• Execution costs higher • Minimize parts that
than planned require full system to be
• Scarce resources executed
available for testing • Inspect architecture to
assess and improve
testability
• Increase intermediate
feedback
• Invest in scaffolding

Requirements
Example Risk Control Strategies
• High assurance • Compare planned testing
critical requirements effort with former projects
increase expense with similar criticality level
and uncertainty to avoid underestimating
testing effort
• Balance test and analysis
• Isolate critical parts,
concerns and properties

Contingency Plan
• Part of the initial plan

– What could go wrong? How will we know, and how
will we recover?
• Evolves with the plan
• Derives from risk analysis
– Essential to consider risks explicitly and in detail
• Defines actions in response to bad news
– Plan B at the ready (the sooner, the better)

Evolution of the Plan
Preliminary First Second Final

plan release release … plan
Emergency
plan

Process Monitoring
• Identify deviations from the quality plan as

early as possible and take corrective action
• Depends on a plan that is
– realistic
– well organized
– sufficiently detailed with clear, unambiguous
milestones and criteria
• A process is visible to the extent that it can be
effectively monitored

Evaluate Aggregated Data by Analogy
160
140
120
100 Total
faults
Critical
80
Severe
60 Moderate
40
20
0
1 3 5
Builds 7 9

Process Improvement
Monitoring and improvement within a

project or across multiple projects:
Orthogonal Defect Classification (ODC)
&Root Cause Analysis (RCA)

Orthogonal Defect Classification (ODC)
• Accurate classification schema
– for very large projects
– to distill an unmanageable amount of detailed
information
• Two main steps
– Fault classification
• when faults are detected
• when faults are fixed
– Fault analysis

ODC Fault Classification
When faults are detected
• activity executed when the fault is revealed
• trigger that exposed the fault
• impact of the fault on the customer
When faults are fixed
• Target: entity fixed to remove the fault
• Type: type of the fault
• Source: origin of the faulty modules (in-house, library,
imported, outsourced)
• Age of the faulty element (new, old, rewritten, re-fixed
code)

ODC activities and triggers
• Review and Code Inspection • Functional (Black box) Test
– Design Conformance: – Coverage
– Logic/Flow – Variation
– Backward Compatibility – Sequencing
– Internal Document – Interaction
– Lateral Compatibility • System Test
– Concurrency – Workload/Stress
– Language Dependency – Recovery/Exception
– Side Effects – Startup/Restart
– Rare Situation – Hardware Configuration
• Structural (White Box) Test – Software Configuration
– Simple Path – Blocked Test
– Complex Path

ODC impact
• Installability • Usability
• Integrity/Security • Standards
• Performance • Reliability
• Maintenance • Accessibility
• Serviceability • Capability
• Migration • Requirements
• Documentation

ODC Fault Analysis (example 1/4)
• Distribution of fault types versus activities

– Different quality activities target different classes of faults
– example:
• algorithmic faults are targeted primarily by unit testing.
– a high proportion of faults detected by unit testing should belong to
this class
• proportion of algorithmic faults found during unit testing
– unusually small
– larger than normal
 unit tests may not have been well designed
• proportion of algorithmic faults found during unit testing unusually
large
 integration testing may not focused strongly enough on interface
faults

• Distribution of triggers over time during field test

– Faults corresponding to simple usage should arise early during
field test, while faults corresponding to complex usage should
arise late.
– The rate of disclosure of new faults should asymptotically
decrease
– Unexpected distributions of triggers over time may indicate
poor system or acceptance test
• Triggers that correspond to simple usage reveal many faults late in
acceptance testing
 The sample may not be representative of the user population
• Continuously growing faults during acceptance test
 System testing may have failed

• Age distribution over target code

– Most faults should be located in new and rewritten code
– The proportion of faults in new and rewritten code with
respect to base and re-fixed code should gradually increase
– Different patterns
 may indicate holes in the fault tracking and removal process
 may indicate inadequate test and analysis that failed in
revealing faults early
– Example
• increase of faults located in base code after porting
 may indicate inadequate tests for portability

• Distribution of fault classes over time

– The proportion of missing code faults should
gradually decrease
– The percentage of extraneous faults may slowly
increase, because missing functionality should be
revealed with use
• increasing number of missing faults
 may be a symptom of instability of the product
• sudden sharp increase in extraneous faults
 may indicate maintenance problems

Improving the Process
• Many classes of faults that occur frequently are rooted
in process and development flaws
– examples
• Shallow architectural design that does not take into account
resource allocation can lead to resource allocation faults
• Lack of experience with the development environment, which
leads to misunderstandings between analysts and programmers on
rare and exceptional cases, can result in faults in exception
handling.
• The occurrence of many such faults can be reduced by
modifying the process and environment
– examples
• Resource allocation faults resulting from shallow architectural
design can be reduced by introducing specific inspection tasks
• Faults attributable to inexperience with the development
environment can be reduced with focused training

Improving Current and Next Processes
• Identifying weak aspects of a process can be
difficult
• Analysis of the fault history can help software
engineers build a feedback mechanism to track
relevant faults to their root causes
– Sometimes information can be fed back directly into
the current product development
– More often it helps software engineers improve the
development of future products

Root cause analysis (RCA)
• Technique for identifying and eliminating
process faults
– First developed in the nuclear power industry; used
in many fields.
• Four main steps
– What are the faults?
– When did faults occur? When, and when were they
found?
– Why did faults occur?
– How could faults be prevented?

What are the faults?
• Identify a class of important faults
• Faults are categorized by
– severity = impact of the fault on the product
– Kind
• No fixed set of categories; Categories evolve and adapt
• Goal:
– Identify the few most important classes of faults and remove
their causes
– Differs from ODC: Not trying to compare trends for different
classes of faults, but rather focusing on a few important
classes

Fault Severity
Level Description Example
Critical The product is unusable The fault causes the program to crash
Severe Some product features The fault inhibits importing files

cannot be used, and there saved with a previous version of the
is no workaround program, and there is no workaround
Moderate Some product features The fault inhibits exporting in
require workarounds to Postscript format.
use, and reduce Postscript can be produced using the
efficiency, reliability, or printing facility, but with loss of
convenience and usability usability and efficiency
Cosmetic Minor inconvenience The fault limits the choice of colors
for customizing the graphical
interface, violating the specification
but causing only minor inconvenience

Pareto Distribution (80/20)
• Pareto rule (80/20)
– in many populations, a few (20%) are vital and many
(80%) are trivial
• Fault analysis
– 20% of the code is responsible for 80% of the faults
• Faults tend to accumulate in a few modules
– identifying potentially faulty modules can improve the cost
effectiveness of fault detection
• Some classes of faults predominate
– removing the causes of a predominant class of faults can have
a major impact on the quality of the process and of the
resulting product

Why did faults occur?
• Core RCA step
– trace representative faults back to causes
– objective of identifying a “root” cause
• Iterative analysis
– explain the error that led to the fault
– explain the cause of that error
– explain the cause of that cause
– ...
• Rule of thumb
– “ask why six times”

Example of fault tracing
• Tracing the causes of faults requires experience,
judgment, and knowledge of the development process
• example
– most significant class of faults = memory leaks
– cause = forgetting to release memory in exception handlers
– cause = lack of information: “Programmers can't easily
determine what needs to be cleaned up in exception handlers”
– cause = design error: “The resource management scheme
assumes normal flow of control”
– root problem = early design problem: “Exceptional conditions
were an afterthought dealt with late in design”

How could faults be prevented?
• Many approaches depending on fault and process:
• From lightweight process changes
– example
• adding consideration of exceptional conditions to a design
inspection checklist
• To heavyweight changes:
– example
• making explicit consideration of exceptional conditions a part of
all requirements analysis and design steps
Goal is not perfection, but cost-effective

improvement

The Quality Team
• The quality plan must assign roles and
responsibilities to people
• assignment of responsibility occurs at
– strategic level
• test and analysis strategy
• structure of the organization
• external requirements (e.g., certification agency)
– tactical level
• test and analysis plan

Roles and Responsibilities
at Tactical Level
• balance level of effort across time
• manage personal interactions
• ensure sufficient accountability that quality tasks are
not easily overlooked
• encourage objective judgment of quality
• prevent it from being subverted by schedule pressure
• foster shared commitment to quality among all team
members
• develop and communicate shared knowledge and values
regarding quality

Alternatives in Team Structure
• Conflicting pressures on choice of structure
– example
• autonomy to ensure objective assessment
• cooperation to meet overall project objectives
• Different structures of roles and responsibilities
– same individuals play roles of developer and tester
– most testing responsibility assigned to a distinct group
– some responsibility assigned to a distinct organization
• Distinguish
– oversight and accountability for approving a task
– responsibility for actually performing a task

Roles and responsibilities
pros and cons
• Same individuals play roles of developer and tester
– potential conflict between roles
• example
– a developer responsible for delivering a unit on schedule
– responsible for integration testing that could reveal faults that delay
delivery
– requires countermeasures to control risks from conflict
• Roles assigned to different individuals
– Potential conflict between individuals
• example
– developer and a tester who do not share motivation to deliver a
quality product on schedule
– requires countermeasures to control risks from conflict

Independent Testing Team
• Minimize risks of conflict between roles played by the
same individual
– Example
• project manager with schedule pressures cannot
– bypass quality activities or standards
– reallocate people from testing to development
– postpone quality activities until too late in the project
• Increases risk of conflict between goals of the
independent quality team and the developers
• Plan
– should include checks to ensure completion of quality activities
– Example
• developers perform module testing
• independent quality team performs integration and system testing
• quality team should check completeness of module tests

Managing Communication
• Testing and development teams must share the goal of
shipping a high-quality product on schedule
– testing team
• must not be perceived as relieving developers from responsibility
for quality
• should not be completely oblivious to schedule pressure
• Independent quality teams require a mature
development process
– Test designers must
• work on sufficiently precise specifications
• execute tests in a controllable test environment
• Versions and configurations must be well defined
• Failures and faults must be suitably tracked and
monitored across versions
Testing within XP
• Full integration of quality activities with development
– Minimize communication and coordination overhead
– Developers take full responsibility for the quality of their work
– Technology and application expertise for quality tasks match
expertise available for development tasks
• Plan
– check that quality activities and objective assessment are not
easily tossed aside as deadlines loom
– example
• XP “test first” together with pair programming guard against some
of the inherent risks of mixing roles

Outsourcing Test and Analysis
• (Wrong) motivation
– testing is less technically demanding than development and can
be carried out by lower-paid and lower-skilled individuals
• Why wrong
– confuses test execution (straightforward) with analysis and test
design (as demanding as design and programming)
• A better motivation
– to maximize independence
• and possibly reduce cost as (only) a secondary effect
• The plan must define
– milestones and delivery for outsourced activities
– checks on the quality of delivery in both directions

Summary
• Planning is necessary to
– order, provision, and coordinate quality activities
• coordinate quality process with overall development
• includes allocation of roles and responsibilities
– provide unambiguous milestones for judging progress
• Process visibility is key
– ability to monitor quality and schedule at each step
• intermediate verification steps: because cost grows with
time between error and repair
– monitor risks explicitly, with contingency plan ready
• Monitoring feeds process improvement
– of a single project, and across projects

PezzeYoung Ch20 Planning

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PezzeYoung Ch20 Planning

Uploaded by

Copyright:

Available Formats

Planning and Monitoring the Process

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 1

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 2

• A good plan must have visibility :

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 3

Requirements and Design and System Test and

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 7

Requirements and Design and System Test and

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 8

Next version Incremental

Failed acceptance test

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 9

Failed acceptance test

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 10

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 11

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 12

Structure Organization structure, Standard structure

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 13

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 14

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 15

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 17

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 18

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 19

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 20

19 D esign acceptance tests

20 D esign system tests

24 Exec integration tests

26 Exec acceptance tests

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 21

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 22

Analysis and design

Design and execute

Design and execute

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 23

Analysis and design

Design subsystem tests

Design system tests

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 24

Analysis and design

Design subsystem tests

Design system tests

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 25

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 27

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 28

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 29

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 30

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 31

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 32

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 33

• Part of the initial plan

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 34

Preliminary First Second Final

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 35

• Identify deviations from the quality plan as

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 36

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 37

Monitoring and improvement within a

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 38

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 39

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 40

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 41

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 42

• Distribution of fault types versus activities

(c) 2007 Mauro Pezzè & Michal Young Ch 20, slide 43