• Like
  • Save
Rethinking Software Engineering
Upcoming SlideShare
Loading in...5

Rethinking Software Engineering






Total Views
Views on SlideShare
Embed Views



6 Embeds 273

http://www.techgig.com 254
http://a0.twimg.com 7
http://paper.li 6
http://www.techgig.timesjobs.com 4
http://us-w1.rockmelt.com 1
http://techgig.in 1



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.

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

    Rethinking Software Engineering Rethinking Software Engineering Presentation Transcript

    • Rethinking Software Engineering
      Ian Sommerville
    • The Flash Crash
    • Large-scale complex IT systems
    • Complex software systems
      Multi-purpose. Organisational systems that support different functions within an organisation
      System of systems. Usually distributed and normally constructed by integrating existing systems/components/services
      Unlimited. Not subject to limitations derived from the laws of physics (so, no natural constraints on their size)
      Data intensive. System data orders of magnitude larger than code; long-lifetime data
      Dynamic. Changing quickly in response to changes in the business environment
    • Coalitions of systems
      Operational independence
      Managerial independence
      Multiple stakeholder viewpoints
      Evolutionary development
      Emergent behaviour
      Geographic distribution
    • Enterprise information systems
      Multi-purpose. Designed to cross-cut the organisation
      System of systems. Integrate several systems, including legacy systems
      Unlimited.Organisational code bases increasing in size
      Data intensive. Database centric systems
      Dynamic. Rapid business change
    • Complex system realities
      There is no definitive specification of what the system should ‘do’ and it is practically impossible to create such a specification
      The complexity of the system is such that it is not ‘understandable’ as a whole
      It is likely that, at all times, some parts of the system will not be fully operational
      Actors responsible for different parts of the system are likely to have conflicting goals
    • There are fundamental reasons why current approaches to software engineering cannot scale to LSCITS engineering
    • Reductionism and software engineering
    • 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”.
      Its focus is on the parts of a system, not the relationships between those parts
      • Reductionism underpins most engineering, including software engineering
    • Software engineering
      Developments in software engineering have largely adopted a reductionist perspective:
      Design methodologies
      Formal methods
      Agile approaches
      Software architecture
      Model-driven engineering
      Process improvement
      Reductionist approaches to software engineering have been successful in allowing us to construct larger software systems
    • Complex and complicated systems
      Reductionist approaches are intended to help deal with complicated systems.
      We are now building complex systems where is is impossible to acquire and maintain a complete understanding of the system. Elements are independently controlled and often have undocumented side-effects.
    • Reductionist assumptions
      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
      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
    • LSCITS reality
      Reductionist assumptions
      Owners of a system control its development
      Decisions made rationally, driven by technical criteria
      Definable problem and clear system boundaries
      Wicked problem and constantly renegotiated system boundaries
      Decisions driven by political motives
      No single owner or controller
      LSCITS reality
    • Reductionism and LSCITS
      Reductionism works (to some extent) for systems that we can control – such as software products
      But, for LSCITS, reductionist assumptions are no longer true
      Incremental improvements in software engineering are not enough to help us build complex systems of systems
    • Research challenges
      Reductionism is essentially based around the notion of a closed system
      The focus in software engineering has been on ‘the software’
      Models and representations
      Verification and validation
      Methods and techniques
      But LSCITS engineering is an open system problem – not just the software but the environments that affect that software’s acceptability and operation
    • Short and long-term research
      Long-term research
      We need new inter-disciplinary approaches to LSCITS engineering which will involve developing completely new engineering paradigms that are not based on reductionism
      But – how do we test and validate these approaches?
      Enlightened 20+ year funding is needed to develop these approaches
      Shorter-term research
      We have to address some key problems and issues that limit the development of LSCITS as, for sure, these LSCITS are being and will be constructed
    • Broadening the perspective
    • Systems in operation
      • How can we model and simulate the interactions between independent systems?
      • How can we monitor coalitions of systems and what are the warning signs of problems?
      • How can systems be designed to recover from failure?
      • To what extent can coalitions of systems be self-managing?
      • How should shared knowledge in a coalition of systems be represented?
    • The socio-political environment
      How can systems be designed to recover from failure?
      How can we integrate socio-technical factors into systems and software engineering methods?
      How can we manage complex, dynamically changing system configurations?
      How can we support the agile engineering of coalitions of systems?
      How should coalitions of systems be regulated and certified?
      How can we do ‘probabilistic verification’ of systems?
    • LSCITS EngD
      Students have to work on an industrial problem and spend a significant period of time working in industry on that problem.
      Students take a range of courses that focus on complexity and systems engineering such as systems engineering for LSCITS, socio-technical systems, high-integrity systems engineering, empirical methods and technology innovation.
      Students don’t have to produce a conventional ‘thesis’ – a book on a single topic but can produce a portfolio of work around their selected area.
    • LSCITS Masters course?
    • Conclusion
      Current software engineering methods and techniques are effective in building closed systems (such as software products)
      But they cannot cope with LSCITS – where we need to consider not just the software but its development and operational environment
      Software engineering has to change to embrace the wider reality of LSCITS engineering
      Failure to do so will put our society at risk as complex software becomes embedded in all aspects of our lives
    • Finding out more