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

1. LSCITS Engineering Prof. Ian Sommerville St Andrews University

2. 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

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

7. We see reductionism in notions such as

8. Contractor/sub-contractor relationships

10. 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.

12. When things get too big, then reductionist approaches become intellectually unmanageable because of the complexity of the interactions between the parts of the whole

13. Environment

14. The relationships between a system and its environment are often uncontrollable

15. People

17. 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

18. LSCITS engineering Reductionism + Reality

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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

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

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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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’

36. 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

37. 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