Software Engineering 10IS51 unit 2

The Eduladder is a community of students, teachers, and programmers just interested to make you pass any exams. So we solve previous year question papers for you.
See Our team
Wondering how we keep quality?
Got unsolved questions?

Ask Questions


You are here:Open notes-->VTU-->Software-Engineering-10IS51-unit-2

Software Engineering [10IS51] unit-2

UNIT-2 CRITICAL SYSTEMS, SOFTWARE PROCESSES

Critical Systems
? For critical systems, it is usually the case that the most important system property
is the dependability 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’s confidence that it will operate as users expect and
that it will not ‘fail’ in normal use.
? Usefulness and trustworthiness are not the same thing. A system does not have to
be trusted to be useful
Dimensions of dependability
The software process
A software process is a structured set of activities required to develop a software
system
It involves the following phases:
? Specification
? Design
? Validation
? Evolution
A software process model is an abstract representation of a process. It presents a
description of a process from some particular perspective.
Software process models
1. The waterfall model
? Separate and distinct phases of specification and development
2. Evolutionary development
? Specification and development are interleaved
 Page 9
 
3. Formal systems development
? A mathematical system model is formally transformed to an
Implementation
4. Reuse-based development
? The system is assembled from existing components
Waterfall model
The different phases in waterfall model are :
? Requirements analysis and definition
? System and software design
? Implementation and unit testing
? Integration and system testing
? Operation and maintenance
The drawback of the waterfall model is the difficulty of accommodating change after
the
process is underway.
Waterfall model problems
? Inflexible partitioning of the project into distinct stages
? This makes it difficult to respond to changing
customer requirements
This model is only appropriate when the requirements are well-understood.
Evolutionary development
There are 2 types :
1. Exploratory development
 Page 10
 
? Objective is to work with customers and to evolve a final system from an initial
outline
specification. Should start with well-understood requirements
2.Throw-away prototyping
? Objective is to understand the system requirements. Should start
with poorly understood requirements
Problems
? Lack of process visibility
? Systems are often poorly structured
? Special skills (e.g. in languages for rapid prototyping) may be required
Applicability
? For small or medium-size interactive systems
? For parts of large systems (e.g. the user interface)
? For short-lifetime systems
Formal systems development
It is based on the transformation of a mathematical specification through different
representations to an executable program.
Transformations are ‘correctness-preserving’ so it is straightforward to show that the
program conforms to its specification.
It is embodied in the ‘Cleanroom’ approach to software development.
 Page 11
 
Problems
? Need for specialised skills and training to apply the technique
? Difficult to formally specify some aspects of the system such as
the user interface
Applicability
? Critical systems especially those where a safety or security case
must be made before the system is put into operation
Reuse-oriented development
It is based on systematic reuse where systems are integrated from existing
components or COTS (Commercial-off-the-shelf) systems
L
Process stages
? Component analysis
? Requirements modification
? System design with reuse
? Development and integration
This approach is becoming more important but still limited experience with it
Process iteration
System requirements ALWAYS evolve in the course of a project so process iteration
where earlier stages are reworked is always part of the process for large systems
Iteration can be applied to any of the generic process models
Two (related) approaches
? Incremental development
? Spiral development
Incremental development
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.
Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve.
 Page 12
 
Advantages
? Customer value can be delivered with each
increment so system functionality is available earlier
? 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 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.
 Page 13
 
CASE
Computer-aided  (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
? Debuggers to support program fault finding
? Automated translators to generate new versions of a program
Case technology
Case technology has led to significant improvements in the software process though
not
the order of magnitude improvements that were once predicted
?  requires creative thought - this is not
readily automatable
?  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.
1. Functional perspective
? Tools are classified according to their specific function
2. Process perspective
? Tools are classified according to process activities that are supported
3. Integration perspective
? Tools are classified according to their organisation into integrated units
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
 Page 14
 
Tools, workbenches, environments

Editors