DRAFT_Exhibit_A_-_GAP_CIE_CDRLs.pdf

FA8707-12-R-0014

Exhibit A

Representative Matrix of CDRL Ordering

For each type of delivery, an “X” in the column indicates that this CDRL is likely to be required as part of the indicated delivery order type. The Government reserves the right to tailor each delivery order as needed; this is only a guide. The Request for Proposal (RFP) for a specific delivery order will classify the delivery as either a sustainment delivery order or a major enhancement delivery order.

CDRL CDRL Name As

Reqd

Monthly Annual Sustainment Delivery

Order

Major Enhancement

Delivery Order

A001 Software Development Plan X

A002 Software Requirements Specification X X

A003 Software Design Description X

A004 Data Base Design Document X X

A005 Software Test Plan X

A006 Software Test Description X X

A007 Software Test Report X X

A008 Reserved

A009 Integrated Program Management Report X X

A010 Program Management Review Package X

A011 Progress Demonstrations X

A012 Deliverable End Item X X

A013 Data Accession List X

A014 Technical Report – Study/Services X

A015 Information Assurance System Security Plan (SSP) X X

A016 Information Assurance Test Products/Reports X X

A017 COTS/FOSS/GOTS Baseline X X

CONTRACT DATA REQUIREMENTS LIST

(1 Data Item)

Form Approved CMB No.0704-0188

The public reporting burden for this collection of information is estimated to average 110 hours per response, including the time for receiving instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing the burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0701-0188), 1215

Jefferson Davis highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. Please DO NOT RETURN your form to the above address. Send completed form to the Government Issuing Contraction Officer for the Contra/PR No. listed in Block E.

A. CONTRACT LINE ITEM NO. B. EXHIBIT C. CATEGORY:

0001 A TDP _________ TM ___________ OTHER _____________X_________________

D. SYSTEM / ITEM E. CONTRACT / PR NO F. CONTRACTOR

GAP CIE SUSTAINMENT FA8707-12-R-0014

1. DATAITEM NO. 2. TITLE OF DATA ITEM 3. SUBTITLE 17. PRICE GROUP

A001 Software Development Plan SDP

4. AUTHORITY (Data Acquisition Document No.) 5. CONTRACT REFERENCE 6. REQUIRING OFFICE 18. ESTIMATE

See Block 16 N/A AF LCMC-HBCC TOTAL PRICE

7. DD 250 REQ 9. DIST

STATEMENT

10. FREQUENCY 12 DATE OF FIRST SUBMISSION 14. DISTRIBUTION $

LT

REQUIRED See Block 16 See Block 16

8. APP CODE D 11. AS OF DATE 13. DATE OF SUBSEQUENT SUBMISSION a. ADDRESSEE b. COPIES

Draft

Final

N/A Date of submission

See Block 16 Reg Repro.

16. REMARKS AF LCMC-

HBCC

1 1

Block 4: Contractor format with Government approval. Content shall contain the information required in attached guidance.

AFLCMC/HBCC

(Contracting)

1 1

Block 10: One final submission 90 days after contract award. Then on an as-required basis thereafter.

Block 12: Draft submission 45 days after contract award.

Block 13: Final submission 90 days after contract award.

Block 14. Submittal in electronic format required

15. TOTAL ------> 2 2

G. PREPARED BY: H. DATE I. APPROVED BY: J. DATE

MIKE REED, Major, USAF GEORGE E. BECK, DAFC, USAF

Software Development Plan (SDP) (A001)

The Software Development Plan (SDP) describes the developer's overall plans for conducting this GAP CIE software maintenance effort. The term "software development" for this document describes efforts to maintain the

COTS/GOTS/FOSS baselines, to resolve corrective, perfective, adaptive findings, and deliver enhancements to the

GAP CIE system. The SDP should be tailored to address the range of software maintenance efforts.

The SDP provides the government insight into, and a tool for monitoring, the processes agreed to for software maintenance, including the methods to be used, the approach to be followed for each activity, and project schedules, organization, and resources.

This document contains guidance for the content of an SDP that satisfies the requirements of A001. The format used should be of the contractors choosing with approval of the government. Portions of this plan may be grouped as separate documents if this approach enhances their usability. Examples include plans for software configuration management and software quality assurance. Also, contractor corporate processes may be (re)used, appropriately tailored this contract’s software effort.

Requirements:

1. Reference documents. GAP CIE System Engineering Plan (SEP).

2. General instructions.

a. Automated techniques. Use of automated tools is encouraged. The term "document" means a collection of data regardless of its medium. If a model, data, or tools-based approach is used, the product(s) shall be capable of being reviewed by the government using USSTRATCOM-standard office automation tools (e.g., Microsoft Office, standard web browser). At a minimum, artifacts shall be delivered to the government on CD ROM.

b. Alternate presentation styles. Diagrams, tables, matrices, and other presentation styles are acceptable substitutes for text when data required can be made more readable using these styles.

c. Common Features. All documents or data sources should have a title page or identifier that provides a clear indication of document content and version number. They should have a table of contents and provide a method of uniquely identifying specific areas of the document (e.g. page numbers and section numbering).

3. Format. A contractor-defined format is acceptable provided the information contained in the delivered product meets or exceeds the information specified in this guidance.

4. Content. The SDP shall contain the following:

1. Scope.

1.1 Identification. 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. Describe the purpose of the system and the software to which this document applies.

It should describe the general nature of the system and software; expected 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. Summarize the purpose and contents of this document and describe any security or privacy considerations associated with its use.

2. Referenced documents. List the documents referenced in this plan, the version of the documents, and their sources including URL address, if available.

3. Overview of required work. Establish the context for the planning described in later sections. Include, as applicable, an overview of:

3.1. Requirements and constraints on the system and software to be developed

3.2. Requirements and constraints on project documentation

3.3. Position of the project in the system life cycle.

3.4. Requirements and constraints (internal and external) on project schedules and resources

3.5. The relationship between the software development effort and other work, such as lifecycle planning, software architecture and integration, and systems engineering support.

3.6. Other requirements and constraints, such as on project security, privacy, methods, standards, interdependencies in hardware and software development, etc.

4. Plans for performing general software development activities. If different builds or different software on the project require different planning, these differences should be noted in the applicable paragraphs. In addition to the content specified below, each paragraph should identify applicable risks/uncertainties and plans for dealing with them.

4.1 Software development process. Describe the software development process and methodologies to be used.

4.1.1 Contract Adherence. Cover the software development activities IAW the SOW and SEP.

4.1.2 Contractor’s approach. Detail the contractor’s approach to software sustainment including:

a. ,Assisting the government with requirement prioritization

b. Management of derived requirements for and from external dependent development (e.g. legacy contractors, external contractors),

c. Entry/exit criteria,

d. Planned deliverables,

e. Formal and informal reviews, and

f. Product correction and quality control processes.

4.1.3 Delivery Schedule. Provide a phased delivery schedule for existing and new system integration and system modifications that support USSTRATCOM requirements. Address how the contractor will enable easy upgrades for required post-delivery changes and technology refresh improvements supporting lifecycle management. The development plan should phase-in capabilities needed to execute USSTRATCOM mission requirements, as they are defined, to include collaboration and integration/interoperability with external systems.

The plan shall provide formal program reviews for key milestones identified in the SOW. Review processes shall provide applicable cost and performance data and shall include definitions of proposed entry/exit criteria; planned deliverables, with details provided for formal and informal reviews; and product correction and quality control processes.

Finally, describe the approach to be used to collaborate with associate contractors (ASCONs) such as other application developers (e.g. legacy contractors, external contractors), other contractors (e.g., infrastructure providers), and government systems engineers. A proposed allocation of responsibilities across the various stakeholder organizations shall be provided.

4.2 General plans for software development. The following information shall be included.

4.2.1 Software development methods. Describe or reference the software development methods to be used.

Included shall be descriptions of the manual and automated tools and procedures to be used in support of these methods. The methods shall cover all contractual clauses concerning this topic.

4.2.2 Standards for software products. Describe or reference the standards to be followed for representing requirements, design, code, test cases, test procedures, and test results. The standards shall cover all contractual clauses concerning this topic. Standards for code shall be provided for each programming language to be used.

They shall include at a minimum:

a. Standards for format (such as indentation, spacing, capitalization, and order of information)

b. Standards for header comments (requiring, for example, name/identifier of the code; version identification; modification history; purpose; requirements and design decisions implemented; notes on the processing (such as algorithms used, assumptions, constraints, limitations, and side effects); and notes on the data

(inputs, outputs, variables, data structures, etc.)

c. Standards for other comments (such as required number and content expectations)

d. Naming conventions for variables, parameters, packages, procedures, files, etc.

e. Restrictions, if any, on the use of programming language constructs or features

f. Restrictions, if any, on the complexity of code aggregates

g. Description of the contractor’s software development environment, including software engineering tools used and how these tools are integrated into a comprehensive integrated development and management environment.

Consideration should also be given as to how contractor tools and architectural artifacts will smoothly integrate with government architectures and engineering products.

4.2.3 Reusable software products. The following information shall be included.

4.2.3.1 Incorporating reusable software products. Describe the approach to be followed for identifying, evaluating, and incorporating reusable software products (e.g., COTS, GOTS, newly developed reusable code), including the scope of the search for such products and the criteria to be used for their evaluation and make-vs.-buy decisions. The description shall cover all contractual clauses concerning this topic. Candidate or selected reusable software products known at the time this plan is prepared or updated shall be identified and described, together with benefits, drawbacks, and restrictions, as applicable, associated with their use.

4.2.3.2 Developing reusable software products. Describe the approach to be followed for identifying, evaluating, and reporting opportunities for developing reusable software products.

4.2.4 Handling of critical requirements. The following information shall be included.

a. Security assurance

b. Assurance of critical requirements

4.2.5 Computer hardware resource utilization. Describe the approach to be followed for allocating computer hardware resources and monitoring their utilization. The GAP CIE computing environment in place at the time this plan is prepared and/or updated shall be used as a basis for estimating computer hardware utilization. The contractor shall identify the system boundaries outside the control of the government program office.

4.2.6 Recording rationale. Describe the approach to be followed for recording rationale that will be useful to the support agency for key decisions made on the project. The approach shall interpret the term "key decisions" for the project and state where the rationale are to be recorded.

4.2.7 Access for acquirer review. Describe the approach to be followed for providing the acquirer or its authorized representative access to developer and subcontractor facilities for review of software products and activities. The approach shall propose a process which provides the government full and timely insight, review, and approval of all software development processes and artifacts (e.g., requirements and design specifications; design, test and integration processes; etc.) at program milestones (e.g., requirements baseline establishment, preliminary and final design, test readiness, etc.).

4.2.8 Software costing.

The contractor shall describe the detailed software costing methodology, including software estimation tools and techniques used, as well as parametric values used in calculating the estimates.

4.2.9 System verification. The contractor shall describe its plan for verified production deliveries leading to operational test and evaluation of requirements and statutory compliance for each delivery. This shall include a plan to verify compliance with all contract-developed SRS requirements without detriment to the delivered performance, functional, and technical requirements stated in the TRD and in place at contract start.

4.2.10 Lifecycle support. The contractor shall describe its plan to provide logistic capability for the system within program funding constraints. This plan should identify methods to incorporate best-value solution alternatives, substantiated by cost/benefit analyses.

5. Plans for performing detailed software development activities. The discussion of each activity shall include the approach (methods, procedures, tools, etc.) to be applied to: 1) the analysis or other technical tasks involved, 2) the recording of results, and 3) the preparation of associated deliverables, if applicable. The discussion shall also identify applicable risks/uncertainties and plans for dealing with them. Reference may be made to 4.2.1 if applicable methods are described there.

In order to avoid duplication and unnecessary work, and to provide best value to the government, the contractor is encouraged to consolidate material (e.g., paragraphs 4 and 5) to provide a single comprehensive treatment of the topic here and/or among other CDRLs, as approved by the government.

5.1 Project planning and oversight. Describe the approach to be followed for project planning and oversight to include:

5.1.1 Software development planning (covering updates to this plan)

5.1.3 System test planning

5.1.4 Software installation planning

5.1.5 Software transition planning

5.1.6 Following and updating plans, including the intervals for management review

5.2 Establishing a software development environment. Describe the approach to be followed for establishing, controlling, and maintaining a software development environment to include:

5.2.1 Software engineering environment

5.2.2 Software test environment

5.2.3 Software development library

5.2.4 Software development files

5.2.5 Non-deliverable software such as build and test tools (Note: It is assumed that all software products and artifacts developed under this contract will be deliverable to the government with unlimited rights. If this is not the case (e.g., proprietary solutions), these exceptions shall be noted in this paragraph, and government approval for such obtained.)

5.3 System requirements analysis. Describe the approach to be followed for participating in system requirements analysis to include:

5.3.1 Analysis of user input

5.3.2 Operational concept

5.3.2 Conducting Development In-Process Reviews

5.3.4 System and software requirements, including any system (e.g., infrastructure, guards, etc.)

requirements deriving from the contractor’s software computing needs

5.4 System design. Describe the approach to be followed for participating in government system design activities to include the overall software architectural design and its relationship to the system design.

5.5 Software requirements analysis. Describe the approach to be followed for software requirements analysis.

5.6 Software design. Describe the approach to be followed for software design, to include:

5.6.1 Examination of existing design

5.6.2 Changes to the existing design

5.6.3 Impacts of design changes

5.7 Software implementation and unit testing. Describe the approach to be followed for software implementation and unit testing, to include:

5.7.1 Software implementation

5.7.2 Preparing for unit testing

5.7.3 Performing unit testing

5.7.4 Revision and retesting

5.7.5 Analyzing and recording unit test results

5.8 Unit integration and testing. Describe the approach to be followed for unit integration and testing, to include:

5.8.1 Preparing for unit integration and testing

5.8.2 Performing unit integration and testing

5.8.3 Revision and retesting

5.8.4 Analyzing and recording unit integration and test results

5.9 System testing. Describe the approach to be followed for participating in system testing, to include:

5.9.1 Preparing for system testing

5.9.2 Dry run of system testing

5.9.3 Performing system testing

5.9.4 Perform performance testing.

5.9.5 Revision and retesting

5.9.6 Regression Testing

5.9.7 Analyzing and recording system test results

5.10 Preparing for software delivery. Describe the approach to be followed for preparing for software delivery, to include:

5.10.1 Preparing the executable software

5.10.2 Preparing the source files and deltas from previous baseline

5.10.3 Preparing version descriptions and deltas from previous baseline

5.10.4 Preparing user manuals, configuration documents (and deltas), and videos

5.10.5 Preparing final requirements and design documents

5.10.6 Installation support for government integration contractor.

5.11 Software configuration management. Describe the approach to be followed for software configuration management.

5.11.1 Configuration identification

5.11.2 Configuration control

5.11.3 Configuration status accounting

5.11.4 Configuration audits

5.12 Corrective action. Describe the approach to be followed for corrective action, to include:

5.12.1 Problem/change reports, including items to be recorded (candidate items include: project name, originator, problem number, problem name, software element or document affected, origination date, category and priority, description, analyst assigned to the problem, date assigned, date completed, analysis time, recommended solution, impacts, problem status, approval of solution, follow-up actions, corrector, correction date, version where corrected, correction time, description of solution implemented)

5.12.2 Corrective action system

5 .13 Joint technical and management reviews. Describe the approach to be followed for joint technical and management reviews, to include:

5.13.1 Joint technical reviews (both contractor and government, and contractor, government, and other

ASCONs), including the Development IPR

5.13.2 Joint management reviews (both contractor and government, and contractor, government, and other

ASCONs), including a proposed set of reviews

5.14 Other software development activities. Describe the approach to be followed for other software development activities, to include:

5.14.1 Risk management, including known risks and risk-control strategies

5.14.2 Software management indicators, including indicators to be used

5.14.3 Security and privacy

5.14.4 Subcontractor management

5.14.5 Interface with software independent verification and validation (IV&V) agents

5.14.6 Coordination with associate developers

5.14.7 Improvement of project processes

5.14.8 Other activities not covered elsewhere in the plan

6. Schedules and activity network. The contractor shall provide government access to the program Schedule.

Details coordinated with the SDP include:

6.1. Schedule(s) identifying the activities in each major (government determined) build and showing initiation of each activity, availability of draft and final deliverables and other milestones, and completion of each activity

7. Project organization and resources. Provide insight into the project organization and resources to be applied in each build.

7.1. Project organization. Describe the organizational structure to be used on the project, including the organizations involved, their relationships to one another, and the authority and responsibility of each organization for carrying out required activities.

7.2 Project resources. Describe the resources to be applied to the project. This should include, as applicable:

7.2.1. Personnel resources, including:

1) The estimated staff-loading for the project

2) The breakdown of staff-loading numbers by responsibility (e.g., management, software engineering, software testing, software configuration management, software product evaluation, software quality assurance, etc.)

3) A breakdown of the skill levels, geographic locations, and security clearances of personnel performing each responsibility

7.2.2. Overview of developer facilities to be used, including geographic locations in which the work will be performed, facilities to be used, secure areas and other features of the facilities, as applicable to the contracted effort.

7.2.3. Acquirer-furnished equipment, software, services, documentation, data, and facilities required for the contracted effort. A schedule detailing when these items will be needed shall also be included.

7.2.4. Other required resources, including a plan for obtaining the resources, dates needed, and availability of each resource item.

Form Approved

CMB No.0704-0188

The public reporting burden for this collection of information is estimated to average 110 hours per response, including the time for receiving instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing the burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0701-0188), 1215

Jefferson Davis highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. Please DO NOT RETURN your form to the above address. Send completed form to the Government Issuing Contraction Officer for the Contra/PR No. listed in Block E.

A. CONTRACT LINE ITEM NO. B. EXHIBIT C. CATEGORY:

0001 A TDP _________ TM ___________ OTHER _____________X_________________

D. SYSTEM / ITEM E. CONTRACT / PR NO F. CONTRACTOR

GAP CIE SUSTAINMENT FA8707-12-R-0014

1. DATAITEM NO. 2. TITLE OF DATA ITEM 3. SUBTITLE 17. PRICE GROUP

A002 Software Requirements Specification SRS

4. AUTHORITY (Data Acquisition Document No.) 5. CONTRACT REFERENCE 6. REQUIRING OFFICE 18. ESTIMATE

See Block 16 SOW, para. 2.16.1 AF LCMC-HBCC TOTAL PRICE

7. DD 250 REQ 9. DIST

STATEMENT

10. FREQUENCY 12 DATE OF FIRST SUBMISSION 14. DISTRIBUTION $

LT

REQUIRED See Block 16 See Block 16 See Block 16

8. APP CODE D 11. AS OF DATE 13. DATE OF SUBSEQUENT SUBMISSION a. ADDRESSEE b. COPIES

16. REMARKS AF LCMC-

HBCC

1 1

Block 4: Contractor format with Government approval. Content shall contain the information required in attached guidance.

AF LCMC-

HBCC

Block 10: As required by the government. Not every delivery order will require an SRS breakdown. Only those requirements that need definition beyond resolving a simple error require decomposition.

Block 12: First draft SRS(s) for each delivery, due 10 days after the System

Requirements Analysis TIM.

Block 13: Note: SRS artifacts will be provided 5 days prior to any SRS Review

TIM. Final version due at GDT&E TRR .

N/A Date of submission

See Block 16 Reg Repro.

Software Requirements Specification (SRS) (A002)

This Software Requirement Specification (SRS) specifies the detailed requirements for each requirement in a delivery order. The scope of this document is limited to the changes required to satisfy the particular delivery order that generates this SRS. In the case of, and with the concurrence of the government, simple deficiency reports (DRs) are requirements and can constitute their own SRS. For enhancements or DRs that are more complex and need a detailed description and resolution, and with government concurrence, the contractor shall develop and deliver, for government review and approval, a set of detailed SRS requirements that defines the scope and solution to each requirement in a delivery order.

The SRSs shall be provided to the government in a format chosen by the contractor and approved by the government.

1. Reference documents. None.

a. Automated techniques. Use of automated techniques is encouraged. The term "document" means a collection of data regardless of its medium. If a model, data, or tools-based approach is used, the product(s) shall be capable of being reviewed by the government using USSTRATCOM-standard office automation tools (e.g., Microsoft Office, standard web browser). At a minimum, artifacts shall be delivered to the government on CD

ROM.

b. Alternate presentation styles. Diagrams, tables, matrices, and other presentation styles are acceptable substitutes for text when data required by this DID can be made more readable using these styles.

c. Common Features. All documents or data sources should have a title page or identifier that provides a clear indication of the document content and version number. They should have a table of contents and provide a method of uniquely identifying specific areas of the document (e.g. page numbers and section numbering)

3. Format. A contractor-defined format is acceptable provided the information contained in the delivered product

4. Content. The deliverable shall contain the following information:

1. Scope.

1.1 Identification. 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. Briefly state the purpose of the system and the software to which this document applies. 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. Summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.

2. Referenced documents. List the number, title, revision, and date of all documents referenced in this document.

This section shall also identify the source for all documents including URL address, if available. For instance, the document containing the government’s delivery order requirements, notes from clarification meetings or

Development In-Process Reviews, or other source material is part of this section.

3. Requirements. The developer shall divide this section into paragraphs or sections that group the delivery order and derived requirements logically. Each requirement shall be assigned a project-unique identifier to support testing and traceability and shall be stated in such a way that an objective test can be defined for it.

It is neither necessary nor desirable to repeat TRD/TDD requirements. The purpose of the SRS is to provide lower-level, detailed requirements that flow from or are derived from the government delivery order. They provide a basis for further software analysis and development, to ensure that the contractor has a sound understanding of the government’s intent for each capability, and to ensure that the government has sufficient visibility into the lower level details, in order to adequately review the proposed approach and make sound approval decisions.

Each SRS document stands alone, and augments any previously delivered SRS. At no time, without documented government approval, does a requirement in a previous SRS become superseded by a new SRS. By default, each SRS delivery is additive in nature. As a maintenance effort, the final software baseline that exists at the end of the transition period is the capabilities baseline for the maintenance effort.

The degree of detail to be provided shall be guided by the following rules:

3.1 The detailed requirement is testable.

3.2 The detailed requirements satisfy the contract requirement.

3.3 The solution satisfies other overall test cases for the requirement.

3.4 The solution defers to design descriptions those characteristics that the acquirer is willing to leave up to the developer.

3.5 System Responsiveness. The requirements specify required behavior of the software and shall include applicable parameters, such as response times, throughput times, other timing constraints, sequencing, accuracy, capacities (how much/how many), priorities, continuous operation requirements, and allowable deviations based on operating conditions.

3.6 Bounds checking. The requirements include, as applicable, required behavior under unexpected and

"out of bounds" conditions, requirements for error handling, and any provisions to be incorporated into the software to provide continuity of operations. Paragraph 3.3.x of this guidance provides a list of topics to be considered when specifying requirements regarding inputs the software must accept and outputs it must produce.

3.7 External interfaces. For external interfaces, the requirements include the specifications or references to files containing the specifications for the interface itself, its network address, the invocation of the interface, and the expected data from the interface. Potential interface errors/issues and their resolution by the software are documented. This information constitutes the expected baseline for the external interface. Example information includes:

3.7.1 System Names/identifiers

3.7.1.1 Project-unique identifier

3.7.1.2 Non-technical (natural-language) name

3.7.1.3 If applicable, DOD or USSTRATCOM standard data element name

3.7.1.4 Technical name (e.g., variable or field name in code or database)

3.7.1.5 Abbreviation or synonymous names

3.7.2 Data type (alphanumeric, integer, etc.)

3.7.3 Size and format (such as length and punctuation of a character string)

3.7.4 Units of measurement

3.7.5 Range or enumeration of possible values (such as 0-99)

3.7.6 Accuracy (how correct) and precision (number of significant digits)

3.7.7 Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply

3.7.8 Security and privacy constraints

3.7.9 Sources (setting/sending entities) and recipients (using/receiving entities)

3.8 Internal data requirements. Specify the requirements, if any, imposed on data internal to the GAP CIE

System. Included shall be requirements, if any, on databases, caches, and data files included in the GAP CIE. If all decisions about internal data are left to the design, this fact shall be so stated.

3.9 Adaptation requirements. Specify the requirements, if any, concerning installation-dependent data to be provided by the software (such as site- or network-dependent runtime environment) and operational parameters that the software is required to use that may vary according to operational need.

3.10 Security requirements. Specify the detailed requirements, if any, for maintaining existing security features in the scope of the delivery order.

3.10.1 Security policies. Specify any Information Assurance policies requiring detailed requirements that are directly related to the content of the delivery order.

3.11 Software environment requirements. Specify the detailed requirements, if any, regarding changes to the environment in which the GAP CIE software must operate. Examples include the computer hardware and operating systems on which the software must run. If infrastructure, database, runtime environment, or other environmental changes are required in order for the software to function according to specification, these shall be identified. The contractor is strongly encouraged to pre-coordinate these requirements with the government prior to formal document delivery to ensure that proposed changes are acceptable.

3.12 Software performance requirements. Specify the requirement changes, if any, on the software's performance characteristics, such as changes to the load testing profiles, the expected maximum capacity during load testing, the times measured during load testing, number of errors documented during testing, and network usage parameters experienced during testing.

3.13 Software quality factors. Specify the requirements, if any, concerned with software quality factors identified in the contract. Examples include quantitative requirements regarding software functionality (the ability to perform all required functions), reliability (the ability to perform with correct, consistent results), maintainability

(the ability to be easily corrected), availability (the ability to be accessed and operated when needed), flexibility (the ability to be easily adapted to changing requirements), portability (the ability to be easily modified for a new environment), reusability (the ability to be used in multiple applications), testability (the ability to be easily and thoroughly tested), usability (the ability to be easily learned and used), and other attributes. Quantitative requirements require the unit of measure and test methodology to be part of the SRS.

3.14 Design and implementation constraints. Specify the requirements, if any, that constrain the design and implementation of the software. These requirements are specified by reference to appropriate commercial or government standards and specifications. Examples include requirements concerning:

a. Use of a particular architecture or requirements on the architecture, such as required databases or other software units; use of standard, military, or existing components; or use of Government/acquirer-furnished property

(equipment, information, or software)

b. Use of particular design or implementation standards; use of particular data standards; use of a particular programming language, COTS, or GOTS product

c. Flexibility and expandability that must be provided to support anticipated areas of growth or changes in technology, threat, or mission

4. Qualification provisions. Define a set of qualification methods and specify, for each requirement in Section 3, the method(s) to be used to ensure that the requirement has been met. A table may be used to present this information, or each requirement in Section 3 may be annotated with the method(s) to be used. Qualification methods may include:

a. Demonstration: The operation of the software, or a part of the software that relies on observable functional operation not requiring the use of instrumentation, special test equipment, or subsequent analysis.

b. Test: The operation of the software, or a part of the software, using instrumentation or other special test equipment to collect data for later analysis.

c. Analysis: The processing of accumulated data obtained from other qualification methods. Examples are reduction, interpretation, or extrapolation of test results.

d. Inspection: The visual examination of software code, documentation, etc.

e. Special qualification methods: Any special qualification methods for the software, such as special tools, techniques, procedures, facilities, and acceptance limits.

5. Requirements traceability. Document:

a. Traceability from each detailed requirement in this specification to the delivery order requirement it addresses.

CONTRACT DATA REQUIREMENTS LIST

(1 Data Item)

Form Approved CMB No.0704-0188

The public reporting burden for this collection of information is estimated to average 110 hours per response, including the time for receiving instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing the burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0701-0188), 1215

Jefferson Davis highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. Please DO NOT RETURN your form to the above address. Send completed form to the Government Issuing Contraction Officer for the Contra/PR No. listed in Block E.

A. CONTRACT LINE ITEM NO. B. EXHIBIT C. CATEGORY:

0001 A TDP _________ TM ___________ OTHER _____________X_________________

D. SYSTEM / ITEM E. CONTRACT / PR NO F. CONTRACTOR

GAP CIE SUSTAINMENT FA8707-12-R-0014

1. DATAITEM NO. 2. TITLE OF DATA ITEM 3. SUBTITLE 17. PRICE GROUP

A003 Software Design Description SDD

4. AUTHORITY (Data Acquisition Document No.) 5. CONTRACT REFERENCE 6. REQUIRING OFFICE 18. ESTIMATE

See Block 16 SOW, para. 2.16.2 AF LCMC-HBCC TOTAL PRICE

7. DD 250 REQ 9. DIST

STATEMENT

10. FREQUENCY 12 DATE OF FIRST SUBMISSION 14. DISTRIBUTION $

LT

REQUIRED As Required See Block 16 See Block 16

8. APP CODE D 11. AS OF DATE 13. DATE OF SUBSEQUENT SUBMISSION a. ADDRESSEE b. COPIES

16. REMARKS AF LCMC-

HBCC

1 1

Block 4: Contractor format with Government approval. Content shall meet requirements of attached guidance.

AF LCMC-

HBCC

(Contracting)

1 1

Block 12: Design artifacts will be provided as part of the Development In-

Process Review Package only for major software updates 5 days prior to the

TIM.

Block 13: Updated draft SDD for each deliver, due 10 days after the TIM. Final version due at GDT&E TRR

See Block 16

N/A Reg Repro.

Software Design Description (SDD)

A003

The Software Design Description (SDD) describes the design of a software enhancement. The scope of this document is limited to the changes required to satisfy the particular delivery order that generates this SDD. It describes the design decisions, the architectural design, and the detailed design needed to implement the software.

The SDD documentation provides evidence to the acquirer that the developer understands the software solution and that the developer is ready to proceed with code changes.

The SDD shall be provided to the government in a format chosen by the contractor and approved by the

1. Reference Documents. None.

collection of data regardless of its medium. If a model, data, or tools-based approach is used, the product(s) shall be capable of being reviewed by the government using USSTRATCOM-standard office automation tools (e.g., Microsoft Office, standard web browser). At a minimum, artifacts shall be delivered to the government on CD

ROM.

b. Alternate presentation styles. Diagrams, tables, matrices, and other presentation styles are acceptable substitutes for text when data required can be made more readable using these styles.

c. Common Features. All documents or data sources should have a title page or identifier that provides a clear indication of document content and version number. They should have a table of contents and provide a method of uniquely identifying specific areas of the document (e.g. page numbers and section numbering).

3. Format. A contractor-defined format is acceptable provided the information contained in the delivered product

4. Content. The SSD shall contain the following:

4.1 Identification. 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).

4.2 System overview. Describe the purpose of the system and the software to which this document applies.

It should 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.

4.3 Document overview. Summarize the purpose and contents of this document and describe any security or privacy considerations associated with its use.

5. Referenced documents. List the number, title, revision, and date of all documents referenced in this document.

This section shall also identify the source for all documents including URL address, if available.

6. Software design decisions. This section shall highlight any derived requirements where the sum of the requirements equals the system capability as required in the delivery order to enable government understanding of design decisions. This section shall be divided into paragraphs as needed to present system-wide design decisions, that is, decisions about the software's behavioral design (how it will behave, from a user's point of view, in meeting its requirements, ignoring internal implementation). This section is expected in final form for preliminary design review events and beyond. Examples of system-wide design decisions are the following:

a. Design decisions regarding inputs the GAP CIE system will accept and outputs it will produce, including interfaces with other systems, web services, and data files.

b. Design decisions on system behavior in response to each input or condition, including actions the system will perform, including response times, other performance characteristics, and handling of unallowed inputs or conditions.

c. Design decisions on how data will appear to the user.

d. Other system-wide design decisions made in response to requirements, such as selected approach to providing required flexibility, availability, and maintainability.

e. Other COTS/GOTS design decisions made in response to requirements identified in the SDD and SRS.

This section shall include references to the system design as applicable. The system design must include the following and should be centralized for reference in the SDD:

a. Identify the components of the software system (subsystems, software units, etc., depending on the architecture views selected). Each component shall be assigned a project-unique identifier or name and shall include developed software and other system components (e.g., GOTS and other applications).

b. Show the static (such as “consists of”) relationship(s) of the components. Multiple relationships may be presented, depending on the selected design methodology (for example, in an object-oriented design, this paragraph may present the class and object structures as well as the module and process architectures).

c. State the purpose of each component and identify the system requirements and system-wide design decisions allocated to it.

d. Describe, in detail, the contractor’s proposed integration strategy, to include: overall approach (e.g., middleware, database-oriented, etc.); integration components (COTS, developed code, adaptation requirements); implications for other system components (other system components, browsers, infrastructure, etc.); expected lifecycle costs and supportability issues; and organizational relationships necessary to implement the approach (e.g., Service Level Agreements). Identify design issues and tradeoffs, along with rationale for the proposed approach.

e. DoDAF 2.0 views as appropriate or requested by the acquirer.

7. Software architectural design. This section shall be divided into the following paragraphs to describe the GAP

CIE system architectural design changes. If design information falls into more than one paragraph, it may be presented once and referenced from the other paragraphs. This section is expected in draft form for preliminary design review events and final for detailed design review events and beyond.

a. Identify the software units that make up the relevant architecture component. Each software unit shall be assigned a project-unique identifier or name.

b. Show the static (such as "consists of") relationship(s) of the software units. Multiple relationships may be presented, depending on the selected software design methodology (for example, in an object-oriented design, this paragraph may present the class and object structures as well as the module and process architectures).

c. State the purpose of each software unit as-is and changes required.

d. Characterize each software unit's development changes required (such as new code, existing design or software to be reused as is, existing design or software to be reengineered, software to be developed for reuse, etc.)

e. Describe how the changes the proposed will impact the utilization of computer hardware resources (such as processor capacity, memory capacity, input/output device capacity, auxiliary storage capacity, and communications/network equipment capacity).

7.2 Concept of execution. This paragraph shall describe the concept of execution among the software units. It shall include diagrams and descriptions showing the dynamic relationship of the software units, that is, how they will interact during software operation, including, as applicable, flow of execution control, data flow, exception handling, concurrent execution, alternate site impacts, behavior under high system load, and other aspects of dynamic behavior.

7.3 Interface design. This paragraph shall be divided into the following subparagraphs to describe the interface characteristics of the software units. It shall include changes to interfaces among the software units and their interfaces with external entities such as systems, services, and data files, including newly consumed data down to the field level. References to consumed data shall be consistent with interface documentation captured in the SRS.

This section shall include details or new or changed data sources, including

Characteristics of individual data elements that the interfacing entity(ies) will provide, store, send, access, receive, etc., such as:

1) Names/identifiers

a) Project-unique identifier or name

b) Non-technical (natural-language) name

2) Data type (alphanumeric, integer, etc.)

3) Size and format (such as length and punctuation of a character string)

4) Units of measurement (such as meters, dollars, nanoseconds)

5) Range or enumeration of possible values (such as 0-99)

6) Accuracy (how correct) and precision (number of significant digits)

7) Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply

9) Sources (setting/sending entities) and recipients (using/receiving entities)

10) Message formatting

11) Protocols used

12) Flow control (such as sequence numbering)

13) Safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing

7.4 COTS/GOTS design requirements. The software design shall be compatible with existing COTS/GOTS products to be used as part of this program. All COTS/GOTS products or changes required for this design shall be listed and identified. The appropriate reference documents shall be added to section 2 of this SDD and reference here by document, section, and page number.

7.5 DoD design requirements. The software design shall comply with DoD directives concerning software design (i.e. JC2 Architecture documents). The appropriate reference documents shall be added to section 2 of this

SDD and reference here by document, section, paragraph, page number, signing authority, and date.

8. Software detailed design. This section shall be divided into the following paragraphs to describe each software unit of the GAP CIE System. If design information falls into more than one paragraph, it may be presented once and referenced from the other paragraphs. This section is expected in draft form for detailed design review events and final by the end of CDT&E.

8.1 (Project-unique identifier of a software unit, or designator of a group of software units). This paragraph shall identify a software unit by project-unique identifier and shall describe the unit. The description shall include the following information, as applicable. Software units that contain other software units may reference the descriptions of those units rather than repeating information.

a. Unit design decisions, if any.

b. Any constraints, limitations, or unusual features in the design of the software unit

c.