Fundamentals of Software Engineering

CS 2042
 Chapter-02
Software Process
Process …
When we provide a service or create a product we always
follow a sequence of steps to accomplish a set of tasks

We can think of a series of activities as a process

Any process has the following characteristics

It prescribes all of the major activities
It uses resources and produces intermediate and final products
It may include sub-processes and has entry and exit criteria
The activities are organized in a sequence
Constrains or control may apply to activities
(budget control, availability of resources )
 Software Processes
 A structured set of activities required to develop a software system.
 When the process involves the building of some product we refer to
the process as a life cycle
 Software Development Process – Software life cycle

Coherent sets of activities for

Specifying,
Designing,
Implementing and
Testing software systems
Major problems in software developments …
Major problems in software developments …

The requirements The developers This is how the

specification was This is how the
understood it problem was
defined like this problem is solved now
in that way solved before.

This is how the program

That is the program This, in fact, is what the
is described by
after debugging customer wanted … ;-)
marketing department
 The Software Process

Specification
defining what the system should do;
Design and implementation
defining the organization of the system and
implementing the system;
Validation
checking that it does what the customer wants;

Evolution
changing the system in response to changing
customer needs.
Generic Software Process Models

The waterfall model

Separate and distinct phases of specification and development
Evolutionary development
Specification and development are interleaved
Reuse-based development
The system is assembled from existing components
Process iteration
Incremental development
Spiral development
Agile software Development
1. Waterfall Model
Requirements
definition

System and
software design

Implementation
and unit testing

Integration and
system testing

Operation and
maintenance
Waterfall Model

The Waterfall Model was first Process Model to be introduced.

It is also referred to as a linear-sequential life cycle
model.
It is very simple to understand and use.
In a waterfall model, each phase must be completed fully
before the next phase can begin.
This type of model is basically used for the project which is
small and there are no uncertain requirements.
At the end of each phase, a review takes place to determine if
the project is on the right path and whether or not to
continue or discard the project.
In this model the testing starts only after the development is
complete. In waterfall model phases do not overlap.
Waterfall Model Phases

Requirements analysis and definition

System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
When to use the waterfall model:

This model is used only when the requirements are very

well known, clear and fixed.
Product definition is stable.
Technology is understood.
There are no ambiguous requirements
Ample resources with required expertise are available
freely
The project is short.
Advantages of Waterfall model

Has well defined phases with well defined inputs

This model is simple and easy to understand and use.
It is easy to manage due to the rigidity of the model –
each phase has specific deliverables and a review process.
In this model phases are processed and completed one at
a time. Phases do notoverlap.
Waterfall model works well for smaller projects where
requirements are very well understood.
Drawbacks of Waterfall model

The drawback of the waterfall model is the difficulty of

accommodating change after the process is underway
Inflexible partitioning of the project into distinct stages
This 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.
Not a good model for complex and object-orientedprojects.
2. Evolutionary Development Model/ Prototyping

Exploratory development
- Objective is to work with customers and to evolve a final system
from an initial outline specification.
- Should start with well-understood requirements.
- The system evolves by adding new features as they are proposed by
customer.
Throw-away prototyping
Objective is to understand the system requirements. Should start
with poorly understood requirements
Develop “quick and dirty” system quickly;
Expose to user comment;
Refine;
Until adequate system developed.
Particularly suitable where:
- detailed requirements not possible;
- powerful development tools (e.g. GUI) available
Evolutionary Development
Concurrent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
Evolutionary Development

Problems
Lack of process visibility
Systems are often poorly structured for rapid
Special skills (e.g. in languages
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
3. Reuse-Oriented Development

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

This approach is becoming more important but

still limited experience with it
Reuse-Oriented Development

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integration validation
 Process Iteration
Modern development processes take iteration as
fundamental, and try to provide ways of managing,
rather than ignoring, the risk
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
4. Incremental Development

The incremental build model is a method of

software development where the product is designed,
implemented and tested incrementally (a little more is
added each time) until the product is finished. It involves
both development and maintenance.
Incremental Development (cont…)
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
Incremental Development (cont…)

Define outline Assign requirements Design system

requirements to increments architecture

Develop system Valida te Integrate Validate

increment Final
increment increment system system

System incomplete
When to use the Incremental model:

This model can be used when the requirements of the

complete system are clearly defined and understood.
Major requirements must be defined; however, some
details can evolve with time.
There is a need to get a product to the market early.
A new technology is being used
Resources with needed skill set are not available
There are some high risk features and goals.
Incremental Development Advantages

Generates working software quickly and early during

the software life cycle.
This model is more flexible – less costly to change
scope and requirements.
It is easier to test and debug during a smaller
iteration.
In this model customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are
identified and handled during it’s iteration.
Incremental Development Disadvantages

Needs good planning and design.

Needs a clear and complete definition of the whole system
before it can be broken down and built incrementally.
Total cost is higher than waterfall.
5. 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.
N o 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 of the Software Process
Det ermine object ives Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analys is
Risk
analys is
Risk
analys is Opera-
Prototype 3 tional
Prototype 2 prot oyp e
R isk
anayl sis P rot o-
R EVIEW t ype 1
Requirement s plan Simulations, models, benchmarks
Life-cycle plan Concept o f
Operat ion S/W
requirement s P rod uct
design Detailed
Requireme nt design
Develop ment
plan validation Code
Unit t est
Integration Design
and t est plan V&V Integr ation
Plan next phase test
Accept ance
S erv ice test Develop, verify
next-level product
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
Key points
Software processes are the activities involved in
producing and evolving a software system.They are
represented in a software process model
General activities are specification, design and
implementation, validation and evolution
Generic process models describe the organisation of
software processes
Iterative process models describe the software process as
a cycle of activities
 Software Process Activities

1. Specification
2. Design
3. Validation
4. Evolution
I. Software Specification

The process of establishing what services are

required and the constraints on the system’s operation
and development

Requirements engineering process

Feasibility study
Requirements elicitation and analysis
Requirements specification
Requirements validation
The Requirements Engineering Process

Feasibility Requirements
study elicitation and
analysis
Requirements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
II. Software Design and Implementation

The process of converting the system

specification into an executable system
Software design
Design asoftware structure that realises the specification
Implementation
Translate this structure into an executable program

The activities of design and implementation are closely

related and may be inter-leaved
Design Process Activities

Architectural design
Abstract specification
Interface design
Component design
Data structure design
Algorithm design
 The Software Design Process

Requirem ent s
sp ecifictaion

Design actvi ties

Data
Archite ctuarl Abst ract In ter face Component Algorithm
struc tuer
design specifictaion design design design
design

Sof tware Data

System In ter face Component Algorithm
specifictaion struc tuer
archite ctuer sp ecifictaion sp ecifictaion sp ecifictaion sp ecifictaion

Design porducts
Design Methods

Systematic approaches to developing a

software design

The design is usually documented as a set of graphical

models
Possible models
Data-flow model
Entity-relation-attribute model
Structural model
Object models
 Programming and Debugging
Translating a design into a program and removing
errors from that program

Programming is a personal activity - there is no generic

programming process.
Programmers carry out some program testing to discover
faults in the program and remove these faults in the debugging
process.

 Black-Box Testing: The internal workings of an application need not be

known.
 Grey-Box Testing:The tester has limited knowledge of the internal
workings of the application.
 White-Box Testing: Tester has full knowledge of the internal workings of
the application.
 The Debugging Process

Locate Design Repair Re-test

error error repair error program
 III. Software Validation

Verification and Validation is intended to show that a

system conforms to its specification and meets the
requirements of the system customer.
Verification is the process of evaluating products of a
development phase to find out whether they meet the
specified requirements.
Validation is the process of evaluating software at the end
of the development process to determine whether
software meets the customer expectations and
requirements.
 The Testing Process

Unit
testing
Module
testing
Sub-system
testing
System
testing
Component Acceptance
testing testing

Integration testing
User
testing
 Testing Stages
Unit testing
Individual components are tested
Module testing
Related collections of dependent components are tested
Sub-system testing
Modules are integrated into sub-systems and tested.The focus
here should be on interface testing
System testing
Testing of the system as a whole.Testing of emergent
properties
Acceptance testing
Testing with customer data to check that it is acceptable
 IV. Software Evolution
Software is inherently flexible and can change.

Software evolution is the term used to refer to the process

of developing software initially, then repeatedly updating it for
various reasons. (specifically software maintenance)

As requirements change through changing business

circumstances, the software that supports the business must
also evolve and change.
 System Evolution

Define system Assess existing Propose system Modify

requirements systems changes systems

Existing New
systems system
Computer-Aided Software Engineering
(CASE)
CASE is the application of computer-assisted tools and
methods in software development to ensure a high-quality
and defect-free software. CASE ensures a check-pointed
and disciplined approach and helps designers, developers,
testers, managers and others to see the project milestones
during development.

One of the best advantages of using CASE is the delivery

of the final product, which is more likely to meet real-
world requirements as it ensures that customers remain
part of the process.
 Key Points
Requirements engineering is the process of developing a
software specification
Design and implementation processes transform the
specification to an executable program
Validation involves checking that the system meets to its
specification and user needs
Evolution is concerned with modifying the system after it
is in use
CASE technology supports software process activities