Software Processes

1
Chapter Objectives

Software process models

Process activities
Coping with change

2
Software Process
❖ A software process is a set of related activities that leads to the
production of a software product
❖ There are four fundamental software process activities:
o Specification – defining what the system should do;
o Design and implementation – defining the organization of the system
and implementing the system;
o Validation – checking that it does what the customer wants;
o Evolution – changing the system in response to changing customer
needs.
❖ These activities further include sub-activities (requirements
validation, architectural design) and supporting activities
(documentation)

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.

4
Categorization of Software Processes
❑ Plan-driven processes
all the process activities are planned in advance and progress is
measured against this plan.
❑ 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 is no ‘ideal’ software process, thus, there is scope for
improving the software process.

5
Software Process Models

6
Software Process Models
A software process model is an abstract representation of a process.
1. The waterfall model
▪ Takes the fundamental process activities and represents them as
separate and distinct phases. Plan-driven model.
2. Incremental development
▪ The system is developed as a series of versions (increments), with each
version adding functionality to the previous version. Could be
plan-driven or agile.
3. Reuse-oriented software engineering
▪ 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. 7
The Waterfall Model

8
Phases of Waterfall Model
✧ 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

❑ Drawback - difficulty of accommodating change after the

process is underway. In principle, a phase has to be complete
before moving onto the next phase.

9
Problems of Waterfall Model
There are some reasons which are given below due to this waterfall
model fails.
▪ One way street:
This model is just like the one-way street. Once a phase is completed and
next phase has started, there is no way to going back on the previous phase.
▪ Overlapping:
The waterfall model has lacked an overlapping among phases. It
recommends that new phase can start only after the completion of the
previous phase. But in real projects, this can’t be maintained. To increase
the efficiency and reduce the cost, phases may overlap.
▪ Interaction:
Users have little interaction with project. This feedback is not taken during
development. After a development process starts, changes can not done
easily.

10
Problems of Waterfall Model
▪ Feedback path:
The waterfall model has no feedback path. In the traditional waterfall model
evolution of software from one phase to another phase is like a waterfall. The
waterfall model assumes that no error is ever committed by developers during
any phases. Hence, it does not incorporate any mechanism for error correction.
▪ Not Flexible:
Difficult to accommodate change requests. The waterfall model assumes that
all the customer requirements can be completely and correctly defined at the
beginning of the project, but actually customers’ requirements keep on
changing with time. After the requirements specification phase is completed
difficult to accommodate any change requests.

11
Incremental Development

12
Benefits of Incremental Development
1. 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.

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

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

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

14
Reuse-Oriented Software Engineering
❖ Reuse-oriented approaches rely on a large base of reusable
software components and an integrating framework for the
composition of these components (sometimes called COTS
-Commercial-off-the-shelf systems).

❖ Reused elements may be configured to adapt their behaviour

and functionality to a user’s requirements

❖ Reuse is now the standard approach for building many types of

business system

15
Reuse-Oriented Software Engineering

16
Key Process Stages
❑ Component Analysis
Given the requirements specification, a search is made for components
to implement that specification
❑ Requirements Modification
The requirements are analyzed using information about the
components. Can search for alternative solutions.
❑ System Design with Reuse
The framework of the system is designed or an existing framework is
reused
❑ Development and integration
Software that cannot be externally procured is developed, and the
components are integrated to create the new system
17
Types of Reusable Software
❑ Stand-alone application systems (sometimes called COTS) that
are configured for use in a particular environment.

❑ Web services that are developed according to service standards

and which are available for remote invocation.

❑ Collections of objects that are developed as a package to be

integrated with a component framework such as .NET or
J2EE.

18
Advantages and Disadvantages
Advantages
Reduced costs and risks as less software is developed from
scratch
Faster delivery and deployment of system

Disadvantages
But requirements compromises are inevitable so system may not
meet real needs of users
Loss of control over evolution of reused system elements as new
versions are not under the control of the organization using them
19
Process Activities

20
Software Specification

❖ Software specification or requirements engineering is the process of

understanding and defining what services are required from the system
and the constraints on the system’s operation and development.
❖ There are four main activities in the requirements engineering process:
❑ Feasibility study
• Whether the requirements can be satisfied with existing technologies?
cost-effective or not?
❑ Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
❑ Requirements specification
• Translating the information gathered during the analysis activity into a
document
❑ Requirements validation
• Checking the validity of the requirements 21
The Requirements Engineering Process

22
Software Design and Implementation

Converts the system specification into an executable system.

1. Software design
▪ Design a software structure that realises the specification;
2. Implementation
▪ Translate this structure into an executable program;

The activities of design and implementation are closely related

and may be inter-leaved.

23
A General Model of the Design Process

24
Design Activities
❑ Architectural design
▪ identifying the overall structure of the system, the principal
components (subsystems or modules), their relationships and how they
are distributed.
❑ Interface design
▪ defining the interfaces between system components.
❑ Component selection and design
▪ we take each system component and design how it will operate.
❑ Database design
▪ designing the system data structures and how these are to be
represented in a database.

25
System Implementation

❖ The software is implemented either by developing a program

or programs or by configuring an application system.
❖ Design and implementation are interleaved activities for most
types of software system.
❖ Programming is an individual activity with no standard
process.
❖ Debugging is the activity of finding program faults and
correcting these faults.

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

27
Stages of Testing

28
Testing Stages

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

29
Testing phases in a plan-driven software
process (V-model)

30
Testing phases in a plan-driven software
process (V-model)

31
Software Evolution
❖ The process of developing software initially, then timely updating it
for various reasons, i.e., to add new features or to remove obsolete
functionalities etc.

❖ The necessity of Software evolution:

▪ Change in requirement with time
▪ Environment change
▪ Errors and bugs
▪ Security risks
▪ For having new functionality and features

32
Software Evolution

33
Coping with Change

34
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.
❖ Whatever software process model is used, it is essential that it
can accommodate changes to the software being developed

❖ Change leads to rework, so the costs of change include both

rework (e.g. re-analyzing requirements) as well as the costs of
implementing new functionality

35
Reducing the costs of rework

There are two related approaches that may be used to reduce the
costs of rework:
❖ Change avoidance
▪ 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
▪ the process is designed so that changes can be accommodated at
relatively low cost.
▪ normally involves some form of incremental development.

36
Coping with change and changing requirements

❑ System prototyping
▪ 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 avoidance.

❑ Incremental delivery
▪ system increments are delivered to the customer for comment and
experimentation. This supports both change avoidance and change
tolerance.

37
Software Prototyping

❑ A prototype is an initial version of a system used to

demonstrate concepts and try out design options.
▪ get new ideas for requirements
▪ find areas of strength and weakness in the software.
▪ propose new system requirements.
▪ may reveal errors and omissions in the proposed requirements
❑ Benefits of prototyping:
▪ Improved system usability.
▪ A closer match to users’ real needs.
▪ Improved design quality.
▪ Improved maintainability.
▪ Reduced development effort.

38
The process of prototype development

39
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

40
Incremental Delivery
✧ An approach to software development where some of the developed
increments are delivered to the customer and deployed for use in an
operational environment
✧ 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.
✧ Each increment provides a subset of the system functionality.
✧ As new increments are completed, they are integrated with existing
increments so that the system functionality improves with each
delivered increment
41
Incremental delivery

42
Advantages of Incremental Delivery
▪ Customers do not have to wait until the entire system is delivered
before they can gain value from it.
▪ Early increments act as a prototype to help elicit requirements for
later increments.
▪ Lower risk of overall project failure.
▪ Easy to incorporate changes into the system.
▪ The highest priority system services tend to receive the most testing.

43
Problems of Incremental Delivery
o 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.
o Iterative development can also be difficult when a replacement
system is being developed.
▪ Getting useful customer feedback is difficult.
o The essence of iterative processes is that the specification is
developed in conjunction with the software.
▪ there is no complete system specification until the final increment is
specified. government agencies may find difficult to accommodate.

44
Boehm’s Spiral Model

45
Boehm’s Spiral Model

✧ The software process is represented as a spiral, rather than a

sequence of activities with some backtracking from one activity to
another.
✧ Each loop in the spiral represents a phase of the software process.
✧ The innermost loop might be concerned with system feasibility, the
next loop with requirements definition, the next loop with system
design, and so on.
✧ It combines change avoidance with change tolerance
✧ It assumes that changes are a result of project risks and includes
explicit risk management activities to reduce these risks

46
Spiral Model

47
Spiral Model

Each loop in the spiral is split into four sectors:

✧ Objective setting
▪ Specific objectives for that phase of the project are defined.
Constraints, detailed management plan, risks, alternative strategies are
identified.
✧ Risk assessment and reduction
▪ For each of the identified project risks, a detailed analysis is carried
out. Steps are taken to reduce the risk.
✧ Development and validation
▪ After risk evaluation, a development model for the system is chosen.
✧ Planning
▪ The project is reviewed and a decision made whether to continue with a
further loop of the spiral. 48