1. Rethinking Software Engineering Ian Sommerville

2. The Flash Crash

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

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 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 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 Rationality Problemdefinition Control 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 SOCIO-POLITICAL ENVIRONMENT LSCITS ENGINEERING SOFTWARE SYSTEMS OPERATIONAL ENVIRONMENT

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?

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 http://arxiv.org/abs/1109.3444