Software Engineering

and
Best Practices
Sources: Various.
Rational Software Corporation slides,
OOSE textbook slides, Per Kroll talk, How to Fail
with the RUP article, textbooks
Most slides have been modified considerably
30

Fundamental Terms /
Concepts
Science

and Engineering

Discover
Relationships

that exist but are not found

Formulas; chemical composition, d=r*t; calories in
fats, carbohydrates, proteins; experimentation;
Astrophysics origins of the universe

Build
Apply

principles of science and mathematics to real

needs, commodities, structures, products, etc.

Software

Engineering; Software
Development

30

Fundamental Concepts / Terms

(2)
Software

Engineering; Software
Development
Job positions:

30

Software developer
Programmer
Software engineer
Analyst / Programmer
Senior what have you
3

What is Software
Engineering?
The

process of solving customers problems

by the systematic development and
evolution of large, high-quality software
systems within cost, time and other
constraints

Note:

30

Process, systematic (not ad hoc), evolutionary

Constraints: high quality, cost, time, meets
user requirements
4

Analysis of the Definition:

Systematic development and evolution

An engineering process involves applying well understood techniques

in a organized and disciplined way
Many well-accepted practices have been formally standardized

e.g. by the IEEE or ISO

Most development work is evolutionary

Large, high quality software systems

Software engineering techniques are needed because large systems

cannot be completely understood by one person
Teamwork and co-ordination are required
Key challenge: Dividing up the work and ensuring that the parts of the
system work properly together
The end-product that is produced must be of sufficient quality

Cost, time and other constraints

30

Finite resources
The benefit must outweigh the cost
Others are competing to do the job cheaper and faster
Inaccurate estimates of cost and time have caused many project
failures

Comments:

$250 billion annually in US.

Over 175,000 projects!
Complexity, size, distribution, importance push
our limits.
Business pushes these limits:

Great demands for rapid development and deployment

Incredible pressure: develop systems that are:

On time,
Within budget,
Meets the users requirements

Figures in the late 90s indicated that at most

70% of projects completed
Over 50% ran over twice the intended budget
$81 billion dollars spent in cancelled projects!!

30

Getting better, but we need better tools and

techniques!

What Happens in Practice

Sequential activities: (Traditional Waterfall Process)
Requirements
Design
Code
Integration
Test

Development Progress
(% coded)

100%

30

Integration
Begins
Risk inadequately addressed
Process not receptive to
Change
Problems not really seen
until near delivery date!
Until then, all is well
Big Bang approach full
delivery
Long development cycles
Little user involvement, etc.
etc
Project Schedule

Late Design
Breakage

Original
Target Date

Symptoms of Software
Development Problems

30

Inaccurate understanding of end-user needs

Inability to deal with changing requirements
Modules that dont fit together (integration)
Software thats hard to maintain or extend (brittle)
Late discovery of serious project flaws (integration)
Poor software quality (architecture, risks
unanticipated)
Process not responsive to Change (Gantt Charts)
Unacceptable software performance
Team members in each others way, unable to
reconstruct who changed what, when, where, why
(software architecture,
and we could go on and on

Need a Better Hammer!

We

need a process that

Will serve as a framework for large scale and small

projects
Adaptive embraces change!
Opportunity

for improvement not identification of failure!

Iterative (small, incremental deliverables)

Risk-driven (identify / resolve risks up front)
Flexible, customizable process (not a burden;
adaptive to projects)
Architecture-centric (breaks components into
layers or
common areas of responsibility)
Heavy user involvement

Identify

best ways of doing things a better

process acknowledged by world leaders

30

Best Practices of Software

Engineering
Develop Iteratively

Use
Manage
Component
Requirements Architectures

Model
Visually

Verify
Quality

Control Changes

Know these!
30

10

Addressing Root Causes

Eliminates the Symptoms
Symptoms

Root Causes

Best Practices

end-user needs

insufficient requirements

develop iteratively

changing
requirements

ambiguous
communications

manage requirements

modules dont fit

brittle architectures

hard to maintain

overwhelming complexity

late discovery

undetected
inconsistencies

poor quality
poor performance
colliding developers
build-and-release

poor testing

use component
architectures
model the software
visually
verify quality
control changes

subjective assessment
waterfall development
uncontrolled change
insufficient automation

Symptoms of problems can be traced to having Root Causes.

Best Practices are practices designed to address the root causes of software p
30

11

Practice 1: Develop Software

Iteratively
Develop Iteratively

Manage
Requirements

Use
Component
Architectures

Model
Visually

Verify
Quality

Control Changes

Considered by many practitioners to be the most significant of t

30

12

Practice 1: Develop Software

Iteratively

Until

recently, developed under assumption most requirements can be identified up front.

The

research deconstructing this myth

includes work by Capers Jones. (See next
slide) In this very large study of 6,700
projects, creeping requirements those not
anticipated near the startare a very
significant fact of software development life ,
ranging from around 25% on average projects
up to 50% on larger ones.

30

13

 Look up a definition of Function Points

30

14

Interestingly,

An initial design will likely be flawed with respect to its key

requirements. Requirements rarely fully known up front!
Late-phase discovery of design defects results in costly
over-runs and/or project cancellation
Oftentimes requirements change even during implementation!

While large projects are more prone to cost overruns,

medium-size/small projects are vulnerable to cancellation.
The key reasons continue to be

30

poor project planning and management,

shortage of technical and project management expertise,
lack of technology infrastructure,
disinterested senior management, and
inappropriate project teams.
15

Waterfall Delays Risks

Walker Royce, 1995

R
I
S
K

Requirements
Design
Code

Waterfall risk
Integration
System
Test

30

T I M E

16

Iterative Development
Iteration 1

Iteration 2

Iteration 3

Earliest iterations address greatest risks

Each iteration produces an executable release
Each iteration includes integration, test, and assessment!
30
17
Objective
Milestones: short-term focus; short term successes!

Accelerate Risk Reduction

Walker Royce, 1995

R
I

Risk
Riskreduction
reduction

Iterative

Iteration
30

Waterfall risk

Iteration

Iteration
T I M E

Iteration

Iteration
18

Iterative Development Characteristics

Critical risks are resolved before

making large investments
Initial iterations enable early user
feedback

Easy to resolve problems early.

Encourages user feedback in meaningful ways

Testing and integration are continuous

assures successful integration (parts all
fit)
Continuous testing.

30

Objective milestones provide short-term

focus
Progress measured by assessing
implementations
Partial implementations can be
deployed

19

UP Lifecycle Graph Showing

Iterations
STUDY THIS!!!
In an iteration,
you may walk
through all
disciplines

C
O
N
T
E
N
T
S
T
R
U
C
T
U
R
E
30

20

TIME

Unified Process Iterations and

Phases
Executable Releases

Inception

Elaboration

Preliminary Architect. Architect.

Iteration
Iteration
Iteration

Construction
Devel.
Iteration

Devel.
Iteration

Transition
Devel.
Iteration

Transition Transition
Iteration
Iteration

An iteration is a distinct sequence of activities

with an established plan and evaluation criteria,
resulting in an executable release.
(There is a lot of very important key terminology used here
(cycle, iteration, phase, milestones, core disciplines, content
of iterations, etc.)
30

21

Problems Addressed by Iterative

Development
Root Causes

30

Insufficient
requirements
Ambiguous
communications
Brittle architectures
Overwhelming
complexity
Subjective assessment
Undetected
inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation

Solutions

Enables and encourages user

feedback
Serious misunderstandings
evident early in the life cycle
Development focuses on
critical issues break it
down!
Objective assessment thru
testing and assessment
Inconsistencies detected
early
Testing starts earlier
continuous!
Risks identified and

22

No Free Lunch - Traps

Abound
Major

impacts on Project Managers, though.

Trap: When the initial risks are mitigated, new ones emerge
Do not do just the easy stuff, to look good.
Keep re-planning based on all new information.
Trap: Remember some Rework enables you to enhance your
solution
Accommodate change early in the project
Trap: Iterative development does not mean never to commit to a
solution

Monitor

scrap and rework

Trap: Must Control requirement creep, however Some

clients will now naturally recognize many musts

30

23

Many Traps in Iterative

Development
Here is another trap: Too long initial iteration

Winning is fun. Winning teams work better than loosing

teams

Better to have a short initial iteration, than one too

long
Cut scope if necessary (much more later)

Avoid analysis-paralysis by time-boxing; you can

enhance in later iterations (more later)

Establish an even rhythm for project (at least w/i a

phase)

30Focus

on results and deliverables, not activities

24

Iterations Are Time-boxed

Work

is undertaken within an iteration.

The iteration plan defines the artifacts to be
delivered, roles and activities.
An iteration is clearly measurable.
Iterations

are risk-driven
Iterations are planned.
Iterations

are assessed!
Generally, initial iterations (in Construction)
based on high risk and core functionalities!
30

25

The Iteration Plan Defines.

The deliverables for
that iteration.

artifacts

The to do list for the

team members
30

26

Problem:

Fixed Plans Produced Upfront

Not Real Practical!
Yet,

senior management wants firm, fixed plans!

Part of their culture / upbringing/ experience

Necessary for planning budgeting, etc. of resources, projects. BUT:
Trap:

Fine-grained planning from start to end?

Takes too much time

Frustrating as change occurs (and it will), if plans too fine-grained.
Know

that: Projects typically have some degree of

uncertainty
This makes detailed plans for the entire project meaningless
Does
30

not mean that we should not plan

27

Solution:

Plan With Evolving Levels of

Coarse-grained Plan: Detail
Fine-grained Plans:
Software Development Plan

Iteration Plans

One For Entire Project

Next Iteration

Phases and major milestones

What and when
Iterations for each phase
Number of iterations
Objectives and Duration

Current Iteration

Iterative Development does not mean less work and shorter schedule
It is about greater predictability
30

28

Progress is made against

MILESTONES
In

the Unified Process:

Each phase is defined by a milestone.

Progress is made by passing milestones.
Milestones measure success
Phases

- NOT TIMEBOXED.
Iterations ARE TIMEBOXED.
Major Milestones
Inception

30

Elaboration

Construction

Transition

29

Summary
Much

more about iteration and

iteration planning later in the course

You

will see some of these again and,

more importantly, use this information
in your own iteration planning.

30

30