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