Advanced Systems Analysis and Design – MSIS811

Software Processes
Topics covered

 Software process models

 Process activities
 Coping with change
 Process improvement

10/20/2024 Chapter 2 Software Processes 2

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.
10/20/2024 Chapter 2 Software Processes 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.

10/20/2024 Chapter 2 Software Processes 4

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.
10/20/2024 Chapter 2 Software Processes 5
Waterfall development 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
 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.

10/20/2024 Chapter 2 Software Processes 6

 Waterfall model

10/20/2024 Chapter 2 Software Processes 7

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.

10/20/2024 Chapter 2 Software Processes 8

Incremental development model
 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.

 Specification, development, and validation activities are

interleaved rather than separate, with rapid feedback across
activities.

 Incremental software development is better than a waterfall

approach for most business, e-commerce, and personal systems.

 Each increment or version of the system incorporates some of the

functionality that is needed by the customer.

10/20/2024 Chapter 2 Software Processes 9

Incremental development model

10/20/2024 Chapter 2 Software Processes 10

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.

10/20/2024 Chapter 2 Software Processes 11

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.

10/20/2024 Chapter 2 Software Processes 12

Reuse-oriented development model

 Based on software reuse where systems are

integrated from existing components or application
systems (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

10/20/2024 Chapter 2 Software Processes 13

Types of reusable software

 Stand-alone application systems (sometimes called

COTS) that are configured for use in a particular
environment.
 Collections of objects that are developed as a
package to be integrated with a component
framework such as .NET or J2EE.
 Web services that are developed according to
service standards and which are available for remote
invocation.

10/20/2024 Chapter 2 Software Processes 14

Reuse-oriented development model

Requirements Component Requirements System design

specifications analysis modifications with re-use

Development System
and validation
integration

10/20/2024 Chapter 2 Software Processes 15

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.
 For example, in the waterfall model, they are
organized in sequence, whereas in incremental
development they are interleaved.

10/20/2024 Chapter 2 Software Processes 16

The requirements engineering process

10/20/2024 Chapter 2 Software Processes 17

Software specification

 The process of establishing what services are

required and the constraints on the system’s
operation and development.
 Requirements engineering process
 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

10/20/2024 Chapter 2 Software Processes 18

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.

10/20/2024 Chapter 2 Software Processes 19

Design activities

 Architectural design, where you identify the overall

structure of the system, the principal components
(subsystems or modules), their relationships and
how they are distributed.
 Database design, where you design the system data
structures and how these are to be represented in a
database.
 Interface design, where you define the interfaces
between system components.
 Component selection and design, where you search
for reusable components. If unavailable, you design
how it will operate.
10/20/2024 Chapter 2 Software Processes 20
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.

10/20/2024 Chapter 2 Software Processes 21

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.

10/20/2024 Chapter 2 Software Processes 22

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.
 Customer testing
 Testing with customer data to check that the system meets
the customer’s needs.

10/20/2024 Chapter 2 Software Processes 23

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

10/20/2024 Chapter 2 Software Processes 24

 Approaches to reduce re-work costs

 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 to get feedback.

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

10/20/2024 Chapter 2 Software Processes 25

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
avoidance.
 Incremental delivery, where system increments are
delivered to the customer for comment and
experimentation. This supports both change
avoidance and change tolerance.

10/20/2024 Chapter 2 Software Processes 26

Process improvement

 Many software companies have turned to software

process improvement as a way of enhancing the
quality of their software, reducing costs or
accelerating their development processes.
 Process improvement means understanding existing
processes and changing these processes to
increase product quality and/or reduce costs and
development time.

10/20/2024 Chapter 2 Software Processes 27

Approaches to improvement

 The process maturity approach, which focuses on

improving process and project management and
introducing good software engineering practice.
 The level of process maturity reflects the extent to which
good technical and management practice has been adopted
in organizational software development processes.
 The agile approach, which focuses on iterative
development and the reduction of overheads in the
software process.
 The primary characteristics of agile methods are rapid
delivery of functionality and responsiveness to changing
customer requirements.

10/20/2024 Chapter 2 Software Processes 28

The process improvement cycle

10/20/2024 Chapter 2 Software Processes 29

Process improvement activities

 Process measurement
 You measure one or more attributes of the software process
or product. These measurements forms a baseline that
helps you decide if process improvements have been
effective.
 Process analysis
 The current process is assessed, and process weaknesses
and bottlenecks are identified. Process models (sometimes
called process maps) that describe the process may be
developed.
 Process change
 Process changes are proposed to address some of the
identified process weaknesses. These are introduced and
10/20/2024the cycle resumes to collect
Chapter data
2 Software about the effectiveness of30
Processes
Process measurement

 Wherever possible, quantitative process data

should be collected
 However, where organisations do not have clearly defined
process standards this is very difficult as you don’t know
what to measure. A process may have to be defined before
any measurement is possible.
 Process measurements should be used to
assess process improvements
 But this does not mean that measurements should drive the
improvements. The improvement driver should be the
organizational objectives.

10/20/2024 Chapter 2 Software Processes 31

 Rational Unified Process (RUP)

10/20/2024 Chapter 2 Software Processes 32

Rational Unified Process

 The Rational Unified Process (RUP) is a modern

process model that has been derived from work on
the UML and the associated Unified Software
Development Process.

 The RUP is a phased model that identifies four discrete phases

in the software process

 However, unlike the waterfall model where phases are equated

with process activities, the phases in the RUP are more closely
related to business rather than technical concerns.

10/20/2024 Chapter 2 Software Processes 33

Rational Unified Process (RUP) phases

 Inception The goal of the inception phase is to establish a

business case for the system. You should identify all external
entities (people and systems) that will interact with the system
and define these interactions.
 Elaboration The goals of the elaboration phase are to develop an
understanding of the problem domain, establish an architectural
framework for the system, develop the project plan, and identify
key project risks.
 Construction The construction phase involves system design,
programming, and testing. Parts of the system are developed in
parallel and integrated during this phase.
 Transition The final phase of the RUP is concerned with moving
the system from the development community to the user
community and making it work in a real environment

10/20/2024 Chapter 2 Software Processes 34

Iteration within the RUP is supported in two ways. Each phase
may be enacted in an iterative way with the results developed
incrementally. In addition, the whole set of phases may also be
enacted incrementally, as shown by the looping arrow from
Transition to Inception

Phase iteration

Inception Elaboration Construction Transition

10/20/2024 Chapter 2 Software Processes 35