1. Software Engineering Dr. K. T. Tsang
Lecture 2
Socio-technical systems

2. 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
Movement sensors
Door sensors
Alarm controller
Telephone caller
Siren
Voice synthesizer

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. Taking system out of service after its useful life time:
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 Engineering Dr. 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

23. 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 causing erroneous outputs
Input set
System Software
Erroneous
Outputs
Output set

35. Software usage patterns
Possible Inputs
User 1
Erroneous Inputs
User 2
User 3
User 4

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.