The document discusses the integration of socio-technical systems (STS) and large-scale complex IT systems (LSCITS), emphasizing the importance of considering socio-technical factors in system design. It highlights characteristics of STS, including emergent properties, non-determinism, and the need for flexibility in operational processes. The document further examines the challenges in LSCITS engineering, such as requirements definition, system design, and the interplay between technical and organizational elements.

1. LSCITS and Socio-technical SystemsProf Ian Sommerville

2. ObjectivesTo introduce the notion of a socio-technical system and to discuss the relationships between LSCITSs and STSs.To explain why socio-technical considerations should influence the design of an LSCITSTo introduce the notion of LSCITS engineering as a systems engineering process.

3. Socio-technical systemsOrganisational systems with automated and manual processes and component that evolve to meet organisational goals or requirements

4. Socio-technical systemsSocio-technical systems include IT systems and the social and organisational environment in which these systems are usedOperators – the people who use the systemProcedures and Processes – ways of working that use the IT systemPolicies – rules and regulations that govern work and the way that it is doneStandards – definitions of how work should be done across the organisationCulture – the ways in which work is done in a local, professional and national setting

5. Software-intensive systemSocial and political environmentLaws, regulations, custom & practiceSystem usersBusinessprocessesOrganisational policies and cultureSocio-technical systemsOrganisational strategies and goals

6. Socio-technical system characteristicsThey exhibit emergent propertiesSome of the properties of the system emerge after it has gone into use and cannot be predicted in advanceThis is true of all systems but is a particular characteristic of STS because of the complexity of the interactions between parts of the systemThey are non-deterministicThey do not always produce the same output when presented with the same input (or input sequence) because the systems’s behaviour is partially dependent on human operators, organizational priorities, etc.They are influenced by the organisations culture, rules and objectivesSTS are inextricably bound up with the organisation using these sysyems, how it thinks of itself and how it works

7. Emergent propertiesProperties of the system as a whole rather than properties that can be derived from the properties of components of a systemEmergent properties are a consequence of the relationships between system components and between technical systems and the socio-technical system in which they are usedThey can therefore only be assessed and measured once the components have been integrated into a systemEmergent properties often have unexpected consequencesHigher rather than lower costsMore rather than less manual intervention

8. Types of emergent propertyFunctional properties These are the designer’s intention and appear when all the parts of a system have been integrated. A burglar alarm system has the property of detecting intruders in a building.Non-functional emergent propertiesThese relate to the behaviour of the system in its operational environment.Examples are reliability, performance, safety, and security.

9. Organisational emergent propertiesThese relate to the relationships between technical systems and the socio-technical system in which they are embedded or to the relationships between a socio-technical system and other socio-technical systems in an organisationAn accounting system that provides better information on accounts to budget holders may lead to increases in expenditure because they now have information about under-spending on a budgetA (socio-technical) system that is intended to provide the public with information about death rates in hospitals leads to increases in the number of patients who are discharged early and die at home

10. Non-determinismNon-determinism (in a systems context) means that the response of a system to a stimulus will not always be consistentSTS are non-deterministic because:People are not inter-changeable. One system user will behave in a different way from another. They react differently because of personal circumstances, workload, etc.People react to changes in the environment in which the system is used. The organisational and operational environments constantly change and affect the use of the system and its responses.

11. Coping with the unexpectedTechnical systems are rigid and are usually unable to cope with circumstances that have not been envisaged by their designersThe non-determinism in STS is (usually) a positive characteristic as it allows the system to cope with unexpected changeIt allows graceful degradation of service in times of increased workloadPeople can prioritise tasks according to their perceived importanceThe processes in the system can be dynamically adapted to cope with organisational or external changes

12. LSCITS and Socio-technical systemsThe relationships between LSCITS and STS

13. STS and LSCITSI find it helpful to distinguish between an LSCITS and a STS, with the important distinction being that LSCITS are designed and socio-technical systems evolve.However, not all STS include LSCITS – STS do not have to be large-scale systems. However, all LSCITS are tightly embedded in STS.Socio-technical issues have a profound effect on the dependability, efficiency and effectiveness of the embedded LSCITSsThere is an increasing conviction that focusing on socio-technical issues in complex systems and understanding how to use these constructively in system design (LSCITS engineering) will provide a better return in terms of system improvement than investments in new technology

14. Organisations/people/systemsLSCITS are organisational systems intended to help deliver some organisational or business goal.If you do not understand the organisational environment where a system is used, the LSCITS is less likely to meet the real needs of the business and its users.

15. Value from socio-technical analysisEffectivenessDeployed systems are more effective in supporting business processesIn many cases, value from new systems is not realised because these are not used at all or part of their functionality is not exploitedDependabilityReduced probability of usage errorsMore effective error recoveryUser satisfactionBetter user acceptance of new systemsFaster ‘time to value’Shorter assimiliation period for new systems. Fewer mismatches between system and work

16. Issues and questionsProcess changesDoes the system require changes to the work processes in the environment? Job changesDoes the system de-skill the users in an environment or cause them to change the way they work? Organisational changesDoes the system change the political power structure in an organisation?

17. LSCITS processesOrganisational EnvironmentLSCITS

18. Organisational processesThe processes of systems engineering overlap and interact with organisational procurement processes.Operational processes are the processes involved in using the system for its intended purpose. For new systems, these have to be defined as part of the system design.Operational processes should be designed to be flexible and should not force operations to be done in a particular way. It is important that human operators can use their initiative if problems arise.Operational processes not covered in these lectures but will be discussed in forthcoming socio-technical systems module.

19. ProcurementAcquiring a system for an organization to meet some perceived needSome system specification and architectural design is usually necessary before procurementYou need a specification to let a contract for system developmentThe specification may allow you to buy a commercial off-the-shelf (COTS) system. Almost always cheaper than developing a system from scratchLSCITS usually consist of a mix of off the shelf and specially designed systems. The procurement processes for these different types of system are usually different.

20. The system procurement process

21. Procurement issuesThe choice of what system to buy is a socio-technical rather than simply a technical decisionCentralisation vs AutonomyComplianceResponse to external circumstancesOrganisational authority structureRequirements may have to be modified to match the capabilities of off-the-shelf components.There is usually a contract negotiation period to agree changes after the contractor to build a system has been selected. During this process, significant changes to the requirements may be negotiated

22. LSCITS engineeringA development process for LSCITS

23. LSCITS engineeringSpecifying, designing, implementing, validating, deploying and maintaining large-scale complex IT systems.Concerned with the services provided by the system, constraints on its construction and operation and the ways in which it is used.LSCITS engineering is a systems rather than a software engineering processLSCITS engineering is particularly concerned with the early stages of the systems engineering process – requirements engineering and architectural designProblems and issues in LSCITS engineering discussed in Lecture 6

24. The system engineering processUsually follows a ‘waterfall’ model because of the need for parallel development of different parts of the systemLittle scope for iteration between phases because hardware changes are very expensive. Software may have to compensate for hardware problems.Inevitably involves engineers from different disciplines who must work togetherMuch scope for misunderstanding here. Different disciplines use a different vocabulary and much negotiation is required. Engineers may have personal agendas to fulfil.

25. The systems engineering process

26. System requirements definitionFocuses on ‘requirements in the large’ rather than detailed ‘requirements in the small’Three types of requirement defined at this stageAbstract functional requirements. System functions are defined in an abstract way;System properties. Non-functional requirements for the system in general are defined;Undesirable characteristics. Unacceptable system behaviour is specified.Should also define overall organisational objectives for the system.

27. System objectivesShould define why a system is being procured for a particular environment.Functional objectivesTo provide a unified student administrative system that maintains all student information from initial application to graduationOrganisational objectivesTo introduce common processes across the organisation for student administrationTo improve applicants’ and students’ perception of the universityTo reduce central administration costs

28. System requirements problemsComplex systems are usually developed to address wicked problemsProblems that are not fully understood;Changing as the system is being specified.Must anticipate hardware/communications developments over the lifetime of the system.Hard to define non-functional requirements (particularly) without knowing the component structure of the system.Organisational and political issues affect the requirementsThere is a continuing tension between control by the organisation and support of operational processes

29. The system design process

30. The system design processPartition requirementsOrganise requirements into related groups. Identify sub-systemsIdentify a set of sub-systems which collectively can meet the system requirements.Assign requirements to sub-systemsCauses particular problems when COTS are integrated.Specify sub-system functionality.Define sub-system interfacesCritical activity for parallel sub-system development.

31. System design problemsRequirements partitioning to hardware, software and human components may involve a lot of negotiation. Difficult design problems are often assumed to be readily solved using software.Hardware platforms may be inappropriate for software requirements so software must compensate for this.

32. Requirements and designRequirements engineering and system design are inextricably linked.Constraints posed by the system’s environment and other systems limit design choices so the actual design to be used may be a requirement.Initial design may be necessary to structure the requirements.As you do design, you learn more about the requirements.

33. Spiral model of requirements/design

34. Key pointsLSCITS are tightly integrated with socio-technical systemsSocio-technical systems are systems whose boundaries include the business processes that these systems are intended to support and the system operators. They are influenced by a wide range of regulatory, cultural and organisational factors.To develop LSCITS, we should extend traditional systems engineering with socio-technical analyses to consider how organisational factors should influence the overall STS designRequirements engineering and architectural design are key phases in the LSCITS engineering process