NASA Software Documentation Standard Appendix C

APPENDIX C

MANAGEMENT PLAN DATA ITEM DESCRIPTIONS

This appendix contains the specifications for the format, outline, and content of the Management Plan and rolled-out sections. Major sections of the Management Plan have been rolled-out into separate Data Item Descriptions (DIDs) using Template DID (NASA-DID-999) for purposes of clarity and manageability.

The Management Plan DIDs provide outlines for the complete Management Plan documents. Major sections of the Management Plan point to lower level DIDs that contain more detailed content descriptions of these major sections.

The number of Management Plan documents generated does not have to reflect the number of DIDs presented in this section. Lower-level detailed DIDs provide additional substructure and contain content discussion which should be reviewed even when the content is recorded in-line (i.e., not rolled-out).

The detailed DIDs in this appendix may be used as they stand to produce separate documents of the Management Plan.

	Table C-1.  Management Plan DIDs (Numeric Order)

DID Number Title

NASA-DID-M000 Management Plan DID NASA-DID-M100 Acquisition Activities Plan DID NASA-DID-M200 Development Activities Plan DID NASA-DID-M210 Training Development Plan DID NASA-DID-M300 Sustaining Engineering and Operations Activities Plan DID NASA-DID-M400 Assurance Plan DID NASA-DID-M500 Risk Management Plan DID NASA-DID-M600 Configuration Management Plan DID NASA-DID-M700 Delivery and Operational Transition Plan DID

Table C-2. Complete DID Set for a Management Plan

NASA-DID-M000 Management Plan NASA-DID-M100 Acquisition Activities Plan NASA-DID-M200 Development Activities Plan NASA-DID-M210 Training Development Plan NASA-DID-M300 Sustaining Engineering and Operations Activities Plan NASA-DID-M400 Assurance Plan NASA-DID-M500 Risk Management Plan NASA-DID-M600 Configuration Management Plan NASA-DID-M700 Delivery and Operational Transition Plan

NASA-DID-M000
MANAGEMENT PLAN
DATA ITEM DESCRIPTION

1.0	INTRODUCTION
2.0	RELATED DOCUMENTATION
3.0	PURPOSE AND DESCRIPTION OF 
4.0	RESOURCES, BUDGETS, SCHEDULES, AND ORGANIZATION
4.1		Business Practices Definition and Revision Process
4.2		Work Breakdown Structure
4.3		Resource Estimation and Allocation to WBS
4.4		Work Authorization
5.0	ACQUISITION ACTIVITIES PLAN
6.0	DEVELOPMENT ACTIVITIES PLAN
7.0	SUSTAINING ENGINEERING AND OPERATIONS ACTIVITIES PLAN
8.0	ASSURANCE PLAN
9.0	RISK MANAGEMENT PLAN
10.0	CONFIGURATION MANAGEMENT PLAN
11.0	DELIVERY AND OPERATIONAL TRANSITION PLAN
12.0	ABBREVIATIONS AND ACRONYMS
13.0	GLOSSARY
14.0	NOTES
15.0	APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

3.0 PURPOSE AND DESCRIPTION OF

Describe the purpose, scope, and major functions of the software being acquired by the organization preparing this plan. Describe in terms that provide a background for understanding the objectives for the management planning information presented in this document. If appropriate, reference sections of the Product Specification for additional detail. Include a system decomposition tree for the entire software system which clearly shows all CSCIs, CSCs, and CSUs and their relationships.

4.0 RESOURCES, BUDGETS, SCHEDULES, AND ORGANIZATION

The purpose of this section is to describe the business aspects of the software acquisition and/or development. In some cases, all of the material that belongs in this section is detailed in the contract. In such cases, this section should contain pointers to the appropriate sections of the contract.

4.1 Business Practices Definition and Revision Process

4.1.1 Definition of Activities

Define the practices, tasks, and activities to be accomplished as the basis for budgeting, scheduling, etc.

4.1.2 Method and Approach

Describe the method and approach for the business practices to be employed in managing the activities that are the subject of this plan. For example:

a. Determining measurable cost projections

b. Determining feasible schedule projections

c. Analyzing possible impacts of proposed changes

d. Analyzing cost effectiveness

e. Determining overhead (indirect cost) rates and allocation

f. Schedule performance

4.1.3 Reporting, Monitoring, and Revision

List the status, performance, review, change request, lessons learned, etc., reports to be used for monitoring and controlling the activities that are the subject of this plan and specify for each report:

a. Purpose

b. Summary of content

c. Who is responsible for generation

d. Schedule of submission

e. Distribution

f. Access restrictions

g. Analysis to be performed on report data

h. Retention period

i. Retention location

Procedures governing the preparation, routing, storage, modification, etc., of reports are included in the repository of procedures, guides, practices, etc., that supplement the software documentation set. The reports themselves are included in, or tracked by, the Management, Engineering, and Assurance Reports.

Describe the monitoring process to identify and react to:

a. Problems that require management attention

b. Variances in actual versus planned cost performance

c. Variances in labor, overhead, and other rates on which budget and actual costs are based

d. Variances in actual versus planned schedule performance

e. Variances in specified versus actual product quality, including documentation

f. Other significant differences between actual and planned performance

Describe the revision process including analysis of the effects of both authorized changes and replanning actions on technical performance, schedules, or cost. Also describe the process for obtaining authorized changes and for revising budgets and schedules.

Explicitly prohibit retroactive changes to records pertaining to work performed that will change previously reported amounts for direct costs, indirect costs, and budgets, except for normal accounting adjustments.

Specify cost control measures to be employed, and describe how costs are to be monitored.

4.2 Work Breakdown Structure

Describe the logical structure for managing acquisition and development (or relevant section thereof) by means of a Work Breakdown Structure (WBS) scheme that is coordinated with the resource allocation described in Section 4.3. An activities-oriented rather than an organization- or product-oriented WBS is recommended. The level of detail given in the WBS should be sufficient to support sound management practices. Further, it may be appropriate for the WBS to be placed in a management planning system and a pointer to that information given in this section.

4.2.1 Activity Definition

For purposes of the WBS, identify the activities to be undertaken. Define these in terms of a descriptive statement in operational terms of activities and identification of the products to be delivered.

Describe the WBS in terms of:

a. A hierarchical structure for controlling the sequences and interdependencies of key activities and responsibilities.

b. Setting objectives and ground rules.

c. Relating activities to products.

The number of WBS levels required is a function of such factors as:

a. Size of effort

b. Volume of activity

c. Cost account structure

d. Number of personnel engaged in a WBS activity

e. Task duration and schedule

f. Number of milestones in each task

g. Implementation cost

h. Risk assessment

4.2.2 Cost Account Definition

Identify and define the cost accounts to be associated with the WBS and its structure. For example, a cost account may be established for each level in the WBS and for each cost category such as direct labor, material, and indirect costs.

Describe cost accounting methods to be used in such terms as:

a. Cost centers

b. Performance control systems

c. Calculation of budgeted cost of work scheduled

d. Calculation for budgeted cost of work performed

e. Analysis of variance

4.3 Resource Estimation and Allocation to WBS

The purpose of this section is to list and describe the resources available to support the activities defined in the WBS. The resources may include funds, personnel, facilities, government-furnished equipment (GFE), reusable software libraries, etc.

4.3.1 Schedules

Present the schedules on which performance and resource planning are based. Depending upon the scope and complexity of the activities that are the subject of the plan, schedules may be presented at several levels: a master schedule, intermediate level schedules, and detailed schedules. It may be appropriate to place schedule information in a management planning system and a pointer to that information given in this section. Note that all schedule information should be included in this section only.

Schedules are normally based on the accomplishment of identified milestones. Milestones frequently mark transition points at which a product is passed from one activity to another. Supplement major milestones with intermediate ones to provide frequent points at which progress can be assessed. Identify milestones in terms of a product or measurable event, a date, and a brief description.

Describe the master schedule in terms of:

a. Specific activities

b. Organizations affected

c. Specific milestones and deliverables

d. Delivery dates for acquired products and services

Describe subordinate schedules to be developed by performing organizations if their plans are incorporated within this document. Detailed subordinate schedules may be integrated into intermediate-level schedules and finally into the master schedule. Prepare subordinate schedules for each activity being managed.

Scheduling detail includes:

a. Major and intermediate milestones (usually marking the delivery of products from one organization to another)

b. Unique units of work

c. Start and completion dates

d. Responsibility for performing the work

e. Integration with detailed engineering, coding, and other schedules as applicable

f. Ongoing, level-of-effort type activities for which discrete portions with starting and ending dates cannot be identified

4.3.2 Funds and Budgets

The purpose of this section is to establish the funding plan and budgets for the activities that are the subject of this plan.

Describe the funding plan, if applicable, in terms of funding projections, the rate of expenditure of allotted funds, and the funding year with respect to the calendar or fiscal year. Termination costs incurred in the event that an activity is terminated at any point in time must also be incorporated.

Describe funding limits in terms of total monetary obligation, yearly funding limits, overrun alternatives including company-provided funds, customer- approved rescheduling to reduce rate of expenditure, and termination of work when funding expires.

Describe the budget, and considerations affecting the budgeting process, in such terms as:

a. The cost, size, complexity, and importance of the activity for which the budget is being prepared

b. Negotiation schedules

c. Lower-level cost authorization procedures

d. The types of cost accumulations to be used

e. Target budgets for each organization and major activity, including such elements as:

1) Direct labor, by labor category

2) Materials, in dollars

3) Other direct costs

4) Cost-time relationship from start to completion dates

5) Development of Budgeted Cost of Work Scheduled by element of cost

f. Impacts due to rephasing and scheduling delays

4.3.3 Organization

The purpose of this section is to describe in detail the organizational structure for carrying out the activities and processes that are the subject of this plan, and to allocate tasks specifically to each of them. Describe both organizational elements and internal and external organizational relationships and interfaces. Identify:

a. The internal organizations and the elements thereof responsible for performing the planned tasks and activities

b. Interfaces between internal organizational elements, and with external organizations, and describe the responsibilities of each party to each interface

c. The individuals responsible for particular work items

d. Managers responsible for control

e. Control, advisory, and coordinating bodies such as Configuration Control Boards, including working groups and panels

Estimate staffing needs and allocate personnel to WBS activities in terms of:

a. Names or titles of key personnel

b. Qualifications and experience

c. Labor categories

d. Skill levels

e. Work assignments

f. Geographic location

g. Security level required

h. Availability to work extended hours

i. Time (hours, weeks, or months)

j. Hiring plans

k. Labor cost accounting

4.3.4 Equipment

Describe all required equipment in terms of:

a. Support for all functions to be performed throughout the life cycle

b. Source, and if an item is to be acquired, whether it will be purchased, leased, or rented

c. References to property management procedures to be observed

4.3.5 Materials, Facilities, and Other Resources

Describe physical facilities available or needed to support development and operational activities. Specify the criteria to ensure that facilities satisfy support requirements. Describe availability and allocation of facilities in terms of:

a. Purpose b. Location c. Use d. Responsibility for operations cost e. If not already available, the means for acquisition (e.g., by capital development, purchase, or lease) f. References to property management procedures

As appropriate, include or refer to drawings, floor plans, and other graphic representations of the facilities.

Describe materials in terms of:

a. Support for the work being accomplished

b. Source (e.g., purchase, interdivisional work order)

c. Material control procedures

Describe other resources such as management software systems, communication networks, etc.

Identify and describe resources that must be acquired, and for each indicate:

a. Source or supplier

b. Date by which needed, acquisition lead time, and likelihood and impact of possible delays

c. Specification of the resource in terms appropriate to a purchase order, statement of work, etc.

d. Method of acquisition (purchase, rental, lease, etc.)

e. Estimated cost and source of funding

4.3.6 Management Reserves

Describe the estimation and allocation of management reserves in terms of:

a. Percentage withheld

b. Allocation criteria

c. Allocation procedure

4.4 Work Authorization

Describe the work authorization process in terms of the actions required to initiate, control, and terminate work. As applicable, describe the work authorization process in terms such as:

a. Specific work authorization statements including:

1) Complete statement of work to be performed

2) Resources provided

3) Technical and administrative direction

4) Work assignment and authorization

5) Reporting

b. Relationship to the Work Breakdown Structure

c. Schedule, including start, completion, intermediate milestones, and interface events

d. Budget, divided into labor, materials, and other direct costs

e. Supporting organizations

f. Identification of work authorization forms, contracts, purchase orders, etc., to be used

g. References to applicable Product Specifications, drawings, and other documents

h. Any special terms, conditions, or limitations

If the process is complex, include a work authorization process chart for clarification.

5.0 ACQUISITION ACTIVITIES PLAN

The purpose of this section is to specify tasks to be performed to manage the acquisition of the software. This section also identifies acquisition requirements and constraints, and specifies the standards to be applied for development and assurance.

The acquisition activities plan includes:

a. Procurement Activities Plan

b. Organizational Requirements and Life Cycle Adaptations

c. Management Approach

d. Technical Approach

Refer to the Acquisition Activities Plan DID (NASA-DID-M100) for a further description of the structure and content under each topic.

6.0 DEVELOPMENT ACTIVITIES PLAN

The purpose of this section is to describe the development process and engineering planning. This plan must meet the requirements stated in the contract and/or the acquirer's Management Plan.

The development activities plan section includes:

a. Methodology and Approach

b. Products and Reports

c. Formal Reviews

d. Interface Control Plan

e. Training for Development Personnel Planning

Refer to the Development Activities Plan DID (NASA-DID-M200) for further description of the contents of the development planning subsections.

7.0 SUSTAINING ENGINEERING AND OPERATIONS ACTIVITIES PLAN

The purpose of this section is to describe the plan for sustaining engineering and supporting operation of the software as installed in the overall system in terms of activities, methods and approach, controls, and support environment requirements. It is important to address activities after delivery of the software and prior to initiation of sustaining engineering and operations for the software in question.

The primary topics for the plan are:

a. Sustaining Engineering and Operations Processes

b. Product Support and Delivery

Refer to the Sustaining Engineering and Operations Activities Plan DID (NASA-DID-M300) for a further description of the structure and content for each topic.

8.0 ASSURANCE PLAN

Describe the activities to be performed by the organization preparing this Management Plan (or an assurance provider) for assurance of the software. Assurance activities include:

a. Review and acceptance testing of products

b. Verification and validation

c. Reliability and maintainability assurance and audits

d. Security and safety assurance

e. Certification

Refer to the Assurance Plan DID (NASA-DID-M400) for a further description of the structure and content for each topic.

9.0 RISK MANAGEMENT PLAN

The purpose of the Risk Management Plan is to identify potential risks affecting development or acquisition, specify analysis and monitoring methods including data collected, and state measures to control or minimize the effects of the risks.

The primary topics for the plan include:

a. Risk Assessment and Evaluation Process

b. Technical Risks

c. Security Risks

d. Safety Risks

e. Resource Risks

f. Schedule Risks

g. Cost Risks

Refer to the Risk Management Plan DID (NASA-DID-M500) for a further description of the structure and content under each topic.

10.0 CONFIGURATION MANAGEMENT PLAN

Describe the activities and plans for configuration management to be performed by the organization preparing this Management Plan. The primary topics for the plan include:

a. Configuration management process

b. Configuration control activities

c. Configuration identification

d. Configuration change control

e. Configuration status accounting

Refer to the Configuration Management Plan DID (NASA-DID-M600) for a further description of the structure and content for each topic.

11.0 DELIVERY AND OPERATIONAL TRANSITION PLAN

The purpose of this section is to specify and coordinate the activities for delivering and installing the software to be performed by the organization preparing this Management Plan.

The topics for the plan include:

a. Support Preparation

b. Delivery and Installation Planning

c. User Training

d. Deliverable Item List

Refer to the Delivery and Operational Transition Plan DID (NASA-DID-M700) for the detailed contents of this section.

12.0 ABBREVIATIONS AND ACRONYMS

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

13.0 GLOSSARY

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

14.0 NOTES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

15.0 APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

Return to Beginning of Appendix

NASA-DID-M100
ACQUISITION ACTIVITIES PLAN
DATA ITEM DESCRIPTION

1.0	INTRODUCTION
2.0	RELATED DOCUMENTATION
3.0	PROCUREMENT ACTIVITIES PLAN
3.1		Procurement Package Preparation
3.2		Proposal Evaluation
3.3		Contract Negotiation
3.4		Procurement Risks
4.0	ORGANIZATIONAL REQUIREMENTS AND LIFE CYCLE ADAPTATIONS
4.1		Business Practices, Resources, and Organizational Requirements
4.2		Life Cycle Adaptations and Approved Waivers
5.0	MANAGEMENT APPROACH
5.1		Software Management Responsibilities
5.2		Categorization and Classification Policy
5.3		Management Mechanisms
5.4		Documentation Requirements
5.5		Risk Management
5.6		Configuration Management
5.7		System Assurance and Integration
5.8		Deviation and Waiver Procedures
5.9		Maintenance of Management Plan
6.0	TECHNICAL APPROACH
6.1		System Requirements and Constraints
6.2		Integrated System Description
6.3		Software Requirements Definition Process
6.4		Software Design and Implementation Process
6.5		Software Test and Delivery Process
6.6		Software Maintenance and Updating Process
6.7		Software System Engineering
7.0	ABBREVIATIONS AND ACRONYMS
8.0	GLOSSARY
9.0	NOTES
10.0	APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

3.0 PROCUREMENT ACTIVITIES PLAN

Describe the procurement activities and events to be conducted and identify who will be responsible, where the activity will be performed, and when the activities will occur for each planned procurement.

3.1 Procurement Package Preparation

If appropriate, describe the justification for acquisition in terms of:

a. Existing resources:

1) Personnel

2) Equipment

3) Schedule

4) Funding availability

b. Alternatives considered; for each, address:

1) Added resources required

2) Commercial and inheritable capabilities available

3) Potential providers' capabilities

4) Reason for rejection or acceptance of alternative

Describe the steps to be taken to prepare the procurement package, such as:

a. Preparation of a Statement of Work

b. Development of a Work Breakdown Structure

c. Specification of a Data Requirements List

d. Specification of Contract Line Item Numbers

e. Development of associated schedule and cost information

3.2 Proposal Evaluation

Describe the proposal evaluation and selection activities to include formation of a Source Selection Evaluation Board, evaluation of documentation submitted by the bidders, and standards and practices to be followed. Describe the methods to be employed to evaluate pricing data, personnel qualifications, performance record, schedules, and quality attributes discussed in the proposals.

3.3 Contract Negotiation

Describe considerations which will govern contract negotiations including:

a. Cost and schedule adjustments

b. Technical and product adjustments

c. Access rights to commercial, reusable, and support computer hardware/software

d. Subcontractor management

e. Reporting requirements

3.4 Procurement Risks

Identify and describe procurement risks and contingencies that need to be assessed and handled during the procurement process. Describe the approach to be used to control or minimize the risks. In particular, address risks affecting at least:

a. Schedule, especially as affected by availability of personnel and equipment

b. Budget, especially as affected by funds allocation process, timing considerations, and costing methods

4.0 ORGANIZATIONAL REQUIREMENTS AND LIFE CYCLE ADAPTATIONS

4.1 Business Practices, Resources, and Organizational Requirements

Describe all requirements for business practices, methods, reporting, metrics, etc. Describe any requirements being imposed with respect to organizational structure; independence of verification and validation; and interfaces with the acquirer, other providers, and other external organizations. Include any other resource requirements such as use of government-furnished equipment or facility access and security requirements.

4.2 Life Cycle Adaptations and Approved Waivers

Describe life cycle adaptations, which include products and reviews, and any approved waivers required in the management, development, and assurance of the software. Include any life cycle adaptation requirement for a phased delivery or incremental development approach.

An example of an adaptation may be the use of prototyping in feasibility studies, risk assessments, or design evaluations. Other adaptations may be requested for accommodating integration of other software being acquired which are GFE or COTS.

Describe the requirements during development to accommodate evolutionary acquisition of major upgrades (i.e., complete iterations of the life cycle) of the software.

5.0 MANAGEMENT APPROACH

Address the following items, which are of fundamental interest to project, field installation, and NASA Headquarters management.

5.1 Software Management Responsibilities

Identify all software for which the project is responsible and identify which organization(s) have responsibility (either total or partial) for which software. Include a clear delineation of software accountability. In addition, by using direct references to the organization chart for the project, identify the title of the person or organization responsible for the software deliverables.

5.2 Categorization and Classification Policy

The purpose of this section is to carefully explain the project's approach toward categorizing lower level elements (such as CSCIs) within a software system. If some lower level elements are more critical than others and thus will be managed differently, explain the criticality criteria, along with the difference in management as a function of criticality. If a project's entire software plan applies only to a selected subset of the effort, explain the criteria used to choose the selected subset.

Specify the risk classification (including safety and security considerations) for the lower level element with respect to its safety and criticality.

Describe the assurance requirements in terms of:

a. Level of assurance and types of activities, including any special requirements such as those for assurance of safety and security requirements

b. Product and quality assurance methods

c. Constraints affecting assurance approach, scope, or effectiveness

d. Testing methods to be employed, types of testing to be performed, and testing approaches

e. Verification and validation measures to be performed, and degree of independence required

f. Certification activities, if any

g. Products, reports, and metric data to be delivered

5.3 Management Mechanisms

Explain how the project is going to function from a management point of view in each of the following areas.

5.3.1 Requirements Development and Control

Identify functionally the major sources of requirements for the software, including the title of the person on the project responsible for generating, coordinating, and controlling these requirements. Include a diagram that defines the management relationship of all major requirements, generators, and software developers. Explain the way in which the project intends to control the requirements, both during the initial generation phase and when the software design is underway.

5.3.2 Schedule Development and Control

Identify the levels of software scheduling that will be used by the project and explain how these schedules will be integrated with the non-software elements of the project. Identify the titles of the persons and organizations responsible for both monitoring and implementing these schedules. Discuss the mechanisms used to report status against these schedules and to change milestone dates as a function of both the phases of the project and the hierarchy of schedules.

5.3.3 Resource Development and Control

Clearly identify the management process that will be used to determine the first estimate of the resources (people, budget, computer time, etc.) required to implement a set of software requirements on a given schedule. Provide an explanation of the mechanisms the project will use to ensure consistency throughout the phases of the project between the software schedules, requirements, and resources. Define those interaction mechanisms (between field installation and/or agencies, as well as between contractors and Government agencies) required to ensure this consistency.

5.3.4 Internal Review Concepts

Explain how and when the project intends to review its own software. Define the kinds of reviews and their purposes. Identify the reviewers with particular attention to their relationship to the eventual users of the software.

5.3.5 External Review Concepts

Explain external review processes to be used to bring a system of checks and balances to the software development process. Give particular attention to the project's plan with respect to inclusion of nonproject personnel in major review activities and the identification of any independent verification and validation effort for the most critical elements of the software. Define the schedule for the reviews and verification.

5.3.6 Board Support

Describe the activities to be performed in support of control boards, working groups, etc. Define any reports to be generated by that activity.

5.3.7 Management and Control

Describe the activities relative to management activities during the life cycle, including monitoring, control of costs, schedules, etc. This section should include a description of the baselining process for products delivered to the acquirer. Define any reports and their content to be generated by this activity.

5.4 Documentation Requirements

Identify, by title and function, those documents that the project will use to manage the software process. Identify variations in the documentation requirements based upon the categorization policy in Section 5.2. Address the personnel and organizations responsible for creation, review, approval, maintenance, and control of the requirements.

5.5 Risk Management

Identify the areas of risk of particular concern and that shall be specifically addressed in the Risk Management Plan. Describe the requirements affecting risk evaluation and control, including types of data to be collected and assessed.

5.6 Configuration Management

Explain the software configuration management techniques to be used. Give particular attention to explaining any variations in the software configuration management scheme that may be a function of project phase, type of software, or software category as defined in Section 5.2. Clearly define the relationship between the software configuration management approach and that employed by the remainder of the project.

Describe the requirements for configuration management activities to be addressed in the Configuration Management Plan, including any requirements for interface between the acquirer's and provider's configuration management. Include any identification (naming) conventions and metrics or other status data required. Include any special security and safety process requirements for configuration management such as access restrictions.

Describe all metrics, reports, or related information.

5.7 System Assurance and Integration

Identify the mechanisms the project will employ to assure the quality of the software development process, as well as the end product. Address the tests by which the project will verify and validate that the project software/hardware systems operate together to meet the mission specifications.

5.8 Deviation and Waiver Procedures

Explain the procedures that will be followed to permit variations from the processes outlined in the software plans. Describe the approval process that allows deviation or waiver from the rules in the Management Plan.

5.9 Maintenance of Management Plan

State the method by which the Management Plan will be maintained. Address whether or not the plan will be updated incrementally or periodically and who will approve changes to the plan.

6.0 TECHNICAL APPROACH

The following topics shall be addressed as part of the technical approach.

6.1 System Requirements and Constraints

Describe the top-level functional requirements that must be satisfied by the various elements of the project software. In addition, enumerate and explain the major project constraints on the software systems, including such items as inheritance from past projects, the precise computer(s) to be used, and other constraints that inhibit freedom of system design.

Describe any requirements affecting engineering and integration activities, such as:

a. Specific languages, such as use of Ada for software

b. Specific hardware

c. Use of specific tools or support environments

d. Use of techniques, such as prototyping

e. Specific inheritables or reuse

f. Any special security or safety considerations for the engineering and integration process

6.2 Integrated System Description

Describe and show a pictorial representation of the functional relationship between the various elements of the project software activity, as well as between the software and the hardware. Of particular importance are functional descriptions of the top-level interfaces between systems. Include an annotated generic diagram explaining the information flow from end-to-end.

6.3 Software Requirements Definition Process

Describe the major steps the project will follow leading up to the definition of the requirements for the software. Of particular interest are schedules for requirements definition, how implementing organizations will assess and/or approve the requirements, levels of detail contained in the requirements documents, and mechanisms employed to categorize or prioritize requirements.

6.4 Software Design and Implementation Process

Describe the major steps the project will follow to develop software that will meet the defined requirements. Milestone definitions, coding and checking concepts, functional allocation assessments, and schedules for software design and implementation should be included in this topic. If different types or categories of software follow a different process, identify the variations.

6.5 Software Test and Delivery Process

Describe the major test categories for the software, including not only the purposes of each test and its tie to requirements, but also the way in which each test will be evaluated. Schedules for testing should also be listed. Explain the interaction between the test process and the eventual software usage. Identify the checklist of prerequisites that must be satisfied before a software program or group of programs is "ready." Include in the checklist a list of deliverables and a list of participating organizations. Present variations in this process as a function of the categorization described in Section 5.2.

Describe the requirements for delivery such as:

a. Sites and methods for installation

b. Installation support

c. Conversion of existing data to new formats

d. Acceptance process

e. Final approving organization

f. Provisions for training the users and operators

g. Any special requirements such as for safety and security

6.6 Software Maintenance and Updating Process

Describe the major steps the project will follow after software has been declared "ready." In particular, describe how the project will manage changes in delivered software in response to both errors and new requirements, what criteria will be used for determining what capabilities go with what deliveries (if phased deliveries are part of the overall software schedule), and how the test and delivery process for a second or third revision of a program or group of programs differs from the test and delivery of the initial version of the program.

6.7 Software System Engineering

Describe the project's approach to software system engineering, including an explanation and schedule of technical tasks to be performed. Include the following topics.

6.7.1 Implementation Policies and Standards

Identify the top-level policies and standards that will be used in the development of the software throughout the project.

List or otherwise identify the standards that are applicable to the development, assurance, and management of the software, including any engineering and technical standards.

List or otherwise identify standards specified relating to use of a support environment(s) with respect to the management, development, and assurance of the software being acquired.

6.7.2 Interface Control Process

Identify the mechanisms that will be used to control interfaces between major subsystems (such as CSCIs or CSCs) of the software. Explain the kinds of items to be controlled, type of documentation to be used, and testing process used to verify the interfaces.

6.7.3 Data Generation and Management Process

Explain how the project will generate and manage the database of numbers that must be used by the software during operations. Identify the sources for data that will be used to test the software.

6.7.4 Performance Assessment Process

Explain how the project intends to monitor the performance of software as it is being developed. Specifically, identify those review activities and/or tests, including where they occur on the schedule, that will permit an accurate assessment of the most important performance parameters (size, timing, etc.). Describe all metrics, reports, or related information.

6.7.5 Operations Maintenance Process

Explain how the project intends to maintain the operational software once it is on-line. This explanation should address such issues as failure reporting, preventative maintenance, and fault protection procedures.

Describe the requirements for the sustaining engineering support such as:

a. Provision of technical assistance

b. User support and training

c. Modification and release of product

d. Assurance including regression testing and recertification

7.0 ABBREVIATIONS AND ACRONYMS

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

8.0 GLOSSARY

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

9.0 NOTES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

10.0 APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

Return to Beginning of Appendix

NASA-DID-M200
DEVELOPMENT ACTIVITIES PLAN
DATA ITEM DESCRIPTION

1.0	INTRODUCTION
2.0	RELATED DOCUMENTATION
3.0	METHODOLOGY AND APPROACH
3.1		Development Engineering
3.2		Prototyping
3.2.1			Purpose and Objectives
3.2.2			Products and By-Products
3.2.3			Feasibility and Risks
3.2.4			Description of Characteristics and Methods
3.2.5			Analysis and Evaluation
3.3		Integration
3.4		Engineering and Integration Support Environment
4.0	PRODUCTS AND REPORTS
4.1		Baselining Process
4.2		Product Specification Roll-Out Definition
4.3		Assurance and Test Procedures Roll-Out Definition
4.4		Reports
5.0	FORMAL REVIEWS
6.0	INTERFACE CONTROL PLAN
6.1		Technical Interfaces
6.2		Interface Controls
7.0	TRAINING FOR DEVELOPMENT PERSONNEL PLANNING
8.0	ABBREVIATIONS AND ACRONYMS
9.0	GLOSSARY
10.0	NOTES
11.0	APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

3.0 METHODOLOGY AND APPROACH

Describe the overall approach for engineering and integration. Describe applied engineering methods and techniques to be employed during development.

3.1 Development Engineering

Describe the development engineering planning in terms of:

a. Life cycle definition including use of phased delivery and incremental development, and product deliveries

b. Statement of applicable standards

c. Engineering methods and techniques, such as requirements analysis approach, including interfaces between various methods across the life cycle. Such methods can be rolled-out into a separate methods document.

d. Trade-off studies, design rationale, etc.

e. If prototyping is intended to be used as a technique within any phase of the life cycle, then the plan for conducting the prototyping process should be detailed in Section 3.2. Use of the results of prototyping should be incorporated into the development planning section.

f. Informal reviews and walkthroughs

g. Informal engineering notes or products

h. Definition of engineering process and product metrics to be collected and assessed

i. Any special considerations, such as security, which could affect the engineering and integration process

j. Training materials development. If the development of the training materials is a major task, then this may be detailed further (in-line or separately) using the Training Development Plan DID (NASA-DID-M210).

3.2 Prototyping

The purpose of the Prototyping Plan is to define the prototyping process to be used within a specific phase(s) of the life cycle.

3.2.1 Purpose and Objectives

Describe the purpose and scope of the prototyping process, including in which phase(s) of the life cycle it is to be used and for what objectives.

Generally, prototyping is used to minimize risk by examining factors such as:

a. Technical feasibility

b. Performance capacities

c. Evaluation of alternatives

d. End user interface and user friendliness

e. Safety and reliability features

f. Trade-offs for allocation of requirements among software

Describe the specific objectives of the prototyping process to be used and its role in and interface to the development life cycle. If the prototyping process requires a major development for a lab bench or other such facility, then that shall be treated as a separate acquisition and shall require its own Management (Development) Plan, Product Specification, and Assurance and Test Procedures. This plan shall only address the use of such a facility in the prototyping process.

3.2.2 Products and By-Products

Describe the primary products of the prototyping process and how these products will be used in the engineering process of the software. For example, the final report from the prototyping process may be an input to the requirements or design of the software.

Make reports of prototyping activities accessible through the Management, Engineering, and Assurance Reports for this software.

If applicable, identify the by-products of the prototyping process. By-products may include hardware, software, models, and data which may be reused at management discretion in future prototyping or in development.

3.2.3 Feasibility and Risks

Prototyping in general, is used to reduce risks and evaluate trade-offs. Describe the expected feasibility of using the prototyping process to produce meaningful results for the development trades analysis process. Describe risks in terms of resources (equipment, time, software, etc.), technical factors, etc., and their effect upon the development process.

Consider the following factors, as appropriate:

a. Operational limitations and constraints (e.g., emulation of interfaces) that will inhibit prototyping in a realistic environment

b. Support limitations or constraints that will limit the effectiveness of the prototyping effort

c. Analytical limitations or constraints that will limit the ability to evaluate data resulting from prototyping

d. Resource limitations and constraints that will inhibit realistic representation

3.2.4 Description of Characteristics and Methods

Describe the characteristics of the prototyping process such as system tools used, software models, hardware breadboards, etc. Describe prototyping methods to be used, such as simulation, evaluation, use of software and hardware models, mock-ups, etc.

3.2.5 Analysis and Evaluation

Describe the process by which prototyping results will be analyzed. Describe how primary products of the prototyping process will be evaluated prior to incorporation into the development process' engineering analysis and products.

3.3 Integration

Describe the integration approach for the software in terms of the integration methodology applied, including use of phased delivery and incremental development, relationship to informal and formal revisions, and testing and product assurance. Describe the relationship with the developer's integration testing as defined in the Assurance Plan section of the Management Plan.

3.4 Engineering and Integration Support Environment

Describe the specific engineering and integration environment to be used for engineering and integration in terms of:

a. Which techniques and tools are required in what phase, including technical management support and documentation tasks

b. Support for generation and management of reports

c. How to accept and apply new support environment tool releases to the integration environment

d. How to adapt and apply the standard support environment engineering and integration rules and tools for this development, including a description of the tailoring process

e. The interface with the acquirer's environment for data and product releases

f. Any special restrictions on this environment, such as access restriction for security or safety

Also include any interfacing and support software including operating systems, pre-processors, test drivers, test data generators, and post-processors to be used.

4.0 PRODUCTS AND REPORTS

4.1 Baselining Process

Identify the baselining process to be used for deliverable products and the interface between the acquirer's and provider's baselining process. Include the role of formal reviews and configuration audits in the baselining process.

4.2 Product Specification Roll-Out Definition

Define which sections of the Product Specification are applicable to this development and their intended release per life cycle phase. Define intended roll-out definition for the Product Specification document.

4.3 Assurance and Test Procedures Roll-Out Definition

Define which sections of the Assurance and Test Procedures are applicable to this development and their intended release per life cycle phase. Define the intended roll-out definition for the Assurance and Test Procedures document.

4.4 Reports

Define what reports are to be generated or managed, their frequency, and content. Samples of specific report forms and instructions for completing them should be included in a standards and procedures repository or an appendix to this document. Make all reports accessible through the Management, Engineering, and Assurance Reports.

5.0 FORMAL REVIEWS

Describe the formal technical reviews required. Indicate how each review is to be conducted to assess the degree of completion of the development effort appropriate to the major milestone to which the review pertains. Relate these reviews to the product and/or software assurance activities.

Describe:

a. How reviews are conducted

b. Who must attend

c. Handling of discrepancies

d. Decision process associated with a review

6.0 INTERFACE CONTROL PLAN

The purpose of the interface control plan is to define the process by which the developer defines and manages all external interfaces between the software and all users, including human or other software. It may be appropriate to roll-out this plan when there are major coordination concerns and risks between the developer and the organizations responsible for the interfacing units.

6.1 Technical Interfaces

Describe engineering and integration interface control planning in terms of:

a. Identification of major external interfaces that need to be managed and defined

b. Definition of the process by which they are to be defined, including designation of working groups responsible for an interface

c. Identification of the products of the process, including the external interface requirements and design sections of the Product Specification, and reports

Describe all external technical interfaces between the software and its environment, including other software, end users, operators, and communications links.

6.2 Interface Controls

Describe the process by which interfaces are controlled, approved, baselined, etc. Describe the relationship of control processes to standard life cycle reviews and baselines.

7.0 TRAINING FOR DEVELOPMENT PERSONNEL PLANNING

The purpose of this section is to specify and coordinate the training to be conducted for personnel involved in the development effort.

The primary topics for the plan are:

a. Definition of Personnel Requiring Training

b. Types of Training by Categories of Personnel

c. Plan for the Conduct of Courses

8.0 ABBREVIATIONS AND ACRONYMS

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

9.0 GLOSSARY

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

10.0 NOTES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

11.0 APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

Return to Beginning of Appendix

NASA-DID-M210
TRAINING DEVELOPMENT PLAN
DATA ITEM DESCRIPTION

1.0	INTRODUCTION
2.0	RELATED DOCUMENTATION
3.0	REQUIREMENTS FOR PERSONNEL TO BE TRAINED
4.0	CURRICULUM DEVELOPMENT REQUIREMENTS
5.0	EVALUATION AND MODIFICATION
6.0	ABBREVIATIONS AND ACRONYMS
7.0	GLOSSARY
8.0	NOTES
9.0	APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

3.0 REQUIREMENTS FOR PERSONNEL TO BE TRAINED

Identify the types of personnel to be trained, categorizing the types as needed to establish training objectives for each. For each type of personnel to be trained specify:

a. Training goals and objectives

b. Major topics to be addressed in the training

c. Characteristics of the personnel type affecting the training, e.g., educational level, language spoken

d. Number of trainees for each training topic

e. Skill level to be attained through the training

f. Number of persons to be trained (by location if there are multiple sites)

Address all user and operator classes of personnel.

Address what organization will conduct the training and for what length of time the training will be required.

4.0 CURRICULUM DEVELOPMENT REQUIREMENTS

Describe the plan for preparing curricula for each type of training to be delivered and for the preparation of related training materials. Include any constraints on length, type, and amount of training for each class of personnel to be trained.

Describe requirements and any constraints for each class of training on the style and media of the training materials such as:

a. Self study modules

b. Classroom lessons

c. Simulation capabilities

d. On-the-job training plans

Lesson plans and other instructional materials that are prepared to implement training may be included here. Note that actual training materials are part of the Product Specification associated with a specific product.

5.0 EVALUATION AND MODIFICATION

Describe the process by which the training materials will be evaluated and updated. Include a description of metric and assessment data to be collected.

6.0 ABBREVIATIONS AND ACRONYMS

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

7.0 GLOSSARY

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

8.0 NOTES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

9.0 APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

Return to Beginning of Appendix

NASA-DID-M300
SUSTAINING ENGINEERING AND OPERATIONS ACTIVITIES PLAN
DATA ITEM DESCRIPTION

1.0	INTRODUCTION
2.0	RELATED DOCUMENTATION
3.0	SUSTAINING ENGINEERING PROCESS
4.0	PRODUCT SUPPORT
4.1		User Support
4.2		User and Operator Training
5.0	ABBREVIATIONS AND ACRONYMS
6.0	GLOSSARY
7.0	NOTES
8.0	APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

3.0 SUSTAINING ENGINEERING PROCESS

Describe the methods to be used to specify modifications or new functional requirements. Also describe how to translate these requirements into design and how to integrate and test the new system release.

Describe the process by which change requests are to be submitted, classified and analyzed, dispositioned, and scheduled. Include classification categories for requests and any variations in the process. Describe all associated products and reports.

Describe the engineering process, methods, etc., to be used to incorporate approved change requests. Include a description of maintenance procedures for developing on-site and remote diagnostics. Include the method for producing documentation updates (including user support materials) to accompany a release and for distributing them to all operators and end users concerned.

Describe the process interfaces between sustaining engineering (maintenance) engineers and configuration management, assurance, and operator organizations. Describe interfaces with the user community and how releases are generated and delivered.

Describe the training plan for sustaining engineering, operations, and other support personnel.

This section contains planning activities similar to those in the Development Activities Plan (NASA-DID-M200) plus some activities specific to sustaining engineering and operations. The Development Activities Plan (NASA-DID-M200) may be used as a model for substructure and further description.

4.0 PRODUCT SUPPORT

4.1 User Support

Describe support activities to be established to assist users, such as:

a. A help desk to respond to problems reported by users and to represent users on change control and review boards

b. Support of change request generation and submittal

c. Providing users with documentation concerning new and modified capabilities or information in new product releases

Describe how an effective interface is to be maintained between users and maintenance (technical) staff.

Describe activities required to report and service error conditions in terms of classes of errors, specific recovery requirements for the various error conditions, and any changes or modifications to the system resulting from critical error situations.

4.2 User and Operator Training

The purpose of this section is to specify and coordinate the training to be conducted for end users and operators of the software.

Topics to be addressed include:

a. Classes of users to be trained

b. Available curriculum

c. Training delivery

d. Assessment and follow-up training

e. Evaluation of adequacy of training curriculum and materials

f. Facility and equipment requirements for conducting training

5.0 ABBREVIATIONS AND ACRONYMS

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

6.0 GLOSSARY

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

7.0 NOTES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

8.0 APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

Return to Beginning of Appendix

NASA-DID-M400
ASSURANCE PLAN
DATA ITEM DESCRIPTION

1.0	INTRODUCTION
2.0	RELATED DOCUMENTATION
3.0	QUALITY ASSURANCE PLANNING
3.1		Approach and Activities
3.2		Methods and Techniques
3.3		Products
4.0	VERIFICATION AND VALIDATION PLANNING
4.1		Approach and Activities
4.2		Methods and Techniques
4.3		Products
5.0	QUALITY ENGINEERING ASSURANCE PLANNING
5.1		Approach and Activities
5.2		Methods and Techniques
5.3		Products
6.0	SAFETY ASSURANCE PLANNING
6.1		Approach and Activities
6.2		Methods and Techniques
6.3		Products
7.0	SECURITY AND PRIVACY ASSURANCE PLANNING
7.1		Approach and Activities
7.2		Methods and Techniques
7.3		Products
8.0	CERTIFICATION PLANNING
8.1		Approach and Activities
8.2		Methods and Techniques
8.3		Products
9.0	ABBREVIATIONS AND ACRONYMS
10.0	GLOSSARY
11.0	NOTES
12.0	APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

3.0 QUALITY ASSURANCE PLANNING

The purpose of this section to specify the measures and activities to be undertaken to assure the quality of the acquisition or development processes (including configuration management) and their resultant products. Planning shall include activities and measures to assure quality and to evaluate the degree of conformance to plans, standards, and procedures specified in the Management Plan.

3.1 Approach and Activities

The purpose of this section is to describe the detailed quality assurance activities for assessing the conformance to standards and plans of the software products and related processes.

Specify and define the reviews and audits to be conducted to assure that both processes and products fulfill the Management Plan requirements and designated standards and procedures. Address at a minimum the following:

a. Assurance activities to be performed in conjunction with formal reviews, such as the Preliminary Design Review or Critical Design Review, for the purpose of evaluating the quality of the products being reviewed

b. Auditing activities to be conducted to assess quality of performance of management, technical, and assurance processes

c. Auditing activities to be conducted to identify the specific contents of delivered products and configuration-controlled baselines, such as physical configuration audits and functional configuration audits

d. Evaluation of the effectiveness of problem reporting, corrective action, and change control and configuration management practices

3.2 Methods and Techniques

The purpose of this section is to describe the methods and techniques to be used for all quality assurance activities listed in Section 3.1.

3.3 Products

Describe the specific format and structure of the products produced by the activities given in Section 3.1. These products are the appropriate Quality Assurance section of the Assurance and Test Procedures document and reports (such as review or audit reports) that are to be incorporated in the Management, Engineering, and Assurance Reports. Also describe metric data to be collected and assessed.

4.0 VERIFICATION AND VALIDATION PLANNING

The purpose of this section is to specify the plans for conducting verification and validation activities, the methods to be employed, and the degree of independence required.

4.1 Approach and Activities

Describe the overall approach to be used to verify and validate the software across the entire life cycle. Describe the specific verification and validation activities to be conducted, such as reviews, audits, inspections, and testing, to support the verification and validation approach.

Describe the overall plan for types (unit, integration, acceptance) of testing. Discuss priorities or particular emphasis on testing, such as reliability and maintainability requirements. Include test management assurance planning for verifying that test standards and procedures have been established and followed, all test requirements have been satisfied, and all test results have been recorded properly. Accommodate any phased delivery or incremental development considerations.

Specify the structure, including roll-out, for the testing section(s) of the Assurance and Test Procedures.

Describe the process, including reporting and change control procedures, to be followed if tests fail, and for retesting after products are updated or patched.

Specify requirements for test reviews prior to and at the conclusion of testing.

Describe the test results reports required. All reports should be included or tracked under the Management, Engineering, and Assurance Reports.

4.2 Methods and Techniques

Describe the specific methods and techniques to be used for all the verification and validation activities listed in Section 4.1.

4.3 Products

Describe the specific format and structure of the products produced by the activities given in Section 4.1. These products are the appropriate Verification and Validation section of the Assurance and Test Procedures and reports (such as review, test, or audit reports) that are to be incorporated in the Management, Engineering, and Assurance Reports. Also describe metric data to be collected and assessed.

5.0 QUALITY ENGINEERING ASSURANCE PLANNING

The purpose of this section is to specify plans for conducting quality engineering assurance. Planning shall include activities and measures to assure reliability, maintainability, and other similar quality factors specified in the Product Specification.

5.1 Approach and Activities

The purpose of this section is to describe the detailed quality engineering assurance activities for assessing the quality factors (reliability, maintainability, etc.) of the software products as specified in the Product Specification and in the Acquisition Activities Plan section of the Management Plan.

Specify and define:

a. Reliability-related activities, including analyses of failure probabilities and failure rates, as well as plans for use of math models and diagrams, tools, and Failure Modes and Effects Analyses

b. Maintainability-related activities, including plans for software maintainability, such as module or unit cohesion, coupling, and employment of coding standards, and expectations for the system in terms of Mean Time Between Maintenance

c. Other quality factors (the other "ilities") as specified in the Product Specification and requirements section of the Acquisition Plan.

5.2 Methods and Techniques

The purpose of this section is to describe the methods and techniques to be used for all quality engineering assurance activities listed in Section 5.1.

5.3 Products

Describe the specific format and structure of the products produced by the activities given in Section 5.1. These products are the appropriate Quality Engineering Assurance sections of the Assurance and Test Procedures and reports (such as analysis reports) that are to be incorporated in the Management, Engineering, and Assurance Reports. Assurance information recorded in the Assurance and Test Procedures for quality engineering assurance should provide numeric measures of the quality factors being evaluated, such as Mean Time Between Failures or expectations of time to repair or recalibrate, whenever possible. Also describe metric data to be collected and assessed.

6.0 SAFETY ASSURANCE PLANNING

The purpose of this section is to specify plans for verifying and validating the safety requirements of the software. The specific activities involved in performing this assurance may vary between acquirer and providers.

6.1 Approach and Activities

Describe the overall approach to be used to perform the safety assurance activities for the software. Describe the specific activities with respect to analysis and review of specific aspects in terms such as:

a. Hazards

b. Fault tolerance

c. Safety criteria such as fail-safe, fail-soft, and fail-operational

This will typically include stating how the safety requirements defined in the Product Specification for a product will be assured.

6.2 Methods and Techniques

The purpose of this section is to describe the methods and techniques to be used for all safety assurance activities listed in Section 6.1.

6.3 Products

Describe the specific format and structure of the products produced by the activities given in Section 6.1. These products are the appropriate Safety Assurance sections of the Assurance and Test Procedures and reports that are to be incorporated in the Management, Engineering, and Assurance Reports. Describe metric data to be collected and assessed.

7.0 SECURITY AND PRIVACY ASSURANCE PLANNING

The purpose of the security and privacy assurance plan is to provide planning for the assurance of the security and privacy aspects of the software. The security and privacy requirements for the software appear in the Product Specification or the in the Acquisition Activities Plan section of the acquirer's Management Plan. The statement of how security and privacy requirements are to be met appears in the Product Specification.

7.1 Approach and Activities

Describe the overall approach to be used to perform security and privacy assurance activities for the software. Describe the specific activities with respect to analysis and review of specific security and privacy aspects in terms of degree of integrity, minimization or potential for abuse or misuse, and maintenance of continuity of operations. Aspects may include:

a. Effective and accurate operations

b. Protection from unauthorized alteration, disclosure, use or misuse of information processed, stored, or transmitted

c. Maintenance of continuity of automated information support

d. Incorporation of management and operational controls

e. Appropriate technical, administrative, environmental, and access safeguards

7.2 Methods and Techniques

The purpose of this section is to describe the methods and techniques to be used for all security and privacy assurance activities listed in Section 7.1.

7.3 Products

Describe the specific format and structure of the products produced by the activities given in Section 7.1. These products are the appropriate Security and Privacy Assurance sections of the Assurance and Test Procedures and reports that are to be incorporated in the Management, Engineering, and Assurance Reports. Describe metric data to be collected and assessed.

8.0 CERTIFICATION PLANNING

The purpose of this section is to define the planning for conducting certification activities.

8.1 Approach and Activities

Describe the overall approach to be used to certify the software. Describe the specific certification activities to be conducted, such as tests, reviews, audits, or inspections, to support the certification approach.

8.2 Methods and Techniques

The purpose of this section is to describe the methods and techniques to be used for all certification activities listed in Section 8.1.

8.3 Products

Describe the specific format and structure of the products produced by the activities given in Section 8.1. These products are the appropriate Certification section of the Assurance and Test Procedures and certification reports that are to be incorporated in the Management, Engineering, and Assurance Reports. Also specify any metric data to be collected and assessed.

9.0 ABBREVIATIONS AND ACRONYMS

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

10.0 GLOSSARY

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

11.0 NOTES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

12.0 APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

Return to Beginning of Appendix

NASA-DID-M500
RISK MANAGEMENT PLAN
DATA ITEM DESCRIPTION

1.0	INTRODUCTION
2.0	RELATED DOCUMENTATION
3.0	RISK ASSESSMENT AND EVALUATION PROCESS
4.0	TECHNICAL RISKS
5.0	SAFETY RISKS
6.0	SECURITY RISKS
7.0	RESOURCE RISKS
8.0	SCHEDULE RISKS
9.0	COST RISKS
10.0	ABBREVIATIONS AND ACRONYMS
11.0	GLOSSARY
12.0	NOTES
13.0	APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

3.0 RISK ASSESSMENT AND EVALUATION PROCESS

Describe the plan for risk reduction or control. Be sure to address each of the following topics:

a. Describe the process to be used to identify the risks affecting acquisition or development of the software, assess the potential impact of each, and determine measures to control or reduce them. Describe the risk evaluation approach including assessment of the impact on the entire software should any lower level elements (such as CSCIs or CSCs) be delivered late or be noncompliant.

b. Describe the measures for continual assessment and monitoring of risks throughout the life cycle including specific data to be collected. Include approaches to control risks where possible, or to minimize the impact of risks that cannot be controlled.

c. For each of the risk categories (Sections 4.0 - 9.0), describe the measures to be taken to monitor the risk level, control the degree of susceptibility to that risk category, or minimize the potential effects of the risks.

d. Define the reports to be generated and their content. All reports shall be accessible through the Management, Engineering, and Assurance Reports.

4.0 TECHNICAL RISKS

Describe the continuing analysis to be performed of the risks associated with technical parameters, including:

a. Methods of risk assessment (e.g., prototyping)

b. Testing requirements

c. Contingency development plans

d. Critical milestones used to track and reassess risks

5.0 SAFETY RISKS

Describe the safety risks and contingencies in terms of:

a. Safety risk analysis

b. Safety decision methodology

c. Adequacy of product assurance to ensure safety

d. Configuration management and procedures that impact safety

6.0 SECURITY RISKS

Describe security risks and contingencies in terms of:

a. Security threat analysis

b. Security decision methodology

c. Formal security policy model including discretionary and mandatory access control enforcement

d. Configuration management and procedures for secure distribution of the system to sites

7.0 RESOURCE RISKS

Describe resource risks and contingencies in terms of resource definition and allocation methodology as well as personnel, facilities, and equipment availability.

8.0 SCHEDULE RISKS

Describe schedule risks and contingencies in terms of schedule definition, assignment of responsibilities, source availability, and tracking. Consider impact of schedules from resource risks such as equipment and personnel availability.

9.0 COST RISKS

Describe development cost risks and contingencies including assessment of:

a. Precision of cost estimates

b. Effects of schedule changes

c. Changes in funds allocation

d. Costing methodology

e. Accounting methods and practices

10.0 ABBREVIATIONS AND ACRONYMS

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

11.0 GLOSSARY

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

12.0 NOTES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

13.0 APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

Return to Beginning of Appendix

NASA-DID-M600
CONFIGURATION MANAGEMENT PLAN
DATA ITEM DESCRIPTION

1.0	INTRODUCTION
2.0	RELATED DOCUMENTATION
3.0	CONFIGURATION MANAGEMENT PROCESS OVERVIEW
4.0	CONFIGURATION CONTROL ACTIVITIES
4.1		Configuration Identification
4.2		Configuration Change Control
4.2.1			Controlled Storage and Release Management
4.2.2			Change Control Flow
4.2.3			Change Documentation
4.2.4			Change Review Process
4.3		Configuration Status Accounting
5.0	ABBREVIATIONS AND ACRONYMS
6.0	GLOSSARY
7.0	NOTES
8.0	APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

3.0 CONFIGURATION MANAGEMENT PROCESS OVERVIEW

Provide an overview of the configuration management process. Discuss the various activities and summarize the flow of information and products developed within the configuration management structure. Include a description of the process of incorporating products received into the baselines maintained by the preparing organization. Be sure to address any access restrictions.

Describe the configuration management information flow in terms of a flow chart or similar graphic. Show each review and control board in the context of the information flow. Summarize change control reports to be generated and how they are to be tracked.

If appropriate, describe special considerations for security that are to be supported by configuration management, such as analyzing proposed changes for adverse effects on security or recording each access to secure data under configuration control.

4.0 CONFIGURATION CONTROL ACTIVITIES

The purpose of this section is to identify and describe the activities to be performed by a configuration control staff and associated organizations. Address at least the topics discussed in the following subsections and include others, such as document revision and technical information center activities, as appropriate.

4.1 Configuration Identification

Describe the configuration identification process and standards for all items in the software system configuration(s). Include a description of each provider's developmental configuration with respect to the methods used by the provider in establishing the configuration and identifying its contents.

Methods for establishing a configuration shall include the manner of identifying (e.g., naming, marking, numbering) the system and its lower level elements (such as CSCIs or CSCs).

4.2 Configuration Change Control

Describe configuration change control responsibilities and activities to be used in maintaining and controlling changes to baselined products, including those identified in the following subsections.

4.2.1 Controlled Storage and Release Management

Describe the methods and activities to be used to formally control the receipt, storage, handling, and release of deliverable configuration items. Specify needs and methods for restricting access to controlled items. Be sure to address any special considerations such as measures taken to ensure security and privacy, e.g., access restrictions, consisting of codes to protect data and system integrity against unauthorized use.

4.2.2 Change Control Flow

Discuss the initiation, transmittal, review, disposition, implementation, and tracking of discrepancy reports and change requests. Use a graphic representation of the change control flow if this provides clarity.

4.2.3 Change Documentation

Describe each report used in the configuration management process and explain its purpose and use. Include an example of each report form or cite the location where the forms can be found (e.g., in the appropriate standards and procedures repository).

For each report:

a. Describe the function of this report.

b. Identify who may initiate the report.

c. Describe subsequent handling and updating of the report.

All reports shall be accessible through the Management, Engineering, and Assurance Reports. Also describe any metric data to be collected and analyzed.

4.2.4 Change Review Process

Describe the process by which each control and review board for configuration management carries out its responsibilities and functions. Describe how each board will provide historical traceability with respect to the configuration identification scheme.

4.3 Configuration Status Accounting

Define the configuration status accounting system's records and reports in terms of purpose, general content, and accessibility.

5.0 ABBREVIATIONS AND ACRONYMS

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

6.0 GLOSSARY

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

7.0 NOTES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

8.0 APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

Return to Beginning of Appendix

NASA-DID-M700
DELIVERY AND OPERATIONAL TRANSITION PLAN
DATA ITEM DESCRIPTION

1.0	INTRODUCTION
2.0	RELATED DOCUMENTATION
3.0	SITE PREPARATION PLANNING
3.1		Facility Planning
3.2		Transition Planning
4.0	DELIVERY PLANNING
5.0	DATA CONVERSION PLANNING
6.0	USER TRAINING PLANNING
7.0	OPERATOR TRAINING PLANNING
8.0	ABBREVIATIONS AND ACRONYMS
9.0	GLOSSARY
10.0	NOTES
11.0	APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template DID (NASA-DID-999) for a detailed structure and content description of this section.

3.0 SITE PREPARATION PLANNING

3.1 Facility Planning

Describe the preparation for the supporting facility in terms such as:

a. Facility sizing

b. Facility preparation

c. Facility scheduling plan and process

d. Definition of required hardware, support software, facility support (air conditioning, etc.)

3.2 Transition Planning

Describe the preparation for the transition to be provided at the site(s) in terms such as:

a. Transition process including coordination between the developer's engineering personnel and support personnel

b. Overall coordination for preparation and implementation including identification of discrepancies or omissions

c. Identification of transition action items and assignment of responsibility for their completion

d. Ensuring that all manuals and other required software products are available when needed

e. Technical assistance

f. Site personnel to support delivery installation team

g. Priority scheduling to ensure adequate software response

h. Any phase-over transition of safety, security or training responsibilities

4.0 DELIVERY PLANNING

Identify, describe, and schedule the tasks associated with delivery and installation of the software, in terms such as:

a. Installation plan, including transition from developer to operations personnel

b. Packaging requirements, in terms of equipment, materials, dates, personnel, and degree of protection needed

c. Shipment requirements, in terms of methods, shippers, dates, estimated size and volume, etc.

5.0 DATA CONVERSION PLANNING

Identify and describe existing data files and databases that must be converted for use with the software. Specify how the conversion will be accomplished.

6.0 USER TRAINING PLANNING

The purpose of this section is to specify what training is to be provided to users (by user classes) and the means, materials, and facilities by which the training will be delivered.

Topics to be addressed include:

a. Classes of users to be trained

b. Available curriculum

c. Training delivery

d. Assessment and follow-up training

e. Evaluation of adequacy of training curriculum and materials

f. Facility and equipment requirements for conducting training

7.0 OPERATOR TRAINING PLANNING

The purpose of this section is to specify what training is to be provided to personnel who are to operate the software.

Topics to be addressed include:

a. Classes of users to be trained

b. Available curriculum

c. Training delivery

d. Assessment and follow-up training

e. Evaluation of adequacy of training curriculum and materials

f. Facility and equipment requirements for conducting training

8.0 ABBREVIATIONS AND ACRONYMS

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

9.0 GLOSSARY

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

10.0 NOTES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

11.0 APPENDICES

Refer to the Template DID (NASA-DID-999) for a detailed description of content for this section.

Return to Beginning of Appendix

Return to NASA Software Documentation Standard

If you have any questions or comments about the SATC, contact:

Dr. Linda Rosenberg
NASA/GSFC
Code 302 -  Bldg 6
Greenbelt, MD 20771

Linda.Rosenberg@gsfc.nasa.gov

This page was last updated on:
06/29/99