Chapter 2 , Cont Sociotechnical Systems Computerbased System Engineering

1
Chapter 2 , Cont Socio-technical Systems
(Computer-based System Engineering)
2
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

3
Intruder alarm system Model OR Architecture
4
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.

5
Functional system components

• Sensor components
• Actuator components (siren)
• Computation components (Alarm Controller)
• Communication components
• Co-ordination components
• Interface components

6
System components

• Sensor components
• Collect information from the systems 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

7
System components continued

• 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

8
ATC (air traffic) System ArchitectureLarge
System
9
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.

10
Sub-system development

• 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 include software change
  that include software change requirement because
  software is more flexible .

11
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

12
System Integration cont

• Incremental integrated process is the best
  approach
• 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.)

13
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

14
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

15
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 subsystemsso 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

16
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

17
Organizations/people/systems

• If you do not understand the organizational
  environment where a system is used, then the
  system is rejected

18
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

19
System hierarchies
20
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.

21
Organizational processes

• The processes of systems engineering interact
  with procurement processes and the process of
  using and operating the system.

Procurement/development/ operational processes
22
System procurement processes

• procurement processes is embedded within the
  client organization that will buy and use the
  system.

23
System procurement process

• 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

24
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,

25
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

26
Contractor/Sub-contractor model
27
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.

28
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

29
Legacy system components
30
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.

31
Alternative way for the component of legacy
system Layered model
32
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.

33
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

34
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