Software Processes

Overview
Don Evans CSE
http://lyle.smu.edu/~devans/4345/SW%20Process%20Overview.ppt

The Software Development

Process
A structured set of activities required to develop a
software system

Specification;
Design;
Implementation;
Validation;
Evolution.

A software process model is an abstract

representation of a process. It presents a
description of a process from some particular
perspective.
2

Generic Software Process

Models
The waterfall model
Separate and distinct phases of specification and
development.

Evolutionary development
Specification, development and validation are
interleaved.

Component-based software engineering

The system is assembled from existing components.

There are many variants of these models e.g.

formal development where a waterfall-like process
is used but the specification is a formal
specification that is refined through several stages
to an implementable design.
3

Waterfall Model
Requirements
defi nition
System and
software design
Implementa
tion
and unit testing
Integration and
system testing
Operation and
maintenance

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 wellunderstood and changes will be fairly
limited during the design process.
Few business systems have stable
requirements.
5

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 and add new features as
proposed by the customer.

Throw-away prototyping
Objective is to understand the system
requirements. Should start with poorly
understood requirements to clarify what is
really needed.
6

Evolutionary development
Concurrent
activities

Specifi ca
tion

Outline
description

Development

Validation

Initial
version

Intermediate
versions

Final
version

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

Component-Based Software
Engineering
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 increasingly used

as component standards have emerged.

A Reuse-Oriented
Development Process
Requirements
specifi cation

Component
analysis

Requirements
modifi cation

System design
with reuse

Development
and integ
ration

System
validation

10

Process Iteration
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 delivery;
Spiral development.

11

Incremental delivery
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.

12

Incremental development

Defi ne outline
requirements

Develop system
increment

Assign requirements
to increments

Validate
increment

Design system
architectur
e

Integrate
increment

Validate
system
Final
system

System incomplete

13

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

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

Spiral model of the software

process
Determine objectives,
alternatives and
constraints

Evaluate alternatives,
identify, resolve risks

Risk
analysis
Risk
analysis
Risk
analysis

REVIEW
Requirements plan
Life-cycle plan

Plan ne xt phase

Operational
protoype

Pr ototype 3

Pr ototype 2
Risk
analysis Pr ototype 1

Simulations, models, benchmarks

Concept of
Operation

S/W
requirements

Development
plan

Requirement
validation

Integration
and test plan

Design
V&V
Acceptance
test
Service

Product
design

Detailed
design
Code

Unit test
Integration
test
Develop, verify
next-level product

16

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

Process activities

Software
Software
Software
Software

specification
design and implementation
validation
evolution

18

Software Specification
The process of establishing what
services are required and the
constraints on the systems operation
and development.
Requirements engineering process
Feasibility study;
Requirements elicitation and analysis;
Requirements specification;
Requirements validation.
19

The Requirements Engineering

Process
Feasibility
study

Requirements
elicitation and
analy sis
Requirements
specifi cation
Requirements
validation

Feasibility
report
System
models
User and system
requirements

Requirements
document

20

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

Design Process Activities

Architectural design
Abstract specification
Interface design
Component design
Data structure design
Algorithm design

22

The Software Design

Process
Requir
ements
specifi ca
tion
Design acti
vities
Architectur
al
design

Abstract
specifi ca
tion

Interface
design

Component
design

Data
structur
e
design

Algorithm
design

System
architectur
e

Software
specifi ca
tion

Interface
specifi ca
tion

Component
specifi ca
tion

Data
structur
e
specifi ca
tion

Algorithm
specifi ca
tion

Design pr
oducts

23

Structured Methods
Systematic approaches to developing a
software design.
The design is usually documented as a
set of graphical models.
Possible models
Object model;
Sequence model;
State transition model;
Structural model;
Data-flow model.
24

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

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

The testing process

Component
testing

System
testing

Ac c eptanc e
testing

27

Testing stages
Component or unit 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.

Acceptance testing
Testing with customer data to check that the
system meets the customers needs.

28

Testing Phases

Requirements
specifi ca
tion

System
specifi ca
tion

System
integration
test plan

Acceptance
test plan

Service

System
design

Acceptance
test

Detailed
design

Sub-system
integration
test plan

System
integration test

Module and
unit code
and test

Sub-system
integration test

29

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.

30

System evolution

Defi ne system
requirements

Assess existing
systems

Existing
systems

Propose system
changes

Modify
systems

New
system

31

The Rational Unified Process

A modern process model derived from
the work on the UML and associated
process.
Normally described from 3 perspectives
A dynamic perspective that shows phases
over time;
A static perspective that shows process
activities;
A practive perspective that suggests good
practice.
32

RUP Phases
Inception
Establish the business case for the system.

Elaboration
Develop an understanding of the problem
domain and the system architecture.

Construction
System design, programming and testing.

Transition
Deploy the system in its operating environment.
33

RUP Best Practice

Develop software iteratively

Manage requirements
Use component-based architectures
Visually model software
Verify software quality
Control changes to software

34

Best Practice 1: Develop

Iteratively

35

Waterfall Development
Characteristics
WaterfallProcess
Requirements
analysis
Design
Codeandunittest
Subsystemintegration
Systemtest

Delays confirmation of
critical risk resolution
Measures progress by
assessing work-products
that are poor predictors of
time-to-completion
Delays and aggregates
integration and testing
Precludes early deployment
Frequently results in major
unplanned iterations
36

Iterative Development
Produces an Executable
Requirements
Analysis & Design
Planning
Implementation

Initial
Planning

Management
Environment
Test
Evaluation
Each iteration
results in an
executable release

Deployment

37

Risk Profiles

Risk

WaterfallRisk

RiskReduction
RiskReduction

IterativeRisk

Time
38

Best Practice 2: Manage

Requirements

39

Aspects of Requirements
Management

Analyze the Problem

Understand User Needs
Define the System
Manage Scope
Refine the System Definition
Manage Changing Requirements

40

Best Practice 3: Use

Component-Based
Architectures

41

Purpose of a Component-Based
Architecture
Basis for reuse

Component reuse
Architecture reuse

Component-based
architecture with
layers

Basis for project management

Planning
Staffing
Delivery

Intellectual control

Manage complexity
Maintain integrity

Applicationspecific
Businessspecific
Middleware
Systemsoftware

42

Best Practice 4: Model

Visually

43

Visual Modeling with Unified Modeling Language

Multiple views
Precise syntax and semantics

Sequence
Diagrams

Collaboration
Diagrams

Dynamic
Diagrams

Statechart
Diagrams

Class
Diagrams

Use-Case
Diagrams

Object
Diagrams

Component
Diagrams

Models

Activity
Diagrams

Deployment
Diagrams

Static
Diagrams

44

Best Practice 5:
Continuously Verify Quality

45

Continuously Verify Your

Softwares Quality
Software problems are
100 to 1000 times more costly
to find and repair after deployment

CosttoRepairSoftware
CostofLostOpportunities
Cost

CostofLostCustomers

Inception

Elaboration

Construction

Transition
46

Test Each Iteration

Iteration1

Iteration2

Iteration3

Iteration4

TestSuite1

TestSuite2

TestSuite3

TestSuite4

UMLModel
and
Implementation

Tests

47

Best Practice 6: Manage

Change

48

Aspects of a CM System

Change Request Management (CRM)

Configuration Status Reporting
Configuration Management (CM)
Change Tracking
Version Selection
Software Manufacture

49

RUP is Organization Along Time

Time

Organizationbyphaseshelpsminimizetherisksofresourceallocation.
50

Major Milestones: Business Decision Points

Productsufficiently
matureforcustomers
Commitresources
forconstruction

Customer
acceptance
orendoflife

Commitresourcesfor
theelaborationphase

Inception

Elaboration

Construction

Transition

time
Lifecycle
Objective
Milestone

Lifecycle
Architecture
Milestone

InitialOperational
Capability
Milestone

Product
Release

51

What Is an Iteration?

52

Iteration: Number and

Duration
Duration driven by
+ size of organization
+ size of project
- familiarity with the process, maturity
- technical simplicity

6, plus or minus 3
Inception:
Elaboration:
Construction:
Transition:

0 .. 1
1 .. 3
1 .. 3
1 .. 2
53

One Iteration
Inan
iteration,you
walkthrough
alldisciplines.

54

Content

Organization Based on
Content

55

Nine Disciplines

56

Artifact Set Evolution Over the Development

Phases

With the
iterative
approach,
artifact sets
mature over
time.
57