Software Engineering HT04
Annabella Loconsole
[email protected]
http://www.cs.umu.se/~bella
http://www.cs.umu.se/kurser/TDBB12/HT04/
Course Organisation
Lecture part
o
o
o
o
o
Traditional lectures
Guest lecture
3 Group exercises
2 Assignments
Written examination
Project part
o Teamwork
• Prototype development
o Team meetings
o Oral presentation of results
o Written reports
Examination: Assignments + Exam+ Project
PVK--Ht04
[email protected]
2
Contents
L1:
L2:
L3:
L4:
L5:
L6:
L7:
L8:
PVK--Ht04
Introduction
Requirements engineering
Project management
Guest Lecture - System engineering
Software design
Detailed design and coding
Quality assurance
Maintenance
[email protected]
3
Introduction
What is software engineering
Software development processes
Software quality
Approaches to improve quality
PVK--Ht04
[email protected]
4
Software Problems
Software becomes more and more complex
Software permeates our daily life
Software failures may harm our lives
Software does not meet expectations
Software projects exceed budgets and
schedules
...
PVK--Ht04
[email protected]
5
Ariane 5 Failure (in ’96 and ’02)
Inertial Reference computer (SRI-1) tried to convert 64-bit float
value to 16-bit signed integer. Value too large, raised
exception. SRI-1 computer shut down. Redundant SRI-2
computer performed same conversion, produced same
exception. SRI-2 sent bad data to flight control computer,
which then put the launcher into an unstable flight trajectory.
Result: Self-destruct mechanism was activated.
Failure Cause: improperly constrained computation.
http://news.bbc.co.uk/2/hi/science/nature/2565387.stm
http://www.esa.int/export/esaCP/ESACVS7708D_index_0.html
PVK--Ht04
[email protected]
6
The Software Crisis is not Over
3% 2%
19%
29%
Undeliverable software
Incorrect software
Unsound software
Major redesign needed
Usable after change
21%
OK as delivered
26%
Study from Study from Medvits C et al “SAIC common approach guidance for CMMI”, GAO report on software results
PVK--Ht04
[email protected]
7
What is Software Engineering?
“The establishment and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently on real machines.”
Definition proposed by Fritz Bauer at
the NATO conference ‘68 in Garmisch
[NRB 76]
COMPUTER
SCIENCE
Theories
ENGINEERING
PRINCIPLES
Computer
Functions
Proven
Techniques
CUSTOMER
Problem
SOFTWARE
ENGINEERING
Tools and
Techniques to
Solve Problem
PVK--Ht04
[email protected]
8
But ...
... we all tell each other and ourselves that software engineering
techniques should be improved considerably, because there is a crisis. But
there are a few boundary conditions which apparently have to be
satisfied. I will list them for you:
1. We may not change our thinking habits.
2. We may not change our programming tools.
3. We may not change our hardware.
4. We may not change our tasks.
5. We may not change our organizational set-up in which the work
has to be done.
Now under these five immutable boundary conditions, we have to try to
improve matters. This is utterly ridiculous. ...”
“
Comment by Edsger Dijkstra at the
NATO conference ‘69 in Garmisch
[BuRa 70]
PVK--Ht04
[email protected]
9
Elements of Software Engineering
Methods
Technical “how tos” to support software
development tasks
Languages
Notations to support methods
Tools
(Semi-) automated support for (the usage of)
methods and languages
Processes
Coordination and management of software
development tasks supported by methods,
languages, and tools
Economically produce quality software
PVK--Ht04
[email protected]
10
Software Development Processes
Requirements
Build first
version
Modify until client
is satisfied
development
maintenance Operation
Does this scale up?
PVK--Ht04
[email protected]
11
The Waterfall Model (‘70)
Requirements
Requirements
Analysis
Specification
Planning
Design
Coding
Testing
Installation
Operation and
Maintenance
PVK--Ht04
[email protected]
12
The V model (‘92)
Requirements
Analysis
Validate requirements
Acceptance
Testing
System
Design
Verify design
Program
Design
PVK--Ht04
Operation and
Maintenance
System
Testing
Unit & Integration Testing
Coding
[email protected]
13
The Spiral Model (‘88)
DETERMINE GOALS,
ALTERNATIVES,
CONSTRAINTS
EVALUATE
ALTERNATIVES
AND RISKS
Risk
analysis1
Budget4
Budget3
Budget2 Budget1
start
Requirements,
life-cycle plan
Prototype1
Concept
of operation
Prototype2
Prototype3
Prototype4
Simulations, models
Detailed
design
Code
Unit test
PLAN
PVK--Ht04
Acceptance
test
[email protected]
System
test
DEVELOP AND
TEST
14
Waterfall vs. Spiral Model
Waterfall Model
Model Complexity Simple, linear
sequence of phases
Management
Document driven
Quality Control
Customer
interaction
Natural milestone
after each phase
Spiral Model
Complex, iterative model;
many integrated tasks
Risk driven
Continuous evaluation,
integrated into the model
Prototypes are built and evaluated
by customers in every iteration
No
Risk
High (late feedback)
Low (risk analysis is
integrated in the model)
Usability
Small and/or low
risk projects
Large projects
PVK--Ht04
[email protected]
15
Incremental and Iterative
Processes
Version- and Configuration Control
Maintenance
Reuse
Requirements
Requirements
Engineering
Engineering
Requirements
DesignEngineering
Design
Documentation
Design
Implementation
Implementation
Implementation
Project
Management
PVK--Ht04
Quality
Assurance
[email protected]
16
Rational Unified Process
RUP is a method of managing OO Software Development
It can be viewed as a Software Development Framework
which is extensible and features:
o Iterative Development
o Requirements Management
o Component-Based Architectural Vision
o Visual Modelling of Systems
o Quality Management
o Change Control Management
PVK--Ht04
[email protected]
17
Rup
PVK--Ht04
[email protected]
18
eXtreme Programming
project
PVK--Ht04
[email protected]
19
Rules and Practices of Extreme
Programming
User Stories
Release Plan
Make frequent small releases
Iterative Development
iteration Planning
Move People Around
Daily Stand Up Meeting
Simplicity is the Key
CRC Cards
Create a Spike Solution
Never Add Functionality Early
PVK--Ht04
The Customer is Always
Available
Coding Standards
Code the Unit Test First
Pair Programming
Sequential Integration
Integrate Often
Collective Code Ownership
Optimise Last
No Overtime
Unit Tests
Acceptance Tests
[email protected]
21
Relative Costs of Development
2% 4% 1% Phases
6%
5%
7%
8%
67%
PVK--Ht04
Compiled data from 1976-1981, see [Schach 97].
[email protected]
Requirements
Specification
Planning
Design
Coding
Testing
Integration
Maintenance
22
Relative Costs of an Error
400
368
350
300
Studies from 1974-1980
250
IBM AS/400 [94]
200
200
150
100
52
50
30
1
2
1
2
3
4
3
10
4
10
[email protected]
ai
nt
en
an
ce
M
ra
tio
n
In
te
g
en
ta
tio
n
n
es
ig
D
ng
Pl
an
ni
s
An
al
y
See [Schach 97].
PVK--Ht04
Im
pl
em
R
eq
ui
re
m
en
ts
0
23
Fault vs Failure
can lead to
human error
PVK--Ht04
fault
[email protected]
can lead to
?!
failure
24
Causes of Errors
6%
12%
8%
14%
34%
22%
StudyPVK--Ht04
from 1978, see [GoRu 95].
4%
Incorrect or misunderstood
requirements
Incorrect or misunderstood
specifications
Design faultinvolving
several components
Design- or code fault in one
component
Spelling mistake or similar
Fault correction
Other reasons
[email protected]
25
Introduction
What is Software Engineering
Software Development Processes
Software Quality
Approaches to Improve Quality
PVK--Ht04
[email protected]
26
Quality is ...
…
…
…
…
…
PVK--Ht04
I know it when I see it
it suits the client/user
it conforms to the specification
it has some inherent quality
it depends on the price
[email protected]
27
And Quality is …
Sponsor
Low costs
Increased productivity Efficiency
User
Functionality
Easy to learn
Easy to remember
Short time of delivery
Flexibility
Maintainer/
modifier
PVK--Ht04
Reliability
Easy to use
Few errors
Good design
Readable code
Good documentation
[email protected]
28
Suitability
Functionality
Accuracy
Interoperabilit
y
Security
Maturity
Reliability
Quality
Usability
Factors
(ISO Efficiency
9126) Maintainability
Fault tolerance
Recoverability
Understandabili
ty
Learnability
Operability
Time behavior
Resource
behavior
Analyzability
Changeability
Stability
Testability
Adaptability
Installability
Portability
Conformance
Replaceability
PVK--Ht04
[email protected]
29
How Companies Pursue Software
Quality
9%
1%
None
Slogans
20%
Improved testing
Focus on prevention
42%
Process improvement
Other
24%
4%
PVK--Ht04
[email protected]
A survey from the CASE Research Corporation (1990), see [Yourdon 92].
30
How To Measure Quality?
Quality Factor
depends
on
Property/
Criteria
Property/
Criteria
Efficiency
Property/
Criteria
determined by
Metric
Metric
Metric
Speed
Size
Response time
LOC
...
Metrics are (objective) measurements to determine
(subjective) quality factors
PVK--Ht04
[email protected]
31
Some Example Metrics
To measure efficiency
o Time behaviour
• Transactions per second
• Response time
• Screen refresh time
o Resource behaviour
• KBytes of executables
• LOC
• Number of processors
To measure usability
o Training time
o Number of help frames
To measure reliability
o MTTF (Mean Time To
Failure)
o Availability
To measure robustness
o Time to restart after a
failure
o Probability of data
corruption on failure
To measure portability
o Number of target systems
o Percentage of target
dependent statements
Measurement is necessary
PVK--Ht04
[email protected]
32
Purpose of Measurement
Analysis: Determine current quality
Prediction: Predict future quality
Not only code can be measured, but also
o Products
• Documentation
• Design
PVK--Ht04
oProcesses
•Analysis phase
•Test phase
[email protected]
oResources
•Personnel
•Budget
33
Approaches to Improve Quality
Capability Maturity Model (CMM)
Personal Software Process (PSP)
Inspections
Standards (ISO9000, ...)
Cleanroom engineering
Statistical quality control
Goal Question Metrics (GQM)
…..
PVK--Ht04
[email protected]
34
CMM
Capability Maturity Model
Developed by SEI 1986 (for the DoD)
Five maturity levels
o Initial (ad-hoc process)
o Repeatable (repeatable process)
o Defined (well-defined, documented process)
o Managed (predictable process)
o Optimised (continuous process improvements)
The DoD requires level 3 from all contractors
PVK--Ht04
[email protected]
35
CMM: Levels
PVK--Ht04
[email protected]
36
5:
4:
3:
2:
1:
Optimized:
Process change management
Technology innovation
Defect prevention
Managed:
Quality management
Process measurement and analysis
Defined:
Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus
Repeatable:
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight
Software project planning
Requirements management
Initial
PVK--Ht04
[email protected]
CMM
Key Process
Areas
37
CMM Results
Faults
CMM Development Person Faults detected delivered Total dev. costs
level
in US$
time
months during dev. and installed
1
29,8
593,5
1.348
61
5.440.000
2
18,5
143,0
328
12
1.311.000
3
15,2
79,5
182
7
728.000
4
12,5
42,8
97
5
392.000
5
9,0
16,0
37
1
146.000
Model predictions for the development of a 200.000 LOC data
processing product (1993), see [Schach 97].
PVK--Ht04
[email protected]
42
CMM Process Maturity Profile
of Software Organizations
Maturity Level
1987-91
1997
1999
2001
1- Initial
80%
61%
48%
38%
December
2002
32%
2- Repeatable
12%
23%
30%
34%
37%
3- Defined
7%
14%
16%
20%
21%
4- Managed
0%
2%
4%
5%
5%
5- Optimizing
1%
1%
2%
4%
5%
Organizations
reporting to SEI
130
795
1179
1641
1998
Source: http://www.sei.cmu.edu/sema/profile.html
PVK--Ht04
[email protected]
43
Personal Software Process -PSP
A process for individual developers
o
o
o
o
Well-defined process steps (scripts)
Forms
Instruction for filling in the forms
Standards
Framework for analysis
Tool for individual process improvements
 Developers find more errors
 Developers improve their estimations
 Developers improve productivity
Improvements at “no” costs
PVK--Ht04
[email protected]
44
PSP Overview
Requirements
Planning
logging (time / defects
Plan
Scripts
guide
Design
Coding
Compile
Testing
Post Mortem
Product
PVK--Ht04
[email protected]
Logs
Logs
Result
Plan
&
Summary
Project and Process Data
Summary Report
45
PSP Levels
PSP3
Cyclic development
PSP2.1
PSP2
Code reviews
Design reviews
PSP1
PSP1.1
Size estimating
Test report
PSP0
Current process
Time recording
Defect recording
Defect type standard
PVK--Ht04
Design templates
Task planning
Schedule planning
PSP0.1
Coding standard
Size measurement
Process improvement
proposal (PIP)
[email protected]
46
CMM and PSP
5:
4:
3:
Optimized:
Process change management
Technology innovation
Defect prevention
Managed:
Quality management
Process measurement and analysis
Defined:
Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
2:
Repeatable:
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight
Software project planning
1:
PVK--Ht04
Organization process definition
Organization process focus
Requirements management
Initial
[email protected]
PSP key process areas
47
References
[Boehm 81] B.W. Boehm, Software Engineering Economics, Prentice Hall, 1981. “Classical.”
[BuRa 70]
J.N. Buxton, B. Randell, Proceedings of the 1969 NATO Conference on Software
Engineering, NATO Science Committee, 1970. “Historical.”
[GoRu 95]
A. Goldberg, K.S. Rubin, Succeeding with Objects, Addison-Wesley, 1995. Object-
[Hump 95]
W.S. Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995. Main
[Myers 79]
G.J. Myers, The Art of Software Testing, Wiley, 1979. “Classical.”
Oriented Software Engineering.
PSP textbook.
[Pfleeger 98] S.L. Pfleeger, Software Engineering, Theory and Practice, Prentice Hall,
1998.
[Schach 97] S.R. Schach, Software Engineering with Java, Irwin, 1997.
[Somm 96]
I. Sommerville: Software Engineering, Addison-Wesley, 1996.
[Yourdon 92] E. Yourdon, Decline and Fall of the American Programmer, Prentice Hall, 1992.
Critical Software Engineering textbook.
PVK--Ht04
[email protected]
48