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

1. 3030
Software EngineeringSoftware Engineering
andand
Best PracticesBest Practices
Sources: Various.Sources: Various.
Rational Software Corporation slides,Rational Software Corporation slides,
OOSE textbook slides, Per Kroll talk, How to Fail withOOSE textbook slides, Per Kroll talk, How to Fail with
the RUP article, textbooksthe RUP article, textbooks
Most slides have been modified considerablyMost slides have been modified considerably

2. 30 2
Fundamental Terms / ConceptsFundamental Terms / Concepts
►Science and EngineeringScience and Engineering
 DiscoverDiscover
►Relationships that exist but are not foundRelationships that exist but are not found
►Formulas; chemical composition, d=r*t; calories in fats,Formulas; chemical composition, d=r*t; calories in fats,
carbohydrates, proteins; experimentation;carbohydrates, proteins; experimentation;
►Astrophysics – origins of the universeAstrophysics – origins of the universe
 BuildBuild
►Apply principles of science and mathematics to realApply principles of science and mathematics to real
needs, commodities, structures, products, etc.needs, commodities, structures, products, etc.
►Software Engineering; Software DevelopmentSoftware Engineering; Software Development

3. 30 3
Fundamental Concepts / Terms (2)Fundamental Concepts / Terms (2)
►Software Engineering; Software DevelopmentSoftware Engineering; Software Development
►Job positions:Job positions:
 Software developerSoftware developer
 ProgrammerProgrammer
 Software engineerSoftware engineer
 Analyst / ProgrammerAnalyst / Programmer
 Senior … what have you…Senior … what have you…

4. 30 4
What is Software Engineering?What is Software Engineering?
►The process of solving customers’ problemsThe process of solving customers’ problems
by the systematic development and evolutionby the systematic development and evolution
of large, high-quality software systems withinof large, high-quality software systems within
cost, time and other constraintscost, time and other constraints
►Note:Note:
 Process, systematic (not ad hoc), evolutionary…Process, systematic (not ad hoc), evolutionary…
 Constraints: high quality, cost, time, meets userConstraints: high quality, cost, time, meets user
requirementsrequirements

5. 30 5
Analysis of the Definition:Analysis of the Definition:
► Systematic development and evolutionSystematic development and evolution
 An engineering process involves applyingAn engineering process involves applying well understood techniqueswell understood techniques in ain a
organizedorganized andand disciplineddisciplined wayway
 ManyMany well-accepted practices have been formally standardizedwell-accepted practices have been formally standardized
► e.g. by the IEEE or ISOe.g. by the IEEE or ISO
 Most development work isMost development work is evolutionaryevolutionary
► Large, high quality software systemsLarge, high quality software systems
 Software engineering techniques are needed because large systemsSoftware engineering techniques are needed because large systems cannot becannot be
completely understoodcompletely understood by one personby one person
 TeamworkTeamwork and co-ordination are requiredand co-ordination are required
 Key challenge: Dividing up the work and ensuring that the parts of the systemKey challenge: Dividing up the work and ensuring that the parts of the system
work properly togetherwork properly together
 The end-product that is produced must be of sufficient qualityThe end-product that is produced must be of sufficient quality
► Cost, time and other constraintsCost, time and other constraints
 Finite resourcesFinite resources
 The benefit must outweigh the costThe benefit must outweigh the cost
 Others are competing to do the job cheaper and fasterOthers are competing to do the job cheaper and faster
 Inaccurate estimates of cost and time have caused many project failuresInaccurate estimates of cost and time have caused many project failures

6. 30 6
Comments:Comments:
► $250 billion annually in US.$250 billion annually in US.
► Over 175,000 projects!Over 175,000 projects!
► Complexity, size, distribution, importance push ourComplexity, size, distribution, importance push our
limits.limits.
► Business pushes these limits:Business pushes these limits:
 Great demands forGreat demands for rapid development and deploymentrapid development and deployment
►  Incredible pressure: develop systems that are:Incredible pressure: develop systems that are:
 On time,On time,
 Within budget,Within budget,
 Meets the users’ requirementsMeets the users’ requirements
► Figures in the late 90s indicated that at mostFigures in the late 90s indicated that at most
 70% of projects completed70% of projects completed
 Over 50% ran over twice the intended budgetOver 50% ran over twice the intended budget
 $81 billion dollars spent in cancelled projects!!$81 billion dollars spent in cancelled projects!!
► Getting better, but we need better tools andGetting better, but we need better tools and
techniques!techniques!

7. 30 7
What Happens in PracticeWhat Happens in Practice
Sequential activities: (Traditional ‘Waterfall’ Process)
Requirements Design Code Integration Test
Late Design
Breakage
100%
Project Schedule
DevelopmentProgress
(%coded)
Original
Target Date
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…

8. 30 8
Symptoms of SoftwareSymptoms of Software
Development ProblemsDevelopment Problems
► Inaccurate understandingInaccurate understanding of end-user needsof end-user needs
► Inability to deal withInability to deal with changing requirementschanging requirements
► Modules that don’t fit together (integration)Modules that don’t fit together (integration)
► Software that’s hard to maintain or extend (brittle)Software that’s hard to maintain or extend (brittle)
► Late discovery ofLate discovery of serious project flawsserious project flaws (integration)(integration)
► Poor software qualityPoor software quality (architecture, risks unanticipated…)(architecture, risks unanticipated…)
► ProcessProcess not responsive to Change (Gantt Charts…)not responsive to Change (Gantt Charts…)
► Unacceptable software performanceUnacceptable software performance
► Team members in each other’s way, unable to reconstruct whoTeam members in each other’s way, unable to reconstruct who
changed what, when, where, why (software architecture, …changed what, when, where, why (software architecture, …
► ……and we could go on and on…and we could go on and on…

9. 30 9
► We need aWe need a processprocess thatthat
 Will serve as a framework for large scale and smallWill serve as a framework for large scale and small
projectsprojects
  Adaptive – embraces ‘change!’Adaptive – embraces ‘change!’
► Opportunity forOpportunity for improvementimprovement not identification ofnot identification of failurefailure!!
 Iterative (small, incremental ‘deliverables’)Iterative (small, incremental ‘deliverables’)
 Risk-driven (identify / resolve risks up front)Risk-driven (identify / resolve risks up front)
 Flexible, customizable process (not a burden; adaptive toFlexible, customizable process (not a burden; adaptive to
projects)projects)
 Architecture-centric (breaks components into ‘layers’ orArchitecture-centric (breaks components into ‘layers’ or
common areas of responsibility…)common areas of responsibility…)
 HeavyHeavy user involvementuser involvement
► Identify best ways of doing things – a better processIdentify best ways of doing things – a better process
– acknowledged by world leaders…– acknowledged by world leaders…
Need a Better Hammer!

10. 30 10
Develop IterativelyDevelop Iteratively
Control ChangesControl Changes
UseUse
ComponentComponent
ArchitecturesArchitectures
ManageManage
RequirementsRequirements
ModelModel
VisuallyVisually
VerifyVerify
QualityQuality
Best Practices of SoftwareBest Practices of Software
EngineeringEngineering
Know these!

11. 30 11
Symptoms
end-user needs
changing
requirements
modules don’t fit
hard to maintain
late discovery
poor quality
poor performance
colliding developers
build-and-release
Root Causes
insufficient requirements
ambiguous
communications
brittle architectures
overwhelming complexity
undetected
inconsistencies
poor testing
subjective assessment
waterfall development
uncontrolled change
insufficient automation
Best Practices
develop iteratively
manage requirements
use component
architectures
model the software
visually
verify quality
control changes
Addressing Root CausesAddressing Root Causes
Eliminates the SymptomsEliminates the Symptoms
Symptoms of problems can be traced to having Root Causes.
Best Practices are ‘practices’ designed to address the root causes of software problems.

12. 30 12
Practice 1: Develop SoftwarePractice 1: Develop Software
IterativelyIteratively
Develop IterativelyDevelop Iteratively
Control Changes
Use
Component
Architectures
Manage
Requirements
Model
Visually
Verify
Quality
Considered by many practitioners to be the most significant of the six

13. 30 13
Practice 1: Develop Software IterativelyPractice 1: Develop Software Iteratively
►Until recently, developed under assumption -Until recently, developed under assumption -
most requirements can be identified up front.most requirements can be identified up front.
►The research deconstructing this myth includesThe research deconstructing this myth includes
work by Capers Jones. (See next slide) In thiswork by Capers Jones. (See next slide) In this
very large study of 6,700 projects,very large study of 6,700 projects, creepingcreeping
requirementsrequirements — those not anticipated near the— those not anticipated near the
start—are astart—are a very significant fact of softwarevery significant fact of software
development lifedevelopment life, ranging from around 25% on, ranging from around 25% on
average projects up to 50% on larger ones.average projects up to 50% on larger ones.

14. 30 14
 Look up a definition of ‘Function Points.’

15. 30 15
Interestingly,Interestingly,
► An initial design willAn initial design will likely be flawedlikely be flawed with respect to its keywith respect to its key
requirements. Requirements rarelyrequirements. Requirements rarely fully knownfully known up front!up front!
► Late-phase discovery of design defectsLate-phase discovery of design defects results in costlyresults in costly
over-runs and/or project cancellationover-runs and/or project cancellation
 Oftentimes requirements change – even during implementation!Oftentimes requirements change – even during implementation!
► While large projects are more prone to cost overruns,While large projects are more prone to cost overruns,
medium-size/small projects are vulnerable to cancellation.medium-size/small projects are vulnerable to cancellation.
► The key reasons continue to beThe key reasons continue to be
 poor project planning and management,poor project planning and management,
 shortage of technical and project management expertise,shortage of technical and project management expertise,
 lack of technology infrastructure,lack of technology infrastructure,
 disinterested senior management, anddisinterested senior management, and
 inappropriate project teams.”inappropriate project teams.”

16. 30 16
Waterfall Delays RisksWaterfall Delays Risks
R
I
S
K
T I M E
Integration
System
Test
Code
Design
Requirements
Waterfall risk
Walker Royce, 1995

17. 30 17
Iterative DevelopmentIterative Development
 Earliest iterations address greatest risks
• Each iteration produces an executable release
• Each iteration includes integration, test, and assessment!
• Objective Milestones: short-term focus; short term successes!
Iteration 1 Iteration 2 Iteration 3

18. 30 18
Accelerate Risk ReductionAccelerate Risk Reduction
Iterative
T I M E
Iteration Iteration Iteration Iteration Iteration
Risk reductionRisk reduction
R
I
S
K
Waterfall risk
Walker Royce, 1995

19. 30 19
Iterative Development CharacteristicsIterative Development Characteristics
► Critical risks are resolved before makingCritical risks are resolved before making
large investmentslarge investments
► Initial iterations enable early userInitial iterations enable early user
feedbackfeedback
 Easy to resolve problems early.Easy to resolve problems early.
 Encourages user feedback in meaningful waysEncourages user feedback in meaningful ways
► Testing and integration are continuousTesting and integration are continuous ––
assures successful integration (parts all fit)assures successful integration (parts all fit)
 Continuous testing.Continuous testing.
► Objective milestones provide short-term focusObjective milestones provide short-term focus
► Progress measured by assessingProgress measured by assessing
implementationsimplementations
► Partial implementations can be deployedPartial implementations can be deployed
 Waterfall method – no deliveryWaterfall method – no delivery
 Incremental development? May be some greatIncremental development? May be some great
values in delivering key parts of application.values in delivering key parts of application.

20. 30 20
UP Lifecycle Graph – Showing IterationsUP Lifecycle Graph – Showing Iterations
In anIn an iteration,,
you may walkyou may walk
through allthrough all
disciplinesdisciplines
C
O
N
T
E
N
T
S
T
R
U
C
T
U
R
E
T I M E
STUDY THIS!!!

21. 30 21
Executable Releases
Unified Process Iterations andUnified Process Iterations and
PhasesPhases
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….)
Preliminary
Iteration
Architect.
Iteration
Architect.
Iteration
Devel.
Iteration
Devel.
Iteration
Devel.
Iteration
Transition
Iteration
Transition
Iteration
Elaboration Construction TransitionInception

22. 30 22
Enables and encouragesEnables and encourages useruser
feedbackfeedback
SeriousSerious misunderstandingsmisunderstandings
evident early in the life cycleevident early in the life cycle
Development focuses onDevelopment focuses on criticacritica
issues – break it down!issues – break it down!
Objective assessment thruObjective assessment thru
testing and assessmenttesting and assessment
Inconsistencies detected earlyInconsistencies detected early
Testing starts earlier –Testing starts earlier –
continuous!continuous!
Risks identified and addressedRisks identified and addressed
early - viaearly - via plannedplanned iterations!iterations!
Problems Addressed by Iterative DevelopmentProblems Addressed by Iterative Development
Root CausesRoot Causes SolutionsSolutions
 Insufficient requirementsInsufficient requirements
 AmbiguousAmbiguous
communicationscommunications
 Brittle architecturesBrittle architectures
 OverwhelmingOverwhelming
complexitycomplexity
 Subjective assessmentSubjective assessment
 UndetectedUndetected
inconsistenciesinconsistencies
 Poor testingPoor testing
 Waterfall developmentWaterfall development
 Uncontrolled changeUncontrolled change
 Insufficient automationInsufficient automation

23. 30 23
No Free LunchNo Free Lunch - Traps- Traps
Abound…Abound…
► Major impacts on Project Managers, though….Major impacts on Project Managers, though….
► Trap: When the initial risks are mitigated, new ones emergeTrap: When the initial risks are mitigated, new ones emerge
Do not do just the easy stuff, to look good.Do not do just the easy stuff, to look good.
Keep re-planning based on all new information.Keep re-planning based on all new information.
► Trap: Remember ‘some’Trap: Remember ‘some’ ReworkRework enables you to enhance your solutionenables you to enhance your solution
Accommodate changeAccommodate change earlyearly in the projectin the project
► Trap: Iterative developmentTrap: Iterative development doesdoes notnot meanmean never to commit to a solutionnever to commit to a solution
► Monitor ‘scrap and rework’Monitor ‘scrap and rework’
► Trap: Must Control “requirement creep, ” however… SomeTrap: Must Control “requirement creep, ” however… Some
clients will now naturally recognize many ‘musts…’clients will now naturally recognize many ‘musts…’

24. 30 24
Many Traps in Iterative DevelopmentMany Traps in Iterative Development
Here is another trap: Too long initial iterationHere is another trap: Too long initial iteration
► Winning is fun. Winning teams work better than loosing teamsWinning is fun. Winning teams work better than loosing teams
► BetterBetter to have a short initial iteration, than one too longto have a short initial iteration, than one too long
 Cut scope if necessary (much more later)Cut scope if necessary (much more later)
► Avoid ‘analysis-paralysis’ byAvoid ‘analysis-paralysis’ by time-boxing;time-boxing; you can enhanceyou can enhance
in later iterations (more later)in later iterations (more later)
► Establish anEstablish an even rhythmeven rhythm for project (at least w/i a phase)for project (at least w/i a phase)
► Focus onFocus on resultsresults andand deliverablesdeliverables, not activities, not activities

25. 30 25
Iterations Are Time-boxedIterations Are Time-boxed
►Work is undertaken within anWork is undertaken within an iterationiteration..
►The iteration planThe iteration plan definesdefines thethe artifactsartifacts toto
be delivered,be delivered, rolesroles andand activitiesactivities..
►An iteration is clearlyAn iteration is clearly measurablemeasurable..
►Iterations areIterations are risk-drivenrisk-driven
►Iterations areIterations are plannedplanned..
►Iterations areIterations are assessedassessed!!
►Generally,Generally, initialinitial iterations (in Construction)iterations (in Construction)
based onbased on high risk and core functionalities!high risk and core functionalities!

26. 30 26
The Iteration Plan Defines….The Iteration Plan Defines….
TheThe deliverablesdeliverables forfor
that iteration.that iteration.
TheThe to do listto do list for thefor the
team membersteam members
artifacts

27. 30 27
Problem:Problem:
FixedFixed Plans Produced Upfront – NotPlans Produced Upfront – Not
Real Practical!Real Practical!
►Yet, senior management wants firm, fixed plans!Yet, senior management wants firm, fixed plans!
 Part of their culture / upbringing/ experiencePart of their culture / upbringing/ experience
 Necessary for ‘planning’ budgeting, etc. of resources, projects…. BUT:Necessary for ‘planning’ budgeting, etc. of resources, projects…. BUT:
►TrapTrap: Fine-grained planning: Fine-grained planning from start to end?from start to end?
 Takes too much timeTakes too much time
 Frustrating as change occurs (and itFrustrating as change occurs (and it will)will) , if plans too fine-grained., if plans too fine-grained.
►Know that:Know that: Projects typically have some degree ofProjects typically have some degree of uncertaintyuncertainty
►This makesThis makes detaileddetailed plans for theplans for the entireentire project meaninglessproject meaningless
►Does not mean that we should not planDoes not mean that we should not plan

28. 30 28
Solution:Solution:
Plan With Evolving Levels of DetailPlan With Evolving Levels of Detail
Current Iteration
Next Iteration
Phases and major milestones
 What and when
Iterations for each phase
 Number of iterations
 Objectives and Duration
One For Entire Project
Fine-grained Plans:
Iteration Plans
Coarse-grained Plan:
Software Development Plan
 Iterative Development does not mean less work and shorter schedule
 It is about greater predictability

29. 30 29
Progress is made againstProgress is made against
MILESTONESMILESTONES
►In the Unified Process:In the Unified Process:
 Each phase is defined by aEach phase is defined by a milestonemilestone..
 Progress is made by passingProgress is made by passing milestonesmilestones..
 Milestones measureMilestones measure successsuccess
►PhasesPhases - NOT TIMEBOXED.- NOT TIMEBOXED.
►IterationsIterations ARE TIMEBOXED.ARE TIMEBOXED.
Inception Elaboration Construction Transition
Major Milestones

30. 30 30
SummarySummary
►Much more about iteration and iterationMuch more about iteration and iteration
planning later in the course…planning later in the course…
►You will see some of these again – and,You will see some of these again – and,
more importantly,more importantly, useuse this information inthis information in
your own iteration planning.your own iteration planning.