Software Engineering
COMP 201
Lecturer: Sebastian Coope
Ashton Building, Room G.18
E-mail: coopes@liverpool.ac.uk
COMP 201 web-page:
http://www.csc.liv.ac.uk/~coopes/comp201
Lecture 3 – Software Processes
COMP201 - Software Engineering
1
Recap from Last Lecture: Generic Software
Process Models
 The Waterfall Model
 Separate and distinct phases of specification and
development
 Evolutionary Development
 Specification and development are interleaved
 Formal Systems Development (example - ASML)
 A mathematical system model is formally transformed to
an implementation
 Reuse-Based Development
 The system is assembled from existing components
COMP201 - Software Engineering
2
Software Specification
 Software Specification: The process of establishing what
services are required and the constraints on the system’s
operation and development
 Requirements Engineering Process
 Feasibility study
 Requirements elicitation and analysis
 Requirements specification
 Requirements validation
COMP201 - Software Engineering
3
The Requirements Engineering Process
Feasi bi li ty
s tu dy
R equ irem ent s
eli cit ati on an d
analy si s
Requ ir em ent s
s pecifi cati on
Feasi bi li ty
repo rt
R equ irem ent s
v al id ati on
S y st em
m o dels
Us er an d s ys tem
requ irem en ts
R equ irem ent s
d ocum en t
COMP201 - Software Engineering
4
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
 Tasks .. Design database, website design, data structures,
communications protocols
 Implementation
 Translate this structure into an executable program
 The activities of design and implementation are closely related
and may be inter-leaved
COMP201 - Software Engineering
5
Design Process Activities
 Architectural design (separate web service modules)
 The sub-systems making up the system and their
relationships are identified and documented.
 Abstract specification
 For each sub-system, an abstract specification of its
operational constraints and services is produced.
 Interface design
 For each sub-system, an unambiguous interface with other
sub-systems is designed and documented

Formal specification may be used in this stage (we study this later)
COMP201 - Software Engineering
6
Design Process Activities
 Component design
 Services are allocated to components and the interfaces of
these components are designed
 Data structure design
 The data structures used in the system implementation are
designed in detail and specified
 Algorithm design
 The algorithms used in components to provide services are
designed and specified
COMP201 - Software Engineering
7
An Example System
 Consider the scenario of developing a Coffee/drinks
machine software
 What are the major sub-systems?
 Graphical display, cash handling, accounting, safety system,
recipe handling, stock control
 How may we define an abstract specification for each?
How do the different sub-systems interact?
 Can you define specifications for components/data
structures and algorithms for one of the sub-systems?
COMP201 - Software Engineering
8
COMP201 - Software Engineering
9
The Software Design Process
Requirements
sp ecifica t ion
Design acti vities
Architectur al
design
Abs tract
sp ecifica t ion
Int erface
design
Comp onent
design
Dat a
st ruct ure
design
Algorithm
design
Syst em
architectur e
Soft war e
sp ecifica t ion
Int erface
sp ecifica t ion
Comp onent
sp ecifica t ion
Dat a
st ruct ure
sp ecifica t ion
Algorithm
sp ecifica t ion
Design pr oduct s
COMP201 - Software Engineering
10
Models
 Graphical views of the operation/structure of the system
 Can be dynamic or static
 Why have models
 Formalizes the type and format of required information
 Easier to get the big picture than text documents
 Some, can be translated automatically to software
implementation
 Can be tested for validity automatically
COMP201 - Software Engineering
11
Design Methods
 Design (structured) methods are systematic
approaches to developing a software design
 The design is usually documented as a set of graphical
models
 Possible models (we study these in detail in later lectures)
 Data-flow model
 Entity-relation-attribute model (data base or class design)
 Structural model
 Object models
 A state transition model showing system states and triggers
COMP201 - Software Engineering
12
Programming and Debugging
 Programming and Debugging consist of translating a
design into a program and removing errors from that
program
 Programming is usually personal activity - there is
no generic programming process, but there are good
programming practices and organisational standards
to be followed.
 Programmers carry out some program testing to
discover faults in the program and remove these
faults in the debugging process
COMP201 - Software Engineering
13
The Debugging Process
Lo cat e
erro r
Des ig n
erro r repai r
COMP201 - Software Engineering
R epai r
erro r
R e-tes t
p ro g ram
14
Debugging in real world
 Ideally the software fault can be re-produced at will
 Some software faults indicate problems with overall
software design and require application re-design
 e.g. lack of thread safety
 If bugs hard or impossible to re-produce in test conditions
 Insert debug/test code embedded into product which logs
and alerts in fault conditions
 Add patch code, which will help recover in fault conditions

Example catching exceptions and logging
COMP201 - Software Engineering
15
Software Validation
 Verification and validation is intended to show that a
system conforms to its specification (verification) and
meets the requirements of the system customer
(validation)
 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
COMP201 - Software Engineering
16
The Testing Process
Un i t
t es ti ng
M o du le
t es ti ng
S u b-s ys tem
t es ting
S y st em
t es ti ng
Accep tan ce
t es ti ng
C o m po nent
t es ti ng
Int egrat io n t est in g
COMP201 - Software Engineering
Us er
t es ti ng
17
Testing Stages
 Unit testing
 Individual components are tested
 Module testing
 Related collections of dependent components are tested
 Sub-system testing (merges with system testing)
 Modules are integrated into sub-systems and tested. The focus
here should be on interface testing
 System testing
 Testing of the system as a whole. Testing of emergent
properties
 Acceptance testing
 Testing with customer data to check that it is acceptable
COMP201 - Software Engineering
18
Testing Phases
Requ ir em ent s
s pecifi cat io n
S y st em
s pecifi cat io n
S y st em
i nt eg rat io n
t es t pl an
Accep tan ce
t es t pl an
S ervi ce
S y stem
d es ig n
Accep tan ce
t es t
Det ail ed
d es ig n
S u b-s ys tem
i nt eg rat io n
t es t pl an
S y stem
i nt eg ratio n t est
COMP201 - Software Engineering
M o du le an d
u ni t co de
and t ess
S u b-s ys tem
i nt eg rat io n t est
19
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
 It is important to realise that maintenance costs are
sometimes several times the initial development costs of
the system.
COMP201 - Software Engineering
20
System Evolution
Defi ne sy st em
requ irem en ts
As s es s exi st in g
s ys tem s
Ex is t in g
s ys tem s
COMP201 - Software Engineering
P ro po se s ys tem
chan ges
M o di fy
s ys tem s
New
s ys tem
21
Automated Process Support (CASE)
 Computer-aided software engineering (CASE) is software
to support software development and evolution processes
 Activity automation:
 Graphical editors for system model development
 Data dictionary to manage design entities
 Graphical UI builder for user interface construction
 Bug/Issue management tools
 Version control management tools
 Debuggers to support program fault finding
 Automated translators to generate new versions of a
program
COMP201 - Software Engineering
22
Case Technology
Case technology has led to significant improvements
in the software process though not the order of
magnitude improvements that were once predicted.
Why is this?
 Software engineering requires creative thought - this is not
readily automatable and the use of artificial intelligence to
provide support for design has not been successful.
 Software engineering is a team activity and, for large
projects, much time is spent in team interactions. CASE
technology does not really support such activities
COMP201 - Software Engineering
23
CASE Classification
Classification helps us understand the different types
of CASE tools and their support for process activities
 Functional perspective
 Tools are classified according to their specific function
 Process perspective
 Tools are classified according to process activities that are
supported
 Integration perspective
 Tools are classified according to their organisation into
integrated units
COMP201 - Software Engineering
24
CASE Integration
 Tools (Bugzilla, GIT)
 Support individual process tasks such as design consistency
checking, text editing, etc.
 Workbenches (Rational Rose UML)
 Support a process phase such as specification or design,
Normally include a number of integrated tools
 Environments (example IDE like Eclipse)
 Support all or a substantial part of an entire software
process. Normally include several integrated workbenches
COMP201 - Software Engineering
25
Lecture Key Points
 Requirements engineering is the process of developing a
software specification
 Design and implementation processes transform the
specification to an executable program
 Validation involves checking that the system meets its
specification and user needs
 Evolution is concerned with modifying the system after it
is in use
 CASE technology supports software process activities
COMP201 - Software Engineering
26