χ χ ν / ç·:êê THANSACTIONS ON KNGINKISHING MANAGEMENT, AUGUST 1970

Technical and Management Notes

C o m p u t e r P r o g r a m m i n g I m p l e m e n t a t i o n Contro ls

Absira et—Historically, where a computer programming group is part of a diversified company there has been a gap between the management and the programming group itself. This gap has been fostered by both a lack of understanding, on management's part, of the intricacies of programming and the attitude of many pro-grammers who consider their work to be an art as opposed to a science.

This gap has led to higher costs for implementing a job and loss of control on management's part, along with frustration and sloppy work habits on the programmers' part.

Even in many software houses, inefficiencies exist due to the lack of proper training of programmers in managerial positions.

It is the intent of this paper to bridge this gap. In addition, this paper will attempt to provide various check lists required by man-agers to guide software projects.

To ensure the successful implementation of any engineer-ing project, tbe staff managers must control each activity and operation. A series of guidelines and procedures have been developed towards this end.

In the area of computer programming, the controls neces-sary for implementation are quite similar to those necessary to implement a hardware project. Conceptually, the basic steps are identical (that is planning, system and subsystem design, implementation, and testing). The differences come in when considering the commodities dealt with.

To aid managers and project leaders in the implementa-tion of a job, a typical program flow diagram has been de-veloped (Fig. 1) . Each box on the typical program flow dia-gram represents a major activity during a program. The items listed within the boxes represent the prime items necessary to

Manuscript received January 1969; revised March 1970.

implement the activiiy Lu ensure the ultimate success ol the program.

Tbe organization of the flow diagram represents the gen-eral sequence in the implementation of a project, but overlaps are expected. The following is a description of the manage-ment controls inherent within the typical program flow diagrams.

I. PROJECT PLANNING AND ORGANIZATION

To start the project properly, the key people should be as-sembled to establish the management plans, define the cus-tomer's requirements, and develop the preliminary system configuration. More specifically, the key people must develop the following.

A. Management Plans

Organization charts Staffing plans Schedule (PERT recommended) Milestone chart for customer interface (review inputs, reports, deliveries, etc.) Cost Breakdown structure and budget allocations Reporting tools Test philosophy

Within these various areas are critical items that are some-times overlooked in the interest of "getting the job started." The organization must include a separate line function for system analysis.

B. Customer Requirements

Management plans Cost reporting (if applicable) Schedule reporting Technical progress reporting Deliverable technical documents Deliverable end products

[13J YV. E. Souder, "The validity of subjective probability of suc-cess forecasts by R&D project managers," IEEE Trans. Eng. Management, vol. EM-16, pp. 35 -49 , February 1969.

[14] C. A. S. Stael von Holstein, "The assessment of discrete sub-jective probability distributions—an experimental study," In-stitute of Mathematical Statistics, University of Stockholm, Stockholm, Sweden, Res. Rept. 41 , July 1969

[15] R. Winkler, "Probabilistic prediction: Some experimental re-sults," Proc. A?ner. Stat. Assoc., pp. 386 -395 , .1967.

[16] , "The quantification of judgment: Some methodological suggestions," / . Amer. Stat. Assoc., vol. 62, pp. 1105-1120, December 1967.

[17] , "Scoring rules and the evaluation of probability asses-sors," /. Amer. Stat. Assoc. ( to be published).

[18] R. Winkler and A. H. Murphy, "E\aluation of subjective pre-cipitation probability forecasts," Proc. 1st Natl. Conj. on Sta-tistical Meteorology. Boston: American Meteorological So-ciety, 1968, pp. 148-157.

[ 1 9 ] , "'Good' probability assessors," J. Appl. MeteoroL, vol. 7, pp. 751-758 , October *1968.

[20] D . II. Woods, "Improving estimates that involve uncertainty," Harvard Bus. Rev., vol. 44, pp. 9 1 - 9 8 , July-August 1966. '

[ 5 ] , "Foresight: Its logical laws, its subjective sources" ( Ç. E. Kvburg, Jr., Transi.), in Studies in Subjective Proba-bility, II. E. 'Kvburg, Jr. and II. E. Smokier, Eds. New York: Wiley, 1904, pp. 93 -158 .

[ 6 ] , "Methods for discriminating levels of partial knowledge concerning a test item," Brit. J. Math. Stat. Psijch., vol. 18, pp. 87 -123 , 1965.

[7 ] W. Edwards, "The theory of decision making," Psijcliol. Bull., vol. 51, no. 4, pp. 380-417, 1954.

[ 8 ] YV. Edwards, H. Landman, and L. Phillips, "Emerging tech-nologies for making decisions," in New Directions in Psychol-ogy II. New York: Holt, Rinehart, and Winston. 1965, pp. 261-325.

[ 9 ] D. Hertz, "Risk analysis in capital investment/' Harvard Bus. R e e , vol. 42, pp. 9.5-106, January-February 1964.

[10] A. L. Minkes and J. M. Samuels, "Allocation of research and development expenditure in the firm," / . Management Stud., vol. 3, pp. 6 2 - 7 2 , February 1966.

[11 ] H. Y. Roberts, "Probabilistic prediction," J. Amer. Stat. Assoc., vol. 60, pp. 5 0 - 6 2 , March 1965.

[12 ] L. J. Savage, The Foundations of Statistics. New York: YViiev, 1954.

TECHNICAL AND MANACKMKNT NOTES 1 1 7

Systern constraints: form factor(s) and/or weight environmental conditions

ñ 11 ys i ca 1 en í i ron ment RFl environment

electrical cooling

Compatibility with other equipments: hardware

interface logistics

software programming language compilation/assembly on multiple machines operation on multiple machine

Maintainability requirements Reliabilily requirements Support Potential system expansion

The customer's requirements must be understood through working discussions between the program's key people and the customer's kev people, as well as through research of all available documents. (Unfortunately, the necessary informa-tion is not always available in the documents. )

C. System Configuration

Hardware/software function delineation Preliminary hardware block diagram Equipment description and criteria Preliminary software flow diagram Software description and criteria

From these activities, the nucleus ol a working team is formed a "modus operandi" is established, and the necessary management tools are determined—all geared to the cus-tomer's needs. Since good management is dynamic, modifica-tions to the previous outputs will be required as the program develops.

I I . FIRM SYSTEM DEFINITION, CONFIGURATION, AND DESIGN

From the information available from steps of I-A and I - B , a firm system definition will evolve.

The amassed information must now be associated and con-verted into a system definition document of the technical aspects of the job. After review of this document by the cus-tomer, a technical base is available to proceed with the im-plementation phase. (Too often, the contractor's understand-ing of the job differs from that of the customer. The system definition document will provide a written basis from which the optimum system will evolve during the review with the customer.)

This document should include, as a minimum, the modes of operation of the system (in detail), the inputs, the outputs, operator functions, and a broad description of the equipment involved. Two major subsections should be included to handle the hardware 1 and the software.

The software section should be organized as follows.

A. Software System

Overall system flow chart and description Subroutine flow charts and description 2

List of all tables, buffers, I / O areas, constants, and switches 2

Priorities of subroutine, interrupts, and discretes 2

Core and time budgets for all programs 2

1 Since this is a description of software program planning, the hardware section will not be discussed here.

2 To the extent possible.

B. Interfaces

Sol t ware—software locutions of tables, buffers, I /O areas, constants, conver-sion factors, and software switches 2

use of registers priorities ol subroutines format of data software switches data rates

Soft w a re -ha id ware format of I / O type of I / O channel (parallel, multiplex, discrete, etc.) discrete and interrupt signals I /O control lines and logic quantity and quality of input data output reports (hardware and software)

C. Testing

Static subroutine tests Dynamic subroutine tests Programming system tests Software/hardware system integration tests

With the availability of an agreed upon system definition document, the program implementation becomes simple since the necessary system information is available in one place and can be widely distributed. Since this is a key document, any changes or deviations must be made formally with the customer's occurrence obtained prior to implementation.

In addition, this phase of the project should establish the computer configuration, followed bv a survey, evaluation, and selection of particular equipment.

III. SOFTWARE DEVELOPMENT

It is at this point in the project that the detailed implemen-tation plans are established. (Generally, these events will take place during the development of the system definition document. )

The form and format of all documentation will be estab-lished (that is, work statements, programming specifications and preliminary handbooks).

The testing plans will be outlined in detail (that is, desk checking, program debugging, programming system integra-tion, hardware/software integration, and preliminary accept-ance testing.

The detailed PERT networks 3 should be generated on the basis of the system definition document, the mathematical model, the manpower loading, and the test plans. Listed be-low are the recommended steps and the resultant aids that can then be used during the next phase of the project.

1 ) Subdivide the overall software system into subroutines (system definition document and mathematical mode l ) . 4

2.) Estimate the time that will be required to perform the analysis, work statement, program specification, cod-ings, and debugging for each module.

3) PERT out the time required to implement the modules, the main line required to interface all the modules, and all tests (module) and main line test programs.

: ß The detailed PERT networks will be a finer breakdown of the general PERT networks developed at the outset of the job.

4 The development of a software "family tree" may be useful as a visual aid in determining which subroutines are required for testing each major program. When tied to the work statement documentation numbers, com-monalities are readily apparent. It is also quite .useful in indoctrinating new personnel and customer personnel in the organization, operation, and inter-relationship of the programming system.

1 1 ς> \ÊÊÊ I H A X S A C I I O N S O N E N G I N E E R I N G M A N A G E M E N T . A U G U S T 1970

DATA SYSTEMS DEPARTMENT

T Y P I C A L F U N C T I O N A L F L O W D I A G R A M ( C O M P U T E R P R O G R A M M I N G )

ôï: TYPICAL FUNCTIONAL FLOW DIAGRAM (FULL FORMAL PROGRAM) w BLOCKS E N T I T L E D "PRELIMINARY SYSTEM

CONFIGURATION AN0 SYSTEM D E S I G N " AND "F IRM SYSTEM CONFIGURATION AND SYSTEM D E S I G N "

PROJECT PLANNING AND ORGANIZATION

C A l T E R I

S P E C I F I C A T I O N S

WORK STATEMENT REQUIREMENTS

SCHEDULE REQUIREMENTS ( P E R T )

COST

CUSTOMER CONCURRENCE

MANAGEMENT PLANS

STAFFING PLAMS

PRELIMINARY BLOCK DIAGRAMS

EQUIPMENT FORM FACTORS

EQUIPMENT EN REQUIREMENT

HARDWARE SOFTWARE FUNCTIONS

JO STRUCTURE

' •EST PLANS

* PROGRAM MANAGER

• ENGINEER 1116 MANAGER

• HAROWARE E N G 1 G S U P ' R

• B U S I N E S S ADMIN ISTRATOR

• SOFTWARE E N G ' G SUP ' R

OUTPUTS

• SYSTEM CONFIGURATION

• JO STRUCTURE

• ORGAN I Ζ AT I ON CHART

• OVERALL PERT DIAGRAM

• BUDGET ALLOCATIONS

• REPORTING TOOLS

• TEST PHILOSOPHY

FIRM SYSTEM CONFIGURATION AND SYSTEM DESIGN

SOFTWARE SYSTEM A N A L Y S I S

COMPUTER CONFIGURATION

PROGRAM LANGUAGE

U T I L I T Y SYSTEM COI (I F REQUIRED)

SYSTEM OUTPUT D E F I N I T I O N

SYSTEM INPUT D E F I N I T I O N

EXECUTIVE PROGRAM FUNCTION

EFFECT ON HARDWARE

• PROGRAM MANAGER

• E N G I N E E R I N G MANAGER

• SOFTWARE E N G ' R S U P ' R

• HARDWARE E N G ' R S U P ' R

• CONSULTANTS

• LEAD ANALYST

• LEAD PROGRAMMER

• LEAD HARDWARE ENGINEER

• ENGINEER

ABBREVI AT I ON S

* = R E S P O N S I B L E P A R T I C I P A N T

ENG'R S U P ' R = E N G I N E E R I N G SUPERVISOR

JO « JOB ORDER

• F IRM SYSTEM CON F I GUR A.'l ON

• F IRM COMPUTER S E L E C T I O N

• F I R M PROGRAM LANGUAGE PLAN (OR FLOW CHARTS)

• P R E L I M I N A R Y MON I TOR ING ROUTINE ( F I R M OR P R E L I Ν I NARY)

a) U T I L I T Y SYSTEM

b) COMPUTER S P E C I F I C A T I O N (SOFTWARE REQUIREMENTS)

c) TEST EQUIPMENT (SOFTWARE)

• SYSTEM A N A L Y S I S DOCUMENTATION

a) SYSTEM MODES

c) I N P U T S

d) THRUPUTS e) HARD OUTPUTS ( T A P E . P R I N T E R . ETC)

SYSTEM R E S T R A I N T S ( I N T E R N A L SPEC REQUIREMENTS)

SOFTWARE DEVELOPMENT (SYSTEM, SUBSYSTEM OR UNIT)

COMPUTER CONFIGURATION

SOFTWARE CONFIGURAT I ON

T R A I N I N G A I D S

SYSTEM PLANS

SOFTWARE DESIGN PLANS

TEST PLANS

a) CODING

b) DEBUGGING

c) SYSTEM MARRIAGE

DOCUMENTATION PLANS

a) PROGRAM S P E C I F I C A T I O N S

b) PROGRAM WORK STATEMENTS

MAN MACHINE R E L A T I O N S H I P S

SUBROUTINE PLANS

a) LANGUAGE

b) FLOW CHARTS

c) PROGRAMMING

d) CODING

• SOFTWARE E N G ' G S U P ' R

• LEAD ANALYST

• LΕΛΟ PROGRAMMER

• COMPUTER ROOM COORDINATOR

DELJVERABLE SYSTEM HARDWARE FROM

TYPICAL FUNCTIONAL FLOW DIAGRAM FOF HARDWAF

OUTPUT

• CODING SHEETS

• WORD COUNT CHART UPDATE

PROGRAM IMPLEMENTATION

PROGRAM CODING REVIEW

TEST DATA GENERATION

S IMULATION ROUTINE

KEY-PUNCH PLANS

DEBUGGING PLANS

MACHINE T I M E PLANS

• LEAD PROGRAMMER

• LEAD ANALYST

• PROGRAMMER

• ANALYST

• OPERATOR

• KEY-PUNCH OPERATOR

OUTPUTS

• MACHINE T IME SCHEDULE

• KEY-PUNCH PLANS

• MACHINE ROOM PLANS

• OPERATOR USAGE PLANS

• SHIFT SCHEDULES

PROGRAM DEBUGGING

INDIVIDUAL PROGRAMS

SUBROUTINE

EFFICIENCY EVALUATION

REVISE WORK ST, AND SPEC I F I CAT I

REV:SF CODING

REVISE CARD DECK

5ft PROGRAMMER

s KEY-PUNCH OPERATOR

• COMPUTER OPERATOR

OUTPUTS

• WORKING PROGRAMS

• CARD D E C K S

• TAPES

• U P D A T E D DOCUMENTATION

• D I S K S

• WORD COUNT CHART UPDATE

PROGRAMMING SYSTEM TEST

WORKING PROGRAMS

SYSTEM EXECUTIVE PROGRIM

TEST PROCEDURE

TEST EQUIPMENT

TEST SETUP

jf: LEAD ANALYST

• LEAD PROGRAMMER

• ANALYST

• PROGRAMMER

ALL CHANGES MUST BE CONTROLLED AND RECORDEO ON WORK STATEMENTS OR FLOW CHARTS. IN A D D I T I O N . CHANGES MUST

" B E INCORPORATED INTC WORKING PROGRAM TOOLS OF IMPLEMENTATION " TO ASSURE CONGRU I T Y .

Fig. 1

T E C H N I C A L A N D M A N A G E M E N T N O T E S

OUTPUTS

â DETAILED PERT NETWORKS

". MODES UP OPERAT

PROGRAMM

INPUTS

THRUPUTS

SYSTEM R E S T R A I N T S R E -Q U I R I N G INTERNAL S P E U F -I CATIONS OVER ANO ABOVE CUSTOMER S P E C I F I C A T I O N S

• WORD COUNT CHART

• Τ IM1NG CHART

P R O G R A M M I N G

D E V E L O P M E N T

SYSTEM A N A L Y S I S DOCUMENTATION

PROGRAM WORK STATEMENT

PROGRAM LANGUAGE

PROGRAM FLOW CHART ( I F NECESSARY)

PROGRAM T E C H N I Q U E S

PROGRAM ASSEMBLER ROUTINE

PROGRAM COMPUTER ROUTINE

PROGRAM S P E C I F I C A T I O N FROMATS

INPUT/OUTPUT D E F I N E D

BUFFERS

MEMORY USE

CODING METHODS

ARRAYS

INDEX R E G I S T E R REQUIREMENTS

INTERNAL FORMATS

S IMULATION REQUIREMENTS

• SOFTWARE E N I 1 G S U P ' R

• LEAD ANALYST

• LEAD PROGRAMMER

• ANALYST

• PROGRAMMER

OUTPUTS

• WORK STATEMENT

a ) ONE FOR EACH SUBROUTINE

t ) SEPARATE MONITOR ROUTINE

• FLOW CHART ( I F R E Q U I R E D )

• WORD COUNT CHART UPDATE

• P R O G R A M M I N G S P E C I F I C A T I O N S a ) ONE FOR EACH D E T A I L

DEVELOPMENT

b) SEPARATE FOR MONITOR

C O D I N G

CODING SHEETS

(CODED AS PER WORK STATEMENT AND PROGRAM S P E C I F I C A T I O N S )

φ PROGRAMMER

• ANALYST

ALL CHANGES MUST BE CONTROLLED - A N D RECORDED OlRECTLY ON WORK -

STATEMENTS OR FLOW CHARTS

S Y S T E M I N T E G R A T I O N

T E S T I N G

HARDWARE OUTPUTS

PROGRAMMING SYSTEM • TEST ACCEPTANCE SIGN OFF

ACCEPTANCE TEST PROCEDURES

• TEST ACCEPTANCE SIGN OFF

'UTS CUSTOMER CONCURRENCE • TEST REPORT

)P ERAT ION AL PROGRAMMING SYSTEM

TEST DATA • SOFTWARE DOCUMENTATION

1NA L DOCUMENTAT ION BUY OFF

ffORD COUNT AND I M l N G UPDATE * E N G I N E E R I N G MGR

• QUAL 1TY ASSURANCE

• HEAD PROGRAMMER

• LEAD ANALYST

• CUSTOMER

P A C K I N G A N D

S H I P P I N G O F S O F T W A R E

D O C U M E N T S

* PROGRAM MANAGER

• QUALITY ASSURANCE

• CUSTOMER

CUSTOMER SUPPORT

OPERATIONAL USAGE

TRAIN ING

a) USAGE

t>) MAINTENANCE

c) CONCEPT OF SYSTEM

Ö PROGRAM MANAGER

• SOFTWARE E N G ' Ê

• F I E L O ENG' R

• CUSTOMER

1 1 ς> \ÊÊÊ I H A X S A C I I O N S O N E N G I N E E R I N G M A N A G E M E N T . A U G U S T 1970

DATA SYSTEMS DEPARTMENT

T Y P I C A L F U N C T I O N A L F L O W D I A G R A M ( C O M P U T E R P R O G R A M M I N G )

ôï: TYPICAL FUNCTIONAL FLOW DIAGRAM (FULL FORMAL PROGRAM) w BLOCKS E N T I T L E D "PRELIMINARY SYSTEM

CONFIGURATION AN0 SYSTEM D E S I G N " AND "F IRM SYSTEM CONFIGURATION AND SYSTEM D E S I G N "

PROJECT PLANNING AND ORGANIZATION

C A l T E R I

S P E C I F I C A T I O N S

WORK STATEMENT REQUIREMENTS

SCHEDULE REQUIREMENTS ( P E R T )

COST

CUSTOMER CONCURRENCE

MANAGEMENT PLANS

STAFFING PLAMS

PRELIMINARY BLOCK DIAGRAMS

EQUIPMENT FORM FACTORS

EQUIPMENT EN REQUIREMENT

HARDWARE SOFTWARE FUNCTIONS

JO STRUCTURE

' •EST PLANS

* PROGRAM MANAGER

• ENGINEER 1116 MANAGER

• HAROWARE E N G 1 G S U P ' R

• B U S I N E S S ADMIN ISTRATOR

• SOFTWARE E N G ' G SUP ' R

OUTPUTS

• SYSTEM CONFIGURATION

• JO STRUCTURE

• ORGAN I Ζ AT I ON CHART

• OVERALL PERT DIAGRAM

• BUDGET ALLOCATIONS

• REPORTING TOOLS

• TEST PHILOSOPHY

FIRM SYSTEM CONFIGURATION AND SYSTEM DESIGN

SOFTWARE SYSTEM A N A L Y S I S

COMPUTER CONFIGURATION

PROGRAM LANGUAGE

U T I L I T Y SYSTEM COI (I F REQUIRED)

SYSTEM OUTPUT D E F I N I T I O N

SYSTEM INPUT D E F I N I T I O N

EXECUTIVE PROGRAM FUNCTION

EFFECT ON HARDWARE

• PROGRAM MANAGER

• E N G I N E E R I N G MANAGER

• SOFTWARE E N G ' R S U P ' R

• HARDWARE E N G ' R S U P ' R

• CONSULTANTS

• LEAD ANALYST

• LEAD PROGRAMMER

• LEAD HARDWARE ENGINEER

• ENGINEER

ABBREVI AT I ON S

* = R E S P O N S I B L E P A R T I C I P A N T

ENG'R S U P ' R = E N G I N E E R I N G SUPERVISOR

JO « JOB ORDER

• F IRM SYSTEM CON F I GUR A.'l ON

• F IRM COMPUTER S E L E C T I O N

• F I R M PROGRAM LANGUAGE PLAN (OR FLOW CHARTS)

• P R E L I M I N A R Y MON I TOR ING ROUTINE ( F I R M OR P R E L I Ν I NARY)

a) U T I L I T Y SYSTEM

b) COMPUTER S P E C I F I C A T I O N (SOFTWARE REQUIREMENTS)

c) TEST EQUIPMENT (SOFTWARE)

• SYSTEM A N A L Y S I S DOCUMENTATION

a) SYSTEM MODES

c) I N P U T S

d) THRUPUTS e) HARD OUTPUTS ( T A P E . P R I N T E R . ETC)

SYSTEM R E S T R A I N T S ( I N T E R N A L SPEC REQUIREMENTS)

SOFTWARE DEVELOPMENT (SYSTEM, SUBSYSTEM OR UNIT)

COMPUTER CONFIGURATION

SOFTWARE CONFIGURAT I ON

T R A I N I N G A I D S

SYSTEM PLANS

SOFTWARE DESIGN PLANS

TEST PLANS

a) CODING

b) DEBUGGING

c) SYSTEM MARRIAGE

DOCUMENTATION PLANS

a) PROGRAM S P E C I F I C A T I O N S

b) PROGRAM WORK STATEMENTS

MAN MACHINE R E L A T I O N S H I P S

SUBROUTINE PLANS

a) LANGUAGE

b) FLOW CHARTS

c) PROGRAMMING

d) CODING

• SOFTWARE E N G ' G S U P ' R

• LEAD ANALYST

• LΕΛΟ PROGRAMMER

• COMPUTER ROOM COORDINATOR

DELJVERABLE SYSTEM HARDWARE FROM

TYPICAL FUNCTIONAL FLOW DIAGRAM FOF HARDWAF

OUTPUT

• CODING SHEETS

• WORD COUNT CHART UPDATE

PROGRAM IMPLEMENTATION

PROGRAM CODING REVIEW

TEST DATA GENERATION

S IMULATION ROUTINE

KEY-PUNCH PLANS

DEBUGGING PLANS

MACHINE T I M E PLANS

• LEAD PROGRAMMER

• LEAD ANALYST

• PROGRAMMER

• ANALYST

• OPERATOR

• KEY-PUNCH OPERATOR

OUTPUTS

• MACHINE T IME SCHEDULE

• KEY-PUNCH PLANS

• MACHINE ROOM PLANS

• OPERATOR USAGE PLANS

• SHIFT SCHEDULES

PROGRAM DEBUGGING

INDIVIDUAL PROGRAMS

SUBROUTINE

EFFICIENCY EVALUATION

REVISE WORK ST, AND SPEC I F I CAT I

REV:SF CODING

REVISE CARD DECK

5ft PROGRAMMER

s KEY-PUNCH OPERATOR

• COMPUTER OPERATOR

OUTPUTS

• WORKING PROGRAMS

• CARD D E C K S

• TAPES

• U P D A T E D DOCUMENTATION

• D I S K S

• WORD COUNT CHART UPDATE

PROGRAMMING SYSTEM TEST

WORKING PROGRAMS

SYSTEM EXECUTIVE PROGRIM

TEST PROCEDURE

TEST EQUIPMENT

TEST SETUP

jf: LEAD ANALYST

• LEAD PROGRAMMER

• ANALYST

• PROGRAMMER

ALL CHANGES MUST BE CONTROLLED AND RECORDEO ON WORK STATEMENTS OR FLOW CHARTS. IN A D D I T I O N . CHANGES MUST

" B E INCORPORATED INTC WORKING PROGRAM TOOLS OF IMPLEMENTATION " TO ASSURE CONGRU I T Y .

Fig. 1