Chapter - 2

Software Processes
 Software Process

• A software process is a coherent set of activities, procedures,

policies, organizational structures, constraints, technologies,
and artifacts that are needed to develop software products.
• The main goal of a software process is to produce quality
software with defined constraints.
• A software process is a set of ordered activities carried out to
produce a software product.
• An activity is a specified task performed to achieve the process
objectives.
• Each activity of software process involves tools and
technologies, procedures, and artifacts.

2
 Process, Project & Product

• A software process is a complex entity in which each activity is

executed with the supporting tools and techniques.
• A software project is an entity, with defined start and end, in which a
software process is being used.
• A successful project is the one that conforms with the project
constraints (cost, schedule, and quality criteria).
• A product is the outcome of a software project produced through
processes.
• A project can have more than one product called work products. A
work product is the intermediate outcome of processes.
• Software process, project, and products are interrelated to each other
for the development of software.

3
 Process, Project & Product

Process

Used
Converted
into Produces
Needs of client Project Product

Used in

Resources

Figure 2.1: Process, project and product

4
 Elements of Software Process

• Artifacts are tangible work products produced during the

development of software.
• Activity specifies the tasks to be carried out implicitly or
explicitly.
• Constraint refers to the criteria or condition that must be met
or possessed by a software product
• People are persons or stakeholders who are directly or
indirectly involved in the process.
• Tools and Technology provide technical support to the
methods or techniques to be used for performing the activities.

5
 Elements of Software Process

• Method or Technique specifies the way to perform an activity

using tools and technology to accomplish the activity.
• Organizational Structure specifies the team of people that
should be coordinated and managed during software
development.
• There are various software processes involved in software
development, change management, project management,
quality management, process improvements, and so on.

6
 Characteristics of Software Process

• Understandability • Rapidity
• Effectiveness • Repeatability
• Predictability • Quality
• Maintainability • Adoptability
• Reliability • Acceptability
• Changeability • Visibility
• Improvement • Supportability
• Monitoring and Tracking • etc.

7
 Process Classification

• Software processes may be classified as

– product development process
– project management process
– change management process
– process improvements
– quality management process

8
 Software Development Life Cycle

• Product development process is carried out as a series of certain

activities for software production. Each activity in the process is
also referred to as a phase.
• General activities include feasibility study, analysis, design, coding,
testing, implementation, and maintenance.
• Collectively, these activities are called the software development life
cycle (SDLC) or phased development life cycle or software life cycle
and each of these activities are called life cycle phase.
• The SDLC provides a framework that encompasses the activities
performed to develop and maintain software.
• Some of these models are waterfall, prototyping, spiral, incremental,
agile process, RUP process model, and so on.

9
 Phased Life Cycle Activities

Project
initiation
Maintenanc
Analysis
e

SDLC
Deployment Design

Testing Coding

Figure 2.3: Software Development Life Cycle (SDLC) activities

10
 Phased Life Cycle Activities

• Project Initiation
– The aim of project initiation is to study the existing system;
determine the feasibility of a new system; and define the
scope, key elements, and a plan for the successful
completion of the project.
– Project initiation involves preliminary investigation,
feasibility study, and a project plan.
– Preliminary investigation (PI) is the initial step that gives a
clear picture of what actually the physical system is.
– PI goes through problem identification, background of the
physical system, and the system proposal for a candidate
system.
11
 Phased Life Cycle Activities

• Project Initiation
– The purpose of the feasibility study is to determine whether the
implementation of the proposed system will support the mission
and objectives of the organization.
– Feasibility study ensures that the candidate system is able to satisfy
the user needs; promotes operational, effective use of resources;
and is cost effective.
– There are various types of feasibility study performed, such as
technical, economical, operational, and so on
– Feasibility report is prepared and submitted to the top-level
management. A positive report leads to project initiation.
– A detailed project plan is actually prepared after knowing the
requirements.
12
 Phased Life Cycle Activities

• Requirements Analysis
– Requirement analysis is the process of collecting factual
data, understanding the processes involved, defining the
problem, and providing a document for further software
development.
– Requirement analysis or requirements engineering is a
systematic approach to elicit, organize, and document the
requirements of a system.
– The requirement analysis phase consists of three main
activities: requirements elicitation, requirements
specification, and requirements verification and validation.

13
 Phased Life Cycle Activities
• Software Design
– Software design focuses on the solution domain of the project on
the basis of the requirement document prepared during the
analysis phase.
– The design phase has three aspects: architectural design,
physical design and logical design.
– Architectural design provides blueprint of the system.
– Physical design concentrates on identifying the different
modules or components in a system that interact with each other
to create the architecture of the system.
– In logical design, the internal logic of a module or component is
described in pseudo code or in an algorithmic manner.

14
 Phased Life Cycle Activities

• Coding
– The coding phase is concerned with the development of the
source code that will implement the design.
– This code is written in a formal language called a programming
language, such as assembly language, C++, Java, etc.
– Good coding efforts can reduce testing and maintenance tasks.
– Programs must be modular so that they can help in rapid
development, maintenance, and enhancements of the system.
– The programs written during the coding phase must be easy to
read and understand.

15
 Phased Life Cycle Activities

• Testing
– Before the deployment of the software, testing is performed to
remove the defects in the developed system
– Testing covers various errors at the requirements, design, and
coding phases.
– Testing is performed at different levels: unit testing, integration
testing, system testing, and acceptance testing.
– Various special tests are also performed to check the
functionality of the system, such as recovery testing,
performance testing, load testing, security testing, and so on.
– Testing is an important technique of software quality assurance.

16
 Phased Life Cycle Activities

• Deployment
– The purpose of software deployment is to make the software available
for operational use.
– It includes various activities to make a system available for assembly
and to transfer it to the customer site.
– Required resources are procured to operate at the customer site and
important information is collected for the deployment process.
– During deployment, all the programs files are loaded onto user’s
computer. After installation of all the modules of the system, training
of the user starts.
– Documentation is prepared in the form of a user manual or system
operation process which ensures the continuity of the system.

17
 Phased Life Cycle Activities

• Maintenance
– The maintenance phase comes after the software product is released
and put into operation through the deployment process.
– Software maintenance is performed to adapt to changes in a new
environment, correct bugs, and enhance the performance by adding
new features.
– The maintenance activities can be classified as adaptive (changes in
the software environment), perfective (new user requirements),
corrective (fixing errors), preventive (prevent problems in the future).
– The software will age in the near future and enter the retirement stage.
– In extreme cases, the software will be reengineered onto a different
platform.

18
Software Development Process Models

• Classical waterfall model

• Iterative waterfall model
• Prototyping model
• Incremental model
• Spiral model
• RAD model
• RUP process model
• Software reuse process
• Agile software development process

19
 Classical Waterfall Model

• The waterfall model is a classical development process model

proposed by R. W. Royce in 1970.
• In this model, software development proceeds through an
orderly sequence of transitions from one phase to the next in
order (like a waterfall).
• It is the simplest and the most widely used model in
development.
• This model produces standard outputs at the end of every
phase, which is called work products.
• This model was enhanced with a feedback process, which is
referred to as an iterative model.

20
 Classical Waterfall Model
Feasibility
study Feasibility report
Requirements
analysis Requirement document
Software
design Design document
Coding
Programs
Testing and
Integration Test reports
Deployment Release
reports
Operation and
Maintenance
Figure 2.4: Classical waterfall model
21
 Classical Waterfall Model

• Advantages
– The main advantage of the waterfall model is that it is easy to
understand and implement.
– Due to the straightforward organization of phases, it is fit for other
engineering process models, such as civil, mechanical, etc.
– It is a document-driven process that can help new people to transfer
knowledge.
– Milestones and deliverables at each stage can be used to monitor the
progress of the project.
– This model works well on large and mature products. It is not well
suited for small teams and projects.
– Where the requirements are well understood and the developers are
confident, the waterfall model works well.

22
 Classical Waterfall Model

• Disadvantages
– The model assumes that the requirements will not change during the project.
Sometimes, it is unrealistic to expect accurate requirements early in a project.
– It is very difficult to estimate the time and cost in the waterfall model.
– There may be difference of opinions among the specialists because there are
specialized teams for each individual phase.
– The people mentally ready to work in a phase will have to wait until its
previous phase is completed.
– Due to so much emphasis on documentation, sometimes people may become
irritated.
– Fixing the software and hardware technology early may create problems for
larger projects.
– There is no inherent risk management policy in this model.
– It is not well suited for small teams and projects.

23
 Iterative Waterfall Model
• The iterative waterfall model is an extended waterfall model
with backtracking at each phase to its preceding phases.
• The life cycle phases are organized similar to those in the
classical waterfall model. The only difference is
backtracking of phases on detection of errors at any stage.
• The errors can come at any stage of the development life
cycle.
• Once a defect is detected there is a need to go back to the
phase where it was introduced.
• On defect detection at the source, some of the work
performed during that phase and all the subsequent phases
may be revised.
24
 Iterative Waterfall Model
Feasibility
study Feasibility report
Requirements
analysis Requirement document
Software design
Design document
Coding
Programs
Testing and
integration Test reports
Deployment Release
reports
Operation and
Maintenance
Backtracking

Figure 2.5: Iterative waterfall model

25
 Iterative Waterfall Model

• On error detection at any phase, it may be required that the

preceding and succeeding phases be changed.
• Detecting and removing defects earlier in the process of
software development is called phase containment of errors.
• Removing defects in early phases of development reduces
testing and maintenance efforts.
• The iterative waterfall model is the most widely used model
and it is simple to apply it in projects.
• Still it is a document-driven model.

26
 Iterative Waterfall Model

• It is very difficult to manage changes between the phases.

• There is a possibility of blocking states, which can slow down
the productivity and efficiency of the process.
• Risks are not addressed in this model.
• This model is most suitable for simple projects where the work
products are well defined and their functioning is understood.

27
 Prototyping Model
• Prototyping is an alternative in which partial working software (i.e.
a prototype) is initially developed instead of developing the final
product.
• IEEE defines prototyping as “a type of development in which
emphasis is placed on developing prototypes early in the
development process to permit early feedback and analysis in
support of the development process.”
• Prototype development is a toy implementation, which provides a
chance to the customer to give feedback for final product
development.
• A prototype provides limited functionalities, low reliability, and
insufficient performance as compared to the actual software.
• A prototype helps customer to understand the requirements that can
further reduce the possibility of requirement changes.
28
 Prototyping Model
Information
gathering

Quick
design

Refine requirements Build prototype

Incorporate customer Customer

suggestions evaluation
Customer satisfied
Design

Coding

Testing

Deployment

Maintenance

Figure 2.6: Prototyping model

29
 Prototyping Model

• The prototype model is well suited for projects where

requirements are difficult to understand and the customer is
not confident in illustrating and clarifying the requirements.
• It fits best where the customer risks are related to the changing
requirements (software and hardware requirements) of the
projects.
• But this model requires exclusive involvement of the
customer, which is not always possible.
• Sometimes bad design decisions during prototype
development may propagate to the real product.

30
 Incremental Model

• The incremental model is an intuitive approach to the waterfall

model with fewer restrictions.
• The activities are performed in the same order as in the waterfall
model, but they are conducted in several iterations.
• Each iteration releases a fully functional work product by
providing additional functionalities in successive releases.
• The final iteration releases the complete product . The
requirements are functionally divided and prioritized according
to the needs of the customers.
• A blueprint of the product based on the prioritized requirements
is also designed, which describes dependency of tasks on each
other.
31
 Incremental Model

Iteration 1 Release 1
Design Coding Testing Deployment

Iteration 2 Release 2

Requirement Design Coding Testing Deployment Operation

analysis and
maintenance
… …
Iteration N Release N

Design Coding Testing Deployment

Figure 2.7: Incremental Model

32
 Incremental Model

• A project control list is prepared, describing the order of the tasks to be

performed and outcomes of the task to be released.
• Each task in the project control list is treated as a mini project.
• Each item in the list is a module, which is to be developed in increments.
• Each task is removed from the project control list and developed using the
waterfall model in a sequential manner.
• Each new release is integrated with the existing increments to provide
enhanced functionality with each delivered increment.
• The length of iterations is generally kept very short and fine. For example,
an iteration can be a duration of 6 weeks, 10 weeks, etc.
• The number of iterations depends upon the nature of the project and the
features it supports.

33
 Incremental Model

• The main advantage of the incremental model is the early

production of working software during the software life cycle.
• Because each module is tested thoroughly, there is little possibility
to change scope and requirements in the final software.
• Due to incremental development, testing and debugging of each
module become easier.
• This model is also helpful in handling risks (technical, requirements,
usability, etc.) because risky modules are identified and handled in a
separate iteration.
• This model is suitable for larger projects where requirements are
somewhat clear and which need phase-wise implementation.

34
 Incremental Model

• Mostly this model is used in web applications, object-oriented

development projects, and product-based companies.
• Also, it is widely used by many commercial software
companies and system vendors.
• Each phase of an iteration is rigid and does not overlap
another. Therefore, coordination between iterations is required
for better quality products.
• Sometimes, an initial upfront cost is required for parallel
development of various modules.

35
 Spiral Model

• The spiral model is an iterative software development

approach, which was proposed by Boehm in 1988.
• In this model, activities are organized as a spiral with many
loops.
• Each loop in the spiral represents a phase of software
development.
• The exact number of loops in the spiral is not fixed.
• The main focus of this model is identification and resolution
of potential risks (product risks, project risks, and process
risks).

36
Spiral Model

37
 Spiral Model

• Each loop in the spiral is split into four quadrants. Each of

these four quadrants is used for the development of each
phase.
– Determine objectives, alternatives, and constraints.
– Evaluate alternatives; identify and resolve risks.
– Develop, verify the next level product.
– Plan for the next phase.

38
 Spiral Model

• The redial dimension represents the cumulative cost incurred

so far for the development of phases in a project.
• The angular dimension indicates the progress made so far in
completing each cycle.
• It is considered a meta model because it incorporates the
features of all other models, which are the waterfall,
prototyping, incremental, simulation, and performance
models.
• The performance of prototype development is evaluated using
benchmarking tools, simulation models, and customer
feedback.

39
 Spiral Model

• The iterative and risk-driven approach of the spiral model is

widely used in software development.
• This model is most suitable for projects having high risks and
also for large, complex, and ambitious projects.
• The estimates (i.e. budget, schedule, etc.) get more realistic as
work progresses because important issues are discovered
earlier.

40
 RAD Model
• Rapid application development (RAD) model is a process
model, which involves incremental process model and
prototyping model.
• This model emphasizes on short development cycle and
modularization of software system into components, each of
which can be constructed by different teams.
• It is a high-speed version of the waterfall model, in which
rapid development is achieved by using component-based
development approach.
• This model helps to create a fully-functional system in short
duration (i.e., 60 to90 days), if the requirements are well
understood and project scope is constrained.

41
 RAD Model
Requirements

Project planning

Team #1 Team #2 Team #n

Modeling Modeling Modeling

•Business modeling •Business modeling •Business modeling
•Data modeling •Data modeling •Data modeling
•Process modeling •Process modeling •Process modeling

Construction Construction Construction

Unit testing Unit testing Unit testing

Integration and testing

Deployment

Figure 2.10 RAD model

42
 RAD Model
• RAD model starts with the business requirements, where
business problem and project scope are defined.
• Software project is partitioned into independent systems or
software components and these are developed by different
teams in parallel.
• Modeling is carried out using prototyping approach to refine
the data and process models, and finalize the system’s analysis
and design.
– Business modeling consists of the flow of information among business
functions in the project.
– Data modeling is refined into the set of objects, identifying their
attributes and relationships among objects.
– Process modeling is done to describe the implementation of the
business model.
43
 RAD Model
• In construction phase,
– reusable components are used for construction.
– Automatic application-generation tools are also used for construction.
– The code for some components is written from the scratch, if the
reusable components are neither available nor generated through
automatic tools.
• Unit testing is performed to ensure that the modules are
working properly.
• In integration and testing, components are assembled together
and then integration testing is performed as a whole.
• Software is deployed at the customer site, manual is prepared,
and training is provided to end users for demonstrating the
system operations.
44
 RAD Model
• RAD reduces the development time by using CBD approach.
• Business functions are modularized and, therefore,it is easier
to produce them.
• Implementation of RAD is suitable for well-understood,
simple, and GUI-based applications.
• Since this model is based on time constraints, commitment is
required from, both, end user and developer.
• Customer and end user’s involvement is required for regular
feedback and finalizing requirements.
• RAD model is extended to promote agile methods, where
products are produced in short time duration with strict
timelines.
45
 RUP Process Model

• The Rational Unified Process (RUP) is a use-case driven,

architecture-centric, iterative, and incremental process model.
• It is a process product, developed and maintained by
Rational® Software.
• The RUP focuses on creating and maintaining models rather
than documentation.
• It is derived from Unified Modeling Language (UML), which
is an industry-standard language that helps to clearly
communicate requirements, architectures, and designs.
• The RUP is supported by tools which automate most of the
activities of the process.

46
RUP Process Model

47
 RUP Process Model

• Inception phase
– establishes the business case for the system and delimit the
project scope.
– This phase produces vision document of the project, initial
use-case model, initial risk assessment, business model,
and a project plan showing the phases and iterations.
– At this stage, customers will be clear with their
requirement and life cycle objectives milestone will be
produced.
• Elaboration phase- analyzes the problem domain, establish
an architectural framework, develop the project plan, and
eliminate the highest risk elements of the project.
48
 RUP Process Model

• Construction phase:
– All application features are developed, integrated, and thoroughly
tested.
– This phase also focuses on the user manuals and the current
beta release details.
• Transition phase:
– The purpose of the transition phase is to move the software
product to the user community for working.
– This phase includes several iterations, including beta
releases, general availability releases, as well as bug-fix
and enhancement releases.

49
 Component-based Development Model
• Component-based development (CBD) is evolved to promote reusability
by using commercially off-the-shelf (COTS) components.
• The CBSE process begins with requirements to understand the problem.
• Architectural design is prepared to find the possible solution which exists
in the form of reusable approach.
• Domain engineering is a mechanism to identify, select, and reuse reusable
components in reuse repository.
• Component engineering is done to discover qualified components from
reuse repository, adapt configurable component, and integrate with other
components.
• Integration testing is carried out to check all interfaces and component
assembly.
• The produced software system is deployed, updated, and stored into the
repository for future reuse.

50
 Component-based Development Model

Domain engineering
Reuse repository

Component
qualification
Component
update
Component
Architectur adaption
Testing Deployment
Requirements al design
Component
integration

Component engineering

Figure 2.9: Component-based development process

51
 Component-based Development Model
• There are various CBD models such asY model, V model, X
model, CBSD dual life cycle model, KNOTmodel, and W
model.
• The CBD models help to provide a cost effective, fast, and
modular approach for developing complex software with
reduced delivery time.
• The CBD models require initial investments for hiring or
developing reusable components, procure skilled engineers,
regular component updates, optimal component selection, and
component certification.
• The models are mostly suitable for object-oriented software
development which supports the components-based
architecture such as CORBA, COM/DCOM, and so on.
52
 Computer-Aided Software Engineering
(CASE)
• CASE is a tools support for software development, project
management, and maintenance activities.
• It is the integration of automated software-based modelling
tools into the software development process.
• It is software tools for enterprise support consisting of project
management, systems development, documentation and
maintenance.
• These tools are well tested which assist to produce desired
results and uncover flaws at any stage of development.

53
 CASE Scope

• Case tools are broadly used in the following areas to speed up

the development process in effective way.
 Requirement engineering
 Software design
 Model generation (data model, data flow diagram etc.)
 Process description
 User interface design
 Code generation
 Test case generation
 Document generation

54
 CASE Scope

 Reverse engineering
 Configuration management
 Version change control
 Project management
 Screen and report generation
 Project planning, etc.

55
 Classification of CASE Technology

• The initial classification was done on the basis of programming

language, structure-centered based on the concept of environment
generation, toolkit environments and methods for developing software
systems.
• The most common classification is based on a framework, which has
three parts[2]:
– Tools: Supports specific tasks in systems development such as, editing,
programming and so on.
– Workbenches: Supports one or more activities of software life cycle that
support a large part of the software process such as, business planning,
GUI Development etc.
– Environment : Toolkits, which are integrated collections of products,
language-centered, integrated, fourth generation environments or
process-centered environments.
56
 CASE Tools

• CASE tools are generally classified into the three categories :

– Upper CASE Tools: Support the development activities at
the early stages of software development process. e.g.
report and form generators, modeling tools.
– Lower CASE Tools: Deal with the implementation and
integration tasks in software development. e.g. database
schema generation, program generation.
– Integrated CASE Tools : Support both early and later stages
of software development. e.g. repository.

57
 CASE Workbenches

• CASE workbench is a set of tools that supports particular

phase in software process by integrating several tools in a
single application.
• CASE workbenches are generally classified into the two
classes :
– Open Workbenches: Control integration mechanisms are
devised and the data integration protocols are open to all.
– Closed Workbenches: The control and data integration
protocols are proprietary.

58
CASE Environments