Professional Documents
Culture Documents
Training On Cost Estimation & Analysis: Karen Richey Jennifer Echard Madhav Panwar
Training On Cost Estimation & Analysis: Karen Richey Jennifer Echard Madhav Panwar
Outline
Introduction to Cost Estimating Life Cycle Costs Data Collection Data Analysis Cost Estimating Methodologies Software Cost Modeling Cross-checks and Validation Risk and Sensitivity Analysis Documentation Requirements Cost Estimating Challenges Cost Estimating Auditor Checklists
2
Preliminary Estimate: Used to develop initial budget, more precise. Detailed Estimate: Serves as a basis for daily project control. Definitive Estimate: Accuracy should be within 10% of final cost.
Important to repeat estimating process (i.e., re-estimate) on a regular basis as more information becomes available
This will keep estimate current as well as increase the accuracy
4
Identifying system performance and/or technical goals. Laying out a program schedule. Selecting a cost element structure (CES). Collecting, evaluating, and verifying data. Choosing, applying, cross-checking estimating methods to develop the cost estimate. Performing risk and sensitivity analysis Time-phasing the cost estimate by fiscal year for cash flow purposes.
Example: 4 years to develop and 10 years operations and support beginning in FY2003
The CES should be reviewed to ensure that there is no double counting of costs that could be allocated to more than one element.
For example, logistics support costs could be included in the investment or operations and support phase.
The CES is hierarchical in nature to accommodate early development (when relatively little data is available) through deployment, when more detailed data is available.
1.5 Outsource Provider Investment 1.6 System Initiation, Implementation & Fielding 1.7 Upgrade (Pre-Planned Product Improvement (P3I)) 1.8 Disposal Costs
Data Collection
Data Required
All CES elements will need data to support the estimate Historical cost and non-cost data need to be collected to support various estimating techniques Technical non-cost data describes the physical, performance, and engineering characteristics of a system
Examples: weight, # of design drawings, SLOC, function points, # of integrated circuit boards, square footage, etc. Important to pick data that is a predictor of future cost
Important to have technical and schedule data because they act as cost drivers
10
Data Collection
Data Required(contd)
Identify both direct and indirect costs
Direct costs are called touch labor and include direct manufacturing, engineering, quality assurance, material, etc. costs which have a direct bearing on the production of a good.
Also included are direct non-wage costs such as training, supplies, and travel.
Indirect costs are considered overhead and include such things as general & administrative support, rent, utilities, insurance, network charges, and fringe benefits. These expenses are typically charged to a company as a whole.
Example: sick/annual leave, retirement pay, health insurance, etc.
11
Data Collection
Data Required (contd)
Some direct costs may be burdened with indirect costs and some may not
Need to know to avoid double-counting or, worse yet, underestimating Important to ask when collecting data whether costs are burdened with indirect costs
12
Data Collection
Data Required (contd)
Data can be collected in a variety of ways
Contractor site visits Data requests for all relevant CES elements Documented cost estimates, if available for earlier versions of the current system
Can save valuable research time for statistical analysis
Data collection is a critical and time consuming step in the cost estimating process!
13
Data Collection
Typical data sources
Two types of data sources:
Primary & Secondary Primary data is found at the original source (e.g., contractor reports, actual program data, etc.)
Preferred source of data
Secondary data is derived from primary data of another similar system such as documented cost estimates, cost studies/research, proposal data, etc.
Second choice to primary data due to data gaps May be best alternative when time constraints or data availability limit primary data collection
14
Data Collection
Typical data sources
Current Program Milestone schedule (for phasing program costs over time) Current Program System Description Important to have a technical understanding of how the system will work Approved program funding (Compare to proposal estimate) Contractor actual cost reports (from internal Management Information System) Current program estimate documentation (if available) Contractor proposals (Compare to program funding profile) Commercial Off-the-Shelf (COTS) catalogs Manufacturer websites (e.g., Dell, Microsoft, etc.)
15
Data Collection
Typical Data Sources (contd)
Forward Pricing Rate Agreements (FPRA) Similar program historical actual costs and estimate documentation Engineering drawings/specifications, Interviews with technical and program management personnel Surveys Professional journals and publications Industry guides and standards Technical Manuals
16
Data Analysis
Data Validity/Integrity
Important to ensure that the cost data collected is applicable to the estimate.
Identifying limitations in the historical data is imperative for capturing uncertainty When using historical cost data for a similar system, appropriate adjustments need to be made to account for differences in the new system being estimated. Data may need to be mapped from the contractors accounting system to the Cost Element Structure (CES)
17
Data Analysis
Data Validity/Integrity (contd)
Proposal data should be validated to ensure that contractor motivations to buy-in or low-bid their estimates are not occurring.
Compare previous contractor proposal bids and actual costs for similar programs. Look for trends in underbidding. Participate in a fact-finding trip to discuss contractor proposal estimates and gather supporting data/evidence.
18
Data Analysis
Normalization
Involves making adjustments to the data so that it can account for differences in
Inflation rates, Direct/indirect costs, Recurring and non-recurring costs, Production rate changes or breaks in production, Anomalies such as strikes, major test failures, or natural disasters causing data to fluctuate, and Learning curve (cost improvement) effects due to efficiencies gained from continually repeating a process
Analysis of the data may indicate the need for more suitable data to add credibility to the estimate.
19
Data Analysis
Normalization (contd)
Accounting for Economic Changes (e.g., inflation)
Lack of cost data uniformity due to upward movement in prices and services over time. Index numbers are used to deflate or inflate prices to facilitate comparison analysis.
Wrong to compare costs from 1980s to today without accounting for inflation over the past 20 years. Cost estimators use inflation indices to convert costs to a constant year dollar basis to eliminate distortion that would otherwise be caused by price-level changes. Constant dollar estimates represent the cost of the resources required to meet each years workload using resource prices from one reference year (e.g., constant 2003 dollars).
Constant dollars reflect the reference year prices for all time periods allowing analysts to determine the true cost of changes for an item
20
Data Analysis
Normalization (contd)
For the United States, the Office of Management and Budget (OMB) is responsible for developing inflation guidance by appropriation for government estimates. Most common indices used by United States Cost Estimators are published by the U.S. Department of Labor, Bureau of Labor Statistics.
Producers Price Index (http://www.bls.gov/ppi/) for goods Employment and Earnings Index (http://www.bls.gov/ces/home.htm#data) for services
Important to pick the appropriate market basket of goods index that most closely matches the costs to be estimated.
21
Data Analysis
Normalization (contd)
For budgetary purposes, however, data expressed in constant dollars should be inflated to represent current year (or Then-year) dollars.
Current year estimates calculate the cost of the resources using the estimated prices for the year in which the resources will be purchased.
Current year estimates reflect inflation
Necessary to express estimates in current year dollars when requesting funding to avoid budget shortfalls.
22
Data Analysis
Normalization (contd)
Example: Assume 5% escalation rate compounded annually
Base-year cost Then-year cost
Current year $273,100 * 1.0000 multiplier = $ 273,100 Current year + 1 $1,911,700 * 1.0500 multiplier = $ 2,007,285 Current year + 2 $4,096,500 * 1.1025 multiplier = $ 4,516,391 Current year + 3 $8,193,000 * 1.1576 multiplier = $ 9,484,217 Current year + 4 $6,144,750 * 1.2155 multiplier = $ 7,468,944 Current year + 5 $1,092,400 * 1.2763 multiplier = $ 1,394,230 Total Estimated Labor cost (budget quality) $25,144,167
23
24
Estimating Methodology
Considerations
Choice of methodology is dependent upon
Type of system
Software, hardware, etc
Phase of program
Development, Production, Support
Available data
Historical data points from earlier system versions or similar system Technical parameters of system
25
Methodology
Expert Opinion
Often called Delphi method, proposed by Dr. Barry Boehm in his book, Software Engineering Economics. Useful in assessing differences between past projects and new ones for which no historical precedent exists.
26
Methodology
Expert Opinion (contd)
Pros:
Little or no historical data needed. Suitable for new or unique projects.
Cons:
Very subjective. Experts may introduce bias.
Larger number of experts will help to reduce bias
27
Methodologies
Expert Opinion - Steps
Gather a group of experts together, Describe overall program in enough detail so experts can provide an estimate, Each member of the expert group then does an independent of the resources needed, Estimates are gathered anonymously and compared, If there exists significant divergence among the estimates, the estimates will be returned to the expert group, The expert group then discusses the estimates and the divergence and works to resolve differences, and The expert group once again submits anonymous, independent estimates which continues until a stable estimate results.
28
Methodology
Expert Opinion - Example
Three software engineers are renown in the ERP software development.
You hold interviews which each explaining the requirements, sizing level, and development process for your new system. Each member of the group submits their opinion of the final cost and the estimate converges to $50M.
29
Methodologies
Analogy
Estimates costs by comparing proposed programs with similar, previously completed programs for which historical data is available.
Actual costs of similar existing system are adjusted for complexity, technical, or physical differences to derive new cost estimates Analogies are used early in a program cycle when there is insufficient actual cost data to use as a detailed approach Compares similarities and differences
30
Methodologies
Analogy (contd)
Often use single historical data point. May have several analogy estimates of sub elements to make up the total cost. Comparison process is key to success.
May have to add or delete functionality from historical costs to match new program
Consult technical experts for advice on complexity factors, technical, performance or physical differences.
(not to be confused with expert opinion method)
Methodologies
Analogy (contd)
Good choice for:
A new system that is derived from an existing subsystem.
Make sure actual cost data is available
A system where technology/programmatic assumptions have advanced beyond any existing cost estimating relationships (CER). Secondary methodology/cross check
32
Methodologies
Analogy (contd)
Pros:
Inexpensive Easily changed Based on actual experience (of the analogous system)
Cons:
Very Subjective Large amount of uncertainty Truly similar projects must exist and can be hard to find Must have detailed technical knowledge of program and analogous system
33
Methodologies
Analogy - Steps
Determine estimate needs/ground rules, Define new system, Breakout new system into subcomponents for analogy estimating, Assess data availability of historical similar systems, Collect historical system component technical and cost data, Process/normalize data into constant year dollars (e.g., constant FY2003$), Develop factors based on prior system,
Example: Program Management is 10% of total development cost
Methodologies
Analogy - Example
Your company is developing a new IT payroll system serving 5,000 people and containing 100,000 lines of C++ code. Another company developed a similar 100,000 lines of code system for $20M for only 2,000 people. Your software engineers tell you that the new system is 25% more complicated than the other system.
Other system development cost was $20M. Estimated cost for new system = 1.25 * $20M = $25M Plus 5,000/2,000, or 2.5 * $25M = $62.5M total cost
35
Methodologies
Parametric
Utilizes statistical techniques called Cost Estimating Relationships (CER).
Relates a dependent variable (cost) to one or more independent variables Based on specific factors that have a high correlation to total cost
Number of software lines of code (SLOC) or function points, Square feet for office floor space, Number of floors in a high rise building for cabling estimates, Database size, etc.
Can be used prior to development. Typically employed at a higher CES level as details are not known. Most cases will require in-house development of CER.
36
Methodologies
Parametric (contd)
Pros:
Can be excellent predictors when implemented correctly Once created, CERs are fast and simple to use Easily changed Useful early on in a program Objective
Cons:
Often lack of data on software intensive systems for statistically significant CER Does not provide access to subtle changes Top level; lower level may be not visible Need to be properly validated and relevant to system
37
Methodologies
Parametric Example
You have a previously developed CER to estimate a new IT system based on SLOC.
Cost = SLOC * 25 $/SLOC The CER is based on systems ranging from 1,000,000 to 3,000,000 SLOC. You have estimated 2,600,000 SLOC for new system Cost = 2,600,000 * $25 = $65M
38
Learning curves specialized type of CER. CERs can be cost to cost or cost to non-cost.
Cost to Cost: e.g., Manufacturing costs are 1.5 times Quality Assurance costs Cost to Non-Cost: $/pound, or engineering hours/# of engineering drawings yields hours/drawing metric that can be applied to new program
39
40
Reliable, normalized data is most important for CER development. Must determine range of data for which the CER is valid. Useful at any stage in a program. Typically CERs are the main cost estimating methodology in early stages of a program.
In later stages of a program, CERs serve as a cross check to other methods High correlation (r2 = 0.75 or higher) for goodness of fit test Least squares best fit (regression analysis, or the ability to predict one variable on the basis of the knowledge of another variable) Multiple regression (a change in the dependent variable can be explained by more than one independent variable) Curvilinear regression (relationship between dependent and independent variable is not liner, but based on a curve) Learning curve (describe how costs decrease as the quantity of an item increases) 41
Must be logically sound as well as statistically sound. Different statistical techniques may be used to judge the quality of the CER.
t-stat
Tests whether the individual X-variable(s) is/are valid
F-stat
Tests whether the entire equation, as a whole, is valid
No single statistic may validate or invalidate a CER, quality of the input data is just as important. Best to use a statistical software package like SAS or SPSS to quickly evaluate alternative CERs.
42
Methodologies
Parametric CERs - Steps
Define the dependent variable (e.g., cost dollars, hours, etc.) and what the CER will estimate, Select independent variables to be tested for developing estimates of the dependent variable,
Variables should be quantitatively measurable and available If there is a choice between developing a CER based on performance or physical characteristics, performance characteristics are generally the better choice because they are known early on
Collect data concerning the relationship between the dependent and independent variables,
Most difficult and time consuming step, but essential that all data is checked to ensure that all observations are relevant, comparable, and free of unusual costs
Select the relationship that best predicts the dependent variable, and Document your findings.
43
In simplest terms, the cost of manufacturing or installing a unit should decrease as the number of units involved increases.
As the number of units produced doubles, the cost per unit decreases by a fixed percentage
The concept of learning curves is not new, originated in the mid-1930s with T.P. Wright in the Journal of Aeronautical Sciences.
44
Methodologies
Parametric Learning Curve - Example
Say that the first 100 tasks of an installation took 10 hours per task and the next 100 averaged 8 hours per task. Thus, the learning curve would be calculated as follows: Learning curve = 8 hours per task/10 hours per task = 0.8
Implies an 80% learning curve meaning an improvement of 20% occurred between the first 100 tasks and next 200 tasks
45
Methodologies
Rate Impact
Basic premise: The number of units produced in a single lot effects the overall cost of producing that lot.
Costco theory that buying in bulk makes the unit cost less
Methodologies
Engineering
Also referred to as bottoms up or detailed method.
Underlying assumption is that future costs for a system can be predicted with a great deal of accuracy from historical costs of that system. Involves examining separate work segments in detail and then synthesizing these detailed estimates along with any integration costs into a total program estimate.
Estimate is built up from the lowest level of system costs. Uses detailed cost element structure (CES). Must include all components and functions. Can be used during development and production.
47
Methodologies
Engineering (contd)
Most useful for systems in production.
Design configuration has stabilized Test results are available Development cost actuals are available
Typically broken into functional labor categories e.g. engineering, manufacturing, quality control, etc.
48
Methodologies
Engineering
Pros:
Objective Reduced uncertainty
Cons:
Expensive Time Consuming Not useful early on May leave out software integration efforts
49
Methodologies
Engineering Steps
Understand program requirements, Prepare program baseline definition, Define ground rules and assumptions, Develop detailed cost element structure, Develop functional estimates, and
Use other program history Compile estimate data Develop rates and factors Incorporate supplier/subcontractor prices Include integration costs to glue the separate components into an integrated system (may need to use a CER for this estimate)
50
Summarize estimate.
Methodologies
Engineering Example
New IT system can be broken down into Labor and Material costs.
Labor: Estimated number of hours 250,000 hrs * $200/hr = $50M Material: From vendor quotes Server = $10M COTS = $3M Desktops (50 @ $100k) = $5M Cost = $50M+$10M+$3M+$5M = $68M
51
Methodologies
Actual
Bases future costs on recent historical costs of same system. Used later in development or production. Preferred method.
Costs are calibrated to actual development or production productivity for your organization
52
Methodologies
Actual
Pros:
Most accurate Most objective of the five methodologies
Cons:
Data not available early on Time consuming Labor intensive to collect all the data necessary
53
Methodologies
Actual - Example
The development process is nearing completion. The material has all been procured at a cost of $20M.
The labor cost to date is $30M. According to earned value cost performance reports (CPRs) the estimate at complete for the remainder of the labor is another $20M.
54
Methodologies
Summary of the Five Cost Estimate Results
Expert - $50M Analogy - $62M Parametric $65M Engineering $68M Actual - $70M
55
Software lines of code (SLOC) are often used to estimate software size which is the most significant driver in determining software costs.
Programming languages also have a significant effect on overall cost.
57
58
59
60
61
Most of the other estimates (requirements, maintenance, etc) are derived from this quantity.
62
Additionally COCOMO uses Cost Drivers grouped in broad categories such as personnel, product, platform, project etc.
Product Cost drivers include:
required reliability and product complexity.
64
COCOMO uses analogy and parametric methods based pm a historical, proprietary database of data submitted by consortium members.
Allows COCOMO to be compatible with current design methods and evolving higher order languages.
65
Where EAF is the Effort Adjustment Factor derived from the Cost Drivers and E is an exponent derived from the five Scale Drivers.
66
67
68
These should be adjusted for every estimate to approximate the new, unique development effort.
69
70
71
72
73
74
CostXpert can accommodate a variety of software sizing elements such as SLOC, function points, object metrics, GUI metrics, and feature points.
75
GAO uses CostXpert during various cost analysis assessments to check the reasonableness of both the software cost estimate and accompanying schedule for delivery. Evaluation copies can be downloaded at
http://www.costxpert.com/products/downloads.html
76
77
78
Quick start wizard enable rapid generation of estimates and details which can then be tailored for the specific project.
79
80
Outputs of the model include: project description, estimation analysis views, schedule, risk analysis, staffing and skill breakout, effort and cost, reliability estimates, and documentation sections. Demo copies of SLIM can be downloaded at http://www.qsm.com/ .
81
82
85
86
87
The International Council on Systems Engineering (INCOSE) has a list of software tools that may be of use.
http://www.incose.org/tools/tooltax/costest_tools.html
88
Factors tend to be the most common approach for top level checks. Software cost models play an important role during later stages of development phase.
Can be used to cross-check the reasonableness of costs forecasted using either the engineering or actual cost methods.
89
91
Errors can also occur from historical data inconsistencies. Cost risk analysis aims to achieve the following objectives:
Identify program level confidence for development schedule, Provide credibility to the target estimate, and Identify technical, schedule, and cost estimating risk drivers for use in risk management.
92
Uncertainty is defined as a situation in which the outcome is subject to an uncontrollable random event stemming from an unknown probability distribution.
Example would be will it rain two weeks from today?
Cost estimating falls more into the range of uncertainty than risk, but most managers use the term risk analysis.
93
Sensitivity analysis highlights the factors that have the strongest impact on the overall cost estimate.
Points to management which factors deserve the most attention. Narrows down the number of lower level cost elements that should be examined using risk analysis techniques.
94
After all cost elements have been identified by a distribution, the simulation is run many times (1,000 10,000 times).
Simulation calculates multiple scenarios of the cost model by repeatedly sampling values from the probability distributions assigned to the various cost elements.
While the simulation runs, the forecasts stabilize towards a smooth frequency distribution called a cumulative frequency distribution or CDF
After thousands of trials, statistics of the results and the certainty of any outcome can be obtained from the CDF.
97
98
Documentation
After cross-checking the estimate major cost drivers, the next step, and most important one of all, involves documenting the entire estimate process. Although this is a difficult and time-consuming procedure, the level of detail and attention will pay big dividends when it comes time to reestimate
May also help data collection of actual analogous costs.
Important to document the estimate as it is being developed (i.e., document as you go).
Hard to remember rationale and judgments for adjusting data months later when it needs to be documented. Documenting as you prepare the estimate leads to a better quality estimate and requires minimum effort at the end.
100
Documentation (contd)
Best to provide more vs. less information
Assume reader knows nothing about the system being estimated. Include step-by-step instructions for how the estimate was developed.
Aim to provide enough information for the estimate to be recreated by a cost analyst independent of the team. Most users of the documentation will either be updating the estimate at a later date or will relay on data for estimating an analogous system.
101
Documentation (contd)
Documentation should include at a minimum:
Introduction Purpose of estimate Estimate team members, POC information, and area of responsibility Program background and system description Program schedule (necessary for phasing costs over time) Scope of estimate (including what was omitted and why) Ground rules and assumptions (all technical and program specific assumptions that bound the estimate e.g., constant 2003 dollars using xx inflation rates) Summary of estimate by year to show phasing by CES Overview of main body that describes how each CES element was estimated
102
Documentation (contd)
Summary of estimate by year showing phasing by CES element (In constant 2002 millions of dollars)
Investment Costs Systems Eng/Program Management Development/Installation/Training Initial Biometric Hardware Costs Initial Biometric Software Costs Network Infrastructure Consulate Facility Renovation Hardware Infrastructure Upgrades Total Investment Costs FY2002 FY2003 FY2004 FY2005 FY2006 FY2007 FY2008 FY2009 FY20010-2012 Total
$ $ $ $ $ $ $ $
$ $
2,523 2,523
$ $
2,523 2,523
$ $
2,523 2,523
$ $
2,523 2,523
$ $
2,523 2,523
$ $
2,523 2,523
$ $
2,523 2,523
$ $
7,569 7,569
$ $ $ $ $ $ $ $
Operations & Support Program Management Biometric Hardware Maintenance Software/System Maintenance Network Infrastructure Maint. Visa Operating Personnel INS Operating Personnel Communications Costs Recurring Training Consulate Facility Maintenance Total Operations & Support Costs Total Life Cycle Costs
FY2002 $ $ $ $ $ $ $ $ $ $ $
33,075
$ $
33,075 52,830
FY2003 540 926 6,400 100 50,715 10,540 1,000 152 70,373 72,896
$ $ $ $ $ $ $ $ $ $ $
FY2004 540 926 6,400 100 50,715 10,540 1,000 152 70,373 72,896
$ $ $ $ $ $ $ $ $ $ $
FY2005 540 926 6,400 100 50,715 10,540 1,000 152 70,373 72,896
$ $ $ $ $ $ $ $ $ $ $
FY2006 540 926 6,400 100 50,715 10,540 1,000 152 70,373 72,896
$ $ $ $ $ $ $ $ $ $ $
FY2007 540 926 6,400 100 50,715 10,540 1,000 152 70,373 72,896
$ $ $ $ $ $ $ $ $ $ $
FY2008 540 926 6,400 100 50,715 10,540 1,000 152 70,373 72,896
$ $ $ $ $ $ $ $ $ $ $
FY2009 540 926 6,400 100 50,715 10,540 1,000 152 70,373 72,896
FY20010-2012
$ $ $ $ $ $ $ $ $ $
1,619.44 2,779 19,200 300 152,145 31,619 3,000 456 211,118 218,687
$ $ $ $ $ $ $ $ $ $ $
Total 5,398 9,263 64,000 1,000 540,225 105,396 10,000 1,520 736,802 781,785
103
Documentation (contd)
Main Body documentation should include:
Enough detail for each CES element that would allow for another analyst to replicate the cost estimate.
Each CES element should provide a description of the methods (with rationale for choosing it), techniques, and data used to generate the estimate as well as any cross-checks done to add rigor to the estimate. Include information such as data sources, direct/indirect labor rates, labor hours, material/subcontracts, learning curve data and methodology, factors, cost estimating relationships with corresponding statistics and data ranges, cost models used, inflation indices, time phasing (e.g., development lasts 3 years and 10 years operations and support), estimator judgments, cross-checks, risk and confidence levels.
Documentation flow should follow the same CES structure shown in the estimate summary by year. If the estimate is an update to a prior estimate, then provide an explanation for any differences.
104
Documentation (contd)
Be sure to spell out all acronyms when first introduced. Cross-reference the reader to where data is used multiple times. Show data at the lowest levels possible.
Include copies of vendor quotes, studies used, statistical analysis printouts, cost model input and output reports, etc.
Include disclaimers to show the level of risk and uncertainty surrounding estimate.
Try to quantify the uncertainty by using a simulation model that will express the summary estimate in terms of level of confidence:
Estimate is presented at the 90% confidence level, or Point estimate of $1 million is bounded by a range of $750,000 to $1,250,000
105
Resources
Lack of trained people is a problem
106
Department of the Army Cost Analysis Manual (U.S. Army Cost and Economic Analysis Center, May 2002)
http://www.ceac.army.mil/pubs/default.asp Link to a zipped MS Word file for downloading or printing Checklist on page 42, Figure 3-4 Validation Considerations
TASC (The Analytic Sciences Corp.), The AFSC Cost Estimating Handbook, Reading, MA, prepared for the U.S. AirForce Systems Command, 1986.
Chapter 8, Cost Models pages 8-6 through 8-12 Appendix D, Staff Review Cost Estimate Checklist pages D-1 through D-8 108
National Research Council Canada (NRC-CNRC) Software Cost Estimation and Control (1994)
http://seg.iit.nrc.ca/English/abstracts/NRC37116.html Appendix A, pages 59-67, Software Cost Estimation Questionnaire
109
Contact Information
For further information please contact us:
Karen Richey (202) 512 4784 or richeyk@gao.gov Madhav Panwar (202) 512- 6228 or panwarm@gao.gov Jennifer Echard (202) 512 3875 or echardj@gao.gov
110