**CHAPTER IV**

**HARDWARE COST MODELING**

**CHAPTER IV**

**HARDWARE COST MODELING**

**[INTRODUCTION]{.underline}**

Hardware cost is defined as all program cost, excluding software
development, for all components, assemblies, subsystems, and systems for
sea, ground, airborne or space applications. Hardware cost includes:
mechanical, electromechanical, electrical/electronic, structural or
pneumatic equipment, and may also include system test, or system
operations. It is defined as the cost to develop, design, build, test,
launch, and operate a system.

Hardware cost estimating approaches are categorized into five basic
methods: (a) parametric, (b) analogy, (c) grassroots, (d) other (methods
such as, standard time or expert consensus approaches), and (e)
combinations of the other form. The first three are well recognized and
clearly defined. The last two \"methods\" cover everything else. This
section will focus on parametric hardware cost modeling techniques.

Parametric estimating is the mathematical procedure or process in which
product or service descriptors directly yield consistent cost
information. A parametric cost model is an estimating system comprised
of Cost Estimating Relationships (CERs) and other parametric estimating
functions, e.g., cost quantity relationships, inflation factors, staff
skills, schedules, etc. Parametric cost models yield product or service
costs at designated Cost or Work Breakdown Structure (CBS/WBS) levels
and may provide departmentalized breakdowns of generic cost elements. A
parametric cost estimate provides a logical and repeatable relationship
between input variables and the resultant costs.

Hardware parametric cost estimating techniques are widely utilized by
industry and government. The use of these techniques expedites the
development of price proposals by the contractor, evaluation by the
government, and subsequent negotiation.

The simplest form of parametric estimating tool is a CER. In this form a
relationship between cost and non‑cost variables is investigated to
determine any possible cause and effect linkages. A statistical analysis
is performed on representative samples of a historical database to
validate these linkages. The analysis is usually based on the
investigation of the relationship between two or more variables. The
known variable (physical parameter, schedule, etc.) is called the
independent variable; the variable we are trying to predict, the cost of
the item, is the dependent variable. The resultant CER is an expression
of the mathematical relationship between parameters characterizing the
item to be estimated and its cost. The strength of CER\'s lie in their
relative simplicity and the convenience they afford in predicting costs.

The primary limitations of CER\'s is that they will yield reliable cost
estimates only within the limits of the spread of independent variables
that were used when the CER was developed. In high technology areas, the
limits of input parameters (independent variables) might go outside the
boundaries of the historical database. Therefore, either the CER\'s must
be re‑examined and updated as the historical database increases, or the
use of the CER must be limited, or used appropriately by properly
trained professionals.

A more sophisticated form of parametric estimating is the computerized
Parametric Estimating Model. These models estimate costs on a broader
scale and are more versatile and much less restrictive than the
acceptable boundaries of CERs.

With parametric estimating models, system acquisition costs can be
derived that are based upon parameters such as quantity, size, weight,
power consumption, environmental specification, complexity and type of
electronic packaging, etc. Some models can also provide schedule
information, or evaluate specified schedules in terms of costs.
Parametric estimating models can provide early cost measurement of
system concepts with a limited description of physical or other
parameters. They are also frequently utilized for independent assessment
of conventionally prepared cost estimates.

Numerous \"home grown\" parametric cost models exist throughout industry
and government to cover a specific range or type of products or systems.
There are also universal parametric estimating systems that generate,
internal to the model, appropriate expressions of CER\'s for a broad
range of products or systems. These models perform a mathematical
extrapolation of past experience in order to predict cost.

Computerized parametric cost estimating models often contain many
mathematical equations relating the input variables to cost. Each set of
input parameters uniquely defines the item of interest for cost
modeling.

Universal parametric (i.e, generic) cost estimating models usually
require calibration. Considering the variety of products, the
differences in accounting methods, etc., the calibration process \"fine
tunes\" these models to emulate the producer\'s organizational and
product characteristics. The calibration process simulates past product
history and organizational traits.

Parametric estimating systems (models) exist to rapidly compute hardware
development and design costs, manufacturing costs of prototypes and
production units along with all the manufacturing support costs. Models
are also available for computing operation and support costs of hardware
in the field. Also, models used for the development and maintenance
costs of computer software are available.

A model is a representation of a real‑life system. In the case of cost
estimating, a parametric model is a system of data, equations, and
inferences presented in mathematical form to represent or describe the
cost of an item. It relates knowns (system descriptions or parameters)
to unknowns (cost of systems). A model can be as simple as a single
equation (CER), or as complex as an inter‑relation of many equations and
functions. It can also be designed to estimate items as small as modules
or components, or as large as subsystems, systems, total programs, or
large development activities.

**[OVERVIEW OF HARDWARE COST MODELING]{.underline}**

A Hardware Cost Model provides estimates of system acquisition costs
based upon quantitative parameters such as complexity, quantity, weight,
and size; and qualitative parameters such as environmental
specification, type of packaging, and level of integration; and schedule
parameters such as months to first prototype, manufacturing rate, and
amount of new design. Hardware cost parametrics bring speed, accuracy,
and flexibility to the cost estimating process. Early cost measurement
of concepts is crucial to a new venture since there is little
opportunity to change program costs significantly once a design has been
detailed. Parametric cost models have been developed to operate with
limited concept description so that many alternatives can be costed
before designs and bills of material are finalized. Parametrics can also
be used extensively as the basis of a cost estimate in preparation of
proposals as well as for the independent assessment of conventionally
prepared cost estimates.

Hardware cost models may be formulated as a universal system to generate
appropriate regressions or CERs for a range of products or systems. In
essence, they permit extrapolation of past experience to predict costs.
Inputs to hardware parametrics cover a wide range of systems. Since all
assemblies must have weight and size, these are often used by the models
as principal descriptors. Electronic hardware items are characterized by
the electronic application and type of componentry. Mechanical and
structural elements can be described in terms of their construction,
type of material, functionality, machinability, and manufacturing
process.

Some uses of Parametric Hardware cost models are:

\* Proposal preparation and submittal

\* Estimates of cost to complete

\* Estimates of modifications

\* Should cost analysis

\* Most Probable Cost estimates

\* Evaluations of bids and proposals (\"Sanity\" Checks)

\* Vendor negotiations

\* Life cycle cost estimates

\* Basis of estimates

\* Independent cost estimates

\* \"What ifs\"

\* Design cost trade‑off analysis

\* Bid/No Bid decisions

\* Estimates of spare parts costs

\* Design to Cost

\* Rough Order of Magnitude (ROM) cost estimates of new or advanced
hardware systems

Parametrics are applicable to all aspects of hardware acquisition ‑
development, production, purchased and furnished hardware, hardware
modifications, subcontractor liaison, hardware/ software integration,
multiple lot production, and hardware integration and test. A normal
modeling capability should exist at all levels of the Work Breakdown
Structure (WBS). Estimates of integration and test costs which are
attributed to each level of integration should also be estimated.

When a parametric model calculates a cost for manufacturing, it does not
use a parts list and labor resource build up, but rather a parametric
representation of the parts and labor costs. Fundamental Input
Parameters To Typical Parametric Models Are Listed Below:

\* Functional design parameters.

\* Quantities of equipment to be developed, produced, modified,
purchased furnished and integrated and tested.

\* Applications (technology of materials and processes) of structural
and electronic portions of the hardware.

\* Hardware geometry consisting of size, weight of electronic and
structural elements, and electronic packaging density.

\* Amount of new design required and complexity of the development
engineering task.

\* Operational environment and specification requirements of the
hardware.

\* Schedules for development, production, procurement, modification, and
integration and testing.

\* Fabrication process to be used for production.

\* Yield considerations for hardware development.

\* Pertinent escalation rates and mark‑ups for General and
Administration charges, profit, cost of money, and purchased item
handling.

The fundamental characteristic of parametric inputs is
inter‑relationship. A change in any one parameter is usually not
localized to one cost element, but rather, may have a ripple effect on
several cost elements. Consider the impact of a change in quantity.
Certainly this change would cause a change in the manufacturing cost. It
may also effect the fabrication process, and, hence, the cost of tooling
and test equipment. In addition, a change in quantity could impact the
production schedule, and thus, impact the costs associated with
escalation. An impact on integration and test, sustaining engineering,
and project management would almost certainly result from a change in
quantity. This dynamic effect is characteristic of most input variables,
and most parametric models.

The model's input parameters uniquely define the hardware for cost
estimating and modeling. The resultant cost output is determined from
the model\'s mathematical equations alone.

Cost may be estimated with a minimal amount of hardware information.
This feature makes models a legitimate tool for cost estimation of
programs in the conceptual stage of development. Of course, it is always
preferable to provide as much information to the models as possible. In
this way, statistical uncertainty associated with the input variables is
reduced.

The modeling activity is basically a conversation between the model and
the cost analyst. Parametric data representing the hardware to be costed
is formulated, and the analyst calls upon embedded text, tables, and
utilities of the model to help create and store the data used to drive
the model. In the course of using a parametric model, the analyst
controls the output formats, the ability to perform sensitivity and risk
analysis, and of course the data that are used to estimate the cost of
the hardware. The data elements created during a session usually
represent systems or sub‑systems composed of many separate
sub‑assemblies. For example, an aircraft might be represented as a
system composed of an airframe, propulsion units, avionics, air to
ground controls, flight controls, and ordinance. In turn, the flight
controls might be a sub‑system composed of instrumentation, radar, and
various processors. At an even lower level, we might find a digital
processor composed of input/output circuits, data storage memory,
program memory, logic circuits, power supply, and chassis and housing.
The number of hardware elements and relative detail of the parametric
information in each is determined by the analyst. There is no limit to
the level of detailed data used for an analysis as long as the cost
model contains historically verifiable parametric cost relationships at
the desired level. Nor is there a requirement that precludes a
parametric user from treating the entire aircraft as a basic assembly of
the lowest order. Thus, an analysis might be accomplished with one data
set representing the aircraft as an assembly, or it might be attained
with many elements representing the aircraft as a system of sub‑systems,
assemblies, and sub‑assemblies. The amount of detail provided to the
model is purely at the descretion of the analyst.

Parametrics can estimate costs for the development and production phases
of the acquisition process. Outputs are categorized by such cost
elements as: drafting, design, project management, system engineering,
data, manufacturing, and tooling and test equipment, etc.

Some parametric models contain the effects of phased interactions
between engineering and manufacturing. In addition to considering a
normal performance period, estimates of the cost impacts due to
accelerated or protracted engineering schedules or due to an operation
plan that requires stops and restarts of production effort can also be
computed.

A comprehensive parametric model should allow an analyst to:

\* Calibrate (Automated is best)

\* Estimate the cost of multiple lot production

\* Calculate manufacturing costs of non‑homogenous assemblies

\* Determine the cost impact of compressing or extending development or
production schedules.

\* Estimate the cost impact of the development schedule (concurrency or
lapse) on production.

\* Perform Cost Risk Analysis

A graphic depiction of hardware modeling is shown in Figure IV-1.

**HARDWARE MODELING**

Hardware model applies common parameters in the comparative evaluation
of new requirements in light of analogous histories.

**FIGURE IV - 1**

Hardware modeling normally entails stringing together numerous CERs
using an appropriate mathematical logic. The math logic is derived
during the calibration process, and allows the math model to emulate the
\"real world\" of program history or to other supportable data or
estimates. When the \"real world\" model is developed, then the new
requirements can be evaluated based on the calibrated model. Modeling
offers significant advantages to the estimator in that once CER
development and the calibration process is complete, cost estimating is
quick, repeatable, and cost effective.

For instance, the first unit production missile cost (T~1~) may be
modeled as

T~1~ = \[(Structure CER) + (Propulsion CER) + (G&A CER)\]\*1.15
(integration factor)

Then,

Total Missile H/W Cost = T~1~ \* Q^b^, where,

Q = quantity, and b is a cost improvement exponent.

Also, for systems engineering and program management we may get

S/E + P/M = .10\*(Missile H/W cost)

Models can also be used to estimate non-recurring development costs.
These costs would be estimated using parameters such as the number of
prototypes, number of tests, the amount of new design and design repeat,
design complexity factors, and others.

A simplified parametric cost estimating process is shown in Figure IV‑2.
The process connects the parametric model to a post processor that in
turn converts the parametric model outputs into typical cost proposal
reports. Ultimately, the customer needs proposal reports in standardized
formats so that competing contractors can be conveniently compared.

Just as the value of a house, when it is evaluated for a mortgage or a
refinancing, is calculated using parametric approaches (square feet, \#
rooms, zip code, \# bathrooms, etc.), the complex products we normally
deal with can be evaluated in exactly the same manner. Parametric
modeling can greatly simplify the cost estimating and cost analysis
processes.

**PARAMETRIC COST ESTIMATING CONCEPT**

PROGRAM HISTORY PROGRAM HISTORY Cost Functional Distribution

Technical

**New Program Baseline Forward Pricing Rates**

WBS

Lines of Code

Make/Buy

Weight

Power

Material

Schedules

Vendor Quotes

**FIGURE IV-2**

**[MICRO‑CIRCUIT AND ELECTRONIC MODULE MODELING]{.underline}**

Parametric cost models exist that are designed to provide quick and
reliable estimates for development and production costs of individual
custom micro‑circuit chips and/or electronic modules. These models
provide the capability to estimate costs and schedules associated with
the development and production of modular electronics, custom
Application Specific Integrated Circuits (ASICs), hybrid or MMIC
packages, common components, and system modules. In view of the
significant cumulative expenses for custom chips, these models are
invaluable for procurement or product planning. Models can assist
analysts in future product planning and incorporate state of the art
technology in the cost estimating process.

Using a WBS structure, analysts can use models to form cost estimates
for individual micro-circuits (chips), the integration of these chips,
and additional electronic components on electronic modules. If the
situation exists, these models may be integrated onto electronic modules
with additional components. The final electronic module may then be
integrated into the WBS used by the hardware models.

Micro‑circuit model input parameters are determined by physically
describing the micro‑circuit, other electronic components, and the
electronic module. A wide range of custom chips can be processed through
use of generic input parameters which include:

\* Number of pins

\* Number of transistors and/or gates

\* Die size

\* Type of packaging

\* CAD sophistication

\* Amount of new design

\* Manufacturing yield

\* Development/Production schedules

Inputs for electronic modules include:

\* Module size

\* Number of sides used for component mounting

\* Technology

\* Function (Memory, Analog, etc.)

\* Quantity produced and/or developed

\* Packaging or interconnect method

\* Board type

\* Development/Production schedules

\* Quantity and types of components

Components as defined for use within these models may be custom chips as
well as off‑the‑shelf items. The amount of detail about the components
may be very limited or as detailed as available information will permit.
A component database file may be used to catalog standard components
that are used on several different electronic modules. This file may
contain information about the standard components including the cost, if
known. Whenever a component from a database file populates a module, it
can be referred to by name with only the number of components per module
required as additional information. The analyst should be allowed to
provide as much cost information as is available. This information may
contain component cost, board cost, and/or assembly and test costs. Any
costs not provided will then be estimated by the model.

Output formats will depend on the item modeled. For a custom
micro‑circuit, costs might be estimated for:

Development engineering costs such as:

\* Chip specification,

\* Chip design,

\* Systems engineering,

\* Project management,

\* Data,

\* Prototype manufacturing

For electronic modules, some of the costs that are estimated are:

\* Development engineering:

\* Drafting

\* Design

\* Systems engineering

\* Project management

\* Data

\* Prototype manufacturing

\* Tooling/Test Equipment

Production costs would be:

\* Drafting

\* Design

\* Project management

\* Data

\* Manufacturing

\* Tooling/Test Equipment.

As with the hardware models, micro‑circuit models have the capability to
be \"fine tuned\" to, directly reflect a particular company and/or
product through the process of calibration. In this sequence of
operation, the model uses actual cost data as inputs and provides
development and manufacturing indices directly related to the historical
costs and specifications. These calibrated indices can then be used as
the basis for estimates of proposed custom micro‑circuits and/or
modules.

[HARDWARE OPERATIONS AND SUPPORT (O&S) OR LIFE CYCLE MODELS]{.underline}

Life cycle cost is defined as the cost associated with all the phases of
a program: design, development, prototype, production, and maintenance
and operations (M&O or O&S). Models are available to estimate life cycle
costs of a variety of hardware programs. With appropriate information,
the life cycle costs of hardware systems can be evaluated. Through
integration with the WBS structure, cost factors for different
equipments are calculated in order to estimate life cycle costs.
Moreover, the models provide for tailoring our analyses to fit a variety
of maintenance concepts and supply systems in order to customize
specific programs and user organizations. After the inputs of a set of
descriptors, the models produce categories of life cycle cost in each of
three phases: development, production, and support.

In a typical application, analysts can instruct the model to select the
most cost effective of numerous built‑in maintenance concepts. Operating
features allow the analyst to specify a subset of the maintenance
concepts for model evaluation. In addition, the analyst can tailor a
variety of maintenance concepts by mixing the preestablished concepts.
Some of these concepts could be:

\* Discard CRU at Failure.

\* Replace parts at depot.

\* Replace parts at manufacturer location.

\* Replace mods at equipment level. Scrap bad mods.

The strength of life cycle models are derived from three factors: 1) use
of hardware models to rapidly generate all hardware related input
parameters ‑‑ particularly useful in the decision making stages of early
concept development before hardware design details are known; 2)
availability of preset maintenance concepts ‑ among which the models can
be instructed to determine the most cost effective approach; and, 3)
ability to rapidly tailor program parameters to reflect specific support
conditions. The interactive feature of parametrics permit immediate
processing of sensitivity analyses to determine the effect of
uncertainties of input data.

Some of the sensitivity analyses allow the determination of the effects
of changes in:

\* Number of equipment level maintenance and/or supply locations.

\* Number of organization level maintenance and/or supply locations.

\* Number of intermediate level maintenance and/or supply locations.

\* Number of depot level maintenance and/or supply locations.

\* Duration of the support period.

\* Cost, size, and weight of units, modules, and parts.

\* Cost of contractor repair.

\* Test equipment costs and loading factor.

\* Shipping costs.

\* Crew size and labor rates.

\* Dedicated vs. non‑dedicated crews.

\* Attrition.

Determination of the effects of the following may be addressed using
risk analysis features built into some models:

\* Equipment operating time.

\* Unit Mean Time Between Failure (MTBF).

\* Unit and Module Mean Time To Repair (MTTR).

\* Authorized stock levels at all supply levels.

\* Safety stock coefficients.

\* Scrap and repair fractions.

Another feature is the capability to model different theaters of
deployment and multi year specification of equipment deployment and
employment (called gradual force structuring). This capability permits
more accurate modeling of remote depots sending work back to a central
depot or the manufacturing facility (contractor facility). Force
structure data permits variation in force levels for each year, as well
as the planned levels of equipment operation for each year.

There are three principal categories of data required to estimate costs
with Life Cycle models: deployment and employment; hardware parameters;
and program globals.

**Deployment And Employment**

This category of inputs pertain to the number of locations at which
equipments are installed, the number of locations at which they can be
maintained, and the number of locations authorized to stock spares; how
often the equipments are operating; and the length of time of the
support period. The analyst defines the size of the program in terms of
the number of locations at which equipments are installed; the number of
organization maintenance locations (for maintenance concepts that
involve organization maintenance); the number of Intermediate
maintenance locations (for concepts that use Intermediate maintenance);
and the number of depot maintenance locations (Government or contractor
depots). With other inputs, the analyst can specify whether these
locations are maintenance only, maintenance and supply, or supply only.
To further define the size of the program, the analyst specifies the
duration of the support period in years, and the \"on‑line\" of the
installed equipments either as hours per month or as a fraction of real
time.

**Hardware Parameters**

Hardware dependent parameters should be generated by the hardware
parametric models for each element modeled in the WBS structure, and
then input into the life cycle model.

**Program Globals**

This is the largest group of inputs, and they are used to describe the
maintenance and supply system to the model. All have preset values that
may be changed by the analyst. Unique sets may be created for use in
subsequent applications of the model.

Some categories of Program Globals are:

*Spread Globals*: Used to control distribution of resources and/or
expenditures across schedules.

*Supply Administration*: To uniquely define the administration as U.S.
Air Force or Navy.

*Discretionary Supply Times*: Frequency of unit, module, and part
ordering.

*Input Data Multipliers*: Coefficients to permit uniform variation of
hardware input parameters for cost effect measurement.

*Miscellaneous*: Includes controls for stock administration,
programmable test equipment software, test equipment maintenance,
attrition, average number of parts consumed per repair, false failure
detection scheduled maintenance, and others.

*Provisioning and Labor*: Stock controls for meeting expected demand of
all units, modules, and parts at each pertinent supply location, number
of hours in a work week, and labor costs at each maintenance location.

*By Theater*: Theater specific parameters dealing with pipeline times at
each maintenance/supply location, fractions of repairs resulting in
scrapping, and supply stocking (inventory) cost factors.

**[COMMERCIAL MODELS]{.underline}**

There are several commercially available hardware cost estimating
models. Three typical models (FASTE, PRICE, SEER) that estimate one or
more of the hardware types are discussed below. Although there are many
others (See Appendix E) this chapter will only discribe these three as
representative. The models will allow an analyst to:

\* Model an entire project through Engineering Development, Production,
Integration, Installation and Life Cycle Phases.

\* Calibrate and Perform Forward Costing.

\* Project Input Files and Output Files.

\* An Economics File.

\* Input variables to the model.

\* Get needed information through the on‑line Help system.

**MicroFASTE**

The MicroFASTE model is used to help the analyst to develop a parametric
model to be used to estimate the costs associated with implementing a
project.

The goal of a particular project may be the production and installation
of a Hardware system, a Software system (or a combination of both). It
may be the construction of nuclear power stations, radar systems or
manned space stations.

Even performing cost estimates for the implementation of a financial
funding program, the construction and operation of an underground coal
or uranium mine, or the design and production of a highly complex module
containing very advanced micro‑circuitry technology are possible through
the techniques of parametric systems analysis.

However, the MicroFASTE model (where the \"E\" on the end of
\"MicroFASTE\" means Equipment), is exclusively for use in performing
parametric analyses for Hardware systems.

Hardware development projects involve several major phases of
implementation. These phases and activities have much in common whether
the project involves production and integration of a small hardware
device, or a large, complex multi‑assembly hardware system. It is these
phases in which costing studies are performed. MicroFASTE classifies
these common implementation phases into the following categories and
sub‑categories:

***Equipment Acquisition Phases and Life Cycle (O&S)***

1\. [Engineering]{.underline}

Design/Drafting

Involves the detail design engineering and drafting effort that
implements the governing specification.

*Systems Engineering*

Establishes the equipment\'s design, performance and test
specifications, predicated on the controlling requirements.

*Documentation*

The recording of engineering activities, preparation of equipment
manuals and required management reports.

*Prototype and Testing*

Covers all charges connected with the manufacture and testing of
engineering prototypes, and includes all brass and bread board models.

*Special Engineering Tooling*

Embodies the special tooling charges affiliated with the prototype
efforts. It does not include capital or amortized equipment that may be
related to the tooling. When there are no prototypes, there will be no
tooling charges.

*Project Management*

Takes in the overall management of all areas connected with the
engineering efforts such as planning, budgeting, operations and
financial controls.

2\. [Production]{.underline}

*Manufacturing*

Involves the direct production charges. This is the same cost value as
calculated when Total Production is specified without the detail
breakdowns.

*Engineering Support*

Embodies the engineering effort that is realted to the manufacturing
activity such as material design reviews, corrections of defects, etc.

*Documentation*

The recording of production events as well as changes to equipment
manuals as necessitated by design modifications caused by production
problems.

*Production Tooling*

Covers special required tooling. It does not include the cost of capital
equipment, or tools that are amortized in overhead accounts.

*Project Management*

Takes in the management of all areas associated with production such as
planning, budgeting, operations and financial control.

3\. [Life Cycle (O&S)]{.underline}

Life Cycle costs are the charges involved in the maintenance and support
of the deployed equipments. The Life Cycle period runs from the first
day of the Starting Year until the last day of the Finish Year specified
in the Life Cycle procedure.

The maintenance concept varies in relation to the equipment\'s
technology and size. The deployed quantities, along with the indicated
Mean‑Time‑Between‑Failure and On‑Time‑Fraction may significantly affect
the equipment availability.

Although Life Cycle cost studies are performed in association with an
Item\'s acquisition studies, Life Cycle costs may not be accumulated
into the project\'s total costing structure. They must be kept track of
separately; the reason for this is that the time frames over which Life
Cycle costs would be realized always span a much greater period of time
than other facets of the project.

***System Integration***

Integration is a study, as an independent analysis that covers the costs
of consolidating various Items into a higher order of assembly. In an
Item\'s Acquisition study, there are variables used to indicate the
character of the Item\'s integration requirements. When an integration
study has been completed, the calculated integration costs may be
accumulated into the project\'s total costs.

***Equipment Installation***

Equipment Installation studies are applicable to large energy producing
systems such as steam or nuclear power plants, and large hardware
systems such as those installed in chemical manufacturing plants. When a
significant percentage of the project\'s total cost will be involved in
putting the equipment in place and making necessary mechanical and
electrical connections to perform its intended task, that is when it
becomes necessary to perform Installation cost analyses.

Installation studies are not generally applicable to relatively small
hardware systems, even though the hardware system may indeed have to
undergo an actual installation procedure to have it perform its intended
function. The costs associated with these activities are accounted for
during the System Integration phase of cost analysis.

Installation is a study that covers the costs of placing this type of
equipment at its work site. Installation studies are performed on an
Item-by-Item basis to determine each pertinent Item\'s installation
costs. Installation costs, therefore, are not computed on a total system
or project basis. However, after completing an Item\'s Installation
study, the calculated costs may be accumulated into the project\'s total
costs.

Normally, the Installation study should follow an Item\'s Acquisition
study. Installation efforts may include production and/or engineering
phases, and their costs may be processed in either a total or a detail
manner.

***Calibration***

Typically, when a costing study is performed on some new unit of
equipment, there are various factors which may not be known about the
item, such as how much one unit will weigh after it is produced. The
model provides the capability of performing a type of study called a
Calibration, which is a costing calculation in reverse, used to generate
reference factors. When weight and its complexity factor, traditional
key factors in parametric cost calculations, are absent, the model will
generate a calculated or \"fiducial\" weight along with a corresponding
weight factor if input costs are given.

In performing calibrations for an Item, the analyst supplies as much
information in parametric form as is known about the item, and enter the
previously known costs of a reasonable, similar item. Then, after the
model performs its calculations for the set of calibration data, a
calculated weight as well as other calculated reference factor values,
including the complexity factor, will be displayed. Those calculated
values can be retained, and used as input values when deriving the
estimated costs of any new unit of equipment.

It may be desirable to perform an iterative series of Calibration and
Forward Costing exercises for a particular unit of equipment until
reference factor values are derived that seem most reasonable for a
given project.

The processes of Calibration and Forward Costing can be applied to any
or all of program phases: Acquisition, Life Cycle, System Integration
and Installation.

**Price Parametric Models**

PRICE models use the parametric approach to cost estimating. Parametric
cost modeling is based on cost estimating relationships (CERs) that make
use of product characteristics (such as hardware weight and complexity)
to estimate costs and schedules.

The CERs in the PRICE models have been determined by statistically
analyzing thousands of completed projects where the product
characteristics and project costs and schedules are known. These
projects encompass a wide range of products and companies. The PRICE
models contain many hundreds of CERs that work together to compute the
costs and schedules for the development and production of hardware and
software products.

An example of parametric modeling is the technique used for estimating
the cost of a house. The actual cost of building a house is, of course,
the total cost of the materials and labor. However, defining the
required materials and labor for developing this cost estimate are time
consuming and expensive. So, a parametric model that considers the
characteristics of the house is used to estimate the cost quickly. The
characteristics are defined quantitatively (floor area, number of rooms,
etc.) and qualitatively (style of architecture, location, etc.).

This parametric technique for estimating the cost of building a house is
widely used in the insurance business and for taxation assessment.

Just as with the building example, determining and costing the material
and labor requirements for hardware and software projects are also
time‑consuming and labor‑intensive, and since the product
characteristics can be defined long before the material and labor
requirements, parametric models permit estimates to be obtained earlier
than with other techniques. Early management and engineering decisions
can be based on these \"up front\" estimates. Many business decisions
must be made before there is sufficient product definition to develop a
conventional estimate. Using parametrics makes it practical to explore
the cost risks associated with uncertainties in the project, and to get
answers to \"what if\" questions such as: \"What if we shorten the
development cycle?\" \"What if we build fewer prototypes?\"

Predevelopment Cost and Schedule Estimates ‑‑ Cost and schedule
estimates can be obtained to develop and manufacture a product that is
still only a concept. The PRICE models accomplish this by using product
characteristics to develop the estimate. PRICE does not require labor
hours and a bill of material.

This early‑on estimating capability makes PRICE a tool for design
engineers, since much of a product\'s cost is locked in by early
engineering decisions. PRICE can provide engineers with cost information
needed to develop minimum‑cost designs.

***Descriptions Of The PRICE Models***

[PRICE H]{.underline}

PRICE H is used to estimate the cost of developing and producing
hardware. Most manufactured items and assemblies can be estimated using
PRICE H. PRICE H uses product characteristics to develop the cost
estimate. This makes the model a good tool to use at the product concept
stage, when there is insufficient definition to quantify the product
labor and material required for a conventional estimate. Key inputs to
the PRICE H Model are:

\* Weight ‑‑ tells the model the size of the product being estimated.

\* Manufacturing Complexity \-- a coded value that characterizes product
and process technologies and (optionally) the past performance of the
organization.

\* Platform ‑‑ a coded value that characterizes the quality,
specification level, and reliability requirements of the product
application.

\* Quantities ‑‑ the number of prototypes and production items to be
estimated.

\* Schedule ‑‑ the dates for the start and completion of the development
and production phases may be specified. The model will compute any dates
that are not specified. Only the date for the start of development is
required.

\* Development Costs ‑‑ effort associated with drafting, design
engineering, systems engineering, project management, data, prototype
manufacturing, prototype tooling, and test equipment.

\* Production Costs ‑‑ effort associated with drafting, design
engineering, project management, data, production tooling,
manufacturing, and test equipment.

\* All costs are reported at the material, labor, overhead, and dollar
level.

It is generally acknowledged that most of the cost of a product is
locked in by the early engineering design decisions. This means that the
early decision process should consider cost as well as technical
alternatives. The lack of product definition early in the concept stage
precludes a credible conventional cost estimate. With PRICE H, however,
engineers and managers are able to develop cost estimates for each
alternative to select minimum cost‑product designs. Before any
investment has been made in design engineering, PRICE H can compute the
unit production cost of a product.

PRICE H can be quickly iterated to obtain estimates under varying
assumptions until the value selected for the estimate represents
acceptable risk. With PRICE H, cost sensitivity to project uncertainties
can be explored, and management\'s \"what if\" questions can be
answered.

[PRICE HL]{.underline}

The PRICE HL (Hardware Life Cycle) Model calculates costs, cost
effectiveness, and operational availability at the system, subsystem,
assembly, and sub‑assembly levels. It is used in all phases of the
acquisition process and is especially well suited when linked with PRICE
H for high‑level analyses in the concept and system design phases. This
coupling provides a system level trade‑off capability to effectively
determine hardware life cycle costs during early stages of hardware
designs. PRICE HL provides cost outputs for all phases of the hardware
life cycle.

[PRICE M]{.underline}

The PRICE M (Electronic Module and Microcircuit) Model produces
estimates of development and production costs for electronic modules and
application specific integrated circuits (ASICs). It uses cost
estimating relationships based on the number of transistors and/or
gates, percentage of new circuit cells and design repeat, specification
level, degree of computer‑aided design, product familiarity, engineering
experience, and calibration factors to estimate ASIC specification and
design costs. Additional relationships provide systems engineering,
project management, and data costs. PRICE M contains a database for
frequently used components that can contain predefined costs or that can
be calculated from the component input specification.

**SEER**

The SEER family of models include the basic hardware cost estimation
model (SEER‑H) and a hardware life cycle cost model. The hardware cost
model estimates hardware cost and schedules and includes a tool for risk
analysis. The hardware model is sensitive to differences in hardware
technologies ASIC, MCMS, exotic materials, miniaturization, etc., and to
different acquisition scenarios; make, modify, customer‑furnished,
purchased, off‑the‑shelf, etc. It is also sensitive to differences in
electronic versus mechanical parameters and makes estimates based on
each hardware item\'s unique design characteristics.

The SEER hardware life cycle model (SEER‑HLC) evaluates the life cycle
cost effects due to variations in: reliability, mean time to repair and
repair turnaround times. SEER‑HLC complements SEER‑H, and both models
will run on a personal computer. The models are based on actual data,
utilize user‑friendly graphical interfaces, and possess built‑in
knowledge bases and databases that allow for estimates from minimal
inputs.

SEER‑IC is an expert system for planning integrated circuit development
and production. SEER‑IC provides a systematic, expert approach to cost
and resource estimation and a capability for Design to Cost (DTC)
tradeoffs and risk analysis. SEER‑IC includes an industry‑wide knowledge
base.

SEER‑DFM (Design for Manufacturability) is a tool designed to assist the
engineer produce and assemble products with efficiency, in a manner
designed to exploit the best practices of an organization. Diverse team
members have an idea of what their true interests are and of how they
can work together and input to the model accordingly. The fundamental
goal of DFM is to make engineering decisions that optimize the
manufacturing process.

Two fundamental analysis steps are taken in a DFM regime: the gross and
detailed tradeoff analysis.

\* Gross analysis involves product design decisions, and also
fundamental process and tooling decisions. Factors that influence gross
analysis include the quantity of the planned product, the rate at which
it will need to be produced, and the investment required. There are also
machinery, assembly and setup costs to contend with.

\* Detailed analysis takes place once many of the primary production
parameters, such as design and basic processes, have been fixed. Factors
that can be adjusted for and balanced at the detailed level include
tolerances, the proportion of surface finishes, secondary machining
options (drilling, reaming, polishing), and the age and degree of
process intervention (how soon is a machine recalibrated or
rebalanced?).

SEER‑DFM explores the DFM effort by developing engineering tradeoffs
that are involved in a DFM analysis and presents the results of each as
costs. SEER‑DFM models the categories of materials and processes used in
modern production lines. SEER‑DFM integrates the following models:

\* machining (turning, boring milling, shaping, chemical‑milling,
grinding\... ): The model explores the tradeoffs from starting with raw
stock vs. sand or investment‑casting, etc. The material may also be
varied. Tooling, setup and other costs hinge on these choices.

\* sheet metal fabrication (presses, shears, die press).

\* mechanical assembly (spot welding, bolting, bracing).

\* electrical assembly (PC board assembly, parts preparation, soldering
& wave soldering, fasteners).

\* injection molding: parameters include weight, cycle time, and
cavities in the mold.

\* SEER‑DFM performs the analysis from standard work measurements
(standard times).

**[REGRESSION‑BASED PRODUCT SPECIFIC COST MODELS]{.underline}**

In many cases regression‑analysis based cost models are generated by
government agencies (or program offices), government support
contractors, or hardware/software contractors. In such cases, a
sufficient quantity of cost data is usually available to build
statistical, i.e., regression based CERS. The flow diagram in Figure
IV‑3 shows the most commonly used process.

![](media/image1.emf){width="6.014583333333333in"
height="7.969444444444444in"}

The point of departure is a Work Breakdown Structure (WBS) or a Cost
Breakdown Structure (CBS). There are many WBSs in existence, such as the
standard WBS by DoD (MIL‑STD‑881B) or contract specific WBS\'s (See
Appendix B). Often, a contract specific WBS is broken into work packages
which are not very suitable for determining component or subsystem
costs. Considerable effort is usually required to extract cost drivers
from the cost of WBS elements which are meaningful and
\"uncontaminated\" by activities which are applicable to more than one
WBS element.

Preliminary CERs are conceptualized, and both cost and technical data
are collected according to the WBS elements and CER format. The cost
data are then normalized with respect to base year constant dollars,
quantity of hardware, completeness of cost inclusions, etc., and
statistical regressions are performed to correlate cost (dollars or
hours) to cost drivers. Mathematical equations for the CERs resulting
from the regression analyses are first checked for their statistical
validity, and next for technical credibility. An extensive review cycle
is then entered, complete with Beta testing, checking by technical and
cost experts within the government and contractor communities, and
modification of the CERs based on revised information or additional data
sources. The final step of this process consists of a significant amount
of documentation of the CER equations, description of included and
excluded costs, data sources, ground rules, rationale, limits,
uncertainties and applicable comments.

This cost model process leads to parametric CERs which can be used by
the government and by contractors.

**[NON‑COMMERCIAL COST MODELS]{.underline}**

The Government often sponsors the Development of Parametric Cost Models
(e.g., Unmanned Space Craft Model Version 7 by Tecolote Research. And
the Missile Analysis and Display Model by EER Systems Corporation which
was sponsored by the USA Missile Command). These Cost Models are usually
based on historical data from a number of systems and are used by
Government and Contractor Cost Analysts alike to develop cost estimates.
They are often used as secondary estimating techniques and as
crosschecks to the primary estimating methodology.

**[NON‑STATISTICAL COST MODELS]{.underline}**

Non-statistical cost models are those which are based on other types of
mathematical analysis, and are generally engineering models. In many
cases, insufficient data exist to construct a meaningful, regression
based CER or model. For example, if only two cost data points are
present for an item (a hardware item like a transmitter, for instance)
an approximation of a CER would consist of fitting a power curve with an
exceptable exponent through the two data points. The exponent should
make sense in light of the analyst\'s experience.

Non-statistical cost models are generally more judgmental than those
based on regression and additional actual data. Uncertainties associated
with a small number of actual data points could easily lead to large
inaccuracies of the cost model. However, a larger amount of data on
which a regression-based cost model is based does not necessarily
improve its accuracy. It depends on the quality of the majority of the
data points (quantity does not always equate to quality).

The use of non‑statistical cost models puts additional emphasis on the
competence of the model originator and will generally increase the
skepticism of an auditor. Non‑statistical cost models for proposals
should generally be used under the following conditions:

\(1\) An insufficient (to produce statistically based CERs and models)
amount of historical data exists;

\(2\) The existing database is really not applicable (i.e., new
technology or new products are being estimated);

\(3\) The cost modeler has sufficient expertise, knowledge and
competence to construct the model (e.g., with respect to choice of
variables);

\(4\) The model can be validated for at least one, preferably more than
one, case; and,

\(5\) Excellent cost and technical visibility exists for the few data
points which form the basis of the model.

The auditor or reviewer needs to scrutinize the cost model with respect
to the above mentioned five criteria, and request sufficiently
reasonable explanations with respect to the derivation of the cost
model. If necessary, the auditor may also require an explanation why the
particular set of variables are being used in the model.

Non‑statistical cost models may not always have weight and complexity as
independent variables. Size may be implied by amount of energy, thrust
level, tank volume, or parts count. Complexity may be implied by
temperature, efficiency, thermodynamic cycle type, or manufacturing
processes and packaging density. In many cases, non‑statistical cost
models can be constructed by equating cost to these directly measurable
parameters. Care has to be taken to equate cost to
[independent]{.underline} technical parameters.

In general, non‑statistical cost models are used at a top level, i.e.,
are often not divisible into the typical WBS labor and material cost
components. However, they can also cover simple cost‑to‑cost ratios such
as quality control labor to manufacturing touch labor hours with only
one or two data points. In this case, it is up to the contractor to
convince the auditor that the historically developed relationship (e.g.,
labor ratio) for one product will also hold for another (hopefully
similar) product.

**[MODEL CALIBRATION]{.underline}**

The act of calibration standardizes a model. Many models are developed
for specific situations and are, by definition, calibrated to that
situation. Such models usually are not useful outside of their
particular environment. However, general cost estimating models
including commercially available ones such as the FAST, PRICE and SEER
Models (described earlier) are designed to be useful as estimating tools
for a wide range of situations. The act of calibration is needed to
increase the accuracy of one of these general models by making it
temporarily a specific model for whatever product it has been calibrated
for. Calibration is in a sense customizing a generic model.

Items which can be calibrated in a model are: product types, operating
environments, labor rates and factors, various relationships between
functional cost items, and even the method of accounting used by a
contractor. All general models should be standardized (i.e. calibrated),
unless used by an experienced modeler with the appropriate education,
skills and tools, and experience in the technology being modeled.

Calibration is the process of determining if there is any deviation from
a standard in order to compute correction factors. For cost estimating
models, the standard is considered historical actual costs. The
calibration procedure is theoretically very simple. It is simply running
the model with normal inputs against items for which the actual costs
are known. These estimates are then compared with the actual costs and
the average deviation becomes the correction factor for the model. The
actual data used for the calibration runs determines what type of
calibration is done. In essence, the calibration factor obtained is
really good only for the type of inputs that were used in the
calibration runs. For a general total model calibration, a wide range of
components with actual costs need to be used. Better yet, numerous
calibrations should be performed with different types of components in
order to obtain a set of calibration factors for the various possible
expected estimating situations. For instance, the PRICE Hardware model
addresses this situation using internal complexity factors. These can be
modified by calibration to the component level. Board fabrication, parts
costs, packaging costs, and the overall design and manufacturing costs
have factors that can be tuned to a specific product, product line, or
business.

**[COST MODEL AUDIT AND ANALYSIS]{.underline}**

Cost models are significantly more complex subjects than simple CERs.
Typically a cost model uses both CERs and mathematical relationships
between the CERs. Both cost models and CERs are based on historical
data. The analyst reviewing a cost model must review the model, the
basis history and the specific application. In addition, models must be
evaluated heuristically by test cases and sensitivity analyses. If a
product specific model is used in an estimate, the analyst needs access
to more information and be able to explore the model\'s internal
relationships and data base. The disadvantage of generic proprietary
cost models is that the cost analyst sometimes does not have access to
the data base and the CERs embedded in the model\'s \"black boxes.\"

**Analyzing A Product Specific Cost Model**

A non‑standard cost model is usually built by the estimator for the
specific purpose of calculating specific product costs. As such, it will
have specific company factors, CERs, and relationships. It is not
uncommon to have a pricing model as a back end to a proprietary model
for purposes of adding pricing factors and to do output formatting. In
addition, it is common to have a front end to the product specific to
deal with purchased items, ancillary costs and sub‑models. The firm
submitting an estimate may use a spread sheet which are utilized to
adjust one model output or format. See Figure IV-4.

Company

Specific Factors

Pricing Factors

and Formats

**FIGURE IV - 4**

When considering calibration, from an auditor\'s standpoint, basically
three things need to be known about an estimate that is prepared using a
model. There are:

\(1\) The skill level of the model builder.

\(2\) If the model was calibrated, what kind of data was used to do the
calibration? Was it an overall general calibration using several data
points or a more specific calibration with actual cost data that
represents the project being modeled? A calibration will have more
credibility if it is performed with data similar to the project being
estimated.

\(3\) The third consideration has to do with the quality of the actual
cost and non‑cost data that went into the calibration. Historical actual
costs are not necessarily \"real\" costs as far as a calibration
activity is concerned (See Chapter II: Normalization of Data). Other
sources such as actuals from a database, vendor firm quotes, vendor
ROMS, management estimates to completion, industry published costs, and
even estimates from other products or other organizations sometimes can
be used as inputs for calibration. The appropriateness of such inputs
need to be considered. Knowing what went into the calibration (for a
specific model) and how it relates to the model\'s current estimate
needs to be taken into consideration when evaluating the appropriateness
and quality of the calibration.

When a product specific cost model is used to perform the actual cost
estimate, the analyst has to evaluate the model much the same as for
single CERs. In addition, however, the relationship between the cost
elements has to be explored. Are the cost drivers generating only one
set of costs or are the various drivers producing overlapping costs ‑
for example, if a factor is calculating both program management and
data, does the program management number exclude data costs? If product
specific models are used, the basis cost history is important for
checking the calibration of the model. It also has to be examined to see
if the source information is clean and well defined.

Regardless of the model type, it is desirable for the model to be
calibrated for the specific situation at hand. For proprietary product
specific models, the calibration has to include company specific
calibration in order to account for company peculiarities, accounting
methods and rates. Once the general features of the company are
incorporated into the model, the auditor has to check the basis of
estimate (sometimes called complexity) factors. Since models usually
broaden their effective databases by incorporating functional
relationships within parameters, the historical basis data utilized by
the model has to be examined for both cost validity and the mathematical
relationships between the technical parameters and cost. This step is
important since the system to be estimated rarely is exactly like
(technically or functionally) the historical case and some normalization
is usually required in the value of the independent variables. The
analyst must see the documentation associated with the basis case both
for the costs and the technical features. In other words, the basis case
must show the source data for the estimated engineering, data, prototype
costs, etc. The basis case documentation must also show the technical
data ‑ weight, size complexity etc. Again, if the cost elements are
significant, considerable detail may be necessary to verify the basis
calibration. For instance, if Printed Wiring Assembly (PWA) costs are a
significant driver for the \"black box\" being estimated, the basis
costs and technical descriptions must be available in some detail
­perhaps down to the board and chip count level.

Once the auditor has verified the model validity both for the
corporation and for the specific basis case, he or she can then address
the application of the model to the case at hand. This involves
examining the tasks being estimated and the technical features of those
tasks. In development cost estimates, the technical detail may be thin,
consisting of simply performance requirements. In this case, the basis
system performance characteristics become significant. For production
estimates, hardware item drawings should exist and can be compared
directly to the drawings of the basis case ‑ which might even be a
previous version of the item being estimated. In all cases, any
extrapolation must be supported by quality information. Vague references
of \"engineering judgment\" are not satisfactory; this judgment has to
be translated into concrete hardware definitions.

**Summary Of Cost Model Audit And Analysis**

In summary, the analyst reviewing a cost model has to work through
several steps in order to evaluate the model‑based estimate. These are:

\* Is the model proprietary or non‑standard? Does the overall estimate
contain interface models or algorithms which transfer data into and
between other models?

\* If non‑standard, are the model interrelationships well described and
well defined, and do they make logical sense?

\* Do the model elements deal with all the costs in the estimate? If
not, is there any overlap between the costs derived through the model
and the costs developed outside the model?

\* Is the model used without adjustment? If adjusted, what is the
justification and source data for the adjustments?

\* Is the basis case used for reference in the estimate a close analog
to the case being estimated? If not, how far is the basis case,
functionally and physically, from the case to be estimated? What are the
functional relationships within the model parameters, and how sensitive
is cost to error in specifications? What is the source documentation for
the base case?

\* What are the values of the elements in the case to be estimated? How
do they compare to the values in the basis case? What are the source
data for the case to be estimated?

Given that not all these questions have unequivocal answers, the auditor
can examine how variations in the parameter values affect the estimate.
If the model is computerized, the auditor can even do \"what if\" tests
to see if some particular cost relationship is especially important. For
those elements which show significance and which are unsatisfactorily
supported, the auditor can request further information and data.

The objective of the analysis is to see whether the estimate is fair and
reasonable. In complicated logical structures, this issue of overall
reasonableness may evolve as a result of examination of the elements of
the estimate. In addition, softness in data, vagueness in specification
and bias in projection can elevate uncertainty in the cost estimate to
the point that this uncertainty becomes a reasonableness issue. In
short, the cost analyst evaluating a cost model has to assure
him/herself that the model is a good simulation of the true cost
influences, that the basis of the estimate is appropriate and well
founded, and that the extension of the basis through the model is a true
picture of what is proposed in the technical description of the system.
If the answer to all these questions is "yes" and if the uncertainty
associated with the estimate is reasonable, the analyst is looking at a
good cost model and estimate.

Appendix E lists other examples of hardware models and describes in some
detail a few of them.