1

Chapter 3

Critical Systems (cont.)

2

SafetySafety is a property of a system that reflects

the system’s ability to operate, normally or abnormally, without danger of causing human death and without damage to the system’s environment

Software control is much harder than Hardware control to any system.

3

Primary safety-critical systemsEmbedded software systems whose failure can

cause the associated hardware to fail and directly threaten people or environment.

Secondary safety-critical systemsSoftware Systems whose failure results in faults in

other systems which can threaten people (indirect way)

Example: Error in Medical database that holds details about the drugs

Discussion here focuses on primary safety-critical systems

Safety-criticality software Classes

4

Safety and reliability are related but distinctIn general, reliability and availability are

necessary but not sufficient conditions for system safety

Safety and reliability

5

Specification errorsIf the system specification is incorrect or incomplete

for critical situation then the system can behave as specified but still cause an accident

Hardware failures generating spurious inputsHardware error may generate a signals that are outside

the ranges that can be handled by the software.

Context-sensitive commands i.e. issuing the right command at the wrong timeOften the result of operator error

Several reasons why reliable systems are not

necessary safe ???

6

Safety achievement (The keys to assuring the safety?)

Hazard avoidance الخطر تجنبThe system is designed so that some classes of hazard

simply cannot arise. Ex: Cutting system.

Hazard detection and removalThe system is designed so that hazards are detected and

removed before they result in an accidentEx: chemical plant system detect excessive pressure

and open a valve to reduce the pressure.

Damage limitationThe system includes protection features that minimise

the damage that may result from an accidentEx: aircraft engine include automatic fire extinguisher.

7

Normal accidentsAlmost all accidents are a result of

combinations of malfunctions األعطال

Designing systems so that a single point of failure does not cause an accident is a fundamental principle of safe systems design

8

SecurityThe security of a system is a system property

that reflects the system’s ability to protect itself from accidental or external attack

Security is becoming increasingly important as systems are networked so that external access to the system through the Internet is possible

Security is an essential pre-requisite for availability, reliability and safety

9

Three types of damage that caused from insecurity or external attack??

Denial of serviceThe system is forced into a state where its normal

services are unavailable

Corruption of programs or dataThe programs or data in the system may be modified in

an unauthorised way, affect on the availability and reliability of system.

Disclosure of confidential informationInformation that is managed by the system may be

exposed to people who are not authorised to read or use that information, affect on the availability and reliability of system.

10

Security assuranceVulnerability avoidance

The system is designed so that vulnerabilities (weakness in computer-based system) do not occur. For example, if there is no external network connection then external attack is impossible

Attack detection and eliminationThe system is designed to detect

vulnerabilities. For example, virus checkers find and remove viruses before they infect a system

11

Chapter 4 - Part 1

Software Processes

12

Software ProcessesSoftware Processes is: Coherent (logically connected) sets of

activities for specifying, designing, implementing, testing and evolution software systemsSpecification, functionality and constraints

must be defined. Design and implementation, software meet

the specification must be produced.Validation, it does what the customer wants.Evolution, must evolve to meet changes.

13

software process model

A software process model is an abstract representation of a process.

It presents a description of a process.There are two types of modeles:

Prescriptive process models advocate an orderly approach to software engineering

Dynamic Process Models/ Methodologies Dynamic Methodology = {Dynamic Activity} +

{Dynamic CR}

14

Software process models

That leads to a few questions …If prescriptive process models strive for

structure and order, are they inappropriate for a software world that thrives on change?

Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? Dynamic Process Model

15

Generic software process models

The waterfall modelSeparate and distinct phases of specification and

developmentIncremental modelRAD model (Rapid Application Development)Evolutionary development

Specification and development are interleavedFormal systems development

A mathematical system model is formally transformed to an implementation

Reuse-based developmentThe system is assembled from existing components

16

Waterfall model

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

17

Waterfall model phases (activities)Requirements definition: services, constraints, and

goals are established.

System and software design: partitions requirements, identifying and describing the subsystems of the software and their relationships.

Implementation and unit testing: construction of programs and programs testing.

Integration and system testing: integrate and test the complete system

Operation and maintenance: install the system, correct errors, and enhance the system performance and services.(This is the longest phase.)

18

Waterfall model

Linear sequential model

Distinct stages with deliverables at the end of each phase

The main advantage : Each phase is terminated with the approval of a

document.

high process visibility—it is easy to see where in the process you are.

19

Waterfall model problemsThe drawback of the waterfall model is the

difficulty of making changes after the process is underway

Therefore, this model is only appropriate when the requirements are well-understood

The waterfall model is mostly used when the project is part of a larger systems engineering projects where a system is developed at several sites.

20

Evolutionary development

Is based on the idea of developing an initial implementation , exposing this to user and refining it through many versions until a system has been developed.

21

Evolutionary Models: Prototyping

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

22

Evolutionary Models: The Spiral

communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

23

Evolutionary Models: Concurrent

Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling activity

represents the stateof a software engineeringactivity or task

24

Evolutionary Models: Concurrent

ValidationFinal

version

Development Intermediateversions

Specification Initialversion

Outlinedescription

Concurrentactivities

25

Evolutionary development-types

Exploratory developmentShould start with well-understood

requirements, and work with the customer to explore their requirements to deliver a final system.

The system evolves by adding a new feature proposed by the customer.

Throw-away prototypingObjective is to understand the customer’s

requirements and develop a better requirements for the system. Should start with poorly understood requirements

26

Evolutionary development Advantages:More effective than waterfall because it meets the

immediate needs of customers.The specification can be developed incrementally.

Problems:Lack of process visibility(manager needs a regular

deliverables to measure progress)Systems are often poorly structured (continual

changes tend to corrupt the software structure )

Applicability:For small or medium-size interactive systemsFor parts of large systems (e.g. the user interface)

27

Evolutionary development

For large system , it is better to use a mixed process between waterfall and evolutionary.

How? We develop a system using throw-away

prototyping to resolve the uncertainties in the system specification

then re-implement using waterfall for a parts of the system that are well understood

and other parts (user interface ) should be developed using the exploratory approach.