Modern Software
Engineering
Current State, Ugh (i)
Some organizations are 10 (even 600) times more
productive than others(1)
Most Software Projects Fail
Some definitions for Failure:
Missed schedule
Missed functionality
Missed budget
Too fragile for usage demands
Defect rates too high once in production
(1) Steve McConnell, After the Gold Rush. Redmond, WA. Microsoft Press, 1999.
Ugh (ii)
In 1995, only 16% of software projects were
expected to finish on time and on budget.(1)
Projects completed by the largest US
organizations have only 42% of originally
proposed functions.(1)
An estimated 53% of projects will cost nearly
190% of their original estimates.(1)
In large companies, only 9% of projects will be
completed on time and on budget.(1)
(1) Standish Group International Report, “Chaos”, as reported in March ‘95 Open Computing. Copyright 1995 SPC.
Ugh (iii)
Canceled projects—$81 billion loss to US
in 1995(1)
Average MIS—1 year late, 100% over
budget(2)
(1) Standish Group International Report, “Chaos”, as reported in March ‘95 Open Computing. Copyright 1995 SPC.
(2) Capers Jones, Applied Software Measurement, McGraw-Hill, 1991.
Engineering vs. Science(1)…
Scientists:
Learn what is true
How to test hypotheses
How to extend knowledge
Engineers:
Learn what is true
Learn what is useful
Learn how to apply well-understood knowledge to
solve practical problems
(1) Steve McConnell, After the Gold Rush. Redmond, WA. Microsoft Press, 1999.
Ad Hoc Survey (i)
[and some answers from UML World attendees
via unscientific show of hands]
How Many have a SWE Degree? [0]
How many of you practice Software Engineering?
~10%
Think of the last year’s projects
3+ months, or
Project team size >= 5
Percent Successful Projects
1% 100%, __ >75%, __ >50%, __ <25%, __ 0%
Ad Hoc Survey (ii)
For failed projects, what went wrong?
•
•
•
•
•
•
•
•
•
•
•
•
Ill-defined requirements? [50%]
Ill-managed requirements changes? [30%]
Poor software development methodology? [25%]
Unrealistic schedule? [25%]
Poor project management? [20%]
Lack of user involvement?
Lack of stakeholder involvement?
Lack of qualified people?
Lack of tools?
Corporate politics get in the way?
Poor or no architecture?
Lack of measurements and controls?
Is this How It Should Be?
Why do we allow this to happen?
Would you like your next <item> built like this?
Item  car, home, airplane,
bridge, ICU monitoring s/w
Engineering and construction firms don’t build
things in the way most software gets built…
Why is software allowed to so often be done
without any engineering? Many Reasons…
Can we do anything about this? Yes!
Are there some better ways? Yes!!
Current Practices are Broke!
We can do better!
We must do it better!
We should employ engineering methods
Everyone can enjoy random
success, but one is advised
not to build a career on it!
-- Bicknell, 1993
The Core Triad for Success
People
Process
Technology
People + Process + Technology
Process is no substitute for synaptic activity
You still need to think and use common sense
And a lot of that is not a book or course-learning
exercise. It takes street smarts.
That’s where mentoring and consulting come in and
add significant value
S/W Evolution
People
• Position Descriptions of the 70s:
 Programmers
• 80s
 Programmer/analysts
• 90s
 Developer
 Architect
 Business Analyst
• 00s ?




UI Designer
Bean Provider
Assembler
Deployer
+ Architect
+ Modeler
+ Implementer
+ Project Manager
+ System Analyst
+ Config. Mgr.
+ System Tester
+ Test Designer
Software Evolution (ii)
Processes
Ad Hoc
Waterfall
Spiral
Incremental
Iterative
RAD/JAD
Unified Process
Extreme Programming (XP)
Feature-Driven Development
Software Evolution (iii)
Technology
Languages: Assembler , Procedural, Structured,
Object-Oriented
3GL/4GL/CASE
Life Cycle Tools
•
•
•
•
Requirements, Architecting, Building, Testing
Configuration Management/Version Control
Round-trip Engineering (manual steps)
Simultaneous round-trip tools
Modeling:
• Structured, DFD,
• Coad, OMT, Booch,
• UML
Software Evolution (iv)
Still facing same problems as the last 25+ years
Ill-defined requirements
Demanding schedules
Fast-moving technology
Fast-moving business needs
Large-scale projects
Not much widespread improvement
But there is hope…
The Venerable Waterfall Process
Postpones Confronting Risk
Late Design Breakage
Maintenance
Testing
Implementation
Design
Analysis
Can work on
well-defined efforts
Can work in smaller efforts
Great for reporting apparent progress
SCRUM
Scrum
Scrum – an activity that occurs during a
rugby match.
Scrum—distinguishing features
Development work is partitioned into “packets”
Testing and documentation are on-going as the
product is constructed
Work occurs in “sprints” and is derived from a
“backlog” of existing requirements
Meetings are very short and sometimes
conducted without chairs
“demos” are delivered to the customer with the
SCRUM – Why?
The Standish Group’s The CHAOS Report, in 1994:
31.1% of projects will be canceled early
52.7% of projects will be over budget by an average of 189%
83.8% of projects will fail
Of the 16.2% of successful projects delivered on time and on budget, on
average, they get delivered with only 42% of their original features.
Source: The Standish Group, 1994. The CHAOS Report. http://www.pm2go.com/sample_research/chaos_1994_1.php
(C) 2002 Kevin Aguanno.
SCRUM – History
First coined by Ikujiro Nonaka and Hirotaka Takeuchi in "The New New Product
Development Game" (Harvard Business Review 86116:137-146, 1986) and
later elaborated in The Knowledge Creating Company (Oxford University Press,
1995) to refer to agile development. Adapted from the sport of rugby, the term
refers to the process used to get a ball back into play. As applied to software
development, it refers to the organization and management technique used to
successfully deliver software development projects in a chaotic environment.
Further developed with the assistance of the DuPont Advanced Research
Facility and presented to the Object Management Group in 1995. Key
developers and promoters of SCRUM are Jeff Sutherland, Ken Schwaber, and
Mike Beedle.
Now widely used around the world.
(C) 2002 Kevin Aguanno.
SCRUM – How It Differs
Traditional software development models (such as Waterfall) are based upon a
defined methodology which attempts to define requirements up front, logically
break down the work, estimate, plan, then begin development, while trying to
limit/control change which will threaten the plan. These are based upon Defined
Process Model theory which was adopted from manufacturing and applied to
software development.
Document System Concept
System Requirements
Architectural Design
Detailed Design
Code, Debug, Unit Test
System Test
Deploy & Operate
Ready.
Aim.
(C) 2002 Kevin Aguanno.
Fire!
SCRUM – How It Differs
SCRUM assumes that baselines will change significantly during the project.
In such an unpredictable environment, empirical methods should be used to
monitor progress and change, rather than using definitive methods to try and
predict progress and stop change.
SCRUM looks forward to change, as it means the end result will be a product
which more closely meets the customer's needs at the end of development.
SCRUM is not, however, without its own structure and control mechanisms...
Ready.
Fire! Correct Course. Recorrect Course...
(C) 2002 Kevin Aguanno.
SCRUM – Basic Principles
SCRUM is founded upon two basic principles:
Team Empowerment. The project team is divided into self-managing multifunction units called Sprint Teams consisting of up to six or seven people. The
team is empowered to use whatever development methods or tools they think
best to prepare their deliverables.

Iterative Development. The project deliverables are built over several iterative
development cycles, each adding additional features, and each resulting in
demonstratable results: working code, written documentation, viewable designs,
etc.

(C) 2002 Kevin Aguanno.
Scrum Principles
Small working teams used to maximize communication
and minimize overhead
Process must be adaptable to both technical and business
challenges to ensure best product produced
Process yields frequent increments that can be inspected,
adjusted, tested, documented and built on
Development work and people performing it are
partitioned into clean, low coupling partitions
Testing and documentation is performed as the product is
built
Ability to declare the product done whenever required
Scrum - 1
Backlog
prioritized list of requirements or features the provide
business value to customer
items can be added at any time)
Sprints
work units required to achieve one of the backlog items
must fit into a predefined time-box
affected backlog items frozen
Scrum - 2
Scrum meetings
15 minute daily meetings
what was done since last meeting?
what obstacles were encountered?
what will be done by the next meeting?
Demos
deliver software increment to customer for
evaluation
SCRUM – Project Structure
SCRUM Structure
Initial List
of Features
Grouped List
of Features
Feature 1
Feature 1
Feature 3
Feature 7
Feature 3
Feature 4
Feature 5
Feature 6
Feature 7
Sprint #1
Planning
Feature 2
Feature 4
Sprint #2
Feature 5
Feature 6
Product Backlog
By Kevin Aguanno. (C) 2002 Element K Journals.
Integrated
Demonstration
Feature 2
Closure
SCRUM – Management Controls
SCRUM projects are not "Out of Control" and, in fact, have several good
management and control elements:
Daily SCRUM Meeting. This is a daily meeting attended by all team members
for a Sprint. The call is generally very brief (15 mins.), the purpose of which is to
update the project manager and other team members on progress and to raise
any issues that the project manager or other team members can assist with.
Three questions are answered by each participant:
 What did I do in the last 24 hours?
 What do plan to do in the next 24 hours?
 What obstacles are standing in my way?
Visible Progress Demonstration. At the end of each Sprint, the customer and
all project team members get to see a visual demonstration of progress to date.
Customer feedback can be obtained early in the process this way, and avoid
costly changes late in the project lifecycle. Overall project progress is very
visible and very easy to track in this way via a function/feature checklist, function
points, or other similar means.
(C) 2002 Kevin Aguanno.
SCRUM – Management Controls
Sprint Burndown Charts. During a Sprint, the team provides an updated
estimate on the number of hours/days to complete their work during the daily
SCRUM meetings. The project manager can use this data to build a Sprint
Burndown Chart showing the progress within a Sprint. The total projected
number of hours for a Sprint usually increases in the early days of the Sprint as
nuances and additional work are uncovered, but then rapidly decline as work
gets underway.
Text (C) 2002 Kevin Aguanno. Chart (C) 1997 Advanced Development Methods Inc.
SCRUM – Management Controls
Accelerated Customer Approval. Because the customer reviews visible
deliverables at the end of each Sprint and provides feedback at that time,
coupled with the fact that subsequent Sprints build upon the work of earlier
Sprints, the final output should not contain any surprises to the customer and will
already include the bulk of his feedback. This should allow for a faster final
customer approval/acceptance of the deliverables.
(C) 2002 Kevin Aguanno.
SCRUM – Case Study
XYZ is a television broadcasting company that was seeking to replace its ad
sales and traffic system, a core business and operational system for
broadcasters touching nearly all aspects of the business. XYZ had been using
their current system for over a decade and the company had structured itself
around the features and limitations of the current system. In addition, the current
system was highly customized to meet the unique business requirements. The
existing system could no longer grow to meet demand and XYZ could not modify
it to meet new customer requirements. XYZ needed a new system.
XYZ hired IBM to analyze their existing and new requirements to uncover the
core functional requirements of the new system and build a request for proposal
(RFP), which would be issued to vendors of ad sales and traffic systems, and
also an evaluation tool for scoring vendor responses. IBM needed to interview
key stakeholders from nearly all areas of the business in over 50 interview
sessions and document their (sometimes conflicting) requirements, rationalize
any discrepancies, prioritize them, and prepare a high-level "to be" picture of how
the new system should look.
(C) 2002 Kevin Aguanno.
SCRUM – Case Study
The IBM project manager used SCRUM as the project management method. Bidaily SCRUM Meetings were held with the project team which included two key
customer representatives and limited to 30 minutes' duration at the start,
diminishing to fifteen minutes' duration later in the project as the project neared
completion and fewer issues arose. The RFP was broken down into several
Sprints each adding more content to the RFP and incorporating stakeholder
feedback: a rough draft Sprint, a first full draft Sprint, a final draft Sprint, a final
release version Sprint, and two parallel Sprints to produce the vendor response
evaluation tool (draft and final).
The results clearly showed the applicability to SCRUM in a consulting
environment. The project was delivered within target budget and timeline
ranges, and XYZ was delighted with the quality of the deliverables. In fact, the
project team was able to over-deliver in some areas that were identified as being
important to key stakeholders, smoothing the approval process for the final
deliverables.
(C) 2002 Kevin Aguanno.
SCRUM – Methodology Alignment
As SCRUM is not really a software development methodology, but more of a
development project management methodology, it does not dictate specific
software development practices (such as daily builds, OO design and modeling,
etc.) which means that most software development methods may be managed
using SCRUM without major conflicts.
(C) 2002 Kevin Aguanno.
SCRUM – When NOT to Use It
SCRUM is not appropriate for all situations, especially:

Large teams,

Complex team organizational structures,

Geographically-scattered teams, and

Life- or mission-critical applications.
(C) 2002 Kevin Aguanno.
A Solution
Feature-Driven Development
Client-centric
Architecture-centric
Repeatable process
Pragmatic, livable methodology
Great for developers
Great for managers
Great for the application!
Feature Driven Development
Practical process model for OO SW engineering.
Applicable to moderate sized and larger SW projects.
FDD—distinguishing features
Emphasis is on defining “features”
• a feature “is a client-valued function that can be implemented in two
weeks or less.”
Uses a feature template
• <action> the <result> <by | for | of | to> a(n) <object>
A features list is created and “plan by feature” is conducted
Design and construction merge in FDD
FDD puts a greater emphasis on project management
guidelines and techniques than many other agile methods.
Defines 6 milestones during the design and implementation of
a feature
design walkthrough, design, design inspection, code, code inspection,
promote to build.
Feature Driven Philosophy
Emphasizes collaboration among team members
Manages problem and project complexity using featurebased decomposition followed integration of software
increments
Technical communication using verbal, graphical, and
textual means
Software quality encouraged by using incremental
development, design and code inspections, SQA audits,
metric collection, and use of patterns (analysis, design,
construction)
Feature Driven Design - 1
Develop overall model
contains set of classes depicting business model of application to
be built
Build features list
features extracted from domain model
features are categorized and prioritized
work is broken up into two week chunks
Plan by feature
features assessed based on priority, effort, technical issues,
schedule dependencies
Feature Driven Design - 2
Design by feature
classes relevant to feature are chosen
class and method prologs are written
preliminary design detail developed
owner assigned to each class
owner responsible for maintaining design document for his or her
own work packages
Build by feature
class owner translates design into source code and performs unit
testing
integration performed by chief programmer
FDD and Software Engineering
Processes:
People:
• FDD
• Testing
• SQA
• Project Mgt
• Class Owners
• Chief Programmers
• Feature Teams
Tools:
• Together® (Model+)
• “Parking Lot” Reports
• Version Control
• Build Management
• UI Builders
FDD terms are in RED
Why the FDD Process?
To enable and enforce
the repeatable delivery of
working software in a
timely manner with
highly accurate and meaningful reporting to
all key stakeholders inside and outside a
project.
The FDD Process in Brief
5 Major Steps/Activities
FDD #1
Develop
an
Overall
Model
FDD #2
Build
a
Features
List
Requirements
& Design
FDD #3
FDD #4
FDD #5
Build
Plan
by
Feature
Design
by
Feature
Build
by
Feature
Promote
to
Build
Sched.
&
$$ Est.
Design, Code,
Some
Initial
Code Testing
Test
& Put
in Build
FDD & Typical SDLC Phases
Maintenance
#1 & #2 are Reqt’s & Design through
Modeling/Coding/ Prototyping
to get it right
Testing
#4 is very granular Detailed
Design/Code
#4
Implementation
#2
#1
#5
Design
Analysis
#5 is Detailed Code
and Test in very,very granular
chunks of client-valued functionality
Reminder:
Why FDD #1 & #2 Processes’ Emphasis on
Requirements & Design?
Studies have shown conclusively that it pays to do
things right the first time
Unnecessary changes are expensive
TRW: a change in requirements-analysis cost 50-200
times less than same change later in the cycle
(construction-maintenance). Boehm, Parpaccio 1988
IBM: removing an error by the start of design, code or
unit test allows rework to be done 10-100 times less
expensively than during unit test or functional test. Fagan
1976
A S/W Eng. View of FDD
FDD #1 & #2
Look at the larger scope
Determine tools and architecture needed to get the job
done as simply and as soon as possible
Eschew the “Code-and-Fix(1)” Approach
Emphasize planning and process up front
• While simultaneously focusing on client needs
• And reducing the need for lots of rework
Conforms to good Engineering Practices
(1) Steve McConnell, After the Gold Rush. Redmond, WA. Microsoft Press, 1999.
An XP View of FDD
FDD #1 & #2
Work with domain experts to elicit requirements
Record (at least) in the form of an object model
• With Together® true round-trip engineering, this means real
source code
Confront riskier sections of domain with deeper coding
as required
Demands using your head, knowing when to stop, retrace steps, and go down new path
Re-architect as required to adapt to requirements
Fits in with XP philosophy
XP Basic Principles(1) & FDD
XP
Rapid Feedback
Tangible, working results,
testable, know if it works
Assume
Simplicity
Focus on big picture, detailed
view driven by client-valued
features, pragmatism rules
Frequent, fine-grained iteration
through reqts to coding and back
Incremental
Change
(1)
FDD
Beck, Kent. Extreme Programming Explained. Reading, MA. Addison Wesley Longman, 2000.
XP Basic Principles & FDD (ii)
XP
Embracing
Change
Quality Work
FDD
Work with running system
sooner, soliciting early client
feedback, encouraging future
feature discussions
Frequent, working results are
non-ambiguous. Razor sharp
reporting of being “done” leads
to habits of being successful.
Working in teams, peer reviews
help to ensure quality.
Typical Iterative Development
ENGINEERING
PRODUCTION
Requirements
Analysis
Design
Coding
Testing
Inception
Elaboration
Construction
Iterations (1-n)
Transition
Fitting UML into Development
Where/how does it fit into s/w development
practices
In modern software development methodologies, there
is a large degree of iterative development.
Productive modeling environments automatically
synchronize source code and class diagrams
This implies that you take successive passes at the
system, adding new information and capability along
the way.
Inception
Iterative
Elaboration
Iterative
Construction
Transition
The Utility of UML
Helps to promote standard communication
But does not supplant human contact!
Class Diagrams are very useful
Sequence and Activity help with dynamics
Use Cases
Useful if your organization has meaningful way to
apply them—no silver bullet
Can be replaced by other means of capturing
features/requirements
FDD Artifacts
FDD
#1 
FDD
#2 
FDD
#3 
S/W Artifacts
Mgt Artifacts
Breadth of App:
List of
Class Diagram,
hi-level
w/out
features
much content
Class Diagram
w/ more shape;
greater domain
understanding
People
Architects,
Domain
Experts
List of
prioritized
features
Architects,
Dom.Exp’ts,
Chief
Prog’rs (CP)
Initial Plan
plus
Reports
Assign CPs
choose class
“owners”
FDD Artifacts (ii)
FDD
#4 
FDD
#5 
S/W Artifacts
Model gets more
content. Detailed
design in code.
Add Seq. Diags.
Model gets
built, feature
by feature.
Promote to build,
release…
Mgt Artifacts
People
Detailed
Form
Models,
Feature
Seq. Diag.
Teams
As req’d
Running
Code &
Tests
Build
and
Test
FDD “Engineering” Outputs
FDD #1
Develop
an
Overall
Model
FDD #2
Build
a
Features
List
FDD #3
FDD #4
FDD #5
Plan
by
Feature
Design
by
Feature
Build
by
Feature
An object
model
(more shape
than content)
A
categorized
list of
features
A Development Plan
FDD “Construction” Outputs
FDD #1
Develop
an
Overall
Model
FDD #2
Build
a
Features
List
FDD #3
FDD #4
FDD #5
Plan
by
Feature
Design
by
Feature
Build
by
Feature
An object
model
(more shape
than content)
A
categorized
list of
features
A Development Plan
A design package (sequences)
(more content
than shape)
A clientvalued
function
FDD UML Extensions
Report progress to management and clients
Very high level (major feature sets)
JK
MS-R
<<major feature set>>
<<major feature set>>
Product Sale Management
Cash Sale Management
Selling Products
Creating Cash Sales
Shipping Products
Delivering Cash Sales
Delivering Products
Accepting Payments
Ordering Products
Creating Orders
(6)
22%
Dec 1999
(2)
27%
Dec 1999
• These reflect UML extensions
made in Together®
FDD UML Extensions (ii)
Chief
Programmer
Next level down (feature sets)
Marty
Mike
Ed
<<feature set>>
<<feature set>>
Selling Products
Shipping Products
Delivering Products
Calculate the Total (12)
of a Sale
UseCase1 (4)
UseCase1
(8)
Asses the Fulfillment27%
Timeliness of a Sale
UseCase2 22%
UseCase2
100%
# Features
Feature1
UseCase3
Dec 1999
Feature2
UseCase4
Jan 2000
Overdue!
Feature3
<<feature set>>
% Complete
UseCase3
(color too)
UseCase4Aug 1999
UseCase5
Feature4
UseCase6
Feature5
UseCase7
Feature6
UseCase8
Doug
Feature7
Freedy
Jon
UseCase1
<<feature set>>
Feature8
<<feature set>>
<<feature set>>
Ordering Products
Feature9
Accepting Payments
Creating Orders
UseCase1 (16)
Feature10
Feature1
(2)
UseCase1(1)
Feature2
22%
UseCase2
0%
UseCase3
Dec 2002
UseCase4
Jan 1999
%
Due Date
FDD UML Extensions (iii)
CP-1
Overall Status:
Work in progress
Attention (ie, Behind)
Completed
Making
Product
Assessments
(14)
Example:
Feature Set:
Making Product Assess’ts –
Work in Progress
Not yet started
Completion Percentage:
75%
(14) there are fourteen features that make
up this feature set
Progress bar
Completion Status:
Completed
MY Targeted Completion Month
CP-1 is the Chief Programmer’s initials
Dec 2001
75% Feature Set is 75% complete
Target is to complete in Dec 2001
FDD Sample Feature Sets
Product Sale Management (PS)
CP-1
CP-1
CP-3
CP-1
Selling
Products
Shipping
Products
Delivering
Products
Invoicing
Sales
(22)
(19)
(10)
(33)
99%
10%
30%
3%
Nov 2001
Dec 2001
Dec 2001
Dec 2001
CP-2
Setting up
Product
Agreements
(13)
CP-2
Inventory Mgmt (IM)
CP-2
CP-3
Opening
New
Accounts
(11)
Logging
Account
Transactions
(30)
Establishing
Storage Units
95%
100%
82%
Oct 2001
Oct 2001
Work In Progress
Dec 2001
Dec 2001
Evaluating
Account
Applications
(23)
KEY:
Making
Product
Assessments
(14)
75%
Customer A/C Mgmt (CA)
CP-2
CP-1
Nov 2001
Attention
CP-3
CP-3
Moving
Content
(26)
Accepting
Movement
Requests
(18)
100%
97%
82%
Nov 2001
Nov 2001
Completed
Progress Bar
(19)
Nov 2001
Not Started
Milestones
“Milestones must be concrete, specific, measurableevents defined with a knife-edge sharpness”
“A programmer will rarely lie about milestone
progress, if the milestone is so sharp he can’t
deceive himself”
“Getting the status is hard since subordinate
managers have every reason not to share it”
Fred Brooks
Milestones (ii)
Domain
Walkthrough
Design
Plan
Plan
Actual
1%
Actual
40%
Design
Inspection
Code
Plan
Plan
Actual
3%
Actual
45%
Code
Inspection
Promote to
Build
Plan
Plan
Actual
10%
Actual
1%
Assigning % permits accurate reporting
A feature that is still being coded is 44% complete
Domain walkthrough 1% + Design 40% + Design
inspection 3% = 44%
Milestones (iv)
The Plan and Actual dates are completion
dates
An entry in the actual column for a
milestone signifies that milestone has been
achieved
This triggers the percentage calculations for
that feature, its feature set and so on
Intervals aren’t recorded – but they could be
FDD Tracking
Granular level of a feature
with planning and
tracking properties used
to calculate %complete
<<feature>>
Accept cash payments
<<feature>>
Accept credit/debit payments
• These reflect UML extensions
made in Together®
FDD Plan View
FDD Feature View
FDD Weekly Summary
FDD Weekly Summary (ii)
FDD Trend Reporting
FDD’s Contribution to S/W
Project Success Factors*
Accurate s/w measurement
Tracks completion by feature
Use of estimating tools
Plan/estimate by feature
Continuous planning
Continuously adjust estimates if required
Formal progress reporting
Formal risk management
Granular and summary (roll-up)
reporting
Object model architecture (shape) is key
part of process
Yes, for modeling/building, FDD doesn’t
cover testing
Informal thru continuous integration
Automated config. control
Not the mission of FDD
<10% requirements creep
 Process works to minimize creep
Formal architecture planning
Formal development methods
Patterns of Software Systems Failure and Success (Jones 1996)
FDD’s Contribution (ii)
Formal design reviews
Part of the process, a milestone
Formal code inspections
Part of the process, a milestone
Formal testing
Automated design and specs
No. Relies partially on process to build
in quality and frequent builds to test
 Not part of FDD, but part of tool
Use of suitable languages
 Not part of FDD, but part of tool
Controlled and measured
complexity
Significant reuse
Part of process to glean granular enough
features and model to a sufficient depth
Informal thru architect
Formal database planning
Not the mission of FDD
Patterns of Software Systems Failure and Success (Jones 1996)
FDD’s Contribution (iii)
Realistic Schedules
 Plan/estimate by feature
Exec understanding of est.
FDD presents clear picture of needs,
should help ensure understanding
Part of the modeling process: involve
client early and often.
Not the mission of FDD
Cooperation with clients
Congruent Mgt. Goals
Team communications
Experienced Sr. Execs
Capable project management
Capable project staff
Use specialists
FDD process covers team collaboration
and radically improves communication
Not the mission of FDD
FDD should help to make project
managers more successful
 FDD team collaboration links lead
developers with junior developers
Not the mission of FDD
Patterns of Software Systems Failure and Success (Jones 1996)
Defect Removal Efficiency
80%—Formal structured peer reviews (e.g., Fagan
inspections) (1)
60%—Code walkthroughs (2)
36%—Integration test
"Formal design and code inspections have the
highest defect removal efficiency of any technique
yet noted, and average about twice as efficient as
most forms of testing." (3)
(1) US Army Information Systems Command, "Software Quality and Testing: What DoD Can Learn From Commercial Practices",
AIRMICS Report # ASQB-GI-92-012, 8/31/1992, p10
(2) Boehm, Barry, Industrial software metrics top 10 list, IEEE Software, Sept. 87
(3) Jones, Capers, Patterns of Software Systems Failure and Success, Thompson, 1996, p129
Further Info
Coad, De Luca, Lefebvre. Java Modeling in Color with
UML. Upper Saddle River, NJ. Prentice Hall, 1999.
Royce, Walker. Software Project Management.
McConnell , Steve. After the Gold Rush. Redmond, WA.
Microsoft Press, 1999.
Jones, Capers. Applied Software Measurement. McGrawHill, 1991.
Beck, Kent. Extreme Programming Explained. Reading,
MA. Addison Wesley Longman, 2000.
Many other assorted articles
Contact: Jon Kern (jk@TogetherSoft.com)