Software

Processes &
Software
Process Models
M A RYA M K H A L I D
D E PA RT M E N T O F C O M P U T E R S C I E N C E ,
B A H R I A U N I V E R S I T Y, I S L A M A B A D
Software Processes

Coherent sets of activities for specifying,

designing, implementing and testing
software systems

SOFTWARE ENGINEERING 2
Objectives
To introduce software process models

To describe a number of different process models and

when they may be used

To describe outline process models for requirements

engineering, software development, testing and evolution

SOFTWARE ENGINEERING 3
Topics covered
Software process models

Process activities

Coping with change

SOFTWARE ENGINEERING 4
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.

SOFTWARE ENGINEERING 5
 Software A software process model is an abstract
representation of a process. It presents a
Process description of a process from some
Model particular perspective.

SOFTWARE ENGINEERING 6
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.

SOFTWARE ENGINEERING 7
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.
SOFTWARE ENGINEERING 8
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 (Reuse-oriented software engineering)

◦ The system is assembled from existing 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.

SOFTWARE ENGINEERING 9
SOFTWARE ENGINEERING 10
The waterfall
model

SOFTWARE ENGINEERING 11
Waterfall model phases
There are separate identified phases in the waterfall model:

1. Requirements analysis and definition

2. System and software design
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance

SOFTWARE ENGINEERING 12
Drawback of Waterfall model
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.

SOFTWARE ENGINEERING 13
 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
Waterfall requirements are well-understood and changes will be
fairly limited during the design process.
model ◦ Few business systems have stable requirements.

problems 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.

SOFTWARE ENGINEERING 14
 Waterfall model
ADVANTAGES DISADVANTAGES
 It is a linear and segmental model.
 It is difficult to define all
 Due to its simple and sequential nature it is easy
to understand even by the inexperienced
requirements at the beginning of the
programmer. project.
 Because of the non existing inter dependencies  The model is not suitable for
of the different stages, no complicated accommodating any change.
coordination among the team members is
necessary.
 A working version of the system is
 Documentation makes the process visible so not seen until late in the project’s life.
managers can monitor progress against the
development plan
SOFTWARE ENGINEERING 15
When to use Waterfall Model
This model is used
only when the
Product definition is Technology is
requirements are very
stable. understood.
well known, clear and
fixed.

There are no Ample resources with

ambiguous required expertise are
requirements available freely

SOFTWARE ENGINEERING 16
Incremental development
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 development of an increment is started, the requirements are
frozen though requirements for later increments can continue to
evolve
SOFTWARE ENGINEERING 17
Incremental
development

SOFTWARE ENGINEERING 18
SOFTWARE ENGINEERING 19
Incremental model
The model is used in the following scenarios:
• A new technology is being used and learnt by the development
team while working on the project
• Resources with needed skill set are not available and planned to
be used on contract basis for specific iterations
• There are some high risk features and goals which may change in
the future

SOFTWARE ENGINEERING 20
 Incremental development benefits

The cost of accommodating changing It is easier to get customer feedback on More rapid delivery and deployment of
customer requirements is reduced. the development work that has been useful software to the customer is
done. possible.
The amount of analysis and Customers can comment on Customers are able to use and
documentation that has to be demonstrations of the gain value from the software
redone is much less than is software and see how much earlier than is possible with a
required with the waterfall has been implemented. waterfall process.
model.

SOFTWARE ENGINEERING 21
Incremental development problems

The process is not visible. System structure tends to degrade

as new increments are added.
Managers need regular deliverables to Unless time and money is spent on
measure progress. If systems are refactoring to improve the software,
developed quickly, it is not cost-effective regular change tends to corrupt its
to produce documents that reflect every structure. Incorporating further software
version of the system. changes becomes increasingly difficult
and costly.

SOFTWARE ENGINEERING 22
 Pros and Cons: (Incremental Model)
ADVANTAGES DISADVANTAGES
 Generates working software quickly and  Needs good planning and design.
early during the software life cycle
 Useful when staffing is unavailable for a
 Needs a clear and complete
complete implementation definition of the whole system
 More flexible - less costly to change scope and before it can be broken down and
requirements. built incrementally.
 Easier to test and debug during a smaller iteration.  Total cost is higher than waterfall
 Easier to manage risk
 because risky pieces are identified and handled during its
iteration.

SOFTWARE ENGINEERING 23
When to use Incremental Model
The requirements of Major requirements
There is a need to get
the complete system must be defined;
a product to the
are clearly defined however, some details
market early.
and understood. can evolve with time.

Resources with There are some high

A new technology is
needed skill set are risk features and
being used
not available goals

SOFTWARE ENGINEERING 24
 Integration and configuration
Based on systematic reuse where systems are integrated from existing components or
COTS (Commercial-off-the-shelf) systems.

Process stages
1. Component analysis;
2. Requirements modification;
3. System design with reuse;
4. Development and integration.

Reuse is now the standard approach for building many types of business systems.
The move to reuse-based development has been in response to demands for lower software
production and maintenance costs, faster delivery of systems, and increased software
quality
SOFTWARE ENGINEERING 25
 Application system reuse
◦ The whole of an application system may be reused by
incorporating it without changing into other systems or by
configuring the application for different customers.
Alternatively, application families that have a common
Reuse- architecture, but which are tailored for specific customers,
may be developed.
oriented Object and function reuse
software ◦ Software components that implement a single function, such
as a mathematical function, or an object class may be reused.
engineering ◦ Based around standard libraries. You reuse the classes and
functions in these libraries by linking them with newly
developed application code.
◦ Particularly effective approach in areas such as mathematical
algorithms and graphics, where specialized expertise is
needed to develop efficient objects and functions.

SOFTWARE ENGINEERING 26
 Component reuse
◦ Components of an application, ranging in size from subsystems
to single objects, may be reused.
◦ Example: a pattern-matching system developed as part of a text-
processing system may be reused in a database management
Reuse- system.
Concept reuse
oriented ◦ Reuse an idea, a way, or working or an algorithm.

software ◦ The concept that you reuse is represented in an abstract notation

(e.g., a system model), which does not include implementation
detail.
engineering ◦ It can, therefore, be configured and adapted for a range of
situations.
◦ Concept reuse can be embodied in approaches such as Design
Patterns, configurable system products, and program generators.
◦ When concepts are reused, the reuse process includes an activity
where the abstract concepts are instantiated to create executable
reusable components.

SOFTWARE ENGINEERING 27
 Reuse-oriented software engineering

SOFTWARE ENGINEERING 28
 •Web services that are developed according to
service standards and which are available for
remote invocation.
Types of
•Collections of objects that are developed as a
software package to be integrated with a component
components framework such as .NET or J2EE.
•Stand-alone software systems (COTS) that are
configured for use in a particular environment.

SOFTWARE ENGINEERING 29
 Reuse-oriented software engineering
ADVANTAGES DISADVANTAGES

Reducing the amount of software Requirements compromises and this

to be developed and so reducing may lead to a system that does not
cost and risks. meet the real needs of users.

It usually also leads to faster Furthermore, some control over the
system evolution is lost as new
delivery of the software.
versions of the reusable components
are not under the control of the
organization using them.

SOFTWARE ENGINEERING 30
Process Activities

SOFTWARE ENGINEERING 31
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,
◦ In incremental development, they are inter-leaved.

SOFTWARE ENGINEERING 32
Software specification
The process of establishing what services are required and the constraints on the
system’s operation and development.
Requirements engineering process
1. Feasibility study
◦ Is it technically and financially feasible to build the system?
2. Requirements elicitation and analysis
◦ What do the system stakeholders require or expect from the system?
3. Requirements specification
◦ Defining the requirements in detail
4. Requirements validation
◦ Checking the validity of the requirements
SOFTWARE ENGINEERING 33
The
requirements
engineering
process

SOFTWARE ENGINEERING 34
 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
SOFTWARE ENGINEERING
closely related and may be inter-leaved. 35
A general
model of the
design process

SOFTWARE ENGINEERING 36
 Design activities
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.

Interface design
◦ where you define the interfaces between system components.

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 ENGINEERING 37
 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.
Testing is the most commonly used V & V activity.

SOFTWARE ENGINEERING 38
Stages of
testing

SOFTWARE ENGINEERING 39
 Development or component testing

• Individual components are tested

independently;
• Components may be functions or objects or
coherent groupings of these entities.
System testing
Testing stages
• 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.

SOFTWARE ENGINEERING 40
Testing phases
in a plan-driven
software
process

SOFTWARE ENGINEERING 41
Testing phases
in a plan-driven
software process

SOFTWARE ENGINEERING 42
Testing phase
What about testing in an incremental model?

SOFTWARE ENGINEERING 43
 Software evolution

SOFTWARE IS AS REQUIREMENTS ALTHOUGH THERE HAS

INHERENTLY FLEXIBLE CHANGE THROUGH BEEN A DEMARCATION
AND CAN CHANGE. CHANGING BUSINESS BETWEEN
CIRCUMSTANCES, THE
SOFTWARE THAT DEVELOPMENT AND
SUPPORTS THE EVOLUTION
BUSINESS MUST ALSO (MAINTENANCE) THIS IS
EVOLVE AND CHANGE. INCREASINGLY
IRRELEVANT AS FEWER
AND FEWER SYSTEMS
ARE COMPLETELY NEW.
SOFTWARE ENGINEERING 44
System
evolution

SOFTWARE ENGINEERING 45
Key points
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.
Iterative process models describe the software process as a cycle of activities

SOFTWARE ENGINEERING 46
 Key points
Requirements engineering is the process of developing a software specification.
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 requirements. The software must evolve to remain useful.

SOFTWARE ENGINEERING 47
 Coping with
change

SOFTWARE ENGINEERING 48
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 implementing new functionality

SOFTWARE ENGINEERING 49
 Reducing the costs of rework

Change avoidance/anticipation, 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.

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.
SOFTWARE ENGINEERING 50
Coping with changing requirements
System prototyping, where a version of the system or part of the
system is developed quickly to check the customer’s requirements
and the feasibility of design decisions. This approach supports change
anticipation.
Incremental delivery, where system increments are delivered to the
customer for comment and experimentation. This supports both
change avoidance and change tolerance.

SOFTWARE ENGINEERING 51
Software prototyping
A prototype is an initial version of a system used to
demonstrate concepts and try out design options.
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 UI design;
◦ In the testing process to run back-to-back tests.

SOFTWARE ENGINEERING 52
Benefits of prototyping
Improved system usability.
A closer match to users’ real needs.
Improved design quality.
Improved maintainability.
Reduced development effort.

SOFTWARE ENGINEERING 53
 The process of prototype
development
SOFTWARE ENGINEERING 54
Prototype development
May be based on rapid prototyping languages or tools
May involve leaving out functionality
◦ Prototype should focus on areas of the product that are not well-
understood;
◦ Error checking and recovery may not be included in the prototype;
◦ Focus on functional rather than non-functional requirements such as
reliability and security

SOFTWARE ENGINEERING 55
Throw-away prototypes
Prototypes should be discarded after development as they are not a
good basis for a production system:
◦ It may be impossible to tune the system to meet non-functional requirements;
◦ Prototypes are normally undocumented;
◦ The prototype structure is usually degraded through rapid change;
◦ The prototype probably will not meet normal organisational quality standards.

SOFTWARE ENGINEERING 56
When to use Prototype Model

Prototype model should be used when the desired system needs to have a lot of
interaction with the end users.
Typically, online systems, web interfaces have a very high amount of interaction
with end users, are best suited for Prototype model. It might take a while for a
system to be built that allows ease of use and needs minimal training for the end
user.
Prototyping ensures that the end users constantly work with the system and
provide a feedback which is incorporated in the prototype to result in a useable
system. They are excellent for designing good human computer interface
systems.
SOFTWARE ENGINEERING 57
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 development of an increment is started, the requirements
are frozen though requirements for later increments can continue to
evolve.

SOFTWARE ENGINEERING 58
 Incremental development and delivery

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;
◦ Difficult to implement for replacement systems as increments have less functionality than the
system being replaced.

SOFTWARE ENGINEERING 59
 Incremental delivery
SOFTWARE ENGINEERING 60
Incremental delivery advantages
Customer value can be delivered with each increment so system
functionality is available earlier.
Early increments can act as a prototype to help elicit further
requirements for later increments.
Lower risk of overall project failure.
The highest priority system services tend to receive the most
testing.

SOFTWARE ENGINEERING 61
Incremental delivery problems
Needs a clear and complete definition of the whole system before it can be broken down and built
incrementally.
Needs good planning and design.
Total cost is higher than waterfall.
Most systems require a set of basic facilities that are used by different parts of the system.
◦ As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities
that are needed by all increments.

The essence of iterative processes is that the specification is developed in conjunction with the
software.
◦ However, this conflicts with the procurement model of many organizations, where the complete system
specification is part of the system development contract.
SOFTWARE ENGINEERING 62
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.
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 throughout the
process.

SOFTWARE ENGINEERING 63
Boehm’s spiral model of the software process
RISK ANALYSIS

PLAN

ENGINEERIN
CUSTOMER EVALUATION

G
SOFTWARE ENGINEERING 64
SOFTWARE ENGINEERING 65
Spiral model sectors
Objective setting/Planning
◦ Specific objectives for the phase are identified and the next phase of the spiral is planned.

Risk assessment and reduction

◦ Risks are assessed and activities put in place to reduce the key risks.

Development and validation

◦ A development model for the system is chosen which can be any of the generic models.

Customer Evaluation
◦ The project is reviewed.

SOFTWARE ENGINEERING 66
 Pros and Cons: (Spiral Model)
ADVANTAGES DISADVANTAGES

 High amount of risk analysis hence,

avoidance of Risk is enhanced.
 Risk analysis requires highly
specific expertise.
 Good for large and mission-critical projects.
 Project’s success is highly
 Strong approval and documentation control.
dependent on the risk analysis
 Additional Functionality can be added at a phase.
later date.
 Doesn’t work well for smaller
 Software is produced early in the software life
projects.
cycle.

SOFTWARE ENGINEERING 67
When to use Spiral Model

•When costs and risk evaluation is important

•For medium to high-risk projects
•Long-term project commitment unwise because of potential changes to economic
priorities
•Users are unsure of their needs
•Requirements are complex
•New product line
•Significant changes are expected (research and exploration)
SOFTWARE ENGINEERING 68
 Key points
Processes should include activities to cope with change.
This may involve a prototyping phase that helps avoid
poor decisions on requirements and design.

Processes may be structured for iterative development

and delivery so that changes may be made without
disrupting the system as a whole.

SOFTWARE ENGINEERING 69
Difference between Iterative Model and
Incremental Model?
The Incremental Model is a method of The Iterative Design is a design methodology based on a cyclic
process of prototyping, testing, analyzing, and refining a
software development where the model is
product or process. Based on the results of testing the most
designed, implemented and tested recent iteration of a design, changes and refinements are
incrementally (a little more is added each made. This process is intended to ultimately improve the
time) until the product is finished. It quality and functionality of a design.
involves both development and In iterative design, interaction with the designed system is used
maintenance. The product is defined as as a form of research for informing and evolving a project, as
finished when it satisfies all of its successive versions, or iterations of a design are implemented.

requirements. In iterative development the working product is not released

to the customer until all the planned iterations have been
In incremental development a (sub)product completed.
is released to the customer after each
increment.
SOFTWARE ENGINEERING 70
Credits
Software Engineering, Tenth Edition by Ian Sommerville

SOFTWARE ENGINEERING 71
Questions?