The purpose of this stage is to transform the complete design into executable manual jobs and computer programs which mat be tested. The process of synthesizing procedural practices into job descriptions can occur independently of the program developmental effort and has no necessary precedence. This stage should be used as a guide for the programmer, the person responsible for defining manual jobs, and for the manager of such personnel. It should be used as a checklist for activities that must be performed, accompanied by some guidance on possible methods for solving those activities. There are no flowcharting, coding standards, etc., as these do not conform to the purpose of this manual. Only in very rare cases would any activity described here be considered as being optional

In many system development efforts, the development of the manual portion of the subsystem is overlooked and ignored in the shadow of the programming effort. This is a serious oversight because computer programs can only be as effective as the manual processing which they support.

It is generally true that the most normal cause of automated system failure can be traced to the man/machine interface points of the system, and, therefore, this area requires extreme care. Only in special cases where there is very little manual interface to the system, to where this is very specialized (such as for engineers using conventional FORTRAN), may the manual process be downgraded.

This stage covers the process of verifying the program specifications produced in Detail Design, producing coding diagrams, coding the programs, compiling and desk checking the programs, and, finally, debugging the programs to the point at which they may be turned over to those responsible for systems testing. This process will involve several people with normally one person having the primary responsibility. The other people will assist him and review his work.

The techniques of structured programming mentioned in 3.6 may be used. They will not be effected unless the structured programming approach was used at the detailed design level. Considerable training is required in order that programmers can fully utilize such techniques. In many cases structured programming may only be used in a modified form for various reasons including the limitations of the programming languages used. In any case, common sense should be used to guide the way in which structured programming is to be implemented.

The major concern in programming is that it be accomplished efficiently and yet thoroughly. Any good means of saving programming time, such, as automatic coding, program generation, desk debugging, flowcharting, and documentation aids should be considered and applied wherever possible.

Special care is called for in the case of multi-programming and multiprocessing due to the increased complexity of the programming effort. This is also true of programming for communications systems.

Before actually starting program development, it is advisable to check the completeness and clarity of the program specification in order to lessen repetitive efforts due to later additions and changes.

Distinction should be made between control and processing module flowcharts. The control flowcharts forms part of the program definition and facilitates the logical division of the complete program into modular parts. These parts consist of routines and subroutines (processing logic) for which detailed flowcharts are prepared as required. Then routines and subroutines are then written in a modular fashion; each part constructed so that it is as independent as possible, allowing for program segmentation.

Advantages of this modular arrangement are that:

The activities included in this stage are for a large-scale system effort; for smaller efforts, some may be combined or omitted. In this event, all activities not conducted should be noted by memorandum (including in the Project File) accompanied by reasons for omission. Activities included in development are to:

The specific products developed by these activities, and included in the Project File are:

In this activity, the procedures developed in Detail Design are grouped into position descriptions for personnel. A position or job is defined as the workload (in terms of procedures) assigned to one man in the proposed system. There may be one or more procedures involved in one personnel position description, or one procedure may be divided into several positions, depending on the size and complexity of the procedures. The grouping of procedures should be along logical, functional lines; that is, personnel should not be expected to accomplish too many varied procedures, especially if they require different hardware, work aids, computer interfaces, skills, or locations. The more complex the procedures, the more this becomes true. These procedures include those relevant to conversion.

Included in these position descriptions are expected levels of job performance. These standards must be defined in such a way as to render them objectively measurable in the light of administrative requirements. They also have an important bearing on the design of training, and are used in developing job performance assessment procedures. The performance standards will relate directly to the methods of quality and quantity control devised for the subsystem. The weighing of the various standards will differ somewhat from position to position for the reason that throughput is most important in some cases, while, in others, accuracy of output is most important.

Important components of performance standards are:

Each worker must be assessed continuously with respect to quantity and quality of work produced. In the present activity, procedures are also developed for measuring performance in accordance with the performance standards. This may include not only development and validation of work sample measures, supervisor rating forms, and other manual procedures, but also the development of computer logic to automatically assess performance.

The performance standards will be used to make projections of the numbers and types of personnel needed. Whenever possible, they should be written so that the effects of trade-off between numbers and skill or experience level can be easily make. Thus, the throughput of an experienced keyboard operator may be twice that of a person who has only recently been trained. It is important that the standards be realistic so that the staffing projections will have a minimum amount of change when the standards are revised.

The total package that would constitute a job specification for an employee would include:

In this activity, initial estimates are made of the types and numbers of personnel required by the system. The numbers required will be considerably more tentative at this stage than the corresponding estimates of skill, knowledge, and aptitude requirements. The former estimates depend on a accurate operating statistics, such as volumes, frequencies, and peaks, where the latter can be developed in large measure through reference to Procedural Practices and Personnel Position Descriptions.

The Personnel Position Descriptions are analyzed and detailed lists are developed of skill and knowledge requirements for each job. Training and/or recruiting programs will be established from these lists; therefore, attention to detail is important.

The initial estimates involve combining the expected volume of work with personnel performance standards; errors in either can lead to staffing problems. The estimates should be based on a time-phased basis, and not on the final totals expected. The transfer of personnel from positions which will later be eliminated should be included in the estimates. The additional personnel requirements for the conversion and implementation period must be considered, in addition to the personnel who will be required for normal system operation. Based on the numbers of personnel required and there associated skills and knowledge, the needs for training, personnel selection, and work aids are developed.

Training and personnel selection are closely related activities. If skilled and experience personnel are selected, the training costs and requirements will be much less; however, in many cases:

Training requirements will tend to fall into three broad categories:

The training plan must establish the requirements in all areas and state how these requirements are to be met. The plan will have to recognize both short and long range training requirements.

Potential types of training available are:

These may be used separately, or in combination, depending on the particular requirements. As training courses require time to develop and test, the activity must be begin as soon as possible after the need is identified. Sources for training courses and materials are:

The training program should be built as an integrated whole. Probably some training will be done in-house, and some from outside. Training is a recurring activity that will extend throughout the life of both the system and the individual.

A training specification should be built around the "behavioral objectives" that can be determined. These

objectives should be as specific and measurable as possible and be directly related to the task the trainee is to perform upon completion of training. The measure of a training program is not how well trainees do on tests but how well they perform after completion of training.

Not all personnel who are satisfactory performers are adequate teachers. On-the-job training should be carefully controlled and have a syllabus and behavioral objectives similar to those of any other course of instruction.

Selection of personnel within the company has certain advantages:

In selecting personnel, one has to be able to discover those who are:

The determination of capability is a difficult problem and requires a full understanding of the requirements of a position. Too often the selection criteria overqualified for a position, resulting in dissatisfied employees. Some ways of assessing capabilities are by:

Aptitude tests can never be the sole criterion for selection. They are merely indicative and do not measure such critical factors as initiative, perseverance, etc.. In addition, only a few positions have aptitude tests which achieve any reasonable measure of reliability. Personnel resumes and other employment records are apt to be inflated and must be treated with care. Usually it is easier to evaluate the employment record of a person within the company as against someone hired from outside. Previous training, including university, is an indicator but it may only prove the person t be a good student, not necessarily a good worker, and vice versa. Interviews can be quite useful if they are conducted by a person qualified both as an interviewer and in regard to the position to be filled. If the interviewer does not understand the position, he cannot ask the right questions or evaluate the replies. Recommendations also must be carefully evaluated. The more specific they are, and the more confidence that is to be placed in the person who wrote them, then the more valuable they are. Thus, determination of capability is a difficult and time consuming task that should not be sighted.

A recruiting program within the company can be initiated by general announcements and requests to supervisors and others for the names of prospective personnel. In both cases, positive inducements will usually have to be offered to supervisors if they are to release and/or recommend good personnel rather than try to remove "deadwood" from their section. The announcement should be clear as to:

Recruiting from outside the company be done by:

Some, or all, of these methods may be used singly or in combinations. The personal contacts of employees within the organization should be utilized, since they may know people who are qualified. In all cases, time delays must be expected in order to:

Necessary work aids for defining the training requirements for the positions should be described. Work aids infer any aid that is available to the person during the course of her performance of an assigned task. This may be a document, mechanical device, or a specifically designed device for the improvement of task performance.

In addition, detailed human engineering specifications are prepared for those system operations which require the presence of people. Too, often, the environment in which people work has a negative effect on their performance. It is better to adjust the environment to human needs rather than force people to attempt to adjust to the environment. The majority of people operate best within a rather narrow range of conditions as regards temperature, sound, etc., and exposure beyond those ranges can bring a lower performance.

In many cases the facilities, environmental control, etc., are in existence and cannot readily be modified. If they do not meet the requirements, then the cost of altering them should be related to the cost of degraded performance by having to operate in an unsatisfactory environment. The goal is to create an environment which will reduce human errors and not create irritation and frustration. In some cases, very minor corrections can drastically improve worker productivity.

These requirements are considered here only insofar as they impose environmental constraints. In some cases, the needs for equipment are more severe than those for people and can impose constraints, such as a ban on smoking in computer rooms.

(To Be Supplied)

A detailed flowchart will approximate the instruction level and be complete enough to guide the coder in the performance of his task. Although each block does not have to represent an instruction, certain blocks should never be combined with other blocks; i.e., decision, input/output, or pre-defined processes.

All the rules which apply to program logic flowcharting apply to this activity, but at a more detailed level.

There is certain software available which can be of assistance to the programmer; one type comprises sets of programs which generate flowcharts from special input cards. Such charting programs have the disadvantage of manually prepared flowcharts. The other type of charting program is that which accepts source deck as input and produces flowcharts ( and frequently some level of logic analysis as output). This type of flowcharting cannot be used initially, but, if the final flowcharts are to be made in this way, then the initial flowcharts can concentrate upon program logic rather than on the neatness, etc., of the drawings, as they will not form part of the final product. Furthermore, it is easier to update computer-produced flowcharts as the new deck can be flowcharted without the manual re-drafting of many sheets.

After preparation of the detailed flowcharts, both these, and the higher level logic flowcharts, should be thoroughly checked prior to coding. Such checking is frequently neglected - lack of time being the standard excuse. However, desk checking of flowcharts is an essential part of flowcharting. Savings resulting from thorough checking are not immediately obvious, but costs of failing to check thoroughly will become all too obvious.

Some advantages of careful desk checking of flowcharts are;

At this point, the assistance of another person is very useful. As much as one may examine one’s own work, complete oversights tend to remain undiscovered. The cases not accounted for in writing the program will probably be those not tested for during the testing process. Another person may perceive oversights directly because of his fresh viewpoint.

In order to fully desk check the flowcharts, it will be necessary to have some test data to use in following through the logic of the program (module). This is the first point at which to prepare test data at a detailed level. As the number of conditions that can be manually checked is limited, this set of test data should be carefully selected.

Coding should not begin until the detailed program flowcharts, HIPO diagrams or other program specification documentation has been completed and checked. The activity of coding these detailed program specifications will provide another validation check of these specifications at an item level, as coding frequently reveals minor flaws in logic. Unfortunately, coding rarely reveals major logic or design errors.

Before commencing, the coder must understand not only which language is to be used but also;

Perhaps the most important control for ensuring good coding is to have a comprehensive and useful set of coding standards within the organization, plus a method for ensuring that these are followed.

It is very important that consistent and effective use be made of notes or comments. Each routine should have at least a brief explanation of what it does. If non-standard solutions or specialized coding techniques are used, they must be careful and fully explained and justified. The coded program with the note or comment statements should be as self-explanatory as possible with reference to no other document.

Immediate optimization should not usually be attempted. Normally, optimization is more effective after successful assembly or compilation, when the machine instructions are known. The exceptions are when core size is known to be critical, when certain routines will be used many times, and when the optimization technique is direct and well understood. An example of the latter is converting an external decimal in the input record to an internal decimal or binary field a the beginning of extensive arithmetical computations. In general, the straightforward coding approach will be the most immediately effective, as well as easing future maintenance and modification efforts. For several languages, optimizing programs are available which can be applied to either source code or object code.

When writing in assembly language, relative addressing should be used with care. Such addressing tends to make the program very difficult to read and understand. Additionally, it is easier to disturb such a scheme when modifications are made than when labels are used. than when labels are used.

Common routines of any type should be coded once and then placed in a special source library from which they may be copied by means of appropriate control cards or terminal commands.

The labels on the routines will reflect those used in the flowcharts. The labeling convention is such that one can proceed backwards from the coding, to the flowchart, to the program descriptions. All subroutine labels will indicate the routine in which they are included. Sequence number all coding.

The data areas to be used in a program should be coded initially. Al I/O and data base work areas should be coded in the item level. Adherence to system-wide labeling conventions is important, as well as the use (where possible) of data areas previously coded as standard throughout the system. As any time when a data file, set, table, or work area is used in more than one program, the coding should be identical in all programs concerned. It is often beneficial to code one standard set of file descriptions and work areas for use in all programs within a subsystem. All data areas should be set to specific initial values.

In coding data areas, particular care must be given to the special requirements of a particular language. Some problems areas are… areas are:

In some languages there is a distinction between global and local variables. Where this facility is available, it should be used to increase the modularity of the program.

The responsibility for the structure and coding of file descriptions may reside in personnel other than those who are coding programs. This function of "data base management" may be very important for control and efficiency within the organization.

The first section of program logic to be coded should be the control module, or root segment. This module will contain other overall logic of the program and determine the sequence of events. It should be strictly modular in concept and consist primarily of a sequence of calls to other logic modules. The calls will be actual software calls to program modules, or merely branches to routines, depending on whether the program is core resident in its entirety or not. The branch would be simple "branches" or "branch and links" in assembly language., or would be ‘PERFORMS’ in COBOL. The program control module should contain no processing logic.

The next coding function is to develop the I/O routines required to service the program, Considerations are:

Whenever possible, the I/O routines should be in the same language as the remainder of the program. However, in some areas, this will not be possible; e.g. where a higher level language cannot read or write to a particular device type, use a certain access method, etc.. some I/O routines will have to be written with great care because of required dependencies; e.g., in S/360 OS COBOL a "BISAM" read requires a "REWRITE". Care should be taken to ensure that all fatal error return codes will be recognized and processed.

Following I/O handling, the remainder of the program logic modules may be coded. The principal point to remember in coding the processing logic is to follow the detailed program specifications exactly. Whenever more efficient or correct coding indicates a variation from the detailed program specification, it must be altered to reflect the variation.

Error handling should be coded separately for four main reasons:

The accuracy and completeness of the transition from coding sheets to punched cards or other media is not entirely the responsibility of keypunch and verifying personnel. Unclear instructions, illegible writing, and us of standards other than those normally used for coding for that department can all lead to errors to errors. Furthermore, the programmer is responsible for checking that all preparation is correctly performed.

Completion of coding to a final, fully prepared source deck can be a time consuming process. to reduce the time required, it is recommended that the programmer submit coding to keypunching in small groups to 20 to 40 sheets at a time. This will impose a more regular requirement on the keypunch and verifying operations. Checking the accuracy of the keypunching operations. checking the accuracy of the keypunching operation will be easier if done in small groups, and corrections can be submitted a errors are detected, so that the final step will involve only the corrections for those sheets. When a large and continuing amount of keypunching is needed, it is useful to notify the keypunch section so that they can schedule the keypunching.

Prior to submission of the source deck for complication, certain control cards must be prepared. Three types of control cards may be involved in compiling:

Most compilers allow a variety of options to be used when compiling. The use of the options may require additional machine time and more output, but with an increase in information available. Each source deck should be examined to determine the appropriate options.

It is necessary that the same operating system and compiler be used for system development as for system operation. It is desirable that it be accomplished on the same machine on which the programs will normally operate.

It is awkward and inefficient to have to load the entire source deck more than once. In the case of programs of great length, the chances of damage to the cards or out-of-sequence conditions increase greatly. Source image libraries should be used if possible. Two of the uses are duplicating sections of code that have been previously created and making corrections with only change cards and control cards. The former is useful when many programs need common routines or identical file descriptions as these can be added to the source deck without having to re-keypunch. The latter allows small correction decks to be used and reduces card handling with its possibilities of errors. Initial source decks, updated with corrections, should be retained for back up at least during development.

The most common type of special purpose programs used at compile time are automatic flowcharting packages which produce flowcharts based on the actual coded program and provide additional information such as cross indexes, diagnostics, etc.. These programs may be used for both analysis and documentation’s.

After each compilation or assembly, the programmer should carefully check the output produced. Some of the sources of errors are found in:

In some cases, in addition to mechanical errors, there may have been misuse of the instruction set or erroneous logic from the program flowcharts.

The computer-provided aids at this stage are generally two:

It is necessary that the programmer should make the maximum use of aids provided to him. Both compilier/assemblers and special purpose programs will provide source listings which can be visually checked. In both cases, sequence numbers will normally be checked on request.

The complier/assembler diagnostic errors should be examined in detail. In many cases, one error can cause others to be generated (e.g., an incorrectly spelled label will cause all instructions using that label in proper spelling to be flagged as an error). The programmer must be careful to ensure that the source of the error has been properly identified as there are cases when the error message can be caused by several conditions.

Warning level error messages should not be suppressed as they can be "fatal" in some cases. It is possible that the condition is intended by the programmer and that the final version of the program will continue to have the warning error messages (e.g., deliberate truncation by moving a longer field into a shorter one).

The compiler option showing object-level coding or object-level data allocations should be used on the first compilation. Such an output is mainly useful for checking the way in which the compiler translates certain critical instructions, alignment of certain data areas or their relative displacement, or the efficiency of the code produced.

Assemblers normally give cross-reference listings as do special purpose programs. The details of these cross-reference listings vary, but, they usually allow one to determine where each name is used and whether some data names are used or not. These listings assist in tracing problems caused by errors in the data names or descriptions. They are also useful for making changes, as the affected instructions are readily identified.

The special purpose programs can produce flowcharts at various levels of detail from the source coding. These can be quite useful in determining whether or not the source code actually reflects the original flowcharts. Sometimes associated diagnostics are provided, such as flagging routines which do not have exits or which cannot be reached.

For reasons similar to those given in the desk checking of flowcharts, it is very useful if another programmer assists in desk checking compilations/assemblies. There is an additional reason in that the other programmer may more readily identify whether the wrong instruction has been used or the instruction improperly formatted.

Two or three compilations (for a short program) should be sufficient to remove all errors detectable by the compiler/assembler or special purpose programs. The length and complexity will affect the number of compilations. Each compilation requires programmer and computer time which becomes irretrievably lost between submission of the compilation and receipt of the results. To ensure maximum efficiency, the results of the compilation must be carefully and thoroughly analyzed. When corrections must be made, particular care should be taken to ensure that new errors are not created when correcting those discovered.

In some cases the program may be keypunched but rather entered via a terminal by the programmer or project librarian. The same degree of care should be taken in preparing the program before entry at a terminal as is done in preparing for keypunching. The use of a terminal can lead to poor programming practices unless very carefully controlled. When proper preparation is done and use care in entry is made, programming and checking via a terminal can increase programmer productivity.

The preparation of program (module) debugging data is primarily the responsibility of the

It is important that the programmer should know the correct output for given input. Some debug data may be prepared that will not be analyzed in detail prior to use: i.e., some output from a test data generator.

There are at least four means of preparing debut data which can be used singly, or in combination:

Branch point analysis (bubble chart) is an especially good tool for ensuring that all routines are completely executed. The purposes of this method is to assist in:

The mechanism involved is to create a branch point analysis chart (bubble chart) describing all the possible paths through the program and noting (as bubbles) all the branch points (with routine names). As this chart is being created, certain errors may be found, such as:

After completion , this chart can be used to assist in the preparation of debug data for the program module. The programmer starts at the beginning of the program and bubble chart and prepares data which forces each branch to be taken. As the data are coded for a particular routine (satisfying all paths through the routine). the bubble for that routine is color coded on the bubble chart. When the chart bas been completely color coded, the programmer knows that every routine has been entered from every routine that can branch to it.

In conjunction with branch point analysis, other means of analysis may be used. The program can be separated into its smaller modules and special conditions coded to test the logic of each small set of instructions, especially data generated by the analysis of the flowcharts during their debugging for some of the detailed program debugging. Program specifications and file descriptions should be reviewed for information to create debug data.

The more complex the file structure, the more careful the analysis of the I/O routines will have to be. Edit routines should be tested for random input information, as well as the standard information they are designed to handle. For instance,, what would happen if gross errors occurred in data input, such as some cards from another input stream being read?

Test data generators can only be used effectively when a careful analysis has taken place. Normally, the analysis is then used to specify the contents of the input parameters which are then prepared as input to the test data generator. The value of the test data generator is that it produces many output records with varying combinations of the parameterized input. However, the output of a test data generator is that it produces may output records with varying combinations of the parameterized input. However, the output of a test data generator will depend upon the quality of its input.

If samples of existing files or inputs are to be used, analysis must still take place. In the case of large files, the sample can only be a small subset of the file in question. Such samples are usually extracted by use of utility programs, and the analysis must ensure that the selected records are a true statistical sample 9 of the file or input in question.

Frequently, debug date will be prepared by some combinations of these techniques. The requirements for different type of programs may make some specific approach more useful than others. Conversion programs, in those file may be as described in the documentation because of errors in the present update programs, or for other reasons (one can sample manual data and transcribe selected records into conversion input, if necessary).

Data at this level are not prepared to test volume capacity or timing features. It is possible that significant timing results will occur as a byproduct for very badly designed procession or I/O routines.

This activity is begun after a completely coded program has been compiled without error and job control is complete. The program may consist of one or more load modules. All possible functions and conditions contained in the program must be checked out, utilizing the branch point analysis chart prepared in the previous activity. He is where the rigorous debugging of an individual program occurs. It is almost impossible for later systems testing and acceptance testing to cover every line of coding in every program, so it is the programmer’s responsibility to ensure that not only will his program stand up under later testing, but also, that it will not fail at some future date during a production run. This is the phase of testing where every instruction within the program is exercised and where the verification of internal consistency within the program is made.

The debugging scheme follow the programming scheme in that it is modular. That is, the testing begins with t he control module and subsequent fashion. However, the program is not normally tested in conjunction with other programs at this stage.

The debug data used are those contrived by the programmer in the previous activity and are not meant to appear "real" so much as being exhaustive. This activity is normally performed by the originating programmer.

If the program is large enough to warrant it, the program module debugging can be performed concurrently with the coding of other modules, thus shortening the total time required to complete a program.

The major points to stress are:

Normally, this activity can be started immediately following the first "clean" compilation. Only dummy files representing those files to be used in production are required.

The first portion of debugging the total program is to ensure that the load modules can be called in and executed properly. Temporary interface coding may be required, such as a branch-to-end right after loading and starting execution. All legal sequences of module (load) calls should be checked to ensure that the proper sequences execute in the same order.

Next to be debugged is the calling in of the software required for I/O processing and the program’s file definitions. When possible, this activity may be performed prior to coding completion of processing (worker) modules. It is important to have the I/O checked in a program before starting to test processing logic, thus avoiding confusing results. Quite often, the majority of the problems encountered in debugging a program center around the I/O. Points to remember are:

Once the I/O processing and control logic are validated, the processing logic modules may be debugged using the ore complete set of data. The most frequent problem here is the failure to recognize and deal with all the error and exception conditions that might occur.

It may be necessary to have special training on debugging techniques and on how to use core dumps to identify problems. Normally one should not have to use the "DUMP" option to identify errors and this option should be used only when necessary as dumps require considerable printing.

Most programming languages have debugging facilities that can be very useful if used with care (they generate extra coding and increase run time). In COBOL there are "EXHIBIT", "TRACE" and similar facilities available which can be very useful to the programmer.

There are packages available which can be used in testing individual programs or modules. These packages provide an environment, within which isolated programs or modules can be tested as if they were in their intended software environment.

What is referred to in this book as "debug programs" is sometimes referred to as "unit testing". The purpose is the same, that is to began subsystem testing with units that have been thoroughly checked out so that the emphasis can be on testing the interfaces between these units. If this activity is not properly carried out prior to subsystem testing than the subsystem test will become disrupted by minor errors within the units which are not related to the important question of interfacing. This will cause the testing schedule to be disrupted and considerable extra costs.

During this stage, both new materials has been produced and changes have been made to existing documentation. The extent of change may range from almost none, to a re-designing of the major subsystem. In all cases, the documentation must be revised to ensure that the description of the system continues to be accurate and complete. Corrections to documentation in the form of revisions should have been made during the activity that identified the for revision.

During this activity, all changes should be reviewed from different, but complementary, pints of view:

All changes made to the system during this stage should be identified, and their impact on the overall system re-assessed, to ensure that:

Economic, technological and operational studies will be reviewed and, where necessary, modified to reflect the changes.

Design documentation is then updated to reflect all changes to the system identified during

review. The project File will now:

After all other activities at this stage have been completed, the final report can be prepared. In addition to describing the system as it currently stands, the report should highlight those changes introduced during this stage that will have an impact on the system’s planned performance.

The report has two main sections caused by the natural division of the activities at this stage, namely:

Prior to this activity, all the products are considered as being working papers and are highly subject to change. The program and Human Job Development Report is a final, technical report that should reflect the system as concrete following full development. changes to this report should be few and made only after careful consideration. The report should be reviewed by all affected parties and approved by management.

This page is intentionally left blank.