Lectures Software Engineering - Chapter 2: Systems Engineering

47 trang hoanguyen 3670

Download

Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 2: Systems Engineering", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

lectures_software_engineering_chapter_2.ppt

Nội dung text: Lectures Software Engineering - Chapter 2: Systems Engineering

Systems Engineering l Designing, implementing, deploying and operating systems which include hardware, software and people ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 1
Objectives l To explain why system software is affected by broader system engineering issues l To introduce the concept of emergent system properties such as reliability and security l To explain why the systems environment must be considered in the system design process l To explain system engineering and system procurement processes ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 2
Topics covered l Emergent system properties l Systems and their environment l System modelling l The system engineering process l System procurement ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 3
What is a system? l A purposeful collection of inter-related components working together towards some common objective. l A system may include software, mechanical, electrical and electronic hardware and be operated by people. l System components are dependent on other system components l The properties and behaviour of system components are inextricably inter-mingled ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 4
Problems of systems engineering l Large systems are usually designed to solve 'wicked' problems l Systems engineering requires a great deal of co-ordination across disciplines • Almost infinite possibilities for design trade-offs across components • Mutual distrust and lack of understanding across engineering disciplines l Systems must be designed to last many years in a changing environment ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 5
Software and systems engineering l The proportion of software in systems is increasing. Software-driven general purpose electronics is replacing special-purpose systems l Problems of systems engineering are similar to problems of software engineering l Software is (unfortunately) seen as a problem in systems engineering. Many large system projects have been delayed because of software problems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 6
Emergent properties l Properties of the system as a whole rather than properties that can be derived from the properties of components of a system l Emergent properties are a consequence of the relationships between system components l They can therefore only be assessed and measured once the components have been integrated into a system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 7
Examples of emergent properties l The overall weight of the system • This is an example of an emergent property that can be computed from individual component properties. l The reliability of the system • This depends on the reliability of system components and the relationships between the components. l The usability of a system • This is a complex property which is not simply dependent on the system hardware and software but also depends on the system operators and the environment where it is used. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 8
Types of emergent property l 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. l Non-functional emergent properties • Examples are reliability, performance, safety, and security. These relate to the behaviour of the system in its operational environment. They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 9
System reliability engineering l Because of component inter-dependencies, faults can be propagated through the system l System failures often occur because of unforeseen inter-relationships between components l It is probably impossible to anticipate all possible component relationships l Software reliability measures may give a false picture of the system reliability ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 10
Influences on reliability l Hardware reliability • What is the probability of a hardware component failing and how long does it take to repair that component? l Software reliability • How likely is it that a software component will produce an incorrect output. Software failure is usually distinct from hardware failure in that software does not wear out. l Operator reliability • How likely is it that the operator of a system will make an error? ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 11
Reliability relationships l Hardware failure can generate spurious signals that are outside the range of inputs expected by the software l Software errors can cause alarms to be activated which cause operator stress and lead to operator errors l The environment in which a system is installed can affect its reliability ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 12
The ‘shall-not’ properties l Properties such as performance and reliability can be measured l However, some properties are properties that the system should not exhibit • Safety - the system should not behave in an unsafe way • Security - the system should not permit unauthorised use l Measuring or assessing these properties is very hard ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 13
Systems and their environment l Systems are not independent but exist in an environment l System’s function may be to change its environment l Environment affects the functioning of the system e.g. system may require electrical supply from its environment l The organizational as well as the physical environment may be important ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 14
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 2000 Software Engineering, 6th edition. Chapter 2 Slide 16
System architecture 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 2000 Software Engineering, 6th edition. Chapter 2 Slide 17
Component types in alarm system l Sensor • Movement sensor, door sensor l Actuator • Siren l Communication • Telephone caller l Co-ordination • Alarm controller l Interface • Voice synthesizer ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 19
Functional system components l Sensor components l Actuator components l Computation components l Communication components l Co-ordination components l Interface components ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 21
System components l Sensor components • Collect information from the system’s environment e.g. radars in an air traffic control system l Actuator components • Cause some change in the system’s environment e.g. valves in a process control system which increase or decrease material flow in a pipe l Computation components • Carry out some computations on an input to produce an output e.g. a floating point processor in a computer system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 22
System components l Communication components • Allow system components to communicate with each other e.g. network linking distributed computers l Co-ordination components • Co-ordinate the interactions of other system components e.g. scheduler in a real-time system l Interface components • Facilitate the interactions of other system components e.g. operator interface l All components are now usually software controlled ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 23
Component types in alarm system l Sensor • Movement sensor, Door sensor l Actuator • Siren l Communication • Telephone caller l Coordination • Alarm controller l Interface • Voice synthesizer ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 24
The system engineering process l 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 l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 25
System requirements definition l Three types of requirement defined at this stage • Abstract 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 l Should also define overall organisational objectives for the system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 28
System objectives l 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 l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 29
System requirements problems l Changing as the system is being specified l Must anticipate hardware/communications developments over the lifetime of the system l Hard to define non-functional requirements (particularly) without an impression of component structure of the system. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 30
The system design process l Partition requirements • Organise requirements into related groups l Identify sub-systems • Identify a set of sub-systems which collectively can meet the system requirements l Assign requirements to sub-systems • Causes particular problems when COTS are integrated l Specify sub-system functionality l Define sub-system interfaces • Critical activity for parallel sub-system development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 31
System design problems l Requirements partitioning to hardware, software and human components may involve a lot of negotiation l Difficult design problems are often assumed to be readily solved using software l Hardware platforms may be inappropriate for software requirements so software must compensate for this ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 33
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 2000 Software Engineering, 6th edition. Chapter 2 Slide 34
System integration 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 35
System installation l Environmental assumptions may be incorrect l May be human resistance to the introduction of a new system l System may have to coexist with alternative systems for some time l May be physical installation problems (e.g. cabling problems) l Operator training has to be identified ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 36
System operation l Will bring unforeseen requirements to light l Users may use the system in a way which is not anticipated by system designers l May reveal problems in the interaction with other systems • Physical problems of incompatibility • Data conversion problems • Increased operator error rate because of inconsistent interfaces ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 37
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 2000 Software Engineering, 6th edition. Chapter 2 Slide 38
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 2000 Software Engineering, 6th edition. Chapter 2 Slide 39
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 40
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 2000 Software Engineering, 6th edition. Chapter 2 Slide 42
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 2000 Software Engineering, 6th edition. Chapter 2 Slide 43
Key points l System engineering involves input from a range of disciplines l Emergent properties are properties that are characteristic of the system as a whole and not its component parts l System architectural models show major sub- systems and inter-connections. They are usually described using block diagrams ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 45
Key points l System component types are sensor, actuator, computation, co-ordination, communication and interface l The systems engineering process is usually a waterfall model and includes specification, design, development and integration. l System procurement is concerned with deciding which system to buy and who to buy it from ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 46
Conclusion l Systems engineering is hard! There will never be an easy answer to the problems of complex system development l Software engineers do not have all the answers but may be better at taking a systems viewpoint l Disciplines need to recognise each others strengths and actively rather than reluctantly cooperate in the systems engineering process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2 Slide 47