Attachment_0004_-_Data_Item_Descriptions_(DID)_Index.docx

DATA ITEM DESCRIPTION (DID) INDEX

For M1061

image3.emf

DI-SESS-80640D RFV.pdf

DATA ITEM DESCRIPTION

Title: REQUEST FOR VARIANCE (RFV)

Number: DI-SESS-80640D Approval Date: 20150407

AMSC Number: N9522 Limitation: N/A

DTIC Applicable: No GIDEP Applicable: No

Preparing Activity: NM Project Number: SESS-2015-012

Applicable Forms: DD Form 1694, Request for Variance (RFV)

Use/relationship: A Request for Variance describes a proposed departure from (a non-conformance with) approved product definition information for a limited amount of time/specified effectivity or a product found to be nonconforming with product definition information after the product has been produced by the production process.

a. This DID contains the format, content, and intended use information for the data deliverable resulting from the work task described in paragraphs 3.3.2 (1)-(6) of EIA-649-1 and the principles of EIA-649.

b. This DID supersedes DI-CMAN-80640C and DI-SESS-81883.

c. Copies of these standards are available online at http://www.sae.org or from SAE International, 400 Commonwealth Drive, Warrendale, PA 15096-0001, Tel 877-606-7323 (inside USA and Canada) or 724-776-4970 (outside USA).

d. An electronic version of DD Form 1694, Request for Variance (RFV), is available online at http://www.dtic.mil/whs/directives/forms/index.htm.

Requirements:

1. Reference Documents. The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as specified in the contract.

2. Format. The RFV shall be in one of the following formats:

a. DD Form 1694, Request for Variance (RFV),

b. The schema required by the Acquirer’s Integrated Data Environment (IDE), or

c. The Supplier’s preferred format.

3. Content. The RFV shall contain all the information in DD Form 1694.

End of DI-SESS-80640D

Source: https://assist.dla.mil -- Downloaded: 2016-08-22T12:31Z Check the source to verify that this is the current version before use.

http://www.sae.org/ http://www.dtic.mil/whs/directives/forms/index.htm image4.emf

DI-MGMT-80934C.pdf

Title: OPERATIONS SECURITY (OPSEC) PLAN

Number: DI-MGMT-80934C Approval Date: 20101213 AMSC Number: 9178 Limitation: N/A DTIC Applicable: No GIDEP Applicable: No Office of Primary Responsibility: NS/I925 Applicable forms: N/A

Use/Relationship: The OPSEC Plan is used to identify and monitor a contractor’s OPSEC activities during the performance of a contract. It is intended to be a living document that will require periodic updates throughout the life of the contract. The OPSEC plan; (1) Describes the OPSEC environment to include identification of critical information, the OPSEC threat and vulnerabilities an adversary might exploit to acquire critical information, (2) Documents the OPSEC risk analysis, (3) Identifies proposed and actual OPSEC measures, (4) Defines and assigns specific OPSEC responsibilities and ties the OPSEC Plan to the contractor’s corporate OPSEC Program, and (5) Serves as a repository of the OPSEC history of the contract.

a. This Data Item Description (DID) contains the format and content preparation instructions for the data product generated by the specific and discrete task requirements delineated in the contract.

b. This DID is applicable only when the contracting activity determines that the sensitivity of the contracted effort warrants OPSEC protections.

c. The contractor’s implementation of the OPSEC Plan, approved by the contracting activity, is subject to joint audit and/or inspection by the Defense Security Service and the contracting activity.

d. This DID supersedes DI-MGMT 80934B.

Requirements:

1. Reference documents: The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices and revisions, shall be as specified in the contract.

a. “Applying OPSEC to U.S. Government Acquisitions and Contracts”. This document is available from the Interagency OPSEC Support Staff (IOSS) at the following web address:

www.ioss.gov.

b. Department of Defense Manual (DODM) 5205.02M, DOD Operations Security (OPSEC) Program Manual, dated November 3, 2008.

Source: https://assist.dla.mil -- Downloaded: 2017-01-18T18:41Z http://www.ioss.gov/

DI-MGMT-80934C

c. Department of Defense Contract Security Classification Specification (DD 254). This document is included as a part of all Request for Proposals (RFP) and Contracts involving classified data.

d. Contract Data Requirements List (CDRL). This document is included as a part of all RFP and contracts containing data deliverable requirements.

e. National Industrial Security Program Operating Manual (NISPOM) 5220.22M, dated February 28. 2006.

2. Format: The OPSEC Plans shall be submitted in contractor determined format and, at a minimum, consist of the following sections listed in the Content Section below.

3. Content:

3.1 COVER PAGE

The cover page for an OPSEC Plan shall clearly present, at a minimum, the following information:

1. Title of the Acquisition Program

2. Title of the Document (i.e. “Operations Security Plan”)

3. Reference to the government contract number

4. Date of latest revision

5. Name, signature and title of the preparer of the OPSEC Plan

6. Name, signature and title of the approver of the OPSEC Plan.

7. Reference for whom the document was prepared (Contracting activity)

8. Reference by whom the document was prepared (Corporation)

9. All appropriate distribution or classification statements

3.2 TABLE OF CONTENTS PAGE

The Table of Contents for an OPSEC Plan shall outline each section contained in the OPSEC Plan.

3.3 PREFACE PAGE

The purpose of the Preface is to provide a brief, unclassified, overview of the program and the need for OPSEC measures. The specific objectives of the contracted effort shall be introduced with reference to all strategic participants and partnerships required to make the program a success. The anticipated development of any innovative concepts or technologies shall also be introduced in the Preface.

The Preface shall reference all links between the OPSEC Plan and any corporate OPSEC Program(s). The Preface may conclude by referencing requirement documents such as the contract number, Contract Security Classification Specification (DD254), Contract Data

Requirements List (DD1423) and any other pertinent guidance provided by the contracting activity. It shall also provide an OPSEC point of contact, with contact information, for additional guidance or assistance such as the OPSEC program manager or contractor program manager.

3.4 OPSEC PLAN INTRODUCTION

3.4.1 Purpose and Scope: The purpose of the OPSEC Plan shall be effectively communicated in this section and include a description of the scope of the OPSEC Plan (unique physical locations, subcontractors, suppliers, period of performance, etc.).

3.4.2 Authorities: The requirement to protect critical information shall be documented within this section. Documenting the requirement can be achieved by referencing the Corporate OPSEC Program (Policy) and Plan, DODM 5205.-2M, specific contract documents including the DD254 for contracts involving classified data, or other contracting activity specific guidance.

3.4.3 OPSEC Plan Major Activity Timeline: This section shall include a list of all major OPSEC Plan activities such as quarterly OPSEC Working Group Meetings, Annual Assessments, scheduled OPSEC awareness training, Sub-contractor OPSEC Assessments and Surveys, Threat and Vulnerability Reviews, etc. This section shall also include scheduled OPSEC Plan reviews.

3.4.4 Responsibilities: The OPSEC Plan shall identify whom is responsible for the major activities described in the Plan. For example (not intended as an inclusive list):

The OPSEC Manager shall be identified by name and include a list of duties that may include:

1. Coordinate all OPSEC policy responsibilities/ procedures within the program.

2. Revise the Program OPSEC Plan as necessary.

3. Convene and coordinate the annual Program OPSEC Assessment.

4. Disseminate updated threat information to program personnel.

5. Assist in the review of contract requirements for OPSEC considerations.

6. Conduct OPSEC briefing(s) upon customer approval of the plan.

7. Principal advisor to the Contractor Program Manager on all OPSEC matters.

8. Develop/Disseminate Program Critical Information List (CIL).

9. Promote OPSEC awareness within the program.

The Contractor Program Manager shall be identified by name and include a list of duties that may include:

1. Responsible for the overall implementation of the program/contract.

2. Ensure proper OPSEC procedures are implemented by program personnel.

3. Ensure all subcontractors and suppliers supporting the program develop and implement procedures in compliance with the Program OPSEC Plan.

4. Remain cognizant of emerging OPSEC threats and vulnerabilities that may adversely impact upon the success of the program.

5. Actively participate in periodic Program OPSEC assessments.

6. Remain cognizant of any changes in critical information and communicate them to the Program OPSEC Manager.

7. Promote OPSEC awareness within the program.

A short description of the expectations and responsibilities of all program personnel (including subcontractors and suppliers) shall be provided and may typically include:

1. Remain compliant with all applicable OPSEC Plans.

2. Maintain an awareness of all applicable CIL.

3. Attend all OPSEC program briefings.

4. Timely reporting of any OPSEC concerns to the Contractor Program Manager and/or the Program OPSEC Manager.

5. Generation of OPSEC Plans (sub-contractors or suppliers only).

3.4.5 Organizational OPSEC Communications and Interfaces: A description as to how the OPSEC Plan will be communicated to all personnel supporting the program (hardcopy, via a webpage, briefings, etc.).

3.4.5.1 Internal: In this section the OPSEC Plan shall identify all anticipated OPSEC interfaces internal to the corporation such as the senior corporate leadership, corporate OPSEC Working Group, OPSEC coordinators, program personnel, etc.

3.4.5.2 External: In this section the OPSEC Plan shall identify all anticipated external points of contact such as the contracting activity, Defense Contract Management Agency (DCMA), The Defense Security Service (DSS), Federal Bureau of Investigation (FBI) and local law enforcement and their primary role within the OPSEC program (i.e. DCMA audits acquisition management practices, DSS provides security oversight, FBI and law enforcement may provide threat data). Subcontractor and supplier OPSEC points of contact shall be similarly identified.

3.4.6 Marking, Handling and Distribution of Documents: This section shall provide a description of marking, handling, storage, access and transmission authorizations and procedures for any critical information provided to, or generated by, the contractor.

Reference to the program classification guide, Freedom of Information Act and any additional guidance provided by the contracting activity may be cited as applicable.

3.5 THREAT

3.5.1 General Threat: This section shall identify and demonstrate an understanding of the overall threat to program critical information throughout the anticipated duration of the contract/program. For example, an information systems program might note the following:

DSS analysis of 2008 threat data shows, “Information systems, especially C4ISR related systems remained the primary sought-after technology for East Asia and Pacific Region countries. Direct requests (often via the Internet) and other suspicious Internet activity continued to be the preferred method of collection. Information systems are primary targets for Near East adversaries of the United States. Near East commercial entity activity indicates a growing collusion between commercial entities and government associated entities such as universities, public agencies and research and development centers. Adversaries using HUMINT and OSINT collection methods represent a significant threat to program critical information. i

The section shall conclude with a brief description of all identified intelligence collection methods that may be expected to be used by an adversary to acquire critical information.

Note: A general description of intelligence collection methods may be found in “Applying OPSEC to Government Acquisitions and Contracts” at www.ioss.gov.

3.5.2 Program Detailed Threat: This section shall be similar to section 3.5.1 above referencing any known direct threats to acquisition specific elements of critical information within the program/contract. As complete a description of each threat as possible shall be provided while maintaining the overall plan classification at the unclassified level. Since detailed threat information may derive from classified sources, reference to source documents as provided by the government contracting activity or other reputable source is permitted.

3.5.3 Threat Analysis: Each threat identified in sections 3.5.1 and 3.5.2 shall be analyzed to determine the level of threat to the corresponding critical information. The results of this analysis shall be presented in this section. A description of the specific threat analysis method used by the contractor to quantify each threat shall be included in this section.

Note: For additional guidance and a sample threat analysis methodology see, “Applying OPSEC to Government Acquisitions and Contracts” at www.ioss.gov and DODM 5205.02.

3.5.4 Changes Within Threat Environment: The Threat section shall conclude with a statement that addresses how new threat data is to be received and incorporated into the OPSEC Plan to ensure OPSEC risk remains in compliance with all applicable guidance.

3.6 CRITICAL INFORMATION

3.6.1 General: Critical information shall be identified within this section of the plan and a comprehensive program Critical Information List (CIL) shall be included.

3.6.2 Critical Information List: Guidance on the creation of a CIL is contained within “Applying OPSEC to Government Acquisitions and Contracts,” available at www.ioss.gov, DODM 5205.02M, or may be provided by the contracting activity. Ideally the CIL shall remain unclassified to facilitate wide internal distribution, but may provide reference to classified information as applicable.

3.7 VULNERABILITY

3.7.1 General: The Vulnerability section of the OPSEC Plan shall describe the analysis of activities (indicators) that point to OPSEC vulnerabilities an adversary can exploit to acquire critical information. This section shall contain a list of all identified OPSEC vulnerabilities.

3.7.2 List of OPSEC Vulnerabilities: Each vulnerability shall be described in sufficient detail as to communicate to the contracting activity the extent of the vulnerability. The Vulnerability List shall remain unclassified, but may provide reference to classified information if applicable. Reference to classified reports and other information shall include an unclassified description of the documentation (report title, number, etc.) and the source responsible for publication of the information.

Note: A list of typical OPSEC vulnerabilities which may require OPSEC measures may be found within “Applying OPSEC to Government Acquisitions and Contracts”, available at www.ioss.gov or may be provided by the contracting activity. These sample vulnerabilities are not all inclusive and the submitted vulnerability list shall be tailored to the specific acquisition or contract.

3.7.3 Vulnerability Analysis: Once potential program vulnerabilities have been identified, the magnitude of each vulnerability shall be determined using a consistent methodology identified and documented in this section of the OPSEC Plan. The results of this analysis shall also be described in this section.

Note: For additional guidance and a sample vulnerability methodology see, “Applying OPSEC to Government Acquisitions and Contracts” at www.ioss.gov and DODM 5205.0-2M.

3.8 RISK ASSESSMENT

3.8.1 General: The OPSEC risk of a program represents the probability of compromise of critical information and the impact to the program/contract taking into account the threat and vulnerabilities. The acceptable level of OPSEC risk (as determined by senior leadership, or the contracting activity) shall be described in this section in terms consistent with the selected OPSEC methodology.

3.8.2 Risk Assessment: The specific OPSEC risk shall be described in terms consistent with the OPSEC methodology selected for determining OPSEC threat and vulnerability.

The method, and the results of the assessment, shall be presented in this section. The conclusion of the risk assessment shall result in an ordinal ranking of OPSEC risk (highest to lowest).

Note: Additional guidance and a sample risk methodology are available in “Applying OPSEC to Government Acquisitions and Contracts” at www.ioss.gov and DODM 5205.0-2M.

3.9 OPSEC MEASURES

3.9.1 General: This section of the OPSEC Plan shall identify specific OPSEC

Measures proposed for mitigating OPSEC risk to acceptable levels including the cost to implement each measure. A sampling of common OPSEC measures is available in “Applying OPSEC to Government Acquisitions and Contracts” at www.ioss.gov . This list is not to be considered exhaustive and is provided as guidance for the development of the program/contract specific list of potential OPSEC measures.

3.9.2 Residual Risk: This section shall contain an analysis of residual OPSEC risk, in terms consistent with the OPSEC methodology selected, as a result of implementation of each OPSEC measure presented in section 3.9.1. This section shall identify which OPSEC measures will be implemented and the rationale for those that will not.

3.10 OPSEC Program Chronology: This section shall document significant program OSPEC events throughout the lifecycle of the program. Significant events may include changes to the CIL, changes in program leadership or results of program assessments and surveys (including subcontractors). At a minimum, this section shall include a brief description of the event, date of occurrence, actions taken by the contractor and final disposition. A known compromise of critical information need only be referenced in keeping with the intended classification of this document.

Note: The history contained herein may be used by the government as a part of an OPSEC or security audit conducted by the contracting activity, DSS or other authorized agency.

3.11 ACRONYMS: This section shall include a complete list of acronyms used in the Program OPSEC Plan (i.e., CDRL – Contract Data Requirements List, DID – Data Item Description, etc.).

3.12 REFERENCES: This section shall include a complete list of all references cited in the Program OPSEC Plan (i.e. DoD Manual 5205.02-M, dated November 3, 2008, Contract Number, Corporate OPSEC Plan(s)/Program(s), etc.).

i The specific example provided derives from annual documentation produced by the Defense Security Service, Counterintelligence Office in 2009. Current assessments may be found at https://www.dss.mil/isp/count_intell/count_intell.html.

4. END OF DI-MGMT-80934C.

image5.emf

DI-NDTI-80566A

Title: Test Plan

Number: DI-NDTI-80566A Approval Date: 14 Nov 2006 AMSC Number: 7639 Limitation: N/A DTIC Applicable: No GIDEP Applicable: No Office of Primary Responsibility: NS/DA02 Applicable Forms: N/A

Use/relationship: The Test Plan outlines the plans and performance objectives at every level of testing on systems or equipment. It provides the procuring activity with the test concept, objectives and requirements to be satisfied, test methods, elements, responsible activities associated with the testing, measures required and recording procedures to be used.

This Data Item Description (DID) contains format and content preparation instructions for the data product generated by the specific and discrete task requirement as delineated in the contract.

This DID is applicable to system and equipment tests that include design evaluation tests, engineering tests, preliminary qualification tests, formal qualification tests, human factors tests, operational tests and acceptance tests.

This DID supersede DI-NDTI-80566.

Requirements:

1. Reference documents. None.

2. General. The test plan shall document in detail the contractor’s plan for conducting tests and analyzing the test results to show how the system, when fielded, will satisfy the requirements of the applicable design specification.

3. Format: The plan shall be in contractor’s format.

4. Contents. The plan shall contain the following:

4.1 Title page. The title page shall include the following:

a. Title of the test to be conducted.

b. Identification of system being tested.

c. Contractor’s name.

d. Contractor number.

e. Security classification.

f. Distribution statement.

4.2 Introduction. Consists of an overview of the objectives of the test plan, including flow diagrams, milestones, personnel participation, locations, schedules, and security measures to be observed. The plan shall include the following:

4.3 Flow diagrams. The flow diagrams will reflect a functional description of the test program using a block diagram portrayal of the functions that must be met to satisfy the total test program. Functions shall be numbered 1.0, 2.0, 3.0, etc.

4.4 Milestones. Identifies the start and expected completion dates of each test to be performed.

4.5 Participation. Identifies the government and contractor participation roles and responsibilties.

4.6 Location. Identifies the facilities where the testing will be performed.

4.7 Schedule. States when testing will be performed, whether testing is on schedule, and if not, what procedures will be taken to meet the schedule.

4.8 Security. Identify and state briefly any security measures of guidelines to be observed.

4.9 Master test list. Lists all tests to be accomplished in the order they are to be performed. A separate listing for each location shall be provided. Each listing shall include the following:

4.9.1 Test description. Name and brief description of test to be performed.

4.9.2 Applicable specification (s). The specifications shall be identified as follows:

a. Title and identification number.

b. Paragraph number associated with the tests.

c. Title of test.

d. Functional category of test.

4.9.3 Parameters. The number of cycles the test will be performed and selected parameters to be observed.

4.9.4 Special tests. Provides a list of special or unusual tests and examination necessary to verify satisfactory equipment performance to specifications.

4.9.5 Test classification category. State the functional area of each test performed.

4.9.6 Test objectives. Describes the objectives of each test performed, including the criteria, baseline, duration, and number of times each test should be performed.

a. Success/failure criteria.

b. Baseline.

c. Duration.

d. Quantity of test.

4.9.7 Test equipment. List all equipment to be used in the test and identify as follows:

a. Description.

b. Nomenclature.

c. Serial number.

4.9.8 Support equipment. List all support equipment that will be used to perform the tests and identify as follows:

a. Description.

b. Nomenclature.

c. Serial number.

d. Calibration constants.

e. Calibration procedures.

f. Operating instructions.

4.9.9 Special test equipment. List all special test equipment required to be designed or fabricated for use on the program as follows:

a. Description.

b. Nomenclature.

c. Data required.

4.9.10 Approach. Describe the steps used to perform each test.

4.9.11 Instrumentation. Indicates the type and recording devices that will be used and the number and types of parameters to be recorded.

4.9.12 Data reduction and analysis. Describes data to be recorded and the data reduction and analysis techniques that will be used to interpret the data.

4.9.13 Government test facilities. Identifies applicable facility and includes a reference to the appropriate facility requirements documents.

Validation procedure. An overview of the procedures that the contractor will use to validate the test results.

5. END OF DI-NDTI-80566A

DATA ITEM DESCRIPTION

Requirements:

image6.emf

DI-MGMT-81650 INTEGRATED MASTER SCHEDULE (IMS).pdf

TITLE: INTEGRATED MASTER SCHEDULE (IMS)

NUMBER: DI-MGMT-81650 APPROVAL DATE: 20050330

AMSC NUMBER: D7544 LIMITATION:

DTIC APPLICABLE: GIDEP APPLICABLE:

PREPARING ACTIVITY: OUSD(AT&L)ARA/AM(SO)

APPLICABLE FORMS: None

USE/RELATIONSHIP: The Integrated Master Schedule (IMS) is an integrated schedule containing the networked, detailed tasks necessary to ensure successful program execution. The IMS is vertically traceable to the Integrated Master Plan (IMP) (if applicable), the Contract Work Breakdown Structure (CWBS), and the Statement of Work (SOW). The IMS shall be used to verify attainability of contract objectives, to evaluate progress toward meeting program objectives, and to integrate the program schedule activities with all related components. This DID is applicable to development, major modification, and low rate initial production efforts; it is not typically applied to full rate production efforts.

a. This Data Item Description (DID) contains the format and content preparation instructions for the data product generated by the specific and discrete task requirement as delineated in the contract.

b. This DID shall be applied to contracts that require Earned Value Management (EVM) and other contracts based on the contract risk assessment.

Refer to the Earned Value Management Implementation Guide (EVMIG) for guidance on tailoring reporting.

c. The prime contractor is required to include significant external interfaces and critical items from suppliers, teammates, or other detailed schedules that depict significant and/or critical elements and Government furnished equipment or information dependencies for the entire contractual effort in a single integrated network. The determination of significant and critical shall be agreed to by the Government and the contractor and shall be defined and documented in the Contract Data Requirements List (CDRL).

d. The IMS shall be statused according to the contractor’s management control system and shall be submitted no less frequently than monthly. If a Contract Performance Report (CPR) is required, the IMS shall be statused and submitted to the procuring activity prior to or concurrently with CPR Formats 1-5 (as applicable). The IMS may reflect data either as of the end of the calendar month or as of the contractor’s accounting period cutoff date, provided it is consistent and traceable to the CPR (if applicable). When subcontractor schedule data reflects a different status date than the prime contractor’s schedule status date, these status dates shall be described in the analysis section of the IMS.

e. This DID shall be used in conjunction with the CWBS DID, DI-MGMT-81334A, and the CPR DID, DI-MGMT-81466. (Note: The IMS DID may be required when there is no EVM (CPR) requirement.)

REQUIREMENTS:

1. Format. The IMS shall be created using a network capable Commercially Off the Shelf (COTS) scheduling software application. Unless otherwise provided in the CDRL, the IMS shall be delivered electronically in the native digital format (i.e., an electronic file produced by the contractor’s scheduling

DI-MGMT-81650

tool). (Note: When the technology is available, the CDRL may be tailored, upon agreement between the prime contractor and the Government representative, to allow the American National Standards Institute (ANSI) X12 standard (806 transaction set), the United Nations Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) standard (PROTAP message), or the XML equivalent to be used to submit data electronically to the procuring activity with on-line access to the data.)

2. Content. The schedule shall contain the contract milestones, accomplishments, and discrete tasks/activities (including planning packages where applicable) from contract award to the completion of the contract. The schedule shall be an integrated, logical network-based schedule that correlates to the CWBS, and is vertically and horizontally traceable to the cost/schedule reporting instrument used to address variances such as the CPR (if applicable). The schedule shall have a numbering system that provides traceability to the IMP (if applicable) and SOW. It shall contain contractual milestones and descriptions and display summary, intermediate, and detailed schedules, and periodic analysis of progress to date. It shall include fields and data that enable the user to access the information by product, process, or organizational lines.

2.1 Contract Milestones and Definitions. Key programmatic events, which define progress and completion for each CWBS element, along with the definition for successful completion of the milestone.

2.2 Summary Master Schedule. A top-level schedule of key tasks/activities and milestones at the summary level of the CWBS and IMP (if applicable). It shall be an integrated roll up of the intermediate and detailed schedules (see

2.3 and 2.4 below) (vertical integration).

2.3 Intermediate Schedules. Mid-level contract schedules that include key tasks/activities and milestones and all associated accomplishments in the summary master schedule, traceable to the CWBS element or IMP event as necessary to display work effort at the intermediate level of summarization.

There may be several intermediate schedules that depict varying levels of detail. They shall be integrated roll ups of the detailed schedules (see 2.4 below) (vertical integration).

2.4 Detailed Schedules. The lowest level of contract tasks/activities that form the network. The detailed schedules shall contain horizontal and vertical integration, as a minimum, at the work package and planning package level. The detailed schedules shall include all tasks/activities, work packages, and planning packages identified in the contract Performance Measurement Baseline (PMB). Every discrete task/activity, work package, and planning package shall be clearly identified and directly related to a control account. Work packages and planning packages shall be individually represented and summarize to or reconcile with the total budget for that control account. If Level of Effort (LOE) control accounts, work packages, or planning packages are included as tasks in the IMS, they shall be clearly identified as such. The detailed tasks/activities, work packages, and planning packages shall be traceable to only one CWBS, IMP, and performing organizational element, as applicable. The level of detail in the IMS (including number and duration of tasks/activities) shall follow the contractor’s EVM process as documented in the EVMS system description, program directives, etc. Shorter-term work packages (ideally equal in length to the statusing interval) are preferred because they provide more accurate and reliable measures of work accomplished.

2.4.1 Key Elements of Detailed Schedules. The key elements of the detailed schedules include the following:

2.4.1.1 Task/Activity. An element of work with duration.

2.4.1.2 Milestone. A specific definable accomplishment in the contract network, recognizable at a particular point in time. Milestones have zero duration and do not consume resources.

2.4.1.3 Duration. The length of time estimated (or realized) to accomplish a task/activity.

2.4.1.4 Percent Complete (Schedule). The proportion of an activity or task that has been completed to time now. This usually involves updating or statusing the activity or task utilizing one of two methods: (1) update the remaining time to complete (remaining duration) and the scheduling software will then automatically update the schedule percent complete or (2) update the schedule percent complete and allow the scheduling software to calculate the time remaining (remaining duration) to complete. Either method will use the following formula: Percent of Duration Completed = (Actual Duration / Total Duration) X 100.

2.4.1.5 Task/Activity and Milestone Descriptions. These are descriptive titles that are concise, complete, and clearly identify the work effort being accomplished. Abbreviations may be used to shorten the descriptive titles.

2.4.1.6 Task/Activity Codes and Data Dictionary. A list of field definitions and code structures. This list shall be provided to the procuring activity.

2.4.1.7 Relationship/Dependency. These identify how predecessor and successor tasks/activities and milestones are logically linked.

Relationships, also called network logic, are modeled in four ways:

2.4.1.7.1 FS (Finish to Start). A predecessor task/activity or milestone that must finish before a succeeding task/activity or milestone can start. FS relationships shall be used whenever possible.

2.4.1.7.2 SS (Start to Start). A predecessor task/activity or milestone that must start before a succeeding task/activity or milestone can start.

2.4.1.7.3 FF (Finish to Finish). A predecessor task/activity or milestone that must finish before a succeeding task/activity or milestone can finish.

2.4.1.7.4 SF (Start to Finish). A predecessor task/activity or milestone that must start before a succeeding task/activity or milestone can finish.

2.4.1.8 Total Float/Slack. The amount of time a task/activity or milestone can slip before it delays the contract or project finish date.

2.4.1.9 Free Float/Slack. The amount of time a task/activity or milestone can slip before it delays any of its successor tasks/activities or milestones.

2.4.1.10 Lag. An interval of time that must occur between a predecessor and successor task/activity or milestone. Since negative time is not demonstrable, negative lag is not encouraged. (Note: Lag should not be used to manipulate float/slack or constrain schedule.)

2.4.1.11 Early Start (ES). The earliest start date a task/activity or milestone can begin the precedence relationships. A computer-calculated date.

2.4.1.12 Early Finish (EF). The earliest finish date a task/activity or milestone can end. A computer-calculated date.

2.4.1.13 Late Start (LS). The latest start date a task/activity or milestone can start without delaying the contract or project target completion date. A computer-calculated date.

2.4.1.14 Late Finish (LF). The latest date a task/activity or milestone can finish without delaying the contract or project target completion date. A computer-calculated date.

2.4.1.15 Critical Path. A sequence of discrete tasks/activities in the network that has the longest total duration through the contract or project.

Discrete tasks/activities along the critical path have the least amount of float/slack. The critical path and near-critical paths (reporting requirements for near-critical paths shall be specified in the CDRL) are calculated by the scheduling software application. The guidelines for critical path and near-critical path reporting are as follows:

2.4.1.15.1 Methodology. The IMS software application computes a critical path and near-critical paths based on precedence relationships, lag times, durations, constraints, and status. Artificial constraints and incorrect, incomplete, or overly constrained logic shall be avoided because they can skew the critical path and near-critical paths.

2.4.1.15.2 Identification. The critical path shall be easily identified.

2.4.1.16 Constraints. Limits applied to network start and finish dates (e.g., “finish no later than”). (Note: Certain types of constraints should be used judiciously because they may impact or distort the network critical path.)

2.4.1.17 Current Schedule. The IMS reflects the current status and forecast.

It includes forecasted starts and finishes for all remaining tasks/activities and milestones. Significant variances to the baseline schedule shall be explained in the periodic analysis. Thresholds for reporting shall be specified in the CDRL.

2.4.1.18 Baseline Schedule. Baseline dates in the IMS shall be consistent with the baseline dates in the PMB for all work packages, planning packages, and control accounts (if applicable). The guidelines for maintaining the baseline schedule are as follows:

2.4.1.18.1 Schedule Changes. Changes to the schedule shall be baselined when incorporated into the schedule.

2.4.1.18.2 Baseline Schedule Changes. Changes to the baseline schedule shall be made in accordance with the contractor’s EVM process. Any movement of contractual milestones in the baseline schedule shall be derived only from either authorized contract changes or an approved over target schedule.

2.4.1.19 Schedule Progress. The IMS shall reflect actual progress and maintain accurate start and finish dates for all tasks/activities and milestones. The guidelines for reflecting schedule progress are as follows:

2.4.1.19.1 Actual Start and Finish Dates. Actual start and actual finish dates shall be recorded in the IMS. Actual start and actual finish dates, as recorded, shall not be later than the status date.

2.4.1.19.2 Progress Line. The progress line depicted in a Gantt chart shall be applied to the current schedule.

2.4.1.20 Retention of Data for Completed Tasks/Activities. Historical performance on completed tasks/activities shall be maintained electronically for analytical use. Historical performance shall be maintained at the time of key program events (Integrated Baseline Review, Critical Design Review, etc.)

for all critical tasks/activities. Data to be retained includes logic, actual and baseline durations, actual and baseline start and finish dates, and the three-point estimates that were used before the task/activity started.

2.4.1.21 External Dependencies. The IMS shall identify significant external dependencies that involve a relationship or interface with external organizations, including all Government furnished items (e.g., decisions, facilities, equipment, information, data, etc.). The determination of significant shall be agreed to by the Government and contractor and shall be defined and documented in the CDRL. The required or expected delivery dates shall also be identified in the IMS.

2.4.1.22 Schedule Margin. A management method for accommodating schedule contingencies. It is a designated buffer and shall be identified separately and considered part of the baseline. Schedule margin is the difference between contractual milestone date(s) and the contractor’s planned date(s) of accomplishment.

2.4.1.23 Schedule Risk Assessment. A schedule risk assessment predicts the probability of project completion by contractual dates. Three-point estimates shall be developed for remaining durations of remaining tasks/activities that meet any of the following criteria: (1) critical path tasks/activities, (2) near-critical path tasks/activities (as specified in the CDRL), (3) high risk tasks/activities in the program’s risk management plan. These estimates include the most likely, best case, and worst case durations. They are used by the contractor to perform a probability analysis of key contract completion dates. The criteria for estimated best and worst case durations shall be applied consistently across the entire schedule and documented in the contractor’s schedule notes and management plan. The guidelines for estimates are as follows:

2.4.1.23.1 Most Likely Estimate. Schedule durations based on the most likely estimates.

2.4.1.23.2 Best/Worst Case Estimates. Best and worst case assumptions shall be disclosed.

The contractor schedule risk assessment shall explain changes to the critical path, margin erosion, and mitigation plans. It shall be incorporated into the contractor’s program risk management process. The schedule risk assessment shall be submitted as specified in the CDRL and prior to the Integrated Baseline Review. The risk analysis may be performed within the IMS or within a separate risk tool as appropriate based on the capability of the automated scheduling tool.

2.4.1.24 User Defined Fields. All user defined fields in the IMS shall be identified by providing a mapping of all fields used in the scheduling software application.

2.4.1.25 Reserved Fields. The Government may reserve some fields and/or require the contractor to use certain fields for specific information. The requirement for reserved fields shall be specified in the CDRL.

2.4.1.26 Calendar. The arrangement of normal working days, together with non-working days, such as holidays, as well as special work days (i.e., overtime periods) used to determine dates on which project work will be completed.

2.5 Monthly Analysis. Monthly analysis is a monthly assessment of schedule progress to date and includes changes to schedule assumptions, variances to the baseline schedule, causes for the variances, potential impacts, and recommended corrective actions to minimize schedule delays. The analysis shall also identify potential problems and an assessment of the critical path and near-critical paths. Thresholds for reporting significant variances to the baseline schedule and near-critical paths shall be specified in the CDRL.

If a CPR Format 5 is required, the monthly analysis shall be submitted to the procuring activity prior to or concurrently with the CPR Format 5.

END OF DI-MGMT-81650

image7.emf

DI-NDTI-80809B

DATA ITEM DESCRIPTION I Form Approved OMB No.0704.0188

1.nTLE 2.IOENTIFICATIONNUMBER

TEST/ INSPECTION REPORT DI-NM’I-80809B

L OESCRIPTlOtVPURPOSE

3.1 The testl inspection report is used to document testl inspection results, findings, and analyses that will enable the government or contracting agency to evaluate compliance with system requirements, performance objectives, specifications, and test linspection plans.

1.APPROVALDATE 5.OFFICEOFPRIMARYRESPONSIBILITY(OPB) Ea.DTICAPPLICABLE 6b.CWIEP AppliCable

(YVMMOD)

F/AFMC-DCJP

970124

,.APPLlCAT\0NflNTER7iElAT10NSH1P

7.1 This data item description (DID) contains the format and content preparation instructions for the data product generated by the specific and discrete task requirement

I as delineated in the contract.

I

7.2 This DID is applicable to engineering (developmental ), preliminary qualification, qualification, and acceptance testing.

7.3 This DID supersedes DI-NDTI-80809A and DI-MISC-80653

1.APPROVALLIMITATION 9a.APPLICABLEFORMS 9b.AMSCNUMBER

F7231

10,PREPARATIONlNSTRUCnONS

10.1 Format. Contractor format is acceptable.

paragraph 10.2 and its subparagraphs in a manner understanding

10.2 CQnL!aL. The test/inspection report shall

applicable.

Organize the information required by that facilitates presentation and contain the following information, as

10. 2.1 Cove. and tile uaae. The following information shall appear on the outside front :over and title page:

a. Report date.

b. Report number (contractor or government)

Contractor’ s name, address, and commercia 1 and government entity code.

Contract number and contract line item number or sequence number (if applicable)

e. ‘fvpe of test/inspection (for example. first article acceptance test, aualitv con formanc-e-inspection, d-evelopmental test-, qualification test, f Identification of item tested/inspected.

9. Date or period of test/inspection.

h. Name and address of requiring government activity.

i. Security classification, downgrading and declassifying environmental Lest) .“ information, if applicable.

(Continued on page 2 )

1.DIS77UBUTIONSTATEMEW

DISTRIBUTION STATEMRNT A : APPROVED FOR PUBLIC RELBASE; DISTRIBUTION IS UNLIMITED.

ID Form 1664,APR 89 PreviOLIsedtliomwe obsdem. Page 1 of & Pages 39123

Block 10, Preparation Instructions (continued)

10.2.2 ~. The table of contents shall identify the following:

a. The title and starting page of each major section, paragraph, and apPendix of the report.

b. The page, identifying number, and title of each illustration (for example; figure, table, photograph, chart, and drawing)

10 .2.3 -ductim. The introduction shall include the following information:

10.2 .3.1 obyectlve W. The specific test/ inspection objective (s) as specified in the contract tasking document.

10. 2.3.2 L.temls) tes~. Complete identification of the item(s) testedl inspected including the following:

a. Nomenclature.

b. National stock number.

Model number, part number t and serial number :: Type of item (for example, prototype, production item, laboratory model )

e. Serial or lot number.

f. Applicable engineering changes

9. Production item specification, if applicable.

h. Date of manufacture.

10.2 .3.3 Complete inspection requirements correlated to contractual

Required testl inspection parameters :: Performance requirements, acceptance or environmental criteria.

10.2.4 ~. Complete test/inspection report identification of the testl requirements including the compliance limits, and summary including the

a. A brief discussion of the significant test/inspection results, ObSerVati Qns, conclusions, and recommendations covered in greater detail elsewhere in the report.

b. Proposed corrective actions and schedules for failures or problems encountered.

c. Identification of deviations, departures, or limitations encountered, referenced to the contract requirements.

d. Tables, graphs, illustrations, or charts as appropriate to simplify the summary data.

10.2.5 ~. Complete identification of all documents referenced in the test finspection report including the following, as applicable:

a. Prior testf inspection reports on the same item.

b. Test /inspection plans and procedure documents

c. Prior certifications of compliance.

d. Contractor’ s file designation where test/ inspection records are maintained.

e. Input parameters used.

The applicable issue of the documents cited therein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as specified in the contract.

Page 2 of 4 Pages

10.2.6 ~. The body of the testlinspection report shall be as follows :

10 .2.6.1 KzZL_ + de.tlflca~.

Complete identification of each item of test equipment used in the testlinspection including the following:

a.

b.

c.

d.

e.

f.

9.

10. 2.6.2

Nomenclature.

Model number.

Serial number.

Manufacturer.

Calibration status.

Accuracy data.

Comments, if applicable.

Testlinmection kuhtv mstd.b&mn and set–w. Complete description of the physical set-up used in conducting the test/inspection to include the following:

a. Location or orientation of the item.

b. Location. orientation, or settinm of test equipment and instrumentation.

c. Location, orientation, or settings of sensors and probes

d. Location or orientation of interconnections, cables, and hoop-ups.

e. Electrical power, pneumatic, fluidic, and hydraulic requirements.

Drawings, illustrations, and photographs maY be used for clarification.

10 .2.6.3 wrocedur~. Complete description of the procedures used in conducting the test/inspection to include the following:

a. Item selection and inspection that verified suitability for test/ inspection.

b. Summarized sequence of testing/inspection steps, including a description of how the item was operated during the test/inspection, and any control conditions imposed.

10 .2.6.4 A copy of all testlinspection results and analysis to include the following:

10.2.6 .4.1 ~. The actual recorded data (for example, log book entries, oscillographs, instrument readings, plotter graphs) If the recorded data is extensive, provide it in an appendix.

10. 2.6.4.2 Test/ insQec!iion resu. Identification of all testlinspection results to include the following:

a. Matrices comparing results achieved against test/inspection objectives or requirements

b. A discussion of these matrices as to their significance, and how they compare to any prior testlinspections.

Calculation examples.

;; Discussion of anomalies, deviations, discrepancies, or failures, including their impact, causes, and proposed corrective actions The discussion shall address discrepancies between design requirements and the tested/inspected Configuration.

10. 2.6.5 Conclusicxls Test/ inspection conclusions distinguished between objective and subjective to include the following:

a. The effectiveness of the testlinspection procedures in measuring item performance.

Page 3 of 4 Pages

b. The success or failure of the item to meet required test/inspection objectives.

c. The need for repeat, additional, or alternative tests linspections.

d. The need for item redesign or further development.

e. The need for improved test/inspection procedures, techniques, or facilities.

f. The adequacy and completeness of the test/inspection requirements.

10.2 .6.6 Recommendations appropriate to the test/inspection results and conclusions including the following:

a b.

c.

d.

e.

f.

9.

h.

Acceptability of the item tested/inspected (pass or fail) Additional testing/inspection required. ,.

Redesign required.

Problem resolution.

Test/inspection procedure or facility improvements Disposition of items tested/inspected.

Documentation changes required.

Testing/ inspection improvements

10.2.7 The following certifications shall be included, .as

applicable:

10.2 .7.1 A statement that the testlinspection was performed in accordance with applicable testlinspection plans and procedures, and that the results are true and accurate. The authentication shall include the signature of the contractor personnel that performed the test(s) /inspection(s) , a contractor representative authorized to make such certification, and any government witnesses

10…