SOFTWARE ENGINEERING

UNIT 1
CHAPTER - 3
 Software Process Models
• Process
– A process is a series of steps involving activities,
constraints and resources that produce an
intended output.
 Software Process Models
• Process
– Activities
• Communicate with the customer
• Identify the requirements
• Check the feasibility
• Analyze the requirement
• Make a design
• Develop the s/w according to the design
• Test the developed s/w
• If the s/w is according to the customer specification and free of errors then
implement it otherwise repeat all the above steps
 Software Process Models
• Process
– Constraints
• Requirements should be carefully identified
• Feasibility should be checked for the suitability of project in terms of
– S/w and H/w requirements
– Cost
– Time

• Problem should be carefully analyzed

• Design should be made keeping reusability in mind
• Testing should be done carefully
 Software Process Models
• Process
– Resources
• People

• Software
• Hardware
• Equipments

• Time
• Money
 Software Process Models

• Software Process
– Building a software product is actually known as
software process.
– Characteristics
• Used to understand and analyze the various s/w
process models.
 Software Process Models
• Software Process
– Characteristics
• Understandability
– Extent to which the process is defined and the ease to understand the process
definition

• Visibility
– Process activities are properly performed and progress of the process is visible
or not

• Supportability
– Either the process is supported by CASE tools or not

• Acceptability
– The process is acceptable or usable by those involved in it or not.
 Software Process Models
• Software Process
– Characteristics
• Reliability
– Product developed is free of errors

• Robustness
– Continuity of the process in spite of unexpected problems

• Maintainability
– Adaption of changing organizational needs

• Rapidity
– Speed of development of a process according to the specification
 Software Process Models
• Software Process
– Characteristics
• Understandability
• Visibility
• Supportability
• Acceptability
• Reliability
• Robustness
• Maintainability
• Rapidity
 Software Process Models
• Definition
– “A development strategy designed to solve an
actual problem in an industry setting”.
Analysis

Design

Code

Test
 Software Process Models
• This strategy includes the
– Process
– Methods
– Tools
– Generic phases
 Software Process Models
• All these models are called as prescriptive models
because they prescribe a set of process elements like
the following workflow
– Framework activities
– S/w engineering actions
– Tasks
– Work products
– Quality assurance and
– Change control mechanisms for each project
 Software Process Models
• The various s/w process models are:
– Waterfall model
– Incremental process model
– Evolutionary process model
• Prototyping model
• Spiral model
• Concurrent development model

– Specialized process model

• Component based development

– Unified process model

 Waterfall Model

• Also called as classical or traditional model.

• It is called waterfall model because it resembles like

a water flow.
• It is base to all other models.

• It is a 5 phase model

• Each phase is executed sequentially with out overlap.

 Waterfall Model

• The 5 different phases are:

– Requirement Analysis & Specification
(Communication)
– Design
– Implementation & Unit Testing (Coding)
– Integration & System Testing (Testing)
– Operation & Maintenance (Maintenance)
 Waterfall Model
Requirement
Analysis &
Specification

Design

Implementation
& Unit testing

Integration &
System Testing

Operation &
Maintenance
 Waterfall Model

• Requirement Analysis & Specification

– Purpose:
• To understand customer requirements & document them
properly

– Work-product / Outcome:
• SRS (Software Requirement Specification) Document

– Use:
• Used as a contract between the developer & the customer
 Waterfall Model
• Design
– Purpose:
• Transforms requirements into a structure suitable for implementation
in some programming language
• S/w architecture is specified in detail.

– Work-product / Outcome:
• SDD (Software Design Document)

– Use:
• Useful to start coding
 Waterfall Model

• Implementation & Unit Testing

– Design implemented
– SDD used
– Coding Phase
– Each and every module is separately tested to
check if they are providing desired functionality
 Waterfall Model

• Integration & System Testing

– Integration is bringing together all the modules and
testing them
– Modules combined together to form a complete s/w.
– Interfaces between the modules are tested
– System testing is testing the s/w with h/w
(environment after deploying)
 Waterfall Model

• Operation & Maintenance

– Purpose:
• Started operating in user environment

• To preserve the value of s/w overtime to add / remove

functionalities
• Done after delivering/deployment of s/w to customer
• Error correction, enhancement, etc.
 Waterfall Model

• Problems with this model

– “Follows the idea of Define before Design and
Design before Code”
– The problems created by the sequential nature of
the waterfall model are:
• Waterfall model expects complete and accurate
requirements early in s/w development process
 Waterfall Model

• Problems with this model

– The problems created by the sequential nature of
the waterfall model are:
• Working S/w: It is not available till very late in the s/w
development cycle.
• Risk: No assessment of risk in this model
 Waterfall Model

• Problems with this model

– The problems created by the sequential nature of the
waterfall model are:
• Change: Not suitable for accommodating changes during
development as the requirements once specified in level 1
cannot be changed through out the development
• Sequential Nature: No realistic in today’s world and this
model is not suitable for large projects.
 Waterfall Model

• When to use waterfall model

– When the requirements are very clearly understood,
and they will not change during SDLC
– It can be used by an organization
• That has an experience in developing a particular kind of
s/w.
• When it wants to build a new s/w based on an existing s/w.
Incremental Process Model
 Incremental Process Model

• Used to get regular feedback from the customer

to improve the needs of the customers.
• In this model, instead of delivering a complete
product, we deliver only a part of the product i.e.
delivering the product in parts and each part has
some functionalities.
 Incremental Process Model
• Characteristics:
– Requirements are defined clearly and no confusion about
requirements.
– Delivery of functionality is done in multiple phases depending on
the priority of the requirements.
– Every cycle delivers a semi – complete product with limited
functionality.
– Last cycle results in complete software.

– It delivers limited functionality quickly.

 Incremental Process Model

• One type of incremental model is:

– Iterative Enhancement model
• Phases:
– Same phases as waterfall model
– They are present with less restriction (need not follow sequential order)
– Occur in same order but in several cycles

• Requirements:
– Major requirements are specified by the customer at beginning and SRS is prepared.
– Priorities becomes the reason for multiple cycles.
– Implementation of these requirements is done based on priority.
 Incremental Process Model

– The phases in iterative model are same as waterfall model but they are done

repeatedly.

– A usable product is delivered after each cycle. This allows obtaining the customers

feedback after each cycle. As the product is developed in increments the testing of

the product also becomes easy.

– In the requirement phase , the requirements are gathered. Developers implement

these requirements based on the priorities. A project list is created consisting of a

set of tasks to be completed .The complete product is delivered after many

releases.

– The model consists of 3 iterative phases design, implementation and analysis. After

the final release, the system goes in the maintenance phase.

 Incremental Process Model

• One type of incremental model is:

– Advantage
• This model allows changes in requirements and adding new features during each

phase.

• Iterative process carried through various cycles permits customer to see the progress

of the software.

• This model is used when the partial portion of the software is to be quickly delivered

to the customer.

- Disadvantage
• Later software increments may require modifications in earlier ones which may

increase cost.
 Differences
Waterfall Model Incremental Model

• One final product • Complete software is

– At the end of SDLC divided into releases
– With all functions & features – Limited functions

• Long wait for product • First release is available

within weeks or months
 Incremental Process Model
• Advantages:
– Work with small team
– Initial product delivery is faster
– Can accommodate changes
– Customer response or feedback is considered

• Disadvantages:
– Actual cost may exceed the estimated cost
– System broken into small increments
 Evolutionary Models

• Phases:
– Same as waterfall model but, they are applied in
cyclical manner.
 Evolutionary Models

• In sdlc evolutionary development model the requirement is

broken down into different functional units.
• These functional units can also be referred to as module.
• These modules can be incrementally built and delivered.
• Here at the beginning the core module of the software
product is developed.
 Evolutionary Models

• New functionality is built, added to existing one and released

as new version.
• Each successive version can perform more functions in
comparison to its previous versions.
• As the evolutionary model in software engineering seems to
be developed in the incremental way so it is termed
as incremental model of the development.
 Evolutionary Models
Where sdlc evolutionary model is suitable to use?
Evolutionary model can be adopted for following types of projects:
• Evolutionary model in software engineering is also suitable for
large products where requirements can be divided into modules.
Every version will get built and delivered to customer who can then
use it instead of waiting for the complete system.
• Complex projects with unstable requirements.

• New technology is used.

• When requirements are not clear.
 Evolutionary Models

• Differences:
Waterfall Evolutionary
Time consuming Time saving
Costly Cheap
Inflexible Flexible
Process is easily understood, Clumsy due to excessive iterations
implementable and maintainable.

Sufficient requirement analysis Insufficient requirement analysis is

carried out performed
 Evolutionary Models
• Differences:
Iterative Evolutionary
• The Iterative Waterfall model is • The Evolutionary model is
probably the most used suitable for large projects which
software development model. can be decomposed into a set of
This model is simple to use and modules for incremental
understand. development and delivery.
• But this model is suitable only • This model is widely used in
for well-understood problems object-oriented development
and is not suitable for the projects. This model is only used
development of very large if incremental delivery of the
projects and projects that suffer system is acceptable to the
from many risks customer.
 Prototype Model
Requirements

Used to finalize requirements

Quick Design

Feedback &
Implement Refinement

Not accepted by customer

Customer
Evaluation
Accepted by customer
Design
In this model first we develop a working prototype

Implementation & (dummy approach which only explains about the outer
Unit Testing structure) of the software instead of the s/w.
Integration &
System Testing Final system development using
waterfall model
Operation &
Maintenance
 Prototyping Model

• The prototype developed has

– Limited functionality
– Not very good quality
– Low performance
– Low reliability, etc

But, used to
- Refine requirements
- Prepare final SRS
 Prototyping Model
• The prototype is not the final product
• Prototype code is discarded after requirements are
finalized
• Benefits:
– Helps us to unravel the customer requirements
– Helps us to gather experience for developing the final system.

– Cost increases in prototype development but overall cost

decreases.
Incremental Process Model
 Evolutionary Models

• Phases:
– Same as waterfall model but, they are applied in
cyclical manner.
 Prototype Model
Requirements

Used to finalize requirements

Quick Design

Feedback &
Implement Refinement

Not accepted by customer

Customer
Evaluation
Accepted by customer
Design
In this model first we develop a working prototype

Implementation & (dummy approach which only explains about the outer
Unit Testing structure) of the software instead of the s/w.
Integration &
System Testing Final system development using
waterfall model
Operation &
Maintenance
Spiral
Model

Combination of
Prototype & Iterative
Model
Spiral Model

• Simplified
Diagram
 Proposed by Barry Boehm in 1986

Spiral It is one of the most important

process model or SDLC model, which
Model provides support for Risk Handling.

Each loop of the spiral is called as

Phase of the software development
process
 Spiral Model
• In this diagrammatic representation, it looks
like a spiral with many loops, the exact
number of loops is unknown and can vary
from project to project.

• The radius of the spiral at any point

represents the expenses, i.e. cost of the
project so far.

• The angular dimensions(measurement of

specific quadrant) represents the progress
made so far in the current phase.
 • Spiral model is a combination of
incremental and prototype models, but
Spiral with more emphasis on Risk analysis.
Model • Each phase of the spiral model is divided
into 4 quadrants
– Planning
– Risk Analysis
– Engineering and Execution
– Evaluation
• A software project repeatedly passes
through these phases in iterations called
spirals in this model.
 Spiral Model
• In planning phase, requirements are gathered
as BRS(Business requirement specification) and
SRS(Software requirement specification).
• In Risk analysis phase, a process is undertaken
to identify the risks and find alternate
solutions. A prototype is produced at the end
of the risk analysis phase. If any risk is found in
this phase, then alternate solutions are
suggested and implemented.
 • In Engineering and Execution
phase, the software is
developed and tested.
Spiral • In Evaluation phase, the
Model customer can evaluate the
output of the project to date
before the project continues to
the next spiral.
Risk Handling in Spiral Model
• What is risk?
– It is any adverse situation that might effect the
successful completion of a software project.
• The most important feature of the spiral model is
handling these unknown risks after the project has
started.
• Such risk resolutions are easier done by developing
a prototype.
• The Spiral model builds a prototype to cope with the
risk at every phase of the software development.
 Spiral Model

• Advantages
– Best approach for testing and developing complex
and large projects
– Better risk analysis and management
– Better requirement analysis
– Fast and easy development

– Better time management

– Easy to change requirements and documentation if
any change happens in the middle of the
development
 Spiral Model
• Disadvantages
– Difficult to follow strategy for small
projects.
– Not much useful for low risk projects.
– Need more experience resources as
process is bit complex.
– Large documentation.
 Spiral Model
• When to use?
– For large and big projects
– For high risk projects
– If requirements are more
complicated
– If frequent changes are
required in the project
Concurrent development model

Also called as concurrent engineering

This model can be represented as “ A series of

major technical activities and tasks. All activities
exist concurrently but reside in different states.”
 Concurrent
development model

• For example, every project

has
– Customer
Communication
– Analysis

– Design

– Development
– Testing &
Implementation
Concurrent development model
Each activity has a ‘state’ and exists simultaneously
with other activities.

Events from activities can trigger changes of state in

other activities.

The concurrent process model defines a series of

events that will trigger transition from state to state
for each of the software engineering activities.
 The current process model is often
used for the development of the
Concurrent client – server applications.

Process
Model This model is applicable to all types
of software development and
provides an accurate picture of the
current state of a project
 Rapid Application Development (RAD) model

Requirement User
Construction Cut over
Planning Description

With active user participation

The above are the 4 phases in RAD

Used when we need to develop a software in quick time

Used when we can modularize the software i.e. each functionality is developed by a

separate team in parallel

Require huge skilled people to complete task rapidly

Developed by IBM
 RAD Model
• Requirement Planning
– Many customers sit together as a group and provide many
requirements and functionalities that are expected from software
(called as group elicitation technique)
– We use prototype approach to gather requirements
– User communication is required for good understanding

Build rapid
User Prototype
prototype Feedback
Evaluation refined

Prototype Approach - Cycle / Process is continued as long as requirements are finalized

 RAD Model

User Description Construction Cut over

The developer and the Design Install the software +
user team review the • High level and Low Acceptance testing
requirements gathered level design (based on SRS) +
We use many automated Coding Training of the user is
tools • Code generators + involved
Screen generators
(drag & drop tools)
Testing

Product released
 • Major features
– Rapid prototype
• Quick initial views about product
RAD – Powerful development tools
• Development time reduced. E.g.
Model CASE tools
– User involvement
• Acceptability of product is
increased
 RAD Model

• Not useful when

– Users cannot be involved continuously

– Tools & reusable components cannot

be used
– High skilled or specialized developers
are not available
– System cannot be modularized
 • Takes many characteristics from
various traditional models
• However these models are applied
when narrowly defined s/w
Specialized engineering approach is chosen.

Process • The various models are:

Models – Component – Based

development
– Formal methods model
– Aspect oriented s/w
development
 Component – Based
Development

• Component base development means to divide a project into

manageable, loosely dependent and separable parts called
modules or components which are developed independently
and are later integrated and tested.
• The various elements of CBD are:
– Reuse of s/w components

– Buy, do not develop

• Commercial off the shelf (COTS)

• Example: We have templates for creating web pages

– Shift of attention

• From programming to composing

• From design to selection
 Component – Based
Development
• This model incorporates many of the
characteristics of the spiral model.
• It is evolutionary in nature, demanding an
iterative approach to the creation of the
software.
• Modeling and construction activities begin with
the identification of candidate components.
• These components can be designed as either
conventional software or either object-oriented
classes or package classes.
 Component – Based
Development
• CBD follows the following steps:
– Available component-based products are
researched and evaluated for the application
domain
– Component integration issues are considered

– A s/w architecture is designed to accommodate

the component.
– Components are integrated into the architecture

– Comprehensive testing is conducted to ensure

proper functionality
 Component – Based
Development
• Advantages

– Supports fast development

– Easy maintenance of component

– Good quality of developed software(if

good components are used)
– Easy creation and upgradation of
software
– Low cost due to reusability of
components
 Component – Based
Development
• Disadvantages

– Developers risk of having their component

repositories become obsolete due to poor
planning or unfavorable industry trends.
– Customers face both risk and challenges in
using component – based applications to
meet their enterprise requirements
– It poses risk to the profitability and long-
term survival.
Formal Methods Model

Set of activities that leads to formal mathematical specification

of computer software to analyze software systems.

Formal methods enable a s/w engineer to specify, develop and

verify a computer-based system by applying mathematical
notation.

A variation on this approach, called clean room software

engineering, is currently applied by some software
development organizations.
 Formal Methods Model

• These methods eliminate many of the problems that are

difficult to overcome using other s/w engineering
approaches.
• Ambiguity, incompleteness and inconsistency can be
discovered and corrected more easily through the
mathematical analysis.
• It is developed in safety-critical environment like aircrafts,
medical devices, etc.
Formal Methods Model

• Drawbacks

– Time consuming and expensive

– Extensive training is required

– Difficult to use for technically

unsophisticated users.
 • Combination of Spiral and Concurrent
process models
• Helps in modularization to reduce
Aspect – development, maintenance costs.

Oriented • Aspect oriented software development

(AOSD) often referred to as Aspect –
Software oriented programming (AOP) is a new
s/w engineering process approach for
defining, specifying, designing and
constructing aspects.
 • Increasing complexities in software due to
customers local and technical concerns span
the entire architecture.

Aspect • These concerns may be localized properties of

Oriented a system, specialized functions or semantic

details.
Development
• Complex system developers implement a set of
localized features, functions and information
content.
• These localized software characteristics are
modeled as components and then constructed
with the context of system architecture.
• These cross-cutting concerns
(those concerns which effect the
overall system) are considered Aspect
in aspect-oriented model. Oriented
• This model provides process and Development
methodological approach for
defining, specifying, designing
and constructing aspects.
 Complex Software System

Information
Features: Functions:
Content:
F1 F11
Doc_1
F2 F12
Doc_2
. .
.
. .
.
. .
.
Fn F1n
Doc_n

Components

Object oriented class

Traditional Object-Oriented Development Approach

Cross cutting
concerns

Span the
entire
architecture

Concern: Customer required properties or areas of technical interests

Aspect: Mechanism for localizing the expression of cross cutting concerns

Aspect oriented software development

 Features

• AOSD ensures better modularization mechanism of program

designs, thereby reducing software design, development and
maintenance costs.
• It ensures improved and smaller size code as a result of
addressing the cross-cutting issues.
• It encourages the reuse of the code.
Aspect oriented • Aspect# is a free AOP framework for .NET
• Aspect C++ is an aspect-oriented extension
Development
to the C++ programming language
Tools
• AspectJ is a seamless aspect-oriented
extension to the Java programming
language
• Nanning Aspects is a simple yet scalable
AOP framework for Java
 The Unified Process
Unified process is an attempt to draw on the best features and characteristics
of various process models but implement them in agile software development.

The unified process recognizes the importance of customer communication and

methods for describing the customer’s view of system.

It emphasizes the important role of software architecture and helps the architect focus on
the right goals such as, understandability, reliance to future changes, and reuse.

The process flow is iterative and incremental that is essential in modern

software development.
 The Unified Process

It is use-case driven, architecture centric, iterative and incremental software

process model.

Thus it is an attempt to draw on the best features and characteristics of

conventional software process models but characterize them in the way that
implements many of the best principles of agile software development.
 The Unified Process Model

• Use-case driven means that it is based on the user view of the software, how
user will interact with the system and possible actions it can perform on the
system.
• Architecture centric means that it focuses on the reliance on the changes of
architecture in the future; portability, adaptability and reusability.
• The iterative and incremental nature of the unified process enables it more
mature, comprehensive and having high quality.
• It is based on Unified Modeling Language (UML) developed for object-
oriented modelling
 Phases of
Unified Model

• There are 5 phases in this model:

– Inception
– Elaboration

– Construction
– Transition

– Production
END OF UNIT 1 - CHAPTER 3