IMBS

Publications

Computer Science

and Technology

NBS Special Publication 500-90

Guide to Contracting

for Software Conversion

Services
NATIONAL BUREAU OF STANDARDS

The National Bureau of Standards' was established by an act ot Congress on March 3, 1901. The Bureau's overall goal is to strengthen and advance the Nation's science and technology

and facilitate their effective application for public benefit. To this end, the Bureau conducts

research and provides: (1) a basis for the Nation's physical measurement system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to promote public safety. The Bureau's technical work is per- formed by the National Measurement Laboratory, the National Engineering Laboratory, and

the Institute for Computer Sciences and Technology.

THE NATIONAL MEASUREMENT LABORATORY provides the national system of

physical and chemical and materials measurement; coordinates the system with measurement

systems of other nations and furnishes essential services leading to accurate and uniform

physical and chemical measurement throughout the Nation's scientific community, industry,

and commerce; conducts materials research leading to improved methods of measurement,

standards, and data on the properties of materials needed by industry, commerce, educational

institutions, and Government; provides advisory and research services to other Government

agencies; develops, produces, and distributes Standard Reference Materials; and provides

calibration services. The Laboratory consists of the following centers:

Absolute Physical Quantities- — Radiation Research — Chemical Physics —

Analytical Chemistry — Materials Science

THE NATIONAL ENGINEERING LABORATORY provides technology and technical ser- vices to the public and private sectors to address national needs and to solve national problems; conducts research in engineering and applied science in support of these efforts; builds and maintains competence in the necessary disciplines required to carry out this research and technical service; develops engineering data and measurement capabilities;

provides engineering measurement traceability services; develops test methods and proposes

engineering standards and code changes; develops and proposes new engineering practices;

and develops and improves mechanisms to transfer results of its research to the ultimate user. The Laboratory consists of the following centers:

Applied Mathematics — Electronics and Electrical Engineering- — Manufacturing

Engineering — Building Technology — Fire Research — Chemical EngineeringTHE INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY conducts

research and provides scientific and technical services to aid Federal agencies in the selection, acquisition, application, and use of computer technology to improve effectiveness and

economy in Government operations in accordance with Public Law 89-306 (40 U.S.C. 759), relevant Executive Orders, and other directives; carries out this mission by managing the Federal Information Processing Standards Program, developing Federal ADP standards

guidelines, and managing Federal participation in ADP voluntary standardization activities; provides scientific and technological advisory services and assistance to Federal agencies; and

provides the technical foundation for computer-related policies of the Federal Government.

The Institute consists of the following centers:

Programming Science and Technology — Computer Systems Engineering.

'Headquarters and Laboratories at Gaithersburg, MD, unless otherwise noted; mailing address Washington, DC 20234. 'Some divisions within the center are located at Boulder, CO 80303.
Computer Science

and Technology

HATIONAL BUBHAO

or standaedb

LIBRARY JUL 1 9 1982

H

Oc/Go

NBS Special Publication 500-90 ^^^i

Guide to Contracting i^^^

for Software Conversion

Services

Mark W. Skall

Center for Programming Science and Technology

Institute for Computer Sciences and Technology

National Bureau of Standards

Washington, DC 20234

U.S. DEPARTMENT OF COMMERCE

Malcolm Baldrige, Secretary

National Bureau of Standards

Ernest Ambler, Director

Issued May 1982
Reports on Computer Science and Technology

The National Bureau of Standards has a special responsibility within the Federal

Government for computer science and technology activities. The programs of the

NBS Institute for Computer Sciences and Technology are designed to provide ADP

standards, guidelines, and technical advisory services to improve the effectiveness

of computer utilization in the Federal sector, and to perform appropriate research

and development efforts as foundation for such activities and programs. This

publication series will report these NBS efforts to the Federal computer community as

well as to interested specialists in the academic and private sectors. Those wishing

to receive notices of publications in this series should complete and return the form

at the end of this publication.

National Bureau of Standards Special Publication 500-90

Nat. Bur. Stand. (U.S.), Spec, Publ. 500-90. 67 pages (May 1982)

CODEN. XNBSAV

Library of Congress Catalog Card Number: 82-600531

U.S. GOVERNMENT PRINTING OFFICE WASHINGTON: 1982

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402

Price $4.50

(Add 25 percent for other than U.S. mailing)
TABLE OF CONTENTS

Page

1. INTRODUCTION 1

2. CONVERSION PHILOSOPHY 6

3. AGENCY RESPONSIBILITIES PRIOR TO RFP CREATION 12

M. DESCRIPTION/SPECIFICATION OF SERVICES 34

5. DELIVERABLES AND ACCEPTANCE 42

6. INSTRUCTIONS TO OFFEROR 4?

7. EVALUATION AND AWARD FACTORS 51

8. CONCLUSIONS 58

Appendix A: Bibliography and References 61

-iii-

GUIDE TO CONTRACTING FOR SOFTWARE CONVERSION SERVICES

MARK W. SKALL

This guide is the first in a series of publications which will be issued by the National

Bureau of Standards with respect to conversion of

Federal agency ADP Systems. The need for these

publications was determined by a study conducted

in 1980, consisting of interviews with commercial

conversion experts and Federal Government agency

personnel who have recently experienced conversions, as well as a search of the current literature. The results of that study are documented in

NBS Special Publication 500-62, entitled

CONVERSION OF FEDERAL ADP SYSTEMS : A TUTORIAL . The purpose of this guide is to educate the

Federal manager in the benefits which can be

gained by contracting for conversion services as well as to specify all the actions the agency must

take to ensure a successful conversion contract.

The guide concludes that a smooth conversion can be accomplished by thoroughly planning the

contractor's activities and effectively communicating these plans to the contractor.

Key words: Acceptance tests; conversion contracting; conversion problems; deliverables; evaluation

criteria; Federal agencies; language translators;

portability; program inventory; RFP; statement of

work.

1 . INTRODUCTION

The conversion of computer system software is one of

the most costly, difficult, and time-consuming tasks associated with the use and maintenance of computer software

within the Federal Government. The GAO, in a report entitled MILLIONS IN SAVINGS POSSIBLE IN CONVERTING PROGRAMS

FROM ONE COMPUTER IQ ANOTHER , [29] estimates that over $450

million is spent annually on Federal computer software

conversion. The person given the responsibility of managing

the conversion effort often has no prior experience in
managing conversions, and the programming staff assigned to

the conversion project usually has only a minimal background

in conversion. It is unlikely that many of the programming

staff participated in a previous conversion at the same agency since the average time between computer replacement

in Federal agencies was found to be seven years, which is

about double the average tenure of a computer/programmer

analyst at a given installation. Additionally, many people

on the conversion staff may also lack an intimate knowledge

of the software requiring the conversion due to staff turn- over since the software was developed. Thus, the general

atmosphere surrounding the initiation of a large scale

conversion can be filled with anxiety and uncertainty.

Much of the anxiety and uncertainty can be alleviated

if the conversion is contracted out to an experienced

conversion vendor. Contracting for conversion services may

be the only alternative since hiring freezes and personnel

ceilings prohibit many agencies from acquiring additional

personnel beyond those needed for the regularly scheduled

tasks. Thus, with the original implementors long since

gone, and documentation frequently inadequate and often

out-of-date, a conversion contractor provides the conversion

manager with a more optimistic outlook for the future.

A study conducted by the National Bureau of Standards

[3] concluded that Federal agency personnel who are involved

in writing Requests for Proposals (RFP's) for conversion

services are very often confused concerning the type of information that should be included within the RFP, the types

of deliverables which need to be specified, and the ways in

which to ensure that the conversion has been completed

correctly. The report further states that many agencies

which have contracted for conversion services in the past

have received systems whose performance is inadequate and

may not meet the user's needs. This situation often results

from the agency's reluctance to include performance requirements as part of the acceptance criteria in the conversion

RFP. This guide addresses the problem areas cited above and

thus gives Federal agency computer managers guidance con- cerning a large, costly and extremely time-consuming project

in which they may have only limited experience.

This guide contains eight chapters. Chapter 1 provides

background material on conversion, defines terms, and

describes the need for this guide. Chapter 2 describes the

different factors which an agency should be knowledgeable in

prior to undergoing a conversion. Chapter 3 discusses the

role of the agency in conversion. Chapters 4 through 7

describe different items which should appear in an RFP for

conversion services, while chapter 8 is a summary of some of

the important points brought out throughout the guide.

-2-
Note: Bracketed numbers, i.e. [N], refer to references in

Appendix A.

Definition of Terms

For the purposes of this guide, conversion is defined

to be the process of taking application software in source language from one piece of equipment and modifying it to ex- ecute correctly on another piece of equipment, while maintaining the functional requirements of the original

software. From the user's viewpoint, the software performs

the same functions in the old and new environments. The ex- isting software is referred to as the source program or source system and the converted software is referred to as the target program or target system.

Once the decision to convert has been made, there are a number of conversion techniques which can be utilized. This

guide will consider the three following techniques, which

are the most widely used: receding, reprogramming , and

redesign. These terms are defined as follows:

* Receding - Each line of code is translated to an equivalent line(s) of code on the new computer system. This translation can be accomplished manually

through visual inspection of the code, automatically

through specialized software, or by a combination of

the two techniques. From the user's and designer's

points of view, the system remains unchanged (with

the exception of processing time, which may either

have increased or decreased.) One line of code may

get translated to many lines of code or many lines

of code may get translated to one line of code. The

type of transformation that occurs depends upon the source and target languages. Examples are COBOL to

COBOL, assembly language to COBOL, and FORTRAN to

FORTRAN. If the source and target languages are

similar, much of the translation will be one-to-one.

* Reprogramming - Some or all new code is produced.

All the code is not translated on a line-for-line

basis, but the same functions frcm a designer's and

user's viewpoints remain, along with the same algorithms. Different logic is used to program the same functions, resulting in greater efficiency.

* Redesign - A new system specification is required.

The entire design of the system may change, resulting in different algorithms to accomplish the same functions. Different program structure and different logic may be used. New techniques, such as

-3-
database management, may be incorporated, and the

structure of program files may change drastically.

The new system specification is related to the previous system because the same functions, from the

viewpoint of the user, are produced. Changes in the

system are transparent to the user.

Why Contract Out for Conversion

Lack of in-house expertise, personnel ceilings, and ex- tremely tight schedules have forced Federal agencies to ac- quire outside conversion assistance to meet management's

demands. There are, however, reasons an agency may want to

contract out for conversion services because of the qualifications of conversion contractors. Conversion experience is

a skill which must be acquired by participating in a great

number of conversions in various programming languages and on a variety of different source and target computers. Ccanpanies specializing in conversion employ people with just

this mix of experience. Experience of a typical conversion

company may very well include Federal agencies and companies

of all sizes, ranging from contracts involving one or two

programs to contracts involving hundreds, or even thousands

of programs. Many large conversion companies have performed

conversions in COBOL, FORTRAN, ALGOL, Pl/1, AUTOCODER and

other programming languages and have utilized the following

hardware: Burroughs, CDC, Honeywell, IBM, NCR, and Univac,

just to name a few. Seme conversion companies have expertise with data base management and communication systems.

Additionally, conversion companies have access to a great

number of software tools, designed to speed up and assure

greater quality assurance in the conversion process. Scane

tools that conversion companies utilize are language translators, file comparators, source code reformatters,

analyzers which count the percentage of statements executed

by test data, and auditing tools which check adherence to

agency standards.

Historically, programmers have viewed conversions as an extremely undesirable activity. They are "stuck" with a program that they neither designed nor coded, and now they

must get it to execute correctly on a machine with which

they may not be familiar. Furthermore, conversion is viewed

as being much more mechanical and not nearly as intellectually stimulating as new coding or design. The above problems are compounded by the fact that the natural instinct of

most individuals is to resist change, and cling to that with

which they are most familiar. Thus, retaining good morale

among programmers assigned to conversion projects is,

perhaps, an impossible task. The U.S. Navy found that working on conversion contributed to the high attrition rate of

civilian employees more than any other activity in the

-4-
Navy's data centers. This factor alone may justify an agency's decision to contract out for conversion services.

The PROVISIONAL CHECKLIST FOR SOFTWARE CONVERSION

PROJECTS [32], prepared by the U.S. GENERAL ACCOUNTING OFFICE states that "Contracting (for conversion services) is

attractive when: a) skilled specialists will convert for a fixed price, b) conversion by a contractor will leave inhouse staff free for regular tasks, c) experienced conversion specialists with automated aids can complete the

conversion more quickly than in-house staff, and d) little

need is foreseen to redesign the programs after they are converted."

-5-
2. CONVERSION PHILOSOPHY

A Federal agency's philosophy concerning the way to approach and implement the conversion process will have a profound effect on the form and content of the eventual RFP to

acquire conversion services. It is important that Federal

agencies understand the ramifications of their decisions

concerning several important issues which materialize during

almost all conversion projects. Furthermore, the failure of

Federal agencies to make decisions concerning the topics

which will be addressed later in this chapter may very well

lead to potential conversion contractors making these decisions for the agency, and incorporating them into their proposal. Since top management in any agency should not

delegate that which is their ultimate responsibility, it is

imperative that decisions should be made addressing the areas to be discussed below.

Improvements During Conversion ?

Many existing systems of programs in Federal agencies

were designed for, and are operating on, computer systems

that are fifteen years old and older. Many of these programs use techniques common to second generation computers,

such as tape oriented files rather than disc, code which is

not modular and contains few, if any, ccxnments, and reliance

on operator intervention. Typically, these programs are poorly documented, if they are documented at all. Certainly, an agency faced with converting programs in this state

may want to make improvements to them which will, at least,

make the programs more readable and maintainable.

Some of the improvements which can be made to programs

during conversion are:

The use of more recent programming methods such as structured programming or modular programming.

The addition of more descriptive comments. Very often, much time is invested, during conversions, in

scrutinizing certain sections of the code to determine the logic. This is valuable information once

it is captured and should not reside solely in the

mind of the person who analyzed the code. Adding

comments to the program will prove very helpful the

next time someone looks at this section of the code.

-6-
* The replacement of sequential tape files with disk.

* The use of language statements contained within a FIPS standard language with no vendor extensions.

* The use of internal standards for naming conventions.

* The creation of a test plan.

* The creation of test data.

* The creation of better documentation.

* The removal of operator intervention and device

dependency

.

A conversion effort presents an opportunity to improve

the computer syst«n. Writing the RFP to include improvements to the converted programs, such as the ones listed

above, should be encouraged by Federal agencies, since they

will make the programs easier to maintain and modify after

conversion and will make the next conversion, if it is

necessary, a much easier task. However, functional changes

that will affect the agency's ability to map the output of

the converted programs back to the output of the source programs should be avoided. If functional changes are incorporated, it becomes extremely difficult to verify whether or not a system of programs has been correctly converted.

If it is deemed absolutely necessary to make functional

changes to a system of presently running programs which are being converted under contract, then these changes should be

made by the Federal agency's programming staff and should be

thoroughly documented so that these changes can be incorporated into the converted programs after canpletion of the

conversion effort.

Acceptance Testing

When a conversion is being done under contract, how

does the agency know that the contractor has successfully

completed the effort? Some absolute criteria must be used

to make this determination. These criteria are referred to

as acceptance criteria. More detail concerning acceptance

criteria will be discussed later in the report when details

of the RFP are presented. A brief summary of the major as- pects of acceptance criteria is presented below:

-7-
* The converted programs must meet design and specification criteria.

* The converted programs must meet processing time

criteria.

* The converted programs must meet accuracy criteria.

* The output of the converted programs operating with

converted files must equal the output of the source programs and files.

* The output of the converted systems operating with

converted files shall equal the output of the source systems and files.

* Documentation must be supplied indicating all programming changes which were made to the structure or

the logic of the programs in the process of converting from the source to the target machine.

* Execution monitoring must demonstrate that a predetermined percentage of the code is actually ex- ecuted during testing.

Type of Contract

Much of the current literature about conversion advocates fixed priced contracts for conversion products. The

argument is that conversion is the only software project

which has a concise specification for the products desired.

This specification is the source programs themselves, which

define the functions which need to be converted to the target environment. If the acceptance tests in the contract

are precise and canprehensive, coupled with liquidated damages for failure to satisfy them, a fixed price contract

does indeed look very desirable.

The problem with fixed price contracts is that the job

must be well enough defined for prospective contractors to

be able to make accurate cost estimates for the conversion.

Many conversion companies maintain comprehensive data bases

for conversion cost estimation. However, these data bases

are usually based on using receding to accomplish the

conversion. Receding only guarantees functionally

equivalent source code, not a program which runs efficiently. If performance and efficiency constraints are included

as part of the acceptance criteria (as they should be), then

the scope of the effort is not known with as much certainty

since a great deal of tuning of the code may be necessary in

order to meet certain performance and efficiency constraints, such as execution speed and memory requirements.

-8-
Contractors may be compelled to switch to reprogramming or redesign to accomplish much of the conversion. Cost estimates for these methods are much more difficult to make,

since these methods can not be automated to the same degree

as receding.

One useful set of criteria that can be used in deciding

among conversion techniques was specified in an NBS Special

Publication entitled CONVERSION OF FEDERAL ADP SYSTEMS ; A

TUTORIAL [3], and is listed below:

* Recoding - Source and target languages should be

similar. The source and target computers should

have comparable hardware/ software capabilities. If

recoding is used when hardware/ software capabilities

are not comparable, then the capabilities of the new computer may not be utilized, often resulting in

inefficient programs.

* Reprogramming - Source and target languages are dissimilar (e.g., converting from assembler to COBOL).

Line-for-line translation (or recoding), when the

source and target languages are dissimilar, may well

result in converted code which is much larger than

the source code. For example, in a conversion of

assembly language to COBOL, assume that the first

assembly language statement loads register 1 with

variable A; the second statement loads register 2

with variable B; the third statanent adds the con- tents of register 1 to register 2; and the fourth

statement puts the new contents of register 2 in

variable C. Some translators, performing line-forline conversion, may generate four COBOL statements

corresponding to these assembly language statements.

In turn, when these COBOL statements are compiled

and assembled, they will produce 16 assembly

language statements, producing a four-fold code ex- pansion. A good programmer, using reprogramming

rather than recoding, would produce COBOL code saying "ADD A TO B GIVING C", which would execute much

more efficiently.

* Redesign - The source program is many generations

old. The design is out-of-date, and the program is

poorly structured and documented. The agency

desires a more modular, maintainable, and readable

program.

-9-
A manager can implicitly specify the appropriate

conversion technique by embedding performance requirements

into the conversion RFP. In this way, the contractor is legally obliged to address constraints specified in the RFP

(such as response time, memory requirements, size of tiie

target program, etc.). The choice of receding as a conversion technique will often fail to result in the target program satisfactorily meeting these performance constraints.

In fact, translators, which use the receding philosophy,

have been known to produce an object expansion rate of 10 to

15 times. Thus, if the new computer is six times faster

than the old one, the converted programs will execute at

about one-half the speed as before conversion. When performance requironents are embedded in the RFP, the contractor

is placed in the ideal situation, from the agency's standpoint. The contractor will still attempt to utilize the

most economical and timeliest technique possible, but this

technique must also meet the performance requirements.

Thus, the product that the agency will obtain is the one

that is the least costly and most efficient, but also satisfactorily meets minimum performance requirements.

Many agencies fail to include any performance con- straints in the RFP, asking instead for functionally

equivalent source code. This can lead to degradation in

performance, as illustrated in the the assembler to COBOL

translation documented above, and may result in a converted

system which does not meet the user's needs.

In suiraiary, for a conversion which only needs to be

receded, the scope of work can be precisely defined and ac- ceptable cost estimates can be made. Generally, conversions

which have stringent performance requirements can not be ac- complished solely by receding. If stringent performance re- quirements are specified, then reprogramming or redesign

will probably be the preferred method of conversion, and the

contract may very well net be fixed price. Remember that

the decision concerning the type of contract is determined

by the specifications in the RFP. The final selection of

the type of contract, however, should be made only after

consultation with the Contracting Officer.

Maintaining Control Over the Contractor

GAO, in a report entitled CONTRACTING FOR COMPUTER

SOFTWARE DEVELOPMENT—SERIOUS PROBLEMS REQUIRE MANAGEMENT

ATTENTION TO AVOID WASTING ADDITIONAL MILLIONS [28], points

out that agencies quickly overcommit themselves and fail to

control contractors through specific clauses in the RFP.

Seme methods which can be used to control contractors are:

-10-
tight contract monitoring,

strict phasing,

requiring written progress reports,

specifying the standards to which the contractor

must adhere,

identifying critical milestones,

identifying a single focal point for communication,

conducting audits to verify if deliverables are

correct.

Agencies often commit thanselves to the entire contract

without receiving feedback as to whether or not the preliminary phases of the contract are being performed satisfactorily. Smaller pieces of the total system should be identified as critical milestones in the preliminary phases of

the contract and a determination can then be made as to

whether or not these programs have been successfully converted, before allowing the contractor to continue with the

contract. The determination as to whether or not the programs have been successfully converted should include

predetermined criteria for the unit test plan and test re- port, the percent of statements that have been executed during testing and the performance of the converted programs.

Written progress reports should be required by the contract

in order to keep the agency apprised of progress and the attainment of critical milestones, as well as potential problems.

To improve communications and to eliminate conflicting

information emanating from the contractor, agencies should

establish a single person as a focal point for communications with the contractor.

*

«

-11-
3. AGENCY RESPONSIBILITIES PRIOR TO RFP CREATION

Before a contractor can begin a contract to convert a computer system, much work must be done by the agency's

staff to produce inputs for the contactor. In fact, agency

people who are knowledgeable about the system which is being

converted must be intricately involved throughout the

conversion effort if the conversion is to be successful.

The most obvious and also the most important task to be

done by the agency's staff is the identification of exactly

what is to be converted. This task provides agency personnel the opportunity to scrutinize the existing system of

programs and to make assessments as to which of these programs are still functional and thus, should be converted.

Identifying what is to be converted is accomplished by

taking a complete inventory of all programs, files, data

bases and documentation which pertain to the source systan.

Many conversion authorities advocate using some form of

conversion inventory worksheet to identify all the program,

file and data base components. Some worksheets recommended

by GSA's Federal Conversion Support Center (FCSC) [8] and

used by the Department of the Anny [15] are shown in figures

1 through 6. Figures 1 and 2 are the FCSC worksheets and

figures 3 through 6 are from the Department of the Army.

Conversion type in figures 4 and 5 refers to the degree of

difficulty involved in converting the file. Type A is the

easiest type of file to convert, type B the second easiest,

and type C the most difficult type of file to convert. The

information required in these worksheets is the absolute

minimum needed by the contractor to successfully complete

the conversion. We recommend that an agency, which is about

to undergo a conversion, examine these sample worksheets and

determine whether or not they are sufficient for its needs.

If these worksheets are not sufficient, the agency should

devise some to meet its needs. Following is a list of items

to choose from when developing a conversion inventory

worksheet. This list is very comprehensive and may include

items not relevant to a particular system of programs.

Thus, in devising a worksheet, an agency should include only

the itans on the list vrtiich are pertinent.

-12-
I I

I I

VI O

Sf5

v> oc BH

CL4

-13-
I

I I

H

o

H

Ols <-•

^ OS o H* U c S <

H

O

W

u

fa

CM

EdO

M

fa

-i

•14-
3O

(U

0)

CD

(0

COB

<uO c >-« o pu

tn .H

Q) td •U -H O 4J z c

(Uo

p-l oo

IS

60c

•H

B

4-1 0) Cd 4J

^-1 cn o

cniI

cubC

CO3

acc

CO hJbOC

•H

COU

(JO oM

U

U 4-) (U 3

•<-) cx o ou

cn

OJ60

CO3

(30 CO c a

CO cO

T-{

U \ 00

CO o

(Uw

iH & 3 43

13 3 O cn B

r-l CO CO (U e.s

(U 4-1 4J 3 X o

0) C/3

MHC

puMQ

CO

CO

•H

4-1 COO

CO

(U (U C

•H

O

i-H CJ

M-l 0) o o

)-l • 3 O O B

COu

a 60 M oU

PU -15-
o

•H

CO (U

Q)> H

C

ou

o>

o

C CO

<U O

N O

•H 0) CO Pi

0)O

(0 CO

N

•Hc

CO00 o

to

o

o

o

o

o

o

0)

a

0)3

cr CO

M o

Ph o o

PQo

o

t3U

O

iH CJ

Q) O

CO U

(U

4-1 X

I -H

<3^ M-l

O

OOCM

CJ

COc

t3

4-1 c

3

cr

CO

M O

pH O

PQ CM CM O

\0

U

O

r-t O

OJ o

CO

4-1 ><!

I -H

C3^ U-l

O

OO

O

CM

o

CO

0)

OJ

CO •H

4Jc

(U3

cr

<u CO

o

oin

M o

P-i o o

CQ CM CM O

o

CJCO -d ^ (1) 4J X

I v-i as yu

PQ

•T3cu

i-ia)

CO

t3

CO •H

4-1 c

cu3

cr

(U CO

o o

PQ 00 cn O

VI QJ vO O ^

O CJ

Q) O

CO -a M cu VI

CJ

•3^

CK <4-l O

CU!X

CO H

bO

CO

0)(X

CO H

bO

CO s

(Ua.

CO H

6C

CO s

cuPu

CO H

00

CO s

(U •H

Vl

(U

4-t COCO

(U J-1 C Q)

0) 4J

Q) to

!-i to

CJ 2: CO

(U u

4-1 (U

CO -u nj CO CL CO

o

•H

4-1 u

COCOc

CO

5-i H

-15-
> cuCX o >~. << CJ CJ H

CO Cfi H !-i CD <^ rH CU

Cfi rH -1-1 CD e e •H U

(J o o S CO CJ no .

II V-i <; D" c XJ' CJ CO

cu cd <U cc) cu —

pi CO Pi CO •K CJ

(1)

— ... ,

.H

•H Q) o CJ o CJ

pi^

N :s S •H s CM 00

X CO 00

cd 1—1

rH rH T—1 . - . -

CNI I—1 o 1— o o o o o

<; Cfi c o o o o d) o o o 1 p.

ta o H

r-- CM CJN 00o o 0) 00 ON H pi* cu . o H O o o o o rH CJ^ a 00 cn

t-f 5 (U •H Pi rH rH

•H

IS o

T3

}-> Oo

0) Ph

es 1 1 [ a, 00 o H

00 •<j- oCM o

CObO cr'

>-l CU o cn

om

cu rH cr cr H C cu cu CO M CO CO Pi

cn

cn cu ID

Per Sup urQ

(U rH rH 1 1 cu cu Cfi •H O > o rH rH

5-1 •H •H p. CO U P. 4-1 CJ MH O < O CO H

Cfi

!-i Q) UO

CO

>-( CO CJCo

•H

-K

-17-
System: Weapons Component Procurement System

No. Documentation Component Complete Incomplete

Not

Applicable

.—. .—

1 Application Description A

i z bystem r±ow Ltiart YA

3 Program Narrative A

i

' \

/. Program Flow Chart /Decision Table YA

Algorithm Description X

6 File Layouts X

7 Reports X

8 Test Data Printouts -

9 Program Listings X

10 User Instructions X

11 Data Preparation Instructions

12 Control Clerk Instructions X

13 Run Sheets X

Comments: System maintenance performed without documentation update.

Transaction and master file formats are out of date.

FIGURE 6. DOCUMENTATION REVIEW FORM
System Information

* System identifier

* Point of contact

* Date the inventory is prepared

* Description of system

* Source computer

* Target computer

* Operating system

* Name and number of all application programs in system

* Total lines of source code of each application program in system

* Name, number and total source code lines of all programs in the system grouped according to the

language they are written in

* Name and number of all files in system

* Name and number of all common subroutines in system

* Name and number of all data bases in system

* Name and number of all stand-alone utilities in system

* Name and number of all programs by size: a) Under

1000 lines, b)1000 - 10,000 lines, or c)greater than

10,000 lines

* Run frequency of the system

* Name and number of all user coded macros

* Interfaces within the system

* Interfaces to other systems

* Description of present DBMS functions and capabilities
* Identification of general purpose interactive timesharing requirements

* Identification of security and privacy requirements

* Identification of all proprietary packages in the

system

* Description of the documentation which exists

B. Program Information - For each program identified in the

Syst«n Information section, the following should be identified:

* Program identifier,

* Point of contact,

* Date the inventory is prepared,

* Description of program, ^

* Source language and version (e.g., FORTRAN 66),

* Source computer,

* Target computer,

* Target language and version (e.g., FORTRAN 77)

* Operating system (source and target),

* Number of lines of source code - a) number of lines

of standard code, b) number of lines of non-standard

code,

* Documentation of existing and potential problems,

* Name and number of all called subprograms,

* Name and number of all input files,

* Name and number of all output files,

* Name and number of all stand-alone utilities used,

* Number of patched statements in object program.

-20-
« DBMS interfaces,

* Telecommunications interfaces,

* Are checkpoint restart capabilities present?

* Does comprehensive test data exist for this package?

* Size of test data (average number of bytes/file),

* Percentage of statements executed by this test data,

* Actual JCL used by the program,

* Description of the overlays used by the program,

* Description of the documentation which exists.

C. File Information ~ For each file identified, the following information should be supplied:

* File identifier,

* Point of contact,

* Date the inventory is prepared,

* Description of the file,

* Source program(s) that reads the file,

* Source program(s) that writes the file,

* Media (mag. tape, disc, etc.),

* Access method,

* Record format,

* Number of records,

* Average record size.

D. Documentation - The following documentation should be

identified:

* User manuals.

-21-
* Local operating manuals,

* Local programming standards and procedures manual,

* Hardware manuals,

* System software manuals,

* Computer manuals,

* Original test plan,

* Program listings,

* Program flow charts,

* Functional specifications,

:=. * Data requirements,

* Design specifications,

* Identification of any deviations frcan original functional or design specifications,

* Data description,

* Sample input and output listings,

* Sample input data, if it exists, in machine readable

form,

* Operator manuals, run books,

* Maintenance manual.

After a complete inventory of all systems, programs,

files, data bases, and documentation has been completed, it

is very useful to develop cross reference lists between the

programming languages used and the types of application

software, as well as a program distribution, by language,

and a file distribution within each department. The sample

charts in figures 7 through 10 [15] may be helpful in this

effort. In Figure 9, file types A, E and C describe the

conversion difficulty of the file. Type A is the easiest

and cheapest type of file to convert. An example of a type

A file is a character data file. Type B is more difficult

and expensive to convert than type A. Type C is the most

difficult and expensive type of file to convert. An example

of a type C file is a packed or compressed file with variable record format.

-22-
<! <)• in ro 0^ o CM o%

w CO CM <r o iH in CO 1

CM rH in iH CM 00 CO CO

CO •u CN 00 o o 00 >^ CO CO H iH CM

<f

O iH CM C3~i CU u vO CM CM CM iH 00 U Q) in 00 u m

<r CM

U CM CO

00 CM 00 00 c CO OJ 00 in rH CO

CO 4J CO CJN <}

CO CO i O W in

CM CM

P=i 00 o CO 00 W CNl rH o CO iH CM CM <r

CK CO in 00 CO M CM CO

.,

C^ <r o CM -vT 00 r~- -

iH o tH CM CM o o- 00 CM <

P3 <J- r-i CO tH rH CO

p.• o

•K •K O"^ O O o o

EC CO o 00 o

&.a

m CO

iH

tH iH

0) £ >-i in o in

O

<U CO CO o CO

O

+J IS CM CM U 4J O O W O iH iH

CJ •H

>4-( CM CM CM CM

•H 00 00 o>

4J CM CM

(U

m CO

•H CO CO o 1P!

CO hJ

0)

PQ CO >> P PQ

CO

i-J CO (U o O 4J 00

H

W <

PQ PQ CO CO Pi CO

H

OOO 3 o CO

O

a 60 (X- < H oc

CO

CO

Cfl

O

C -H O +J •H CO 4J O

CO "H O iH

•H

a. CO

CO ^ -

0)

•> 00

CO OC 3

CO 00 3 C

OC CO C rH

CO o

x; CO

CO

CO o e o

CO

(-1 0) OC a o ^ U 3 a o

cn MHO MHo

Q) CO ^ 0) 6 C 3 -H C <H

CO CO u *-i O O

4-1 4-1

CO CO u u

(U 0) ua o 8

PC

p4cs

Pi!=OM[X4

-23-
-24-
File Type

Dept

No. of Unique Files/No. Records A .B

'

( rC

SAB 18 23,000 X

SSB 1 685 X

SSB 3 2,161 X

HSS 36 76,432 X

HPS* 10 186 ,490 X

HPS 5 4,000 X

f HMP* 2 6,000 X

HMP* 4 28,000

CAU 89 113,418 X i

1 CAB* 15 146,382 X

i

TOTALS 183 586,568

*Data base files

i

FIGURE 9. SAMPLE FILE SmiMARY: CONVERSION

-25-
CONVERSION MAN--MONTH ESTIMATES

1 Language* Number Number Programs Files Totals

Dept. he- DB F A

- Programs T7-? 1 £1 e r ixes Low Low Hi Low Hi

DAB X 82 18

SSB

i

X 35 4

1

HSS

1

X 80 36

HPS X

VA

X

13

10

4

5

10

0

i

' HMP X

X

27

6

0

6 —

(

CAU

! X

X

X

64

23

12

—^—^—^—

78

11

0

CAD X

X

00

00

15

0

i

f

!

1

TOTALS 372 183

*C = COBOL DB = Data Base F = FORTRAN A == Assembly language

FIGURE 10. PROGRAM/FILE DISTRIBUTION BY DEPARTMENT

-26-
Assessing the Future

After a complete inventory has been taken, decisions

can then be made as to the future of all the programs and

files identified. This phase of the conversion presents

agency personnel with a golden opportunity to "clean up" an existing system. Perhaps, some of the programs or files

identified in the various checklists can be "thrown away"

(i.e. not converted to the target system) because the functions they perform are not needed anymore. Even if program

functions are still needed, usable programs may already ex- ist for the new system which, with little or no additional

effort, can reproduce the functions of the old program.

Moreover, the old software may be so poorly designed or inefficient that it should be discarded and new applications

written for the system. It may, in fact, be easier to write

some new programs from scratch than to convert them to the

target system. An assessment should also be made of the future expected life of each program. It may be that certain

programs will only be needed for a short time following the

conversion. In this case, a quicker, cheaper alternative to

conversion (such as emulation or simulation) should be investigated for these programs. If the decision to convert

the programs is made, the various conversion techniques

identified in chapter 1 should be investigated.

The users should be brought into the process at this

stage. They may reconmend that certain functions be deleted

or modified. If functions are deleted, existing application

programs may not have to be converted. Comments should also

be solicited from users concerning the existing output.

They may recommend that the output should be modified. Be

careful, however, when attempting to modify the output,

since it is imperative to be able to map the output of the source system to the output of the target system. It is

therefore recommended that changes made to the programs

which affect the output be made prior to the beginning of

the translation phase or subsequent to the completion of

system testing.

The users should also be able to help determine the re- lative priority of the various application programs, thus

helping determine which programs should be converted in the

first batch by the contractor. The inclusion of organizational priorities into the RFP will help ensure that the

conversion schedule developed will be responsive to the

agency's needs, while interfering as little as possible with

the existing operation.

-27-
Note Existinp: Conversion Difficulties

All programs which have been identified on the program

worksheet as having potential problems should now be re- viewed in depth to determine the nature of these problems.

A program is defined as having no conversion difficulties if

it can be converted to another computer by reccanpiling and

correcting only syntax errors. If the program has conversion difficulties, these difficuties should be documented in

a separate list. The noted conversion difficulties generally fall into two groups:

1 . Extensive logic changes needed which affect the program throughout (e.g., a FORTRAN array which is

larger than the new system can accomodate must be

redesigned, and the logic to access the array must

be rewritten)

2. Code replacement needed, affecting the program in a specific, limited area (e.g., replacing

ENCODE/DECODE in FORTRAN with a more widely accepted

input/output method)

This detailed list and analysis of potential conversion

difficulties will make the contractors' job less costly

(since they don't have to determine these problem areas for

themselves) and helps assure that these major problem areas

are addressed in the conversion. The charts which are described in Figures 11 and 12 [15] may be of help in determining how prevalent potential conversion problems are within the existing code.

-28-
O

CM CM o o O vD

(U vO <r o o O c CO 00 in 00 CM ON

•H

hJ on iH CN

03

C/3

00

O vO 00 <1- CM 00 CM 00 CM

CM rH -a- CM iH cn

CO

00

00

CM

CMCO

CM

CM in CM CO CM o

CO o

•H

4-) CO iH3

CJ iH

CO OX

CO H

(l4

COEM

Pi! >

C/3 oo

Pi

PQOU

PioM

0)N

•HrH c m CO

u

CO COU QJ

4-1 OJ o 0) 4-J •H a 4J c cn o (1) O o w <; o Pi

C/2 (/I CO

Pu <:a

CO

<:HOH

-29-
cnE

CDOU

Pico

•H

CO

0)>cou

0) ^3OOm

(1) c

•HOOUm

0)oOo

T3Oo

LTl CO

CM

vO in

00

m

CO o 00 00

CM rH owoM

PQ

PQ<

CMoCO

M

PiH

PQ

HO

Pi

CO

in

C3N

in

esi

<:Ho

(J

COH

PiooOPE4

CM

-30-
Data Preparation

Data preparation is the process of gathering all the

materials that will be used in the conversion. The agency

staff should do the vast majority, if not all, of the data

preparation since they are the most qualified to identify

the types and sequence of information to gather, and the

ways in which to prepare the conversion materials. During

data preparation, the agency staff must ensure that all the

inputs to the conversion process, (which should have been

derived from the conversion inventory worksheet, and modified based on each program's usefulness on the new system)

are available to be used by the contractor. These inputs

should include program source listings, input files, record

layouts, documentation, etc.

Test files must be generated to ensure that the con- tractor adequately tests and validates the converted system.

Thus, test data that can exercise at least 70 percent of the

program code should be generated on the source system.

Although the study of testing is currently in the research

stage, the 70 percent figure is regarded by conversion specialists to be a reasonable rule of thumb. However, the 70

percent figure should be adjusted depending upon the importance of the code tested. If the code is crucial to the

operation of a system, test data that exercises 80 percent

or even 90 percent of the program code may be appropriate.

It is desirable to keep the input data test files as small

as possible, while still providing adequate testing. A test

file should be small enough to yield acceptable run times

for the converted program, and still be representative of

data that can test 70 percent of the code. Test data files

(as well as listings) are needed for each program identified

on the conversion inventory worksheet.

After test files that test an acceptable amount of code

are developed, each source program should be recompiled and

run with the test files, producing sample output. Later on,

during the testing phase of the conversion contract, the

contractor will use this sample output as a comparison for

the actual output of the converted programs to determine if

the programs have been converted correctly, from a functional standpoint.

Determine Manpower and Computer Resource Estimates

Before an RFP for conversion services can be completed,

estimates must be made by the agency as to the resources re- quired for the contract. Specifically, the agency must

develop a conversion workload estimate that itemizes the

manpower estimate, as well as the computer costs, to com- plete the conversion effort. Estimating the staff time,

-31-
computer costs, and time necessary to complete the conversion is not an easy task. There is no universal formula for

estimating conversion costs, and it is beyond the scope of

this guide to develop a comprehensive discussion of this topic. A recent publication by GSA, entitled REVIEW AND

ANALYSIS OF CONVERSION COST-ESTIMATING TECHNIQUES [91, addresses this topic.

A useful approach which may aid agencies in determining

conversion resource requirements is the development of a prototype conversion. In this approach, a representative

sample of the programs to be converted is chosen, along with

qualified people to perform the conversion. It is doubtful

that in-house people would be available to perform a prototype conversion since a major reason for contracting out for

conversion services in the first place is a lack of qualified people available in-house. It may, therefore, be appropriate to include the prototype conversion as the initial task for the ensuing conversion contract, or as a separate preliminary contract. A separate preliminary contract is preferable since the cost estimates derived from

the prototype can be used in negotiations with the offerors

for the follow-on conversion contract. Reference [21] may

be useful in helping to determine these estimates.

Two factors will necessitate adjustments to the parameters derived from the prototype. One is the initial learning phase which will undoubtedly cause the time estimate to

be high. The other factor is the interrelationship problems

which must be solved when systems are highly interconnected.

The prototype may not be representative of system interrelationships, and consequently, the time estimates derived from

the prototype would be low. Probably the most critical factors affecting the parameters are the abilities and experience of the people who will perform the conversion. Conversion is likely to be more successful, and accomplished in

fewer staff-hours, when performed by people experienced in

conversion.

Summary of Functions to be Accomplished Prior to the RFP

In summary, it is imperative that a Federal agency un- dergoing a conversion perform the following functions, prior

to releasing the RFP:

* Identification of what is to be converted - This is

accomplished by taking a complete inventory of all

programs, files, data bases, and documentation.

-32-
* An assessment of the future of all programs - Decisions may be made to discard programs because they

were poorly designed or inefficient and to develop

new applications for the target system. Certain

programs may only be needed for a short time on the

target system and a cheaper alternative to conversion may be chosen for these programs. Users may

recommend that certain functions be deleted or modified. Finally, users should also help to determine

the relative priority of the various programs.

* A review of existing conversion difficulties - All

programs which have been identified in the program

inventory as having potential problems should be re- viewed in depth to determine the nature of these

problems.

* Data preparation - The agency staff must ensure that

all inputs to the conversion process are available

to be used by the contractor. These inputs include

program source listings, input files, record layouts, documentation, etc.

* The generation of test files - The agency should

generate test files that can exercise at least 70

percent of the program code. Each source program

should be executed with these test files to produce

sample output which will later be used as a comparison with the output generated from the converted

programs.

* A determination of manpower and computer resource

estimates - The agency must develop a conversion

workload estimate that itemizes manpower, as well as the computer costs, to complete the conversion effort.

-33-
4. DESCRIPTION/SPECIFICATION OF SERVICES

The next four chapters address the content of the RFP

for conversion products. Specifically, these chapters point

out the kinds of information that should be included in different sections of the RFP. This chapter deals with defining the scope of work. Chapter 5 talks about deliverables

and acceptance criteria. Chapter 6 addresses how to specify

the instructions to the offeror and chapter 7 discusses

evaluation criteria. It must be emphasized that these

chapters do not comprise a boilerplate for the information

to be contained in an RFP for conversion services. Instead,

they contain general guidance concerning the types of con- siderations a conversion manager is generally faced with.

Each agency which is engaged in developing an RFP for

conversion services should work with their own procurement

department, as well as GSA's Federal Conversion Support

Center, to derive the details of the RFP.

The purpose of this chapter is to detail the scope of

work which will be performed. The SPECIFICATION OF SERVICES

section is the core of the RFP, since this is where the

agency specifies exactly what is to be converted and the

conditions and constraints that m.ust be adhered to by the

contractor. Each section in this chapter addresses a separate area that an agency should include in an RFP to define the scope of work. Prior to the gathering of information necessary for this section, a glossary of terms that are used in the RFP should be developed. The glossary

should then be included as a separate attachment to the RFP.

Reason for Conversion

The agency should first provide background information

concerning the goals of the agency, the way in which the

source system contributes to these goals, and a functional

description of the source system. This should be followed

by a detailed explanation of the circumstances necessitating

the proposed conversion. An understanding of the reasons

for the conversion effort, and an awareness of the goals of

the conversion can help the contractor decide upon a general

implementation strategy, including the choice of an appropriate conversion technique to use. This information can be included as an attachment to the RFP, rather than embedded in the section which describes the scope of work.

-34-
Current Computer System

This section should describe both the current hardware

and current non-application oriented software. The hardware

description should include the manufacturer and model number

of the mainframe, primary memory capacity, secondary storage

capacity, and a complete description of all peripheral devices.

The software description should include the name and

version number of the operating system, the compilers, interpreters, and assemblers available and a description of

general purpose system utilities presently used by the source system. In addition, general purpose programs, written and used by in-house personnel, should be briefly

described. This information can be included as an attachment to the RFP, rather than embedded in the section which

describes the scope of work.

Target Computer Svstem

Both tlie target hardware and non-application target

software should be described in this section. As with the

current hardware, the description of the target hardware

should also include the manufacturer and model number of the

mainframe, primary memory capacity, secondary storage capacity, and a complete description of all peripheral devices.

Similarly, the target software description should include the name and version number of the operating system,

the compilers, interpreters, and assemblers which will be

available on the target machine, and a description of general purpose system utilities which will be available on the

target system.

Charts, similar to the ones listed in Figure 13 [15], can be extremely useful in identifying tasks which need to

be accomplished because of differences both in the hardware

and non-application software between the current and target

systCTis. These types of charts can be produced by the agency and included in this section of the RFP, or prepared as an attachment to the RFP. The charts can subsequently be

expanded by the contractor after the award.

Description of Applications

The most important item to be addressed when defining

the scope of work for a conversion effort is to precisely

define the application programs which are to be converted.

As was mentioned in chapter 3, a complete inventory of all

programs, files, data bases, and documentation which pertain

to the source syst«n should have been taken, prior to writing the RFP. The information derived from this inventory is

used to help define the scope of work.

-35-
Piouw 3

CO

CL) u CU d bC

4-1 CO u 3 o W)

•H

u CO c 4-1 e o :0

CO CO CO z

!>i

J-l CO

D 6fi 0)

a rH

n)

O

C

u

O iH U •H -H 5-1 CO >-i rH ^ 4-) CD 0) CO C O > c o CO o o •H •H (U CLJ OJ 3 CO 50

CO

M

C XI

C o Co CO 0) O CO •H 5-1 •H OJ rH CO 00 I—

U CO r a o CO 5-1 4-1 CU M E C C C CO c

CD •H CO (1) tH >->

u o •H &0 4-J 4_( 00

4-1 (0 0 CO p , 1 >> 5-4 c c W I-* •H 14-1 bO rHr-1 t3P [ 1 e •H •H <U -H (J •H T3 CO ^ CO cO

r-l

O CU

D

(L) e T3

n

CO

5-1 CO

0) (U u 5-1 CO •H >

^4O- CO

(-1 •H O 0) T3 e

p-( 0) •H <4-( G<; rH O

CD CO 13 CL) a) OJ 4J 4J 4J o o CO

P-. »-l oii C CO

C o o

P-i •H

a •H

t-i 1 iH

iH o iH

•H

m •H CU

c: rH

O

iH !S

COU

CU

4-1 •H CU a CO 13

>^ CU 0 CU

>-i c u CO Pm O •H CO 3

iH < CO e S-i CO CO

4-1 OJ 0) 0) C CO 4-J u

CU 0^

O CJ o cn 4-) CO CO1 4J

d) >^

u •H CO

>-i CO 4-1 Cm Xi a CO CO o o OJ 54 o 1 5-1 fU M o CM •H CO O CO T3 C 54 CM iH (U O- in O cn CN <t 2 o

PiW

<:

P4

O

P-I ^o

CO3O

•H

4J

CO

54

CU ^3

•H

CO3Oo3o

•H

CO

5-1 CU>3o

CJ

Ph

4-) 3

OJ

CD

(U

5-1 P4

CU CO

•rl 4J3O

543

CD

CUO

O

CO

"4-1

M

54

CU 13 rH

+j 0)

a 3 N &,

•H -H CO

CU

4-1 CO

CO3O

•H

4J

COo

•H

Ph CJ en (u

P-i CO M CO

(U o 3 (U 54 O 0) 3

!3 CO Ph

CO rH

54 rH

<D CO 3

CU OJ bO O

CO

CO rHa

a

a. CU CO O 54 rH O

(U o ^ > 4-1 M

(U p

4-1 •H>

•H

4J 3

•H

O CO

4-1 54bO

CU o

bC

U

CO a. 3 I bO3 4-1 to rH

hJ 3

rH ^ o CU U CD •u 3 3O 4-1 CJ rH 3

CU CU -3 > e O -H

*-) 4-J CJ P. (U E MH

CO <4-l > CU OJ

CU Pi

<u

4-> uo3

CO E

(U

4-1 CD

CDbO3

•H

4-1 bO CO O >4

^1I •H3

CUao

J3

CO

<u

CO

CDCUoo

!-i D- rHiH E CO

CU 'H

4-1 5-1 CO <U

CD

CD

CD bO E 3 CO •H 54 4J

CO54

(U3- O

bOO

54a o

C/3 o

CJw

Pi<:o

cn i

1^

CO

PS

!=> OM

-36-
The best way to define the applications to be converted

in the RFP is to include the conversion inventory

worksheets, described in chapter 3, as an attachment to the

RFP. As a minimum, the following information should be provided by the worksheets:

* A description of all programs to be converted.

(Figures 1,3,7,8 and 10)

* A description of all files to be converted. (Fig- ures 2,4,9 and 10)

* A description of all data bases to be converted, including a description of source and target DBMS to

be used. (Figure 5)

Conditions/ Constraints

In addition to a description of what is to be converted, the Scope of Work needs to define how it is to be converted. In this section, any and all conditions or con- straints relating to the methods used by the contractor in

implementing the conversion should be discussed.

The first condition or constraint which should be

enumerated is the required use of agency standards in performing the conversion. This may include programming standards, documentation standards, or any other standard affecting any aspect of the conversion that the agency wishes

to impose on the contractor. The standards which are imposed may be either standards internal to the agency or na- tional standards, such as American National Standards Institute (ANSI) or Federal Information Processing Standards

(FIPS), to which the agency may require the contractor to

adhere.

Examples of internal agency standards are conventions

for variable names or sub-program names, standards for programming style (indentation of certain statements, organization of types of statements with respect to other types of

statements) or requirements for programming methodology (the

target language code must follow structured programming

methodology and must not use any backward goto's, etc.).

An example of national standards which an agency may

choose to invoke is the requirement for the target program

to conform to the ANSI or FIPS standard for a particular

language. This requirement prohibits the contractor from

using extensions to the language, provided by the compiler

of the target machine, in performing the conversion. According to FIPS PUB 68 (Minimal BASIC) and FIPS PUB 69 (FORTRAN), source programs, whether developed internally or on

-37-
contract should be limited to the elements of the Federal

Standard. Nonstandard language features should be used only

when the needed operation or function cannot reasonably be

implemented with the standard features alone.

Another type of constraint which may be imposed is the

requirement for the contractor to use a specific conversion

methodology (e.g., receding, reprogramming, redesign.) Criteria which can be used in helping to determine which

conversion technique to use are described in chapter 2.

However, unless the agency has a specific reason for requiring a certain technique, the choice of an appropriate

conversion technique can be left up to the contractor. Appropriate performance requirements included in the RFP

(which will be discussed later in this chapter) may force

the contractor into using a specific conversion technique in

order to meet a specific performance requiranent.

Performance Criteria

In a report by the National Bureau of Standards [3],

the authors concluded that the lack of performance criteria

in an RFP can often times result in a converted system that

does not meet the users' needs. In the past, the failure of

Federal agencies to include performance requirements as part

of the conversion RFP and the resultant contract, have

forced agency personnel to fine-tune the converted code,

after they have received it as a deliverable under the

conversion contract. This is not only extremely costly to

the agency, in labor hours, but even more importantly it often means that the converted programs can't be used until

the fine-tuning is completed. Since this fine-tuning may

take a year or more until it successfully results in the

converted programs executing according to minimum operational efficiency constraints, the inclusion of comprehensive

performance constraints into the RFP can save much time and

effort later on.

Some types of performance requirements which may be included in an RFP are processing time criteria, memory and

execution time considerations, and accuracy criteria. Performance requirements must be measurable and verifiable.

Asking a contractor to ensure that processing time be as fast as possible, for instance, is a meaningless requirement.

Accuracy criteria, in the form of required precision in

results of arithmetic operations, will more likely be a major consideration in the scientific, rather than business,

community. If precision requirements do exist, they should

be specified on an individual basis, so that the contractor

is not forced to use excessive storage locations for greater

-38-
precision in all programs, leading to disastrous execution

time and memory requirements.

Ideally, functional specifications, which describe user requirements, should exist for all source programs and systems. These requirements should have formed the basis for

the design of the original programs. Criteria for processing time for the target system can, and should, be derived

from the existing functional specifications since the actual

functions of a system should not change during a conversion

effort. Processing time criteria are extremely crucial if

the system being converted is an interactive, rather than

batch, system. An increase of seconds in response time of

the converted system compared to the source system can be

extremely crucial and may well lead to users being much more

reluctant to use the converted system.

Contractor Responsibil ities

CONVERSION OF FEDERAL ADP SYSTEMS: A TUTORIAL Q] lists

six major phases of conversion: the planning phase, the data

preparation phase, the translation phase, the unit testing

phase, the system testing phase, and the parallel testing

phase. The contractor performing the conversion has distinct and specific responsibilities relating to each of

these phases. These responsibilities for each of the phases

should be detailed in the RFP, and are explained in the

remainder of this chapter.

The planning phase consists of identifying and documenting computer systems, programs, and data files that

operate on the source computer system, as well as deciding

how the transition to the new computer system should be

made. The RFP should require the contractor to review the

agency's work done during the planning phase and provide a schedule for the collection of programs, files, data bases,

and documentation, as well as milestones for data preparation, conversion, and unit, system, and parallel testing.

In addition, the contractor should be asked to describe, in

detail, all tasks that he or she will perform throughout the

duration of the contract.

The data preparation phase is the process of gathering

all the materials that will be used in the conversion. The

information gathered in the planning phase is used to assure

that all the inputs to the conversion process (program source listings, input files, record layouts, and documentation) are ready for the conversion. Test data must also be

generated in this phase to assure that adequate testing and

validation will be performed on the converted system. Generation of test data can be done either by the agency or re- quired of the contractor in the RFP. If the agency staff

-39-
decides to generate the test data, they should make sure that they have a way of ensuring that the test data they

have generated executes a predetermined percent of the code.

On the other hand, if the test data is generated by the contractor, the RFP can, and should, require the contractor to

ensure that the test data executes a predetermined percent

of the code. Thus, for the data preparation phase, the RFP

should require the contractor to collect all of the inputs

to the conversion process and to generate test data either

by utilizing existing production files or based on criteria

provided by the agency.

In the translation phase, each source program is

translated to run on the target machine. The RFP should

state that the contractor must convert each source program,

by name, to the target machine and target language. The

contractor should be made responsible for providing all com- puter resources, facilities, and conversion tools to be used

during this phase.

The objective of the unit testing phase is to compile,

execute, and test each target program with its test data,

and to match the resultant execution output files with those

produced on the source computer. The RFP should require the

contractor to test each program at the unit level with a minimum percent code execution necessary for successful

testing. If a predetermined percent of the code is not executed, the contractor should be required to revise the test

files to achieve the desired code execution.

The system testing phase continues the testing beyond

the unit test. The interactions of the various programs

which form the system are now tested. In this phase, the

job control language commands necessary to execute each system are produced. The programs are compiled and executed as

a system. The RFP should require the contractor to test the

converted system as a whole, using test data, and to develop

all job control statements necessary to execute the system.

Parallel testing begins after system testing is completed. The production job control language commands are prepared and the production files are converted. The system

is updated to incorporate production maintenance changes

made during the conversion. The programs are compiled and

executed, and the outputs are compared to the existing production system. The RFP should require the contractor to

provide a plan for parallel testing and implementation,

software aids, and training of agency personnel. Optionally, the RFP may want to call for contractor personnel onsite for a fixed period of time to help parallel test and

implement the system.

-40-
Warranty

Some conversion firms offer warranties which guarantee

that the converted programs will produce output functionally

equivalent to that produced by the source programs. With

this warranty, the conversion firm will usually agree to

correct errors made by the contractor in converting the programs for a period of either one or two years following

delivery of the programs to the agency. The correction of errors is done at no additional charge to the agency. If an agency desires this type of warranty, it must be specified

in the RFP.
5. DELIVERABLES AND ACCEPTANCE

The deliverables in a conversion contract should be

derived from each of the different phases of conversion.

Each deliverable, including its precise form, should be

clearly specified in the RFP. These deliverables, besides

including actual source code, will also include different

types of documentation. This documentation will usually be

of two different types: 1) documentation to verify that a certain phase of the contract has been completed (e.g. a document verifying that a specific program was successfully

tested, detailing the test data that was used, and citing

the percent of the code that was executed) and 2) documentation in sufficient detail to allow the agency to understand

how the converted programs differ from the source programs

and to allow for future maintenance of the programs.

The suggested deliverables, associated with each

specific phase of conversion, are listed below.

Planning Phase

* Schedule for the collection of programs, files, data

bases, and documentation, and milestones for data

preparation, conversion, and unit, system, and

parallel testing.

* A detailed list and explanation of specific tasks,

identifying program batches, and start and ccxnpletion dates.

Data Preparation Phase

* An accounting of all collected materials for each

run.

* A description of the test data generated for each

program.

Translation Phase

* Listings of each of the translated programs.

-42-
* Any tools or aids developed for the conversion - including all necessary tapes, documentation, etc.

Unit Testing Phase

* A description of the completed testing of each con- verted program, detailing the test file used and the

percent of code executed by the test data.

* A comparison of the output of the source and target

programs, showing identical ouput when utilizing the same input data.

* A discussion of any specific performance requirements for a particular program and an explanation as to how the unit testing phase verifies that the performance requirements are adhered to.

* Any test files developed or modified by the contractor.

System Testing Phase

* Converted source programs on magnetic tape and con- verted source program listings.

* Converted job control language commands for each

system.

* A description of the completed testing of each con- verted system, detailing the test file used and the

percent of code executed by the test data.

* A comparison of the output of the source and target

systems, showing identical output, when utilizing

the same input data in the system testing phase.

The contractor must identify, and explain, any

places in the output where an identical match does

not occur.

* A discussion of any specific performance requirements for the system, as a whole, and a justification as to how these requirements are verified in

the system testing phase.

* Any test files developed or modified by the contractor.

-43-
Parallel Testing Phase

* A detailed plan for parallel testing and implementation, as well as necessary software aids, and a plan

for training of agency personnel.

* A program which converts all source system input

files to a format acceptable to the target machine,

* A file compare routine, developed for the target

machine, which will determine the equality of two

files, and, thus, help the agency during the parallel testing phase.

Documentation for Understandabilitv

Documentation which helps the programmer understand the

logic within a program can be presented in two different

ways: 1) either internal to the program or 2) external to

the program. Internal documentation takes the form of non- executable statements in the language, which serve as comments. The comment line in FORTRAM or the REM statement in

BASIC are examples of these types of statements. Making

sure contractors supply comments in any programs they are writing for an agency is a must. For a conversion contract,

the contractor should be made to supply comments about

specific sections of the code which proved exceptionally

difficult to convert and any impact that these sections of

the code may have on future maintenance and general understandability or readabiltiy. These comments can be cited as deliverables as a product of the unit testing phase.

Program documentation external to the code should also

be supplied by the contractor. If acceptance criteria are properly included in the RFP, the contractor may have to do

extensive reprogramming, or even redesign to meet the performance requirements. Updated documentation (if program

documentation currently exists) or new program documentation

must reflect the changes made to the programs for the purpose cited above.

In addition, other types of documentation, designed to

help a designer, programmer or user understand the converted

system may be asked for, depending upon the conversion

method used (receding, reprogramming or redesign) or the future plans of the agency. The following is a partial list

of some other documentation which may be desired by the

agency:

-44-
* Operating instructions, including a description of

the job control commands used.

* Training documents.

* Data file descriptions.

* Program flowcharts or top down design analysis (only

if reprogramming and redesign are required).

* System flow charts (if redesign is required).

* Implementation plan to be used for the remainder of

the conversion task.

Acceptance Criteria

GAO, in a document entitled CONTRACTING FOR COMPUTER

SOFTWARE DEVELOPMENT—SERIOUS PROBLEMS REQUIRE MANAGEMENT

ATTENTION 10 AVOID WASTING ADDITIONAL MILLIONS, [28], states

that "Extensive acceptance testing criteria and test data

should be developed before the contract is released and ac- ceptance tests contractually required. Test and acceptance

criteria—how software must perform before it will be

accepted—must be identified."

Acceptance criteria comprise one of the most important

parts of the conversion contract. Without adequate acceptance criteria, an agency may spend millions of dollars on conversion and wind up with a converted system which is not

usable. Acceptance of the contractor's deliverables and final payment should occur only when the following conditions

have been met by the contractor, and verified by the agency:

* All files converted.

* Program outputs equal - The output of the converted

programs, utilizing the converted files must equal

the output of the source programs, utilizing the

source files. The agency should make sure it scru- tinizes the output of each converted program for

equality, and checks to make sure that a predetermined percent of the program code was exercised by

each program during the unit testing phase.

* System outputs equal - The output of the converted

systons, utilizing the converted files must equal

the output of the source system, utilizing the

source files.

-45-
* Documentation updated to reflect changes - If possible, documentation should be required in hard-copy

as well as some machine readable medium (computer

readable or word processing equipment) so that it can be revised more easily. This documentation

should include internal (comments in source code) as well as external documentation, as explained earlier

in this chapter.

* Meets design and functional specification criteria - Although this is a conversion effort, rather than an original design, the agency must ensure that any and

all design and/or specification criteria that are

included are adhered to by the contractor.

* Meets processing time criteria - The agency must

designate acceptable parameters for processing time,

making it incumbent upon the contractor to choose

the appropriate method of conversion (receding,

reprogramming, redesign, etc.) to produce functionally equivalent source code which executes within

the constraints set up by processing time parameters. For on-line systems, maximum acceptable

response time must be specified by the agency for

each set of user interface functions.

* Meets accuracy criteria - This entails specifying an acceptable level of precision for arithmetic operations.

* Meets other performance constraints - This includes

run-time efficiency, efficient utilization of main

and secondary storage (including proper structuring

of data bases, when working in a data base environment), and error checking.

Audits should occur at regular intervals to ensure that

these conditions are being met by the contractor.

-46-
6. INSTRUCTIONS TO OFFEROR

When preparing an RFP for conversion services, the

agency must decide what information is needed from the con- tractors in order to effectively evaluate their proposals.

The instructions to the offerors concerning this type of information should be included in a separate section of the

RFP. To the offerors, these instructions specifically

describe what they are being asked to do, with respect to

the preparation of the proposal.

The information which the offeror is asked to provide

will subsequently form the basis for evaluating the proposal, based on the evaluation criteria provided in the RFP.

This section of the RFP should contain a warning that insufficient data or inappropriate data may be considered as evidence of a lack of understanding of the intended effort, and

will affect the evaluation score.

The following sections of the offeror's proposal are

needed, as a minimum, in order to perform a complete evaluation. The offeror should be instructed, in this section of

the RFP, to provide the following information:

1) Work Statement -The offeror should be instructed to include the following three areas of discussion in his Work

Statement:

i) A discussion of the technical and management problems

involved in the conversion, demonstrating a clear understanding of all the issues.

ii) An outline and discussion of a proposed technical approach for accomplishing the conversion. The proposed

technical approach should include a proposed Implementation Plan which identifies tasks to be accomplished,

along with projected completion dates. The offeror

should provide a detailed explanation and description of

the proposed methodology to be used, including a description of which conversion technique(s) (receding, reprogramming, redesign) will be used for each program or group of programs, and an explanation of why that particular technique is most effective for these programs. The

offeror should identify any automated conversion aids

that are presently available, or that may be developed

for this contract. The description of the automated

tools should also provide an indication of the effectiveness of that particular tool (i.e., the percentage of

manual coding that remains after utilization of the

tool.) Finally, the offeror should submit a proposed test

-47-
plan, which describes the methodology for ensuring satisfactory program design and testing, including quality as- surance.

iii) A discussion of the phasing for the contract, based

upon the technical approach being proposed.

2) Offeror Experience and Capability - This section should

include sufficient information to permit evaluation of the

previous and current experience and effectiveness of the offeror in similar or related work, and to demonstrate the

offeror's current capability for carrying out the intended

contract effort.

At a minimum this section should include:

i) Previous conversions performed by offeror, describing

the source and target systems, including a discussion of

the scope and complexity of the conversion effort.

ii) Principal clients served in performing these conversions, including pertinent dates, contract numbers, approximate cost, sponsor contact (name, organization,

telephone number, and address), and offeror's key personnel involved.

iii) Level of involvement of planned subcontractors under

the proposed contract, including sufficient detail to

permit overall evaluation.

iv) Brief overall capability identification of offeror.

v) Identification of prospective supporting units or facilities which may be utilized in accomplishing the proposed effort.

3.) Proposed Contract Kev Personnel - This section should include such information necessary to permit evaluation of the

quality, competence, and experience of the personnel proposed to be available for the performance of the intended

contract effort. The offeror should be required to provide,

for each prospective key person, a resume which includes, at

a minimum:

i) Name,

ii) Title,

iii) Brief description of previous work experience

(dates, duties, and onployers), indicating whether the

experience was managerial or technical.

-48-
iv) Detailed statement of previous experience relevant to

the intended effort and of recent and current work ex- perience. (Names, current telephone numbers and addresses, where possible, of supervisors or others with

direct knowledge of individual's effort and of technical

sponsors should be supplied),

v) Specific capabilities, such as programming languages

and computers used,

vi) Education,

vii) Publications, patents, and other presentations (a

copy to be supplied, upon request, of any listed reference not otherwise readily available),

viii) Labor category and relative percentile salary level

within category,

ix) Proposed level of effort availability.

it) Certification - If any proposed Contract Key Personnel

are not presently employees, the offeror should be informed

that he or she must be involved in current good faith negotiations with prospective employees whose resumes have been

submitted and that the offeror has ascertained that the applicant will be available to work under the proposed contract. The offeror should also be asked to provide updated

information during negotiations and prior to award when any

proposed Contract Key Personnel are no longer available.

5.) Technical Management Plan - The offeror should describe

the organization and management plan which will be utilized

for the technical management of the proposed contract. This

description should demonstrate an understanding of the na- ture of the proposed effort and its potential problems, and

how issues will be handled in a timely manner at the proper

level of authority. The plan should include the following:

i) A staffing plan indicating how the proposed key personnel will be assigned and the disposition of their time

between the proposed contract and other work in progress.

ii) A clear and complete description of lines of activity; interaction with the Contracting Officer's Technical

Representative (COTR); and control of scheduling of

tasks, reports and other activities.

iii) Identification and discussion of real or apparent

possible sources of conflict of interest, that is, a situation which may diminish the offeror's capacity to give

-il9-
impartial, technically sound, objective assistance and

advice. The term "offeror" in this subparagraph includes

any staff, subcontractors, consultants, or any others

connected with the offeror who may influence the proposed

contract results. The proposal should also identify and

discuss planned efforts of the offeror to minimize the

effect of any conflict of interest. The offeror should

provide updated information during negotiations and prior

to award, if any changes are appropriate.

iv) A description of the project management and control

tools and techniques proposed and the effectiveness of

such tools.

6) Modifications - Any proposed modifications of the proposed contract as described in the RFP should be specifically itemized and discussed in this section. These modifications may differ in technical approach, level of effort proposed, and/or period of performance as long as all the re- quirenents and deliverables of the solicitation are met.

-50-
7. EVALUATION AND AWARD FACTORS

Once the offerors prepare their proposals, based on the

instructions given to them, the information they have provided becomes the basis for evaluating the relative merits

of their proposals. Thus, the evaluation criteria, which

are discussed in this chapter, are derived from the instructions given to the offeror. In the remainder of this

chapter, suggested evaluation factors are discussed, and a suggested weighting factor is assigned to each. The weighting factor indicates the relative importance associated with

each of the factors during evaluation.

Technical Approach to the Statement of Work

The information provided by the offeror in the Work

Stat^nent is the first area to be considered in evaluating

the proposal. The technical approach to the stat^nent of

work is the section of the proposal where most of the crucial information is obtained and consequently deserves to

have a high weighting factor assigned to it. It is in this

section where the agency should discover if the offeror ac- tually understands the work involved and if the offeror has

the capability to do the job.

When scoring each section of a proposal, it is usually

helpful to have a checklist of sub-factors, pertinent to the

area, to help decide how many points to assign to each offeror. For the sake of completeness, the offeror should address as many of the factors in the checklist as possible.

However, the offeror should not be guaranteed a good score

just because all of the factors cited below have been addressed. Quality is still the most important criteria in

scoring the proposal. Therefore, the content of the

offeror's response concerning the areas in the checklist,

and whether or not the offeror demonstrates an understanding

of the intended effort and the ability and willingness to

perform the conversion are more important than the number of

sub-factors that are addressed in his proposal. The following checklist is proposed for helping to evaluate the technical approach to the statement of work:

* Conceptual soundness of approach.

-The overall approach should make sense and

should be an appropriate approach for this particular system of programs.

-51-
Schedule and plan to implement the approach.

-The major phases of conversion should be identified by the offeror.

-The correct activities should be planned for

these phases.

Identification of conversion planning elements.

-The offeror should demonstrate an understanding

of what is involved in the planning phase of

conversion.

-A comprehensive conversion plan should be

presented by the offeror.

Degree of use and quality of conversion aids proposed.

-The offeror should identify the conversion aids

to be used.

-The offeror should also identify the effectiveness of these conversion aids (i.e., the percentage of manual coding that remains to be done

after utilizing the tool).

Offeror's approach to translation.

-The offeror should present a detailed explanation and description of the proposed methodology

to be used, including a description of which

technique(s) (receding, reprogramming, . redesign)

shall be used for each program or group of programs, and an explanation as to why that technique is most effective for these programs.

-The offeror should discuss how non-standard code

will be treated and whether or not I/O and non- standard code will be modularized.

Offeror's approach to quality control.

-The offeror should discuss quality control for

incoming materials as well as quality control

during the translation phase.

Offeror's testing philosophy.

-A comprehensive test plan should be presented by

the offeror.

-52-
* Acceptance testing and verification.

-Detailed acceptance tests should be proposed by

the offeror.

-Performance considerations should be taken into

account by the offeror.

The offeror's philosophy of implementation is among the

most important information contained in an offeror's statement of work. The following factors concerning implementation philosophy should be taken into account in scoring the

offeror's technical approach to the statement of work:

* Maintainability of converted code - This factor con- cerns the quality of the converted code.

-Will the code be readable and maintainable?

-V/hat types of standards will be used, besides

the ones provided by the agencies?

-How does the offeror view comments and the need

for program documentation?

* Training

.

-The offeror should discuss plans for training of

both his or her staff and the agency staff.

-Specifically, training for programmers,

analysts, operators, users, and management needs

to be discussed.

* Understanding of and approach to problem areas - The

offeror should address the following questions:

-How will distinct differences in canputer architecture affect the conversion?

-Will problems arise because of different word

sizes on the two machines?

-If so, how will these be handled?

-Will problems arise because of different collating sequences?

-Will differences in JCL cause special problans?

-53-
-Will differnces in primary, as well as secondary

memory between the two machines cause problems?

-If so, how will these problems be handled?

-How will machine dependencies in the source code

be handled?

-Is program documentation sufficient to address

some of the above problems?

Qualification of Offeror

In this section of the proposal, the offeror details

the experience of the firm and corporate management, excluding a detailed profile of key personnel. This section, as well as the section on key personnel, is extremely critical

in evaluating the proposal because the success of a computer

system conversion depends heavily on the experience of the

entity performing the conversion. Thus, a high weighting

factor is suggested. Comprehensive, detailed experience in

conversion is difficult to find since conversions occur infrequently (once every five to seven years), and the people

who perform the conversions frequently move on to other

areas in data processing, such as design or original programming. Firms which specialize in conversions and who

maintain people who build up an expertise in this discipline

are in great demand. Previous conversions, performed by the

offeror, should be as similar to the conversion addressed in

this RFP as possible.

The following checklist is proposed as an aid in helping to score the qualifications of the offeror and/or subcontractor:

* The degree of general experience in software conversion - The offeror should provide details of similar

previous conversions performed, describing the scope

and complexity of the effort, the source and target

systems, and the principal clients served in performing these conversions. References should be

checked.

* Specific experience in target language or machine - The offeror should describe experience in converting

systems to the target language specified in this

solicitation as well as to the target computer

specified in this solicitation.

-54-
* The available facilities - The offeror should

describe the facilities which will be used to perform this conversion and specify how these facilities were utilized in performing other conversions.

* Level of management participation in the conversion

process - Since the major difficulties associated

with conversions are very often management rather

than technical problems, the offeror should demonstrate the conversion management expertise which is

retained by the firm.

* Variety of conversion experience - Although not as important as the other factors, a variety of experience will allow the contractor to make difficult decisions concerning unexpected problems, based, in

many instances on similar instances in prior conversions.

* Corporate resources - Although larger doesn't always

imply better, the offeror must demonstrate that sufficient technical and managerial staff are available

to do the job.

Qualification of Proposed Key Personnel

In this section of the proposal, the offeror details

the experience of the key personnel. Ccmpetent, experienced

conversion specialists are extremely difficult to find.

Thus, this section of the proposal must be scrutinized very

carefully to determine whether or not the key personnel are actually qualified. A high weighting factor is suggested

for Qualification of Proposed Key Personnel.

The following checklist is proposed as an aid in helping to score the qualifications of the key personnel:

* Relative experience of project team - The offeror

must demonstrate that the project team has com- petence and experience to perform the conversion.

Specific capabilities, such as programming languages

utilized, conversion tools utilized, and computers

worked on should be detailed in this section. A

complete employment history, including relevant

current and recent work experience, project names,

descriptions and degree of involvement, and clients

should be provided here. References should be

checked

.

-55-
* Mix of skills of proposed personnel - The offeror

must demonstrate that the project team has a sufficient mix of skills to cover the broad areas involved in the different phases of conversion.

* Relative experience of project manager - The project

manager is the most important of the key personnel

proposed. He or she must possess a broad background

of managerial experience in past conversion projects

as well as enough low-level conversion expertise to

make decisions affecting the technical direction of

the project.

Reasonableness of Management Plan

In this section, the offeror describes the organization

and management skills which will be utilized for the technical management of the proposed contract. Managonent skills

involve staffing, scheduling, reporting, managing personnel,

and controlling materials. This description should demonstrate how issues will be handled in a timely manner, at the

proper level of authority. A relatively low weight is

recommended for this factor. The following checklist is

proposed as an aid in helping to score the reasonableness of

the management plan:

* A staffing plan indicating how the proposed key personnel will be assigned, and the disposition of

their time between the proposed contract and other

work in progress must be provided by the offeror.

* A detailed schedule, which is consistent with both,

the goals of the conversion, as well as the limitations of the conversion effort should be provided by

the offeror.

* Responsible management officials must be named,

* Lines of activity and responsibility must be clearly

and completely described.

* Interaction with the Contracting Officer's Technical

Representative must be detailed.

* Reporting dates and methods should be given.

* Milestones should be clearly identified.

-56-
* The offeror should demonstrate his or her ability to

respond on short notice.

* The offeror should demonstrate his or her flexibility to respond to changed conditions.

* Conflicts of interest should be discussed by the offeror .

* A description of the project management and control

tools and techniques should be provided by the offeror .

Cost

If the contract is fixed price, the agency has determined that the RFP precisely defines the scope of work. In

this case, the responsibility is on the contactor to deliver

a converted system according to specifications. Since the

agency is contractually assured of a correct converted system, regardless of which offeror is selected, the least

costly offeror becomes very attractive. Conversely, the

determination that a cost plus contact is needed, implies

that the scope of work is not as precise, and the agency is

depending upon the contractor's best efforts to perform the

conversion. In this case, the quality of the contractor is

more important than the cost. Thus, a relatively low

weighting factor is suggested for cost with the assumption

that the contract will be some sort of cost plus contract

(cost plus fixed fee, cost plus incentive fee, etc.). If it

is decided that the contract shall be a fixed-price contract, then the weight associated with the cost factor will

have to increase significantly, and the weight for the other

evaluation factors identified must decrease proportionately.

However, as stated earlier, many conversions do not

lend themselves to fixed price contracts since the scope of

the effort is not known with great certainty, especially if

performance and efficiency constraints are included as part

of the acceptance criteria. In this case, cost should be a relatively smaller factor than the other factors identified,

since the selection of a low cost, but only marginally qualified technical proposal may very well result in a converted

system which does not meet the agency needs, and is thus,

unusable as it stands. Much expenditure of agency

resources, in both manpower and cost, would then be necessary in order to tune the converted system to the point

where it would be usable. In the long run, this approach

would not only be highly detrimental to the agency's goals

and needs, but would actually result in a conversion which

is more costly, over its systems life cycle.

-57-
8. CONCLUSIONS

Probably the most important thought to keep in mind

when writing an RFP for conversion services is to include,

in the RFP, everything that you want the contractor to do.

Don't assume that anything will be done if it is not specifically stated in the RFP. Avoid the pitfall of having to

rely on the contractor for follow-on work because the

deliverables have not been sufficiently thought-out and

specified. Only close attention to every detail of what

should be in the RFP can assure a successful conversion effort. This chapter presents a summary of the most crucial

aspects of the RFP.

Specification of Services

In this section of the RFP, all software which is to be

converted must be precisely defined. There is no easy way

to accomplish this. A ccmplete inventory of all programs,

files, data bases, and documentation must be done and the

results from this inventory included as an attachment to the

RFP. Any constraints which the agency would like to impose

on the contractor must be stated explicitly.

If a specific conversion technique is not required by

the RFP, the contractor will almost surely choose to perform

a line-for-line conversion since this is the easiest and

least costly method. Similarly, if the RFP does not specify

performance criteria, the contractor will probably choose to

perform a line-for-line conversion since there is no incentive to improve the operating efficiency of the system.

Even if perfcanance criteria can not be derived and, thus, are not included in the RFP, there may be another reason for

asking for reprogramming or redesign rather than a linefor-line conversion. Especially when converting from assembly language to a higher level language, such as COBOL, a line-for-line conversion will result in converted code which

is much larger than it should be.

Deliverables and Acceptance

The deliverables associated with each phase of conversion and the acceptance criteria must be explicitly stated.

Minimum acceptance criteria include:

* All files converted,

-58-
Program outputs equal,

System outputs equal,

Documentation updated to reflect changes.

Meets design and functional specification criteria.

Meets processing time criteria.

Meets accuracy criteria.

Meets other performance constraints.

Instructions to Offeror

The instructions to the offeror should request all information which is needed in order to evaluate the offeror's

proposal. These instructions should address the following

areas:

* Work statement,

* Offeror's experience and capability,

* Proposed contract key personnel,

* Certification,

* Technical management plan,

* Modifications.

Evaluation and Award Factors

The choice of evaluation factors and the weight as- signed to them are very important since this choice will ultimately decide which offeror receives the contract award.

The suggested evaluation factors are:

* Technical approach to the statement of work,

* Qualification of offeror,

* Qualification of key personnel.

ft

ft

ft

ft

ft

ft

ft

-59-
* Reasonableness of management plan,

* Cost.

Conversion contracting can be an experience which is

weighed down with problems if it is not well thought-out.

Many problems can be avoided, and a smooth transition to the

target machine can be accomplished, by thoroughly planning

the contractors' activities and effectively ccanmunicating

these plans to them. An agency cannot expect to receive

anything which is not clearly specified in the contract.

-60-
Appendix A: Bibliography and References

1. A study for The FY76 Worldwide ADP Single Managers

Conference

ADP Conversion Cost

Randolph AFB Tx, 3-5 December 1975

2. Berg, John, L., editor

Data Base Directions - The Conversion Problan

NBS Special Publication 500-64, September I98O

3. Collica, Joseph, et al.

Conversion of Federal ADP Systems: A Tutorial

NBS Special Publication 500-62, August I98O

4. Computerworld

"Users Underestimate Conversion Costs : Survey"

October 8, 1979 p. 55

5. Conference Book of the National Symposium on Computer

Systems Enhancement

Converting Today's Systems To Tomorrow ' s Technology

Data Processsing Management Association, November 13-15,

1979

6 . Cooper , Roger

"Upgrading Federal Computers Through Existing Systems"

Government Executive, August 1979

7. Dooley, Ann

"Conversion Causes Welfare Payment Delays"

Computerworld, October 15, 1979

8. Federal Conversion Support Center

CONVERSION STUDY CHECKLIST

9. Federal Conversion Support Center

REVIEW AND ANALYSIS OF CONVERSION COST-ESTIMATING TECHNIQUES

Report No. GSA/FCSC-8I/OOI , January 1981

10. Federal Information Processing Standard 43

Aids for COBOL Program Conversion (FIPS PUB 21 to FIPS PUB

21-1)

National Bureau of Standards, December 1, 1975

1 1 . Fleiss, J. , et al.

Programming for Transferability

Prepared for Rome Air Development Center, September 1972

-61-
12. Frank, Werner L,

The New Software Economics

Library of Congress Catalog No. 79-90434, 1979

13. Fry, J. , et al.

"An Assessment of the Technology for Data and ProgramRelated Conversion"

AFIPS Conference Proceedings

National Computer Conference, Anaheim, California, June 5-8,

1978

pp. 887-907

14. GSG, Inc.

DPSC Experience Using the NAVDAC Conversion Management

System

March 10, 1980

15. Headquarters, Department of the Army

Army Automation Planning Guide for Software Conversion Department of the Army Technical Bulletin, October 1977

16. Lynn, C. , et al.

"Program Conversion - One Successful Paradigm"

AFIPS Conference Proceedings, Volume 48

National Computer Conference, 1979

17. Morgan, L.W., et al.

Conversion of CCF UNIVAC Software

MITRE Corporation MTR-4710, January 1978

18. NTIS

Computer Software Transferability and Portability

A Bibliography with Abstracts

NTIS/PS-79/0567, May 1979

19. Oliver, Paul

Bibliography of Conversion References

Federal COBOL Compiler Testing Service, April 4, 1978

20. Oliver, Paul

"Guidelines to Software Conversion"

AFIPS Conference Proceedings

National Computer Conference, Anaheim, California, June 5-8,

1978

pp. 877-886

21. Oliver, Paul

Handbook for Estimating Conversion Costs of Large Business

Programs

Department of the Navy, February 14, 1979

22. Oliver, Paul

-62-
Survey of Conversion Support Software

Federal COBOL Compiler Testing Service, March 16, 1978

23. Rand Information Systems

Conversion Special Report : Changing to New Technology

Commissioned by the Data Processing Management Association

Education Foundation for the National Symposium on Computer

Systems Enhanc^nent, November 13-15, 1979

24. Rand Information Systans

Questions and Answers on Conversion

25. Razza, Sal

"Software Portability"

Computerworld, November 19, 1979, p. 57

26. Schneider, Daniel B.

Computer Systems Conversion

A Management Perspective

U.S. Department of Justice, October 1978

27. Snider, Edward L., et al.

Data Processing Service Center Project Final Report

Naval Data Automation Command, December 1979

28. The Comptroller General of The United States

Report To The Congress

Contracting For Computer Software Development—Serious

Problems

Require Management Attention To Avoid Wasting Additional

Millions

GAO FGMSD-80-4, November 9, 1979

29. The Comptroller General of The United States

Report To The Congress

Millions in Savings Possible in Converting Programs from One

Computer to Another

GAO FGMSD-77-34, September 15, 1977

30. The Comptroller General of the United States

Report To The Congress

The Federal Information Processing Standards Program : Many

Potential Benefits , Little Progress , and Many Problems

GAO FGMSD-78-23, April 19, 1978

31. US Army Computer Systems Support and Evaluation Agency

Survey of Software Conversion Aids ( Emulators , Simulators , Translators)

1 December 1975

32. US General Accounting Office

PROVISIONAL CHECKLIST FOR SOFTWARE CONVERSION PROJECTS

September 15, 1977

-63-

NBS-114A incv. z-wci U.S. DEPT. OF COMM. I. PUBLICATION OR 2. Performing Organ. Report No. 3. Publication Date BIBLIOGRAPHIC DATA

REPORT NO. SHEET (See instructions) NBS SP 500-90 May 1982

4. TITLE AND SUBTITLE

Guide to Contracting for Software Conversion Services

5. AUTHOR(S)

Mark W. Skall

6. PERFORMING ORGANIZATION (If joint or other than NBS. see /n struct/on s)

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

7. Contract/Grant No.

8. Type of Report & Period Covered

Final

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State. ZIP)

Same as No. 6

10. SUPPLEMENTARY NOTES

Library of Congress Catalog Card Nimiber: 82-600531

Document describes a computer program; SF-185, FlPS Softv/are Summary, is attached.

11. ABSTRACT (A 200-word or less factual surnmory of most significant information. If document includes a si gnificant

bi bliography or literature survey, mention it here) This guide is the first in a series of publications which

will be issued by the National Bureau of Standards with

respect to conversion of Federal agency ADP Systems. The

need for these publications was determined by a study conducted in 1980, consisting of interviews with commercial

conversion experts and Federal Government agency personnel

who have recently experienced conversions, as well as a search of the current literature. The results of that study

are documented in NBS Special Publication 500-62, entitled

CONVERSION OF FEDERAL ADP SYSTEMS ; A TUTORIAL. The purpose

of this guide is to educate the Federal manager in the benefits which can be gained by contracting for conversion services as well as to specify all the actions the agency must

take to ensure a successful conversion contract. The guide

concludes that a smooth conversion can be accomplished by

thoroughly planning the contractor's activities and effectively communicating tnese plans to the contractor.

12. KEY WORDS (Six to twelve entries; alphabetical order; copitali ze only proper names; and separate key words by semicolon s) Acceptance tests; conversion contracting; conversion problems; deliverables;

evaluation criteria; Federal agencies; language translators; portability;

program inventory; RFP; statement of work

13. AVAILABILITY

[X; J Unlimited

[ j For Official Distribution. Do Not Release to NTIS

hi J Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

" 20402.

[. j Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

67

15. Price

USCOMM-DC S0O-P80

ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SCIENCE & TECHNOLOGY

Superintendent of Documents,

Government Printing Office,

Washington, D. C. 20402

Please add my name to the announcement list of new publications to be issued in the series: National Bureau of Standards Special Publication 500-.

Name

Company

Address

City State Zip Code

(Noiincation key N-S03)

/

j!r U^. GOVERNMENT PRINTING OmCE : 1982 O—360-997 (2088)

NBS TECHNICAL PUBLICATIONS

PERIODICALS

JOURNAL OF RESEARCH—The Journal of Research of ihe National Bureau of Standards reports NBS research and develop- ment in those disciplines of the physical and engineering sciences in which the Bureau is active. These include physics, chemistry,

engineering, mathematics, and computer sciences. Papers cover a broad range of subjects, with major emphasis on measurement

methodology and the basic technology underlying standardization. Also included from time to time are survey articles on topics

closely related to the Bureau's technical and scientific programs. As a special service to subscribers each issue contains complete

citations to all recent Bureau publications in both NBS and non- NBS media. Issued si\ times a year. Annual subscription: domestic

$18; foreign $22.50. Smgle copy, 54,25 domestic: $5.35 foreign.

NONPERIODICALS

Monographs—Major contributions to the technical literature on

various subjects related to the Bureau's scientific and technical activities. Handbooks—Recommended codes of engineering and industrial practice (including safely codes) developed in cooperation with in- terested industries, professional organizations, and regulatory

bodies. Special Publications—Include proceedings of conferences sponsored by NBS, NBS annua! reports, and other special publications

appropriate to this grouping such as wall charts, pocket cards, and

bibliographies. Applied Mathematics Series—Mathematical tables, manuals, and

studies of special interest to physicists, engineers, chemists,

biologists, mathematicians, computer programmers, and others engaged in scientific and technical work.

National Standard Reference Data Series—Provides quantitative data on the physical and chemical properties of materials, compiled from the world's literature and critically evaluated. Developed under a worldwide program coordinated by NBS under

the authoritv of the National Standard Data Act (Public Law

90-3%).

NOTE: The principal publication outlet for the foregoing data is the Journal of Physical and Chemical Reference Data (JPCRD)

published quarterly for NBS by the American Chemical Society

(ACS) and the .American Institute of Physics (,AI P). Subscriptions,

reprints, and supplements available from ACS, I 155 Sixteenth St., NW, Washington, DC 20056.

Building Science Series—Disseminates technical information developed at the Bureau on building materials, components,

systems, and whole structures. The series presents research results,

test methods, and performance criteria related to the structural and

environmental functions and the durability and safety characteristics of building elements and systems.

Technical Notes—Studies or reports which are complete in themselves but restrictive in their treatment of a subject. Analogous lo monographs but not so comprehensive in scope or definitive in treatment of the subject area. Often serve as a vehicle for final reports of work performed at N BS under the sponsorship of other government agencies.

Voluntary Product Standards—Developed under procedures

published by the Department of Commerce in Part 10, Title 15, of

the Code of Federal Regulations. The standards establish nationally recognized requirements for products, and provide all concerned interests with a basis for common understanding of the

characteristics of the products. NBS administers this program as a supplement lo the activities of the private sector standardizing

organizations. Consumer Information Series—Practical information, based on NBS research and experience, covering areas of interest to the con- sumer. Easily understandable language and illustrations provide

useful background knowledge for shopping in today's tech- nological marketplace. Order the above NBS puhlicaiicms from: Superiniendeni oj Documenis. Government Printing Office. Washington. DC 20402. Order the following NBS publications—FIPS and NBSIR's—from

the National Technical Information Services. Springfield. VA 22161

Federal Information Processing Standards Publications (FIPS

PUB)—Publications in this series collectively constitute the Federal Information Processing Standards Register. The Register

serves as the official source of information in the Federal Governmeni regarding standards issued by NBS pursuant to the Federal Property and Administrative Services Act of 1949 as amended.

Public Law 89-306 (79 Stat. 1127), and as implemented b> Executive Order 1 1717 (38 FR 12315, dated May II, 1973) and Part 6 of Title 15 CFR (Code of Federal Regulations).

NBS Interagency Reports (NBSIR)—A special series of interim or

final reports on work performed by NBS for outside sponsors

(both government and non-government). In general, initial dis- tribution is handled by the sponsor; public distribution is by the National Technical Information Services, Springfield, VA 22I6I,

in paper copy or microfiche form.
U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Washington. DC 20234 POSTAGE AND FEES PAID

U.S. DEPARTMENT OF COMMERCE

COM-215

OFFICIAL BUSINESS

Penalty for Private Use. $300

THIRD CLASS