JMR_TD_MSAD_Capstone_BAA_SSoT_FINAL.docx

Single Source of Truth (SSoT) Study Provider Call For the Joint Multi-Role Technology Demonstrator (JMR TD) Mission Systems Architecture Demonstration (MSAD) Capstone Demonstration Overarching Broad Agency Announcement (BAA)

Prepared by the US Army Aviation Development Directorate (ADD) to supplement the information contained in the JMR TD MSAD Capstone Demonstration Overarching Broad Agency Announcement (BAA) Table 1: Document Update Record Change Log

1. Initial Release

Table 2: Referenced Documents

Document Name

Table of Contents

Table of Figures Figure 1. Authoritative Source of Truth Concept 6

1. Introduction This Call, W911W6-19-R-0013, is issued under Broad Agency Announcement (BAA) Number W911W6-18-R-0006, the MSAD Capstone Demonstration, referred to in this Call as the Overarching BAA. This Call solicits proposals for the SSoT Study Provider Role for the MSAD Capstone S&T Program, and provides the SSoT Study Provider Role specific requirements within the overall program objectives, as well as the instructions, and conditions outlined in the Overarching BAA. Sections in this Call supplement the Overarching BAA. Offerors are advised to review the Overarching BAA to provide context to the technical details within this Call.

SSoT Study Provider Detailed Discussion Overview of the SSoT Study Provider Role The SSoT Study and Demonstration is an effort conducted in parallel with the JMR TD MSAD Capstone Demonstration. An SSoT is expected to be an important enabler in future procurements.

The term “Single Source of Truth” originated in the database community as a schema design methodology: each data element (e.g. telephone number) should be stored in a single place and referenced everywhere used to ensure data consistency and facilitate change management. The term has subsequently been adopted for Model Based Development (MBD) to achieve similar outcomes. However, models (and their meta-models) are not the same as databases, and the activities associated with development and evolution of models resembles those of software development more so than documenting database schemas. Additionally, to achieve the Government’s vision, an SSoT will be much more than a repository of information.

The term SSoT is, in many ways, synonymous with the Authoritative Source of Truth (ASoT) concept described in the Department of Defense Digital Engineering Strategy released by the Office of the Deputy Assistant Secretary of Defense for Systems Engineering in June 2018. For alignment to that strategy, the term ASoT is used in this Call from this point forward. The desire for an authoritative source of primarily digital information is the impetus for tooling and automation that enables discovery, management, analysis, use, and distribution of information to stakeholders across the life cycle of a product. The figure below describes how the ASoT is a centralized source of information supported by potentially many different domain areas of expertise. The ASoT is interconnected, and provides stakeholders a perspective on system information relevant to their informational needs as well as supporting tools and data to assist in obtaining information and performing decision-making.

Figure 1. Authoritative Source of Truth Concept A focus area of the Capstone Demonstration is investigating the interconnectedness and integration of model content as well as methods for describing information in a model-based environment. The significance of this focus is the continuing shift in both Government policy and execution away from what has traditionally been a document-centric process, and toward a connected set of related information represented in models and other digital artifacts. This shift does not necessarily imply the desire for a single database or a single repository of all product lifecycle information. The activities of this Call will expand the perspective beyond individual artifacts, models and their content towards the higher order ASoT. The ASoT represents the current state of the technical baseline of a product that serves as the central reference for models and data across the lifecycle of a product or system. A larger framework provides context, guidance and supporting processes, tooling, and meta-data within the ASoT and supports the technical content, providing stakeholders relevant, accurate, and timely information.

Objectives This task has three primary phases. The first defines the scope and boundary of an ASoT. It defines the types of information that support desired engineering and acquisition decisions as well as the features an ASoT provides to support those activities. This phase also defines the governance processes necessary to ensure proper use and management of the ASoT to include how tools are tracked and how changes to managed content can be discovered and analyzed as updates are received. The second phase is a demonstration of the current state of technology in providing the features and satisfying the requirements within the context of defined scope identified in Phase 1. Phase 2 shall be proposed as an optional task. Phase 2 should assess the gaps between the scope of Phase 1 and currently available tools, processes, and technology. Phase 3 summarizes and reports the findings of Phase 1 (and Phase 2 if awarded).

Requirements The ASoT exists to provide the necessary information to the appropriate stakeholder in the appropriate context throughout the lifecycle of a particular product. The ASoT provides for the management, discovery, use, and analysis features in a robust and mature environment that is secure and accessible. Because it is anticipated that the ASoT will constitute a high-value cybersecurity target for adversaries, the Study Provider will address security requirements and measures.

ASoT User Stories The following section provides context for subsequent investigation activities, and serves as context for Study Provider requirements.

1. The Government wants a network-based, authoritative source of digital information across the lifecycle of a product enabling discovery, management, and use of managed information supported by a high degree of tooling and automation that is secure and accessible.

a. The Government wants the ASoT to be the primary means of exchanging models, data, and other digital artifacts in order to support planning, development and sustainment activities within the engineering and acquisition communities.

b. The Government wants the ASoT to represent the current state and history of a product’s technical baseline.

c. The Government wants content within the ASoT to be discoverable, traceable, integrated, and authoritative.

d. The Government wants to formally manage content within the ASoT as well as be able to assess the level of trust allocated to managed content.

2. The Government wants only authorized users to access managed content, which includes data that may have different levels of access authorization.

a. The Government wants authorized stakeholders (Government and multiple simultaneous industry) to be able to collaborate on managed ASoT content.

b. The Government wants to protect managed content that contains intellectual property and/or controlled unclassified information (CUI).

c. The Government wants to be able to manage and protect classified ASoT content, while maintaining necessary links to related unclassified information.

3. The Government wants ASoT tools capable of being hosted on a Government network, or in a commercially provided Government Cloud Computing enclave.

4. The Government wants to understand the type of information that will be necessary to enable the discovery, management, and use of managed information.

a. The Government wants the ASoT to support technical reviews of managed content representing stakeholder-centric views and perspectives.

b. The Government wants the ASoT to support stakeholder-centric analysis of managed content using context sensitive tools enabling decision making and engineering activities.

5. The Government wants a “model of models” approach that includes a method of accommodating different tools and model formats to include those tailored or customized for specific purposes.

6. The Government wants the ability to translate model-based content from one tool format to another.

7. The Government wants managed content to be consistent throughout the ASoT. Consistency requires that dependencies within the ASoT be identifiable and analyzable throughout the lifecycle.

8. The Government wants to identify and resolve inconsistencies pertaining to semantics (definition, units, etc.) across the ASoT using automation and transformations.

9. The Government wants to automate the process of model updates so that changes in one model based on values of properties will be traceable to all other models that depend on this variable. From this traceability of use of variables, it should be possible to re- execute analyses in other models using this new value to determine the effect of the change across managed content.

10. The Government wants a controlling authority to identify and manage change across the ASoT.

11. The Government wants adequate availability and continuity of operations (COOP) for managed content. COOP includes backup, recovery, allowable downtime, and other such related support requirements.

12. The Government wants to be able to recompete the source of ASoT services. Activities supporting a recompete of the ASoT include moving managed content from one environment to another, and assessing ASoT performance and support requirements (i.e. bandwidth, storage, maintenance, information assurance, backup etc) for programs of multiple complexities and sizes.

Technical General The Study Provider shall provide subject matter expertise to the Government pertaining to the capabilities, development, and use of an ASoT that addresses a network-based, authoritative source of product digital information across the lifecycle of a product, enabling discovery, management, and use of managed information supported by a high degree of tooling and automation that is secure and accessible.

The Study Provider shall perform engineering services investigating and describing the scope, requirements, and management/governance aspects associated with an ASoT and its repository as described in the ASoT user stories.

The Study Provider shall perform a demonstration to characterize the current state of tooling and technology capable of satisfying the identified requirements and aspects, and document the results of the demonstration.

Phase 1: ASoT Study Phase 1 defines the scope and boundary of an ASoT. It defines the types of information that support desired engineering and acquisition decisions as well as the features an ASoT provides to support those activities. This phase also defines the governance processes necessary to ensure proper use and management of the ASoT to include how tools are tracked and how changes to managed content can be discovered and analyzed as updates are received.

The Study Provider shall develop an overarching approach to implementing a Government ASoT that addresses, at a minimum, the necessary processes, types of tools, and expertise. The Study Provider shall collaborate with the Government to develop, as part of the overarching approach, a set of use cases and activity diagrams describing the Government’s implementation and use of an ASoT addressing product lifecycle engineering and acquisition activities.

The Study Provider shall investigate and document ASoT requirements that support identified user stories, and at a minimum address:

user access controls and notifications (with or without a Common Access Card (CAC)) content management and configuration content confidentiality, integrity, and availability traceability, consistency, exchange, and interoperability of managed content protection of intellectual property and controlled unclassified information content archive and retrieval tooling integration and support (client and server based) user collaboration and information exchange of different formats of managed content (e.g. schedules, documents, models, etc.)

content format translation content auditing, metadata, queries and the ability to search through multiple information formats ASoT process and content governance Stakeholder-centric content analysis and metric reporting The Study Provider shall perform a trade study investigating commercially available tools, environments, standards, processes, and best practices, capable of supporting identified requirements, and assess the respective technical maturity and applicability to the overarching approach.

The trade study shall identify gaps between commercially available solutions and the overarching approach, and provide implementation recommendations to address identified gaps.

The Study Provider shall develop a tool-independent ASoT specification that addresses the overarching approach and incorporates the results of the trade study and demonstration.

Phase 2: ASoT Demonstration (Option) Phase 2 is a demonstration of the current state of technology in providing the features and satisfying the requirements within the context of defined scope identified in Phase 1. Phase 2 should assess the gaps between the scope of Phase 1 and currently available tools, processes, and technology. Phase 2 shall be proposed as an option.

The Study Provider shall perform a demonstration that implements a representative ASoT as described in the overarching approach.

The Study Provider shall develop a demonstration plan that describes the scope, approach, and objectives of the demonstration.

The demonstration plan shall include a selection of tooling, processes, and best practices recommended within the trade study and implement as many of the ASoT requirements as feasible within resources and schedule.

The Study Provider shall procure the tooling necessary to implement the demonstration plan.

Phase 3: Findings/Lessons/Best Practices Phase 3 summarizes and reports the findings of Phase 1 and Phase 2.

The Study Provider shall provide a final report outlining the findings, recommendations, and analysis pertaining to the definition and use of an ASoT.

The final report shall document key processes, tools and experience necessary to establish an ASoT, and describe the recommended environment and structure capable of supporting developed use cases and requirements.

Programmatic Management The Study Provider shall develop an integrated master schedule (IMS) to level 3 based upon the Government schedule provided as GFI that identifies, at a minimum, phases, durations, dependencies, and key IPRs.

The Study Provider shall perform a kick-off meeting within 20 days of contract award.

With exception of the information required to support the kick-off meeting, the Study Provider shall submit all required artifacts 14 days prior to a specified review/milestone. Kick-off meeting artifacts shall be submitted immediately prior to the meeting.

The Study Provider shall provide bi-monthly Technical Status Reports (TSR) detailing technical progress.

TSRs shall describe work performed to date, by task, compared to the work plan, including schedule status; and report on all problems, technical issues or major developments during the reporting period.

TSRs shall provide a brief summary of results and findings and an assessment of all data, findings, lessons learned, and conclusions as a result of each subtask effort as well as plans for the next reporting period.

The Study Provider shall provide bi-monthly Cost Status Reports (CSR) detailing cost, schedule, and staffing.

CSRs shall contain a description of schedule, status of deliverables, funding levels (planned vs actual), and staffing progress (hiring status, number of full time equivalents, and hours expended (planned vs actual)).

CSRs shall include a comparison of task progress to the plan, an explanation of any variance exceeding 10%, and an overview of progress as well as funding levels and variances.

Program Data Repository The Study Provider shall establish a repository of program information that protects intellectual property (IP) and reports cyber incidents in compliance with DFARS 252.204-7012/NIST SP 800.171 for all Covered Defense Information (CDI).

The Study Provider shall use the Government collaboration service (Office 365 environment), to distribute information and collaborate with Government Participants.

Meetings/Travel The Study provider shall identify necessary IPRs and other expected meetings.

Funding Level, Performance Period, and Order of Precedence.

Any award made from this call will be subject to availability of funds. The Government plans to incrementally fund efforts starting in FY 19 with additional funding being provided in FY 20.

The Period of Performance for the Call is expected to begin in 4QFY19 and continue to the end of 1QFY21.

Any inconsistency in this Call and the Overarching BAA shall be resolved by giving precedence to the language stated in this Call.

Funding Instrument See section 4 of the Overarching BAA.

Security Requirements See section 5 of the Overarching BAA.

Government Furnished Data / Equipment / Information The Government does not anticipate the need for any GFI for this Call. However, if the Offeror deems such information necessary, it shall be identified in the Call response.

Instructions to Offerors General The following sections identify the volumes and their contents that will contain the information presented in the Offeror’s response. They are listed in order of importance.

PROPOSAL VOLUME I – Technical Approach:

Consistent with section 8.2 of the Overarching BAA, the Technical Volume is composed of a textual description of the Offeror’s approach. The page count of the textual description will be limited to 40 pages inclusive of the Data Rights Sub-Factor. The Government will assess the Offeror's technical approach for satisfying the following items, which are listed in order of precedence:

1. The Offeror shall describe the approach to accomplishing Phase 1 of this Call, and specifically address:

a. a vision and approach to achieving the Government’s user stories in a network-based, collaborative environment that spans the lifecycle of a product.

b. The approach to describing and documenting the scope (use cases and requirements) of the ASoT

c. The approach to enabling discovery of managed content

d. The approach to providing suitable confidentiality, integrity and availability of managed content

e. The approach to management and governance of the ASoT and managed content

2. The Offeror shall describe the approach to accomplishing the Phase 2 Option of this Call, and specifically address the approach to performing a relevant and representative demonstration that includes managed content, tooling, and processes in the context of Phase 1.

3. The Offeror may describe the approach to any other item that is relevant to the Objectives of this Call to include needed GFI.

PROPOSAL VOLUME I Sub-Factor – Data Rights With the exception noted in the following paragraph, the Government desires, “Unlimited Rights”, but requires at a minimum, "Government Purpose Rights" (GPR) as defined by DFARS Part 227, to all technical data, deliverables, and computer software developed under this Call, with no limitations on the use of delivered and/or residual software, exempting background data assertions. Background data and software (possessing less than GPR data rights) shall not be coupled to data, deliverables, or software developed under this Call.

It is the Offeror's responsibility to clearly define in the proposal, the proposed data rights for technical data, computer software and each deliverable. Ambiguities will be negatively evaluated against the Offeror. Approaches that make use of background data should be carefully considered given the Government’s intent, and should provide a method to allow continued use in subsequent Government activities (to include use by Government contractors), or support a clear and achievable path to alternative processes and tools. The Government will assess the Offeror’s approach to Data Rights as they pertain to the following items, which are listed in order of precedence:

1. The Offeror shall describe the approach to providing the Government with required GPR or greater data rights for all technical data, deliverables, and computer software developed under this Call.

2. The Offeror shall describe, when appropriate, the approach to ensuring that tools and processes proposed with Limited Rights are not coupled to required deliverables possessing GPR or greater data rights (with the possible exception of software deliverables).

3. The Offeror shall describe, when appropriate, the approach to allowing the Government (and Government contractors) the continued use of tools and processes possessing Limited Rights during subsequent Government efforts.

4. The Offeror shall describe any software to which it will assert Restricted Rights or commercial license rights, and how it will facilitate licensing for this software to support the BAA objectives. In addition, the Offeror will include copies of any commercial software licenses/end user licensing agreements (EULAs) that will require the Government to agree to either with the Offeror or one of its suppliers.

PROPOSAL VOLUME II - Technical Experience and Qualifications Consistent with the instructions and page count indicated in section 8.3 of the Overarching BAA, the Government will assess the Offeror's experience and qualifications as they pertain to the following items, which are listed in order or precedence:

1. The Offeror shall describe previous experience with providing/developing ASoT capability.

2. The Offeror shall describe previous experience with Product Lifecycle Management (PLM) tools and processes.

3. The Offeror shall describe previous experience with data format translation and interoperability.

4. The Offeror shall describe previous experience with the identification and use of metadata, metrics, and other indicators useful to ASoT stakeholders in the discovery, use and management of managed content.

5. The Offeror shall describe previous experience with model-based processes and tooling supporting the exchange and management of model-based information.

6. The Offeror shall identify key personnel.

7. The Offeror shall describe the suitability (experience, qualifications and availability) of identified key personnel performing the proposed work. Biographies shall be provided for key personnel.

8. The Offeror shall describe the suitability and availability of the work environment (facilities, processes, tooling, etc.) supporting the proposed work.

PROPOSAL VOLUME III - Cost Consistent with section 8.4 of the Overarching BAA, the Government will assess the Offeror's cost approach as they pertain to the following items, which are listed in order of precedence:

1. The Offeror shall include specific details that demonstrate the Offeror's understanding of proposed costs.

2. The Offeror shall indicate the proposed funding instrument (e.g., TIA, FAR-based contract, OT, etc.). Any proposed cost share will be accepted and valued based on 32 CFR 37.530 through 37.555 for Non-FAR-Based instruments and FAR 42.707 and FAR 16.303 for FAR-Based instruments.

3. The Offeror shall include a funding profile by Government Fiscal Year, a cost breakout by month, a cost breakdown providing man-hours and monthly costs by task, all pricing rates used, travel and equipment and materials listings, if applicable. Details for the Phase 1 and Phase 3 efforts shall be severable from the Phase 2 Option.

4. The Offeror shall ensure that all subcontracted work is appropriately identified as such and that cost proposals by each subcontractor/sub recipient are included in the proposal or that the subcontractor submits a detailed proposal concurrent to the Government with the Offeror’s submission. In addition, the Offeror shall provide a summary of the price or cost analysis performed on each subcontracting proposal.

5. The Offeror shall provide sufficient details to demonstrate the cost reasonableness and realism of the proposed cost approach. Such details will include the basis for estimating proposed costs, and sufficiently explain estimating processes, methods, factors as well as any assumptions or contingencies used in the proposed cost estimates. The cost approach should complement and support the technical approach.

PAGE LIMITATIONS

The limitations set forth in section 7.2 of this call and section 8 of the Overarching BAA for all other volumes, will be applied. Evaluators will not evaluate any content in pages beyond the page limit.

Evaluation Criteria / Basis for Award Consistent with section 9 of the Overarching BAA, the Evaluation Factors identified in the sections below are listed in order of evaluation precedence (most important to least important).

Proposal Submission Instructions Technical and cost proposals shall be provided in electronic format. The cost proposal shall be provided in the offeror’s format as well as Excel format for cost verification purposes. Proposals shall be submitted via AMRDEC Safe Access File Exchange (SAFE): https://safe.amrdec.army.mil/safe/ to Robert.c.waible.civ@mail.mil. Proposals shall be received no later than 24 June 2019; 4:00pm eastern time.

Questions may be submitted in writing via email to Rob Waible, robert.c.waible.civ@mail.mil. All questions must be submitted no later than 14 days prior to the call closing date to ensure a response. All substantive questions and responses received which can be answered without revealing sensitive information will be posted to FedBizOpps as an amendment to the call. Proposals received after the date and time specified for closing will be handled in accordance with the Overarching BAA.

Evaluation Factor I - Technical Approach Consistent with section 9.1 of the Overarching BAA, the Government will assess the Offeror's response to the items, identified in section 7.2 of this Call. The Government will evaluate the Offeror’s response against the following considerations:

1. Sufficiency of the proposed effort to satisfy Call requirements in a manner supporting the Capstone Outcomes identified in sections 2.4 (items 9 and 18), and SSoT Study Provider role identified in section 2.8.9.5 of the Overarching BAA. Sufficiency is the extent to which the proposed effort has merit, and is innovative, efficient, and effective.

2. Likelihood of the Offeror to accomplish the proposed effort. Likelihood is the risk associated with the proposed technical approach as it pertains to supporting the Capstone Outcomes identified in sections 2.4 (items 9 and 18), and SSoT Study Provider role identified in section 2.8.9.5 of the Overarching BAA.

3. Sufficiency of the Offeror’s approach to providing data rights. Sufficiency is the extent to which the Offeror’s approach supports the Government’s intent captured in section 2.5 of the Overarching BAA and provides the Government with the opportunity to continue the use of any processes and tools possessing limited data rights.

4. Capability of the Offeror’s approach to data rights to support the proposed technical approach.

5. Likelihood of the Offeror’s approach to data rights to satisfy the Government’s requirements. Likelihood is the risk associated with the proposed approach.

Evaluation Factor II - Technical Experience and Qualifications Consistent with section 9.2 of the Overarching BAA, the Government will assess the Offeror's response to the items, identified in section 7.3 of this Call. The Government will evaluate the Offeror’s described experience and qualification in the context of time (within the last 5 years) and relevance (directly pertaining to an aviation or similar domain) for the following considerations:

1. Relevance of the Offeror’s experience. Relevance is the degree to which the Offeror’s experience and qualifications are directly related to and supportive of the Government’s requirements.

2. Amount of the Offeror’s experience. Amount is the quantity and timeliness of the Offeror’s experience and qualifications with an emphasis on that gained in the last 5 years.

3. Suitability of key personnel. Suitability is the degree to which identified personnel have the requisite relevance and amount of experience and qualifications to have a key role in the proposed tasks.

4. Capability of the Offeror’s experience, key personnel and facilities to support the proposed technical approach.

5. Likelihood of the Offeror’s experience and qualifications to satisfy the Government’s requirements. Likelihood is the risk associated with the proposed approach.

Evaluation Factor III - Cost to the Government Consistent with section 9.3 of the Overarching BAA, the Government will assess the Offeror's response to the considerations identified in section 7.4 of this Call. The Government will evaluate the Offeror’s response for the following considerations:

1. Overall value of the proposed effort. Value is the degree to which the effort is affordable and incorporates the appropriate use of cost sharing and data rights.

2. Reasonableness and Realism of the Offeror’s proposed cost to the Government. Reasonableness is the degree to which the cost may be too high, whereas Realism is the degree to which the cost may be too low, and includes the assessment of the cost elements (labor hours, labor categories/mix, subcontracts, travel, materials, and any other direct costs), and any proposed cost share.

3. Capability of the Offeror’s cost approach to support the proposed technical approach.

4. Likelihood of the Offeror’s cost approach to satisfy the Government’s requirements. Likelihood is the risk associated with the proposed approach.

Data Items / Deliverables Deliverables for this Call are identified in the table below. With the exception of models, all deliverables are permitted to be provided in contractor format. Models shall be delivered in .eap. As long as the output delivered to the Government can be natively imported by Sparx Enterprise Architect v13, Offerors/Participants may use any tool they desire to create the content. The Government will use delivered model content “As-Is”. Responsibility for ensuring that the deliverable can be consumed by the Government toolset in a manner that accurately depicts the content belongs to the Offeror/Participant.

Table 2 – SSoT Study Provider Deliverables

2.3.2.2.4

Model-based content for describing the specification may be used

Note: Document ID is provided as a reference. Contractor format is allowable.

image1.png