The purpose of the Product Specification is to document the technical aspects relative to the development of the software. This information is produced over the life cycle for the software.

The specifications for the format, outline and content of the Product Specification are listed below. Major sections have been moved to separate documents for clarity and manageability. Lower-level detailed specs provide additional substructure and contain content which should be take into account even when the content is assembled in one document.

CONTENTS

3.0  CONCEPT
4.0  REQUIREMENTS
5.0  ARCHITECTURAL DESIGN
6.0  DETAILED DESIGN
7.0  VERSION DESCRIPTION
8.0  USER DOCUMENTATION
8.1  User's Guide
8.2  User's Training Materials
9.0  OPERATIONAL PROCEDURES
10.0 MAINTENANCE MANUAL
10.1 Implementation Details
10.2 Modification Aids
10.3 Code Adaptation

Refer to the Template WIS for the detailed structure and content of the document.

3.0 CONCEPT

The purpose of this section is to provide an overview of the software. When required, this section provides the scope and context that will aid in understanding the requirements. Depending upon the system decomposition and the size and complexity of the parent software, this section may not be needed. If this is the case, reference the appropriate concept section.

The primary topics for the concept section include:

a. Definition and Purpose

b. User Definition

c. Capabilities and Characteristics

d. Sample Operational Scenarios

Refer to the Concept WIS for the detailed structure and content of this section.

4.0 REQUIREMENTS

The purpose of this section is to specify and augment, as appropriate, the functional, performance, and interface requirements of the software. The section also specifies the major characteristics, implementation constraints, and design goals.

The primary topics for the requirements specification include:

a. Requirements Approach and Tradeoffs

b. External Interface Requirements

c. Software Requirements

d. Traceability to Parent's Design

e. Partitioning for Phased Delivery

Refer to the Requirements WIS for the detailed structure and content of each topic.

5.0 ARCHITECTURAL DESIGN

The purpose of the architectural design is to document the top-level, comprehensive design for the software (which may consist of one or more CSCIs, CSCs, or CSUs) including major external and internal interfaces and logical data scheme. In addition, the section should describe the rationale for the architecture.

The primary topics for the architectural design specification include:

a. Design Approach and Tradeoffs

b. Architecture Design Description

c. External Interface Design

d. Traceability to Requirements

e. Partitioning for Incremental Development

Refer to the Architectural Design WIS for the detailed structure and content of each topic.

6.0 DETAILED DESIGN

The purpose of this section is to describe the design for the software in enough detail to be able to write the software code to implement the design. Detailed design defines the structure and functions down to the computer software unit level.

The primary topics for the detailed design specification include:

a. Detailed Design Approach and Tradeoffs

b. Detailed Design Description

c. External Interface Detailed Design

d. Traceability to Architectural Design

e. Coding and Implementation Notes

f. Firmware Support

Refer to the Detailed Design WID for a further description of the structure and content for each topic.

7.0 VERSION DESCRIPTION

This section will describe in detail the configuration and content of the product and instructions for its set-up. For each new release, the section also provides information on the status of changes since previous releases.

The primary topics for the version description include:

a. Changes in Functional Capabilities

b. Set-up Instructions

c. Inventory and Software Product Identification

d. Change Status

e. Adaptation Data

Refer to the Version Description WID for a further description of the structure and content for each topic.

8.0 USER DOCUMENTATION

8.1 User's Guide

The purpose of the software User's Guide is to provide instructions to end users (human and other systems) on the use of the software.

The primary topics for the User's Guide include:

a. Overview of Purpose and Functions

b. Installation and Initialization

c. Startup and Termination

d. Functions and their Operation

e. Error and Warning Messages

f. Recovery Steps

Refer to the User's Guide WIS for a further description of the structure and content for each topic.

8.2 User's Training Materials

The purpose of this section is to document the training materials provided for the users. This section will contain the actual training materials. When media other than paper hard copy are used, describe the media and reference training materials such as video tapes and computer-aided instruction files.

9.0 OPERATIONAL PROCEDURES

The purpose of the Operational Procedures is to provide instructions to the system operators (as opposed to end users) on the procedures for operating, controlling, troubleshooting, and maintaining the software.

The primary topics for the Operational Procedures include:

a. System Preparation and Set-up Procedures

b. Standard Operating Procedures

c. Fault and Recovery Procedures

d. Emergency Procedures

e. Diagnostic Procedures

Refer to the Operational Procedures WIS for a further description of the structure and content for each topic.

10.0 MAINTENANCE MANUAL

The purpose of the Maintenance Manual is to provide a location for data and information to aid in analysing and debugging the software. This should not duplicate information available in other sections of the Product Specification.

10.1 Implementation Details

Describe details about:

a. Specific data representations or formats

b. Operating system interfaces and dependencies

c. Support software such as libraries

d. Hardware dependencies

e. Other interfaces

10.2 Modification Aids

Describe design details that could be used in the modification or expansion of the software.

10.3 Code Adaptation

Describe design details that support the initialization or adaptation of data or code. Relate this information to version information of the software.

The document describes how and which functions and data are realised and also which data and services can be exchanged via the interfaces — down to the level of a programming specification.

The realisation of the data are to be included into the product "Data Dictionary".

In the case of a database, it will be completely described down to the level of a schema definition. Results of an analysis about resource and time requirements need also be documented.

Such a document exists for each database (of each SW Unit of each Segment in the System).

It is possible to combine several designs into one product "Database Design".

2 Database Description

2.1 DBMS Name

The database management system used will be mentioned here.

2.2 Schema Definition

The detailed design has to be done down to the data elements level. This means

• for file systems:
  Definition of the record structures and the data elements contained therein,
• for hierarchical databases:
  Definition of the Segments, the data elements included and the hierarchy of the segments,
• for relational databases:
  Definition of the tables or views, the data elements included, the external keys and integrity conditions.

 The realisation of the data (data type and format, location) has to be included in the product "Data Dictionary".

3 Characteristic Quantities

This chapter deals with, among other things:

• resource and time requirements,
• priorities and operation sequence,
• precision of processing,
• maximum, minimum and probable frequency of signals.

Data Dictionary

This product contains all information about the data used in SW Units (individual data and complex structures). It can be generated manually -- but it is better with the help of a tool. The information is collected and administered in activity "Data Administration".

The input information for the Data Dictionary is delivered by the SW Architecture and SW Design. The Data Dictionary must contain the identifiers, the characteristics and attributes of the data structures and its elements (data description). Also important is information dependent on the implementation (data realisation). Such a product exists for each project.

2 Data Description

The tabular description contains the following information:

• identification
  unique identifier of the data elements chosen in accordance with the conventions of the programming language and project rules for identification in the CM Plan
• long name
  the long name describes the content and the use of the data elements
• relations within a data element
  e. g. structuring into record — field — item, identifying key, etc.
• relations to other data elements
  e. g. redundancy, dependencies with regard to contents or time
• physical unity and normalization
  Decisive for processing a datum is its physical unity. Is a temperature given in Centigrade, Fahrenheit, or Kelvin? A distance given in kilometers or miles?
• refinement
  identifiers of data elements are given into which the (complex) data is structured
• defining SW Component/SW Module
  A data element is only defined by a SW Component or SW Module. The identifier is given here.
  • referencing SW Component/SW Module
    All SW Components and SW Modules referencing (using) the data element are listed by giving its identifier and kind of reference:
  • read access
  • write access
  • plausibility/integrity
  • special characteristics and attributes

3 Data Realisation

The following information has to be given:

• data type and size
  in the case of scalar data: e. g. integer, real, char, and number of digits,
  in the case of composite data: e. g. record, array, and description of individual fields analogously to scalar data
• range and domain
• precision
• default setting
• access
  kind of access (e. g. sequential, indexed) and identifying key
• life time
  generation times and frequencies
• memory space requirements
  calculated from data type and format, while considering HW dimensioning
• location

If memory has to be allocated statically the addresses are taken from the cross-reference listings of the compilers and/or linkers.

It is to list the start address; for parts of data elements the address relative to the beginning of the structure must be given. A note is required if a relative address is concerned.

The purpose of the Architectural Design is to record the logical/functional design information for the software. This includes design rationale and trades, the selected architecture of the software including at least one level of decomposition, the relationships and interface description between the levels and the allocation of the software requirements to lower levels.

CONTENTS

3.0 DESIGN APPROACH AND TRADEOFFS
4.0 ARCHITECTURAL DESIGN DESCRIPTION
5.0 EXTERNAL INTERFACE DESIGN
5.1 Interface Design
5.2 Interface Allocation
6.0 REQUIREMENTS ALLOCATION AND TRACEABILITY
7.0 PARTITIONING FOR INCREMENTAL DEVELOPMENT

Refer to the Template WIS for the detailed structure and content of the document.

3.0 DESIGN APPROACH AND TRADEOFFS

Describe the rationale and tradeoffs as well as other design considerations, including any use of prototyping, influencing the major decisions affecting the design of the software. Detailed design engineering and trades information that must be reevaluated or considered when changes are proposed during development or during sustaining engineering should be included in an appendix or explicitly referenced.

4.0 ARCHITECTURAL DESIGN DESCRIPTION

The purpose of this section is to describe the logical or functional design of the software. The following topics should be included:

1. Logical or functional decomposition
2. Description of the lower level elements including their inputs and outputs
3. Relationships and interactions between the lower level elements
4. Logical data design - conceptual schema
5. Entity/data identification and relationships

5.0 EXTERNAL INTERFACE DESIGN

This section contains the design specifications for interfaces between the software and its external users. The section should be rolled-out when it will be placed under configuration control as a separate item, such as when two systems are referencing the same interface design. When rolled-out, it becomes the External Interface Design document.

5.1 Interface Design

Describe the design for each interface identified in the requirements section of the Product Specification as an external interface in terms of:

1. Information description
2. Initiation criteria
3. Expected response
4. Protocol and conventions
5. Error identification, handling, and recovery
6. Queuing
7. Implementation constraints

5.2 Interface Allocation

The purpose of this section is to allocate the software's external interface requirements to the appropriate lower level elements. Use a table or graphics if appropriate for clarity. Ensure that all external interface requirements, including performance, site adaptation, and design goals, are allocated.

6.0 REQUIREMENTS ALLOCATION AND TRACEABILITY

This section documents the allocation of the software's requirements to the lower level elements. Show the traceability of all requirements including performance and constraints for this software to the design presented above. Explicitly identify any derived requirements.

7.0 PARTITIONING FOR INCREMENTAL DEVELOPMENT

If the software is to be produced using phased delivery or incremental development, specify what requirements and functions are to be satisfied in each increment of the software.

The purpose of the Detailed Design is to record the design information for the software. This includes design rationale and trade-offs, the selected design of the software including its decomposition into compilation and code units, the design of all interfaces, and the mapping between the logical or functional design of the software and its detailed design units.

CONTENTS

3.0 DETAILED DESIGN APPROACH AND TRADEOFFS
4.0 DETAILED DESIGN DESCRIPTION
4.1 Compilation Unit Design and Traceability to Architectural Design
4.2 Detailed Design of Compilation Units
5.0 EXTERNAL INTERFACE DETAILED DESIGN
5.1 Interface Allocation Design
5.2 Physical Interface Design
6.0 CODING AND IMPLEMENTATION NOTES
7.0 FIRMWARE SUPPORT MANUAL

Refer to the Template WIS for the detailed structure and content of the document.

3.0 DETAILED DESIGN APPROACH AND TRADEOFFS

Describe the rationale and tradeoffs, and other design considerations, including any use of prototyping, influencing the major decisions affecting the design of the software. Detailed design engineering and trades information that must be reevaluated or considered when changes are proposed during development or during sustaining engineering should be included in an appendix or explicitly referenced.

4.0 DETAILED DESIGN DESCRIPTION

4.1 Compilation Unit Design and Traceability to Architectural Design

This section presents the overall physical design of the software into its compilation units. The information for each unit should include:

1. Compilation unit identification
2. Compilation unit descriptions including:
   1. Inputs and outputs
   2. Functions
   3. Data descriptions and relationships
   4. Diagrams
   5. Control and signal flow
   6. Error handling
3. Interfaces descriptions between compilation units
4. Packaging details such as placement of units in library

This section includes a mapping of or the traceability between the architectural design elements to the compilation units.

4.2 Detailed Design of Compilation Units

This section contains the design information detailed to the level necessary to code the individual compilation units and all lower level code units. The information for each unit should include:

a. Detailed design to the lowest level (i.e., module or subroutine)

b. Functions or operations

c. Algorithms

d. Specific data definitions including data conversions

e. Local and global data

f. Parameters for initiation and adaptation

g. Logic flow, including:

1. Control flow

2. Timing variations

3. Priority assignments

4. Interrupt priorities and handling

h. Error detection and handling

i. Physical data design:

1. Internal schema

2. Query language

3. Access method

4. Key, record, and data element definition and structure

5. Use of database management capability

j. Device interface

5.0 EXTERNAL INTERFACE DETAILED DESIGN

This section contains the detailed design specifications for interfaces between the software and its external users. The purpose of the software external interface detailed design is to record the physical design information for the external interfaces to the software. This includes the data types, physical data format or layout, message descriptions, data transmissions, and protocols and priorities.

This section should be rolled-out when it is to be placed under configuration control as a separate item, such as when two elements are referencing the same interface design. When rolled-out, it becomes the External Interface Detailed Design document.

5.1 Interface Allocation Design

This section describes the mapping or traceability of the external interface design of the software into its specific compilation units and lower level units.

5.2 Physical Interface Design

Describe each external interface for the software. For each interface, describe the details of the interface, including:

a. (Interface Name/Identifier) Type and Purpose. Describe the type and purpose of the interface.

b. Data Transmission. Provide a detailed specification of the data records and elements transmitted across the interface in such terms as:

1. Unique identifier for each record and data element

2. Brief description and purpose of each record and data element

3. Source and destination for each record or single data element transmission

4. Data type and (if appropriate) unit of measure

5. Limit and range of values

6. Accuracy

7. Precision (in terms of significant digits)

If shared memory is used, then define:

8. The purpose for the shared memory

9. The shared memory location(s) used for transmissions across the interface

c. Message Descriptions. Identify each message transmitted across the interface and specify the assignment of data elements to each message. Provide cross references between data elements and messages, as a two-way sorted list.

d. Interface Priority. Specify the relative priority of this interface and of each message transmitted across it.

e. Communication Protocols. Identify the protocol for the interface by name and describe its technical details in terms of the following:

1. Fragmentation and reassembly of messages

2. Message formatting

3. Error control and recovery procedures, including fault tolerance features

4. Synchronization, including connection establishment, maintenance, termination, and timing

5. Flow control, including sequencing, and buffer allocation

6. Data transfer rate, whether periodic or aperiodic, and minimum interval between transfers

7. Routing, addressing, and naming conventions

8. Transmission services, including priority and grade

9. Status, identification, notification, and other reporting features

10. Security, including encryption, user authentication, compartmentalisation, and auditing

6.0 CODING AND IMPLEMENTATION NOTES

The purpose of this section is to specify information such as:

a. Stubs for incremental development

b. Use of compiler options

7.0 FIRMWARE SUPPORT MANUAL

If the software design is implemented in firmware, refer to the Firmware Support Manual WIS for a further description of the content of this section.

PURPOSE

To provide visibility into the design and the degree of compliance with the requirements.

CONTENTS:

The document shall give a overview on the design of the unit/item and its use.

The following subjects shall be indicated if applicable:

• Overall description, including functional objectives, design description and operating principles,
• Configuration (elements of the item and there features),
• Functions including functional configuration, functional description, functional block diagram, a switching diagram showing the location of the telemetry outputs and telecommand inputs and logic and circuit diagrams,
• Performance including all performance data,
• Interfaces,
• Budgets (e.g. mass, power, etc.).

The purpose of the user's guide is to provide end users (rather than system operators or administrators) with instructions explaining how to execute the software effectively.

CONTENTS

3.0 OVERVIEW OF PURPOSE AND FUNCTIONS
4.0 INSTALLATION AND INITIALIZATION
5.0 STARTUP AND TERMINATION
6.0 FUNCTIONS AND THEIR OPERATION
7.0 ERROR AND WARNING MESSAGES
8.0 RECOVERY STEPS

Refer to the Template WIS for the detailed structure and content of the document.

3.0 OVERVIEW OF PURPOSE AND FUNCTIONS

3.0 OVERVIEW OF PURPOSE AND FUNCTIONS

Describe the purpose and main capabilities of the software, and state its overall operation in terms of:

a. Functions

b. Options

c. Restrictions and limitations

If appropriate, reference the version description section.

4.0 INSTALLATION AND INITIALIZATION

Explain in detail the procedures for installing, tailoring, and initiating the software, including:

a. Equipment set-up

b. Power-on and power-off

c. Bootstrap and load

d. Initiation commands

e. Interrupt/recovery/restart

f. Initialization of files, variables, or other data

g. Tailoring, reconfiguration, adaptation

h. Re-initialization after failure

5.0 STARTUP AND TERMINATION

Describe how to start and terminate operation normally, and how to determine whether normal termination has occurred.

If the user has some control over abnormal termination, describe the procedures involved such as:

a. Trouble indicators and corrective actions

b. On-line interventions

c. Trap recovery

d. Operating communications

e. Fault isolation techniques

f. Conditions requiring software abort or equipment shut-down

Describe procedures for restarting after both normal and abnormal termination. If recovery procedures are required for restarting after abnormal termination, explain them in terms of:

a. Check points

b. Collection of failure data

c. Restoring files

d. Restoring devices to operational mode

6.0 FUNCTIONS AND THEIR OPERATION

Describe each function in terms of:

a. Purpose of function

b. Step-by-step procedures for execution

c. User inputs: commands, data, and option selection

d. Expected results and the procedures for examining these results

e. Related functions

Describe any inputs from a source other than the user that may occur while the software is in use and that may affect its interface with the user (for example, inputs from a remote sensor). Include applicable attributes of the input such as format, frequency, and effect upon the software state or mode.

7.0 ERROR AND WARNING MESSAGES

List and explain each possible error condition and associated message that may be encountered. Describe the corresponding corrective actions to be taken.

If appropriate, identify an agency that may be called upon for assistance.

8.0 RECOVERY STEPS

Explain recovery procedures the user may employ.

The purpose of the operational procedures manual is to document the actual operational procedures of the software.

CONTENTS

3.0 SYSTEM PREPARATION AND SET-UP PROCEDURES
4.0 STANDARD OPERATING PROCEDURES
5.0 FAULT AND RECOVERY PROCEDURES
6.0 EMERGENCY PROCEDURES
7.0 DIAGNOSTIC PROCEDURES

Refer to the Template WIS for the detailed structure and content of the document.

3.0 SYSTEM PREPARATION AND SET-UP PROCEDURES

This section describes the procedures conducted by the operator to set-up and prepare the system for operation, both initially and for new releases or modifications to the system. This includes instructions for both software and, as appropriate, hardware.

4.0 STANDARD OPERATING PROCEDURES

This section describes the detailed operational procedures that are part of the standard practices for operating the information system. The types of procedures defined here include:

a. Monitoring procedures

b. Daily operating procedures, such as system back-ups and logs for maintenance

c. Standard safety and security procedures

d. On-demand procedures, such as in response to a user request

5.0 FAULT AND RECOVERY PROCEDURES

This section describes the detailed operational procedures to be conducted in case of a fault or abnormal condition in the hardware, software, or some other aspect of the system. The immediate actions and subsequent recovery procedures are documented for every anticipated fault condition.

6.0 EMERGENCY PROCEDURES

This section describes the detailed operational procedures to be conducted in case of an emergency. The types of procedures defined here include:

a. Procedures for critical system failures

b. Environmental emergency procedures, such as fires or hurricanes

c. Safety or security emergency procedures

7.0 DIAGNOSTIC PROCEDURES

Explain diagnostic procedures the operator may employ such as:

a. Correlation to error messages

b. Diagnostic initialization

c. Recording diagnostic data

d. Analysis of diagnostic results

The Acquisition Plan provides a definition of the activities that must be undertaken to acquire software, through procurement or development, and specifies management and assurance requirements. This plan covers all aspects of the life cycle for the software including procurement.

CONTENTS

Refer to the Template WIS for the detailed structure and content 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 Supplier Selection 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 minimise 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 ORGANISATIONAL 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 organisational structure; independence of verification and validation; and interfaces with the acquirer, other providers, and other external organisations. Include any other resource requirements such as use of customer-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  management.

5.1 Software Management Responsibilities

Identify all software for which the project is responsible and identify which organisation(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 organisation chart for the project, identify the title of the person or organisation responsible for the software deliverables.

5.2 Categorisation and Classification Policy

The purpose of this section is to carefully explain the project's approach toward categorising 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 organisations 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 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 categorisation policy in Section 5.2. Address the personnel and organisations 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 organisations will assess and/or approve the requirements, levels of detail contained in the requirements documents, and mechanisms employed to categorise or prioritise 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 organisations. Present variations in this process as a function of the categorisation 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 organisation

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

The Configuration Management Plan defines the configuration management process for the software and its associated products.

CONTENTS

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

Refer to the Template WIS for the detailed structure and content of this section.

3.0 CONFIGURATION MANAGEMENT PROCESS OVERVIEW

Provide an overview of the configuration management process. Discuss the various activities and summarise 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 organisation. 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. Summarise 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 analysing 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 organisations. 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 unauthorised 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 analysed.

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.

Integration Plan

The Integration Plan contains regulations governing the technical aspects for the assembly of the System, the Segment, or the SW Unit or HW Unit. The plan identifies the integration products simultaneously as assessed objects; in this respect, it must be kept consistent with the Assessment Plan. The technical prerequisites and limitations must be explained, just like the organization of the integration. The individual integration measures are described in detail.

The Integration Plan handles the levels System, Segment and SW Unit or HW Unit, respectively. The possible decomposition selected for the Integration Plan finally depends on the project standards, the size, and the complexity of the individual integration levels.

2 Integration Products and Strategies

Based on the hierarchical allocation (Segments; SW Units/HW Units; SW Components, SW Modules and Databases) and on the logical connection (found in the architecture documents), the assembly of the integration products is defined per integration step. Apart from the products, also the integration strategy is defined for each integration step.

3 Marginal Integration Conditions

3.1 Integration/Assessment Environment

This chapter lists the environment required for the integration. The SW Components are parts of the development and target computer and of the assessment environment; therefore, the corresponding passages from the Technical Requirements and the Assessment Plans can be stated or referenced at this point.

3.2 Priorities

The order of the integration depends on technical aspects (logical connection of integration products). A priority is allocated to each integration step.

3.3 Risks

If a special integration step happens to be risky the possibly existing problems and countermeasures have to be documented (e. g. danger for hardware during interaction with faulty software while no protection measures have been taken).

3.4 Other Marginal Conditions

If required this contains a description of other requirements and limitations (e. g. availability of integration equipment).

4 Organization of the Integration

The realization of the integration must be planned on the basis of previously listed integration steps and marginal conditions.

4.1 Integration Network Plan

The integration steps are put into chronological order, according to strategies, risks, and other marginal conditions.

4.2 Staff

The organizational units participating in the integration (SD, QA, CM, PM) are listed.

4.3 Responsibilities

The organizational units/instances are allocated responsibilities within the scope of the integration (supervision of the time schedule, realization of certain integration steps, quality assurance measures, etc.).

5 Integration Measures

5.1 Required Products

The products required for the realization of the integration measures are listed.

5.2 Integration Instructions

The technical instructions have to be generated on the basis of the integration strategies and marginal conditions. This includes procedures for the assembly of products as well as instructions for the integration equipment.

5.3 Special Measures

Special measures (e. g. based on the assembly of devices, switch on/off procedures) will be explained.

SOURCE: VM97

TRANSITION PLAN

The plan identifies the hardware, software and other resources needed for the support of deliverable software and describes the developer’s activities for transitioning deliverable items.

The plan is developed if the software support concept calls for transition of responsibility from the developer to a separate support agency. It may also be used by the acquirer for updating the Computer Resources Life Cycle Management Plan.

1. Scope

This section shall be divided into the following paragraphs.

1.1 Identification

This paragraph shall contain a full identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s) and release number(s).

1.2 System overview

This paragraph shall briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer and support agencies; identify current and planned operating sites; and list other relevant documents.

1.3 Document overview

This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.

1.4 Relationship to other plans

This paragraph shall describe the relationship, if any, of this plan to other project management plans.

2. Referenced documents

This section shall list the number, title, revision and date of all documents referenced in this document. This section shall also identify the source for all documents not available through normal Government stocking activities.

3. Software support resources

This section shall be divided into paragraphs to identify and describe the resources needed to support the deliverable software. These resources shall include items needed to control, copy, and distribute the software and its documentation, and to specify, design, implement, document, test, evaluate, control, copy, and distribute modifications to the software.

3.1 Facilities

This paragraph shall describe the facilities needed to support the deliverable software. These facilities may include special buildings, rooms, mock-ups, building features such as raised flooring or cabling; building features to support security and privacy requirements (TEMPEST shielding, vaults, etc.), building features to support safety requirements (smoke alarms, safety glass, etc.), special power requirements, and so on. The purpose of each item shall be described. Diagrams may be included as applicable.

3.2 Hardware

This paragraph shall identify and describe the hardware and associated documentation needed to support the deliverable software. This hardware may include computers, peripheral equipment, hardware simulators, stimulators, emulators, diagnostic equipment, and non-computer equipment. The description shall include:

3.3 Software

This paragraph shall identify and describe the software and associated documentation needed to support the deliverable software. This software may include computer-aided software engineering (CASE) tools, data in these tools, compilers, test tools, test data, simulations, emulations, utilities, configuration management tools, databases and data files, and other software.

The description shall include:

3.4 Other documentation

This paragraph shall identify any other documentation needed to support the deliverable software. The list will include, for example, plans, reports, studies, specifications, design descriptions, test cases/procedures, test reports, user/operator manuals, and support manuals for the deliverable software.

This paragraph shall provide:

a. Names, identification numbers, version numbers, and release numbers, as applicable

b. Rationale for including each document in the list

c. Identification of each document as acquirer-furnished, an item that will be delivered to the support agency, an item the support agency is known to have, an item the support agency must acquire, or other description of status

d. If a document must be acquired, information about where to acquire it e. Information about licensing and data rights f. Security and privacy considerations, limitations, or other items of interest

3.5 Personnel

This paragraph shall describe the personnel needed to support the deliverable software, including anticipated number of personnel, types and levels of skills and expertise, and security clearances. This paragraph shall cite, as applicable, actual staffing on the development project as a basis for the staffing needs cited.

3.6 Other resources

This paragraph shall identify any other resources needed to support the deliverable software. Included may be consumables such as magnetic tapes and diskettes, together with an estimate of the type and number that should be acquired.

3.7 Interrelationship of components

This paragraph shall identify the interrelationships of the components identified in the preceding paragraphs. A figure may be used to show the interrelationships.

4. Recommended procedures

This section shall be divided into paragraphs as needed to describe any procedures, including advice and lessons learned, that the developer may wish to recommend to the support agency for supporting the deliverable software and associated support environment.

5. Training

This section shall be divided into paragraphs as appropriate to describe the developer’s plans for training support personnel to support of the deliverable software.

This section shall include:

6. Anticipated areas of change

This section shall describe anticipated areas of change to the deliverable software.

7. Transition planning

This section shall be divided into paragraphs as needed to describe the developer’s plans for transitioning the deliverable software to the support agency.

This section shall address the following:

a. All activities to be performed to transition the deliverable software to the support agency. These activities may include planning/coordination meetings; preparation of items to be delivered to the support agency; packaging, shipment, installation, and checkout of the software support environment; packaging, shipment, installation, and checkout of the operational software; and training of support personnel.

b. Roles and responsibilities for each activity

c. The resources needed to carry out the transition activities and the source from which each resource will be provided

d. Schedules and milestones for conducting the transition activities. These schedules and milestones shall be compatible with the contract master schedule.

e. Procedures for installation and checkout of deliverable items in the support environment

The purpose of the Engineering and Operations Plan is to define the process by which the organization preparing this Management Plan intends to maintain and operate the software and process change requests. This includes plans for training the users and operators of the software.

CONTENTS

3.0 SUSTAINING ENGINEERING PROCESS
4.0 PRODUCT SUPPORT
4.1 User Support
4.2 User and Operator Training

Refer to the Template WIS for the detailed structure and content of the document.

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

The Management Plan DID's provide outlines for the complete Management Plan documents. Major sections of the Management Plan point to lower level WIS's 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 WIS's presented in this section. Lower-level detailed WIS's provide additional substructure and contain content discussion which should be reviewed even when the content is recorded in-line (i.e. not rolled-out).

Complete Set for a Management Plan

Management Plan

Acquisition Activities Plan

Development Activities Plan

Training Development Plan

Sustaining Engineering and Operations Activities Plan

Assurance Plan

Risk Management Plan

Configuration Management Plan

Delivery and Operational Transition Plan

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

TABLE OF CONTENTS

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 NOTES 14.0 APPENDICES  

EXPLANATORY NOTE

The purpose of the Management Plan is to provide the organisation for all planning information. It includes planning for management, assurance and development for all life cycle phases for the software, including sustaining engineering.

1.0 INTRODUCTION

Refer to the Template WIS for the detailed structure and content of this section.

2.0 RELATED DOCUMENTATION

Refer to the Template WIS for the detailed structure and content of this section.

3.0 PURPOSE AND DESCRIPTION

Describe the purpose, scope and major functions of the software being acquired by the organisation 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. Analysing possible impacts of proposed changes

d. Analysing 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 authorised changes and replanning actions on technical performance, schedules or cost. Also describe the process for obtaining authorised 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 organisation- 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, customer-furnished equipment (CFE), 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. Organisations affected

c. Specific milestones and deliverables

d. Delivery dates for acquired products and services

Describe subordinate schedules to be developed by performing organisations 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 organisation 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 authorisation procedures

d. The types of cost accumulations to be used

e. Target budgets for each organisation 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 Organisation

The purpose of this section is to describe in detail the organisational 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 organisational elements and internal and external organisational relationships and interfaces. Identify:

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

b. Interfaces between internal organisational elements, and with external organisations, 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 Authorisation

Describe the work authorization process in terms of the actions required to initiate, control, and terminate work. As applicable, describe the work authorisation 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 authorisation

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 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. Organisational Requirements and Life Cycle Adaptations

c. Management Approach

d. Technical Approach

Refer to the Acquisition Plan WIS for a further description of the structure and content under each topic.

6.0 DEVELOPMENT 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 WIS 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 Engineering and Operations Plan WIS for a further description of the structure and content for each topic.

8.0 QUALITY ASSURANCE PLAN

Describe the activities to be performed by the organisation 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 organisation 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 organisation 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 WIS for the detailed structure and content of this section.

13.0 GLOSSARY

Refer to the Template WIS for the detailed structure and content of this section.

14.0 APPENDICES

Refer to the Template WIS for the detailed structure and content of this section.

The Quality Assurance Plan specifies the conduct of quality assurance, quality engineering assurance, safety assurance, security and privacy assurance, testing, verification and validation, and certification during the acquisition or development of software.

CONTENTS

3.0 QUALITY ASSURANCE
3.1 Approach and Activities
3.2 Methods and Techniques
3.3 Products
4.0 VERIFICATION AND VALIDATION
4.1 Approach and Activities
4.2 Methods and Techniques
4.3 Products
5.0 QUALITY ENGINEERING ASSURANCE
5.1 Approach and Activities
5.2 Methods and Techniques
5.3 Products
6.0 SAFETY ASSURANCE
6.1 Approach and Activities
6.2 Methods and Techniques
6.3 Products
7.0 SECURITY AND PRIVACY ASSURANCE
7.1 Approach and Activities
7.2 Methods and Techniques
7.3 Products
8.0 CERTIFICATION
8.1 Approach and Activities
8.2 Methods and Techniques
8.3 Products

Refer to the Template WIS for the detailed structure and content of the document.

3.0 QUALITY ASSURANCE

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

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:

1. 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
2. Auditing activities to be conducted to assess quality of performance of management, technical, and assurance processes
3. 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
4. Evaluation of the effectiveness of problem reporting, corrective action, and change control and configuration management practices

3.2 Methods and Techniques

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

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

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

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:

1. 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
2. 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
3. Other quality factors (the other "ilities") as specified in the Product Specification and requirements section of the Acquisition Plan.

5.2 Methods and Techniques

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

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:

1. Hazards
2. Fault tolerance
3. 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

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

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, minimisation or potential for abuse or misuse, and maintenance of continuity of operations. Aspects may include:

1. Effective and accurate operations
2. Protection from unauthorised alteration, disclosure, use or misuse of information processed, stored, or transmitted
3. Maintenance of continuity of automated information support
4. Incorporation of management and operational controls
5. Appropriate technical, administrative, environmental and access safeguards

7.2 Methods and Techniques

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

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

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.