1

SOFTWARE ENGINEERING

Challenges for the 21st Century

Ian Sommerville
Lancaster University
The 1960s

n 1961-1963
u New hardware
technology
n 1963 -1968
u The emerging
software crisis
n 1968, 1970
u The birth of
software
engineering
3

Responses to the crisis

n The most important goals
were to get control of the
software development
process and to improve
software performance and
software reliability
n This led to
u new approaches to the
management of software
engineering
u new techniques of software
development
4
The waterfall model!

The 1970s

n Structured programming
n Types and type checking
n System modelling
n Testing techniques
n Inspections and reviews
n Configuration management

6
Is there still a software crisis?

n Software is off the danger

list.
n We can successfully build
large, reliable systems
n Software engineering has
worked!

New business challenges

n Responsiveness
u Businesses must
continually respond to
their changing
environment
n Openness
u Centralised IT is no longer
viable -
n Global competition
u Competitive pressures are
changing the nature of
software
8
Rapid software development

n Time to delivery (not cost or

even quality) is the principal
driver now for many systems
n We need new techniques to
radically reduce the
development time for large
systems
n Component-based
development, domain-
specific systems, end-user
development...

Heterogeneous systems

n Systems are becoming

increasing heterogeneous
and software has to be able
to adapt simultaneously to
a range of execution
platforms
n Platform-independent
languages, extensible
markup languages,
component execution
frameworks
10
Modern software qualities

n Adaptiveness
u Software must be
adaptive to respond to
rapid business change
n Resilience
u Software must be resilient
to cope with change
n Adequacy
u Software must be ‘good
enough’ for its purpose

11

Technical challenges

n New techniques of
software development
n New types of
architecture for software
systems
n New methods of
evaluating software
technology innovation

12
Measurement

n Underpinning all
successful engineering
innovations is the
notion of measurement
- you can objectively
assess if a tool or
technique is effective

13

William Thomson
(Lord Kelvin)
1824 -1907
The ultimate empiricist?

n When you can measure what you are speaking

about and express it in numbers you know
something about it
n If you cannot measure it, you cannot improve
it
n Heavier-than-air flying machines are
impossible!

15

Software measurement

n Measurement of products
or systems is absolutely
fundamental to the
engineering process.
n I am convinced that
measurement as practised
in other engineering
disciplines is IMPOSSIBLE
for software engineering

16
Software engineering is different!

n Kelvin was referring to events in

and attributes of the physical
world
n BUT this doesn’t apply to
software.
u There is NO software
engineering mathematics
u There are no universal
relationships between what
we can measure and software
product quality

17

System categories

n Natural systems
u People, rainfall, bodies in
motion
n Designed physical systems
u Hammers, engines, rockets
n Designed abstract systems
u Mathematics, systems theory,
software
n Human-activity systems
u Software development, research

18
Human-activity systems

n Are abstractions of a structured

set of activities that have some
purpose
n Involve different stakeholders and
are therefore subject to different
interpretations
n Are situated within other human-
activity systems (such as an
organisation) and are intimately
and inextricably linked to these
systems

19

On-line hospital appointments

n Patients
u Convenient hospital
appointments
n Administrators
u Reduced administration
costs
n Doctors
u Improved patient care

20
Designed physical systems

n Physical systems are underpinned by

e =mc2 well-understood mathematical
foundations.
n Mathematical models can be used to
V = IR predict the behaviour and attributes
of a physical system
n Measurement can be used to
compare them and to validate the
mathematical models.
n Measurements can be understood in
terms of universal physical concepts

21

Natural system

Constrains
Designs
Traditional Designed physical
Engineering system

Supports

Human-activity
system
Traditional measurement

n Relates the designed

physical system to
u Natural systems
u Other designed physical
systems using metrics
derived from natural
systems
n Measurement with respect
to human-activity systems
is limited or is indirect.

23

Engineering innovation assessment

n Attributes to assess
effectiveness of new
techniques are drawn from
natural systems and are
universally agreed
u Higher performance
u Lower weight / size
n These can be related to the
requirements of the human
activity system

24
Software engineering

n Software systems do not

reflect and are not
constrained by the physical
world.
n They are designed, abstract
systems that support
human-activity systems
n There is no technical
solution to software
complexity

25

Designs
Software Designed abstract
Engineering system

Supports

Human-activity
system
Software measurement

n Software measurement can

only relate software
systems to
u other software systems
u human-activity systems
n As human-activity systems
may always be considered
from multiple perspectives
these cannot be subject to
unambiguous analysis

27

Consequences

n Laboratory experiments can

only demonstrate the
uselessness rather than the
usefulness of software
engineering techniques
n The usability of techniques
and tools is fundamental and
usability issues are liable to
mask any other factors in a
system evaluation

28
Laboratory experiments

n Small-scale systems can be

evaluated with respect to
natural systems. Because they
are related to the same natural
systems, predictions can be
made
n Therefore, an R & D process
that starts with research, goes
to laboratory prototype then
industrial prototype then
production makes sense.
29

Usability
n The fundamental concepts
and organisation of a
method and tool profoundly
affect its usability
n If these are inherently alien
to the final end-users then
any assessment of the
functionality of the tool is
meaningless

30
Software experimentation

n We can only meaningfully

assess software methods
and tools in a real setting.
Both the problems and the
organisational context are
significant.

31

Research challenges

n Move the focus of software

engineering research to
consider the system in an
organisational context
u Methods and tools for the
situated evaluation of
software
u Make them usable by the
people developing and using
the software
u Make them cost-effective from
an organisational perspective
32
And finally!

n Let’s leave the last

word to Lord Kelvin

n Large increases in cost

with questionable
increases in
performance can only
be tolerated in race
horses and women!

33

34