Software Processes

crookpatedspongySoftware and s/w Development

Dec 2, 2013 (3 years and 9 months ago)

133 views





Software Engineering, COMP201



Slide
1

Lectures 2 & 3

Software Processes





Software Engineering, COMP201



Slide
2

What is a Process … ?


When we provide a service or create a product we always
follow a sequence of steps to accomplish a set of tasks


You do not usually

»
put up the drywall before the wiring for a house is installed or

»
bake a cake before all the ingredients are mixed together


We can think of a series of activities as a
process



Any process has the following characteristics


It prescribes all of the
major activities


It uses resources and produces
intermediate and final products


It may include sub
-
processes and
has entry and exit criteria


The activities are
organized in a sequence


Constrains or control may apply to activities


(budget control, availability of resources )





Software Engineering, COMP201



Slide
3

Software Processes

Coherent sets of activities for



Specifying
,


Designing
,


Implementing

and


Testing

software systems

When the process involves the building of some product
we refer to the process as a
life cycle

Software development process


software life cycle





Software Engineering, COMP201



Slide
4

Major problems in software developments …

The requirements
specification was
defined like this


The developers
understood it in
that way

This is how the
problem was
solved before.


This is how the problem
is solved now

That is the program after
debugging

This is how the program is
described by marketing
department

This, in fact, is what the
customer wanted …
;
-
)





Software Engineering, COMP201



Slide
5

The Software Process


A
structured set of activities

required to develop a

software system


Specification


Design


Validation


Evolution


A
software process model

is an abstract
representation of a process



It presents a description of a process from some
particular perspective





Software Engineering, COMP201



Slide
6

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





Software Engineering, COMP201



Slide
7

1. Waterfall Model

R
e
q
u
i
r
e
m
e
n
t
s
d
e
f
i
n
i
t
i
o
n
S
y
s
t
e
m

a
n
d
s
o
f
t
w
a
r
e

d
e
s
i
g
n
I
m
p
l
e
m
e
n
t
a
t
i
o
n
a
n
d

u
n
i
t

t
e
s
t
i
n
g
I
n
t
e
g
r
a
t
i
o
n

a
n
d
s
y
s
t
e
m

t
e
s
t
i
n
g
O
p
e
r
a
t
i
o
n

a
n
d
m
a
i
n
t
e
n
a
n
c
e




Software Engineering, COMP201



Slide
8

Waterfall model phases


R
equirements analysis and definition


S
ystem and software design


I
mplementation and unit testing


I
ntegration and system testing


O
peration and maintenance




The drawback of the waterfall model is the difficulty of
accommodating change after the process is underway





Software Engineering, COMP201



Slide
9

Waterfall model problems


Inflexible partitioning

of the project into distinct stages


This makes it difficult to respond to changing customer
requirements


Therefore, this model is only appropriate when the
requirements are well
-
understood

Waterfall model describes a
process of stepwise refinement



Based on
hardware engineering models



Widely used in
military

and
aerospace



industries





Software Engineering, COMP201



Slide
10

Why Not a Waterfall

But software is different :


No fabrication step



Program code is another design level



Hence, no “commit” step


software can always be changed…!


No body of experience for design analysis (yet)



Most analysis (testing) is done on program code



Hence, problems not detected until late in the process


Waterfall model takes a static view of requirements



Ignore changing needs



Lack of user involvement once specification is written


Unrealistic separation of
specification

from the
design



Doesn’t accommodate prototyping, reuse, etc





Software Engineering, COMP201



Slide
11

2. Evolutionary development


Exploratory development


-
Objective is
to work with customers

and
to evolve a final
system from an initial outline specification
.

-
Should start with well
-
understood requirements.

-
The system evolves by adding new features as they are
proposed by customer.


Throw
-
away prototyping


Objective is to understand the system requirements. Should
start with poorly understood requirements

»
Develop “quick and dirty” system quickly;

»
Expose to user comment;

»
Refine;



Until adequate system developed.


Particularly suitable where:

-
detailed requirements not possible;

-
powerful development tools (e.g. GUI) available





Software Engineering, COMP201



Slide
12

Evolutionary development

V
a
l
i
d
a
t
i
o
n
F
i
n
a
l
v
e
r
s
i
o
n
D
e
v
e
l
o
p
m
e
n
t
I
n
t
e
r
m
e
d
i
a
t
e
v
e
r
s
i
o
n
s
S
p
e
c
i
f
i
c
a
t
i
o
n
I
n
i
t
i
a
l
v
e
r
s
i
o
n
O
u
t
l
i
n
e
d
e
s
c
r
i
p
t
i
o
n
C
o
n
c
u
r
r
e
n
t
a
c
t
i
v
i
t
i
e
s




Software Engineering, COMP201



Slide
13

Evolutionary development


Problems


Lack of process visibility


Systems are often poorly structured


Special skills

(e.g. in languages




for rapid prototyping)
may be required


Applicability


For small or medium
-
size interactive systems


For parts of large systems

(e.g. the user interface)


For short
-
lifetime systems





Software Engineering, COMP201



Slide
14

3. Formal systems development


Based on the transformation of a mathematical
specification

through different representations to an
executable program


Transformations are ‘correctness
-
preserving’

so it is
straightforward to show that the program conforms to its
specification




Embodied in the ‘Cleanroom’ approach
(which was
originally developed by IBM)

to software development





Software Engineering, COMP201



Slide
15

Formal systems development

R
e
q
u
i
r
e
m
e
n
t
s
d
e
f
i
n
i
t
i
o
n
F
o
r
m
a
l
s
p
e
c
i
f
i
c
a
t
i
o
n
F
o
r
m
a
l
t
r
a
n
s
f
o
r
m
a
t
i
o
n
I
n
t
e
g
r
a
t
i
o
n

a
n
d
s
y
s
t
e
m

t
e
s
t
i
n
g




Software Engineering, COMP201



Slide
16

Formal transformations

R
2
F
o
r
m
a
l
s
p
e
c
i
f
i
c
a
t
i
o
n
R
3
E
x
e
c
u
t
a
b
l
e
p
r
o
g
r
a
m
P
2
P
3
P
4
T
1
T
2
T
3
T
4
P
r
o
o
f
s

o
f

t
r
a
n
s
f
o
r
m
a
t
i
o
n

c
o
r
r
e
c
t
n
e
s
s
F
o
r
m
a
l

t
r
a
n
s
f
o
r
m
a
t
i
o
n
s
R
1
P
1




Software Engineering, COMP201



Slide
17

Formal systems development


Problems


Need for specialised skills and training to apply the
technique


Difficult to formally specify some aspects of the
system such as the user interface


Applicability


Critical systems especially those where a safety or
security case must be made before the system is
put into operation





Software Engineering, COMP201



Slide
18

4. Reuse
-
oriented development


Based on systematic reuse

where systems are
integrated from existing components or COTS
(Commercial
-
off
-
the
-
shelf) systems


Process stages


Component analysis


Requirements modification


System design with reuse


Development and integration


This approach is becoming more important but
still limited experience with it





Software Engineering, COMP201



Slide
19

Reuse
-
oriented development

R
e
q
u
i
r
e
m
e
n
t
s
s
p
e
c
i
f
i
c
a
t
i
o
n
C
o
m
p
o
n
e
n
t
a
n
a
l
y
s
i
s
D
e
v
e
l
o
p
m
e
n
t
a
n
d

i
n
t
e
g
r
a
t
i
o
n
S
y
s
t
e
m

d
e
s
i
g
n
w
i
t
h

r
e
u
s
e
R
e
q
u
i
r
e
m
e
n
t
s
m
o
d
i
f
i
c
a
t
i
o
n
S
y
s
t
e
m
v
a
l
i
d
a
t
i
o
n




Software Engineering, COMP201



Slide
20

Process iteration


Modern development processes take iteration as
fundamental,
and try to provide ways of managing,
rather than ignoring, the risk


System requirements ALWAYS evolve in the course
of a project

so process iteration where earlier stages
are reworked is always part of the process for large
systems


Iteration

can be applied to any of the generic process
models


Two (related) approaches


Incremental development


Spiral development





Software Engineering, COMP201



Slide
21

5. 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, COMP201



Slide
22

Incremental development

V
a
l
i
d
a
t
e
i
n
c
r
e
m
e
n
t
D
e
v
e
l
o
p

s
y
s
t
e
m
i
n
c
r
e
m
e
n
t
D
e
s
i
g
n

s
y
s
t
e
m
a
r
c
h
i
t
e
c
t
u
r
e
I
n
t
e
g
r
a
t
e
i
n
c
r
e
m
e
n
t
V
a
l
i
d
a
t
e
s
y
s
t
e
m
D
e
f
i
n
e

o
u
t
l
i
n
e

r
e
q
u
i
r
e
m
e
n
t
s
A
s
s
i
g
n

r
e
q
u
i
r
e
m
e
n
t
s






t
o

i
n
c
r
e
m
e
n
t
s
S
y
s
t
e
m

i
n
c
o
m
p
l
e
t
e
F
i
n
a
l
s
y
s
t
e
m




Software Engineering, COMP201



Slide
23

Incremental development advantages


Customer value

can be delivered with each
increment so system functionality is available
earlier


Early increments

act as a prototype to help
elicit requirements for later increments


Lower risk of overall project failure


The highest priority system services



tend to receive the most testing





Software Engineering, COMP201



Slide
24

Extreme programming


New approach

to development based on the
development and delivery of
very small increments

of
functionality



Relies on constant code improvement
, user
involvement in the development team and pairwise
programming



Design

of the test suits first !


Then you perform
testing

of the system after each small
increment





Software Engineering, COMP201



Slide
25

6. Spiral development


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, COMP201



Slide
26

Spiral model of the software
process

R
i
s
k
a
n
a
l
y
s
i
s
R
i
s
k
a
n
a
l
y
s
i
s
R
i
s
k
a
n
a
l
y
s
i
s
Risk
anal
ysis
P
r
o
t
o
-
t
y
p
e

1
P
r
o
t
o
t
y
p
e

2
P
r
o
t
o
t
y
p
e

3
O
p
e
r
a
-
t
i
o
n
a
l
p
r
o
t
o
y
p
e
C
o
n
c
e
p
t

o
f
O
p
e
r
a
t
i
o
n
S
i
m
u
l
a
t
i
o
n
s
,

m
o
d
e
l
s
,

b
e
n
c
h
m
a
r
k
s
S
/
W
r
e
q
u
i
r
e
m
e
n
t
s
R
e
q
u
i
r
e
m
e
n
t
v
a
l
i
d
a
t
i
o
n
D
e
s
i
g
n
V
&
V
P
r
o
d
u
c
t
d
e
s
i
g
n
D
e
t
a
i
l
e
d
d
e
s
i
g
n
C
o
d
e
U
n
i
t

t
e
s
t
I
n
t
e
g
r
a
t
i
o
n
t
e
s
t
A
c
c
e
p
t
a
n
c
e
t
e
s
t
S
e
r
v
i
c
e
D
e
v
e
l
o
p
,

v
e
r
i
f
y
n
e
x
t
-
l
e
v
e
l

p
r
o
d
u
c
t
E
v
a
l
u
a
t
e

a
l
t
e
r
n
a
t
i
v
e
s
i
d
e
n
t
i
f
y
,

r
e
s
o
l
v
e

r
i
s
k
s
D
e
t
e
r
m
i
n
e

o
b
j
e
c
t
i
v
e
s
a
l
t
e
r
n
a
t
i
v
e
s

a
n
d
c
o
n
s
t
r
a
i
n
t
s
P
l
a
n

n
e
x
t

p
h
a
s
e
I
n
t
e
g
r
a
t
i
o
n
a
n
d

t
e
s
t

p
l
a
n
D
e
v
e
l
o
p
m
e
n
t
p
l
a
n
R
e
q
u
i
r
e
m
e
n
t
s

p
l
a
n
L
i
f
e
-
c
y
c
l
e

p
l
a
n
R
E
V
I
E
W




Software Engineering, COMP201



Slide
27

Spiral model sectors


Objective setting


Specific objectives for the phase are identified


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


Planning


The project is reviewed and the next phase of the spiral is
planned





Software Engineering, COMP201



Slide
28

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





Software Engineering, COMP201



Slide
29

The requirements engineering
process

F
e
a
s
i
b
i
l
i
t
y
s
t
u
d
y
R
e
q
u
i
r
e
m
e
n
t
s
e
l
i
c
i
t
a
t
i
o
n

a
n
d
a
n
a
l
y
s
i
s
R
e
q
u
i
r
e
m
e
n
t
s
s
p
e
c
i
f
i
c
a
t
i
o
n
R
e
q
u
i
r
e
m
e
n
t
s
v
a
l
i
d
a
t
i
o
n
F
e
a
s
i
b
i
l
i
t
y
r
e
p
o
r
t
S
y
s
t
e
m
m
o
d
e
l
s
U
s
e
r

a
n
d

s
y
s
t
e
m
r
e
q
u
i
r
e
m
e
n
t
s
R
e
q
u
i
r
e
m
e
n
t
s
d
o
c
u
m
e
n
t




Software Engineering, COMP201



Slide
30

II.

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





Software Engineering, COMP201



Slide
31

Design process activities


Architectural design


Abstract specification


Interface design


Component design


Data structure design


Algorithm design





Software Engineering, COMP201



Slide
32

The software design process

Ar
chitectur
al
design
Abstr
act
specifica
tion
Interface
design
Component
design
Da
ta
structur
e
design
Algorithm
design
System
ar
chitectur
e
Softw
ar
e
specifica
tion
Interface
specifica
tion
Component
specifica
tion
Da
ta
structur
e
specifica
tion
Algorithm
specifica
tion
R
equir
ements
specifica
tion
Design acti
vities
Design pr
oducts




Software Engineering, COMP201



Slide
33

Design methods


Systematic approaches to developing a
software design



The design

is usually documented as a set of graphical
models


Possible models


Data
-
flow model


Entity
-
relation
-
attribute model


Structural model


Object models





Software Engineering, COMP201



Slide
34

Programming and debugging


Translating a design into a program and
removing errors from that program



Programming is a personal activity

-

there is no
generic programming process



Programmers carry out some program testing

to
discover faults in the program and remove these faults
in the debugging process





Software Engineering, COMP201



Slide
35

The debugging process

L
o
c
a
t
e
e
r
r
o
r
D
e
s
i
g
n
e
r
r
o
r

r
e
p
a
i
r
R
e
p
a
i
r
e
r
r
o
r
R
e
-
t
e
s
t
p
r
o
g
r
a
m




Software Engineering, COMP201



Slide
36

III Software validation


Verification and validation

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





Software Engineering, COMP201



Slide
37

The testing process

S
u
b
-
s
y
s
t
e
m
t
e
s
t
i
n
g
M
o
d
u
l
e
t
e
s
t
i
n
g
U
n
i
t
t
e
s
t
i
n
g
S
y
s
t
e
m
t
e
s
t
i
n
g
A
c
c
e
p
t
a
n
c
e
t
e
s
t
i
n
g
C
o
m
p
o
n
e
n
t
t
e
s
t
i
n
g
I
n
t
e
g
r
a
t
i
o
n

t
e
s
t
i
n
g
U
s
e
r
t
e
s
t
i
n
g




Software Engineering, COMP201



Slide
38

Testing stages


Unit testing


Individual components are tested


Module testing


Related collections of dependent components are tested


Sub
-
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





Software Engineering, COMP201



Slide
39

Testing phases

R
e
q
u
i
r
e
m
e
n
t
s
s
p
e
c
i
f
i
c
a
t
i
o
n
S
y
s
t
e
m
s
p
e
c
i
f
i
c
a
t
i
o
n
S
y
s
t
e
m
d
e
s
i
g
n
D
e
t
a
i
l
e
d
d
e
s
i
g
n
M
o
d
u
l
e

a
n
d
u
n
i
t

c
o
d
e
a
n
d

t
e
s
s
S
u
b
-
s
y
s
t
e
m
i
n
t
e
g
r
a
t
i
o
n
t
e
s
t

p
l
a
n
S
y
s
t
e
m
i
n
t
e
g
r
a
t
i
o
n
t
e
s
t

p
l
a
n
A
c
c
e
p
t
a
n
c
e
t
e
s
t

p
l
a
n
S
e
r
v
i
c
e
A
c
c
e
p
t
a
n
c
e
t
e
s
t
S
y
s
t
e
m
i
n
t
e
g
r
a
t
i
o
n

t
e
s
t
S
u
b
-
s
y
s
t
e
m
i
n
t
e
g
r
a
t
i
o
n

t
e
s
t




Software Engineering, COMP201



Slide
40

IV 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





Software Engineering, COMP201



Slide
41

System evolution

A
s
s
e
s
s

e
x
i
s
t
i
n
g
s
y
s
t
e
m
s
D
e
f
i
n
e

s
y
s
t
e
m
r
e
q
u
i
r
e
m
e
n
t
s
P
r
o
p
o
s
e

s
y
s
t
e
m
c
h
a
n
g
e
s
M
o
d
i
f
y
s
y
s
t
e
m
s
N
e
w
s
y
s
t
e
m
E
x
i
s
t
i
n
g
s
y
s
t
e
m
s




Software Engineering, COMP201



Slide
42

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


Debuggers

to support program fault finding


Automated translators

to generate new versions of
a program





Software Engineering, COMP201



Slide
43

Case technology


Case technology has led to significant
improvements in the software process

though not the order of magnitude
improvements that were once predicted



Software engineering requires creative thought

-

this is not readily automatable



Software engineering is a team activity

and, for
large projects, much time is spent in team
interactions. CASE technology does not really
support these





Software Engineering, COMP201



Slide
44

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






Software Engineering, COMP201



Slide
45

Functional tool classification


Tool type

Examples

Planning tools

PERT tools, estimation tools,
spreadsheets

Editing tools

Text editors, diagram editors, word
processors

Change management tools

Requirements traceability tools, change
control systems

Configuration management tools

Ver
sion management systems, system
building tools

Prototyping tools

Very high
-
level languages,

user interface generators

Method
-
support tools

Design editors, data dictionaries, code
generators

Language
-
processing tools

Compilers, interpreters

Program ana
lysis tools

Cross reference generators, static
analysers, dynamic analysers

Testing tools

Test data generators, file comparators

Debugging tools

Interactive debugging systems

Documentation tools

Page layout programs, image editors

Re
-
engineering tools

Cross
-
reference systems, program re
-
structuring systems

Activity
-
based classification

R
e
e
n
g
i
n
e
e
r
i
n
g


t
o
o
l
s
T
e
s
t
i
n
g

t
o
o
l
s
D
e
b
u
g
g
i
n
g

t
o
o
l
s
P
r
o
g
r
a
m

a
n
a
l
y
s
i
s

t
o
o
l
s
L
a
n
g
u
a
g
e
-
p
r
o
c
e
s
s
i
n
g
t
o
o
l
s
M
e
t
h
o
d

s
u
p
p
o
r
t

t
o
o
l
s
P
r
o
t
o
t
y
p
i
n
g

t
o
o
l
s
C
o
n
f
i
g
u
r
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t

t
o
o
l
s
C
h
a
n
g
e

m
a
n
a
g
e
m
e
n
t

t
o
o
l
s
D
o
c
u
m
e
n
t
a
t
i
o
n

t
o
o
l
s
E
d
i
t
i
n
g

t
o
o
l
s
P
l
a
n
n
i
n
g


t
o
o
l
s
S
p
e
c
i
f
i
c
a
t
i
o
n
D
e
s
i
g
n
I
m
p
l
e
m
e
n
t
a
t
i
o
n
V
e
r
i
f
i
c
a
t
i
o
n
a
n
d
V
a
l
i
d
a
t
i
o
n




Software Engineering, COMP201



Slide
47

CASE integration


Tools


Support individual process tasks such as design
consistency checking, text editing, etc.


Workbenches


Support a process phase such as specification or
design, Normally include a number of integrated
tools


Environments


Support all or a substantial part of an entire software
process. Normally include several integrated
workbenches





Software Engineering, COMP201



Slide
48

Tools, workbenches,
environments

S
i
n
g
l
e
-
m
e
t
h
o
d
w
o
r
k
b
e
n
c
h
e
s
G
e
n
e
r
a
l
-
p
u
r
p
o
s
e
w
o
r
k
b
e
n
c
h
e
s
M
u
l
t
i
-
m
e
t
h
o
d
w
o
r
k
b
e
n
c
h
e
s
L
a
n
g
u
a
g
e
-
s
p
e
c
i
f
i
c
w
o
r
k
b
e
n
c
h
e
s
P
r
o
g
r
a
m
m
i
n
g
T
e
s
t
i
n
g
A
n
a
l
y
s
i
s

a
n
d
d
e
s
i
g
n
I
n
t
e
g
r
a
t
e
d
e
n
v
i
r
o
n
m
e
n
t
s
P
r
o
c
e
s
s
-
c
e
n
t
r
e
d
e
n
v
i
r
o
n
m
e
n
t
s
F
i
l
e
c
o
m
p
a
r
a
t
o
r
s
C
o
m
p
i
l
e
r
s
E
d
i
t
o
r
s
E
n
v
i
r
o
n
m
e
n
t
s
W
o
r
k
b
e
n
c
h
e
s
T
o
o
l
s
C
A
S
E
t
e
c
h
n
o
l
o
g
y




Software Engineering, COMP201



Slide
49

Key points


Software processes are the activities involved in
producing and evolving a software system. They are
represented in a software process model


General activities are specification, design and
implementation, validation and evolution


Generic process models describe the organisation of
software processes


Iterative process models describe the software process
as a cycle of activities





Software Engineering, COMP201



Slide
50

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 to its
specification and user needs


Evolution is concerned with modifying the system after it
is in use


CASE technology supports software process activities