1 software engineering dr. k. t. tsang lecture 2 socio-technical systems kentsang/swe/swe.htm
TRANSCRIPT
1
Software EngineeringDr. K. T. Tsang
Lecture 2
Socio-technical systemshttp://www.uic.edu.hk/~kentsang/SWE/SWE.htm
• This lecture is based on chapter 2 in Sommerville
3
System - a purposeful collection of interrelated components that work together to achieve some objective
Technical computer based systems- includes hardware & software but not procedures and processes, e.g. TV, mobile phones
Socio-technical systems- systems with defined operational procedures, e.g. pay-roll accounting systems
4
Socio-technical systems• A system that includes people, software
and hardware
• E.g. a publishing system
5
2.1Emergent system properties
• Properties that attributed to the whole system, not to any specific part of the system– Functional emergent properties: related to its
overall function; e.g. car & airplane are – Non-functional emergent properties: e.g.
performance, reliability, repair-ability, safety, security, usability, volume/space occupied
6
Reliability of a system
• Hardware reliability- probability of a hw component failing, how long it takes to repair
• Software reliability- probability to get incorrect output, sw failure
• Operator reliability- probability of human error
7
2.2 System engineering
• The activity of specifying, designing, implementing, validating, deploying and maintaining socio-technical systems.
• It involves hardware, software, human users and the system’s operating environment.
• Many engineering discipline may be involved.
• Difficult to change design once decisions are made.
8
Phases of system engineering
• Requirement definition
• System design
• Sub-system development
• System integration
• System installation
• System testing
• System evolution
• System decommission
9
2.2.1System requirement definition
• Specify what the system should do (its functions), and essential/desirable properties– Abstract function requirements– System properties (non-functional)– Forbidding characteristics
10
2.2.2 System design process
• Partition requirements
• Identify sub-systems
• Assign requirements to sub-systems
• Specify sub-system functionality
• Define sub-system interfaces
11
2.2.3 System modeling
• During the analysis and design phase, systems may be modeled as a set of components & relationships between them.
• This model can be represented as a block diagram showing sub-systems and connections among them.
12
Simple burglar alarm system in block diagram
Alarm controller
Movement sensors Door sensors
Siren Voice synthesizer Telephone caller
13
An Architectural model: Air traffic control system see figure in text book:Sommerville
14
2.2.4 Subsystem development
• Subsystem development take on its own life.
• This may involve starting another system engineering process from scratch.
• Or, some systems are commercial off-the-shelf (COTS) system that can be integrated into the system.
15
System integration
• When all systems are developed and tested, they are put together to make up the complete system.
• This can be done in a “big bang” fashion.
• Most prudently, they should be integrated one at a time, because:– Subsystems can hardly be finished at the same
time– Incremental integration reduces the cost of error
location
16
System installation
17
System testing
18
2.2.6 System evolution: reasons
• Large, complex system often has a long life time.
• System requirement may be changed due to changes in business practice or new functions are added, or changes in software/hardware technology.
• To keep up with the new situation or new hw, system must be evolved accordingly.
19
System evolution
is often costly because– Original design must be re-examined in light of the
new requirement– Changes in one subsystem be affect other
subsystems in terms of performance and behavior– If reasons for original design decision are un-
documented, it will be difficult to make sound decision to modify the original design
– As system ages, previous changes may add up to the cost of further changes
20
2.2.7 System decommission
Taking system out of service after its useful life time:– Disassembling & recycling hw & materials– Saving data that may be still valuable to the
organization
21
Software EngineeringDr. K. T. Tsang
Lecture 3
Critical systems
22
Types of critical systems
• Safety-critical systems- may result in injury or damages if fail
• Mission-critical systems- may result in failure of goal-directed activity if fail
• Business-critical systems- may result in high cost to business if fail
• This lecture is based on chapter 3 in Sommerville.
24
Dependability of critical systems
• The most important emergent property of critical systems because– Unreliable critical systems are rejected by
users– System failure costs are often enormous– Untrustworthy systems may cost lost of
valuable data/information
25
Types of system failure
• Hardware failure - due to bad design, or bad components
• Software failure – due to bad spec, design or implementation
• Human failure – fail to operate the system correctly
26
Example of a safety-critical system
• Insulin pump system (p.46 Sommerville)
• Radiotherapy system with software controller
27
Major aspects of system dependability
• Availability – able to deliver service at any given time when requested
• Reliability - able to deliver service over a period of time
• Safety - able to deliver service without causing damage
• Security - able to protect itself against accident or deliberate intrusion during operation
28
Other aspects in dependability• Reliability - how quick to recover from system
failure. This includes whether it is easy to diagnose problem and replace components in trouble
• Maintainability – is system easily changed to accommodate new requirement without introducing errors
• Survivability – ability to continue to deliver service when system is under attack or part of it is disable
• Error tolerance – whether the system can recover from user errors
29
It all depends on the system• Not all aspects of dependability are
important/applicable to all systems
• For a medical treatment system (Radiotherapy machine, insulin pump … ), availability (available when needed), and safety (able to deliver a safe dose of treatment) are most important consideration. While other aspects are either unimportant or not applicable.
30
Performance & dependability
• Generally, high level of dependability can only be achieved at the expense of system performance
• Increasing dependability can greatly increase developmental cost
31
3.3 Availability & reliability
• Availability – the probability that a system will be operational and able to deliver the requested service, at a point in time.
• Reliability – the probability of providing trouble-free operation as requested in a given environment, over a specified time period.
32
Types of System problem
• System failure – not able to deliver service as expected at a point in time
• System error – an erroneous system state that leads to unexpected behavior
• System fault – a software condition that leads to system error
• Human error – e.g. input error, operational error
33
Approaches to improve reliability• Fault avoidance – minimize possibility of or
trap mistakes before they cause faults; e.g. avoid pointers
• Fault detection & removal – detect and remove faults before system is used; e.g. systematic testing & debugging
• Fault tolerance – ensure faults do not result in system error/failures; e.g. system self checking, use redundant modules
34
A system as input/output mapping
Input set
Output set
System Software
Input causing erroneous outputs
Erroneous
Outputs
35
Software usage patterns
Possible Inputs
User 4
User 2
User 1Erroneous Inputs
User 3
36
Safety-critical system
• These systems never damage people or environment even if they fail.
• Most safety-critical systems are controlled by software.
• Examples: air traffic control systems, auto-pilot systems for aircraft or automobile, process control system in chemical plant.
37
Types of Safety-critical software
• Primary type: embedded as a controller in systems, whose failure will directly cause human injuries and environmental damages.
• Secondary type: indirectly causing injuries; e.g. computer aided engineering design software, medical database holding info of drugs prescribed to patients.
38
Reliability & safety• They are different attributes of dependability.
• Software systems that are reliable are not necessary safe due to– Incomplete specification, no description of system
behavior during critical situations.– Hardware failure may throw software in an
unanticipated situation.– Operator input may be correct only under specific
condition which is not met.
39
Terminology concerning safety• Accident/mishap – unplanned event/events which
cause human injuries or damages to property/environment.
• Hazard – condition with potential causing an accident.
• Damage – a measure of the loss due to a mishap.• Hazard severity – assessment of worst possible
damage from a hazard.• Hazard probability – probability of event which
create a hazard.• Risk – the probability that the system will cause an
accident.
40
How to assure system safety?
• Hazard avoidance – in system design
• Hazard detection & removal before the accident – in system design
• Damage limitation/control – system may include feature to minimize damage from an accident
41
Contribution of Software control to safety
• System complexity contributes to higher probability of accident.
• Software control increases system complexity.• Software control may increase probability of
accident.• Software controlled system may
– monitor a wider range of conditions– provide sophisticated safety interlock
• Software controlled system may improve system safety.