An Overview of

offbeatnothingSoftware and s/w Development

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

48 views

CMSC 345, Version 1/03

An Overview of

Software Processes

Reference:
Software Engineering
, by
Ian Sommerville, 6
th

edition, Chapter 3

CMSC 345, Version 1/03

Objectives


To introduce the general phases of the
software (development) life cycle


To describe various generic
software
process models

and their pros and cons


CMSC 345, Version 1/03

Software Life Cycle


The phases necessary to develop and
maintain a software system. These phases
include:


Requirements (Specification)


Design


Implementation (Coding)


Testing (Validation)


Maintenance (Evolution)


A
software process model

is an abstract
representation of how these phases can be
addressed.

CMSC 345, Version 1/03

Requirements


The process of establishing


what services are required of the
system


the constraints on the system’s
operation and development


The “what” of the software life cycle

CMSC 345, Version 1/03

A Generic Requirements 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
CMSC 345, Version 1/03

Design


The process of converting the system
specification (requirements) into a software
structure that realizes that specification


The “how” of the software life cycle


CMSC 345, Version 1/03

A Generic 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
CMSC 345, Version 1/03

Implementation


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.


The activities of design and implementation
are closely related and may be interleaved.

CMSC 345, Version 1/03

Testing


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.

CMSC 345, Version 1/03

A Generic 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
CMSC 345, Version 1/03

V
-
Model of Test Planning

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
CMSC 345, Version 1/03

System Maintenance


Software is inherently flexible and can change
(as opposed to hardware).


In the past, there has been a demarcation
between development and evolution
(maintenance). This is increasingly irrelevant
as fewer and fewer systems are completely
new.


Software engineering should be thought of as
an evolutionary process where software is
continually changed over its lifetime in
response to customer needs.

CMSC 345, Version 1/03

Software Process Models


Waterfall model (Royce, 1970)


Prototyping


Throwaway


Evolutionary


Incremental development


Spiral model (Boehm, 1988)

CMSC 345, Version 1/03

Waterfall Model

Requirements

Design

Implementation

Maintenance

Testing

CMSC 345, Version 1/03

Observations


The following phase should not start until the
previous phase has finished.


In practice,


Phases overlap


May return to a previous phase


Still widely used, especially on very large
projects

CMSC 345, Version 1/03

Waterfall Model Pros and Cons

Pros




Cons

CMSC 345, Version 1/03

Prototyping

Requirements

Implementation

Design

Testing

Design

Implementation

Testing

Maintenance

CMSC 345, Version 1/03

Observations


Used for requirements elicitation and
validation


A “working” model (prototype) of the final
system is developed during requirements


Is an
iterative

process


Prototype can be thrown away or evolved
into the final system (
evolutionary
prototyping
)

CMSC 345, Version 1/03

Prototyping Pros and Cons

Pros




Cons

CMSC 345, Version 1/03

Throwaway vs. Evolutionary

Throwaway pros




Evolutionary pros

CMSC 345, Version 1/03

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
CMSC 345, Version 1/03

Observations


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.


Is an iterative process

CMSC 345, Version 1/03

Incremental Pros and Cons

Pros




Cons

CMSC 345, Version 1/03

Spiral Model

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
CMSC 345, Version 1/03

Observations


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.


Uses
prototyping

CMSC 345, Version 1/03

Things to Think About


What about modifying existing software?


What about using existing software?


In
-
house modules


COTS (Commercial Off
-
The
-
Shelf)