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
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:
Process, systematic (not ad hoc), evolutionary…
Constraints: high quality, cost, time, meets user
requirements
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 evolution
► 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
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 to develop applications 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!!
► We are doing something wrong as an industry!
What Happens in Practice
Sequential activities: (Traditional ‘Waterfall’ Process)
Requirements Design Code Integration Test
100% Integration
Begins
Development Progress
Risk inadequately addressed
Process not receptive to Change Late Design
Problems not really ‘seen’ Breakage
(% coded)
until near delivery date!
Until then, ‘all is well…’
Big Bang approach – full delivery
Long development cycles…
Little user involvement, etc. etc… Original
Target Date
Project Schedule
Symptoms of Software
Development Problems
► Inaccurate understanding of end-user needs
► Inability to deal with changing requirements
► Modules that don’t fit together (integration)
► Software that’s 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 (Risk, architecture, …)
► Team members in each other’s 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…
Best Practices of Software
Engineering
Develop Iteratively
Use
Manage Model Verify
Component Visually
Requirements Architectures Quality
Control Changes
Know these!
Addressing Root Causes
Eliminates the Symptoms
Symptoms Root Causes Best Practices
end-user needs insufficient requirements develop iteratively
changing ambiguous manage requirements
requirements communications use component
modules don’t fit brittle architectures architectures
hard to maintain overwhelming complexity model the software
late discovery undetected visually
poor quality inconsistencies verify quality
poor performance poor testing control changes
colliding developers subjective assessment
build-and-release waterfall development
uncontrolled change
insufficient automation
Practice 1: Develop Software
Iteratively
Develop Iteratively
Use
Manage Model Verify
Component Visually
Requirements Architectures Quality
Control Changes
Considered by many practitioners to be the most significant of the six
Practice 1: Develop Software Iteratively
► Until recently, we were developing systems
under the assumption that 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
start—are a very significant fact of software
development life, ranging from around 25% on
average projects up to 50% on larger ones.
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 – during development!
► While large projects are more prone to cost overruns,
medium-size/small projects are vulnerable to cancellation.
► The key reasons continue to be
poor project planning and management,
shortage of technical and project management expertise,
lack of technology infrastructure,
disinterested senior management, and
inappropriate project teams.”
Waterfall Delays Risks Walker Royce, 1995
R Requirements
I Design
S Code
Waterfall risk
K Integration
System
Test
T I M E
Iterative Development
Iteration 1 Iteration 2 Iteration 3
• Earliest iterations address greatest risks
• Each iteration produces an executable release
• Each iteration includes integration and test
Accelerate Risk Reduction Walker Royce, 1995
I Risk reduction
S
Waterfall risk
K Iterative
Iteration Iteration Iteration Iteration Iteration
T I M E
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.
► Objective milestones provide short-term focus
► Progress measured by assessing implementations
► Partial implementations can be deployed
Waterfall method – no delivery
Incremental development? May be some great
values in delivering key parts of application.
Critical components delivered first?
► No big-bang approach!
Iterative Lifecycle Graph
In an iteration,
you may walk
C through all
O
N
disciplines
T
E
N
T
S
T
R
U
C
T
U
R
E
TIME
RUP Iterations and Phases
Executable Releases
Inception Elaboration Construction Transition
Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition
Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration
An iteration is a distinct sequence of activities
with an established plan and evaluation criteria,
resulting in an executable release.
Problems Addressed by Iterative Development
Root Causes Solutions
Insufficient requirements Enables and encourages user
feedback
Ambiguous
communications Serious misunderstandings
evident early in the life cycle
Brittle architectures
Overwhelming Development focuses on critical
complexity issues – break it down!
Subjective assessment Objective assessment thru
Undetected testing
inconsistencies
Inconsistencies detected early
Poor testing
Waterfall development Testing starts earlier –
Uncontrolled change continuous!
Insufficient automation Risks identified and addressed
early - via planned iterations!
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 that ‘some’ Rework enables you to enhance
your solution
Accommodate change early in the project
► Trap: Iterative development does not mean never to commit
to commit to a solution
► Monitor ‘scrap and rework’
► Trap: Must Control “requirement creep, ” however… Some
clients will now naturally recognize many ‘musts…’
Many Traps in Iterative Development
Here is another trap: Too long initial iteration
► Winning is fun. A winning team works better than a loosing
team
► 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 within a phase)
► Not completing iterations makes you lose most of the benefit
► Focus on results and deliverables, not activities
Problem: Dangerous Iteration
Patterns
Teams not synchronized -> chaos
First iteration too loaded -> panic
Too much overlap -> no feedback loop
Problem: Fixed Plans Produced
Upfront – not practical!
►Trap: Fine grained planning from start to end
►Too much uncertainty makes detailed
plans for the entire project meaningless
►Does not mean that we should not plan
Establish milestones and track progress
relative to milestones
Solution: Plan With Evolving
Levels of Detail
Coarse-grained Plan: Software Fine-grained Plans:
Development Plan Iteration Plans
One For Entire Project Next Iteration
Phases and major milestones
What and when
Iterations for each phase
Number of iterations Current Iteration
Objectives and Duration
Iterative does not mean less work and shorter schedule
It is about greater predictability
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
►Generally, initial iterations based on high risk
and core functionalities!
The Iteration Plan Defines….
The deliverables for
that iteration.
The to do list for the
team members
Project progress is made against
MILESTONES
►Each phase is defined by a milestone.
►Progress is made by passing milestones.
►Phases - NOT TIMEBOXED.
►Iterations ARE TIMEBOXED.
►Milestones measure success
Major Milestones
Inception Elaboration Construction Transition
► 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.