SOFTWARE ENGGNIRING

• Software Engineering is the technological and managerial discipline

concerned with systematic production and maintenance of software
products that are developed and modified on time and within cost
estimates.

• S OFTWARE = Programs + Documentation required to develop, operate and

maintain programs.
• Documentation is an essential component of software because it is not
possible to understand different aspects of large programs without
documentation.

What is a software process?

 A set of activities whose goal is the development or evolution of software.
 Generic activities in all software processes are:
 Specification - what the system should do and its development
constraints
 Development - production of the software system
 Validation - checking that the software is what the customer wants
 Evolution - changing the software in response to changing demands.
 The identification of the software development as an engineering discipline
led to the need of a “Software Development Model” or “Software Life
Cycle”. The detailed model is still the topic of research but it is now clear
that a number of general models or paradigms of software development
can be identified.

 Software Process Models

 Waterfall model

 Evolutionary development

 Component-based software engineering

 Incremental model

 Spiral model
 Software Process Activities

 Specification

 Design and implementation

 Validation

 Evolution

 The Rational Unified Process

 Computer-Aided Software Engineering

Software Process Models

 Software process = organized set of activities aimed at building a software
system
 Software process model = an abstract representation of a software
process
 Fundamental software process activities:
 Software specification
 Software design
 Software implementation
 Software validation
 Software evolution

Software Process Models

1. T HE WATER - FALL APPROACH : This approach views the software life
cycle as made up of a number of stages such as: requirements specification,
software design, implementation and so on. After the completion of one
stage the development proceeds to the next stage.
2. E XPLORATORY P ROGRAMMING : This approach involves developing a
working system as quickly as possible and then modifying that system until
it works in an adequate way. This is used in the development of AI systems
where the users can not formulate a detailed requirement specification and
where adequacy rather than correctness in the aim of designers.
3. P ROTOTYPING : This approach is similar to exploratory programming in
that first phase involves the quick development of a program for user’s
experiment. But here the objective is to establish the system requirements.
This is developed from an outline specification. The users experiment with
the prototype to refine and improve the specification. This is followed by
the re-implementation of the software to produce a production quantity
system.
4. F ORMAL T RANSFORMATION : This approach involves developing a
formal specification of the system and transforming this specification to a
program using correctness - preserving transformations. Each
transformation is sufficiently close to the previous description that effort of
verifying the transformation is not excessive. It can then be guaranteed
that the developed program is the true implementation of the specification.
5. S YSTEM A SSEMBLY FROM R E - USABLE C OMPONENTS : This
approach involves developing software system from the existing
components. Thus the system development process becomes one of the
assembly rather than creation.

The first three of these approaches are all being used for practical system
development. Some systems have been built using formal transformation but
this is still an untried approach. The re-use-oriented model is still not
commercially viable because of the lack of reusable component libraries.

1. THE WATERFALL MODEL

This model is illustrated in the figure below. Because of the cascade from one
stage to other this model is called waterfall model. This is also called “Classic
Life-Cycle”. This model is the oldest and widely used one.

R EQUIREMENTS A NALYSIS AND D EFINITION : The system’s services,

constraints and goals are established by consultation with the system users.
They are then defined in a manner which is understandable by the users and
the development staff.
 Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance

S YSTEM AND S OFTWARE D ESIGN : The system design process partitions

the requirements either to hardware or to software systems and establishes an
overall systems structure. The software design involves representing the
software system functions in such a way that may be transformed to one or
more executable programs.

I MPLEMENTATION AND U NIT T ESTING : In this stage the software

design is realised as a set of working programs or program units. The unit-
testing means verifying each unit that meets its specifications and it is verified
that the defined input produces the desired results.

I NTEGRATION AND S YSTEM T ESTING : The individual program units or

programs are integrated and tested as a whole system to ensure that software
requirements are met. After testing the system is delivered to the customer.

O PERATION & M AINTENANCE : Normally (not necessarily) this is the

longest phase of the life cycle. The system is installed and put into practical
use. Maintenance involves correcting errors, which were not detected in
earlier stages of the life cycle, improving the implementation of the system
units and enhancing the system’s services as new requirements are discovered.

 Advantages:

• Organized approach, provides robust separation of phases

• Reflects common engineering practice
 Disadvantages:

• Doesn’t cope well with changes required by the client

• Development teams might wait for each other

• A working version of the product is available only late

 Applicability:

• When requirements are well known and few changes are likely to be
needed
• Can be used also for parts of larger software systems
2. Evolutionary Development…
This is based on the idea of developing an initial implementation, exposing it to
the user and refining this through many stages until an adequate system has
been developed

 This method requires rapid development of the system & rapid

incorporation of the modifications. To accomplish thus:
 A very high-level programming language such as LISP or PROLOG is
required.
 Powerful dedicated hardware is required.
 Integrated set of tools for the development of software is required.
 Its main difference from the other approaches is in the verification &
validation:
 Without a specification verification is impossible because for this purpose
the program is composed of its specifications.
 The notion of correctness is replaced by the notion of adequacy.
 It has been mostly used to develop AI systems & has been little used in the
development of large, long life systems because :
 It is not economical to produce a great deal of documentation as the
system goes on changing regularly.
 This results in a system whose structure is not well defined and if there is
any it gets deteriorated.
 Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version

Main characteristics

• The phases of the software construction are interleaved

• Feedback from the user is used throughout the entire process
• The software product is refined through many versions
• Types of evolutionary development:
• Exploratory development
• Throw-away prototyping

 Advantages:

• Deals constantly with changes

• Provides quickly an initial version of the system
• Involves all development teams

 Disadvantages:

• Quick fixes may be involved

• “Invisible” process, not well-supported by documentation
• The system’s structure can be corrupted by continuous change
• Special tools and techniques may be necessary
• The client may have the impression the first version is very close to the
final product and thus be less patient

 Applicability:
• When requirements are not well understood
• When the client and the developer agree on a “rapid prototype” that will be
thrown away
• Good for small and medium-sized software systems

3. Component-based Software
Engineering…
Main characteristics:

• Makes intensive use of existing reusable components

• The focus is on integrating the components rather than on creating them
from the scratch

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integration validation

 Advantages:

 Reduces considerably the software to be developed “in-house”

 Allows faster delivery
 In principle, more reliable systems, due to using previously tested
components
 Disadvantages:
 Compromises in requirements are needed
 Less control over the system’s evolution
 Applicability:
 When there is a pool of existing components that could satisfy the
requirements of the new product
 Emerging trend: integration of web services from a range of suppliers

4. Incremental Development…
 Main characteristics:

 Hybrid model that combines elements of the waterfall and evolutionary

paradigms
 The specification, design, and implementation phases are broken in smaller
increments

Define outline Assign requirements Design system

requirements to increments architecture

Develop system Validate Integrate Validate

increment increment increment system
Final
system
System incomplete

 Advantages:

 Provides better support for process iteration

 Reduces rework in the software construction process
 Some decisions on requirements may be delayed
 Allows early delivery of parts of the system
 Supports easier integration of sub-systems
 Lower risk of project failure
 Delivery priorities can be more easily set

Disadvantages:

 Increments need be relatively small

 Mapping requirements to increments may not be easy
 Common software facilities may be difficult to identify
 Applicability:
 When it is possible to deliver the system “part-by-part”

Boehm’s Spiral Model

 Main characteristics:
 Also a hybrid model that support process iteration
 The process is represented as a spiral, each loop in the spiral representing a
process phase
 Four sectors per loop: objective setting, risk assessment and reduction,
development and validation, planning
 Risk is explicitly taken into consideration

Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analysis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product

 Advantages:
 Risk reduction mechanisms are in place
 Supports iteration and reflects real-world practices
 Systematic approach
 Disadvantages:
 Requires expertise in risk evaluation and reduction
 Complex, relatively difficult to follow strictly
 Applicable only to large systems
 Applicability:
 Internal development of large systems
Process Activities
1. Specification
Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document

2.Design & Implementation

Requirements
specification

Design activities

Architectural Interface Component Data Algorithm

Abstract
design design design structure design
specification
design

Software Data
System Interface Component Algorithm
specification structure
architecture specification specification specification
specification

Design products

3. Testing..
The debugging process
Locate Design Repair Re-test
error error repair error program

The testing process

Component System Acceptance

testing testing testing

Testing phases
 Requirements System System Detailed
specification specification design design

System Sub-system Module and

Acceptance
integration integ ration unit code
test plan
test plan test plan and test

Acceptance System Sub-system

Service
test integ ration test integ ration test

System evolution

Define system Assess existing Propose system Modify

requirements systems changes systems

Existing New
systems system

The Rational Unified Process

RUP phases
Phase iteration

Inception Elaboration Construction Transition

Classification of CASE technology
 CASE
technology

Tools Workbenches Environments

File Integrated Process-centred

Editors Compilers
comparators environments environments

Analysis and
Programming Testing
design

Multi-method Single-method General-purpose Language-specific

workbenches workbenches workbenches workbenches