Long Term Mine Reconnaissance System [LMRS]

3.2 Briefings, Reviews and Technical Focus Meetings.

This Statement of Performance and Results (SPR) defines the effort required to develop a detailed design for the Long-Term Mine Reconnaissance System (LMRS). The objective of this phase will be to validate the key design and performance features of the LMRS and subsystems, and to produce specifications and plans for the follow-on Development phase of the program. In parallel with the design activities, the contractor shall also develop a concept of operations that defines how the system will be operated and supported. This SPR includes systems engineering, prototype demonstration of LMRS subsystems, and program management tasks to achieve these objectives. The contractor's technical documentation, program plans, and any test results that demonstrate a balanced set of life cycle Reliability, Maintainability & Availability (RM&A), affordability, and technical performance requirements within a manufacturable system, will validate successful achievement of the detailed design phase objectives and will complete the efforts tasked in this SPR.

Clandestine mine reconnaissance has been identified as the Navy's number one Unmanned Undersea Vehicle (UUV) priority in the Navy's UUV Program Plan of April 1994 (Updated May 1995). The Long-Term Mine Reconnaissance System (LMRS) is a new acquisition program that is intended to provide a long-term solution to this requirement.

a. The LMRS will employ a UUV system that is capable of launch and recovery from SSN688/688I and NSSN class submarines. The LMRS will provide an early, rapid, and accurate clandestine mine reconnaissance capability. It will provide the means for surveying potential mine fields in support of proposed amphibious operations, other battle group operations, and for safe ship transit around mined waters.

b. The preliminary design of the LMRS included trade studies, requirements allocation, system engineering, and system and subsystem design efforts, which led to a fully integrated functional system design. The design efforts were documented in a System Engineering Design Data Package (SEDDP) as part of the Electronic Data Base utilized during the preliminary design phase.

c. The detailed design will build on the preliminary design and will include development and demonstration of prototyping necessary for risk mitigation of critical subsystems. In addition to the prototyping demonstrations, the status of the design will be provided at an interim Critical Design Brief (CDB) and will culminate in a final Critical Design Review (CDR) to determine the readiness and risks associated with proceeding with system development. After completion of the Detailed Design Phase, the Government intends to conduct a competition limited to the detailed design contractor(s) to select a single source for the fabrication, test and evaluation of the LMRS prototype.

d. This contract will incorporate several acquisition reform initiatives, including the use of a performance specification with a minimum of military standards and specifications, and greater reliance upon industry standards and established contractor in-house practices. These initiatives also stress the use of Commercial Off-The-Shelf/Non-Development Items (COTS/NDI) which provide cost effective approaches, and the use of an Integrated Process and Product and Development (IPPD) management approach to facilitate a more cost effective and efficient acquisition process.

The following directives as cited and as tailored in this SPR are identified below. When specific paragraphs of these documents are referenced in the SPR, the reference shall be inclusive of all subparagraphs to that paragraph, unless otherwise specified.

The following military handbooks, DOD and Navy regulations, and other documents cited in this SPR shall be used for guidance and information.

The contractor's efforts must result in a system design and a set of deliverables that allow the program to transition smoothly into the Development phase. Concurrent engineering will play a critical role in ensuring that the program's goals are achieved in an effective manner. A balanced life-cycle set of LMRS products and processes will only be achieved by continuous and simultaneous consideration of the system's processes (e.g. development, manufacturing, verification, operations, training, logistics, support, and disposal). During this phase, the contractor shall demonstrate that his design and development approach considers all of these functions. This will include limited prototype development and demonstration of subsystems to ensure risk has been reduced to a manageable level for both operational and technical performance issues.

As part of an Electronic Information System (EIS) the contractor shall maintain current the Electronic Data Base utilized in the Preliminary Design Phase. The EIS shall document all unclassified aspects of the program, including the system design, the contractor's system engineering efforts, and the contractor's program management effort. Any classified information shall be submitted via mail in paper form. The contractor shall maintain this EIS in an accurate and timely fashion, updating it with all pertinent changes on a real-time basis. The EIS shall be accessible by the Government in near real-time. Monthly updates shall be provided to the government via CD ROM.

System engineering efforts are grouped into System Design and Technical Specialty subsections. The contractor's system engineering efforts shall fully address both of these equally important aspects of the development program.

The contractor shall present the configuration and status of the detailed design, and the status of the contract to the Government in three ways: (1) through Design Briefings and Reviews, (2) through a Electronic Information System (EIS) and (3) prototype demonstration.

(CDRL B001: Electronic Information System / General Program Documentation)

The contractor shall implement a system engineering design process to develop a detailed system design that meets the requirements of the LMRS System "A" Performance Specification. The contractor's system engineering process shall transform the requirements stipulated in the LMRS Performance "A" Specification and the contractor’s derived requirements from the Preliminary Design Phase (PDP) into a detailed design. The contractor shall generate and maintain a requirement’s verification and decision matrix to provide an audit trail from requirements of the LMRS System Performance "A" Specification to design implementation and verification.

(CDRL B001: Electronic Information System / Requirements Verification Matrix)

Software development shall be an integral part of the system engineering effort and the plan to accomplish this shall be developed and maintained by the contractor in the EIS during the detailed design phase. This plan shall identify how the contractor plans to tailor the approaches articulated in Mil-Std 498 (Software Development and Documentation) and meet the requirements of the LMRS Performance "A" Specification and the guidance of ASD (C3I) memo of 29 Apr 97 and Ser 03/97-0171 of 4 Jun 97. The programming language selection should be made in the context of the system and software engineering factors that influence overall life-cycle costs, risks, and potential for interoperability.

(CDRL B001: Electronic Information System / Software Development Plan)

The contractor shall develop detailed designs that build upon the Allocated Baseline (ABL) established during the Preliminary Design Phase and result in the Product Baseline (PBL) of the LMRS. The contractor shall describe this design in product orientated design documents that allow for the manufacture and maintenance of the LMRS. These documents shall be placed on the EIS . The contractor shall identify any GFE items that are proposed as part of the design baselines. The contractor shall conduct this task utilizing the system engineering design process specified in paragraph 3.1.

(CDRL B001: Electronic Information System / Design Documents)

The contractor shall establish and implement a Product Integrity (PI) process to ensure the LMRS design is producible, safe, reliable, maintainable, supportable, and cost-effective.

The contractor shall establish a Quality Assurance (QA) process utilizing the guidance of ISO 9000 to assure the required QA elements for hardware and software are identified and developed into the design and development of the LMRS.

The contractor shall establish effective integration of logistic engineering to assure the required support structure elements are identified and implemented into the design and development of the LMRS.

(CDRL B001: Electronic Information System / Logistic Support Analysis)

The contractor shall develop, update, and maintain in the EIS an approach to identify the planning and implementation necessary to ensure that the LMRS is producible.

(CDRL B001: Electronic Information System / Producibility)

The contractor shall develop, update, and maintain in the EIS an approach to identify the planning and implementation necessary to ensure and validate the achievement of the reliability, availability, maintainability and testability requirements specified in the LMRS Performance "A" Specification prior to the end of the Development Phase.

(CDRL B001: Electronic Information System / RAM-T Approach)

By tailoring Mil-Std-882C and utilizing the guidance of NAS 411, the contractor shall ensure that safety and environmental protection considerations are integral parts of the system engineering and detailed design efforts. The safety program shall address personnel and equipment concerns relative to the design, subsystem prototyping, development, testing, use, maintenance, life cycle support and disposal of the LMRS. If the contractor recommends the use of hazardous materials, the contractor shall obtain Government approval for using the hazardous material. In addition, the contractor shall perform an Environmental Analysis that addresses the entire life cycle of the LMRS program, including any testing that may be performed during the detailed design phase, to identify any areas of potential environmental impact and how the impacts could be mitigated. This analysis should include alternatives considered, potential environmental effects, rationale for concept/design alternatives chosen, and mitigation measures. The level of detail in these analyses should be commensurate with the maturity of the particular subsystem design in question (i.e. a subsystem that is still in the design phase will be less formal than a subsystem that is ready for testing).

(CDRL B001: Electronic Information System / Environmental Analysis)

(CDRL B001: Electronic Information System /Safety Assessment Report)

The contractor shall develop and maintain in the EIS a current LMRS Life Cycle Cost (LCC) estimate. The final LCC estimate shall be consistent with the PBL at Critical Design Review (CDR).

(CDRL B001 Electronic Information System / Life Cycle Cost Estimate)

The contractor shall develop, update, and maintain in the EIS a concept of operations for the LMRS that describes how the system would be operated in both peace time and war time scenarios. It should embody the results of the system engineering efforts tasked within paragraph 3.1 to the extent necessary to document how the contractor's system will utilize the existing infrastructure. The contractor shall identify effects of the concept of operations on the performance of the system, the host submarine platform, and the cadre who will operate the LMRS

(CDRL B001: Electronic Information System (EIS) / Concept of Operations)

The contractor shall implement a configuration management (CM) process to identify and control hardware and software configuration items and their documentation. Configuration control shall be maintained completely internally, i.e., without the need for government approval, until the government approves the PBL in conjunction with the CDR.

The contractor shall conduct four (4) design briefings/reviews, as described below. The contractor is encouraged to streamline these design reviews. In addition up to five (5) technical focus meetings (TFM) shall be conducted. Each briefing/review and/or TFM will replace the monthly program review (Par 3.5).

The purpose of the Software Functional Brief (SFB) is to ensure a technical understanding of the completed software specifications for the identified CSCI’s and the design compatibility between the hardware and software is established. In addition, the SFB should address how obsolescence in hardware will be addressed within the software design and how hardware replacement risk is mitigated through the identification of appropriate CSCIs. The brief should demonstrate convergence on computer software subsystem requirements as an integrated part of system requirements. This brief is planned for one (1) working day at the contractor’s facilities.

(CDRL B001: Electronic Information / Technical Briefings)

The purpose of conducting an Interim System Brief (ISB) is to confirm incremental progress toward meeting system level requirements and system maturity, including if the identified risk mitigation is achieving needed progress. This brief is planned for one (1) working day at the contractor’s facility and shall be conducted prior to month eight of the exercised option. (CDRL B001: Electronic Information System / Technical Briefings)

The purpose of the CDB is to present a Preliminary Product Baseline (PPBL) that demonstrates the following:

The contractor should demonstrate that there is consistency among the above items, and that the design is on track and will be ready to proceed into the Product Baseline (PBL)..

At the CDB the contractor shall present status on the following:

Finally, the contractor shall discuss how its design meets all the performance requirements of the LMRS Performance "A" Specification. This brief is planned for up to two (2) working days at the contractor’s facilities. and shall be conducted nominally prior to month fifteen of the exercised option.

(CDRL B001: Electronic Information System / Technical Briefings)

The purpose of the CDR is to present a Product Baseline (PBL) that demonstrates the following:

This brief is planned for up to three (3) working days at the contractor’s facilities. and shall be conducted during the final month of the exercised option.

(CDRL B001: Electronic Information System/ Technical Briefings)

Technical focus meetings (TFM) will serve as the form for the contractor to present to the government information that he deems relevant and critical to his design evolution. Up to five (5) TFM’s may be scheduled with Navy participation. TFM’s should be one day in duration at either the contractor or Navy facilities.

(CDRL B001: Electronic Information System/Technical Briefings)

A primary objective of this Detailed Design phase will be to further reduce system development risk through early prototype planning, development and demonstration. Effective prototyping shall include:

• identifying and prioritizing the subsystems that warrant further demonstration test and evaluation
• establishing meaningful and appropriate prototyping efforts
• mitigating the risk by performing relevant demonstrations.

The results and lessons learned by prototyping shall be captured and appropriately integrated into the system design. These tests should reflect as closely as possible the salient elements and challenges of development and of the operational scenario.

While the contractor has the flexibility to define the types and level of prototyping to be developed to support his detailed design, he shall be required to prototype a full or scaled version of the recovery subsystem. It will be up to the contractor to define, based on his specific design, how and to what extent his recovery subsystem prototype will ensure the following criteria are satisfied:

(CDRL B001: Electronic Information System/ Prototype Report)

(CDRL B001: Electronic Information System /Recovery Prototype Planning)

The contractor shall develop a test and evaluation plan, and provide such plan on the EIS prior to the CDB. This plan shall document how the contractor intends to demonstrate the ability of the integrated LMRS development phase prototype system to meet the functional requirements of the LMRS System "A" Specification, and the allocated requirements in the corresponding set of design documents. This plan should identify all testing and evaluation required to develop and demonstrate the LMRS for Navy acceptance.

(CDRL B001: Electronic Information System / Test & Evaluation Plan)

The contractor shall establish and maintain management operations in accordance with the following paragraphs. The use of Integrated Product and Process Development (IPPD) management approaches and the use of Integrated Process Teams (IPT) are strongly encouraged. The contractor shall conduct monthly meetings with the Government either by Video teleconference (VTC) or in person. These meetings will provide the contractor and Government an opportunity to discuss any questions or issues identified in the EIS or any recent changes to the program.

The contractor shall implement and maintain a Cost Schedule Status Reporting (CSSR) system. This system shall be developed using the contractor’s internal Government approved cost reporting system. The system should be designed to provide the contractor the necessary management knowledge to identify and correct problems prior to impacting the program.

(CDRL B001: Electronic Information System / Monthly Reports)

CSSR reporting shall be maintained in the contractor’s EIS. Reporting should be at a level to allow insight and understanding of the contractor’s program performance (normally WBS level 3). Variances, both schedule and cost, should be identified and reported. The threshold for reporting variances is +/- 10% and $25K at the third level WBS, with reporting done at the third level WBS only, not at rollups. The contractor shall identify the cause and any planned/executed corrective action for significant variances.

(CDRL B001: Electronic Information System / CSSR)

The contractor shall develop, implement, and maintain in the EIS a risk management process and plan that identifies, evaluates, and mitigates LMRS program risks from a technical, cost, and schedule perspective. Risks shall be evaluated as to their impact on reliability, safety, supportability, readiness, affordability, and technical performance objectives.

(CDRL B001: Electronic Information System / Risk Management Process and Plan)

Long-Term Mine Reconnaissance System (LMRS)

Allocated Baseline. The initially approved documentation describing a subsystem functional, performance, interoperability, and interface requirements that are allocated from those of the system or a higher level subsystem; interface requirements with interfacing subsystems; design constraints; derived requirements (functional and performance); and verification requirements and methods to demonstrate the achievement of those requirements and constraints. Generally, there is an allocated baseline for each subsystem to be developed.

Configuration Item (CI). [Not used in this standard but widely used in Government configuration management]. An aggregation of hardware, firmware, or computer software or any of their discrete portions, which satisfies an end use function and is for separate configuration management. Configuration items may vary widely in complexity, size, and type, from an aircraft, electronic, or ship system to a test meter or round of ammunition. Any item required for logistic support and designated for separate procurement is a configuration item.

Design. (verb) The process of defining, selecting, and describing solutions to requirements in terms of products and processes. (noun) The product of the process of designing that described solution (either conceptual, preliminary, or detailed) of the system elements or system end-items.

Demonstration. A demonstration consist of readily observable and functional operations that allow limited partial, or incremental determination of compliance with requirements.

Environment. The natural and induced conditions experienced by the system including its people, products, and processes. The natural environment (weather, climate, ocean conditions, terrain, vegetation, space conditions); threat environment (effects of existing and potential threat systems to include electronic warfare and communications interception); operations environment (dust, fog, smoke, nuclear-chemical-biological, thermal, shock, vibration, power variations); transportation and storage environment; maintenance environment; test environments; manufacturing environments (critical process conditions, clean room, stress) and other environments (e.g., software engineering environment, electromagnetic) related to system utilization.

Functional Baseline. The initially approved documentation describing a system’s or item’s functional, performance, interoperability, and interface requirements and the verification required to demonstrate the achievement of those specified requirements.

Interface Requirement. The functional and physical requirements and constraints at a common boundary between two (or more) functions or items. Interfaces result from the interaction between functions, items, products of an item, or collateral effects of operating an item. Functional interfaces are the relationships between characteristic actions (internal or external). Physical interfaces are the relationships between internal parts of the solution as well as between the solution and external elements.

Technical Performance Measurement (TPM). The continuing verification of the degree of anticipated and actual achievement for technical parameters. Confirms progress and identifies deficiencies that might jeopardize meeting a system requirement. Assessed values falling outside established tolerances indicate a need for evaluation and corrective action.

Non-Developmental Item (NDI). Non-developmental means "not requiring development." Non-developmental items include:

Preliminary Product Baseline. The preliminary documentation, describing the necessary functional, performance, and physical requirements of the subsystem; the functional and physical requirements designated for review and comment prior to submission for production acceptance testing; and procedures and plans necessary for deployment, support, training, and disposal of the subsystem. There is a preliminary product baseline for each subsystem, component, and part.

Product Baseline. The initially approved documentation describing all of the necessary functional, performance, and physical requirements of the subsystem; the functional and physical requirements designated for production acceptance testing; and test necessary for deployment, support, training, and disposal of the subsystem. In addition to the documentation, the product baseline of a subsystem may consist of the actual equipment and software. There is a product baseline for each subsystem, component, and part.

Risk. A measure of the uncertainty of attaining a goal, objective, or requirement pertaining to technical performance, cost, and schedule. Risk level is categorized by the probability of occurrence and the consequences of occurrence. Risk is assessed for program, product, and process aspects of the system. This includes the adverse consequences of process variability. The sources of risk include technical (e.g., feasibility, operability, producibility, testability, and systems effectiveness); cost (e.g., estimates, goals); schedule (e.g., technology/material availability, technical achievements, milestones); and programmatic (e.g., resources, contractual).

Subsystem. A grouping of items satisfying a logical group of functions within a particular system.

System Life Cycle. The period extending from inception of development activities, based on an identified need or objective, through decommissioning and disposal of the system.

Systems Engineering. An interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life-cycle balanced set of system people, product, and process solutions that satisfy customer needs. Systems engineering encompasses:

Tailoring. The process by which individual task statements (sections, paragraph, or sentences) of specifications, standards, and related documents are evaluated to determine the extent to which they are most suitable for a specific system and equipment development and the modification of these requirements to ensure that each achieves an optimal balance between operational needs and cost.