1 chapter 3 critical systems (cont.). 2 safety safety is a property of a system that reflects the...
TRANSCRIPT
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
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.