                                                               October 5, 1982



                              Preliminary Draft



                              SECOND GENERATION
                                COMPREHENSIVE
                         HELICOPTER ANALYSIS SYSTEM
                                  (2GCHAS)





                                     #N10

                         SOFTWARE LIFE CYCLE ANALYSIS












                            2GCHAS PROJECT OFFICE
                           AEROMECHANICS LABORATORY
                    RESEARCH AND TECHNOLOGY LABORATORIES
                             AMES RESEARCH CENTER
             U.S. ARMY AVIATION RESEARCH AND DEVELOPMENT COMMAND

                                                             October 5, 1982







                              SECOND GENERATION
                                COMPREHENSIVE
                          HELICOPTER ANALYSIS SYSTEM
                                   (2GCHAS)





                                     #N10

                         SOFTWARE LIFE CYCLE ANALYSIS






                           Prepared Under Contract
                                 NAS 2-10784

                              TABLE OF CONTENTS

SECTION 1 - INTRODUCTION
1.1  General
1.2  Scope and Applicability

SECTION 2 - SOFTWARE LIFE CYCLE PHASE DEFINITIONS
2.1  Introduction
2.2  Requirements Definition
2.3  Analysis
2.4  Architectural Design
2.5  Detailed Design
2.6  Software Implementation
2.7  Testing
2.8  Training
2.9  Configuration Control
2.10 Documentation
2.11 Management

SECTION 3 - POTENTIAL TOOL SUPPORT AREAS
3.1  Introduction
3.2  Requirements Definition
3.3  Analysis
3.4  Architectural Design
3.5  Detailed Design
3.6  Software Implementation
3.7  Testing
3.8  Training
3.9  Configuration Control
3.10 Documentation
3.11 Management

SECTION 4 - REFERENCES





                                    i

SECTION 1 - INTRODUCTION

1.1  General
     This paper defines and details the scope of the software life cycle
     phases for the 2GCHAS Project, and suggests types of functional
     capabilities needed for software tools to aid in the activities
     associated with each phase.  Also presented is the relationship of each
     phase with all related Project elements (Product Assurance, Methodology,
     etc.).  This helps to determine which elements are responsible for
     defining the approach/methodology to be followed in the development of
     each phase.

1.2  Scope and Applicability
     The 2GCHAS software life cycle is a series of phases and associated
     activities ranging from initial requirements definition to the operation
     and maintenance of the installed, integrated system.  Automated and/or
     manual tools will be assembled to aid in these life cycle phases, which
     are as follows:
       o  Requirements Definition
       o  Analysis
       o  Architectural Design
       o  Detailed Design
       o  Software Implementation
       o  Testing
       o  Training
       o  Configuration Control
       o  Documentation
       o  Management

     Embedded within the life cycle are a series of configuration management
     baselines which order and control the growth of the resultant software
     products.

     The Project Management Plan specifies and defines the seven volumes of
     the Project Master Documentation (See Reference E.).  Each volume
     addresses a different Project activity.


                                     1

     The top-level Project activities which have a bearing on the 2GCHAS
     life cycle phases are as follows:
       o  Project Management
       o  Product Assurance
       o  Library Development and Operations
       o  Software Development
       o  Installation, Maintenance, and Enhancement
     See Reference E. For complete definition of these five Project level
     activities.

     The growth pattern of the software system as a whole, as seen through
     development of its component parts, is expected to be an iterative one.
     That is, the 10 life-cycle phases are not tackled and subsequently
     completed sequentially and independently.  Rather, there is much
     overlapping of the phases and passing of information between them.  For
     example, upon entering the architectural design phase, a new perspective
     may be gained on the analysis approach and the analysis improved by this
     additional information.  By addressing this growth pattern through the
     use of the life cycle phases, the highly interactive nature of the
     software system may be understood.  Particular importance is placed upon
     the interfaces of the top-level Project activities listed above with the
     development activities within each life cycle phase.  The remainder of
     this paper will identify these interactions and designate possibilities
     for software tools functions needed to carry out their associated
     activities.













                                     2

SECTION 2 - SOFTWARE LIFE CYCLE PHASE DEFINITIONS

2.1  Introduction
     The following definitions are intended to be comprehensive enough to
     provide descriptions which are sufficient for analyzing tool
     requirements.  A complete development of the phases is provided in the
     Methodology Manual.

     In order to ensure adequate delineation of the phases, including the
     addressing of the interfaces of the phases, description of the transition
     from one phase to another is stressed. Each phase description includes
     requirements which must be met in order for the development in that phase
     to commence and items which are produced during that phase.

     Since the top-level goal of the Software Quality Control (SQC)
     subfunction of Software Quality Assurance (SQA) is to assure compliance
     with Product Assurance Policies, a major activity of the SQC subfunction
     is the monitoring of all phases of software development.  Therefore, the
     SQA program applies detailed Standards and Procedures for the monitoring
     of the life cycle phases throughout the development process.  (See
     Reference F.)

2.2  Requirements Definition
     In this phase, the functional capabilities of the software system are
     defined in a specification.  The specification is an enforceable document
     containing testable requirements for functions which the completed System
     must perform.  (See References A. and I.)  This document is referred to
     in the 2GCHAS Project as the Type A System Requirements Specification.
     (See Reference H.)

     In order for this phase to commence, there must be a consensus on the
     need for a new product, and descriptions of previous products which are
     outdated or inadequate. The product of this phase on the 2GCHAS Project
     is a Type A System Requirements Specification to which the final system
     must comply.



                                     3

2.3  Analysis
     In the analysis phase, the input, output, and processes (i.e., the
     functions) of the software system are studied using a structured
     approach.  The purpose of the analysis phase is to determine the
     functions and information which are needed in the System.  Analysis
     is applied to the requirements definition and may result in a
     revised System requirements specification.  Also, the analysis
     effort is an iterative one.  That is, feedback from one step in the
     analysis phase is studied, and applied where appropriate, to the
     next step in the analysis phase.  An analysis report containing Data
     Flow Diagrams, the Data Dictionary, and Mini-specs is produced as a
     result of the analysis effort.  Definitions for the Data Flow
     Diagram, Data Dictionary, and Mini-specs are summarized below:  (See
     References B. and G. for more complete definitions)

          A Data Flow Diagram (DFD) is a network of related functions
          showing all interfaces between/among System components.
          The System may be automated, manual, or a combination of
          both.  The DFD, therefore, also provides a partitioning of
          the System into its component parts by showing a major
          decomposition of functions and all the interfaces among the
          pieces.  A DFD shows flow of data through the System.  It
          portrays the data required as input to a process and the
          data produced by a process, but does not deal with the
          control (or sequence) of these processes.

          A Data Dictionary (DD) is a complete set of definitions of
          data flows, data elements, files, and data bases.  The
          following definitions are fundamental to the structured
          approach and are discussed in detail in Reference B.  A
          data flow is a pipeline along which information of known
          composition is passed.  A data element is a data flow which
          is not decomposed into subordinate data flows.  According
          to Reference B., data element may also be referred to as a
          functional primitive.  A file is a data store and a data
          base is a data store which is accessed in more than one way
          and may be modified in format without affecting the programs

                                     4

          which access it.  The DD is a documenting of each of the
          interfaces and data stores on all of the DFDs.  It is only
          when each and every element of the DFD has been rigorously
          defined that the analysis phase is complete.

          A Mini-Spec (MS) is a statement describing the transformation of
          input data flow(s) into output data flow(s).  Mini-Specs document
          the internals of the DFD processes in a rigorous fashion.

     In addition to the analysis report (containing the DFDs, DD, and MSs), a
     product of the analysis phase may be a revised System requirements
     specification.  The products of the analysis phase should not only be
     precise, concise, and highly readable, but should also have the following
     qualities:

       o  Graphic:  The Data Flow Diagrams should present a meaningful
          picture of what is being specified, a conceptually
          easy to understand presentation of the subject matter.

       o  Partitioned:  The processes on the Data Flow Diagrams are the
          basic elements into which the System is decomposed.  This
          partitioning can be presented in a top-down fashion so that
          there is a smooth progression from the most abstract to the
          most detailed.

       o  Rigorous:  The Data Dictionary will provide a rigorous
          documentation of the interfaces; and the Mini-Specs, a
          rigorous specification of processes.

       o  Maintainable:  Redundancy is minimized.  The process of
          changing the requirements specification can be tightly
          controlled.

       o  Logical (not physical):  By eliminating elements which depend
          upon hardware, operating system, and operating procedure from
          the Specification, non-functional requirements may also be
          eliminated.  (See Analysis steps below).

                                     5

     The Analysis effort may be viewed in a top-level fashion in terms of
     the four steps through which the model of the System proceeds.  (See
     Reference G for greater detail on these steps.)

       o  Current Physical Model:  Describes the current System in
          terms of the context diagram which defines the limits of
          the System.

       o  Current Logical Model:  Simplifies the previous model,
          removes physical constraints and optimizes by separating the
          new requirements into logical and physical ones.

       o  New Logical Model:  Incorporates new requirements.

       o  New Physical Model:  Imposes boundary constraints.

2.4  Architectural Design
     The purpose of the Architectural Design (AD) Phase is to determine a
     hierarchical, control oriented structure which implements the functions
     identified and defined during the analysis phase.  (See References F. and
     J.)

     The first step in the AD phase may be the application of the strategy
     called Transform Analysis.  This is a strategy for deriving a design
     directly from the Data Flow Diagram.  Transform analysis is a design
     strategy in which the structure of a system is derived from an analysis
     of the flow of data through a system and of the transformations of data.
     The result of this step is not a finished design, but a good beginning to
     the design process.  The rest of that process is primarily concerned with
     evaluation and refinement of the initial design.

     An alternative approach to the Transform Analysis step is a strategy
     called Transaction Analysis.  This step is also a design strategy for
     original derivation of a modular structure from a DFD.  It differs from
     the first approach in that it is applicable to a transaction oriented
     class of DFDs.  That is, Transaction Analysis is a design strategy in


                                     6

     which the structure of a system is derived from an analysis of the
     transactions the system is required to process.

     The following criteria are applied in evaluating the initial design:

       o  Cohesion:  evaluates the binding (relatedness of the internal
          functions of a module)

       o  Coupling:  evaluates the degree of interdependence between
          modules

       o  Scope of control/effect:  evaluates whether a module affects
          other modules unexpectedly (i.e., other than through the
          defined interface)

       o  Module Size:  an understandable number of processing elements
          per module

       o  Shape of Structure:  fan-out at upper levels, fan-in at lower
          levels

     The products of the AD phase are the following:

       o  Structure Chart:  a graphic tool for representing hierarchy of
          of control

       o  Updated Data Dictionary (Intermodule Communications):
          a description of communications between modules (e.g.,
          intermediate files, subroutine arguments, external variables)

       o  Module specifications:  describe the internal functions of
          modules

2.5  Detailed Design
     In this phase, the information in the structure charts from the
     architectural design phase will be expanded into a more detailed
     pseudo-English form or Program Design Language (PDL).  The choices

                                     7

     between algorithms for alternate approaches to implementing functions and
     between options for the design of data structures will be made at this
     stage.

     The Detailed Design generates "blue prints" for the System which can be
     implemented in a mechanical fashion.  (See Reference G.)

     The initial operations involved in the Detailed Design phase are the
     choosing of data and control structures and the partitioning of the
     System into physical modules.  At this point attributes such as type,
     range, encoding, security, access and flow mechanics, as well as physical
     structure may be assigned to the data and the processes which are
     represented on the structure charts.

     The initial examination of the following constraints may also begin:

       o  Hardware or Operating System software interface

       o  Implementation Dependencies:  Language choice, Operating System
          facilities

       o  Desirable Performance

       o  User Interface

       o  Error Checking and action

       o  Compatibility Requirements (i.e., the interfaces among the
          imposed constraints)

     Due to the iterative nature of software development, these criteria
     will be examined further in the implementation phase and feedback
     will be applied to the detailed design effort.  Detailed design
     methodology is specified in the Methodology Manual and documentation
     formats are specified in the Library Development and Operations Task
     Manual.


                                     8

2.6  Software Implementation
     Implementation produces executable software on specified hardware.  The
     objective of this phase is to transform PDL code produced in the detailed
     design phase into executable FORTRAN code.  Decisions will be made with
     respect to the criteria first addressed in the detailed design phase.  In
     addition, storage management, code optimization, packaging and assembly
     language efficiency versus memory trade-offs will be fully addressed.
     Therefore, most important decisions have been made, and the "blue prints"
     from the detailed design have been coded in accordance with the FORTRAN
     77 programming standards.

     The products specific to the implementation phase are the FORTRAN code
     and documentation in the form of load modules and load libraries.

2.7  Testing
     Testing is a process of executing a program with the intention of
     uncovering errors.  It is not meant as a process to demonstrate the
     validity or correctness of a program.  This process is to be performed
     with economy of both programmer time and hardware time in mind.  The
     design of test cases will emphasize the choice of a limited, but useful,
     number of tests used to reveal a maximum number of errors.

     Testing may be employed at five different levels of software development.
     These levels are defined as follows:  (See Reference D.)

       o  Module testing is the process of testing each subprogram in
          the System.  The function of a subprogram is compared with
          the functional specifications and interface requirements of
          the subprogram.

       o  Function testing is a process of finding discrepancies
          between the program and its external specification.  The
          external specification is a set of program requirements
          developed with the end user's point of view.

       o  System testing is the process of comparing the performance of
          the System with its original objectives.

                                     9

       o  Acceptance testing is the process of comparing the System with
          its initial requirements and the current needs of the end
          users.

       o  Installation testing is employed to find installation errors
          such as errors in creating appropriate files and libraries in
          the installation process.

     Successful testing of 2GCHAS code at appropriate stages throughout
     development is a major goal of the Quality Assurance effort in that
     development testing is the major component in the Verification and
     Validation process.  (See Reference E.)  The Development Testing
     subfunction of Validation and Verification addresses those types of tests
     to be performed during the period starting shortly after Implementation
     has begun and terminating upon issuance of a software package to the User
     Community.  The purpose of such testing is to sample the actual
     functioning of the code in question.  The objective in all instances is
     to expose errors or conflicts with applicable specifications and
     standards through controlled exercises of the program by running
     specially prepared test cases.  Thus, in order to minimize the effect of
     errors by discovering and correcting them at early stages, testing is
     planned for small discrete steps of code development soon after the
     commencement of the development process.  Testing starts with the first
     module and ends only after issuance of a System Build or Release to the
     User Community.  Then post-development testing continues until the
     successful demonstration of the functional capabilities of the System.

2.8  Training
     Courses will be offered throughout the lifetime of the Project with the
     subject matter covering the various stages of the development
     methodology.  Also, training in the use of the System which begins upon
     delivery of the first usable subset (Release) of the System and continues
     throughout the lifecycle of the System will be offered.  This training
     involves teaching potential users how to use the System, including how to
     prepare input, how to interpret output, the mathematical basis for the
     System, System limitations, and how to use the System documentation.


                                     10

     The training efforts will be monitored by the Quality Assurance team in
     order to ensure that all training provided by the Project will have
     adequate content to provide participants with either the information to
     aid them in fulfillment of their assigned task or adequate instruction in
     the operation of the System.  (See Reference E.)

     Project management will ensure that all training needed by the
     users/analysts will be provided.  The Library Development and Operations
     Task Manual will specify the format for all useful documentation, and the
     PA team will control quality of, and changes to, these documents.

2.9  Configuration Control
     Configuration Control provides for the processing and approval/
     disapproval of all change proposals throughout the software life cycle.
     Once a Computer Program Configuration Item (CPCI) has been baselined, all
     changes made to it must be done in a formal manner.  Written requests for
     change are submitted to the Configuration Control Board (CCB) for
     approval or disapproval.  All requests are documented and, if approved, a
     formal notice of that planned change is issued to Project personnel.
     (See Reference F.)  Once the change is implemented, standard QA and CM
     procedures are used to assure that the change was done correctly and is
     distributed.

     Configuration Control is the process of evaluating, coordinating, and
     approving or disapproving proposed changes to an established baseline
     configuration of a CPCI.  This process maintains the formally approved
     configuration, ensures implementation of all approved changes, and
     regulates change procedures to ensure conformance between documentation
     and the coding it identifies.

     Formal control of a CPCI begins with the definition and approval of a
     baseline configuration for the CPCI and continues throughout the life
     cycle.  Subsequent to the approval of a baseline, all changes to that
     baseline must be proposed in the form of a Software Change Proposal
     (SCP), or Software Enhancement Proposal (SEP), and subsequently
     disseminated through the use of a Software Change Notice (SCN).  These
     proposals may be submitted by anyone in the 2GCHAS Development and User

                                     11

     community, but are reviewed and approved or disapproved by the CCB.
     Complete SCP, SEP, and SCN procedures will be included in the PA Manual.

     The PA team, with support from the Library staff, manages these efforts.

2.10 Documentation
     The Documentation phase begins immediately upon project inception
     and continues throughout the life cycle of the System.

     Project documentation includes all documentation items produced for the
     finalized System, all intermediate documentation items, and even
     historical or background documents produced before commencement of the
     Project.  The top-level description and control of documentation is
     specified in the Library Development and Operations Task Plan.  (See
     Reference C.)

     The Quality Assurance team implements procedures and controls for the
     monitoring of various forms and versions of documentation from the time
     of their initial approval or acceptance until they have been incorporated
     into the final deliverable product.  (See Reference F.)

2.11 Management
     The Management phase of the 2GCHAS Project begins with the Project
     inception and continues throughout the life of the Project.  This phase,
     involves all of the other life cycle phases.  A project such as the
     development of 2GCHAS dictates the need for especially efficient
     management based upon sound principles.  Thorough planning is
     particularly crucial, with overall Project planning necessarily providing
     the foundation upon which technical activities are to be planned and
     implemented.  The Project Management Plan, (See Reference E.)  addresses
     those foundational matters including objectives, milestones, and policies
     as well as general activities and procedures which are germane to the
     Management phase.  The purposes of the Management phase, and,
     therefore, the Management Plan are threefold:

       o  To provide a central repository for all general overall Project
          planning;

                                     12

       o  To provide an aid to communications of top-level plans to the
          2GCHAS Project Staff and to interested parties external to the
          Project; and

       o  To provide a foundation upon which more detailed plans can be
          generated which will address specific activities within the
          Project Work Breakdown Structure (WBS).

     Whereas the WBS presents the tasks in a hierarchically-ordered form, the
     Project Planning Network (PPN) relates tasks and subtasks to one another
     in a time-ordered manner.  This completes the "picture" for planning
     purposes.  Monitoring of schedules can then be achieved with GANTT and
     milestone charts.

























                                     13

SECTION 3 - POTENTIAL TOOL SUPPORT AREAS

3.1  Introduction
     Based upon the definitions in Section 2 for the ten life cycle
     phases, the following tools have been identified for support in the
     development of those areas.  This list of tools will become more
     detailed, specific, and extensive as the Project evolves.
     Therefore, this section will be maintained as a living portion of
     the overall Software Life Cycle Analysis and updated whenever new
     material is discovered.

     A separate but related effort is the survey of candidate tools, the
     results of which will depend upon this document.  Both documents
     will be maintained in a complementary and consistent fashion.

3.2  Requirements Definition
     The tools support to be provided for the requirements definition
     phase in general falls under the purview of Library policy.  In
     addition, the Product Assurance program provides procedures for the
     handling of the baselined System Requirements Definition Document
     including the change control and disposition of the document.
     Therefore, specific tools will be addressed in the subsections
     herein entitled "Configuration Control" and "Documentation".

3.3  Analysis
     Tools with the following capabilities are desirable:

       o  To generate Data Flow Diagram graphs based on user's input.
          The graphs consist of bubbles (ellipses or circles) and all
          other necessary graphical symbols and lines.

       o  To produce labels for both the processes and data flows.
          These labels shall be maintained so that they can be displayed
          on the Data Flow Diagram graphs or printed out as lists of
          data dictionary and mini-specs.

       o  To allow descriptions of data flows and processes to be
          entered into the system and printed out in a report form.

                                     14

     All documentation produced will have formats specified in the
     Library Development and Operations Task Manual. The structured
     analysis approach to follow will be specified in the Methodology
     Manual.

3.4  Architectural Design
     The desirable tools will have the following functional
     capabilities:

       o  To generate graphical symbols to represent data flows,
          connectors, and modules.

       o  To produce labels for both the modules and data flows.  The
          labels will be maintained so that they can be listed or
          displayed on the graphs.

       o  To take the descriptions of module specifications from users
          and be able to print them out in a report form.

       o  To take the descriptions of data flows from the user, or from
          the results of the analysis, and be able to print them out in
          a report form.

     The approach to follow for structure chart development will be
     defined in the Methodology Manual.  Documentation formats are
     specified in the Library Development and Operations Task Manual.

3.5  Detailed Design
     Desirable functional capabilities of supporting tools in this phase
     are as follows:

       o  To structure the listing of the detailed design documents
          according to their internal flow control structure.

       o  To provide the capability to list and cross-reference the data
          items defined and referenced.


                                     15

       o  To list all the external references.

       o  To list all the comment statements in a clear stand-out form.

3.6  Software Implementation
     The following tools are either necessary or desirable for this stage
     of development:

       o  Preprocessor
          In the detailed design stage, the documents are expected to
          be written in a kind of Program Design Language (PDL) which
          contains many control structures and data structures that
          have no direct equivalence in the FORTRAN 77 language.  It is
          desirable to have a preprocessor to assist in converting
          those structures.  Preprocessors are useful in the following
          two cases.  In the first case, the preprocessor essentially
          takes the source written in an extension of the target
          language (FORTRAN 77) and produces the code which will be
          acceptable to the FORTRAN 77 compiler.  In the second case,
          the conversion of various control structures can take place
          at an earlier stage before the expansion of the PDL to the
          FORTRAN code.

       o  Compilers
          This tool is necessary to translate the source code written
          according to the language standards into the machine code.
          It is desirable for compilers to provide some static analysis
          capabilities, e.g., cross-referencing, external references
          listing, syntax checking, etc.

       o  Assemblers
          This tool is necessary to translate source code written in
          assembler language into machine code.

       o  Text Editors
          This tool provides interactive on-line aids to the programmer/
          user in the development of programs and documents that may

                                     16

          require many updates in a limited period of time.  Fast
          response time in a multiple user environment, and a powerful
          command language which can fully utilize the computer's
          capabilities, while at the same time providing a timely,
          coherent user session, are the primary goals generic to the
          text editor.

          Documentation of development efforts shall follow guidelines
          established in the Software Development Manual.  Procedures
          for code development and implementation are specified in the
          PA Manual and Methodology Manuals.

3.7  Testing
     The aids in these activities can be grouped into two types of analyzers
     discussed in the following:

       o  Static Analyzers
          These tools can examine source code for errors and
          inconsistencies without actually executing the program.
          Several areas classified according to their functions are
          listed.

       o  Code Analysis
          Tools will perform syntax analysis on the source code, extr-
          acting information which can be used later for consistency
          check among modules.  They will also identify certain
          error-prone statements, e.g., computed GOTO, etc. for special
          checking.

       o  Program Structure Checks
          Tools can provide information on the relationships between
          program statements.  The results can be presented in the form
          of program graphs or connectivity tables.  This information
          will be useful in finding the improper loop nestings,
          unreferenced labels, unreachable statements and statements
          with no successors.  Loops without clear loop constructs,
          e.g., loops using IF(X)GOTO, will be identified.

                                     17

       o  Proper Module Interface Checks
          Tools can detect inconsistencies in the declaration of data
          structures and improper linkages among modules.  For example,
          the called and calling routine should have the same number of
          parameters and the corresponding parameters should have
          similar types.

       o  Dynamic Analyzer
          These tools will be able to analyze other programs during
          their execution to check for run-time anomalies and
          correctness.  The following capabilities are desirable:

            o  Monitor Program Run-Time Behavior
               Tools with automated monitor insertions can extract
               bounds in variables or trace variables during execution.
               They can record frequency of traversal in code sections
               and trace execution path.

            o  Automated Test Case Generation
               A program is considered tested if all executable
               statements within the program are executed at least
               once.  Automated tools can aid programmers in generating
               test cases when statements and branches not exercised
               are detected.

            o  Conditional Testing
               Tools can aid programmers in setting up statements for
               variables' range checks and checkpoint for various
               conditional checks on the validity of data.

               Methods for testing and debugging will be specified in
               the Methodology Manual.  Standards to be met and
               procedures to follow will be specified in the PA
               Manual.




                                     18

3.8  Training
     The use of Computer Aided Instruction can provide direct assistance to
     the users in learning the system or certain features of the system.
     Drills, practice exercises, and tutorial sequences are typically
     presented.  Dialogue between user and computer about instruction content
     is usually included for flexibility and effectiveness in the learning
     processes.

3.9  Configuration Control
     Tools can aid the configuration control effort in monitoring the
     correspondence between documents resulting from different
     development phases.  Tools can maintain and keep track of all
     changes to the software development and the related documents.

3.10 Documentation
     Documentation for the software development is needed in all phases.
     However, tools are especially useful in generating and maintaining
     documentation for software.

     Several areas that may be supported by tools are listed as follows:

       o  Cross-Reference Generators
          Tools can provide cross-reference listings of all variables,
          statements, labels, symbols, and addresses in the program.

       o  Module Spec Generator
          For each module, tools can be used to prepare specification
          documents.  Input/output data requirements, process
          descriptions, and hardware/design constraints can be
          maintained or generated by those tools.

       o  Flowchart Generator
          Tools may be used to generate flowcharts from the program
          source listings.




                                     19

       o  Data Definition Generator
          Tools can assist in keeping track of the complete sets of
          definitions for variables and other information items in the
          software system.

       o  Interface Analyzer
          Analysis tools can be used to generate information on the
          interfaces within the software system.

3.11 Management
     Tools may assist the management planning efforts in producing the
     following two charts.

       o  PERT/CPM Charts
          The Program Evaluation and Review Technique/Critical Path
          Method is a management technique to control large-scale,
          long-term projects. The resulting charts from this management
          technique will show the allowed time frame planned for each
          step and the relationship of the completion of each step to
          related activities in the preceding and succeeding steps.
          Tools may generate the entire chart with flexibility in both
          the time frame and organization of various activities.

       o  GANTT Charts
          This is a Project schedule chart which contains major/minor
          milestones including start/stop dates and individual task
          duration in a format convenient for in-process monitoring.
          Tools may generate the Gantt Chart based on the essential
          data from management planning.

          Project Management shall oversee these efforts.  The Library
          Development and Operations Task Manual will specify the
          format of the Project Management Manual within which these
          charts will be found.




                                     20

SECTION 4 - REFERENCES

     A.  AMCP70-4

     B.  De Marco, Tom, "Structured Analysis and System Specification",
         Prentice Hall, Inc., 1979.

     C.  Computer Sciences Corporation, "Library Development Task Plan",
         1982.

     D.  Computer Sciences Corporation, "Methodology Synopsis for
         Detailed Design, Implementation, and Testing", December, 1981.

     E.  Computer Sciences Corporation, "Project Management Plan", 1982.


     F.  Computer Sciences Corporation, "Project Product Assurance Plan",
         1982.

     G.  Technical Design of California and Computer Sciences
         Corporation, "Structured Analysis and Design Seminar", 1981.

     H.  Computer Sciences Corporation and 2GCHAS Project Office,
         Aeromechanics Laboratory USARTL (AVRADCOM), "Type A System
         Specification", July, 1982.

     I.  Military Standard MIL-STD-490, "Specification Practices",
         October 30, 1968.

     J.  Yourdon, Edward and Constantine, Larry L., "Structured Design",
         Prentice Hall, Inc., 1979.







                                     21
