Unit 2-software development process notes

Unit-2
Critical Systems, Software
Processes
NHCE-MCA Software Engineering Concepts 1

Critical Systems

Chapter Outline
Safety-critical system
System dependabilitySystem dependability
Availability and reliability
Safety
Securityy

Critical Systems
Safety-critical systems
• Failure results in loss injuryinjury oror damagedamage of life,
to the environment;
• Chemical plant protection system;
Mission critical systemsMission-critical systems
• Failure results in failure of some goalgoal--directeddirected
activityactivity;;yy;;
• Spacecraft navigation system;
Business-critical systems
• Failure results in high economiceconomic losseslosses;;
• Customer accounting system in a bank;

System dependability
For critical systems, it is usually the case that the most
important system property is the dependabilitydependability of the system.
The dependability of a system reflects the user’s degree of
trust in that system. It reflects the extent of the user’suser’s
confidenceconfidence that it will operate as users expect and that it will
not ‘fail’ in normal use.

Importance of dependability
Systems that are not dependabledependable and are unreliableunreliable, unsafeunsafe
or insecureinsecure may be rejectedrejected by their users.or insecureinsecure may be rejectedrejected by their users.
The costs of system failure may be very high.
Undependable systems may cause informationinformation lossloss with aUndependable systems may cause informationinformation lossloss with a
high consequent recovery cost.

Development methods for critical systems
The costs of critical system failure are so high that
development methods may be used that are notdevelopment methods may be used that are not
cost-effective for other types of system.
Examples of development methods
• Formal methods of software developmentp
• Static analysis
E t l lit• External quality assurance

Socio-technical critical systems
Hardware failure
• Hardware fails because of design and manufacturingHardware fails because of design and manufacturing
errors or because components have reached the end of
their natural life.
Software failure
• Software fails due to errors in its specification, design orSoftware fails due to errors in its specification, design or
implementation.
Operational failureOperational failure
• Human operators make mistakes. Now perhaps the
largest single cause of system failures.
largest single cause of system failures.

A software-controlled insulin pump
Used by diabetics to simulate the function of the pancreas
which manufactures insulin, an essential hormone that
metabolises blood glucose.
Measures blood glucose (sugar) using a micro-sensor and
computescomputes thethe insulininsulin dosedose required to metabolise the
glucose.

Insulin pump organisation
Needle
Insulin reservoir
Needle
assembly
Pump Clock
Sensor AlarmController
Display1 Display2
Power supply

Insulin pump data-flow
Blood
Blood
parameters
Blood sugar
analysis
Blood sugar
sensor
Blood parameters
Blood sugar
level
Insulin
requirement
computation
Pump control
Insulin
delivery
controller
Insulin
pump
Insulin
Pump control
commands Insulin
requirement
controller

Dependability requirements
The system shall be available to deliver insulin when required
to do so.
The system shall perform reliabilityreliability and deliver the correct
amount of insulin to counteract the current level of blood
sugar.
The essential safetysafety requirement is that excessive doses ofyy
insulin should never be delivered as this is potentially life
threatening.

Dependability
The dependability of a system equates to its trustworthiness.
A dependable system is a system that is trusted by its users.A dependable system is a system that is trusted by its users.
Principal dimensions of dependability are:
• Availability;• Availability;
• Reliability;
Safety;• Safety;
• Security

Dimensions of dependability
Dependability
Availability Reliability SecuritySafetyAvailability Reliability Security
The ability of the system The ability of the system The ability of the system The ability of the system
Safety
The ability of the system
to deliver services when
requested
to deliver services as
specified
to operate without
catastrophic failure
to protect itelf against
accidental or deliberate
intrusion

Other dependability properties
R i bilitRepairability
• Reflects the extent to which the system can be repaired in
th t f f ilthe event of a failure
Maintainability
• Reflects the extent to which the system can be adapted to
new requirements;
Survivability
• Reflects the extent to which the system can deliver
services whilst under hostile attack;
Error tolerance
• Reflects the extent to which user input errors can be
avoided and tolerated.

Dependability costs
Dependability costs tend to increase exponentially as
increasing levels of dependability are requiredg p y q
There are two reasons for this
• The use of moremore expensiveexpensive developmentdevelopment techniquestechniquesThe use of moremore expensiveexpensive developmentdevelopment techniquestechniques
and hardware that are required to achieve the higher
levels of dependabilityy
• The increasedincreased testingtesting andand systemsystem validationvalidation that is
required to convince the system client that the required
levels of dependability have been achieved

Costs of increasing dependability
Cost
Low Medium High Very
high
Ultra-high
high
Dependability

Reliability
• The probability of failure-free system operation over aThe probability of failure free system operation over a
specified time in a given environment for a given purpose
AvailabilityAvailability
• The probability that a system, at a point in time, will be
operational and able to deliver the requested servicesoperational and able to deliver the requested services
Both of these attributes can be expressed quantitatively

It is sometimes possible to subsume system availability under
system reliabilityy y
• Obviously if a system is unavailable it is not delivering the
specified system servicesp y
However, it is possible to have systems with low reliability that
must be available. So long as system failures can be repairedg y
quickly and do notnot damagedamage datadata, low reliability may not be a
problem
Availability takes repair time into account

Reliability terminology
Term Description
System failure An event that occurs at some point in time whenSystem failure An event that occurs at some point in time when
the system does not deliver a service as expected
by its users
System error An erroneous system state that can lead to systemy y y
behaviour that is unexpected by system users.
System fault A characteristic of a software system that can
lead to a system error. For example, failure to
initialise a variable could lead to that variable
having the wrong value when it is used.
Human error or
mistake
Human behaviour that results in the introduction
of faults into a systemmistake of faults into a system.

Faults and failures
FailuresFailures are a usually a result of systemsystem errorserrors that are
derived from faults in the system
However, faultsfaults dodo notnot necessarilynecessarily resultresult inin systemsystem errorserrors
• The faulty system state may be transient and ‘corrected’
before an error arises
Errors do not necessarily lead to system failures
• The error can be corrected by builtbuilt--inin errorerror detectiondetection
and recovery
• The failure can be protected against by builtbuilt--inin
protectionprotection facilitiesfacilities.. These may, for example, protect
system resources from system errors

Reliability achievement
Fault avoidanceFault avoidance
• Development technique are used that either minimiseminimise
thethe possibilitypossibility ofof mistakesmistakes or traptrap mistakesmistakes before theythethe possibilitypossibility ofof mistakesmistakes or traptrap mistakesmistakes before they
result in the introduction of system faults
Fault detection and removalFault detection and removal
•• VerificationVerification and validationvalidation techniques that increase the
probability of detecting and correcting errors before theprobability of detecting and correcting errors before the
system goes into service are used
Fault toleranceFault tolerance
•• RunRun--timetime techniquestechniques are used to ensure that system
faults do not result in system errors and/or that system
faults do not result in system errors and/or that system
errors do not lead to system failures

Reliability modelling
You can modelmodel a system as an inputinput--outputoutput mapping where
some inputs will result in erroneous outputsp p
The reliability of the system is the probability that a particular
input will lie in the set of inputs that cause erroneousp p
outputs
DifferentDifferent peoplepeople willwill useuse thethe systemsystem inin differentdifferent waysways soyy yy
this probability is not a static system attribute but depends on
the system’s environment

Input/output mapping
IeInput set
Inputs causing
erroneous outputs
Program
OeOutput set
Erroneous
outputs
OeOutput set

Reliability perception
Possible
inputsinputs
User
1
Erroneous
inputs1
User
3
User
inputs
3
User
2

Reliability improvement
Removing X% of the faults in a system will not necessarily
improve the reliability by X%. A study at IBM showed that
% f f %removing 60% of product defects resulted in a 3%
improvement in reliability
P d f b i l d i f hProgram defects may be in rarely executed sections of the
code so may never be encountered by users. Removing these
does not affect the perceived reliabilitydoes not affect the perceived reliability
A program with known faults may therefore still be seen as
reliable by its usersreliable by its users

SafetySafety
Safety is a property of a system that reflects the system’s
ability to operate,operate, normallynormally oror abnormally,abnormally, withoutwithout dangerdanger of
causing human injury or death and without damage to the
system’s environment
I i i i l i id f fIt is increasingly important to consider software safety as more
and more devices incorporate software-based control systems
S f t i t l i i t i thSafety requirements are exclusive requirements i.e. they
exclude undesirable situations rather than specify required
system servicessystem services

Safety criticality
Primary safety-critical systems
• Embedded software systems whose failure can cause the
associated hardware to fail and directly threaten people.
Secondary safety-critical systems
• Systems whose failure results in faults in other systems
which can threaten people

Safety and reliability
Safety and reliability are related but distinct
• In general, reliability and availability are necessary but not
sufficient conditions for system safety
Reliability is concerned with conformance to a given
specification and delivery of service
Safety is concerned with ensuring system cannot cause
damage irrespective of whether
or not it conforms to its specification

Safety terminology
Accident
Hazard
Damageg
Hazard severity
Hazard probability
Risk

Safety achievement
Hazard avoidance
• The system is designed so that some classes of hazard
simply cannot arise.
Hazard detection and removal
• The system is designed so that hazards are detected and
removed before they result in an accident
Damage limitation
• The system includes protection features that minimise the
damage that may result from an accident

Normal accidents
Accidents in complex systems rarely have a single cause as
these systems are designed to be resilient to a single point of
ffailure
• Designing systems so that a single point of failure does
id i f d l i i l f fnot cause an accident is a fundamental principle of safe
systems design
Al t ll id t lt f bi ti fAlmost all accidents are a result of combinations of
malfunctions
It i b bl th th t ti i ti ll blIt is probably the case that anticipating all problem
combinations, especially, in software controlled systems is
impossible so achieving complete safety is impossible
impossible so achieving complete safety is impossible

SecuritySecurity
The security of a system is a system property that reflects the
system’s ability to protect itself from accidental or
deliberate 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

Fundamental security
If a system is a networked system and is insecure then
statements about its reliability and its safety are unreliable
These statements depend on the executing system and the
developed system being the same. However, intrusion can
h h i d/ i dchange the executing system and/or its data
Therefore, the reliability and safety assurance is no longer valid

Security terminology
ExposureExposure
Vulnerability
Attack
ThreatsThreats
Control

Damage from insecurity
Denial of service
• The system is forced into a state where normal services
are unavailable or where service provision is significantly
degraded
Corruption of programs or data
• The programs or data in the system may be modified in
an unauthorised way
Disclosure of confidential information
• Information that is managed by the system may be
exposed to people who are not authorised to read or use
that information

Security assurance
Vulnerability avoidanceVulnerability avoidance
• The system is designed so that vulnerabilities do not occur.
For example, if there is no external network connection then
external attack is impossibleexternal attack is impossible
Attack detection and elimination
• The system is designed so that attacks on vulnerabilities are
detected and neutralised before they result in an exposure.y p
For example, virus checkers find and remove viruses before
they infect a system
Exposure limitation
• The system is designed so that the adverse consequences
of a successful attack are minimised. For example, a backup
policy allows damaged information to be restored

Software Processes

Topics covered
Software process models
P it tiProcess iteration
Process activities
The Rational Unified Process
Computer aided software engineeringComputer-aided software engineering

I.The software process
A structured set of activitiesset of activities required to develop a
software systemy
• Specification;
• Design;Design;
• Validation;
• Evolution• Evolution.
A software process model is an abstract representation of a
process It presents a description of a processdescription of a process from someprocess. It presents a description of a processdescription of a process from some
particular perspective.

Generic software process models
The waterfall model
•• Separate and distinctSeparate and distinct phases of specification and
development.
Evolutionary development
• Specification, development and validation are
interleaved.interleaved.
Component-based software engineering
• The system is assembled from existing componentsexisting components.y g pg p

Waterfall model

Waterfall model phases
Requirements analysis and definition
System and software designSystem and software design
Implementation and unit testing
Integration and system testingIntegration and system testing
Operation and maintenance
Th i d b kTh i d b kThe main drawbackThe main drawback of the waterfall model is the difficulty
of accommodating change after the process is underway. One
h h t b l t b f i t th t hphase has to be complete before moving onto the next phase.

Waterfall model problems
Inflexible partitioning of the project into distinct stages makes it
difficult to respond to changing customer requirements.
Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly
limited during the design process.

Exploratory development
• Objective is to work with customerscustomers and to evolveevolve a finalObjective is to work with customerscustomers and to evolveevolve a final
system from an initial outline specification. Should start
with well-understood requirements and add new featuresq
as proposed by the customer.
Throw-away prototyping
• Objective is to understand the system requirements.
Should start with poorlypoorly understoodunderstood requirementsrequirements to
clarify what is really needed.

Problems
• Lack of process visibility;Lack of process visibility;
• Systems are often poorly structured;
• Special skills (e g in languages for rapid prototyping) may• Special skills (e.g. in languages for rapid prototyping) may
be required.
ApplicabilityApplicability
• For small or medium-size interactive systems;
For parts of large systems (e g the user interface);• For parts of large systems (e.g. the user interface);
• For short-lifetime systems.

Component-based software engineering
Based on systematic reuse where systems are integrated from
existing components or COTS (Commercial-off-the-shelf)
systems.
Process stages
• Component analysis;
• Requirements modification;
• System design with reuse;
• Development and integration.

Reuse-oriented development

II.Process iteration
Iteration can be applied to any of the generic process models.
Two (related) approachesTwo (related) approaches
• Incremental delivery;
• Spiral development• Spiral development.

Incremental delivery
Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments
with each increment delivering part of the required functionality.
User requirements are prioritised and the highest priority
requirements are included in early increments.

Incremental development

Incremental development advantages
Customer value can be delivered with each increment so
system functionality is available earlier.y y
Early increments act as a prototype to help elicit requirements
for later increments.
Lower risk of overall project failure.
The highest priority system services tend to receive the mostThe highest priority system services tend to receive the most
testing.

Spiral development
Process is represented as a spiral rather than as a sequence of
activities with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the
spiral are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the
process.

Spiral model sectors
Objective setting
• Specific objectives for the phase are identified.
Risk assessment and reduction
• Risks are assessed and activities put in place to reduce
the key risks.
Development and validation
• A development model for the system is chosen which
can be any of the generic models.
Planning
• The project is reviewed and the next phase of the spiral is
planned.

Spiral model of the software process

III.Process activities
Software specification
S ft d i d i l t tiSoftware design and implementation
Software validation
Software evolution

1.Software specification
The process of establishing whatwhat servicesservices are
required and the constraints on the system’srequired and the constraints on the system s
operation and development.
Requirements engineering process
• Feasibility study;y y
• Requirements elicitation and analysis;
R i ifi i• Requirements specification;
• Requirements validation.

The requirements engineering process

2.Software design and implementation
The process of converting the system specification into an
executableexecutable systemsystem.yy
Software design
• Design a software structure that realises theDesign a software structure that realises the
specificationspecification;;
ImplementationImplementation
•• TranslateTranslate this structure into an executableexecutable programprogram;;
The activities of design and implementation are closely relatedThe activities of design and implementation are closely related
and may be inter-leaved.

Design process activities
Architectural design
Abstract specificationAbstract specification
Interface design
Component designComponent design
Data structure design
Algorithm designAlgorithm design

The software design process

Structured methods
Systematic approaches to developing a software design.
The design is usually documented as a set of graphicalThe design is usually documented as a set of graphical
models.
Possible modelsPossible models
• Object model;
• Sequence model;• Sequence model;
• State transition model;
Structural model;• Structural model;
• Data-flow model.

Programming and debugging
Translating a design into a program and removing errors from
that program.p g
Programming is a personal activity - there is no generic
programming process.p g g p
Programmers carry out some program testing to discover faults
in the program and remove these faults in the debuggingg gg g
process.

The debugging process

3.Software validation
Verification and validation (V & V) is intended to show that a
system conformsconforms toto itsits specificationspecification and meets they pp
requirements of the system customer.
Involves checkingchecking and reviewreview processes and system testing.gg p y g
System testing involves executing the system with testtest casescases
that are derived from the specification of the real data to be
processed by the system.

The testing process

Testing stages
Component or unit testing
• Individual components are tested independently;• Individual components are tested independently;
• Components may be functions or objects or coherent
groupings of these entitiesgroupings of these entities.
System testing
T ti f th t h l T ti f t• Testing of the system as a whole. Testing of emergent
properties is particularly important.
A t t tiAcceptance testing
• Testing with customer data to check that the system
t th t ’ d
meets the customer’s needs.

Testing phases

4.Software evolution
Software is inherently flexible and can change.
As requirements change through changing businessAs requirements change through changing business
circumstances, the software that supports the business must
also evolve and change.g
Although there has been a demarcation between development
and evolution (maintenance) this is increasingly irrelevant as( ) g y
fewer and fewer systems are completely new.

System evolution

IV.The Rational Unified Process
A modern process model derived from the work on the UMLUML
and associated process.
Normally described from 3 perspectives
• A dynamicdynamic perspectiveperspective that shows phases over time;
• A staticstatic perspectiveperspective that shows process activities;
• A proactiveproactive perspectiveperspective that suggests good practice.pp p pp p gg g p

RUP phase model

RUP phases
Inception
• Establish the business case for the system.
Elaboration
• Develop an understanding of the problem domain and the
system architecture.
Construction
• System design, programming and testing.
Transition
• Deploy the system in its operating environment.

RUP good practice
Develop software iteratively
Manage requirementsManage requirements
Use component-based architectures
Visually model softwareVisually model software
Verify software quality
Control changes to softwareControl changes to software

Static workflows
Workflow Description
Business modelling The business processes are modelled using business use cases.
Requirements Actors who interact with the system are identified and use cases are
developed to model the system requirements.
Analysis and design A design model is created and documented using architectural
models, component models, object models and sequence models.
Implementation The components in the system are implemented and structured into
implementation sub-systems. Automatic code generation from design
models helps accelerate this processmodels helps accelerate this process.
Test Testing is an iterative process that is carried out in conjunction with
implementation. System testing follows the completion of the
implementation.
Deployment A product release is created, distributed to users and installed in their
workplace.
Configuration and
change management
This supporting workflow managed changes to the system (see
Chapter 29).
Project management This supporting workflow manages the system development (see
Chapter 5)Chapter 5).
Environment This workflow is concerned with making appropriate software tools
available to the software development team.

V. Computer-aided software engineering
Computer-aided software engineering (CASE) is software to
support software development and evolution processes.
Activity automation
• Graphical editors for system model development;
• Data dictionary to manage design entities;
• Graphical UI builder for user interface construction;p ;
• Debuggers to support program fault finding;
• Automated translators to generate new versions of aAutomated translators to generate new versions of a
program.

Case technology
Case technology has led to significant improvements in the
software process. However, these are not the order of
magnitude improvements that were once predicted
• Software engineering requires creative thought - this is
not readily automated;
• Software engineering is a team activity and, for large
projects, much time is spent in team interactions. CASE
technology does not really support these.

CASE classification
Classification helps us understand the different types of CASE
tools and their support for process activities.
Functional perspective
• Tools are classified according to their specific function.
Process perspective
• Tools are classified according to process activities that
are supported.
Integration perspective
• Tools are classified according to their organisation into
integrated units.

Functional tool classification
Tool type Examples
Planning tools PERT tools, estimation tools, spreadsheets
Editing tools Text editors, diagram editors, word processorsg g p
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 interface generators
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
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems

Activity-based tool classification

CASE integration
Tools
• Support individual process tasks such as design
consistency 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 software
process. Normally include several integrated
workbenches.

Tools, workbenches, environments

Unit Revision Questions
1. Define Critical System. Explain different typestypes of critical system with
examples.
2. Explain important factors /properties in dependabilitydependability of critical system .p p p p p yp y y
3. Describe dependability importance and influence in critical system withwith
example.example.
4 Explain the safetysafety and securitysecurity measures in critical systems4. Explain the safetysafety and securitysecurity measures in critical systems.
5. Describe various system process modelssystem process models advantages and draw backs
with description and block diagrams
Discuss the stages of incrementalincremental and spiral modelsspiral models with examples6. Discuss the stages of incrementalincremental and spiral modelsspiral models with examples.
7. Elicit various system development process activitiessystem development process activities with suitable
example and diagram.
E l i ti l ifi d (RUPti l ifi d (RUP) ti iti ith l8. Explain rational unified process(RUPrational unified process(RUP) activities with example.
9. Explain importance of computer aided software engineering(CASEcomputer aided software engineering(CASE)
tools and list some of the tools.

Unit 2-software development process notes

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Unit 2-software development process notes

Similaire à Unit 2-software development process notes (20)

Plus de arvind pandey

Plus de arvind pandey (13)

Dernier

Dernier (20)

Unit 2-software development process notes