SOFTWARE ENGINEERING

Software Processes

Chapter 2 Software Processes 1

 Topics covered

2.1. SDLC

2.2. Process activities

• 2.2.1. Software Specification
• 2.2.2. Software Design and Implementation
• 2.2.3. Software Validation
• 2.2.4. Software Evolution

Chapter 2 Software Processes 2

2.1. Software Development Life
Cycle (SDLC)

Chapter 2 Software Processes 3

 Software Development Life Cycle
(SDLC)

• A structured set of activities

required to develop a software
system. Specification

• Many different software

processes but all involve:
• Specification – defining what Evolution Design
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; Implementati
Validation
• Evolution – changing the system on
in response to changing
customer needs.

Chapter 2 Software Processes 4

 Plan-driven and agile processes

•Plan-driven processes are processes where all

the process activities are planned, 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 5
2.2. Process activities

Chapter 2 Software Processes 6

 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.

Chapter 2 Software Processes 7

2.2.1. Software specification

Chapter 2 Software Processes 8

 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

Chapter 2 Software Processes 9

 What is a requirement?
• It may range from a high-level abstract statement of a service or of a
system constraint to a detailed mathematical functional specification.
• This is inevitable as requirements may serve a dual function
• May be the basis for a bid for a contract - therefore must be open to
interpretation;
• May be the basis for the contract itself - therefore must be defined in detail;
• Both these statements may be called requirements.

Chapter 2 Software Processes 10

 Types of requirement

User requirements System requirements

Statements in natural language plus A structured document setting out detailed
diagrams of the services the system descriptions of the system’s functions,
provides and its operational constraints. services and operational constraints.
Written for customers. Defines what should be implemented so
may be part of a contract between client
and contractor.

Chapter 2 Software Processes 11

 System stakeholders

Any person or organization who is Stakeholder types

affected by the system in some way
and so who has a legitimate interest End users
System managers
System owners
External stakeholders

Chapter 2 Software Processes 12

 Functional and non-functional
requirements

• Functional requirements
• Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave in
particular situations.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards,
etc.
• Often apply to the system as a whole rather than individual features or services.
• Domain requirements
• Constraints on the system from the domain of operation

Chapter 2 Software Processes 13

 Requirements engineering
• The process of establishing the services that a customer requires from a
system and the constraints under which it operates and is developed.
• The system requirements are the descriptions of the system services and
constraints that are generated during the requirements engineering
process.

Chapter 2 Software Processes 14

The requirements engineering process

Chapter 2 Software Processes 15

 Requirements elicitation
• Software engineers work with a range of system stakeholders to find out
about the application domain, the services that the system should
provide, the required system performance, hardware constraints, other
systems, etc.
• Stages include:
• Requirements discovery,
• Requirements classification and organization,
• Requirements prioritization and negotiation,
• Requirements specification.

Chapter 2 Software Processes 16

The requirements elicitation and analysis
process

Chapter 2 Software Processes 17

 Requirements specification
• The process of writing down the user and system requirements in a
requirements document.
• User requirements have to be understandable by end-users and
customers who do not have a technical background.
• System requirements are more detailed requirements and may include
more technical information.
• The requirements may be part of a contract for the system development
• It is therefore important that these are as complete as possible.

Chapter 2 Software Processes 18

 Changing requirements
• The business and technical environment of the system always changes
after installation.
• New hardware may be introduced, it may be necessary to interface the system
with other systems, business priorities may change (with consequent changes in
the system support required), and new legislation and regulations may be
introduced that the system must necessarily abide by.
• The people who pay for a system and the users of that system are rarely
the same people.
• System customers impose requirements because of organizational and budgetary
constraints. These may conflict with end-user requirements, and, after delivery,
new features may have to be added for user support if the system is to meet its
goals.

Chapter 2 Software Processes 19

 Changing requirements
• Large systems usually have a diverse user community, with many users
having different requirements and priorities that may be conflicting or
contradictory.
• The final system requirements are inevitably a compromise between them and,
with experience, it is often discovered that the balance of support given to
different users has to be changed.

Chapter 2 Software Processes 20

 Requirements validation

•Concerned with demonstrating that the

requirements define the system that the
customer really wants.
•Requirements error costs are high so validation
is very important
• Fixing a requirements error after delivery may cost
up to 100 times the cost of fixing an implementation
error.

Chapter 2 Software Processes 21

 Requirements checking
• Validity. Does the system provide the functions which best
support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer
included?
• Realism. Can the requirements be implemented given available
budget and technology
• Verifiability. Can the requirements be checked?

Chapter 2 Software Processes 22

 Requirements validation techniques
• Requirements reviews
• Systematic manual analysis of the requirements.
• Prototyping
• Using an executable model of the system to check requirements.
• Test-case generation
• Developing tests for requirements to check testability.

Chapter 2 Software Processes 23

 Requirements reviews
• Regular reviews should be held while the requirements definition is being
formulated.
• Both client and contractor staff should be involved in reviews.
• Reviews may be formal (with completed documents) or informal. Good
communications between developers, customers and users can resolve
problems at an early stage.

Chapter 2 Software Processes 24

 Review checks
• Verifiability
• Is the requirement realistically testable?
• Comprehensibility
• Is the requirement properly understood?
• Traceability
• Is the origin of the requirement clearly stated?
• Adaptability
• Can the requirement be changed without a large impact on other requirements?

Chapter 2 Software Processes 25

2.2.2. Software design and
implementation

Chapter 2 Software Processes 26

 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.

Chapter 2 Software Processes 27

A general model of the design process

Chapter 2 Software Processes 28

 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.

Chapter 2 Software Processes 29

 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.

Chapter 2 Software Processes 30

2.2.3. Software validation

Chapter 2 Software Processes 31

 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.

Chapter 2 Software Processes 32

 Verification vs validation
• Verification:
"Are we building the product right”.
• The software should conform to its specification.
• Validation:
"Are we building the right product”.
• The software should do what the user really requires.

Chapter 2 Software Processes 33

 V & V confidence
• Aim of V & V is to establish confidence that the system
is ‘fit for purpose’.
• Depends on system’s purpose, user expectations and
marketing environment
• Software purpose
• The level of confidence depends on how critical the software is to an
organisation.
• User expectations
• Users may have low expectations of certain kinds of software.
• Marketing environment
• Getting a product to market early may be more important than finding defects
in the program.

Chapter 2 Software Processes 34

 Program testing
• Testing is intended to show that a program does what it is intended to
do and to discover program defects before it is put into use.
• When you test software, you execute a program using artificial data.
• You check the results of the test run for errors, anomalies or
information about the program’s non-functional attributes.
• Can reveal the presence of errors NOT their
absence.
• Testing is part of a more general verification and validation process,
which also includes static validation techniques.

Chapter 2 Software Processes 35

 Program testing goals
• To demonstrate to the developer and the customer that the software
meets its requirements.
• For custom software, this means that there should be at least one test for every
requirement in the requirements document. For generic software products, it
means that there should be tests for all of the system features, plus combinations
of these features, that will be incorporated in the product release.
• To discover situations in which the behavior of the software is incorrect,
undesirable or does not conform to its specification.
• Defect testing is concerned with rooting out undesirable system behavior such as
system crashes, unwanted interactions with other systems, incorrect
computations and data corruption.

Chapter 2 Software Processes 36

 Validation and defect testing
• The first goal leads to validation testing
• You expect the system to perform correctly using a given set of test cases that
reflect the system’s expected use.
• The second goal leads to defect testing
• The test cases are designed to expose defects. The test cases in defect testing can
be deliberately obscure and need not reflect how the system is normally used.

Chapter 2 Software Processes 37

 Testing process goals
• Validation testing
• To demonstrate to the developer and the system customer that the
software meets its requirements
• A successful test shows that the system operates as intended.
• Defect testing
• To discover faults or defects in the software where its behaviour is
incorrect or not in conformance with its specification
• A successful test is a test that makes the system perform incorrectly and
so exposes a defect in the system.

Chapter 2 Software Processes 38

Stages of testing

Chapter 2 Software Processes 39

 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.

Chapter 2 Software Processes 40

An input-output model of program testing

Chapter 2 Software Processes 41

A model of the software testing process

Chapter 2 Software Processes 42

2.2.4. Software Evolution

Chapter 2 Software Processes 43

 Software evolution

•Software is inherently flexible and can change.

•As requirements change through changing
business circumstances, the software that
supports the business must also evolve and
change.
•Although there has been a demarcation
between development and evolution
(maintenance) this is increasingly irrelevant as
fewer and fewer systems are completely new.

Chapter 2 Software Processes 44

System evolution

Chapter 2 Software Processes 45

 Software change
• Software change is inevitable
• New requirements emerge when the software is used;
• The business environment changes;
• Errors must be repaired;
• New computers and equipment is added to the system;
• The performance or reliability of the system may have to be improved.
• A key problem for all organizations is implementing and
managing change to their existing software systems.

Chapter 2 Software Processes 46

 Importance of evolution
• Organisations have huge investments in their software systems - they are
critical business assets.
• To maintain the value of these assets to the business, they must be
changed and updated.
• The majority of the software budget in large companies is devoted to
changing and evolving existing software rather than developing new
software.

Chapter 2 Software Processes 47

A spiral model of development and
evolution

Chapter 2 Software Processes 48

Evolution and servicing

Chapter 2 Software Processes 49

 Evolution and servicing
• Evolution
• The stage in a software system’s life cycle where it is in operational use and is
evolving as new requirements are proposed and implemented in the system.
• Servicing
• At this stage, the software remains useful but the only changes made are those
required to keep it operational i.e. bug fixes and changes to reflect changes in the
software’s environment. No new functionality is added.
• Phase-out
• The software may still be used but no further changes are made to it.

Chapter 2 Software Processes 50

 Evolution processes
• Software evolution processes depend on
• The type of software being maintained;
• The development processes used;
• The skills and experience of the people involved.
• Proposals for change are the driver for system evolution.
• Should be linked with components that are affected by the change, thus allowing
the cost and impact of the change to be estimated.
• Change identification and evolution continues throughout the system
lifetime.

Chapter 2 Software Processes 51

Change identification and evolution
processes

Chapter 2 Software Processes 52

The software evolution process

Chapter 2 Software Processes 53

Change implementation

Chapter 2 Software Processes 54

 Change implementation
• Iteration of the development process where the revisions to the system
are designed, implemented and tested.
• A critical difference is that the first stage of change implementation may
involve program understanding, especially if the original system
developers are not responsible for the change implementation.
• During the program understanding phase, you have to understand how
the program is structured, how it delivers functionality and how the
proposed change might affect the program.

Chapter 2 Software Processes 55

 Urgent change requests
• Urgent changes may have to be implemented without going through all
stages of the software engineering process
• If a serious system fault has to be repaired to allow normal operation to continue;
• If changes to the system’s environment (e.g. an OS upgrade) have unexpected
effects;
• If there are business changes that require a very rapid response (e.g. the release
of a competing product).

Chapter 2 Software Processes 56

The emergency repair process

Chapter 2 Software Processes 57