Software process models

Chapter 2 Software Processes 1

The software process
• A structured set of activities required to develop a
software system.
• Many different software processes but all involve:
• 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.
• A software process model is an abstract representation of a
process. It presents a description of a process from some
particular perspective.
3
Software process descriptions
• When we describe and discuss processes, we usually
talk about the activities in these processes such as
specifying a data model, designing a user
interface, etc. and the ordering of these
activities.
• Process descriptions may also include:
• Products, which are the outcomes of a process activity;
• Roles, which reflect the responsibilities of the people involved
in the process;
• Pre- and post-conditions, which are statements that are
true before and after a process activity has been enacted or a
product produced.
Chapter 2 Software Processes 4
 Prescriptive Models

• Prescriptive process models advocate an orderly approach to

software engineering
That leads to a few questions …
• If prescriptive process models strive for structure and order, are
they inappropriate for a software world that thrives on change?
• Yet, if we reject traditional process models (and the order they
imply) and replace them with something less structured, do we
make it impossible to achieve coordination and coherence in
software work?

These slides are designed to

accompany Software
Engineering: A Practitioner’s
Approach, 8/e (McGraw-Hill,
2014). Slides copyright 2014 by 6
Roger Pressman.
Plan-driven and agile processes
• Plan-driven processes are processes where all of the
process activities are planned in advance and progress
is measured against this plan.
• In agile processes, planning is incremental, and it is
easier to change the process to reflect changing
customer requirements.
• In practice, most practical processes include elements
of both plan-driven and agile approaches.
• There are no right or wrong software processes.

Chapter 2 Software Processes 7

Phases of a problem-solving loop

Chapter 2 Software Processes 8

Phases within phases

Chapter 2 Software Processes 9

Software process models
• The waterfall model
• Plan-driven model. Separate and distinct phases of specification
and development.
• Incremental development
• Specification, development and validation are interleaved. May be
plan-driven or agile.
• Integration and configuration
• The system is assembled from existing configurable components.
May be plan-driven or agile.
• In practice, most large systems are developed using a
process that incorporates elements from all of these models.
Chapter 2 Software Processes 10
 The Waterfall
Model
Communication
project initiation Planning
requirement gathering estimating Modeling
scheduling
analysis Construction
tracking
design Deployment
code
test delivery
support
f eedback

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 8/e
11
(McGraw-Hill, 2014). Slides copyright 2014 by
The waterfall model/e classic life cycle/Linear
Sequential Model

Chapter 2 Software Processes 12

Waterfall Model

Chapter 2 Software Processes 13

Software requirements analysis.
• The requirements-gathering process is intensified and
focused specifically on software.

• To understand the nature of the program(s) to be built,

the software engineer ("analyst") must understand the
information domain for the software, as well as the
required function, behavior, performance, and interface.
• Requirements for both the system and the software are
documented and reviewed with the customer.

30/10/2014 Chapter 2 Software Processes 14

Design
• Software design is actually a multistep
process that focuses on four distinct
attributes of a program: data structure,
software architecture, interface
representations, and procedural
(algorithmic) detail.
• The design process translates requirements
into a representation of the software that
can be assessed for quality before coding
begins.
• Like requirements, the design is
30/10/2014
documented and becomes part of the
Chapter 2 Software Processes 15
software configuration.
Code generation.
• The design must be translated into a machine-readable
form.
• The code generation step performs this task.
• If design is performed in a detailed manner, code
generation can be accomplished mechanistically.

Chapter 2 Software Processes 16

Testing.
• Once code has been generated, program testing begins.
• The testing process focuses on the logical internals of
the software, ensuring that all statements have been
tested, and on the functional externals; that is,
conducting tests to uncover errors and ensure that
defined input will produce actual results that agree with
required results.

30/10/2014 Chapter 2 Software Processes 17

Support.
• Software will undoubtedly undergo change after it is
delivered to the customer (a possible exception is
embedded software).
• Change will occur because errors have been
encountered,
• because the software must be adapted to
accommodate changes in its external environment (e.g.,
a change required because of a new operating system
or peripheral device), or because the customer requires
functional or performance enhancements.

30/10/2014 Chapter 2 Software Processes 18

Waterfall model phases
• There are separate identified phases in the waterfall
model:
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
• The main drawback of the waterfall model is the
difficulty of accommodating change after the process is
underway. In principle, a phase has to be complete
before moving onto the next phase.
Chapter 2 Software Processes 19
Waterfall model problems
• Inflexible partitioning of the project into distinct stages
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.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
• In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.
30/10/2014 Chapter 2 Software Processes 20
Relative effort distribution among
different phases of a typical product.

Chapter 2 Software Processes 21

Iterative Waterfall Model

Chapter 2 Software Processes 22

Distribution of effort for various
phases in the iterative waterfall
model.

Chapter 2 Software Processes 23

To Think----
•Describe the Waterfall Model and its Phases:
•Explain each phase of the Waterfall model in detail. How does the process flow from one
phase to the next, and what are the main activities and deliverables in each phase?

•Discuss the Advantages and Disadvantages of the Waterfall Model:

•What are the benefits of using the Waterfall model for software development? Conversely,
what are its limitations and potential issues? Provide examples or scenarios where the
Waterfall model might be particularly effective or problematic.

•Compare and Contrast the Waterfall Model with Agile Methodologies:

•How does the Waterfall model differ from Agile methodologies in terms of flexibility, process,
and response to changes? Discuss how each approach handles requirements changes,
project feedback, and iterative development. Which situations or project types might be
better suited for one methodology over the other?