Rethinking Software Engineering
Download as PPTX, PDF3 likes725 views
Ian Sommerville argues that current approaches to software engineering are insufficient for engineering large-scale complex IT systems (LSCITS). Reductionism, which underpins most engineering approaches, breaks systems down into parts but does not account for relationships between parts. However, LSCITS are open systems with no single owner and undefined problems. New interdisciplinary paradigms beyond reductionism are needed to engineer LSCITS while considering the socio-political and operational environments. Short-term research should address verification and managing dynamically changing system configurations, while long-term funding is required to develop new non-reductionist engineering approaches.
Rethinking Software Engineering
- 1. Rethinking Software EngineeringIan Sommerville
- 4. Large-scale complex IT systems
- 5. Complex software systemsMulti-purpose. Organisational systems that support different functions within an organisationSystem of systems. Usually distributed and normally constructed by integrating existing systems/components/servicesUnlimited. 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 dataDynamic. Changing quickly in response to changes in the business environment
- 6. Coalitions of systemsOperational independence Managerial independence Multiple stakeholder viewpointsEvolutionary developmentEmergent behaviourGeographic distribution
- 7. Enterprise information systemsMulti-purpose. Designed to cross-cut the organisationSystem of systems. Integrate several systems, including legacy systemsUnlimited.Organisational code bases increasing in sizeData intensive. Database centric systemsDynamic. Rapid business change
- 8. Complex system realitiesThere is no definitive specification of what the system should ‘do’ and it is practically impossible to create such a specificationThe complexity of the system is such that it is not ‘understandable’ as a wholeIt is likely that, at all times, some parts of the system will not be fully operationalActors 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. ReductionismReductionism “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 partsReductionism underpins most engineering, including software engineeringSoftware engineeringDevelopments in software engineering have largely adopted a reductionist perspective:Design methodologiesFormal methodsAgile approachesSoftware architectureModel-driven engineeringProcess improvementReductionist approaches to software engineering have been successful in allowing us to construct larger software systems
- 12. Complex and complicated systemsReductionist 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 assumptionsControlReductionist 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 approachesA rational worldReductionist approaches assume that rationality will be the principal influence in decision makingDefinable problemsReductionist approaches assume that the problem can be defined and the system boundaries established
- 14. LSCITS realityReductionist assumptionsOwners of a system control its developmentDecisions made rationally, driven by technical criteriaDefinable problem and clear system boundariesRationalityProblemdefinitionControlWicked problem and constantly renegotiated system boundariesDecisions driven by political motivesNo single owner or controllerLSCITS reality
- 15. Reductionism and LSCITSReductionism works (to some extent) for systems that we can control – such as software productsBut, for LSCITS, reductionist assumptions are no longer trueIncremental improvements in software engineering are not enough to help us build complex systems of systems
- 16. Research challengesReductionism is essentially based around the notion of a closed systemThe focus in software engineering has been on ‘the software’Models and representationsVerification and validationMethods and techniquesBut 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 researchLong-term researchWe need new inter-disciplinary approaches to LSCITS engineering which will involve developing completely new engineering paradigms that are not based on reductionismBut – how do we test and validate these approaches?Enlightened 20+ year funding is needed to develop these approachesShorter-term researchWe 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 perspectiveSOCIO-POLITICAL ENVIRONMENTLSCITSENGINEERINGSOFTWARE SYSTEMSOPERATIONAL ENVIRONMENT
- 19. Systems in operationHow 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 environmentHow 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 EngDStudents 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.
- 26. ConclusionCurrent 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 environmentSoftware engineering has to change to embrace the wider reality of LSCITS engineeringFailure to do so will put our society at risk as complex software becomes embedded in all aspects of our lives