DT249/4 Information Systems Engineering

1. DT249/4 Information Systems Engineering Systems Engineering

2. System Engineering – Why Study? • In many cases, the software element of a system does not integrate properly or fails altogether because software engineers treat their system element (software) as if it existed in a vacuum. • It does not. • Don't take a "software-centric" view of the system • consider all system elements before focusing on software.

3. What is a system? • A purposeful collection of inter-related components working together to achieve some common objective • May include • software, • mechanical, electrical and electronic hardware, and • be operated by people. • System components are dependent on other system components • The properties and behaviour of system components are inextricably inter-mingled

4. System categories • Technical computer-based systems • Systems that include hardware and software but where the operators and operational processes are not normally considered to be part of the system. The system is not self-aware. • Socio-technical systems • Systems that include technical systems but also operational processes and people who use and interact with the technical system • Governed by organisational policies and rules

5. Socio-technical system characteristics • Emergent properties • Properties of the system of as a whole that depend on the system components and their relationships. • Non-deterministic • They do not always produce the same output when presented with the same input because the systems’s behaviour is partially dependent on human operators. • Complex relationships with organisational objectives • The extent to which the system supports organisational objectives does not just depend on the system itself.

6. Emergent properties • Properties of the system as a whole rather than properties that can be derived from the properties of components of a system • Emergent properties are a consequence of the relationships between system components • They can therefore only be assessed and measured once the components have been integrated into a system

7. Types of emergent property 1. Functional properties • These appear when all the parts of a system work together to achieve some objective. • For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components. 2. Non-functional emergent properties • Examples are reliability, performance, safety, and security. • Relate to the behaviour of the system in its operational environment. • Often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.

8. Examples of emergent properties

9. Systems engineering • Systems engineering is the activity of specifying, designing, implementing, validating, deploying and maintaining socio-technical systems. • Concerned with the services provided by the system, constraints on its construction and operation and the ways in which it is used.

10. The system engineering process • Usually follows a ‘waterfall’ model because of the need for parallel development of different parts of the system • Little 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 together • Much scope for misunderstanding here. Different disciplines use a different vocabulary and much negotiation is required. Engineers may have personal agendas to fulfil.

11. Systems engineering process vs. software development process • Distinction between the systems engineering process and the software development process: • Limited scope for rework during system development. E.g. Once some system engineering decisions have been made (siting of base stations in a mobile phone system), they are very expensive to change. • Interdisciplinary involvement. A lot of scope for misunderstanding – as different engineers use different terminology and conventions.

12. System objectives • An important part of the requirements definition phase is to establish a set of overall objectives that the system should meet. • Examples: • “To provide a fire and intruder alarm system for the building that will provide internal and external warning of fire or unauthorised intrusion.” • “To ensure that the normal functioning of the work carried out in the building is not seriously disrupted by events such as fire and unauthorised intrusion.”

13. System objectives (I) • Should define why a system is being procured for a particular environment. • Functional objectives • To provide a fire and intruder alarm system for the building which will provide internal and external warning of fire or unauthorized intrusion. • Organisational objectives • To ensure that the normal functioning of work carried out in the building is not seriously disrupted by events such as fire and unauthorized intrusion.

14. System requirements problems • Complex systems are usually developed to address complex problems • Problems 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.

15. The system design process • Partition requirements • Organise requirements into related groups. • Identify sub-systems • Identify a set of sub-systems which collectively can meet the system requirements. • Assign requirements to sub-systems • Causes particular problems when COTS are integrated. • Specify sub-system functionality. • Define sub-system interfaces • Critical activity for parallel sub-system development.

16. System design problems • Requirements 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. • Interdisciplinary activity • Involving teams drawn from various backgrounds

17. Inter-disciplinary involvement • Air traffic control (ATC) system • Uses radars and other sensors to determine aircraft position

18. Requirements and design • Requirements 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.

19. System modelling • System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. • Different models present the system from different perspectives • External perspective • showing the system’s context or environment; • Behavioural perspective • showing the behaviour of the system; • Structural perspective • showing the system or data architecture.

20. System modelling

21. System modelling • External perspective • Context Models • Process Models • Behavioural perspective • Data-Driven Models • Event-Driven Models • Structural perspective • Class Diagrams External Perspective Behavioural Perspective Structural Perspective

22. Context Models External Perspective • Context models are used to illustrate the operational context of a system • they show what lies outside the system boundaries. • social and organisational concerns may affect the decision on where to position system boundaries • Architectural models show the system and its relationship with other systems.

23. Context Models External Perspective ATM Machine

24. Process models External Perspective • Simple architectural models are usually supplemented by other models, such as process models. • Process models show the overall process and the processes that are supported by the system.

25. Behavioural models Behavioural Perspective • Behavioural models are used to describe the overall behaviour of a system. • Two types of behavioural model are: • Data-flow models • that show how data is processed as it moves through the system; • State machine models • that show the systems response to events. • These models show different perspectives so both of them are required to describe the system’s behaviour.

26. Data flow diagrams Behavioural Perspective • Can be used to show end-to-end processing in a system: • They show the entire sequence of actions that take place from an input being processed to the corresponding output that is the system’s response. • Next figure shows this use of data flow diagrams: • Processing that takes place in the insulin pump system

27. Architectural model Behavioural Perspective • An architectural model presents an abstract view of the sub-systems making up a system • May include major information flows between sub-systems. • Usually presented as a block diagram • May identify different types of functional component in the model. • Should be supplemented by brief descriptions of each sub-system

28. Architectural model Behavioural Perspective • At this level, the system is decomposed into a set of interacting subsystems. • Each subsystem should be represented in a similar way until the system is decomposed into functional components. • Functional components are components that, when viewed from the perspective of the sub-system, provide a single function.

29. Sub-Systems Behavioural Perspective • Usually multifunctional • Almost all component may include hardware and software, e.g..: • Embedded computing; • A network linking machines will consist of physical cables plus repeaters and network gateways, and they include processors and software to drive these processors as well as specialised electronic components • May be a large systems themselves • Usually developed in parallel

30. Block Diagrams Behavioural Perspective • Showing the major sub-systems and interconnections between these sub-systems • When drawing a block diagram • Represent each sub-system using a rectangle; • Show relationships between the sub-systems using arrows that link these rectangles; • The relationships indicated may include: • data flow; • ‘uses/used-by’; or • some other dependency relationship • The block diagram should be supplemented by brief descriptions of each sub-system.

31. Air traffic control system architecture

32. Sub-systemDevelopment Behavioural Perspective • Typically parallel projects developing the hardware, software and communications. • May involve some COTS (Commercial Off-the-Shelf) systems procurement. • Lack of communication across implementation teams. • Bureaucratic and slow mechanism for proposing system changes means that the development schedule may be extended because of the need for rework.

33. Sub-SystemDevelopment Behavioural Perspective • An overall architectural description should be produced to identify sub-systems making up the system. • Once these have been identified, they may be specified in parallel with other systems and the interfaces between sub-systems defined.

34. Example: Air traffic control system Behavioural Perspective • Includes hundreds of hardware and software components plus human users who make decisions based on information from that computer system • Several major sub-systems, themselves large systems; e.g. • Flight plan database • Weather System • Accounting system • Radar • Transponder • Aircraft communications system • Controller consoles • Data communication system • Activity logging system • The arrowed lines that link these systems should show information flow between these sub-systems

35. Air traffic control system architecture

36. Systems Integration Behavioural Perspective • The process of putting hardware, software and people together to make a system. • Should be tackled incrementally so that sub-systems are integrated one at a time. • Interface problems between sub-systems are usually found at this stage. • May be problems with uncoordinated deliveries of system components.

37. System Integration Behavioural Perspective • Two approaches: • ‘big-bang’ approach – where all the subsystems are integrated at the same time • incremental approach - where sub-systems are integrated one at a time • Incremental approach is best: • usually impossible to schedule the development of all the sub-systems so that they are all finished at the same time. • incremental integration reduces the cost of error location.

38. System Installation Behavioural Perspective • 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.

39. Software Tools Behavioural Perspective • Software tools can be used to support systems design activities: • Project management tools can produce project plans and schedules (e.g. gannt and pert charts) for design activities. • Documentation tools can allow easy development, storage, retrieval and maintenance of system design documentation. Such tools may include a data dictionary facility. • CASE tools can automate aspects of the development of design documentation and can in some cases generate code from the designs produced.

40. Software Tools:Benefits Behavioural Perspective • Project management tools allow monitoring and tracking of design activities • Documentation tools are useful for keeping systems design documentation up to date for future software maintenance activities • CASE tools can often check for consistency between different design diagrams and documents, thus improving quality control, and helping to enforcing design standards in the design process.

41. SystemEvolution Behavioural Perspective • Large systems have a long lifetime. They must evolve to meet changing requirements • 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. • Existing systems which must be maintained are sometimes called legacy systems.

42. SystemDecommissioning Behavioural Perspective • System decommissioning means taking the system out of service after its useful lifetime • May require removal of materials (e.g. dangerous chemicals) which pollute the environment • Should be planned for in the system design by encapsulation • May require data to be restructured and converted to be used in some other system.

43. Organizations, People and Computer Systems • Socio-technical systems are organizational systems intended to help deliver some organizational or business goal • If you do not understand the organizational environment where a system is used, the system is less likely to meet the real needs of the business and its users.

44. Human andOrganisational Factors • Process changes • Does the system require changes to the work processes in the environment? If so, training will be required. Users might resist the introduction of the system if that involve losing their jobs • Job changes • Does the system de-skill the users in an environment or cause them to change the way they work? Designs that involve managers having to change their way of working to fit the computer system are often resented. • Organisational changes • Does the system change the political power structure in an organisation? E.g., if an organisation is dependent on a complex system, those who know how to operate the system have a great deal of political power.

45. Example: Insulin pump control system • A personal insulin pump is an external device that mimics the function of the pancreas • Collects data from a blood sugar sensor and calculates the amount of insulin required to be injected. • Calculation based on the rate of change of blood sugar levels. • Sends signals to a micro-pump to deliver the correct dose of insulin. • Safety-critical system as low blood sugars can lead to brain malfunctioning, coma and death; high-blood sugar levels have long-term consequences such as eye and kidney damage.

46. Example: Insulin pump hardware architecture

47. Example: Mental Health Care-Patient Management System MHC-PMS • The MHC-PMS • an information system that is intended for use in clinics. • It makes use of a centralized database of patient information but has also been designed to run on a PC, so that it may be accessed and used from sites that do not have secure network connectivity. • When the local systems have secure network access, they use patient information in the database but they can download and use local copies of patient records when they are disconnected.

48. The Context Model of the MHC-PMS

49. image database medical records system hospital admissions system patient information system drug dispensing system Context model – another example • A patient information system in a hospital, including image storage for x-rays and a patient admissions system.

50. Class Diagrams Structural Perspective