©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Systems engineering 2

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 2 System modelling l An architectural model presents an abstract view of the sub-systems making up a system l May include major information flows between sub-systems l Usually presented as a block diagram l May identify different types of functional component in the model

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 3 Burglar alarm system

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 4 Sub-system description

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 5 ATC system architecture

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 6 Sub-system development l Typically parallel projects developing the hardware, software and communications. l May involve some COTS (Commercial Off-the-Shelf) systems procurement. l Lack of communication across implementation teams. l Bureaucratic and slow mechanism for proposing system changes means that the development schedule may be extended because of the need for rework.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 7 l The process of putting hardware, software and people together to make a system. l Should be tackled incrementally so that sub- systems are integrated one at a time. l Interface problems between sub-systems are usually found at this stage. l May be problems with uncoordinated deliveries of system components. System integration

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 8 l After completion, the system has to be installed in the customer’s environment Environmental assumptions may be incorrect; May be human resistance to the introduction of a new system; System may have to coexist with alternative systems for some time; May be physical installation problems (e.g. cabling problems); Operator training has to be identified. System installation

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 9 System evolution l Large systems have a long lifetime. They must evolve to meet changing requirements. l Evolution is inherently costly Changes must be analysed from a technical and business perspective; Sub-systems interact so unanticipated problems can arise; There is rarely a rationale for original design decisions; System structure is corrupted as changes are made to it. l Existing systems which must be maintained are sometimes called legacy systems.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 10 System decommissioning l Taking the system out of service after its useful lifetime. l May require removal of materials (e.g. dangerous chemicals) which pollute the environment Should be planned for in the system design by encapsulation. l May require data to be restructured and converted to be used in some other system.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 11 Organisations/people/systems l Socio-technical systems are organisational systems intended to help deliver some organisational or business goal. l If you do not understand the organisational environment where a system is used, the system is less likely to meet the real needs of the business and its users.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 12 Human and organisational factors l Process changes Does the system require changes to the work processes in the environment? l Job changes Does the system de-skill the users in an environment or cause them to change the way they work? l Organisational changes Does the system change the political power structure in an organisation?

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 13 Organisational processes l The processes of systems engineering overlap and interact with organisational procurement processes. l 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. l 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.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 14 Procurement/development processes

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 15 System procurement l Acquiring a system for an organization to meet some need l Some system specification and architectural design is usually necessary before procurement You need a specification to let a contract for system development The specification may allow you to buy a commercial off-the- shelf (COTS) system. Almost always cheaper than developing a system from scratch l Large complex systems usually consist of a mix of off the shelf and specially designed components. The procurement processes for these different types of component are usually different.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 16 The system procurement process

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 17 Procurement issues l Requirements may have to be modified to match the capabilities of off-the-shelf components. l The requirements specification may be part of the contract for the development of the system. l There is usually a contract negotiation period to agree changes after the contractor to build a system has been selected.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 18 Contractors and sub-contractors l The procurement of large hardware/software systems is usually based around some principal contractor. l Sub-contracts are issued to other suppliers to supply parts of the system. l Customer liases with the principal contractor and does not deal directly with sub-contractors.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 19 Contractor/Sub-contractor model

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 20 Legacy systems l Socio-technical systems that have been developed using old or obsolete technology. l Crucial to the operation of a business and it is often too risky to discard these systems Bank customer accounting system; Aircraft maintenance system. l Legacy systems constrain new business processes and consume a high proportion of company budgets.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 21

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 22 Legacy system components l Hardware - may be obsolete mainframe hardware. l Support software - may rely on support software from suppliers who are no longer in business. l Application software - may be written in obsolete programming languages. l Application data - often incomplete and inconsistent. l Business processes - may be constrained by software structure and functionality. l Business policies and rules - may be implicit and embedded in the system software.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 23

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 24 Key points l Human and organisational factors have a significant effect on the operation of socio-technical systems. l There are complex interactions between the processes of system procurement, development and operation. l A legacy system is an old system that continues to provide essential services. l Legacy systems include business processes, application software, support software and system hardware.