Download Course summary TDT4235

Course summary
TDT4235
Tor Stålhane
IDI / NTNU
What we try to do
• QA – Create trust to a product or service
• SPI – Solve fuzzy problems by
–
–
–
–
Identifying and describing the problem
Collect information to understand the problem
Select a potentially useful technique
Arrive at a useable solution
Create trust
Domain
knowledge
Product
Trust
Tools and
methods
A “soft” problem
Experience
Problem
Method 1
Method 4
Method …
Method 3
Method n
Possible
solution
Method 6
Method …
Method 2
Method 7
Method 5
Available tools
and methods
Summary of Quality Assurance – 1
QA is about two things:
• Having a way of working that is
– Defined – there is clear description
– Documented, written down for everybody to see
– Communicated, everybody in the company knows
about it
– Agreed-upon, everybody in the company works this
way
• Keeping our promises. When we have promised
to do the job in a certain way, this is how it will be
done if nothing else is agreed upon later.
Summary of Quality Assurance – 2
The QA department or the QA responsible
needs to
• Check that we keep our promises
• Look for improvement opportunities
– New things to do
– Things to change
– Things we should stop doing
Summary of Quality Assurance – 3
Quality control is
• not software process improvement
• a way to keep status quo.
t
Old status
quo
Chaos
Integrate
and
practice
New status quo
Summary of SPI – 1
This part of the summary will focus on the SPI
part of the course. The main messages are:
• SPI => change
• Change => risk
• Risk can be reduced or controlled by
– Collecting data
– Analysing data
Summary of SPI – 2
Sociology
Risk analysis
Data analysis
Where do
the problems
come from?
Process
change
Economy
Software
engineering
Cost / benefit
Summary of SPI – 3
The amount and type of data that we need to
collect will depend on our
• Willingness to accept risk
• Time frame – when do we need it
• Planning horizon
The trade-off diagram
Experience
100%
Data
Risk
Risk management – 1
“Risk management is project management for
grown-ups”
Needs to identify
• Risks – what can go wrong?
– Frequency or probability
– Consequences
– Mitigation – what can we do about it?
Risk management – 2
Need to consider both risk, benefits and
opportunities.
• Only benefits => too optimistic
• Only risks => too pessimistic
• Not opportunities => will not be able to grab
them when and if they arise
Risk management – 2
Need to consider both risk, benefits and
opportunities.
• Only benefits => too optimistic
• Only risks => too pessimistic
• Not opportunities => will not be able to grab
them when and if they arise
The total view
Benefits
C
H
A, C are opportunities
B is a benefit
B
M
A
L
L
Probability
M
L
M
H
Costs
C
E
H
D
D is a cost
C, E are risks
The complete picture
Benefits
C
H
A, C are opportunities
B is a benefit
B
M
A
L
L
Probability
M
L
M
H
Costs
C
E
H
D
D is a cost
C, E are risks
This will not happen by itself – it must be planned
for. We must identify risk mitigations and
opportunity enablers. Otherwise, we should just
skip the whole thing
How much risk are we willing to take
A
P
C
D
A
P
C
D
A
P
C
D
Complete PDCA cycle:
• P – identify problem
• D – perform one or more experiments
• C – analyze experiment data
• A – act on the basis of the analysis
PDCA without data collection
• P - identify problem
• D – collect subjective data
• C – analyze subjective data
• A - act on the basis of the results
PDCA – blind faith version
• P – none
• D – none
• C – none
• A – do whatever the gurus says
The data collection process
As shown in the next diagram, we will keep on
collecting data until we
• Can reduce the decision risks to an acceptable
level
• Run out of time or money
Plan SPI activities
Collect info
Perform risk
assessment
No
Acceptable
risk
Yes
Final SPI plan
More time
available
Yes
Qualitative
Data collection
Quantitative
Qualitative
Data analysis
Company
priorities
Improvement
opportunities
Improvement
activity
Improvement
implementation
Quantitative
Qualitative
Data collection
Quantitative
Qualitative
Affinity diagrams
Interviews
Questionnaires
Gap analysis
SWOT
Data archaeology
GQM
Error reports
Surveys
Data archaeology
Data plots
RCA – trees and networks
Force fields
Data analysis
Quantitative
Statistics
PDCA and risk
The amount of risk we are willing to accept and
the corresponding actions or lack thereof can be
illustrated by using different versions of the
PDCA cycle.
Improvements
Risk assessment
Introduce changes
What are the results
Needs
Act
Plan
Check
Do
Plotting techniques
Statistical analyses
Root Cause Analysis
Risk assessment
SWOT / SWIR
Gap analysis
Planning
Risk assessment
Delphi analysis
Data archeology
KJ / affinity diagrams
Pilot projects
GQM
Post Mortem Analysis
Improvements
Risk assessment
Introduce changes
What are the results
Root Cause
Analysis
Needs
SWOT / SWIR
Act
Plan
Check
Do
Data archeology
Delphi analysis
Improvements
Needs
Risk assessment
Introduce changes
What are the results
Planning
Act
Plan
Check
Do
GQM
Pilot project
Plotting techniques
Statistical analyses
Root Cause Analysis
Improvements
Needs
Risk assessment
Introduce changes
What are the results
Gap analysis
Root Cause Analysis
Act
Plan
Check
Do
KJ / affinity diagrams
Improvements
Risk assessment
Introduce changes
What are the results
Needs
Act
Plan
Check
Do
Post Mortem Analysis
Gap analysis
Risk assessment
Process
PMA
Project
Measurement
Relevant
data
Historical
data
Knowledge
Experience
Analysis
Improvement
opportunities
Process
GQM
Project
Measurement
Relevant
data
Historical
data
Knowledge
Experience
Analysis
Improvement
opportunities
Proactive SPI or
Only subjective
data – e.g. Delphi
Process
Project
Measurement
Relevant
data
Historical
data
Knowledge
Experience
Analysis
Improvement
opportunities
What is the status?
e.g. SWOT
Select area
Management decides
Results
Action
Results
Action
Results
Action
Results
Action
Results
Action
Collect data
Analyze data
Results
Action
The trade-off diagram
Experience
100%
Data
Risk
We will often have to be here
We would like to be here
Last – but not least
There is a clear tendency for the software
industry to move towards more fast, small
projects
SPI and QA will have to follow or run the risk of
being irrelevant.