(A) EPA
t ~9ttf^
Office of Information Resources Management
U.S. Environmental Protection Agency
401M Street S.W.
Washington, DC 20460
Superfunr' temical Analysis Data System
Work Plan for Phase II:
Preliminary Design and Options Analysis
March 1989
Prepared with the assistance of
BOOZ'ALLEN & HAMILTON Inc.
Contract #68-01-7282
-------
SCADS Phase II Work Plan
Table of Contents...
1. Introduction
2. Preliminary Requirements Analysis 7
3. Options Analysis 13
4. Benefit/Cost Analysis 20
A. Overview of the COCOMO Model A-1
B. Overview of the GSA Conversion Cost Model (Version 4) B-1
-------
SCADS Phase II Work Plan
Section!: Introduction
The objectives of this project are to,
Identify potential uses of data in the Superfund program's
Contract Laboratory Program (CLP) Analytical Results Database
(CARD)
Develop a system concept which presents the inputs,
processes and outputs of a system which would address
prioritized and practical user requirements
Determine viable options for implementing the system concept
Analyze benefits and costs and select the best option.
-------
SCADS Phase II Work Plan
Section 1: Introduction
CARD was developed for a single purpose,
Since the early 1980s, the CLP has been EPA's major vehicle for
obtaining chemical analyses of samples from Superfund sites.
CARD has used automated means since January 1988 to collect the
results of these analyses.
To date, the use of CARD data
has been dedicated to a single
purpose -- ensuring that
contract laboratories have
performed within their contract
requirements.
CARD currently resides on
the RTF mainframe and runs
under the ADABAS database
management system.
-------
SCADS Phase II Work Plan
Section 1: Introduction
The Mission Needs Analysis is completed,
In Phase I of the project, the Mission Needs Analysis, over 150
EPA personnel in all ten Regional offices and each major
Headquarters office were interviewed.
Each interviewee identified potential uses of CARD data to
support current or planned activities and described the benefits
which could be derived. The results of these interviews are
recorded in the Report of the Data Collection Effort, dated October
1988.
Next an Initial System Concept was developed to model the
inputs, processes and outputs of a system which addresses user
requirements. The final concept was documented in the Initial
System Concept, dated December 1988, and in the Mission Needs
Statement, dated February 1989.
-------
SCADS Phase II Work Plan
Section 1: Introduction
The next phase of the project is the
Preliminary Design and Options Analysis,
Phase II of the project, the Preliminary Design and Options
Analysis, has the following objectives:
Translation of the user needs identified during the Mission
Needs Analysis into a set of requirements of sufficient
detail to serve as criteria for options analysis
Identification and development of options which satisfy
the defined requirements
Determination of the option with the most suitable balance
of benefits to costs.
-------
SCADS Phase II Work Plan
Section 1: Introduction
Phase II will be conducted in three stages,
Preliminary
Requirements
Analysis
Requirements Checklist
Preliminary
Design and
Options Analysis
Viable Options
Benefit/Cost
Analysis
Selected Option
-------
SCADS Phase II Work Plan
Section 1: introduction
The purpose of this Work Plan is to,
...define a detailed technical approach to conducting a
Preliminary Design and Options Analysis for a Superfund
Chemical Analysis Data System.
This Work Plan describes the three major stages of the
analysis and the steps and deliverables at each stage.
The approach defined in this Plan will serve as the blueprint
for conducting the analyses to follow. It will be refined as the
stages of the analyses progress.
-------
SCADS Phase II Work Plan
Section 2: Preliminary Requirements Analysis
Requirements Checklist
Preliminary
Design and
Options Analysis
Viable Options
Benefit/Cost
Analysis
Selected Option
-------
SCADS Phase II Work Plan
Section 2: Preliminary Requirements Analysis
The objectives of the preliminary requirements
analysis are to...
Establish the preliminary requirements of the proposed system
before a detailed design and development
effort begins
Develop criteria that will be used to evaluate the feasibility of
alternatives identified during the options analysis
Identify areas for improvement, omissions or redundancies
during this early stage and avoid changes at later stages when
changes are more costly.
8
-------
SCADS Phase II Work Plan
Section 2: Preliminary Requirements Analysis
The steps involved in this analysis are,
Step 1: Determine the data, functional, performance, and
special requirements of each potential application of
CARD data identified during the Mission Needs
Analysis.
Requirement?-descri
i^mwM'.-'£Mw'M(-}*MMm:*mmmw*&
or references that
-------
SCADS Phase II Work Plan
Section 2: Preliminary Requirements Analysis
Step 1, determining requirements (cont'd)...
For example, Regions I, III, IV, VI, VII and OPPE, OPTS, ORD, OSWER,
and OW all expressed a keen interest in using CARD data for the
assessment of trends in environmental quality, tracking the
incremental effects of contaminants over time, etc.
The requirements matrix for trend analysis would look like:
POTENTIAL
APPLICATION
Trend Analysis
REQUIREMENTS
DATA
Requires data validation
flags to select data
appropriate for analysis
Requires geographic
locators
FUNCTIONAL
The system must
provide the ability to
screen for data
validation flags
The system must be
able to overlay trend
data over site maps
PERFORMANCE
The system must allow
user-defined
interpretation of data
validation flags
The system must
provide maps of
appropriate scale to
capture detail
SPECIAL
Standardization is
required for the
interpretation of the
data validation flags
Map overlays require an
interface to a
Geographic Information
System (CIS)
10
-------
SCADS Phase II Work Plan
Section 2: Preliminary Requirements Analysis
Next, evaluate the requirements list,
Step 2: The requirements identified and categorized in step 1
will then be evaluated and ranked on their priority and
feasibility, and any constraints will be identified.
REQUIREMENT
CONSTRAINT
1. Data validation flags must be provided. These flags
represent the Regional review of the CLP data.
HIGH
MED
LOW
Standardisation on the implementation and
interpretation of the flags. Logistics of data entry.
o
-------
SCADS Phase II Work Plan
Section 2: Preliminary Requirements Analysis
Finally, narrow the list for the final checklist.
Step 3: After ranking all the requirements, those with a low
priority and a low feasibility, or any duplicated
requirements will be deleted from the matrix.
Step 4: The remaining requirements, listed on a checklist, will
be used as evaluation criteria for the options analysis.
12
REQUIREMENT/CRITERION
OPTION A
OPTION B
OPTION C
OPTION X
-------
SCADS Phase II Work Plan
Section 3: Options Analysis
Preliminary
Requirements
Analysis
Requirements Checklist
Preliminary
Design and
Options Analysis
Viable Options
13
Benefit/Cost
Analysis
Selected Option
-------
SCADS Phase II Work Plan
Section 3: Options Analysis
The objectives of the options analysis are to.
Develop between six and eight design options as potential
system solutions
Evaluate each option in several categories using a rating
system to quantify its desirability
Select the four highest rated options to undergo the benefit/cost
analysis.
14
-------
SCADS Phase II Work Plan
Section 3: Options Analysis
This analysis requires the following steps,
Step 1: Develop between six to eight viable options for
implementing the system concept. The range of
options will be from the status quo to the most
challenging options to implement. Each option will
contain at a minimum the following information:
including process flows and functions
Operational Environment« including hardware, software, telecommunications,
and automated and manual processes
Resources -
Constraints
including labor, ADP, and costs
such as scheduling, industry and EPA trends, etc.
15
-------
SCADS Phase II Work Plan
Section 3: Options Analysis
For example, the status quo option would be,
Option 1 - Status Quo (Abbreviated Version)
Description:
Currently, chemical analysis results from the Contract Lab Program (CLP) reside in the CLP Analytical
Results Database (CARD). (Refer to chart 2 for a listing of data elements.) Automated means have been
employed since January 1988 to place the data in CARD - floppy diskettes of the sample analysis data and
hardcopy reports are forwarded to the Sample Management Office (SMO) where, after a check for usability,
it is transmitted to the logical mainframe in Cincinnati for automated contract compliance screening. After
the screening, the data is transmitted to and resides on the mainframe at RTP.
Operational Environment:
The procedures described above utilize PCs at the contract labs and SMO, an D3M 4341 at Cincinnati, and
an IBM 3090 at RTP. Diskettes are shipped to SMO and data is transmitted thereafter via EPA's Tl
network. SAS, the statistical software package, is used for the contract compliance screening. CARD itself
is a customized ADABAS application.
Constraints:
In order to address user needs for the data,
several severe constraints must be overcome.
These include the inclusion of data validation
flags, site ID codes, and geographic locators.
Resources:
Considerable resources (time, labor and costs) would need
to be expended to overcome the system constraints
16
-------
SCADS Phase II Work Plan
Section 3: Options Analysis
The analysis will include these areas of evaluation,
Step 2: After each option has been designed, the next step is to
evaluate each option against the following categories:
criteria checklist to
§^||ggg|,.'||^:
MMLM tug MII* unwell
? HS;:; :, ' :':| i;;-! /:/*.:."'* £,:"' '". >/'
issues such as the
|^i^^||gi(l
^^^^^^^^^^^^^^^^
lllili«^^^
option willalso be evaluated on the basis o
WoJ^:*!^?^!^***;^.*':'*;*^^;;*;*;**^^ ^^?'S\ ift^^**^* ?. '"'^-"^^^ **^^ ^^*6".ft"y "^ ^*-: T*Sj
,"' "' .- . |'"J-:|:;J-:"i::''^'';:v:':v:;:v:^\ ::'.::;;'vr:'""' ".'.':"'::':'.':'1--'.-.':"'' - '::". "",''-, .':':': -'^-.'-i - -.--'"!'
-------
SCADS Phase II Work Plan
Section 3: Options Analysis
Only four options will remain after the analysis.,
Step 3: As a final step, no more than four options will be
chosen for the benefit/cost analysis.
To do so, weights will be assigned to the evaluation
categories to reflect relative priorities. The rating of the
option in a category will then be multiplied by the
weight of that category, and all ratings for that option
will be summed to obtain a final score. The benefit/cost
analysis will be performed on the four highest scores.
The matrix on the following page illustrates this
process.
18
-------
SCADS Phase II Work Plan
Section 3: Options Analysis
Each option will be scored as illustrated below,
Option A
^v^rv^S' /t- \^'\
S&'&z/.''*. *&£? 5 i - J ^* &
Other
Considerations
O
19
-------
SCADS Phase II Work Plan
Section 4: Benefit/Cost Analysis
Preliminary
Requirements
Analysis
Requirements Checklist
Preliminary
Design and
Options Analysis
Viable Options
20
Selected Option
-------
SCADS Phase II Work Plan
Section 4: Benefit/Cost Analysis
The objectives of the benefit/cost analysis are to.
Determine which option is the most economically viable
Determine which option best meets the system requirements
Identify the desirable and undesirable attributes of each option,
21
-------
SO/IDS Phase II Work Plan
Section 4: Benefit/Cost Analysis
This analysis requires the following steps.
Step 1: The first step to conducting the benefit/cost analysis
will be to decide on a "framework." This framework will
include at a minimum:
Determination of the system life from design through implementation and
operation. (A minimum period of five years is recommended)
Selection of a sample to use as a representation of the entire population in
the evaluation; i.e., costs will be based on representative Regional
office(s) and then extrapolated to estimate Agency-wide costs.
Definition of assumptions used to perform the benefit/cost analysis. The
assumptions could include:
- Consideration of an annual Inflation factor to be applied to all labor costs. (A minimum of 5%/yr. Is
recommended.)
Application of an overhead rate for direct costs
- Assignment of the value of a full-time equivalent (FTE) (OMB Circular A-76 recommends 2087 hours.)
- Determination of a discount rate to be used for net present value calculations. (OMB Circular A-94
recommends 10%.)
22
-------
SCADS Phase II Work Plan
Section 4: Benefit/Cost Analysis
Step 1, developing a framework (cont'd)...
Identification of the recurring (on-going) and non-recurring costs and benefits for each
option:
Recurring Costs
maintenance and lease of ADP
equipment
software maintenance
personnel (including salaries and
fringe benefits)
space occupancy
supplies and utilities
timesharing
training and travel
Non-recurring Costs
initial purchase of ADP and
communications equipment
software development and data
conversion and system testing
initial training
site modifications
studies
Both quantitative and qualitative benefits will be identified and analyzed. Benefits may
include:
- Reductions In costs
- Additional Information processing capabilities
- Greater program effectiveness or efficiency
- Value enhancement.
23
-------
SCADS Phase II Work Plan
Section 4: Benefit/Cost Analysis
The next step is to collect data on costs,
Step 2: Once the framework has been established, the next step is
to collect the data necessary to conduct the cost analysis.
Major costs will be estimated as explained below:
Hardware, training, supplies, etc., will be determined by market analysis.
Software development costs (e.g., changing the functionality of the
current system) will be estimated with the Constructive Cost Model
(COCOMO). (See Appendix A)
Software conversion costs, where applicable, will be estimated with the
GSA Conversion Cost Model (Version 4). (See Appendix B)
Labor costs, including software and hardware maintenance, will be
estimated in FTEs and converted to costs by multiplying by the
appropriate government pay scale.
Space occupancy costs will be an estimate of the square footage
required, multiplied by an agreed upon rate.
24
-------
SCADS Phase II Work Plan
Section 4: Benefit/Cost Analysis
1W3
Tow Co*u
25
quantitative and
qualitative
benefits will be
defined and
listed. Benefits
which can be
quantified will
be calculated by
subtracting the
option's costs
from the status
quq's costs. The benefits can then be summed for the
entire life of the system.
-------
SCADS Phase II Work Plan
Section 4: Benefit/Cost Analysis
The final step is to compare benefits and costs.,
Step 4: The final step of the benefit/cost analysis, is a
comparison of each option's benefits and costs (see
next page). Quantitative comparisons can be made by
calculating the:
An option whose benefits outweigh its costs is
satisfactory to support the Agency's mission.
26
-------
SCADS Phase // Work Plan
Section 4: Benefit/Cost Analysis
The best option will be recommended for SCADS.
Costs:
Casts:
27
Costs:
-------
SCADS Phase II Work Plan
Appendix A: Overview of the COCOMO model
Preliminary
Requirements
Analysis
Requirements Checklist
Preliminary
Design and
Options Analysis
Viable Options
Benefit/Cost
Analysis
Selected Option
-------
Constructive Cost Model (COCOMO)
Summary
A. OVERVIEW
The COCOMO model was developed by Barry Boehm to provide a model to assist with
software engineering economic problems. COCOMO provides various models for
estimating the costs of a software project. There is currently no known software which
automates the COCOMO calculations.
COCOMO is a hierarchical algorithmic method for estimating the costs of a software
project There are three levels to the COCOMO hierarchy ~ the basic, intermediate, and
detailed levels. Each of these levels is further broken down into organic, embedded, and
semidetached development modes. The levels and modes are described in sections B and
C, respectively.
B. HIERARCHICAL LEVELS
The basic level of COCOMO is a simple model for estimating the costs of a
software project as a function of its size in thousands of delivered source instructions
(KDSI). The Basic COCOMO equations for effort and schedule are listed below. The
effort equations are used for estimating man-months (MM) and the schedule equations are
used for estimating the time of development (TDEV) in months.
Development Mode Effort Equation Schedule
1.05 0.38
Organic (MM) = 2.4(KDSI) TDEV = 2.5(MM)
Semidetached (MM) = 3.0(KDSI)' TDEV = 2.5(MM)'
1.20 0.32
Embedded (MM) = 3.6(KDSI) TDEV = 2.5(MM)
The equations from the Basic COCOMO model can be used for the majority of software
projects. The software projects to which this model are applicable are the small-to-medium
size products developed in-house.
The Basic COCOMO model for annual software maintenance effort estimation is
calculated in terms of the Annual Change Traffic (ACT). The ACT is the fraction of the
software product's source code which undergoes some type of addition or modification.
The ACT equation for estimating basic annual maintenance effort (MM)AM, given the
estimated development effort (MM)D. is as follows:
(MM)AM = 1.0 (ACT) (MM)D
A-l
-------
Intermediate - The next level, the Intermediate COCOMO model, is more accurate and
detailed than the Basic model. It is more suited to cost estimations in the more detailed
stages of software product definition. Intermediate COCOMO incorporates an additional
15 variables into the model which are grouped in the following categories: software product
attributes (e.g., database size), computer attributes (e.g., amount of main storage),
personnel attributes (e.g., programmer experience), and project attributes (e.g., use of
software tools).
Each of the cost drivers determines a multiplying factor which estimates the effect of the
attribute on the software development effort. The multipliers are used to obtain an estimate
of the software development and maintenance efforts. The nominal effort equations used
for Intermediate COCOMO use the same exponents as the Basic COCOMO model but with
different coefficients. The nominal effort estimates for the three modes are as follows:
Development Mode Nominal Effort Equation
Organic (MM)NOM = 3.2(KDSD!jM
Semidetached (MM)NOM » 3.0(KDSI)U2
Embedded (MM)NOM = 2.8(KDSDUO
The Intermediate model uses the same formula as the Basic model for the computation of
the annual maintenance effort
Detailed - The most detailed level of the COCOMO model uses the various cost drivers
to estimate the software product's costs by phase, subsystem, and module. The detailed
model provides phase-sensitive effort multipliers for each cost driver that are used to
determine the amount of effort required to complete each phase. Also, a three-level product
hierarchy is used. These levels are the module level, the subsystem level and the system
level.1
The module level is the number of delivered source instructions (DSI) in the module
and the cost drivers which tend to vary at the lowest level such as the module's complexity
and the module programmers' capabilities and experience. The subsystem level is the
remainder of the cost drivers which includes the time and storage constraints, the analyst's
capabilities, and the schedule. The system level is used for applying the major overall
project relations such as the nominal effort schedule and schedule equations.
For the estimation of overall development schedules and the estimation of effort
distribution by activity, the detailed model uses the same techniques that are used in
Intermediate and Basic COCOMO models. Also, the annual maintenance effort for the
Detailed COCOMO model is calculated in the same way as the other models.
1 Barry Bochm, Software Engineering Economics (New Jersey: Prentice-Hall,
Inc., 1981), pp. 354-355.
A-2
-------
C. DEVELOPMENT MODES
COCOMO addresses three modes of software development for each of the three
hierarchical levels. These modes are organic, semidetached, and embedded.1
Organic Mode In an organic mode software is developed by a small team in a very
familiar, in-house environment. The people working on die project will have a lot of
experience working with related systems in the organization and understands the
organization and it's objectives.
The organic mode is for a project conducted in a stable environment where there is little
concurrent development There is not a requirement for innovative algorithms and there is
little pressure to complete a project early. The projects are usually no more than 50 KDSI.
Embedded Mode - The embedded mode is for a project operating within very right
constraints in regard to hardware, software, regulations, and operational procedures. An
embedded mode project is for innovative and unknown areas of software development
Semidetached - The semidetached mode represents an intermediate stage between the
organic and embedded modes. This can be considered as either an intermediate level of the
project characteristics or as a mixture of the organic and embedded mode characteristics. A
semidetached mode project can be for a product up to 300 KDSI.
D. ASSUMPTIONS
Some definitions and assumptions in using COCOMO are:
Delivered Source Instructions are the program instructions that are created
excluding comments, test drivers, and unmodified utility software. These
instructions are any job control language, format statements, and data
declarations.
COCOMO's development period encompasses the product design through the
end of the integration and test phase.
COCOMO cost estimates cover the activities indicated on the software work
breakdown structure.2
Estimates are for all direct labor for the personnel involved in the activities listed
in Exhibit I. This includes project managers and project librarians but not
secretaries, personnel department employees, janitors, etc.
A COCOMO man-month is 152 hours of work.
COCOMO assumes good management by the developer and the client
1 Ibid., pp. 78-82.
2 Ibid., p. 52.
A-3
-------
COCOMO assumes only minor refinements or modifications to the
requirements specifications. Any major capability changes will require a
revised cost estimate.
The Basic and Intermediate COCOMO models assume that the cost drivers are
not phase dependent though, they do distinguish between development and
maintenance. The detailed COCOMO model assumes that the cost drivers are
phase dependent
Phase costs include all costs incurred during that phase.
E. PROCEDURES
The above summary highlights the major formulas of the COCOMO model. To use
this model to estimate software development costs the following steps should be
performed:
Step 1 - Estimate the number of thousands of delivered source instructions. This
estimate will be based on a review of similar programs and/or experienced
programmers' estimates. The determination of the KDSI will be of use in
Steps 2 and 3.
Step 2 - Determine which hierarchical level of the COCOMO model to use - basic,
intermediate, or detailed. The choice of model should be based on the
level of accuracy needed and the stage in the software production.
Step 3 - Whichever model is chosen, it will then be necessary to select the mode
which best reflects the development environment organic, semi-
detached, or embedded.
Step 4 - Once the model and mode are chosen, the formulas provided through
COCOMO can be used. In all cases, using the number of thousands of
delivered source instructions, you can determine the number of man-
months (MM) for the development effort.
StepS - The time of development (TDEV) can be determined using the man-
months from Step 4.
Step 6 - Depending on which model and mode has been selected, the formulas
associated with each will be used to estimate the costs for the software
product
Step? - For each model and mode the final calculation will be that of software
maintenance. This formula is the same for all models.
StepS - Once all the data have been calculated, the costs and other data should be
summed as applicable.
F. SAMPLE EXERCISE
A company is planning on using a group of in-house programmers and analysts for
the development of a computer program to keep track of chemicals. The project team has
A-4
-------
worked on similar programs for several years. Based on the environment, the organic
mode's model will be used for the estimate. The team has determined that the program will
be approximately 32,000 delivered source instructions. The following can be estimated
using the equations:
Effort:
Productivity:
Schedule (TDEV)
Average Staffing:
Costs:
2.4 (32)L05 = 91 man-months (MM)
32.000 DSI = 352 DSI/MM
91 MM
2.5 (91)0-38 = 14 months
91 MM = 6.5 FTE software personnel (FSP)
14 months
14 months * (~$50/hr * 152 hr/mo) * 6.5 FSP = $691,600
For the estimate of annual software maintenance for this project for the first year, it
is estimated that approximately 4000 DSI will be added and 2400 DSI will be modified.
The annual change traffic is computed as follows:
ACT:
Annual
maintenance effort:
FSP to maintain
program:
Annual cost of
maintenance:
4000 + 2400
32,000
.20 or 20%
1.0 (0.2)(91 MM) = 18 MM
= 1.5 FSP
12 months
1.5 FSP * (~$50/hr * 152 hr/mo) = $136,800/yr
A-5
-------
SCADS Phase II Work Plan
Appendix B: Overview of the GSA Conversion
Cost Model...
Preliminary
Requirements
Analysis
Requirements Checklist
Preliminary
Design and
Options Analysis
Viable Options
Benefit/Cost
Analysis
Selected Option
-------
GSA CONVERSION COST MODEL (Version 4)
Summary
A. OVERVIEW
The GSA Conversion Cost Model is a model used for estimating the cost of
software conversion. This model was developed by Carol Houtz in response to the many
problems associated with conversion estimating. The General Accounting Office
discovered that millions of dollars were misspent because of inaccurate cost estimating by
Federal agencies for software conversions.
The Conversion Cost Model (CCM) is broken into IS tasks. This breakdown of
tasks allows the estimator to use only those equations that are applicable to the conversion
at hand. If a task has already been performed or is not necessary, the costs associated with
the task will not be estimated. Subjective variables such as complexity and level of
documentation were kept at a minimum to keep the cost model objective.
Three main areas of conversion costs are:
* staff resources - manpower required to accomplish the conversion tasks;
* machine resources ~ computer time to accomplish the conversion tasks; and
miscellaneous resources ~ supplies, materials, travel, etc.
The CCM gives nominal attention to the machine and miscellaneous resources.
CCM algorithms and equations are provided in a software package that can be
purchased for most of the 15 baseline tasks. Guidelines are provided for the factors that
should be included and for determining the costs of tasks that are conversion-effort
dependent1
B. TASKS
The conversion process is broken down into 15 baseline tasks. A brief description
of the tasks and the applicable equations follow:
(1) Conversion Planning and Analysis: includes the review and revision of existing
conversion policies, procedures, and standards; definition, development, and
implementation of new policies, procedures, and standards; and preparation of a
description of work to be done, as well as the selection of conversion priorities.
U.S. General Services Administration Federal Software Management Support Center,
Conversion Cost Model (Version 4), Report NTIS PB86 225463 (1986), pp. 12-23
B-l
-------
noncompatible target - staff days = (5 * # systems (S)) + # programs (P) -t- # job streams (J)
compatible target - staff days = S + P/2 + J/2
(2) Inventory and Conversion Study Preparation: involves data collections,
preparation, summarization, analysis, and validation of the inventory. No
algorithm or equation is provided for this task, as it is dependent on the site.
(3) Work Package Identification and Preparation: involves the definition of what a
work package is and what its elements are; identification of all programs, files,
documentation, test data, etc. which should be included in each work package; the
effort to assemble all work packages and their elements; and the establishment of an
inventory control system for the work packages. The equation for estimating this
is:
Staff days = (S * 3) + ((P + no. of files (F) +JV10)
(4) Test Data Generation and Validation: includes all creation, preparation, and
generation of test data sets to validate the converted programs, files, and systems.
The equation for estimating this task is variable:
Staff days »((2 * P) + F) * (.2 + (TDK - IDE)) * I - (DOC/3))
TDR m die percentage of code the test data is required to exercise
TDE » the percentage of code the test data currently exercises
DOC « documentation (this can vary from 0-100%)
(5) Application Program and System Software Conversion: involves software
translation, generation, or transference; software compilation and debugging;
program level redocumentation; and individual testing with test data. Conversion
complexity, documentation status, and productivity rates are all major factors that
affect the conversion of application programs and systems software. Also, the
different conversion classes such as reprogramming, re-engineering, high-order
language to high-order language and straight conversion need to be considered.
The main equation is as follows:
Conversion Productivity Rate - Dvlp Productivity Rale/
(((1.0 - (DOC/2)) Design Effort) + Prog Effort + Test Effort)
The design, programming and testing effort will depend on the conversion class.2
(6) Data Hie and Data Base Conversion: includes detailed files and data base analysis,
conversion or transfer, file level recommendation, and unit testing of the file and
data base conversion. The complexity, data description or data dictionary
languages and the documentation status also affect this conversion.3
(7) Operation Control Language (OCL) Conversion: includes the analysis, translation,
generation, or rewrite of OCL; operating level redocumentation, and unit testing.
The methodology for estimating the OCL conversion is the same as that for the
application program and system software conversion.
2 Ibid., pp. 12-23.
3 Ibid., pp.23-27.
B-2
-------
(8) Redocumcntation: includes modifying any technical, user or operational
documentation at the application, operating system, or project level. This task can
be estimated as follows:
Technical staff days = (P/4 + S) * redoc coordination effort (RCOR) * DOC
Clerical staff days * (P/2 + (S « 2)) * RCOR * DOC
(9) System Testing: is the full application system testing conducted with system test
data and involves all system components.
Staff days = (J/4 + P/2 + S/2 + ((P+ F + J)/80)} * (1 -t- RE/10))
(10) Acceptance Testing: involves testing converted programs and job streams, all
operating instructions and procedures, revised documentation, and converted live
data files and data bases.
Staff days = (duration (DUR) * (S/8)) + «J + ((P +Fy5)) * (l-e*»-(DUR/20))
(11) Site Preparation: includes all the tasks associated with the initial set up of the
computer room or the modifications to the site. There are no algorithms available
for this task because of its dependence upon the site and the conversion effort
(12) System Transition: is the actual process of switching from the old system to the
new system. There are three ways of doing this: complete parallel or dual
operations, immediate transition, or phased parallel or dual operations.
(13) Conversion Training: is retraining the personnel for the target system and its
environment The training can be either courses for the conversion-related activities
or training involving courses to develop skills in the new environment
(14) Conversion Management and Administrative Overhead and/or Contract
Administration and Support: includes the management of the conversion effort and
the supervision of the technical, clerical, and other managerial personnel.
(IS) Conversion Aids: are software tools or conversion aids are available in the areas of
management, translation, testing, implementation, performance, and documenta-
tion. The costs for each of these aids is determined separately. These costs can be
obtained from market analysis.
C. ASSUMPTIONS
Some definitions and assumptions in using CCM (Version 4) are:
Conversion means the transformation without functional change of computer
programs and/or data elements. The software conversion can be done by
translation, receding, reprogramming, or rewriting software.4
A "compatible" conversion is one where the target software is very similar in
regard to source code, object code, and operating system compatibility.
4 Ibid., p. 4.
B-3
-------
Guidelines are provided as part of the model to adjust the equations for varying
levels of compatibility.
A "noncompatible" conversion is a move to a different vendor's equipment and
operating system. Also, the source language of the source and target would be
different. Because of the amount of changes necessary, thorough testing will
be required.
* At least 70% of the code, or program logic paths, including those logic paths
that are most frequently used, should be executed during conversion in order to
ensure that the software was converted correctly.
The CCM assumes 240 staff days per year.
The CCM does not differentiate between work performed in-house or by a
contractor, nor does it differentiate between the skill levels of individuals
required to perform certain tasks.
The default fully loaded annual salary used in this model is $72,000.
There are additional assumptions associated with the individual baseline tasks that should
be considered when using the model.
D. PROCEDURES
Above are the major tasks in a conversion effort as defined by the GSA CCM
(Version 4). When using this model the following steps should be performed:
Step 1 - Determine which tasks are applicable for the current project
Step 2 - Determine what inputs are necessary for the equations associated with the
tasks. The inputs may include the lines of code of application programs,
lines of code of the operation control language (OCL), the level of existing
documentation, the number and type of data files (ASCII, binary, or some
special format), the number of programs, the number of OCL files, and a
productivity rate for software development The algorithms and formulas
provided for the tasks selected can then be used to determine a cost
conversion estimate.
Step 3 - Sum all costs and levels of resources for comparison to other cost
conversion estimates.
E. SAMPLE EXERCISE
A company is planning on a software conversion of a computer program that keeps
track of chemicals. The current environment is a IBM 4381 and the target environment is
an IBM 3090. The conversion class for this program is a straight conversion which has an
80% level of documentation, a 20% design effort, 10% programming effort, and a 20%
testing effort For this conversion effort, only baseline tasks #5-#7 are required. The
computer program is 10,000 lines and the OCL is 50 lines of code. The programmer's
development productivity rate is 12.6 lines of code (LOC)/day.
B-4
-------
Conversion J2.6 LQC/dav = 30 LOC/day
Productivity [((1.0- 0.80/2) * 0.20) + 0.10 + 0.20]
Rate:
ApplProg 10.000 LOG * S72.QOO/vr = $100,000
Conversion Cost: 30 LOC/day 240 staff days/yr
OCL 5QLQC * $72.000/vr = $500
Conversion Cost: 30 LOC/day 240 staff days/yr
Data Conversion: ((10 binary files *3) + (2 ASCH files *!)) = 32 equivalent
files
Data Conversion Cost: [32 files * (1.0-(0.80/2)] * S72.QOO/vr = $5,760
240 staff days/yr
B-5
-------
-------
------- |