Your SlideShare is downloading. ×
Rethinking Software Engineering
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rethinking Software Engineering


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Rethinking Software Engineering
    Ian Sommerville
  • 2. The Flash Crash
  • 3.
  • 4. Large-scale complex IT systems
  • 5. 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
  • 6. Coalitions of systems
    Operational independence
    Managerial independence
    Multiple stakeholder viewpoints
    Evolutionary development
    Emergent behaviour
    Geographic distribution
  • 7. 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
  • 8. 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
  • 9. There are fundamental reasons why current approaches to software engineering cannot scale to LSCITS engineering
  • 10. Reductionism and software engineering
  • 11. 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
  • 12. 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.
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. Broadening the perspective
  • 19. Systems in operation
    • How can we model and simulate the interactions between independent systems?
    • 20. How can we monitor coalitions of systems and what are the warning signs of problems?
    • 21. How can systems be designed to recover from failure?
    • 22. To what extent can coalitions of systems be self-managing?
    • 23. 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?
  • 24. 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.
  • 25. LSCITS Masters course?
  • 26. 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
  • 27. Finding out more