Software Engineering
Hans van Vliet
Vrije Universiteit
Amsterdam, The Netherlands
email: hans@[Link]
ARIANE Flight 501
Disintegration after 39 sec
Caused by large correction for attitude deviation
Caused by wrong data being sent to On Board
Computer
Caused by software exception in Inertial
Reference System after 36 sec.
SE, Introduction, Hans van Vliet, 2008 2
The details
Overflow in conversion of variable BH from 64-bit
floating point to 16-bit signed integer
Of 7 risky conversions, 4 were protected; BH was
not
Reasoning: physically limited, or large margin of
safety
In case of exception: report failure on databus and
shut down
SE, Introduction, Hans van Vliet, 2008 3
Possible explanations
Inadequate testing
Wrong type of reuse
Wrong design philosophy
SE, Introduction, Hans van Vliet, 2008 4
Inadequate testing?
Specification does not contain Ariane 5 trajectory
data as a functional requirement
In tests, the SRIs (components that measure
altitude and movements of the launcher) were
simulated by software modules
SE, Introduction, Hans van Vliet, 2008 5
Improper reuse?
If a component works perfectly well in one
environment, it doesnt necessarily do so in
another
Ariane 5 is much faster than Ariane 4, and
horizontal velocity builds up more rapidly
excessive values for parameter in question
Wish for quick alignment after hold in shutdown
this software runs for a while after lift-off. It
doesnt have any purpose for the Ariane 5, but
was still kept
SE, Introduction, Hans van Vliet, 2008 6
Wrong design philosophy?
If something breaks down, such is caused by a
random hardware failure
Action: shut down that part
There is no provision for design errors
SE, Introduction, Hans van Vliet, 2008 7
Further information:
IEEE Computer, jan. 1997, p. 129-130
[Link]
SE, Introduction, Hans van Vliet, 2008 8
Software engineering
The beginning
1968/69 NATO conferences: introduction of the
term Software Engineering
Idea: software development is not an art, or a bag
of tricks
Build software like we build bridges
SE, Introduction, Hans van Vliet, 2008 9
Current status
a lot has been achieved
but
some of our bridges still collapse
SE, Introduction, Hans van Vliet, 2008 10
Tacoma Narrows bridge
SE, Introduction, Hans van Vliet, 2008 11
Same bridge, a while later
SE, Introduction, Hans van Vliet, 2008 12
Further references
Henry Petroski, Design Paradigms: Case Histories
of Error and Judgement in Engineering
A. Spector & D. Gifford, A Computer Science
Perspective of Bridge Design, Comm. Of the ACM
29, 4 (1986) p 267-283
SE, Introduction, Hans van Vliet, 2008 13
Relative distribution of software/hardware
costs
100
Hardware
Development
Percent of total cost
60
Software
20
Maintenance
1955 1970 1985
Year
SE, Introduction, Hans van Vliet, 2008 14
Point to ponder #1
Why does software maintenance cost so much?
SE, Introduction, Hans van Vliet, 2008 15
Definition (IEEE)
Software Engineering is the application
of a systematic, disciplined, quantifiable
approach to the development, operation,
and maintenance of software; that is,
the application of engineering to
software
SE, Introduction, Hans van Vliet, 2008 16
Central themes
SE is concerned with youre doing it
BIG programs together
complexity is an software must
issue effectively support
software evolves users
development must involves different
be efficient disciplines
SE is a balancing act
SE, Introduction, Hans van Vliet, 2008 17
Building software ~ Building bridges?
yes, and no
software is logical, rather than physical
progress is hard to see (speed progress)
software is not continuous
SE, Introduction, Hans van Vliet, 2008 18
Simple life cycle model
problem
requirements engineering
reqs specification
design
design
implementation
system
testing
working system
maintenance
SE, Introduction, Hans van Vliet, 2008 19
Point to ponder #2
Is this a good model
of how we go about?
of how we should go about?
SE, Introduction, Hans van Vliet, 2008 20
Requirements Engineering
yields a description of the desired system:
which functions
possible extensions
required documentation
performance requirements
includes a feasibility study
resulting document: requirements specification
SE, Introduction, Hans van Vliet, 2008 21
Design
earliest design decisions captured in software
architecture
decomposition into parts/components; what are
the functions of, and interfaces between, those
components?
emphasis on what rather than how
resulting document: specification
SE, Introduction, Hans van Vliet, 2008 22
Implementation
focus on individual components
goal: a working, flexible, robust, piece of
software
not a bag of tricks
present-day languages have a module and/or
class concept
SE, Introduction, Hans van Vliet, 2008 23
Testing
does the software do what it is supposed to do?
are we building the right system? (validation)
are we building the system right? (verification)
start testing activities in phase 1, on day 1
SE, Introduction, Hans van Vliet, 2008 24
Maintenance
correcting errors found after the software has
been delivered
adapting the software to changing requirements,
changing environments, ...
SE, Introduction, Hans van Vliet, 2008 25
Global distribution of effort
design 15% coding 20%
requirements
engineering 10%
specification 10%
testing 45%
SE, Introduction, Hans van Vliet, 2008 26
Global distribution of effort
rule of thumb: 40-20-40 distribution of effort
trend: enlarge requirements specification/design
slots; reduce test slot
beware: maintenance alone consumes 50-75% of
total effort
SE, Introduction, Hans van Vliet, 2008 27
Kinds of maintenance activities
corrective maintenance: correcting errors
adaptive maintenance: adapting to changes in the
environment (both hardware and software)
perfective maintenance: adapting to changing
user requirements
SE, Introduction, Hans van Vliet, 2008 28
Distribution of maintenance activities
corrective 21%
perfective 50%
adaptive 25%
preventive 4%
SE, Introduction, Hans van Vliet, 2008 29
Point to ponder #3
You are a tester, and the product you are testing
does not yet meet the testing requirements agreed
upon in writing. Your manager wants to ship the
product now, continue testing so that the next
release will meet the testing requirements. What
do you do?
Discuss the issue with your manager?
Talk to the managers boss?
Talk to the customer?
SE, Introduction, Hans van Vliet, 2008 30
Hammurabis Code
SE, Introduction, Hans van Vliet, 2008 31
Hammurabis Code (translation)
64: If a builder build a house for a man and do not
make its construction firm, and the house which
he has built collapse and cause the death of the
owner of the house, that builder shall be put to
death.
73: If it cause the death of a son of the owner of
the house, they shall put to death a son of that
builder.
SE, Introduction, Hans van Vliet, 2008 32
Software Engineering Ethics - Principles
Act consistently with Managers shall promote
the public interest an ethical approach
Act in a manner that is Advance the integrity
in the best interest of and reputation of the
the client and employer profession
Ensure that products Be fair to and
meet the highest supportive of
professional standards colleagues
possible Participate in lifelong
Maintain integrity in learning and promote
professional judgment an ethical approach
SE, Introduction, Hans van Vliet, 2008 33
Quo Vadis?
It takes at least 15-20 years for a technology to
become mature; this also holds for computer
science: UNIX, relational databases, structured
programming,
Software engineering has made tremendous
progression
There is no silver bullet, though
SE, Introduction, Hans van Vliet, 2008 34
Recent developments
Rise of agile methods
Shift from producing software to using software
Success of Open Source Software
Software development becomes more
heterogeneous
SE, Introduction, Hans van Vliet, 2008 35
The Agile Manifesto
Individuals and interactions over processes and
tools
Working software over comprehensive
documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
SE, Introduction, Hans van Vliet, 2008 36
Producing software Using software
Builders build pieces, integrators integrate them
Component-Based Development (CBSD)
Software Product Lines (SPL)
Commercial Off-The-Shelves (COTS)
Service Orientation (SOA)
SE, Introduction, Hans van Vliet, 2008 37
Open Source: crowdsourcing
1. Go to LEGO site
2. Use CAD tool to design your favorite castle
3. Generate bill of materials
4. Pieces are collected, packaged, and sent to you
5. Leave your model in LEGOs gallery
6. Most downloaded designs are prepackaged
No requirements engineers needed!
Gives rise to new business model
SE, Introduction, Hans van Vliet, 2008 38
Heterogeneity
Old days: software development department had
everything under control
Nowadays:
Teams scattered around the globe
Components acquired from others
Includes open source parts
Services found on the Web
SE, Introduction, Hans van Vliet, 2008 39
Point to ponder #4
Which of the following do you consider as Software
Engineering Principles?
Build with and for reuse
Define software artifacts rigorously
Establish a software process that provides flexibility
Manage quality as formally as possible
Minimize software components interaction
Produce software in a stepwise fashion
Change is inherent, so plan for it and manage it
Tradeoffs are inherent, so make them explicit and document
them
Uncertainty is unavoidable, so identify and manage it
SE, Introduction, Hans van Vliet, 2008 40
SUMMARY
software engineering is a balancing act, where
trade-offs are difficult
solutions are not right or wrong; at most they are
better or worse
most of maintenance is (inevitable) evolution
there are many life cycle models, and they are all
models
SE, Introduction, Hans van Vliet, 2008 41