1 Chapter 2 Socio-technical Systems (Computer-based System Engineering)

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Chapter 2 Computer-Based System Engineering.
Advertisements

1 Notes content copyright © 2004 Ian Sommerville. NU-specific content © 2004 M. E. Kabay. All rights reserved. Socio-technical Systems IS301 – Software.
CIS 376 Bruce R. Maxim UM-Dearborn
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
Chapter 2 – Software Processes
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Systems engineering 2.
Chapter 10 – Sociotechnical Systems Lecture 1 1Chapter 10 Sociotechnical Systems.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 2 Slide 1 Socio-technical Systems.
Socio-technical Systems
©Ian Sommerville 2000Software Engineering, 6th edition Slide 1 Introduction l Getting started with software engineering l Objectives To introduce software.
Software Engineering General Project Management Software Requirements
Chapter 2.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technical Systems.
Software Engineering Chapter 2 Socio-technical systems Ku-Yaw Chang Assistant Professor Department of Computer Science and Information.
SWE Introduction to Software Engineering
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Course Instructor: Aisha Azeem
©Ian Sommerville 2006Critical Systems Slide 1 Critical Systems Engineering l Processes and techniques for developing critical systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Systems engineering 1.
Requirements Engineering
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Software Evolution Planning CIS 376 Bruce R. Maxim UM-Dearborn.
Chapter 10 – Sociotechnical Systems 1Chapter 10 Sociotechnical Systems.
1 Chapter 2 Socio-technical Systems (Computer-based System Engineering)
CSI315 Web Applications and Technology Overview of Systems Development (342)
Software Engineering Dr. K. T. Tsang
2. Socio-Technical Systems
3- System modelling An architectural model presents an abstract view of the sub-systems making up a system May include major information flows between.
Socio-technical Systems. Objectives l To explain what a socio-technical system is and the distinction between this and a computer-based system. l To introduce.
Philosophical, Ethical, Socio- Technical Aspects of ISD.
Socio-technical Systems
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Software Engineering Chapter 2: Computer-based System Engineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Chapter 2 Computer-Based System Engineering As modified by Randy Smith.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Systems Engineering l Designing, implementing, deploying and operating systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Topic (1)Software Engineering (601321)1 Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
Software Requirements Engineering CSE 305 Lecture-2.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Software Requirements Engineering: What, Why, Who, When, and How
Socio-technical Systems (Computer-based System Engineering)
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Systems Engineering l Specifying, designing, implementing, validating, deploying.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Chapter 2 Computer-Based System Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technical Systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Socio-technical Systems. Objectives To explain what a socio-technical system is and the distinction between this and a computer-based system To introduce.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Chapter 10 – Sociotechnical Systems 1Chapter 10 Sociotechnical Systems CS 425 November 14, 2013 Ian Sommerville, Software Engineering, 9 th Edition Pearson.
Software Prototyping Rapid software development to validate requirements.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
1 Software Engineering, 8th edition. Chapter 2 Courtesy: ©Ian Sommerville 2006 Feb 12 th, 2009 Lecture # 3 Socio-technical Systems.
1. 2 An Introduction to Software Engineering 3 What is software? Computer programs and associated documentation such as requirements, design models and.
Socio-Technical Systems, York EngD Programme, 2009Slide 1 LSCITS and Socio-technical Systems Prof Ian Sommerville.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 2 Slide 1 Socio-technical Systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technical Systems.
Slide 1 CS 310 Chapter 2 Socio Technical Systems A system that includes people, software, and hardware Technical computer-based systems include hardware.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Chapter2: Systems Engineering l Designing, implementing, deploying and operating.
CHAPTER 2. Designing, implementing, deploying and operating systems which include hardware, software and people.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Computer-based system engineering.
Socio-technical Systems
Chapter 5 – Requirements Engineering
DT249/4 Information Systems Engineering
CS310 Software Engineering Lecturer Dr.Doaa Sami
Systems Engineering Designing, implementing, deploying and operating systems which include hardware, software and people.
Presentation transcript:

1 Chapter 2 Socio-technical Systems (Computer-based System Engineering)

2 System Engineering Is the activity of specifying, designing, implementing, deploying, maintaining systems, which include hardware, software, people and interaction of the system with users and its environment.

3 Objectives To introduce the concept of emergent system properties such as reliability and security To explain system engineering and system processes

4 What is a system? A collection of inter-related components working together towards some common objective. A system may include software, mechanical, electrical and electronic hardware and be operated by people. System components are dependent on other system components System is more than simply the sum of its parts! It has properties of the system as a whole. (emergent properties)

5 Socio-technical system characteristics They have emergent properties Properties of the system of a whole that depend on the system components and their relationships. They are often Non-deterministic غير قطعية They do not always produce the same output when presented with the same input because the system’s behaviour is partially dependent on human operators.

6 System categories, cont… 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. Socio-technical systems Systems that include technical systems but also operational processes and people who use and interact with the technical system. Socio-technical systems are governed by organizational policies and rules.

7 Problems of systems engineering Large systems are usually designed to solve 'wicked' problems الشرس Systems engineering requires a great deal of coordination across disciplines distrust and lack of understanding across engineering disciplines Systems must be designed to last many years in a changing environment

8 Emergent System 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 (result) of the relationships between system components They can therefore only be assessed and measured ONCE the components have been integrated into a system

9 Examples of emergent properties

10 Types of emergent properties 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.

11 Types of emergent properties (cont.) 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 that may make the system unusable.

12 Complexity of emergent system properties- reliability Because of component inter-dependencies, faults can be propagated through the system, so failure in one component can affect the operation of other components. System failures often occur because of unforeseen inter-relationships between component.

13 Influences on a system reliability Hardware reliability What is the probability of a hardware component failing and how long does it take to repair that component? 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. Operator reliability How likely is it that the operator of a system will make an error?

14 Influences on a system reliability (cont.) Properties such as performance, usability, and reliability are difficult to assess but can be measured after the system is operational. However, some properties such as safety and security pose a different problem, because it is very hard to predict all possible modes of access and explicitly forbid them. Safety - the system that reflects the system’s ability to operate without danger Security - the system should not permit unauthorised use Measuring or assessing these properties is very hard (why???)

15 The system engineering process Usually follows a ‘waterfall’ model because of the need for development of different parts of the system. There are important distinctions between the system engineering process and the software development process:

16 The system engineering process (cont.) Little scope for rework during system development because hardware changes are very expensive, reworking the system design to solve these problems. Software becomes so important in systems because of its flexibility Example: siting of Base station in mobile cell Always involves engineers from different disciplines, many engineering 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.

17 Inter-disciplinary involvement Air traffic control

18 The hardest part of building a software system is deciding what to build Advice: be sure you have assessed overall feasibility before you expend effort and time eliciting detailed requirements. Advice: if different customers cannot agree on requirements, the risk of failure is very high.

19 The system engineering process (cont.)

20 1- System requirements definition System requirements A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Three types of requirement defined at this stage 1. Abstract functional requirements. The basic functions that the system must provide are defined in an abstract way 2. System properties. Non-functional requirements for the system in general are defined (availability, performance) 3. Desirable and Undesirable characteristics. Unacceptable system behaviour is specified (what the system must not do)

21 System requirements definition (cont.) Also, the system requirement must define overall organizational objectives which the system should meet. Example: Consider a system for an office building to provide for fire protection and intruder detection. A statement of objective might be: 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

22 System requirements problems: Complex systems are usually developed to address wicked problems Problems that are not fully understood; Example : earthquake Can tackle the problem after it has happened

23 2- The system design process 1

24 The system design process 1 (cont.) Partition requirements, organize requirements into related groups, HW Req., SW Req. 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 are integrated, happen when purchase any sub-system. Specify sub-system functionality and relationships between them Define sub-system interfaces, if the interface has been agreed then a parallel sub-system development becomes possible.

25 System design 1 problems: As a problems appear you often have to redo work done in earlier stages. Solution : Using spiral process, each round on the spiral may add more detail to design.

26 Spiral model of requirements and design Spiral process 2

27 3- System modelling 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

28 Intruder alarm system Model OR Architecture

29 Component types in alarm system Sensor Movement sensor, door sensor (detect door opening, and movement in the rooms) Siren صفارة انذار Siren- warning when intruder is suspected شك. Communication Telephone caller, make external calls to police. Co-ordination Alarm controller, control the operation of the system. Interface Voice synthesizer, a synthesize message giving the location of the intruder.

30 Functional system components Sensor components Actuator components (siren) المحرك Computation components (Alarm Controller) Communication components Co-ordination components Interface components

31 Functional System components Sensor components Collect information from the system’s environment e.g. radars in an air traffic control system Computation components Carry out some computations on an input to produce an output e.g. a floating point processor in a computer system Communication components Allow system components to communicate with each other e.g. network linking distributed computer Interface components Facilitate the interactions of other system components e.g. operator interface All components are now usually software controlled

32 4- Sub-system development Typically parallel projects developing the hardware, software and communications from scratch. الصفر May involve some COTS (Commercial Off-The-Shelf) systems.. Bought for integration to system. COTS usually cheaper than to develop special-purpose component COTS may not meet the requirement exactly. (problem) If COTS product available it is worth to expense your time of rethinking in the design.

33 Sub-system development (cont.) When a problem is encountered in a system, a system need modification. For systems that involve extensive hardware, making modification after manufacturing has started is very expensive… Solution “Work arounds” that includes software change requirement because software is more flexible.

34 5- System Integration The process of putting hardware, software and people together to make a system The system may be integrated using: 1- a “big bang approach”: all subsystems are integrated at the same time. 2- incremental integrated process: the sub-systems are integrated one at a time

35 System Integration cont… Incremental integrated process is the best approach (why??) because: It reduce the cost of error location. In “big bang approach” the error may be from any of these subsystems. While in “incremental process” the errors are probably on the new subsystem or in the interaction between the existing subsystem and the new subsystem. Incremental integrated process problem: Interface problems between sub-systems are usually found at this stage (integration + testing) (Data flow( in / out ) at the boundary.)

36 6- System installation- problems Environmental assumptions may be incorrect May be human resistance to the introduction of a new system May be physical installation problems (e.g. cabling problems) Operator training has to be identified

37 System operation Users may use the system in a way which is not suitable by system designers May reveal problems in the interaction with other systems Physical problems of incompatibility Increased operator error rate because of inconsistent interfaces

38 7- System evolution Large and complex systems have a long lifetime. They must evolve to meet changing requirements[ error in system or change environment] Evolution is inherently costly because: Changes must be analyzed from a technical and business perspective [after changing must get the same goal of the system] Sub-systems interact [change in subsystem may affects on other subsystems]so problems can arise As systems Age: System structure is corrupted as changes are made to it, so the cost of making changes increases Existing systems which must be maintained are sometimes called legacy systems

39 8- System decommissioning Taking the system out of service after its useful operational lifetime وقف التشغيل Regards to Hardware: May require removal of materials (e.g. dangerous chemicals) which pollute the environment Regards to software: May require data to be restructured and converted to be used in some other system

40 Organizations/people/systems If you do not understand the organizational environment where a system is used, then the system is rejected

41 Systems and their environment Systems are exist in an environment The system is intended to make some changes in its environment, heating system changes its environment by increasing or decreasing its temperature. Environment affects the functioning of the system e.g. system may require electrical supply from its environment

42 System hierarchies

43 Human and organizational factors that affect the system design: Process changes, does the system require changes to the work processes in the environment? If so, training is required. If so they may resist the introduction to the system. Job changes, does the system de-skill the users in an environment or cause them to change the way they work? If so they may resist the introduction to the system. Organizational changes, does the system change the political power structure in an organization? e.g. Those who know how to operate in a Complex system have a great deal of political power.

44 Organizational processes The processes of systems engineering interact with procurement processes and the process of using and operating the system. Procurement/development/ operational processes

45 System procurement processes procurement processes: is embedded within the client organization that will buy and use the system.

46 System procurement process (cont.) This process concerned with: deciding on the best suppliers of that system and the best way for the organization to acquire a system to meet some need Some system specification is usually necessary You need a high level specification of what the system should do, in order to design or build (buy) a 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

47 System procurement process Issues Requirements may have to be modified to match the capabilities of off-the-shelf components The requirements specification may be part of the contract for the development of the system. After the contractor to build the system has been selected, there is usually a contract negotiation period for further changes to the requirements to be agreed upon,

48 Contractors and sub-contractors The procurement of large hardware/software systems is usually based on some principal contractor Sub-contracts are issued to other suppliers to supply parts of the system Customer deals with the principal contractor and does not deal directly with sub-contractors

49 Contractor/Sub-contractor model

50 Organizational processes, Operational processes Operational processes : the using of the system. 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. Example: Operators of Air traffic control system follow specific processes when the aircraft enter and leave airspace, when they have to change height, speed.

51 Legacy systems It is a Socio-technical systems that have been developed in the past and often use old or obsolete technology. it is often too risky to replace these systems, because the new system may not work well Bank customer accounting system;

52 Legacy system components

53 Legacy system components Hardware - may be obsolete mainframe hardware. Support software - may rely on support software from suppliers who are no longer in business. Application software - may be written in obsolete programming languages. Application data - often inconsistent and may be duplicated.

54 Alternative way for the component of legacy system : Layered model

55 Layered Legacy system Each layer depend on the layer below it Changing on layer may require consequent changes to layers that are above an below the changed layer.

56 Key points System engineering involves input from a range of disciplines, SW, HW, People and Environment. Emergent properties are properties that are characteristic of the system as a whole and not its component parts System architectural models show major sub-systems and inter-connections. They are usually described using block diagrams

57 Key points The systems engineering process is usually a waterfall model and includes specification, design, development and integration. System procurement is concerned with deciding which system to buy and who to buy it from