1.01 The purpose of the Preliminary Design Phase
is to develop the overall architecture of the

system and to produce specifications reflecting the
logical view of the system.

1.02 Whenever this section is reissued, the rea-
son(s) for reissue will be included in this para-
graph.

1.03 This section is a guideline. It provides ex-
panded information in support of the concepts

of Total System Development specified in Section
007-220-300*, Total System Development - Mile-
stones.

1 .04 During Preliminary Design, the system model
selected at the completion of the Feasibility

Phase must be reevaluated to determine if that ap-
proach is still valid and can be satisfied by the system
requirements developed during Definition Phase.
Also, the reasonable architectural options must be
examined in terms of their technical, operational,
and economic feasibility. Once a generalized archi-
tectural approach has been established, the design of
the system must be developed. Also during this de-
* Check Divisional Index 007 for availability.

sign activity, system control features and perfor-
mance and reliability requirements must be
integrated into the total system design.

1 .05 During this phase, the strategies and require-
ments for system test and conversion should

be established. Typically, the selected conversion
strategy will influence selection of a specific test
strategy. For example, a flash cut of the entire sys-
tem would require that each portion of the system be
fully tested before conversion. On the other hand,
sequential conversion of subsystems or system ver-
sions would dictate a phase and cumulative test
strategy. Because of the high interrelation between
the system test and conversion functions, planning
for the two should be a coordinated effort.

1.06 Throughout the Preliminary Design process,
decisions will be made concerning the re-
sources required to perform specific system functions
or sets of functions. As the functional or logical de-
sign is firmed up, the total resource requirements for
the system must be determined for both conversion
and on-going operation. Requirements should be de-
veloped for personnel, equipment, facilities, trans-
portation, hardware, software, and the
communications network. As these requirements are
prepared, they should be reviewed with each appro-
priate planning and/or support organization to as-
sure resource availability and conformance to
organizational resource plans.

1.07 By the end of the Preliminary Design, there
will be sufficient information to develop a rea-
sonably precise view of the costs and benefits of the
new system. Development and conversion costs, oper-
ational expenses, anticipated maintenance costs, and
the magnitude of system benefits should be
recalculated. Significant differences (10 to 15 per-
cent) from Feasibility Phase estimates should be ex-
amined and the reasons for the increase(s) or
decrease(s) identified.

1.08 The composition of the project team for the
Preliminary Design Phase is critical to pro-

ducing an effective system design. Depending upon
the type(s) of system architecture that is to be em-
ployed, a variety of expertise may be required — per-
sonnel subsystem and human performance, computer
subsystem, data base, data communications, soft-
ware, hardware, etc. For large projects or for projects
with heavy technical involvement in any of these
areas, it is usually advisable to have technical experts
actually assigned as project personnel. Where techni-
cal demands are not so great, it may be possible to
obtain part-time assistance from technical support
groups.

1 .09 It is important that all project personnel work
as a team throughout the Preliminary Design

Phase. The selection of a system architecture and the
development of an optimum system design will re-
quire a great number of technical decisions and
trade-offs utilizing inputs from each of the specialty
areas represented on the team, eg, PSS, CSS, data
base, and data communications. This interdisciplin-
ary approach to design is beneficial throughout the
system process. Additionally, every effort should be
made to colocate all project personnel during Prelim-
inary Design in order to foster the decision-making
process and the effective flow of information.

1.10 There should be a high degree of interaction
between the project team and the technical

support and planning groups during Preliminary
Design. The various support groups can provide in-
formation and ideas concerning design alternatives.
In addition, in most companies, the support organiza-
tion is responsible for the actual selection of equip-
ment, software, hardware, etc, based on the total
requirements across projects/applications. Also, the
design of the communications network and data
bases for the system will typically be a support re-
sponsibility based on requirements from the applica-
tion. Because of these shared responsibilities, the
project manager should assure a close day-to-day
working relationship with all affected planning and
support organizations.

1.11 It is important that a design review be held at
the completion of the Preliminary Design

Phase. The review should focus on the operational,
technical, and economical characteristics of the sys-
tem and should typically involve the following orga-
nizations as required:

1.12 The purpose of this design review is to assure
that all facets of the design have been prop-
erly addressed and satisfy the system requirements
and to gain the acceptance, concurrence, and/or ap-
proval of the various organizations that are or will he
involved in the development, installation, or opera-
tion of the new system. Thus, this review point is a
major milestone in the system development process.

2.01 The first step in addressing the design of the
system structure is the review and validation

of the proposed system model. The system require-
ments are then reviewed to determine if they ade-
quately represent the system model. If changes to the
model or requirements are required, they should be
documented.

2.02 Following these reviews, design activities can
proceed. The emphasis at this point is twofold:

(a) To finalize the logical data views into the logi-
cal record, segment, and data base specifica-
tions

(b) To structure the system down to a level of
module and program descriptions for machine

processing; task and work module (position) de-
scriptions for human processing.

2.03 The logical data structure, usually developed
in the Definition Phase, may be presented in

products such as linkage diagrams, entity depen-
dency diagrams, and usage views. Based on this data

information and system functions information from
a high-level flow diagram, the logical record specifi-
cations and segment and data base specifications can
be developed.

2.04 The detailed functional architecture of the
system can be developed in parallel with the

work on the data structure and specifications. Al-
though the architecture is heavily related to the data
structure, there is sufficient information on the
views of the logical data from the Definition Phase
to start identifying the functional architecture for
the system. During this activity, several architecture
options may be identified. In developing these op-
tions, the following influences in addition to the data
structure must be considered:

Each identified architecture option must be evalu-
ated in terms of its feasibility [ie, technical, opera-
tional, and economical feasibility (both
developmental and operational)].

2.05 Identifying the functional architecture op-
tions basically involves the following three

2.06 When allocating the system functions, some
analysis of these functions will be required in

order to clearly identify to which processor, person or
machine the function or subfunction should be allo-
cated. Those functions allocated to people should be
reviewed to determine that the results will be mean-
ingful work for them. Also, allocated functions
should be continually reviewed throughout the de-
sign process to assure the allocation is still appropri-
ate. For example, it may become evident in later

design that the volume of work, accuracy required, or
processing criticality is such that people cannot per-
form effectively or efficiently, and the function
should be reallocated to the machine. Conversely, a
function assigned to the machine may be performed
infrequently, require judgmental decisions, and
could be performed more effectively by people. In this
case, the function should be reallocated to the human
processor.

2.07 Once an architectural option has been selected
(with the functions appropriately allocated),

each function can be further analyzed. The low level
processes identified through this analysis can then be
synthesized into modules and programs for machine
processing or tasks and work modules (positions) for
human processing. During this analysis process, the
data structures and function considerations must be
considered in order to develop an effective design.

2.08 System control and reliability requirements
must be examined to determine the processes

(machine and human) which need to be interwoven
with the transaction oriented functions. The various
areas which require system controls and the means
for providing such controls will determine the control
processes to be designed and integrated into the over-
all system design. The processes to satisfy reliability
requirements also must be designed and integrated
into the overall design. The design of these two sets
of processes will be influenced by the architectural
option selected and must also consider the data and
function structures.

3.01 At this point in Preliminary Design, enough is
known about the system requirements; system

functions; personnel requirements; hardware, soft-
ware, and equipment requirements; and the system
schedule to develop the initial system test and con-
version strategies. Both of these strategies are de-
pendent on the nature of the system that has been
designed and both can be influenced by the dictates
of the other strategies (ie, testing can be influenced
by the conversion strategy or vice versa).

3.02 For testing, an overall system test plan for
dynamic testing will be developed and re-
viewed. This plan will include general test objectives,
testing environment (verification, validation, and
certification) for each level of testing (unit, integra-
tion, and system), strategies and techniques to be

used, testing schedule, resource estimates for testing,
and test data base requirements. This overall test
plan should be reviewed and evaluated. Once the plan
is accepted, specific test plans will be developed in the
Detail Design Phase for the PSS and CSS units, inte-
gration, system, conversion, and acceptance testing.

3.03 Static testing of phase products will be
planned and conducted using techniques such

as desk top reviews, peer reviews, andwalk-throughs.
Although each phase of TSD will include these types
of product reviews, they are especially important
during Preliminary Design because of the develop-
ment of the overall test plan. During these product
reviews, an objective is to ensure the design specifica-
tions contain specific and measurable criteria for
unambiguous testing because these specifications
will be the basis for developing the overall test plan.

3.04 Another factor to consider in developing the
overall test plan is the selected conversion

strategy. Different strategies may require adjust-
ments to various aspects of the test plan such as the
schedule, resources, test cases, and test data base.

3.05 As previously noted, the selection of an appro-
priate conversion strategy is done at this point

as a part of the initial view of conversion require-
ments. The specifics for the conversion plan will be
developed in Detail Design based on these conversion
requirements.

3.06 The data conversion considerations developed
in the Definition Phase should be reviewed

and updated if required. This information plus
knowledge of the system architecture and data struc-
tures will be used to select a conversion strategy (eg,
a phased conversion or flash cutover), and to identify
if conversion can be accomplished using the system
functions or if special conversion functions must be
designed or a conversion subsystem is needed.

3.07 Other factors to consider in developing the
conversion strategy and requirements are the

impact on the business operations during conversion,
such as reorganization in user work units, special
training requirements for conversion procedures,
and resource requirements (eg, unique or special
hardware or software and personnel requirements
for conversion).

4.01 With the basic design of the system available,
a more definite set of physical resource re-

quirements can now be determined. These resource
requirements should address the following as appro-
priate for the system:

These resource requirements must include both con-
version and operational needs. In many cases, the
same resources will be used for both conversion and
daily operations. However, when special or addi-
tional resources are required for conversion, they
must be clearly highlighted, and the length of time
they will be required should be identified.

4.02 The cost analysis of these resource require-
ments are discussed in Part 5, Refined Eco-
nomic Analysis. However, when special or additional
conversion resources are required, their potential
costs should be reviewed in conjunction with the
length of time they will be required based on the con-
version strategy selected. If potential costs are high
for these resources, it would be appropriate to exam-
ine the entire proposed conversion process to deter-
mine if adjustments can be made to reduce these
costs. Although conversion costs are not on-going,
they can be a major expenditure when bringing in a
new system.

4.03 Each of the seven potential resource require-
ments must be defined based on the design of

the system at this point in the development cycle and
the system requirements with any updates incorpo-
rated during this phase. As the various resource re-
quirements are defined, the current set of
assumptions and constraints must be reviewed to
determine if there are any conflicts. If conflicts are
found, they must be resolved by clearing or rewriting
assumptions, negotiating changes to constraints, or
making adjustments to the design. This may require
obtaining agreement to changes in the system re-
quirements.

4.04 Various modeling, simulation, and quantitive
analysis techniques are available to assist in

determining each type of resource requirement. The
selection of techniques to use is influenced by a num-
ber of factors:

(e) Skill and knowledge of project members in
using a specific technique or availability of

4.05 As the various resource requirements are pre-
pared, they should be reviewed with each ap-
propriate planning and/or support organization to
assure resource availability and conformance to or-
ganizational resource plans. If the required resources
are not available or are not in comformance with re-
source plans, then adjustments must be negotiated
either to the plans to provide for the resources or to
the system under development.

5.01 At this point in the development cycle, the
economic analyses prepared in the Feasibility

Phase are reviewed and refined but only for the sys-
tem alternative being developed. The same economic
analyses and method of calculation used during feasi-
bility should be used again at this point to assure a
common basis for comparing any variances in the
results. If additional analyses are deemed useful,
they should be prepared. However, if additional anal-
yses are prepared, those results which are
recalculations of the Feasibility analyses should be
clearly indicated.

5.02 The cost and benefit calculations may still be
presented in ranges; however, the difference

between the low and high ends of a range calculated
during Preliminary Design should be less than calcu-
lated during Feasibility. With more specifics known
about the system during this phase, the refined eco-
nomic analyses results should be more precise.

5.03 The refined economic analyses results should
be compared with the same calculations pre-
pared during Feasibility. Any results which differs

significantly (10 to 15 percent) from the Feasibility
estimates should be examined, and the reasons iden-
tified for the increase(s) or decrease(s).

6.01 During this phase, various types of product
reviews should have been conducted. However,

a final review of the overall system preliminary de-
sign should be conducted at this point to assure logi-
cal continuity and completeness of design based on a
comparison with the system requirements produced
in the Definition Phase and any updates to it. Testing
and conversion information, resource requirements,
and refined ecomonic analyses results should also be
included in this end-of-phase review. This review will
typically involve such groups as users, support ap-
proval, operation, or any other group that will be
impacted by the system or that can contribute tech-
nical or subject matter expertise to the review.

6.03 The status and recommendations plus other
supporting information required by the ap-
propriate project approval entity are submitted to
that group to obtain authorization to proceed. The
project approval entity should evaluate the project in
the following ways:

(a) Compare the refined economic analysis with
the economic results from the Feasibility

(b) Determine if the business goals and objectives
addressed by the system are still viable and

7.01 The following sections will provide additional
information relevant to the Preliminary De-
sign Phase:

Total System Development / Preliminary Design Phase Guidelines


1.01 The primary objectives to be satisfied during
the Detail Design Phase are:

(b) Produce the detailed specifications that are
required to construct the system.

1.02 Whenever this section is reissued, the rea-
son(s) for reissue will be included in this para-
graph.

1.03 This section is a guideline. It provides ex-
panded information in support of the concepts

of Total System Development specified in Section
007-220-300*, Total System Development - Mile-
stones.

1.04 Many of the activities within this phase are
interactive. Because major activities may be

assigned to several groups of people, each designer or
design group must be sure to identify all critical de-
sign interfaces and monitor the progress of individu-
als responsible for related system modules. The
design of a module may also be affected by decisions
made in performing activities later in the phase. For
these reasons, the designer may find the design or at
least the specification of a module may not be
finalized until near the end of the phase.

1 .05 Although they are not highlighted as a sepa-
rate activity because they are embedded in the

system design, such things as error control, system
controls and examination, reliability, and recovery
must be considered throughout the Detail Design
Phase. ■ ■ :-.,. ;-,;;_ .•

1 .06 It is recognized that some detail design activi-
ties may actually be performed by support

organizations; for example, physical data base de-
sign, data communications specification, facility
planning, etc. Each project must determine its spe-
cific responsibility for each of these design functions
and provide a means for overall coordination of the
design effort. , ,. > ,.,,,; . : ..^ruy,:r:

1 .07 Control of change during this phase is critical.
The design change requests that are received

during this phase and the next will usually impact
either the system design, the system development
schedule, or both. In order to properly control such
changes, procedures to document, evaluate, put in
order of priority, and determine the disposition of
each design change request must be strictly followed.

2.01 Procedures must be developed for all of the
work modules and functions of the system.

2.02 Tasks within each work module or function
must be analyzed to determine the complete,

detailed processing requirements. This may involve
breaking each task down into further levels of detail
until all required activities for accomplishing the
tasks have been identified.

2.03 The designer must also analyze each task and
step to determine the conditions under which

malfunctions or errors are likely to occur. The objec-
tive of this analysis is to identify each possible error
condition; determine how frequently it is likely to
occur; and decide how to prevent, minimize, or cor-
rect such occurrences. If there is no way to prevent
certain types of contingencies, it may be necessary to
design corrective procedures to handle these prob-
lems.

2.04 The resulting procedure should optimize both
processing flow and human performance. The

processing sequence should be logical and efficient.
All decision points should be clearly identified and all
subsequent processing steps specified. Control steps
should be provided as necessary to avoid unnecessary
or incorrect processing. Whenever possible, feedback
mechanisms should be provided to inform the opera-
tor of how well the function is being performed.

2.05 Once each manual procedure has been devel-
oped, the designer should determine the need

for exhibits, decision or statement tables, perfor-
mance aids, forms, reference materials, or other tools

2.06 When forms are to be used in the work mod-
ule, each form should be designed and a speci-
fication prepared, stating: ' • ' ■ ■

When forms are to be stored in manual files, the con-
tent, organization, and physical attributes of the file
must be determined.

2.07 Some work modules require unique equip-
ment, furniture, or facilities. Such special

work station requirements must be identified and
reflected in the development of the manual proce-
dures. This is particularly important for Visual Dis-
play Terminal (VDT) or equipment positions as these
mechanisms may have special capabilities or restric-
tions on usage. , . ^

2.08 Once the procedures, forms, files, and facili-
ties have been designed, the means by which

each procedure will be documented must be decided.
All procedures should be documented, both to prop-
erly communicate required operating methods and to
provide for system integrity, auditability, and con-
trol. However, the means selected for this documen-
tation may vary depending upon system
requirements. Procedures may be captured in:

The designer must select the best means of documen-
tation in light of user requirements, the nature of the

procedure itself, on-the-job usage of the product, and
document maintenance considerations.

2.09 Section 007-230-210, System Deliverable Doc-
umentation, provides content and packaging
specifications for documentation delivered with a
centrally developed system.

3.01 At this point in the Detail Design Phase, the
detailed logic procedures for each program or

module must be developed. Potential techniques to be
utilized include detailed functional analysis, stepwise
refinement, use of a program definition language,
flowcharts, and structure charts.

3.02 Although largely independent of the program-
ming language that will be used for implemen-
tation, the design should take the capabilities and
limitations of the language used into consideration.
The limitations in particular may require
restructuring the functions of a program or module
so they coincide with a physical structure that can be
implemented in the language.

3.03 At this point, the designer must specify any
messages or codes that may be produced by

3.04 It is also critical that the designer determine
how each module is to be implemented. The

designer must specify any interfaces explicitly and
design the internal data structures that will be used
by the module.

4.01 Detailed specifications must be developed at
this time for all the data and physical struc-
tures used by the mechanized portion of the system.
These specifications will serve as documentation of
the system and should provide a vehicle to ensure
system integrity, auditability, control, and mainte-
nance.

4.02 Kach data group and element should be as-
signed a unique identifier or alias that will be

used in programs that refers to data. The designer
must analyze each use of a group or element to deter-
mine the best formats (including length and data
type) for storage and display, taking into account

space requirements, the need for conversion, efficien-
cy, versatility, and readability. Specific codes, includ-
ing record type designators, should be assigned to all
applicable elements. ,

4.03 The physical layout of each record or segment
must be designed now so the precise record

4.04 The organization and use of each file that will
not reside under a data base management sys-
tem must also be specified.

4.05 The design of the physical data bases must be
completed. The designer must select the spe-
cific data base physical structures and internal ac-
cess methods that will be used to store and retrieve
the data. The designer must also provide for data se-
curity and recoverability of the data base as required
by the Preliminary Design specifications.

5.01 In performing this activity, designers must
consider how their data requirements fit into

the overall company network. Much money and re-
sources can be wasted if the characteristics of the
corporate environment are overlooked. Therefore,
the proposed network design should be reviewed with
Planning, Technical Support, Computer Operations,
and Marketing to assure proper compatibility and
completeness. • •' -

5.02 If an existing corporate communications net-
work specification does not meet the needs for

this system, a new data network specification must
be prepared. A data network specification must in-
clude all the elements of the data system. In addition
to the communication lines, the designer also must
consider who is communicating, what is being trans-
mitted and where, the type of transmission, telepro-
cessing software packages and access methods,
network speed, control, security, backup and recov-
ery.

5.03 The capabilities and services to be provided by
the application system will definitely influ-
ence the decisions made by the network designer. For
example, line selection, terminals, and response
times will vary depending on whether the application
is batch, inquiry/response, message switching, data
entry, or data collection. A further consideration is
whether or not the network will use on-line, off-line,
or interactive processing. . ^

5.04 In planning a data communications system
the following seven basic factors should be
considered:

(a) Function: The designer should carefully re-
view and/or further define the overall objec-
tives of the teleprocessing system in terms of the
functions it must perform.

(b) Distribution: The designer must identify all
locations to be served by the network. The lo-
cations may be within the same building or in sep-
arate buildings, at short or long distances. Once
the locations and the required functions are
known, lines and terminals can he considered. The
line selected could be dial up or private, switched
half duplex or full duplex. Also to be considered is
the pattern of flow, in terms of who receives and
who transmits.

(c) Volume: Next, the amount of information to
be communicated should be determined. Ana-
lyze both the number and length of messages, as
well as peak volumes and potential growth. When
estimating the probable volumes, retransmission
requirements resulting from line or operational
errors must also be considered.

(d) Urgency: Closely associated with volumes is
the need to know when the information is

available for transmission, when it is required,
and what response times are allowable. Speed of
transmission will be dependent upon the types of
media, terminals, and lines used. Backup, recov-
ery, and equipment or hardware availability (up^
time) will also require consideration in the net-
work design.

(e) Language: The language required by the
user (the data and programs) is another im-
portant consideration. In this respect, particular
software or hardware and conversion or interface
requirements may have to be met. In addition,
human performance characteristics should be con-
sidered in the design of the human/machine inter-
face, input coding, output interpretation, etc.

(f) Accuracy: The designer must consider the
performance aspect of the teleprocessing net-
work. The requirements set for transmission accu-
racy are critical to the selection of the proper
physical components of the communication sys-
tem. In addition, the teleprocessing software facil-
ities for editing, checking, balancing, and data
correction must be compared to the actual func-
tional requirements of the application system.

(g) Cost: After weighing all of the factors above,
the designer must evaluate the cost of the net-
work that has been designed. Trade-offs may be
necessary, based on what is required and provided
versus how much it costs and how much is avail-
able, with particular attention paid to the true
value of the total system.

5.05 The communication network specification
should define the configuration and compo-
nents of the network, the data to be shared via the
network with other systems, network utilization and
performance requirements, and any special proce-
dures for network operation.

6.0 1 Once work module and/or work station design
has been completed, all equipment require-
ments should be fully detailed. Specific types and
quantities of equipment items will have been deter-
mined and vendor negotiations initiated.

6.02 Any requests for equipment modification or
redesign to be done by the vendor must be

specified so these requirements may be stated in the
contract agreement. The same is true for any special
work that will be done withfn the eompany or by a
local contractor.

6.03 An equipment specification should be devel-
oped for each equipment item that will be used

with the system. The specification should include a
general description of the item, any required modifi-
cations, delivery and test requirements, maintenance
characteristics, installation locations, quantity, and
cost. This specification will serve as a useful checklist
during system test and conversion. Therefore, all ac-
tivities that must be performed to obtain the equip-
ment and assure that it is operational should be
included in the specification.

6.04 The term "facilities" refers to the total physi-
cal space that will be occupied by the person-
nel and machine components of the system. The
facilities requirements should include the amount of
space, the physical location, and the environmental
characteristics of the facility allotted to each compo-
nent of the system.

6.05 In most cases, planning or engineering will be
involved in the detailed planning of machine

facilities. However, the facilities requirements are
critical to assuring that the actual physical facilities
will properly support the operational system. For

machine facilities, the following factors should be
considered in preparing the requirement:

6.06 If the facility is to be occupied by personnel,
the following factors should be considered:

6.07 The final descisions concerning these types of
work facilities will probably be made by the
user organization. In fact, the facilities requirements
themselves may be developed by the user representa-
tives on the project team. However, if the design deci-
sions and facilities preparation is to be the
responsibility of the user department, the system
designers must identify all the facilities characteris-
tics that will impact overall system performance and
assure that the final design adequately supports sys-
tem operation.

7.01 Once the basic design of the system has been
completed, the hardware and software specifi-
cations can be finalized. This may require revision to
the requirements developed in Preliminary Design or
it may necessitate further detailing of specific fea-
tures or items.

7.02 The hardware requirements developed in Pre-
liminary Design have provided Information

Systems Organization (ISO) Planning with an early
estimate of the resources required for operation of
the new system. When program, data base, and file
designs are complete, the original estimates should
be reviewed using the more detailed specifications
developed during this phase. Estimates of individual
program sizes can be used to validate earlier esti-
mates of module size, device requirements can be
modified as necessary, and the specific content of
records within files can be used to recalculate data
transfer requirements and validate estimated run
times.

7.03 The planning organization will use detail de-
sign estimates to adjust the composite projec-
tion of processing requirements. If any modeling or
simulation of the application was done, those results
should also be forwarded to the planning group. Such
results may aid the planning group in viewing the
total operations environment. This is a critical phase
for planning, because if the resources required by
this system or others are less than previously antici-
pated, a slippage in the equipment installation sched-
ule could be indicated. On the other hand, an increase
in requirements may dictate an accelerated installa-
tion plan, a different machine assignment, or a"
change in the projected system conversion date.

7.04 When the system is to be installed in more
than one location, hardware sizing guidelines

should be developed. The guidelines should define the
various parameters, formulas, and/or processing
options that can be used to estimate resource require-
ments for a given processing site.

7.05 Basic software requirements will probably
remain constant after Preliminary Design.
However, changes in the types of operating control
system, release, or level may affect project plans for
test, conversion, and/or operation. New software or
features announced since the last software evalua-
tion may be of significant benefit to the new system.
Therefore, a review of software needs and the prepa-
ration of a final specification is recommended.

8.01 The total personnel requirement to convert,
operate, and maintain the system must be de-
termined. Personnel estimates should include these
categories:

For each category, the numbers of people, skill levels,
departmental affiliation, time frame needed, etc,
should be specified. If the system is to be installed in
multiple locations, personnel staffing guidelines,
parameters, or formulas may have to be developed.

8.02 If work modules have been grouped into jobs,
either with certainty or as a guideline, each

the work group, personnel and physical require-
ments, administrative requirements, etc.

9.01 Several types of training may be required for
system conversion and/or operation for:

9.02 The designer should consider the specific
training needs of these groups of people as

well as any others whose jobs may be affected by the
new system. The extent of training can be determined
by comparing the existing skill&and knowledge of the
people to the skills and knowledge they will need in
order to operate and manage the new system. The
basis for training then becomes those new capabili-
ties that personnel will have to develop. For each per-
sonnel category, and for most jobs within a category,
a specific training package will be identified.

9.03 Obviously, not all training packages will have
to be developed from scratch. In some cases

there may be existing course materials that will
serve perfectly well with some modification and/or
additions. The designer should review current train-
ing packages and determine where development time
might be save through minor revision to existing
courses.

9.04 The designer should also determine the num-
ber of people who will require each type of

training. The amount of time spent on the develop-
ment of a specific training package will depend to a
large degree on the number of people who will use it.

9.05 For each training package, whether for formal
or informal instruction, the designer should

determine what the people should know or be able to
do by the time they complete their training. Those
things they will need to know or do become the basis
for establishing course objectives.

9.06 Course objectives should be stated so they can
be measured in terms of the trainee's actual

performance. Objectives that cannot be measured are
of doubtful value for inclusion in the course specifica-
tion. The setting of course objectives is important in
assuring that all required topics are included in the
course specification.

9.07 The course objectives will help the designer to
decide on the best training method to use.

Examples of training methods are seminars, lectures,
programmed instruction, computer aided instruc-
tion, w^orkshops, etc. The selection of the proper in-
struction method depends greatly on the content of
the course, the number of students predicted, the
skill of the developer, the time available for develop-
ment or instruction, and the materials and equip-
ment available.

9.08 With a method selected, the designer can de-
termine how the course should be presented.

The course could be taught in one continuous session
or broken up into segments or modules that address
specific aspects of the course content. The duration
of the training sessions are determined by the type
of training being given, the method of instruction,
and the number and location of the people being
trained. Judgment and common sense are perhaps
the best guides in making this determination.

9.09 The materials required for the training pack-
age must be identified. Examples of training

materials are instructor guides, student workbooks,
handouts, audio and video tapes, slides, exercises and
case problems, quizzes, student and course evaluation
fbrrtis, etc. In addition to these materials, the deliver-
able user documentation may be used extensively in
the training environment. Such documents as user
manuals, administrative guides, work module in-
structions, performance aids, and forms can all be
effectively used in the classroom. Any document that
will be used on the job should be introduced and re-
viewed in the training session.

lO.OT In preparation for the testing activities in
the Implementation and Conversion Phases,
detailed test plans for the following three levels of
testing must be prepared:

(a) Unit testing examines each discrete compo-
nent (module, program, work module or proce-
dure) of the system.

(b) Integration testing examines how each com-
ponent of the system interacts with each other

as they are assembled in a stepwise manner. This
testing concentrates on chained programs or work
modules and human/machine interfaces.

(c) System testing examines the operation of all
components of the system as a whole, accord-
ing to its system requirements and performance
criteria.

10.02 As test plans for each level of testing detail
are developed, the following testing strate-
gies, based primarily on environment, should be con-
sidered:

(a) Verification examines the logical correctness
of each component (module, program, work

module, developmental component, or procedure),
either individually or together, using controlled
data in a test environment.

(b) Validation examines the logical correctness of
the system using controlled data in the operat-
ing environment or one that approximates the op-
erating environment as closely as possible.

(c) Certification examines the performance, qual-
ity, and reliability of the system to ensure that

the system meets its objectives and its perfor-
mance requirements. This type of testing is con-
ducted in the actual operating environment using
real data. Certification emphasizes tlie perfor-
mance aspect (eg, volume, response time, fallback,
and recovery, etc) of the system rather than the
logical correctness of the system.

10.03 Acceptance testing is conducted as an exten-
sion of system testing and completes certifi-
cation testing. It is performed by or on behalf of those
who will use and operate the system to ensure the
user's needs are met. It must be performed as a condi-
tion of acceptance by organizations installing a Cen-
trally Developed System (CDS). The Project Manager
will coordinate acceptance testing requirements with
the recipients of the CDS.

10.04 For each specific test, a test design is pre-
pared outlining objectives, techniques, me-
dia, expected results, resources, and schedules.

10.05 The design and creation of a test data base is
also a major testing activity in this phase.

10.06 A test status report system should also be
established to provide the Project Manager
with an effective means to observe and control the
test activity.

1 1 .01 Although primary system performance spec-
ifications are established early in develop-
ment, the specific means by which these objectives
will be met are reflected in the detailed specifications
of each of the system components. Because of the vol-
ume of such specifications, it is desirable to provide
a summary of the overall performance attributes of
the system as seen at the end of design.

11.02 The following information should be pro-
vided in the performance specification:

(b) Processing performance criteria (accuracy,
throughput, resource utilization, etc)

measures have been taken to assure that perfor-
mance level, and the means by which system perfor-
mance can be measured in the operational
environment.

12.01 The conversion plan should include all
preconversion activities, a description of
each step in the conversion process, and a conversion
schedule. The schedule should indicate the start and
completion date for all activities, personnel assign-
ments by name, both project and user personnel, and
dependencies on nonproject events. It is of critical

importance that the project personnel and the users
agree on the conversion plan, including the commit-
ment to provide personnel as identified on the con-
version schedule. ■

12.02 Since, in some cases, conversion may follow
the completion of the Detail Design Phase by

only a few weeks, the preparation of the converison
plan has been included as a Detail Design activity. It
is recognized, however, that for larger projects the
Implementation Phase may last up to a year or lon-
ger. Under those circumstances, some of the detailed
decisions, actual personnel assignments, and the de-
termination of schedule dates will be postponed until
sometime during the Implementation Phase when
they can be established with a greater degree of cer-
tainty.

12.03 The conversion plan and schedule encompass
a number of activities that affect both the

developer and the user. While those activities are
very dependent upon the project, the characteristics
of the system, and the conversion approach, there are
a number of items which should be considered by any
project. They are:

(a) Personnel staffing (schedules, method of han-
dling displacements or acquisitions, etc)

For each conversion activity, the schedule and person
or organization responsible should be identified.

12.04 For central developers, the conversion plan
must include all those activities required for

system installation and development of any interface
functions. This information will be contained in the
Installation Planning Guide that is delivered to the

12.05 Once the detailed plan for conversion is com-
pleted, conversion costs and resources should
be reviewed. Any significant deviations from the
original estimates should be reviewed with affected
organizations.

13.01 For most projects, a Detail Design review is
desirable or required. However, most of the

documentation produced during this phase is fairly
detailed and technical. For these reasons,
modularized design reviews of the system may be
required.

13.02 Within the project, it may be desirable to
conduct walk-tbrougbs to determine the

adequacy of individual design specifications. One or
more development groups may be involved in this
process.

13.03 Technical design reviews may also be con-
ducted to evaluate certain subsystems within

the total system. Technical support, planning, opera-
tions, or the user may participate in these subsystem
reviews.

13.04 A nontechnical system design review with
special emphasis on operational procedures,

schedules, controls, reports, forms, etc, may be held
with user representatives.

13.05 Whatever design review procedures are se-
lected, the amount of information, technical

content, and level of detail should be appropriate for
the reviewer's area of interest and technical exper-
tise.

14.01 The following sections will provide addi-
tional information relevant to the Detail
Design Phase:

Total System Development / Detail Design Phase Guidelines