The Cost Estimation Body of Knowledge for Software is in development for a number of years within ICEAA. First as a section of the general CEBoK, but it will be established as a separate CEBoK-S for Software, since software is becoming very prominent within the cost estimation community.

1. Cost Estimating
Body of Knowledge - Software:
past, present, and future
Megan Jones
Eric van der Vliet

2. Introduction
• ICEAA has maintained a Cost Estimating Body of Knowledge (CEBoK)
for many years – it serves as the foundation for CCEA/PCEA
certification
• While there is a CEBoK module on software cost estimating, ICEAA
recognizes that
• Software is an ever-increasing portion of total systems cost
• There are unique aspects of software cost estimating that merit special attention
• Recognizing these facts, ICEAA decided to develop a Cost Estimating
Body of Knowledge – Software (SCEBoK) and plans to finish the initial
version in late 2022
• This briefing provides an overview of CEBoK-S

3. Why is Software Cost Estimating Important?
Software is increasingly embedded (in
everything)

4. 2016-2018
2015: Established the Software Cost Estimation Training and Certification
Steering Committee with ICEAA, Nesma, and IFPUG
2016: Started the Software Certification Curriculum Working Group in
2016 to identify important topics, structure a table of contents for
a software cost estimating curriculum
2017: First appearance of the content that would become the Software
Cost Estimating Body of Knowledge. Seven software estimation
training sessions featured at the ICEAA Professional Development
& Training Workshop In Portland, Oregon, USA
2018: 14 Software CEBoK Training offerings at the 2018 ICEAA
Workshop

5. 2019
ICEAA and Nesma sign a MOU committing to continue the project
16 Software CEBoK training offerings at the 2019 ICEAA Workshop
The same training is offered October 2019 at the IWSM-Mensura
Conference in Haarlem, Netherlands
ICEAA begins negotiating contracts to accelerate the effort using paid vs.
volunteer contributions
ICEAA has partners with the U.S. Defense Acquisition University (DAU)
to use their existing course materials, known as BCF-250:
Software Cost Estimating, as one of the foundations for SCEBoK

6. 2020
ICEAA partners with the U.S. Defense Acquisition University (DAU) to
use their existing software cost estimating course materials as one
of the foundations for SCEBoK (along with previously-presented
software training slides and other sources)
Establishes the ICEAA SCEBoK Review Group (ISRG) to collaborate and
best develop an industry and globally accepted product
Contracts a project manager to integrate the source material with ISRG
feedback and to create a written, readable SCEBoK body of
knowledge and a series of PowerPoint slides to use when training
SCEBoK content
Re-brands as Cost Estimating Body of Knowledge-Software (CEBoK-S) to
reduce confusion between CEBoK and SCEBoK

7. Expected Rollout: Late 2022
• First edition will be in PowerPoint format
• Will be available for learning and instructing
• ICEAA is preparing a standalone specialty certification
for Software Cost Estimating, due in 2023
• Eventual goal is to offer an online narrative-format
body of knowledge

8. CEBoK-S Target Audiences
 Commercial organizations
 Original Equipment Manufacturers (OEMs)
 Government organizations
 Consulting firms
 Quasi-government organizations (e.g., Federally Funded Research &
Development Centers)
 Academic institutions

9. CEBoK-S Goals
CEBoK-S will be developed to:
 Provide users with an understanding of software estimating that will
compliment and enhance cost estimates and analyses
 Factually and objectively present all software sizing methods to allow
users to draw their own conclusions about the merits of any given
method
 Provide guidance to the essential considerations in software cost
estimating
 Ensure content is not biased towards or focused on the the US
Government or US Department of Defense

10. CEBoK-S and CEBoK ®
CEBoK-S will be a supplement to ICEAA’s Cost Estimating
Body of Knowledge (CEBoK®)
 Fundamental cost estimating lessons will not be repeated in CEBoK-S
 CEBoK-S should be used in conjunction with CEBoK
 References and links will cross between core CEBoK lessons and CEBoK-S modules

11. SCEBoK Lesson Summary
Lesson 0: Setting
the stage for
SCEBoK
Lesson 1:
Introduction
Lesson 2:
Software
Development
paradigms
Lesson 3: SCEBoK
Five-step
Estimating Process
Lesson 4:
Estimating Custom
Software
Development
Lesson 5:
Software
Sustainment
Lesson 6:
Estimating
Procured Software
Solutions
Summary,
Templates
Lesson Z:
Commercial
Estimating
Models
Lesson X:
Software Size
Lesson Y:
Productivity
11

12. Lessons 1--6
Lesson 0: Setting the Stage for CEBoK-S
Outline and overview of content
Lesson 1: Introduction
Why software cost and schedule estimating is important
Lesson 2: Software Development Paradigms
Explore each software development paradigm with descriptions
and considerations

13. Lessons 1-6
Lesson 3: CEBoK-S Five-step Estimating Process
Step 1: Develop the scope of the estimate
Step 2: Collect and analyze historical data
Step 3: Create the software estimate
Step 4: Adjust the estimate for risk and uncertainty
Step 5: Document and present the estimate

14. Lessons 1-6
Lesson 4: Estimating Custom Software Development
• Creating a Software Development Estimate
• Software Schedule Estimating
Lesson 5: Software Sustainment
• Definition of Software Sustainment
• Importance of Software Sustainmnet
• Cost Estimating Techniques
• Software Obsolescence

15. Lessons 1-6
Lesson 6: Estimating Procured Software Solutions
• Description of COTS software and its importance
• Primary COTS cost drivers
• Best practices in COTS projects
• Description of ERP and its importance
• Primary ERP system cost drivers and estimating techniques

16. Lesson Supplements: X & Y
Lesson X: Software Size
• Dimensions of software size, methods, and units of measure
• Software size consideration
Lesson Y: Productivity
Lesson Z: Commercial Estimating Models

17. Software-intensive program1
Investment:
• Program/project management
• Systems engineering
• BPR/ Change management
• System Development
• System Procurement
• Hardware (make and/or buy)
• Software (buy)
• System level integration & test
• System
deployment/implementation
Operations & support (O&S)2
• Help desk/service desk support
• Technology refresh/upgrade
• System sustainment
SCEBoK
Lessons 2, 4
SCEBoK Lesson 5
SCEBoK
Lesson 6
1. Adapted from Standard IT LCC WBS V5, US Dept of Homeland Security
2. O&S contains continuation of many investment categories + those new
ones listed here… See definitions in notes
SCEBoK Lesson 6
Software life cycle (example)
• Investment
• Plan (sourcing, business case, governance)
• Develop and/or procure
• Custom Software Development
• Requirements  implementation
• Software procurement
• System Integration
• Deployment
• Software Sustainment
SW Changes (Maintenance, Enhancements, Cyber)
Recurring Software Licenses
Other components (6)
End of life
A. Review: Drawing the Line between Software
Development, Procurement, and Sustainment
17

18. Estimating the
Investment
Stage of
Software
Custom
software
developmen
t?
Procure or
Lease?
2. SaaS
Lease
Procure 1. COTS
Purchase
Can only do a Rough
Order of Magnitude
(ROM) estimate
Three major
options: COTS
products glued
together,
Enterprise
solution, or
Data
Warehouse??
Multiple COTS
Products “glued”
together
4. ERP
3. SOA
Enterprise Solution
Do you
know
software
architectur
e ?
Refer to Lesson 4:
Custom Software
Development
No
Yes
C. Identify the Type of
Procured Software Solution (1 of 2)
18
No
Yes
5. EDW
Enterprise Data Warehouse (EDW)
Lesson 6: Estimating Procured
Solutions
Standalone
COTS
Package(s)
Yes
No
6. Hybrid – select most
appropriate approaches from
Lessons 6 and/or 4

19. OPTIMISM
Innate bias - Planning Fallacy
Project managers are risk-seeking
1 COST, SCHEDULE,
TECHNICAL MISALIGNMENT
Like a three-legged stool, all need to
be consistent in order for a project to
balance
2 MOORE’S LAW
Exponential growth in technology
Paired with projects that take a decade
or longer to complete means that
either there is a continual requirements
update process, or the product is
obsolete on delivery
3
BLACK SWANS
Unpredictable, rare, unprecedented
events that have a huge impact
Why Cost and Schedule Growth
Occur
Numerous Reasons, Both
Internal and External
“The Non-Secret of Good Cost
[and Schedule] Estimating:
Don’t Drink the Kool-Aid”-Lawrence
Goeller, OSD Cost Analysis
Improvement Group
4 LAKE WOBEGON
Project managers and staff are not like
the children of Garrison Keillor’s
fictional town – they are not all above
average
5
Source: Christian B. Smart, Solving for Risk Management: Understanding the
Critical Role of Uncertainty in Project Management

20. Summary of Development Paradigms and
Methods
20
Paradigm Method Estimating Level/Approach Logically Associated
Associated contract
contract type
Predictive/
Plan-driven
Waterfall While the CES/WBS may contain activity-level and CSCI-level elements, development effort is
usually estimated at the top-level, for the overall software development effort. Any activities not
included in the CER/Analogy used for estimating are estimated separately.
Firm fixed price
(FFP)
Predictive-
with-
modifications
Incremental Each increment is estimated separately, using size (ESLOC or FP) and other relevant cost drivers
for that increment. Upfront requirements and software testing follow traditional waterfall steps,
with incremental portions of software requirements proceeding through mini-waterfall cycles of
analysis, design, and coding. It is easier to estimate the expected size and productivity of each
increment
Time and materials
or Cost-
reimbursable
Predictive-
with-
modifications
Evolutionary Each “pass” is estimated separately, using size (ESLOC or FP) and other relevant cost drivers for
that pass. In this paradigm, the expected size and productivity of each pass or prototype is closely
tied to previous passes, depending on the feedback received for that pass. Therefore, creative
approaches to estimating later passes is needed.
Time and materials
or Cost-
reimbursable
Predictive-
with-
modifications
Spiral Similar to the Evolutionary paradigm in that cost drivers for each spiral will usually be dependent
on results/analysis of the previous spiral. However, in this paradigm the unique development
activities for each spiral need to be considered, as well as the additional risk and opportunity
assessment and planning effort associated with this paradigm. Size is ESLOC or FP.
Time and materials
or Cost-
reimbursable
Agile Iterative /
Scrum
Sprints are time-boxed, fixed-duration, full-development cycles that ideally, result in working
software at the end of each sprint. Size and productivity are fluid compared to other paradigms
and emerge as development progresses, rather than being predictable at the onset. Estimating
cost and schedule are more difficult than for waterfall due to a lack of relevant and comparable
historical data, and scope flexibility. Estimates based on relative average effort per sprint or
average person hours per sprint, but consistency issues abound. Highly flexible, (but difficult to
estimate.) Minimum viable product (MVP) size may be estimated from a statement of objectives
(SOO) or technical baseline, if available.
Time and materials
or Cost-
reimbursable
Part
predictive/
part agile
Hybrid-agile No standard definition of a hybrid-agile method, but typically consists of a variation of:
1. a formal, upfront, waterfall-like requirements phase to fix the high-level scope;
2. a series of partial-scrum-like build iterations (consisting of analysis, design and coding phases);
3. followed by a waterfall-like testing phase. Estimate based on
Once the development in step 2 begins, cost and schedule are fixed and delivered software size
Fixed price with
incentives or time
and materials

21. Agile paradigm:
overview (1 of 2)
• Stresses iterative and incremental development
and evolution of requirements  Change-driven
• Agile  an umbrella term for a suite of methods
and practices based on values of the Agile
Manifesto1
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• Works well with smaller teams, interim products,
highly engaged customers
21
Adapted from www.agilealliance.org

22. Agile versus waterfall: overview1 (1 of 3)
22
1. AGILE ASSESSMENT GUIDE Best Practices for Agile
Adoption and Implementation, September 2020 GAO-20-

23. Differentiator Agile methods Predictive methods
Focus of work Change-driven based on product value:
fixed time and cost, estimated scope
Project plan: fixed scope, estimated cost and
duration
Frequency of
deployment
Iterative, early & frequent (2-3 weeks) One big release (end of project)
Quality Continuous inspection and testing during
every iteration (impact on rework)
Testing phase inspects out poor quality at the
end (impact on rework)
Customer involvement Co-located, daily review via product owner
owner
Interaction with customers at beginning and
end
Risk of changing
requirements
Minimizes risk by engaging customer to
prioritize requirements to be developed
first
Fixed requirements with high risk due to
incomplete or incorrect requirements or change
change
Development teams Self-organized, may split effort between
Development and Operations
Hierarchical or matrix, fully dedicated to
development
Operations and Security
Security Considerations
With DevSecOps, continuous deployment,
deployment, continuous testing during
development. Can reduce integration costs
costs
Little to no consideration of operations or
security during development. Separate teams.
Operations and security concerns handled post-
post-development
Prototypical contract
type(s)
Time and materials (T&M) or cost-
reimbursable
Firm fixed price (FFP) or fixed price with
incentives 23
Agile versus waterfall: overview (2 of 3)

24. Adapted from https://www.process.st/waterfall-vs-
agile/
24
Agile versus waterfall: overview (3 of 3)
Topic Agile Predictive / waterfall Hybrid-agile (Partly predictive/partly agile)
agile)
Fixed Cost & schedule Scope (requirements) Initial high-level scope fixed, but is flexible to
prioritization and change during development
Estimated Scope (features) Cost & schedule Cost & schedule initially estimated, but
becomes fixed during development
Driver Change-driven Plan-driven Hybrid
Development
risks1
Cost & schedule mostly fixed.
Delivered size may fall short
Scope fixed  cost & schedule
overruns
Cost & schedule mostly fixed during build.
Delivered scope may fall short

25. Agile paradigm:
Iterative development (2 of 2)
Advantages:
 Adaptable and embraces change
 Prioritizes customer satisfaction and communication
 Focus on business need and business value
 Sustainable development pace
Disadvantages:
 Not structured enough for architecture design or re-design work
 May need to be combined with waterfall model to fit organizational needs
Appropriate when:
 Requirements are not well known upfront
 Flexibility and responsiveness to changing requirements are important
25

26. The next slides  look at 6 modern agile frameworks +
hybrids
Agile concepts and software estimating1 (1
of 2)
26
WORK
LEVEL
AGILE
DELIVERABLE
ESTIMATION
TYPE
LEVEL SOURCE OF
ESTIMATING
DATA
Organiza
tion
TYPE OF
ESTIMATE
???
Epics Solutions Long-term Portfolio Portfolio
backlog
Value
streams
Budget
indication /
Size-based
S/W
Cost
estimato
r
Features /
Capabilitie
s
Solution Long-term Solution Solution
Backlog
Value
stream
Budget
assignment
to value
stream
S/W
Cost
estimato
r
Features Releases Mid-term
(2-3
months)
Product
Manage
ment
Program
Backlog
Release
Train
Story point
based; Size
/ Effort
based
S/W
Cost
estimato
r
User
Stories
Release Short-term
(2-3 weeks)
Team Team Backlog Iteration
s
Story point
based
Dev
Team
1. Table prepared by Eric van Vliet, CGI Netherlands

27. Source: GAO-20-590G GAO Agile Assessment
Guide, 2020 Page 126
• Consistent sizing is
critical for software
cost estimating
• SLOC and Function
Points can be used for
software development
estimates AND life
cycle cost estimates
(LCCE)
C.1 Software sizing considerations (4 of 5)
Agile: Consistent sizing vs Relative Sizing
27

28. • Original size may be based on high-level estimate of product or release
backlog
• If estimate based on past project velocity, uncertainty with size
compounds
• Agile scope evolves:
• Minimum viable product (MVP) size may grow,
• Content of releases may grow
• Relative effort sizing becomes relevant during project
• Basis of effort, cost and schedule estimate changes
• Cannot fix all three sides of iron triangle
28
Step 4:
Conduct
Sensitivity,
Risk, and
Uncertainty
Analysis
Software Development Growth
3. Agile Scope Growth

29. Agile Velocity is NOT Productivity
• While Velocity, as a generic term, sounds like efficiency, it is NOT Productivity
• Velocity = Sum of Completed Relative Efforts / 1
• Completed relative effort is the estimated relative effort in story points, of a user story completed during
the sprint;
• 1 represents a single sprint, however the # of hours is variable across sprints, duration is fixed, effort
hours are not
• From GAO Agile Guide: “Beware of self-reporting: … velocity is a measure of the rate
at which the team delivers a user story. It is not comparable from team to team, and
should not be used to distinguish one team from another. It is very easy to show an
increase in velocity without adding value to the program by inflating story point
estimates. In other words, increasing velocity does not always indicate a change in
productivity.”1
• To mitigate inconsistencies related to Velocity  can use Productivity (in standard
sizing units per person hour) for agile projects
29
1. GAO-20-590G GAO Agile Assessment
Guide, page 106