LSCITS-engineering

LSCITS Engineering, York EngD Programme, 2010 Slide 1
LSCITS Engineering
Prof. Ian Sommerville
St Andrews University

Objectives
• To discuss why the traditional approach to
engineering is not adequate for building LSCITS
• To introduce the notion of LSCITS engineering and to
introduce LSCITS engineering challenges
• To suggest a research agenda for LSCITS
engineering

What is an LSCITS?
• The key difference between an LSCITS and other
classes of large system is that there are significant
‘unknowns’ in the environments in which LSCITS is
procured, developed and operated.
• An LSCITS is an LSITS (or a collection of LSITSs)
where unknown, unstable and uncontrollable factors
in the systems procurement, development and
operational environment affect the design and use of
the system
• LSCITS have a close and entangled relationships
with the socio-technical systems that rely on these
LSCITS

An LSCITS model
S1
S3
S4
S5
S6
S7
S2
STS 1
STS 2

The basis of engineering
A discussion of the fundamental assumption that is a
foundation for engineering and systems development

Reductionism
• Reductionism
– “an approach to understanding the nature of complex things
by reducing them to the interactions of their parts, or to
simpler or more fundamental things”.
• Reductionism underpins most engineering, including
software engineering
• We see reductionism in notions such as
• Contractor/sub-contractor relationships
• Top-down design

Reductionist assumptions
• Control
– Reductionist approaches assume that we have control over the
organisation of the system. It is then possible to decompose the
system into parts that can themselves be engineered using
reductionist approaches
• Understandable relationships
– The relationships between the parts are visible and understandable
• A rational world
– Reductionist approaches assume that rationality will be the principal
influence in decision making
• Definable problems
– Reductionist approaches assume that the problem can be defined
and the system boundaries established

Software engineering
• Developments in software engineering have largely adopted a
reductionist perspective:
– Design methodologies
– Formal methods
– Agile approaches
– Software architecture
– Model-driven engineering
• Reductionist approaches to software engineering have been
successful in allowing us to construct larger software systems
• More effective reductionist approaches allow us to deal with
increasingly complicated systems.

Problems with reductionism
• Scale
• When things get too big, then reductionist approaches
become intellectually unmanageable because of the
complexity of the interactions between the parts of the whole
• Environment
• The relationships between a system and its environment are
often uncontrollable
• People
• Who refuse to behave in a rational and deterministic way

Engineering project failures
• Engineering projects ‘fail’ (go over schedule and
budget) when reductionist assumptions break down
• Edinburgh tramways project
– Environment problems. There are no maps of existing utilities
and there have been complex problems of moving pipes and
cabling to accommodate the tram system
– There has been considerable political wrangling between the
local government and the national government
• Software project failures
– Relatively common because, even for LSITS, reductionist
assumptions are dubious

Complex and complicated
systems
• Reductionist approaches are intended to help deal
with complicated systems i.e. systems where the
relationships between elements are largely static and
which can (in principle) be understood and controlled
• However, LSCITS are complex systems, with
dynamic relationships between elements. It is is
impossible to acquire and maintain a complete
understanding of the system and where elements are
independently controlled and often have
undocumented side-effects

LSCITS engineering
Reductionism + Reality

LSCITS development
Software capabilities
S1
S2
S3
S4
LSCITS
Systems contribute
capabilities
Used to construct
Systems Development
Creates
new
???
???

Continuous development
• It is rare (perhaps unknown) for an LSCITS to be
developed from ‘scratch’
• Rather, an LSCITS emerges from an assembly of
existing technical and socio-technical systems that
are supplemented by the development of new
software to help achieve a broad set of goals
• LSCITS engineering is a continual process of
procurement, development, deployment, operation
and de-commissioning

Brownfield development
• LSCITS are rarely, if ever, developed from scratch
• It is often the case that an LSCITS emerges after
experience with a range of individual systems
• By the time we recognise the need for an LSCITS, we
have already accumulated a range of constraints:
– Legacy systems
– Technologies
– Socio-technical systems
– Laws and regulations

Alternatives to reductionism
• Bricolage
– Systems are developed opportunistically by integrating
available systems and components and by using whatever
integration mechanisms work at the time
– Mashups, where different web services are combined
opportunistically, are examples of bricolage
• Problems with fit to socio-technical world, security,
dependability, maintainability

Alternatives to reductionism
• Emergence
– Systems are developed using an evolutionary ‘survival of the
fittest’ approach based on genetic algorithms, etc.
– The argument is made that this is what underlies the
development of the web
• Problems
– Uncontrollable. You cannot be sure that you get the system
that you need or that the system will not have undesirable
properties
– Visibility. It is hard to demonstrate compliance, safety, etc.
– Scale. Notwithstanding the example of the web, there is no
evidence that current approaches based on emergence scale
to large systems

Has reductionism had its day?
• At the moment, reductionism is the only tool that we
have for the specification, design and construction of
LSCITS
• The problem is not in reductionism in itself, but in
believing that it is all that is required to engineering
complex systems
• We need to move to a situation where we use
reductionism as far as possible but recognise that we
need to temper this with a dose of reality

Better software engineering?
• LSCITS engineering problems cannot be solved by
– improved software processes, process maturity, quality
management etc.
– better tools and technology
– more rigorous methods of development
– Better project management
• These can all contribute and are worth doing but
break down in the face of large-scale uncertainty
• A key requirement for LSCITS engineering is the
ability to represent, model and demanage both scale
and uncertainty

LSCITS Engineering
• LSCITS Engineering (LSCITS-E) is the process of creating,
evolving and managing LSCITSs.
• Not just a technical discipline – needs involvement of people
with a wide range of expertise (social science, psychology,
engineering, management, etc.)
• We need new systems and software engineering approaches
(e.g. designing for failure) that take into account the inherent
complexities of LSCITS and the need to cope with uncertainty
• LSCITS-E will incorporate current software engineering
activities(notably requirements engineering and system
architecture), you should bear in mind that current methods are
what we’ve got rather than what we need

The realities of LSCITS-E
• Social and technical are inseparable
– Focus on the social and the technical together rather than consider
technical issues in isolation
• Perfection is unattainable
– Adopt a pragmatic acceptance of the world as it is, populated by
imperfect people
• You can’t win
– Accept that systems will always be a compromise, with multiple,
often conflicting, notions of what is meant by ‘success’ and where
the system boundaries lie
• Things will go wrong
– Adopt a view of dependability where partial failure is normal and
tolerable

LSCITS-E Challenges
Problems that we have to address to make LSCITS
engineering a reality

LSCITS – E challenges
• Managing scale
• Dealing with uncertainty
• Thinking and reasoning about LSCITS
• Making systems work together effectively
• Standards for LSCITS

Scale causes problems
• No centralised or unified understanding of the ‘system as a
whole’
• The ability to understand an individual constituent of the system
and its relationships decreases as the number of constituents
increases
• Problems of management and governance are exacerbated and
increase as new systems are added and the overall LCSITS
increases in size
• The (socio-technical) effects of changes to constituents of the
system become impossible to predict
• Size makes it more difficult to reach consensus about system
requirements

Coping with uncertainty
• Uncertainty is a universal characteristics of LSCITS and the
principal cause of system problems is unpredicted events and
behaviour in both the technical and socio-technical systems
– Aleatory uncertainty
• Uncertainty that relates to the fact that the world is uncertain.
– Epistemic uncertainty
• Uncertainty that arises because our knowledge of the world is incomplete
• Coping with uncertainty is about designing for flexibility and
utilising the abilities of people to deal with unseen problems
• Will be discussed in more detail in the following lecture

LSCITS abstractions
• Our existing abstractions (functions, objects, component, etc.)
that we use in defining software systems are based on a
reductionist view of the world
• We need new abstractions which are more effective at
representing large-scale systems and accommodating
uncertainty to allow us to represent and reason about LSCITS
• Examples of possible abstractions
– Responsibilities
• A duty to achieve, maintain or avoid some state, subject to constraints.
– Capabilities
• The ability to completely or partially discharge a responsibility

Interoperability and integration
• The constituents of LSCITS have to interoperate
(ensuring that constituent systems that can operate
smoothly together) and integrate (ensuring that
constituent systems can exchange information in a
controlled way)
– Interoperability is about control; integration is about data
– Integration is not just about physical data exchange but also
must take into account business rules and data regulations
• To achieve effective interoperation and integration,
we need to pay attention to socio-technical issues,
system requirements and architecture

Standards
• General interoperability/integration can only be
achieved if standards are widely adopted and
systems are built that implement these standards
• Currently, the standards that have been accepted
and that are widely adopted are low-level standards
– Standards for data exchange
– Standards for service syntax
• We need standards based on semantics if true
interoperability is to be achieved

Research agenda for LSCITS
engineering
• Requirements engineering for LSCITS
– LSCITS means uncertainty and we need better tools and
techniques for understanding where uncertainties exist and
how the system should cope with these uncertainties.
– Better techniques are required to understand the
requirements from the socio-technical environment in which
the LSCITS is used
• Managing failure
– Moving from a world where failure is something to be avoided
to a world where failure is normal and simply has to be lived
with
– Ensuring the ‘small failures’ do not cascade to ‘large failures’

Research agenda for LSCITS
engineering
• LSCITS architecture
– Abstractions for representing LSCITS architecture
– Architectural styles and patterns for LSCITS
– Architecture trade-offs and system consequences
• Dynamic systems
– Integration mechanisms that allow systems to evolve rapidly
in response to changing demands and capabilities,
governance, standards and regulation
– Methods of understanding and managing these systems

Key points
• Reductionism is the basis of engineering, including
software engineering. However reductionism cannot
cope effectively with complexity
• Better reductionist approaches are not adequate, in
themselves, for building LSCITS but we cannot
simply discard our current approaches
• Key challenges for LSCITS engineering are
managing scale, developing new abstractions to
model LSCITS, integration and interoperation and
challenges

LSCITS-engineering

More Related Content

What's hot

Similar to LSCITS-engineering

More from Ian Sommerville

Recently uploaded

LSCITS-engineering