1c system specification
TRANSCRIPT
-
7/29/2019 1c System Specification
1/43
-
7/29/2019 1c System Specification
2/43
Agenda Software Application
CASE
CASE Tools System Specification
-
7/29/2019 1c System Specification
3/43
Software Application Software may be applied in any situation.
Information content and determinacy are important
factors. Content refers to the meaning and form of incoming
and outgoing information.
For example, many business applications use highly
structured input data (a database) and produceformatted reports.
Software that controls an automated machine
3
-
7/29/2019 1c System Specification
4/43
Software Application(Cont..) It is somewhat difficult to develop meaningful generic
categories for software applications.
The following are the classification for software.
1. System Software
2. Embedded Software
3. Real-time Software
4. Business Software
5. Personal Computer Software
6. Engineering And Scientific Software
7. Artificial Intelligence Software
-
7/29/2019 1c System Specification
5/43
CASE CASE stands for Computer-Aided Software
Engineering.
CASE Technology provides software process.
CASE improve the software quality and producitvity.
-
7/29/2019 1c System Specification
6/43
The use of CASE are limited by two factors:
Design activity based on a creative thought. It has
been hardness technology to provide support for
design have not been successful.
Software Engineering is a team activity and they
spend a lot of time interacting with otherteammembers.
-
7/29/2019 1c System Specification
7/43
CASE Classification
It helps us to understand the types of CASE tools and
their role in supporting software process activities.
CASE tool from 3 of these perspectives
A function perspective
A process perspective An integration perspective
-
7/29/2019 1c System Specification
8/43
Functional tool classificationTool type Examples
Planning tools PERT tools, estimation tools, spreadsheets
Editing tools Text editors, diagram editors, word processors
Change management tools Requirements traceability tools, change control systems
Configuration management tools Version management systems, system building tools
Prototyping tools Very high-level languages, user int erface generat ors
Method-support tools Design editors, data dictionaries, code generators
Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static analysers, dynamic analysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Docum entation tools Page layout programs, image edit ors
Re-engineering tools Cross-reference systems, program re-structuring systems
-
7/29/2019 1c System Specification
9/43
Activity-based tool classification
Sp ecificatio n Design Implemen tatio n Verificat ion
and
Validat ion
Re-eng ineering t ools
Testing too ls
Debugging tools
Program analysis to ols
Language-processing
tools
Method suppor t to ols
Prototyping tool s
Configuration
management tools
Change man agement tools
Document ation too ls
Editing tool s
Planning t ools
-
7/29/2019 1c System Specification
10/43
CASE integration
Tools
Support individual process tasks such as designconsistency checking, text editing, etc.
Workbenches
Support a process phase such as specification or design,Normally include a number of integrated tools.
Environments
Support all or a substantial part of an entire softwareprocess. Normally include several integratedworkbenches.
-
7/29/2019 1c System Specification
11/43
System Specification A specification is an explicit set of requirements to be
satisfied by a material, product, or service.
In computer science, a formal specification is a
mathematical description of software or hardware that maybe used to develop an implementation
Different type of Specification
1. Formal Specification2. Program Specification
3. Functional Specification
4. Document Specification
-
7/29/2019 1c System Specification
12/43
1. Risk-driven specification
2. Safety specification
3. Security specification4. Software reliability specification
-
7/29/2019 1c System Specification
13/43
Risk-driven specification
Critical systems specification should be risk-driven.
This approach has been widely used in safety andsecurity-critical systems.
The aim of the specification process should be tounderstand the risks (safety, security, etc.) faced bythe system and to define requirements that reducethese risks.
-
7/29/2019 1c System Specification
14/43
Stages of risk-based analysis
Risk identification Identify potential risks that may arise.
Risk analysis and classification
Assess the seriousness of each risk. Risk decomposition
Decompose risks to discover their potential rootcauses.
Risk reduction assessment Define how each risk must be taken into eliminated
or reduced when the system is designed.
-
7/29/2019 1c System Specification
15/43
Risk-driven specification
-
7/29/2019 1c System Specification
16/43
Risk identification
Identify the risks faced by the critical system.
In safety-critical systems, the risks are thehazards that can lead to accidents.
In security-critical systems, the risks are thepotential attacks on the system.
In risk identification, you should identify risk
classes and position risks in these classes Service failure
Electrical risks
-
7/29/2019 1c System Specification
17/43
Insulin pump risks Insulin overdose (service failure). Insulin under dose (service failure). Power failure due to exhausted battery (electrical).
Electrical interference with other medicalequipment (electrical). Poor sensor and actuator contact (physical). Parts of machine break off in body (physical).
Infection caused by introduction of machine(biological).Allergic reaction to materials or insulin
(biological).
-
7/29/2019 1c System Specification
18/43
Risk analysis and classification
The process is concerned with understanding thelikelihood that a risk will arise and the potentialconsequences if an accident or incident should occur.
Risks may be categorized as: Intolerable.
As low as reasonably practical (ALARP).
Acceptable.
-
7/29/2019 1c System Specification
19/43
Levels of risk
Unaccepta ble r egion
Ris k cannot b e toler ated
Ris k to lerated onl y if
risk reduction i s impr act ical
or g ross ly e xpensive
Acceptable
region
Negl igible ris k
ALARPregion
-
7/29/2019 1c System Specification
20/43
Risk assessment
Estimate the risk probability and the risk severity.
It is not normally possible to do this precisely so
relative values are used such as unlikely, rare, veryhigh, etc.
-
7/29/2019 1c System Specification
21/43
Risk assessment - insulin pump
Identified hazard Hazard
probability
Hazard
severity
Estimated
risk
Acceptability
1. Insulin overdose Medium High High Intolerable
2. Insulin underdose Medium Low Low Acceptable
3. Power failure High Low Low Acceptable
4. Machine incorrectly fitted High High High Intolerable
5. Machine breaks in patient Low High Medium ALARP
6. Machine causes infection Medium Medium Medium ALARP7. Electrical interference Low High Medium ALARP
8. Allergic reaction Low Low Low Acceptable
-
7/29/2019 1c System Specification
22/43
Risk decomposition
Concerned with discovering the root causes of risksin a particular system.
Techniques have been mostly derived from safety-
critical systems and can be
Inductive, bottom-up techniques.
Deductive, top-down techniques.
-
7/29/2019 1c System Specification
23/43
Risk reduction assessment
The aim of this process is to identify dependabilityrequirements that specify how the risks should bemanaged and ensure that accidents/incidents do notarise.
Risk reduction strategies
Risk avoidance;
Risk detection and removal;
Damage limitation.
a ety requ rements nsu n
-
7/29/2019 1c System Specification
24/43
a ety requ rements - nsu npump
SR1: The system shall not deliver a single dose of insulin that is greater than a specified
maximum dose for a system user.SR2: The system shall not deliver a daily cumulative dose of insulin that is greater than a
specified maximum for a system user.SR3: The system shall include a hardware diagnostic facili ty that shall be executed at
least 4 times per hour.
SR4: The system shall include an exception handler for all of the exceptions that are
identified in Table 3.
SR5: The audible alarm shall be sounded when any hardware or software anomaly is
discovered and a diagnostic message as defined in Table 4 should be displayed.SR6: In the event of an alarm in the system, insulin delivery shall be suspended until the
user has reset the system and cleared the alarm.
-
7/29/2019 1c System Specification
25/43
Safety specification
The safety requirements of a system should beseparately specified.
These requirements should be based on an analysisof the possible hazards and risks as previously
discussed. Safety requirements usually apply to the system as a
whole rather than to individual sub-systems.
-
7/29/2019 1c System Specification
26/43
Safety requirements
Functional safety requirements
These define the safety functions of the protectionsystem i.e. the define how the system should provideprotection.
Safety integrity requirements
These define the reliability and availability of theprotection system. They are based on expected usageand are classified using a safety integrity level (SIL)from 1 to 4.
-
7/29/2019 1c System Specification
27/43
Security specification
Has some similarities to safety specification
Differences
No well-defined notion of a security life cycle forsecurity management; No standards;
Generic threats rather than system specific hazards
Mature security technology (encryption, etc.).However, there are problems in transferring this intogeneral use
-
7/29/2019 1c System Specification
28/43
System reliability specification
Hardware reliability Software reliability
Operator reliability
-
7/29/2019 1c System Specification
29/43
Rate of fault occurrence (ROCOF)
Reflects the rate of occurrence of failure in thesystem.
ROCOF of 0.002 means 2 failures are likely ineach 1000 operational time units e.g. 2 failuresper 1000 hours of operation.
Relevant for operating systems, transactionprocessing systems where the system has to
process a large number of similar requests thatare relatively frequent Credit card processing system, airline booking
system.
-
7/29/2019 1c System Specification
30/43
1. Formal specification in the software process
2. Sub-system interface specification
-
7/29/2019 1c System Specification
31/43
Formal methods
Formal specification is part of a more generalcollection of techniques that are known asformal methods.
These are all based on mathematicalrepresentation and analysis of software.
Specification in the software
-
7/29/2019 1c System Specification
32/43
Specification in the software
process
Specification and design are intermingled.
Architectural design is essential to structure aspecification and the specification process.
Formal specifications are expressed in amathematical notation with precisely definedvocabulary, syntax and semantics.
Specification in the software
-
7/29/2019 1c System Specification
33/43
Specification in the software
process
-
7/29/2019 1c System Specification
34/43
Use of formal specification
Formal specification involves investing more effort inthe early phases of software development.
This reduces requirements errors as it forces adetailed analysis of the requirements.
Incompleteness and inconsistencies can bediscovered and resolved.
Hence, savings as made as the amount of rework dueto requirements problems is reduced.
-
7/29/2019 1c System Specification
35/43
Cost profile
The use of formal specification means that the costprofile of a project changes
There are greater up front costs as more time andeffort are spent developing the specification
However, implementation and validation costsshould be reduced as the specification processreduces errors and ambiguities in the requirements.
-
7/29/2019 1c System Specification
36/43
Development costs with formal specification
-
7/29/2019 1c System Specification
37/43
Specification techniques
Algebraic specification
The system is specified in terms of its operations andtheir relationships.
Model-based specification The system is specified in terms of a state model that
is constructed using mathematical constructs suchas sets and sequences.
-
7/29/2019 1c System Specification
38/43
Interface specification
Large systems are decomposed into subsystemswith well-defined interfaces between thesesubsystems.
Specification of subsystem interfaces allowsindependent development of the differentsubsystems.
Interfaces may be defined as abstract data typesor object classes.
-
7/29/2019 1c System Specification
39/43
Sub-system interfaces
-
7/29/2019 1c System Specification
40/43
Specification components Introduction
Defines the sort (the type name) and declares otherspecifications that are used.
Description Informally describes the operations on the type.
Signature Defines the syntax of the operations in the interface and
their parameters.
Axioms Defines the operation semantics by defining axioms
which characterise behaviour.
-
7/29/2019 1c System Specification
41/43
Behavioural specification Model-based specification exposes the system state
and defines the operations in terms of changes to thatstate.
The Z notation is a mature technique for model-basedspecification. It combines formal and informaldescription and uses graphical highlighting whenpresenting specifications.
-
7/29/2019 1c System Specification
42/43
The structure of a Z schema
-
7/29/2019 1c System Specification
43/43
Thank youAnd
Question