Embed Size (px)
Citation preview
Software Cost Estimation
Raytheon Space and Airborne SystemsDeana Seigler
11/20/2003
Copyright © 2003 Raytheon Company. All rights reserved.
11/20/2003 Page 2
Topics to be Covered
• Overview of Raytheon’s Software Cost Estimation Process
• Thin Spec
• Work Breakdown Structure
• Software Size Estimation
• Wideband Delphi Process
• Estimating Software Cost– Development Costs
– Support Costs
– Other Costs
• Using a Second Estimation Technique
• Cost Realism Analysis
• Cost Review with Senior Management
11/20/2003 Page 3
Why estimate the effort?
• Supplier needs to know . . .– What are they promising to produce? Can they meet the
requirements?
– Who will be required to perform the work?
– How much effort will it take?
• Customer wants to know . . .– What can be accomplished? Will it meet my needs?
– When will it be done?
– How much will it cost?
• Ensure the software will meet requirements for . . .– Technical performance and quality
– Schedule
– Cost
Ensures everyone understands the scope of the effort
11/20/2003 Page 4
Cost Estimation Flowchart
Understand Softw are
Requirements
1Start
Generate Thin
Spec
2
Identify / Ref ine
Softw are Products
3
Prepare / Ref ine WBS
4
Perfom Initial Size
Estimate
5
Perform Wideband
Delphi Size Estimate
6
Prepare Initial
Schedule
7
Refine Schedule
8
Estimate Softw are
Development
Resources using
10
Estimate Softw are
Development Support
Resouces using Histroical
Support Adders Analysis
11
Validate Estimated
Resouces using a
Second Technique
12
Prepare Low er
Level Schedules
9
Determine and
Document Final
Estimate
13
Perform Cost
Realism Risk
Analysis
14
Prepare Senior
Management Review
Charts
15
Prepare Review
Package
16
Review Estimate
w ith Senior Softw are
Management
17
Review Estimate w ith
Program Management
18
Consistent WBS &
SW Products
Definition?
Consistent SW
Size Betw een 2
Methods?
Consistent
Resources?
Consistent
Schedule/Required
Resources?
Consistent WBS,
Sizing, Resources,
Schedules?
End
A
B
B
A
A
N
Y
N
Y
N
Y
Y
Y
N
N
N
N
Understand Requirements
Divide into Components
Individual Estimates
Wideband Delphi Mtg
Convert size to hours
Estimate support effort
Layout Schedule
Validate w/2nd technique
Refine Schedule
Verify Consistency
Document Final Estimate
Cost Realism Analysis
Prepare Review Charts
Review Estimate w/Mgmt
11/20/2003 Page 5
• Outputs– Understanding of the requirements and breakdown into products
– Total software development effort for the program
– Software development effort by month
– Total software development effort per software product
– Software development effort per stage (Requirements Analysis, Design, Implementation, Evaluation/Test)
• Exit Criteria– You have defined all software development activities necessary to
satisfy contractual and internal requirements
– You have generated cost estimates in more than one way and evaluated and resolved discrepancies.
– You have presented estimates to senior management and received approval for them.
What Will Be Produced
11/20/2003 Page 6
• SOW (or equivalent) is usually provided by the Customer and states:
– Deliverables and Tasks Required� Major functions and interfaces to be provided
� Hardware and software to be delivered
� Training and support services to users
– Constraints on schedule, cost
– Performance and quality standards
• The SOW may also include a high level description of the problem to be solved
– Operational concept
– Mission
– Major interfaces and components of system
Review the Statement of Work
11/20/2003 Page 7
Preliminary Requirements Analysis
• Decomposition of critical requirements is the first step– Identify major capabilities to better understand the requirements and
their interrelationships
– Divide the requirements into simple categories that you and others within your team will understand
– Group capabilities into software products� Mission vs. Test software
� Each processor as a separate product
� In-house vs. supplier software
� Frequency of anticipated releases
– Evaluate alternatives such as COTS, software reuse from other projects, and development life cycles
11/20/2003 Page 8
Create a Thin Spec
• The Thin Spec documents the requirements for a project as they are known at the start of the project
• The Thin Spec typically contains:– Requirements allocated to the product– Identified external interface definitions and requirements– Preliminary time & size estimates and constraints– Target and development platform data – Agreements made with other groups
• Goal: Gain a solid basis for estimation– Understand and document the problem– Identify the preliminary list of requirements
• Approach: Define and scope the problem domain and environment– Interview customers and ensure right participants and good interaction– Derive all information needed for estimate and proposal
11/20/2003 Page 9
Preparing the Thin Spec
• The Thin Spec is a team responsibility– The Software Lead directs effort and ensures that any issues
are discussed and negotiated– Systems engineer and software systems engineer develop
the Thin Spec
• The Thin Spec is based on whatever information you can get from whatever reliable source will provide it, including:
– Preliminary requirements and product definitions– White papers and trade study results– Customer ConOps documents– Technical interchange meetings– End-user interviews and staff experience
11/20/2003 Page 10
Tailoring the Process
• Tailor the organization’s process to fit your project– Modify activities or artifacts
� Change the scope
� Adjust the level of formality
� Modify the approval or review process, …
– Delete activities and artifacts that aren’t needed
– Add things that are needed but not in standard process
• Proper tailoring leads to a better plan– With good tailoring, you run more efficiently without losing the
benefits of the organization’s process
– Tailoring is not a license to avoid what you should be doing
– The process is a risk reduction tool based on organizational experience
11/20/2003 Page 11
• Customer standards (e.g., 12207, NASA or FAA)– Most are designed to be tailored
• Known risks and opportunities
• Number of engineers working on project
• Software product complexity and size
• Overall level of effort and schedule
• Documentation requirements
• Organization’s Process Goals– CMMI Level
– Required Metrics
– Process Improvement Initiatives (pilot new processes)
Influences on Tailoring
11/20/2003 Page 12
• Work Breakdown Structure defines the hierarchy of activities to be performed to meet customer requirements. It is:– The basis for estimating– The structure for documenting the estimate– A means for tracking actual performance against estimates
• A WBS helps organize the software effort into manageable pieces (“buckets”) for estimating and tracking.– Ensures you don’t forget to include costs for a task– Maps to the Statement of Work
• Raytheon uses a standard top-level WBS across programs– Facilitates collection and use of historical data– Easier to perform trend analysis– Ensures all required activities are accounted for in the estimate
Next Step – Create the WBS
11/20/2003 Page 13
• Software Development WBS Elements– Design– Code and Test– Software Integration
• Support WBS Elements– Software Requirements Analysis– Software Qualification Test– Software Management Planning and Control– Software Quality Engineering– Software Configuration Management– Software Support of System Integration
• Program Specific WBS Elements (Optional)– Process Support or Tool Support– Additional Stages (e.g. maintenance, preliminary and detailed design)– Field Test Support– Training– Supplier Management Activities– Travel
WBS Elements
11/20/2003 Page 14
• SW planning & control• Support software• SW maintenance
Level 3
Level 4
Level 5&6
Level 7
AAB1Software Program
AAB3Test
Software
AAB301Test
Software
• SW reqs analysis• Design• Implementation• Test
AABElectronic
Whiteboard
AAB2Deliverable Software
AAB201User
Interface
AAB202Database
• SW reqs analysis• Design• Implementation• Test
• SW reqs analysis• Design• Implementation• Test
WBS Example - Tree
11/20/2003 Page 15
WBS Example - LinearLevel 3 AAB Electronic Whiteboard Software Level 4 AAB1 Software Program (all) Level 5 AAB11 Software planning & control
AAB12 Support softwareAAB13 SW maintenance
Level 4 AAB2 Deliverable Software Level 5&6 AAB201 User Interface Level 7 AAB2011 Software requirements analysis
AAB2012 DesignAAB2013 ImplementationAAB2014 Test
Level 5&6 AAB202 Database Level 7 AAB2021 Software requirements analysis
AAB2022 DesignAAB2023 ImplementationAAB2024 Test
Level 4 AAB3 Test Software Level 5&6 AAB301 Test Software Level 7 AAB3011 Software requirements analysis
AAB3012 DesignAAB3013 ImplementationAAB3014 Test
11/20/2003 Page 16
• Now we understand the basic scope and requirements (Thin Spec) and we have the problem decomposed into a WBS . . .
We can start estimating the size of the software
• Size estimates are based on:– New software that must be developed from scratch
– Existing software that needs to be modified, and
– Existing software that can be reused without modification.
• Need to define the systems and software architecture– Processor selection
– Memory capacity, throughput, I/O channel capacity
– Design for future re-use
Now create the size estimate
Size estimates provide a basis for estimating effort, cost and schedule later in the estimation process.
Size estimates provide a basis for estimating effort, cost and schedule later in the estimation process.
11/20/2003 Page 17
Exercise - Size Units
How do you measure the size
of a house?
How do you measure the size
of a house?
11/20/2003 Page 18
Lines of Code
• Raytheon’s most common size measure is the Source Line of Code (SLOC), which is
a complete logical source program statement terminated by a statement delimiter. … SLOC excludes comments and blank lines.
• Delivered Lines Of Code (DLOC) is defined as the number of SLOC delivered for the contract– As counted by the Raytheon Line Counter (RLC) tool
– Used for estimates, productivity and fault density
• DLOC is not always the best measure of size• Other units commonly used include:
� Function Points (more on next slide)� Objects or Classes� Requirements� Tests� Screens
11/20/2003 Page 19
Equivalent Size - Concept
• Reuse can save money, but it’s not free– Requires some effort for understanding, modifying your architecture
or design, testing, integrating, etc.
– Generally speaking, the cost of reused software ranges from 10-30% of the cost of “new” software
• Equivalent size is a normalized size measure that reflects the reduced effort needed when software is reused
– Accounts for the costs and benefits of reuse
<--- Without reuse
With reuse --->
11/20/2003 Page 20
Exercise - Reuse
What questions should you ask about software
from other programs that
might be reusable on your program?
What questions should you ask about software
from other programs that
might be reusable on your program?
11/20/2003 Page 21
• Each module is categorized as:– New: Software developed from scratch or more than half of
which is modified
– Reused: Software obtained from another application and used without change
– Modified: Software obtained from another application and modified only a modest amount (less than 50%)� Even a minor change makes the module categorized as modified
instead of reused
� The entire module is categorized a modified, not just the lines that will be changed
� Example: If 40% of a 1,000 DLOC unit will be modified, then all 1,000 lines are categorized as modified.
• Effort factors are applied to the Reused and Modified DLOC to determine Equivalent Lines of Code (ELOC)
Software Categories
11/20/2003 Page 22
Equivalent Size Formula
ELOC = New DLOC
+ Modified DLOC * FM
+ Reuse DLOC * FR
Where:FM and FR are the ratio of
• Effort needed to integrate the modified or reused software to
• Effort needed for equivalent new code
5%N/ANew Build w/Same SW
10%40%Easy
25%55%Medium
40%70%Hard
Reuse Factor (FR)Modified Factor (FM)Difficulty Adapting Software Artifacts
11/20/2003 Page 23
Example of Equivalent Size
• Suppose you have the following software estimate:
• Due to the benefits of reuse, you only need to do 2180 ELOC worth of work to produce 3500 of actual DLOC.
ELOC = 1500*100% + 400*70% + 1600*25% = 2180
2140 Equivalent LOCESCR
3500 DLOCTotal
25% (FR)1600 (Reuse DLOC)Reused
70% (FM) 400 (Modified DLOC)Modified
100%1500 (New DLOC)New
FactorSize (Screens)Category
11/20/2003 Page 24
Calculating ELOC Factors
Reuse Factor (FR) = 25%
Stage Weight Effort
Design 40% 25%
Code and Test 30% 0%
Software Integration 30% 50%
Modification Factor (FM) = 55%
Stage Weight Effort
Design 40% 50%
Code and Test 30% 40%
Software Integration 30% 75%
Detailed estimate of the reuse and modification factors
11/20/2003 Page 25
Outputs of the Process
• A list of the components for each software product
• An estimated size for each component, “glueware” and “middleware”, and a total for the complete product
• An estimate of what portion of each component will be new, modified, or reused code
• Also include estimates of the minimum and maximum size for each component
• If relevant to your application, you may also include estimates of memory requirements, processor throughput, etc.
11/20/2003 Page 26
Risks in Estimating SW Size
• Perfect estimates are rare, but success depends on reasonable estimates– Manage by fact – not guesswork
• You may estimate incorrectly if:– You don’t decompose the problem to an appropriate level
– The requirements are vague or at too high a level
– You don’t include all of the required functionality
– You have no history to compare with
– You are overly optimistic or pessimistic
– You are unfamiliar with the application, the target architecture, or the programming language
• Both under-estimation and over-estimation are bad– Under-estimation means you can’t deliver what you promised
– Over-estimation could mean you loose the business all together
11/20/2003 Page 27
• The information typically starts off as individual estimates, then is refined during the estimating process
• Wideband Delphi sessions are held for individuals to resolve differences between their independent estimates
TOTAL
. . .. . .
950950950Figure Generator
FIG GEN
390600.65600I/F to Platform
1553 IF
135450.30450I/O DriverDriver
ELOCDLOCFMFRNewModifiedReused
Total Size
Reuse FactorsSizeDescriptionSoftware
Component
Documenting Size Estimates
11/20/2003 Page 28
• Wideband Delphi . . .– is a method that makes use of multiple experts in a structured process
– improves accuracy and completeness by incorporating multiple viewpoints
– involves the program team in the estimating process which builds buy-in to program plans
• Experts make individual estimates for components with which they are familiar
• Experts meet in a structured team meeting to discuss their assumptions and work toward convergence on a single result
• Moderator ensures the process is followed
XXXX
X X X XX
XX XXX
Wideband Delphi Method
11/20/2003 Page 29
• Moderator leads a discussion, where each estimator discusses assumptions about their estimate. For example:• What functions were performed in each component• What reuse software would be available
• These discussions may lead to inconsistent assumptions, questions, allocations, etc. • The group tries to reach consensus on these.
• After every estimator has had a chance to discuss his or her assumptions, each evaluator re-estimates, changing values as appropriate based on the discussions that took place
• The moderator plots the new estimates.
• Iterate through the process until estimates converge to within 5-10%
Wideband Delphi Meeting
Estimates for Project Beta
X X X X X
X X X X X
Estimates for Project Beta
X X X X X
X X X X X
11/20/2003 Page 30
100%50%LLow
35%35%MMedium
10%10%HHigh
Potential Size Increase
(Maximum)
Potential Size Decrease(Minimum)
Confidence Code
Confidence in Size Estimate
WBD session yields Most Likely valuesWBD session yields Most Likely values
Confidence Factors
• Size estimation is not an exact science
• Variation depends on your confidence in the estimate
• An estimate of 100 lines of Medium confidence could be as low as 65 lines or as high as 135 lines
11/20/2003 Page 31
• To estimate the cost of the software development effort, you need to estimate all of the required resources:– Estimate the effort for SW development
(labor hours)
– Estimate Support Costs (management,SCM, SQE, …)
– Estimate other costs such as travel, tools, licenses, development and target processors, etc.
• Also need to determine program duration, schedule dependencies and staffing profile– May find that staff needs to stay around while other parts of the
system are completed or tested
Estimating Cost
Allocating labor months to the schedule can also help you evaluate the estimates.
Allocating labor months to the schedule can also help you evaluate the estimates.
11/20/2003 Page 32
• All engineering effort for design, code, test, and software integration – This effort is called the Software Development Effort
• This is generally derived from the software size estimate and other program characteristics
As defined here, “software development cost” excludes
software requirements analysis, formal test, system
integration, and any other support costs
As defined here, “software development cost” excludes
software requirements analysis, formal test, system
integration, and any other support costs
Software Development Costs
11/20/2003 Page 33
Select a Productivity Rate
• Productivity rates vary based on . . .– Problem domain
– Experience level of personnel
– Other factors previously discussed
• Historical data should be used to determine rate– Examine similar projects’ productivity rate (past experience)
– Ask the Software Engineering Process Group
– Query the organization’s Software Metrics database
– Use your past experience
• Estimate three productivity rates– Minimum - smallest it is likely to be (lower productivity = more effort)
– Most Likely - what you think it will be
– Maximum - largest it is likely to be (higher productivity = less effort)
Effort Hours = ELOC / ProductivityEffort Hours = ELOC / Productivity
11/20/2003 Page 34
Documenting the Productivity Rates
……………
Experience from 2 previous projects
.88.80.75Signal Processor
Assumes JAVA2.11.51.2User I/F
Based on Product Y1.2.95.85Control Module
CommentsMaxMost Likely
MinProduct
These values will be used to convert ELOC to hours.They are also input to the cost realism analysis.
These values will be used to convert ELOC to hours.They are also input to the cost realism analysis.
11/20/2003 Page 35
Six Standard Categories:• Software planning and control (management)
• Software quality engineering (SQE)
• Software configuration management (SCM)
• Software requirements analysis
• Software evaluation (qualification test)
• Software support of system integration and test
Each is estimated in an appropriate manner and then represented (for reporting purposes) as a
percent of the software development effort
Each is estimated in an appropriate manner and then represented (for reporting purposes) as a
percent of the software development effort
Support Costs
11/20/2003 Page 36
• Variety of factors can cause support costs to vary– Problem domain and application criticality can have a large impact
– Amount of reuse can affect the support costs
– Process to be followed or contractual requirements influences cost
• Ways to estimate support costs– Examine historical data from the organizations measurement repository
– Perform a bottoms-up task-based estimate
– Perform a level-of-effort estimate
• Representing the support costs– Estimated in hours
– Transformed into a percentage of the software development effort
– Example: Software development effort =1000 hoursManagement effort estimated to be100 hours, then Software planning and control = 10%.
Support Costs Vary
11/20/2003 Page 37
……………
Lower than normal due to reuse gains
14%10%8%Reqs Analysis
Bottom-up Estimate7.5%6%4.5%SW CM
Based on Product Y8%7.5%7%Planning & Control
CommentsMaxMost Likely
MinCategory
These values will be used as input to the cost realism analysisThese values will be used as input to the cost realism analysis
Documenting the Support Costs
Estimate minimum and maximum percentages for eachof the six support costs
11/20/2003 Page 38
• This category includes all other cost items, such as:– Contract-required audits and validations that are not part of the
normal process,
– Travel for meetings, remote site testing, etc.,
– Equipment and software that must be purchased, and
– Anything else found in the WBS that is not covered elsewhere
• These are usually estimated after the development and Support Costs have been estimated
• Generally these are not directly based on size or on a percent of the software development effort
• Typically, this category includes non-labor items, such as travel and materials (represented as $)
Other Costs
11/20/2003 Page 39
Test Software$3,000$2,500$2,000Material
Finance support tasks
$15,000$1,200$1,000Level-of-Effort Tasks
COTS Test & Integration
$10,000$6,000$4,000COTS Integration
MaximumMost LikelyMinimum
CommentsOther Items CostOther Items
As with other elements of the estimate, you need to estimate min, most likely, and max values, which will be used as
input to the cost realism analysis.
As with other elements of the estimate, you need to estimate min, most likely, and max values, which will be used as
input to the cost realism analysis.
Documenting the Other Costs
11/20/2003 Page 40
• Algorithmic or parametric estimating models are excellent ways to verify your estimate – COCOMO, PRICE S and SEER are examples
• Expert Judgment (based on prior experience)– Individual expert judgment
– Standard Delphi (uses multiple experts, written communication, converge on estimate)
– Wideband Delphi (also allows for meetings and verbal communication)
• Analogy (compare to a similar program, based on history)
• Top-Down (estimate product, then allocate down)
• Bottom-Up (estimate components, then aggregate to product)
The key is to use a second technique that has very different assumptions and concepts
The key is to use a second technique that has very different assumptions and concepts
Estimate using Second Technique
11/20/2003 Page 41
Many Factors Influence Cost
• Major factors that can influence software effort and cost include:
Cost Factors
People Time
Organization
Complexity
Reliability
Newness
– People working on the program (experience and capability)� Experienced people cost more but are more efficient
– The domain, size, and complexity of the software being developed� Effort increases as complexity increases
– The schedule (amount of time you have to develop)� Accelerating or stretching schedule increases cost
– Reliability and security requirements� Safety critical systems require more testing
– Uniqueness of technology� New concepts can have unexpected problems
11/20/2003 Page 42
4.18
2.36
1.87
1.66
1.57
1.561.51
1.49
1.49
1.34
1.32
1.23
1.23
1.20
1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50Software productivity range
Personnel/team capabilityProduct complexity
Required reliabilityTiming constraint
Applications experienceStorage constraint
Modern programmingVirtual machine volatility
Software toolsVirtual machine experience
Turnaround time
Schedule constraintDatabase size
Language experience
Some COCOMO Cost Factors affect productivity much more than others
Impact of COCOMO Cost Factors
11/20/2003 Page 43
Reconciling Estimates
• If you estimate in two or more ways, the results are likely to be different
• This is a good thing!
• By investigating the differences and resolving the discrepancies you will learn a lot more and produce better estimates.– What assumption was used for personnel availability?
– What support tasks are included? Did you overlook any activity?
– Is the schedule realistic? Is the staffing curve realistic?
Adjusting availability is a common way to boost apparent productivity -- but it is just an illusion!
Adjusting availability is a common way to boost apparent productivity -- but it is just an illusion!
11/20/2003 Page 44
• Identify Schedule Constraints from– customer
– program management
• Determine earliest start and latest end dates
• Consider dependencies
• Determine software product start and end dates for each stage
• Prepare top level schedules during estimation process– by product
– by stage
– show dependencies
SOW
RFP
CDR
Schedule Estimation
11/20/2003 Page 45
By Product and Stage
Show Dependencies
Example Top Level SW Schedule
11/20/2003 Page 46
• A method of evaluating the risk of an estimate and the probability of success
• Uses Excel and Crystal Ball to perform a Monte-Carlo simulation based on the estimates you have generated– Size– Productivity– Support Costs– Other Costs
• Minimum, Most Likely and Maximum estimates for each element are needed for this analysis
• May give you reason to reevaluate and refine your estimates– If the probability of success is 20%, don’t even take it to management.– Revise your estimates so that most likely values are closer to the
maximum values.
Perform Cost Realism Analysis
11/20/2003 Page 47
Cumulative Chart
Certainty is 47.65% from $8,250,000 to $9,660,420
Mean = $9,699,295.000
.250
.500
.750
1.000
0
500
1000
2000
$8,250,000 $8,937,500 $9,625,000 $10,312,500 $11,000,000
2,000 Trials 0 Outliers
Forecast: SWAggregate
Estimate: Amount = $9,660,420 Certainty = 47.65%Risk: Amount = $320,328 Probability = 52.35% Factored Risk = $167,692
Cost Realism Analysis
11/20/2003 Page 48
• Raytheon has a standard format for presenting the software estimate to higher management.
• Six slides, two required and four backup – First Slide Summarizes the Estimate
– Second Slide Summarizes Risk Analysis
– Four Backup Slides
We have a standard package so everyone can learn how to interpret a
software estimate the same way.
We have a standard package so everyone can learn how to interpret a
software estimate the same way.
Software Cost Review
11/20/2003 Page 49
• First Slide Summarizes the Estimate
– Type of software
– Size
– Source of Requirements (e.g., Customer Spec, Raytheon Spec)
– Productivity
– Cost Summary
1Senior Management Review ChartsSoftware Cost Summary
Type of Software: Air Traffic Control
Source of Requirements: Customer provided RFP, Product Thin Specs
Expected contract turn-on / Duration: May 1999 / 26 months
Software Sizing, Reuse, and Productivity: Reuse/Mod NormalizedEquivalent Cost Productivity Development
SW Items New Mod Reused Size Avoidance (Items/hour) Cost / ItemSLOC 169,301 75,000 20,000 215,551 18% 2.91 $26Tables 50 24 0 63 15% 0.024 $3134Screens 60 7 0 63 6% 0.022 $3470Func. Points 0 0 0 0 0 0 0
Software Cost Summary: Cost (M PCL $)Software Development (SLOC) $5.59Software Development (Tables) $0.20software Development (Screens) $0.22Software Development (Func. Points) $0.00Total Software Development Cost $6.01
Software Support Cost $3.19
Other Software-Related Cost $0.45
Total Software Cost $9.65
Software Cost Review
11/20/2003 Page 50
• Second Slide Summarizes Risk Analysis – Top Three Risks
– Cost Impact, Probability, and Mitigation Plans
– Cost Realism Analysis
– Probability of executing the program within the current proposed price.
2
.
.
.
.
.
.
.
S e n io r M a n a g e m e n t R e v ie w C h a r t sS o f tw a r e R is k A n a ly s is
R i s kC o s t I m p a c t
( K P C L $ )P r o b a b l i t y
F a c t o r
F a c t o r e d C o s t I m p a c t
( K P C L $ )M i t i g a t i o n
F r o m C R A T o o l S i m u l a t i o n : P r o d u c t i v i t y D e c r e a s e , S i z e G r o w t h , a n d S u p p o r t A d d e r S u p p o r t G r o w t h
3 2 0$ 5 2 % 1 6 8$
F o c u s o n M D P C S C I s i z e g r o w t h p o t e n t i a l , a c q u i r e n e w s o f t w a r e d e v e l o p m e n t t o o l s a n d t r a i n a l l e n g i n e e r s ; m a n a g e c u s t o m e r r e q u i r e m e n t s s c o p e c r e e p
C u s t o m e r d i r e c t e d s u b c o n t r a c t o r p r o d u c t m a y n o t b e a v a i l a b l e i n t i m e
5 0 0$ 3 0 % 1 5 0$ P r o v i d e a d d i t i o n a l s u b c o n t r a c t m a n a g e m e n t o v e r s i g h t ; i n c l u d i n g w e e k l y t e l e c o n s a n d t e c h n i c a l i n t e r c h a n g e s m o n t h l y
S y m b o l o g y t a s k b e i n g m o v e d f r o m H / W t o S / W 4 0 0$ 6 0 % 2 4 0$
S t a r t S / W R A t o a v o i d f u r t h e r s c h e d u l e i m p a c t ; G e n e r a t e S y m b o l o g y a l g o r i t h m d e s i g n d o c u m e n t s
T o t a l R i s k 1 , 2 2 0$ 4 6 % 5 5 8$
Cumulative Chart
Certainty is 47.65% from $8,250,000 to $9,660,420
Mean = $9,699,295.000
.250
.500
.750
1.000
0
500
1000
2000
$8,250,000 $8,937,500 $9,625,000 $10,312,500 $11,000,000
2,000 Trials 0 Outliers
Forecast: SWAggregate
E s t im a te :A m o u n t = $ 9 ,6 6 0 ,4 2 0C e r ta in ty = 4 7 .6 5 %R is k :A m o u n t = $ 3 2 0 ,3 2 8P ro b a b il i t y = 5 2 .3 5 %F a c to re d R is k = $ 1 6 7 ,6 9 2F a c to re d R is k R a t io = 1 .7 %
Software Cost Review
11/20/2003 Page 51
• Four Backup Slides – Software Cost Details
– Historical vs. Program Selected Support Costs
– Software Productivity by Software Category
– Historical vs. Program Selected Software Development Productivity
Senior Management Review ChartsDetailed Software Cost
3
LaborSoftware Development Tasks Hours PCL K $
SLOC 74,159 5,587.1Tables 2,625 197.8Screens 2,864 215.8Function Points 0 0Subtotal 79,648 6,000.7
Software Support TasksSW Planning and Control 7,407 558.0SQE (SQA) 3,743 282.0SCM 5,894 440.1SW Requirements Analysis 8,921 672.1SW Qualification Test 8,921 672.1SW Support of System Integration 7,407 558.0Subtotal 42,293 3186.4
Other Software-Related TasksPost IOC Warranty 4,000 301.4Software Development Facility 2,000 150.7Subtotal 6,000 452.0
Total Cost (Development + Support + Other) 127,941 9639.1
Senior Management Review ChartsHistorical vs. Program SW Support Adders
4
AdderHistorical Percent Historical
Software Support Adders Minimum Selected Maximum
Software Planning and Control 7% 9.3% 20%
SQE (SQA) 5% 4.7% 15%
SCM 5% 7.4% 15%
Software Requirements Analysis 8% 11.2% 16%
Software Qualification Test 8% 11.2% 20%
SW Support of System Integration 5% 9.3% 22%
Totals 38% 53.1% 108%
Comments:e.g., The local historical data for SQE is lower than the historical averages across otherbusiness areas.
Senior Management Review ChartsProgram Software Productivity
5
Software ELOC Software ReferenceProduct Description ELOC Productivity Devel. Hrs Program
MSP Mission Planning 9,117 4.47 2,040 Program A, Component C
DTF Data Formatting 22,313 3.21 6,951 Program B, Product Y
COM Common MDP 21,416 3.28 6,529 Program A, Product Z
MDP Mission Processing 111,826 2.54 44,026 Program A, Product Z
DEA DE / Analysis 39,387 3.32 11,864 Program C, Component A
EXM External Msg Proc. 11,492 4.18 2,749 Program A, Component B
Totals 215,561 2.91 74,159
Comments:TBD
Senior Management Review ChartsHistorical vs. Program Productivity
6
Similar Year ELOC K SW Program ProductProgram Completed K ELOC Productivity Devel. Hrs Type Domain
Program A 1998 136 40.5 3.36 EMD Air Traffic Control
Program B 1997 148 64.5 2.29 EMD Air Traffic Control
Program C 1996 145 55.4 2.62 EMD Air Traffic Control
Program D 1997 480 201.6 2.38 EMD Air Traffic Control
New Program 215.6 74.2 2.91 EMD Air Traffic Control
Comments:TBD
Software Cost Review
11/20/2003 Page 52
Summary
• To generate software cost estimates, you: – Scope the effort and create the Thin Spec.
– Break system into products and components.
– Define a Work Breakdown Structure to collect costs.
– Estimate the software development effort (labor).
– Estimate the support effort required (SCM, SQE, etc.).
– Estimate other costs.
– Estimate effort using a second method.
– Evaluate the estimates by comparing the two methods.
– Iterate the process as required to resolve differences.
– Convert the effort into cost and document final estimate.
– Identify potential risks. Adjust estimate for acceptable level of risk.
Conclude the process by reviewing estimate with Senior Management.
Conclude the process by reviewing estimate with Senior Management.
