Software process models

ISE 2019
• There are many software processes but all must
include four activities that are fundamental to
software engineering:
• SOFTWARE SPECIFICATION: The functionality of
the software and constraints on its operation
must be defined.
• SOFTWARE SPECIFICATION & IMPLEMENTATION:
The software to meet the specification must be
provided.
• SOFTWARE VALIDATION: The software must be
validated to ensure that it does what the
customer wants.
• SOFTWARE EVOLUTION: The software must
evolve to meet changing customer needs.
 Software process models
• The waterfall model
– Plan-driven model. Separate and distinct phases of specification
and development.
• Incremental development
– This approach interleaves the activities of specification,
development and validation . The system is developed as a
series of versions (increments) with each version adding
functionality to the previous version.
• Reuse oriented software engineering
– The system is assembled from existing configurable
components. Focuses on integrating these components into a
system rather than developing from scratch.
– In practice, most large systems are developed using a process
that incorporates elements from all of these models.
The waterfall model
 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.
 Waterfall model phases
• The principal stages of the waterfall model directly reflect
the fundamental development
• activities:
• 1. Requirements analysis and definition The system’s
services, constraints, and goals are established by
consultation with system users. They are then defined in
detail and serve as a system specification.
• 2. System and software design The systems design process
allocates the requirements to either hardware or software
systems by establishing an overall system
• architecture. Software design involves identifying and
describing the fundamental software system abstractions
and their relationships.
 Waterfall model phases
• 3.Implementation and unit testing During this stage, the software
design is realized as a set of programs or program units. Unit testing
involves verifying that each unit meets its specification.
• 4. Integration and system testing The individual program units or
programs are integrated and tested as a complete system to ensure
that the software requirements have been met. After testing, the
software system is delivered to the customer.
• 5. Operation and maintenance this is the longest life cycle phase.
The system is installed and put into practical use. Maintenance
involves correcting errors which were not discovered in earlier
stages of the life cycle, improving the implementation of system
units and enhancing the system’s services as new requirements are
discovered.
 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.
Incremental development
 Incremental development
• Incremental development is based on the idea of
developing an initial implementation, exposing this to user
comment and evolving it through several versions until an
adequate system has been developed (Figure).
Specification, development, and validation activities are
interleaved rather than separate, with rapid feedback
across activities.

• Incremental development reflects the way that we solve

problems, rarely work out a complete problem solution in
advance but move toward a solution in a series of steps,
backtracking when we realize that we have made a mistake.
By developing the software incrementally, it is cheaper and
easier to make changes in the software as it is being
developed.
 Incremental development
• Each increment or version of the system
incorporates some of the functionality that is
needed by the customer. Generally, the early
increments of the system include the most
important or most urgently required
functionality. This means that the customer can
evaluate the system at a relatively early stage in
the development to see if it delivers what is
required. If not, then only the current increment
has to be changed and, possibly, new
functionality defined for later increments.
 The Incremental Model

• •Software separated into different “increments”

– -complete working portions

• •Focus on delivery of operational product with

each increment -can be evaluated

• •Useful when insufficient staff and can be

planned to manage technical risks,
• e.g. waiting for new hardware
The Incremental Model
Incremental development benefits
• The cost of accommodating changing customer
requirements is reduced.
– The amount of analysis and documentation that has to be
redone is much less than is required with the waterfall
model.
• It is easier to get customer feedback on the
development work that has been done.
– Customers can comment on demonstrations of the
software and see how much has been implemented.
• More rapid delivery and deployment of useful software
to the customer is possible.
– Customers are able to use and gain value from the
software earlier than is possible with a waterfall process.
 Incremental development problems
• The process is not visible.
– Managers need regular deliverables to measure
progress. If systems are developed quickly, it is not
cost-effective to produce documents that reflect every
version of the system.
• System structure tends to degrade as new
increments are added.
– Unless time and money is spent on refactoring to
improve the software, regular change tends to corrupt
its structure. Incorporating further software changes
becomes increasingly difficult and costly
Reuse-oriented software
engineering
 Reuse-oriented software
engineering
• 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.
• Reuse is now the standard approach for
building many types of business system
 Reuse-oriented software
engineering
• In the majority of software projects, there is
some software reuse. This often happens
informally when people working on the
project know of designs or code that are
similar to what is required. They look for
these, modify them as needed, and
incorporate them into their system.
 Reuse-oriented software
engineering
• 1.Component analysis Given the requirements
specification, a search is made for components to
implement that specification. Usually, there is no
exact match and the components that may be
used only provide some of the functionality
required.
• 2. Requirements modification During this stage,
the requirements are analyzed using information
about the components that have been
discovered. They are then modified to reflect the
available components. Where modifications are
impossible, the component analysis activity may
 Reuse-oriented software
engineering
• 3.System design with reuse During this phase,
the framework of the system is designed or an
existing framework is reused. The designers take
into account the components that are reused and
organize the framework to cater for this. Some
new software may have to be designed if
reusable components are not available.
• 4. Development and integration Software that
cannot be externally procured is developed, and
the components and COTS systems are integrated
to create the new system. System integration, in
this model, may be part of the development
 Reuse-oriented software
engineering
• There are three types of software component
that may be used in a reuse-oriented process:
• 1. Web services that are developed according
to service standards and which are available
for remote invocation.
• 2. Collections of objects that are developed as
a package to be integrated with a component
framework such as .NET or J2EE.
• 3. Stand-alone software systems that are
configured for use in a particular environment.
 Process activities
• Real software processes are inter-leaved
sequences of technical, collaborative and
managerial activities with the overall goal of
specifying, designing, implementing and
testing a software system.
• The four basic process activities of
specification, development, validation and
evolution are organized differently in different
development processes. In the waterfall
model, they are organized in sequence,
 Software specification
• Software specification or requirements engineering is the process of
understanding and defining what services are required from the system
and identifying the constraints on the system’s operation and
development. Requirements engineering is a particularly critical stage of
the software process as errors at this stage inevitably lead to later
problems in the system design and implementation.

• Requirements engineering process

– Feasibility study
• Is it technically and financially feasible to build the system?
– Requirements elicitation and analysis
• What do the system stakeholders require or expect from the
system?
– Requirements specification
• Defining the requirements in detail
– Requirements validation
• Checking the validity of the requirements
 Software specification
• There are four main activities in the requirements engineering process:
• 1. Feasibility study An estimate is made of whether the identified user
needs may be satisfied using current software and hardware technologies.
The study considers whether the proposed system will be cost-effective
from a business point of view and if it can be developed within existing
budgetary constraints. A feasibility study should be relatively cheap and
quick. The result should inform the decision of whether or not to go ahead
with a more detailed analysis.
• 2. Requirements elicitation and analysis This is the process of deriving the
system requirements through observation of existing systems, discussions
with potential users and procurers, task analysis, and so on. This may
involve the development of one or more system models and prototypes.
These help you understand the system to be specified.
 Software specification
• 3. Requirements specification Requirements
specification is the activity of translating the
information gathered during the analysis activity into a
document that defines a set of requirements. Two
types of requirements may be included in this
document. User requirements are abstract statements
of the system requirements for the customer and end-
user of the system; system requirements are a more
detailed description of the functionality to be provided.

• 4. Requirements validation This activity checks the

requirements for realism, consistency, and
completeness. During this process, errors in the
requirements document are inevitably discovered. It
must then be modified to correct these problems.
Software specification
 Software design and
implementation
• The process of converting the system
specification into an executable system.
• Software design
– Design a software 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.
Software design and
implementation
 Software design and
implementation
• The implementation stage of software
development is the process of converting a
system specification into an executable system.
• A software design is a description of the
structure of the software to be implemented, the
data models and structures used by the system,
the interfaces between system components and,
sometimes, the algorithms used.
• Designers do not arrive at a finished design
immediately but develop the design iteratively.
They add formality and detail as they develop
their design with constant backtracking to correct
 Software design and
implementation
• 1. Most software interfaces with other software
systems. These include the operating system,
database, middleware, and other application
systems. These make up the ‘software platform’,
the environment in which the software will
execute. Information about this platform is an
essential input to the design process, as designers
must decide how best to integrate it with the
software’s environment.
• 2. The activities in the design process vary,
depending on the type of system being developed.
• Four activities that may be part of the design
 Software design and
implementation
• 1. Architectural design, where you identify the
overall structure of the system, the principal
components (sometimes called sub-systems or
modules), their relationships, and how they are
distributed.

• 2. Interface design, where you define the

interfaces between system components. With a
precise interface, a component can be used
without other components having to know how it
is implemented. Once interface specifications are
 Software design and
implementation
• Component design, where you take each
system component and design how it will
operate.

• Database design, where you design the

system data structures and how these are to
be represented in a database.
 Software validation
• Verification and validation (V & V) is intended
to show that a system conforms to its
specification and meets the requirements of
the system customer.
• Involves checking and review processes and
system testing.
• System testing involves executing the system
with test cases that are derived from the
specification of the real data to be processed
by the system.
Stages of testing
 Testing stages
• Development or component testing
– Individual components are tested independently;
– Components may be functions or objects or
coherent groupings of these entities.
• System testing
– Testing of the system as a whole. Testing of
emergent properties is particularly important.
• Acceptance testing
– Testing with customer data to check that the
system meets the customer’s needs.
• When a plan-driven software process is used (e.g., for critical systems
development),testing is driven by a set of test plans. An independent team of testers
works from these pre-formulated test plans, which have been developed from the
system specification and design. Figure 2.7 illustrates how test plans are the link
between testing and development activities. This is sometimes called the V-model of
development (turn it on its side to see the V).
• Acceptance testing is sometimes called ‘alpha testing’. Custom systems are developed
for a single client. The alpha testing process continues until the system developer and
the client agree that the delivered system is an acceptable implementation of the
requirements.
• When a system is to be marketed as a software product, a testing process called ‘beta
testing’ is often used. Beta testing involves delivering a system to a number of
potential customers who agree to use that system. They report problems to the
system developers. This exposes the product to real use and detects errors that may
not have been anticipated by the system builders. After this feedback, the system is
modified and released either for further beta testing or for general sale.
 Software Evolution
• The flexibility of software systems is one of the
main reasons why more and more software is
being incorporated in large, complex systems.
Once a decision has been made to manufacture
hardware, it is very expensive to make changes to
the hardware design. However, changes can be
made to software at any time during or after the
system development. Even extensive changes are
still much cheaper than corresponding changes to
system hardware.
• It is more realistic to think of software
engineering as an evolutionary process where
software is continually changed over its lifetime
in response to changing requirements and
 Points to remember
• Software processes are the activities involved
in producing a software system. Software
process models are abstract representations
of these processes.
• General process models describe the
organization of software processes. Examples
of these general models include the ‘waterfall’
model, incremental development, and reuse-
oriented development.
• Requirements engineering is the process of
 Points to remember
• Design and implementation processes are
concerned with transforming a requirements
specification into an executable software
system.
• Software validation is the process of checking
that the system conforms to its specification
and that it meets the real needs of the users
of the system.
• Software evolution takes place when you
change existing software systems to meet new
 Coping with change
• Change is inevitable in all large software projects.
The system requirements change as the business
procuring the system responds to external
pressures and management priorities change. As
new technologies become available, new design
and implementation possibilities emerge.
Therefore whatever software process model is
used, it is essential that it can accommodate
changes to the software being developed.
• Change adds to the costs of software
development because it usually means that work
 Coping with change
• Change is inevitable in all large software
projects.
– Business changes lead to new and changed system
requirements
– New technologies open up new possibilities for
improving implementations
– Changing platforms require application changes
• Change leads to rework so the costs of change
include both rework (e.g. re-analysing
requirements) as well as the costs of
 Reducing the costs of rework
• Change avoidance, where the software process includes
activities that can anticipate possible changes before
significant rework is required.
• For example, a prototype system may be developed to show some key
features of the system to customers. They can experiment with the
prototype and refine their requirements before committing to high software
production costs.
• Change tolerance, where the process is designed so that
changes can be accommodated at relatively low cost.
– This normally involves some form of incremental
development. Proposed changes may be implemented in
increments that have not yet been developed. If this is
impossible, then only a single increment (a small part of the
system) may have be altered to incorporate the change.
• Two types of coping with change and changing system
requirements are:
 Software prototyping
• A prototype is an initial version of a system used
to demonstrate concepts and try out design
options. and find out more about the problem
and its possible solutions. Rapid, iterative
development of the prototype is essential so that
costs are controlled and system stakeholders can
experiment with the prototype early in the
software process.
• A prototype can be used in:
– The requirements engineering process to help with
requirements elicitation and validation;
– In design processes to explore options and develop a
 Benefits of prototyping
• Improved system usability.
• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.
 The process of prototype
development
• System prototypes allow users to see how well the
system supports their work. They may get new ideas
for requirements, and find areas of strength and
weakness in the software. They may then propose new
system requirements. Furthermore, as the prototype is
developed, it may reveal errors and omissions in the
requirements that have been proposed.
• A system prototype may be used while the system is
being designed to carry out design experiments to
check the feasibility of a proposed design. For example,
a database design may be prototyped and tested to
check that it supports efficient data access for the most
common user queries. Prototyping is also an essential
part of the user interface design process.
The process of prototype
development
 The process of prototype
development
• The objectives of prototyping should be made explicit from
the start of the process. These may be to develop a system
to prototype the user interface, to develop a system to
validate functional system requirements, or to develop a
system to demonstrate the feasibility of the application to
managers. The same prototype cannot meet all objectives.
If the objectives are left unstated, management or end-
users may misunderstand the function of the prototype.

• The next stage in the process is to decide what to put into

and, perhaps more importantly, what to leave out of the
prototype system. To reduce prototyping costs and
accelerate the delivery schedule, you may leave some
functionality out of the prototype. You may decide to relax
non-functional requirements such as response time and
memory utilization. Error handling and management may
 The process of prototype
development
• The final stage of the process is prototype
evaluation. Provision must be made during
this stage for user training and the prototype
objectives should be used to derive a plan for
evaluation. Users need time to become
comfortable with a new system and to settle
into a normal pattern of usage. Once they are
using the system normally,they then discover
requirements errors and omissions.
 Throw-away prototypes
• Developers are sometimes pressured by
managers to deliver throwaway prototypes,
particularly when there are delays in
delivering the final version of the software.
• 1. It may be impossible to tune the prototype
to meet non-functional requirements, such as
performance, security, robustness, and
reliability requirements, which were ignored
during prototype development.
 Throw-away prototypes
• 2. Rapid change during development
inevitably means that the prototype is
undocumented. The only design specification
is the prototype code. This is not good enough
for long-term maintenance.
• 3. The changes made during prototype
development will probably have degraded the
system structure. The system will be difficult
and expensive to maintain.
• 4. Organizational quality standards are
 Incremental delivery
• 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 system increments have been identified, the

requirements for the services to be delivered in the
first increment are defined in detail and that increment
is developed. During development, further
requirements analysis for later increments can take
place but requirements changes for the current
increment are not accepted.
 Incremental delivery
• Once an increment is completed and
delivered, customers can put it into service.
This means that they take early delivery of
part of the system functionality. They can
experiment with the system and this helps
them clarify their requirements for later
system increments. As new increments are
completed, they are integrated with existing
increments so that the system functionality
improves with each delivered increment.
• Incremental development
– Develop the system in increments and evaluate
each increment before proceeding to the
development of the next increment;
– Normal approach used in agile methods;
– Evaluation done by user/customer proxy.
• Incremental delivery
– Deploy an increment for use by end-users;
– More realistic evaluation about practical use of
software;
 Incremental delivery advantages
• Customer value can be delivered with each
increment so system functionality is available
earlier.
• Early increments act as a prototype to help
elicit requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to
receive the most testing.
 Boehm’s spiral model
• 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. Thus, the innermost loop might be
concerned with system feasibility, the next loop
with requirements definition, the next loop with
system design, and so on.
• No fixed phases such as specification or design -
loops in the spiral are chosen depending on what
is required.
• Risks are explicitly assessed and resolved
Boehm’s spiral model of the software
process
 Spiral model sectors
• Each loop in the spiral is split into four sectors:

• 1. Objective setting Specific objectives for that phase of the

project are defined. Constraints on the process and the
product are identified and a detailed management plan is
drawn up. Project risks are identified. Alternative strategies,
depending on these risks, may be planned.

• 2. Risk assessment and reduction For each of the identified

project risks, a detailed analysis is carried out. Steps are
taken to reduce the risk. For example, if there is a risk that
the requirements are inappropriate, a prototype system
may be developed.
 Spiral model sectors
• 3.Development and validation
A development model for the system is chosen which can be
any of the generic models.

• 4.Planning
The project is reviewed and a decision
made whether to continue with a further loop
of the spiral. If it is decided to continue, plans
are drawn up for the next phase of the project.