• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
L6 LSCITS Engineering
 

L6 LSCITS Engineering

on

  • 610 views

Thoughts on the issues that affect LSCITS engineering - in truth, we really have no idea how to do this

Thoughts on the issues that affect LSCITS engineering - in truth, we really have no idea how to do this

Statistics

Views

Total Views
610
Views on SlideShare
601
Embed Views
9

Actions

Likes
0
Downloads
11
Comments
0

2 Embeds 9

http://alef.fiit.stuba.sk 6
http://www.sabsoli.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    L6 LSCITS Engineering L6 LSCITS Engineering Presentation Transcript

    • 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
      STS 1
      STS 2
      S2
      S5
      S7
      S4
      S1
      S3
      S6
    • 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 there are many interactions between components but which can (in principle) be understood and controlled
      However, LSCITS are complex systems where 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
      Systems contribute
      capabilities
      Software capabilities
      S1
      Creates
      new
      S2
      Used to construct
      S3
      Systems Development
      ???
      S4
      LSCITS
      ???
    • 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 never 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