Software Engineering: Slide Set 02: Software Process Models

SOFTWARE ENGINEERING
Slide Set 02: Software Process Models

Software Process
• There are various software development
approaches defined and designed which are
used/employed during development process of
software, these approaches are also referred as
"Software Development Process Models“.
• Each process model follows a particular life

cycle in order to ensure success in process of
software development.
Software Process Models 2

Software Process
Process
Activities
Software Software Software Software

Specifications Development Validation Evolution
Figure 2.1 : Software Process Activities

Software Process Model
• A software process model (also called Life
Cycle Model) is a simplified description of a
software process that presents one view of
that process.

The Generic Model
• The generic models are not definitive
descriptions of software processes. Rather,
they are abstractions of the process that can be
used to explain different approaches to
software development.
• The Generic Models are process frameworks

that may be extended and adapted to create
more specific software engineering processes.

Adaptability of Models
• A life-cycle model will always be applied on every
project but the most suitable model and details of
phases will vary based on:
 Type of project (scientific, embedded, business, etc.)

 Characteristics of the project
 Common sense judgment
 Experience of the project team

The Waterfall Model
• Waterfall Model (also known as Linear Sequential
Model) was first Process Model to be introduced
and followed widely in Software Engineering to
ensure success of the project.
• In "The Waterfall" approach, the whole process of

software development is divided into separate
process phases.

The Waterfall Model
• The phases in Waterfall model are:
– Requirement Specifications
– Software Design
– Implementation
– Testing & Maintenance

The Waterfall Model
• All these phases are cascaded to each other so
that second phase will start when defined set of
goals are achieved for first phase and it is signed
off, so the name "Waterfall Model".
• All the methods and processes undertaken in

Waterfall Model are more visible.

The Waterfall Model
Figure 2.2 : The Waterfall Model

The Stages of Waterfall Model
Stage I: Requirement Analysis & Definition
• All possible requirements of the system to be

developed are captured in this phase.
• Requirements are set of functionalities and

constraints that the end-user (who will be using
the system) expects from the system.

• The requirements are gathered from the end-user

by consultation, these requirements are analyzed
for their validity and the possibility of
incorporating the requirements in the system to
be development is also studied.

• Finally, a Requirement Specification document is

created which serves the purpose of guideline for
the next phase of the model.

Stage II: System & Software Design
• Before a starting for actual coding, it is highly

important to understand what we are going to
create and what it should look like? The
requirement specifications from first phase are
studied in this phase and system design is
prepared.

Stage II: System & Software Design
• System Design helps in specifying hardware and

system requirements and also helps in defining
overall system architecture.
• The system design specifications serve as input for

the next phase of the model.

Stage III: Implementation & Unit Testing
• On receiving system design documents, the work

is divided in modules/units and actual coding is
started.
• The system is first developed in small programs

called units, which are integrated in the next
phase.

Stage III: Implementation & Unit Testing
• Each unit is developed and tested for its

functionality; this is referred to as Unit Testing.
• Unit testing mainly verifies if the modules/units

meet their specifications.

Stage IV: Integration & System Testing
• As specified above, the system is first divided in

units which are developed and tested for their
functionalities.

Stage IV: Integration & System Testing
• These units are integrated into a complete system

during Integration phase and tested to check if all
modules/units coordinate between each other and
the system as a whole behaves as per the
specifications.
• After successfully testing the software, it is

delivered to the customer.
Stage V: Operations & Maintenance
• This phase of "The Waterfall Model" is virtually

never ending phase (Very long).
• Generally, problems with the system developed

(which are not found during the development life
cycle) come up after its practical use starts, so the
issues related to the system are solved after
deployment of the system.
Stage V: Operations & Maintenance
• Not all the problems come in picture directly but

they arise time to time and needs to be solved;
hence this process is referred as Maintenance.

Advantages of the Waterfall Model
• Easy to explain to the user.
• Stages and activities are well defined.
• Helps to plan and schedule the project.
• Verification at each stage ensures early detection

of errors / misunderstanding.

Disadvantages of the Waterfall Model
• Requires that requirements are well-specified and
unchanging.
• Assumes a sequential flow, which real projects

rarely follow.
• Working version becomes available very late (after

coding).
• Developers may have to wait due to dependent

Software Process Models
tasks.
23
Conclusion of the Waterfall Model
• When the requirements are well understood, it is
reasonable to use this approach.

The Prototyping Model
• Often, a customer defines a set of general
objectives for software but does not identify
detailed input, processing, or output
requirements.
• In these, and many other situations, a prototyping

paradigm may offer the best approach.

• The prototyping paradigm begins with
requirements gathering.
• Developer and customer meet and define the

overall objectives for the software, identify
whatever requirements are known, and outline
areas where further definition is mandatory. A
"quick design" then occurs.

• The quick design leads to the construction of a
prototype.
• The prototype is evaluated by the customer/user

and used to refine requirements for the software
to be developed.

• Iteration occurs as the prototype is tuned to satisfy
the needs of the customer, while at the same time
enabling the developer to better understand what
needs to be done.

The Stages of Prototyping Model
Stage I: Requirements Definition/Collection
• Similar to the phase I of the Waterfall Model, but

not as comprehensive.
• The information collected is usually limited to a

subset of the complete system requirements.

Stage II: Design
• Once the initial layer of requirements information

is collected, or new information is gathered, it is
rapidly integrated into a new or existing design so
that it may be folded into the prototype.

Stage III: Prototype Creation/Modification
• The information from the design is rapidly rolled

into a prototype. This may mean the
creation/modification of paper information, new
coding, or modifications to existing coding.

Stage IV: Assessment
• The prototype is presented to the customer for

review.
• Comments and suggestions are collected from the

customer.

Stage V: Prototype Refinement
• Information collected from the customer is

digested and the prototype is refined.
• The developer revises the prototype to make it

more effective and efficient.

Stage VI: System Implementation
• In most cases, the system is rewritten once

requirements are understood. Sometimes, the
Iterative process eventually produces a working
system that can be the cornerstone for the fully
functional system.

Figure 2.3 : Prototyping Model

Validate
Verify
Figure 2.4 : The Waterfall Model with Prototyping

Validation Vs Verification
• Validation:
– Validation is concerned with checking that the system

will meet the customer’s actual needs.
• Verification:
– Verification is concerned with whether the system is

well-engineered, error-free, and so on. Verification will
help to determine whether the software is of high
quality, but it will not ensure that the system is useful.
Advantages of the Prototyping Model
• Misunderstandings, ambiguities and missing
functions may be identified.
• User sees the model at an early stage.
• The user may ask for the finished product via “a

few fixes” to the prototype.

Disadvantages of the Prototype Model
• Prototyping can lead to false expectations.
• Prototyping can lead to poorly designed systems.

Conclusion of the Prototype Model
• When requirements are not well understood, it
may be reasonable to use this approach.
• A prototype’s purpose is to understand

requirements. A better (good quality) product
must be subsequently developed.

Rapid Application Development (RAD) Model
• The main objective of RAD is to cut development

time and expense by involving users in every
phase of systems development.
• Because it is a continuous process, RAD allows the

development team to make necessary
modifications quickly, as the design evolves.

Rapid Application Development (RAD) Model
Figure 2.5 : Rapid Application Development Model

Advantages of Rapid Application Development
(RAD) Model
• Systems can be developed more quickly with
significant cost savings.
• Automated tools are used to facilitate construction

of the software.
• Suitable for those projects which are scalable.

Disadvantages of Rapid Application
Development (RAD) Model
• The system might work in the short time, but the
corporate and long term objectives of the system
might not be met.
• Accelerated time cycle might allow less time to

develop quality, consistency and design standards.

Conclusion of Rapid Application Development
(RAD) Model
• RAD can be attractive if a business application can
be modularized. However, the organization must
understand the possible risks.

Evolutionary Models
• These models emphasize that the systems should
evolve with time.
• Evolutionary models are iterative.
• They are characterized in a manner that enables

software engineers to develop increasingly more
complete versions of the software.

Evolutionary Models
• Some popular Evolutionary models are:
– The incremental Model
– The Spiral Model
– The WINWIN spiral Model
– The Concurrent Development Model

The Incremental Model
• The incremental model combines elements of the
Linear Sequential Model (applied repetitively)
with the iterative philosophy of prototyping.
• Delivers software in increments, each increment is

a working product and adds to the functionality of
the previous increment.

• When an incremental model is used, the first
increment is often a core product. That is, basic
requirements are addressed, but many
supplementary features (some known, others
unknown) remain undelivered. The core product is
used by the customer (or undergoes detailed
review).

• As a result of use and/or evaluation, a plan is
developed for the next increment.
• The plan addresses the modification of the core

product to better meet the needs of the customer
and the delivery of additional features and
functionality.
• This process is repeated following the delivery of

each increment, until the complete product is
produced.

Figure 2.6: The Incremental Model

• The incremental process model, like prototyping
and other evolutionary approaches, is iterative in
nature.
• But unlike prototyping, the incremental model

focuses on the delivery of an operational product
with each increment.

Advantages of Incremental Model
• Business pressure may be met.
• Technical risks may be managed.
• Fewer resources may be used to proceed.
• Client does not have to pay for entire software

together.

Disadvantages of Incremental Model
• Increments may be difficult to define.
• Software may be difficult to maintain.

Conclusion of Incremental Model
• When the “core” product is well understood and
increments can be easily defined, it is reasonable
to use this approach.

Spiral Model
• The spiral model, originally proposed by Boehm
(1988), is an evolutionary software process model
that couples the iterative nature of prototyping
with the controlled and systematic aspects of the
waterfall model.
• Spiral model is a combination of iterative

development process model and sequential linear
development model i.e. waterfall model with very
high emphasis on risk analysis.

Spiral Model
• It allows for incremental releases of the product,
or incremental refinement through each iteration
around the spiral.
• Using the spiral model, software is developed in a

series of incremental releases.
• During early iterations, the incremental release

might be a paper model or prototype. During later
iterations, increasingly more complete versions of
the engineered system are produced.

Spiral Model
Figure 2.7: Spiral Model

Advantages of Spiral Model
• Risks are resolved before they become
problematic.
• Good for large and mission-critical projects.
• Software is produced early in the software life

cycle.

Disadvantages of Spiral Model
• It can be costly model to use.
• Risk analysis requires highly specific expertise.
• Project success is highly dependent on the risk

analysis phase.
• Does not work well for smaller projects.

Conclusion of Spiral Model
• When risks are high and need to be
resolved, it is reasonable to use this
approach.

Task Regions of Spiral Model
• Customer Communication:
– Tasks required to establish effective communication
between developer and customer.
• Planning:
– Tasks required to define resources, timelines, and other
project related information.
• Risk Analysis:
– Tasks required to assess both technical and
management risks.

Task Regions of Spiral Model
• Engineering:
– Tasks required to build one or more representations of
the application.
• Construction and Release:

– Tasks required to construct, test, install, and provide
user support (e.g., documentation and training).
• Customer Evaluation:
– Tasks required to obtain customer feedback based on
evaluation of the software representations created
during the engineering stage and implemented during
the installation stage.
The WINWIN Spiral Model
• The spiral model discussed previously suggests a
framework activity that addresses customer
communication.
• The objective of this activity is to elicit project

requirements from the customer.
• In an ideal context, the developer simply asks the

customer what is required and the customer
provides sufficient detail to proceed.

• Unfortunately, this rarely happens. In reality, the
customer and the developer enter into a process of
negotiation, where the customer may be asked to
balance functionality, performance, and other
product or system characteristics against cost and
time to market.
• The best negotiations strive for a “win-

win” result.

Figure 2.8: The WINWIN Spiral Model

The Concurrent Development Model
• The concurrent process model can be represented
schematically as a series of major technical
activities, tasks, and their associated states.
• The concurrent model is often more appropriate

for system engineering projects where different
engineering teams are involved.

none
Modeling act ivit y
rep resent s t he st at e
Under o f a so f t ware eng ineering
act ivit y o r t ask
development
A wait ing
changes
Under review
Under
revision
Baselined
Done
Figure 2.9: The Concurrent Development Model

• Figure 2.9 provides a schematic representation of
one Software engineering task within the
modeling activity for the concurrent process
model.
• The activity – modeling- may be in any one of the

states noted at any given time.
• All activities exist concurrently but reside in

different states.

• For example, early in the project the
communication activity has completed its first
iteration and exists in the awaiting changes state.
The modeling activity which existed in the none
state while initial communication was completed
now makes a transition into underdevelopment
state.
• If, however, the customer indicates the changes in

requirements must be made, the modeling activity
moves from the under development state into the
awaiting changes state.

• The concurrent process model defines a series of
events that will trigger transitions from state to
state for each of the Software engineering
activities, actions, or tasks.

The Formal Methods Model
• The formal methods model encompasses a set of
activities that leads to formal mathematical
specification of computer software.
• Formal methods enable a software engineer to

specify, develop, and verify a computer-based
system by applying an accurate mathematical
notation.
• Ambiguity, incompleteness, and inconsistency can

be discovered and corrected more easily.

The Formal Methods Model
• Although the formal methods model offers the
promise of defect-free software but are rarely used
because:
– The development of formal models is currently quite

time consuming and expensive.
– Only few software developers have the necessary

background to apply formal methods, extensive training
is required.
– It is difficult to use these models as a communication

mechanism for technically unsophisticated customers.
The Rational Unified Process (RUP)
• RUP is a software engineering process in that it
describes a framework for activities leading to a
software product.
• According to Rational (developers of Rational Rose

and the Unified Modeling Language), RUP is like an
online mentor that provides guidelines, templates,
and examples for all aspects and stages of program
development.

Features of (RUP)
• It is a software process.
• It is the product sold by IBM (formerly by rational

software).
• It is supported by a large array of tools.
• It is configurable.
• It is regularly updated.

Three Perspectives of RUP
• Best Practices:
– A set of principles which are integrated into the process.
• Dynamic Perspective:
– Phases, iterations, milestones of the process which

change over time.
• Static perspective:
– The aspects of the process which are present in some

form in all dynamic phases: activities, artifacts,
workflows. Software Process Models 76
Phases of the RUP
• Inception Phase:
– The goal is to establish a business case for the system.
– Identify all external entities (people and systems) that

will interact with the system. Define these interactions.
– Use this information to access the contribution that the

system makes to the business.

Phases of the RUP
• Elaboration Phase:
– To understand the problem domain.
– To establish an architectural framework for the system.
– To develop the project plan.
– To identify key project risks.

Phases of the RUP
• Construction Phase:
– It is concerned with system design, programming and

testing.
– Parts of the system are developed in parallel and

integrated.

Phases of the RUP
• Transition Phase:
– Customer delivery and feedback.
• Production Phase:
– Software monitoring and support.

Component-based Software Engineering
(CBSE)
• This technique assumes that parts of the system
already exist. The system development process
focuses on integrating these parts rather than
developing them from scratch.
• The technical framework for a component-based

process model is provided by the object oriented
technologies.
• The object oriented paradigm emphasizes the

creation of classes that encapsulate both data and
the algorithms used to manipulate the data.
(CBSE)
• If properly designed and implemented, object-
oriented classes are reusable across different
applications and computer-based system
architectures.
• The Component-Based Development (CBD) model

incorporate many of the characteristics of the
spiral model. However, the component-based
development model composes applications from
pre-packaged software components (called
classes).

(CBSE)
Requirement Component Requirements System Design

Specification Analysis Modifications with Reuse
Development
System
and
Validation
Integration
Figure 2.10: Component-based Software Engineering

(CBSE)

Capability Maturity Model (CMM)
• The Capability Maturity Model (CMM) is a
methodology used to develop and refine an
organization's software development process.
• It is used to define key activities required at

different levels of process maturity.
• It establishes five process maturity levels that are

shown in figure 2.11.

Levels of Capability Maturity Model
(CMM)
Figure 2.11: Capability Maturity Model

(CMM)
• Level 1: Initial
– The software process is characterized as adhoc, and occasionally

even chaotic. Few processes defined.
• Level 2: Repeatable
– Basic project management processes established to track cost,

schedule and functionality.
• Level 3: Defined
– Process for both management and engineering is documented,

standardized and integrated.
(CMM)
• Level 4: Managed
– Detailed measure of the process and product quality

collected. Both are quantitatively understood and
controlled.
• Level 5: Optimizing
– Continuous process improvement enabled by

quantitative feedback and testing innovative ideas.

Software Engineering: Slide Set 02: Software Process Models

Uploaded by

Copyright:

Available Formats

You might also like

Software Engineering: Slide Set 02: Software Process Models

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering: Slide Set 02: Software Process Models

Uploaded by

Copyright:

Available Formats

SOFTWARE ENGINEERING

Slide Set 02: Software Process Models

• Each process model follows a particular life

Software Process Models 2

Software Software Software Software

Figure 2.1 : Software Process Activities

Software Process Models 3

Software Process Models 4

• The Generic Models are process frameworks

Software Process Models 5

 Type of project (scientific, embedded, business, etc.)

Software Process Models 6

• In "The Waterfall" approach, the whole process of

Software Process Models 7

Software Process Models 8

• All the methods and processes undertaken in

Software Process Models 9

Figure 2.2 : The Waterfall Model

Software Process Models 10

• All possible requirements of the system to be

• Requirements are set of functionalities and

Software Process Models 11

• The requirements are gathered from the end-user

Software Process Models 12

• Finally, a Requirement Specification document is

Software Process Models 13

• Before a starting for actual coding, it is highly

Software Process Models 14

• System Design helps in specifying hardware and

• The system design specifications serve as input for

Software Process Models 15

• On receiving system design documents, the work

• The system is first developed in small programs

Software Process Models 16

• Each unit is developed and tested for its

• Unit testing mainly verifies if the modules/units

Software Process Models 17

• As specified above, the system is first divided in

Software Process Models 18

• These units are integrated into a complete system

• After successfully testing the software, it is

• This phase of "The Waterfall Model" is virtually

• Generally, problems with the system developed

• Not all the problems come in picture directly but

Software Process Models 21

• Stages and activities are well defined.

• Helps to plan and schedule the project.

• Verification at each stage ensures early detection

Software Process Models 22

• Assumes a sequential flow, which real projects

• Working version becomes available very late (after

• Developers may have to wait due to dependent

Software Process Models 24

• In these, and many other situations, a prototyping

Software Process Models 25

• Developer and customer meet and define the

Software Process Models 26