Scitax Advisory Partners LP
Canada
... the full service R&D tax credit specialists
Scitax 20th Anniversary — celebrating 20 years

MIL-STD-881C WhitepaperBack to the full Whitepaper

Appendix B: Electronic Systems

Download full PDF

Appendix B: Electronic Systems

APPENDIX B: ELECTRONIC SYSTEMS WORK BREAKDOWN STRUCTURE AND DEFINITIONS B.1 SCOPE This appendix provides the Work Breakdown Structure and definitions for the prime mission product (PMP) and platform integration. Definitions for WBS elements common to Electronic Systems and all defense materiel items are given in Appendix L: Common Elements, Work Breakdown Structure and Definitions.

B.2 APPLICABLE DOCUMENTS

B.2.1 Government Publications. The following standards form a part of this document to the extent specified herein.

Unless otherwise indicated, copies of federal and military specifications, standards, and handbooks are available from the:

Acquisition Streamlining and Standardization Information System (ASSIST) database (https://assist.daps.dla.mil) Document Automation & Production Service 700 Robbins Avenue Building 4/D Philadelphia, PA 19111 STANDARDS MIL-STD-196E, Joint Electronics Type Designation System MIL-STD-1464A, Army Nomenclature System MIL-STD-1661, Mark and Mod Nomenclature System MIL-HDBK-1812, Type Designation, Assignment and Method for Obtaining

B.2.2 Non-Government publications. The following documents form a part of this document to the extent specified herein. AMERICAN NATIONAL STANDARDS INSTITUTE (ANSI) ANSI/IEEE STD 610.12-1990 (R2002), Standard Glossary of Software Engineering Terminology IEEE/EIA 12207-2008; GUIDE FOR SYSTEMS AND SOFTWARE ENGINEERING – SOFTWARE LIFE CYCLE PROCESSES

ANSI Standards can be found online at: http://webstore.ansi.org

ANSI Customer Service 25 W 43rd Street, 4th Floor New York, NY, 10036 or The Institute of Electrical and Electronics Engineers, Inc. (IEEE) Operations Center 445 Hoes Lane Piscataway, NJ 08854-4141 www.ieee.org

B.3 WORK BREAKDOWN STRUCTURE LEVELS

  • 1.0Electronic System
    • 1.1Prime Mission Product (PMP) 1…n (Specify)
      • 1.1.1PMP Subsystem 1…n (Specify)
        • 1.1.1.1PMP Subsystem Hardware 1…n
        • 1.1.1.2PMP Subsystem Software Release 1…n
        • 1.1.1.3Subsystem Integration, Assembly, Test and Checkout
      • 1.1.2PMP Software Release 1…n (Specify)
        • 1.1.2.1Software Product Engineering
        • 1.1.2.2Computer Software Configuration Item (CSCI) 1…n
        • 1.1.2.3Subsystem Integration, Assembly, Test and Checkout
      • 1.1.3PMP Integration, Assembly, Test and Checkout
    • 1.2Platform Integration, Assembly, Test and Checkout
    • 1.3System Engineering
    • 1.4Program Management
    • 1.5System Test and Evaluation
      • 1.5.1Development Test and Evaluation
      • 1.5.2Operational Test and Evaluation
      • 1.5.3Mock-ups / System Integration Labs (SILs)
      • 1.5.4Test and Evaluation Support
      • 1.5.5Test Facilities
    • 1.6Training
      • 1.6.1Equipment
      • 1.6.2Services
      • 1.6.3Facilities
    • 1.7Data
      • 1.7.1Technical Publications
      • 1.7.2Engineering Data
      • 1.7.3Management Data
      • 1.7.4Support Data
      • 1.7.5Data Depository
    • 1.8Peculiar Support Equipment
      • 1.8.1Test and Measurement Equipment
      • 1.8.2Support and Handling Equipment
    • 1.9Common Support Equipment
      • 1.9.1Test and Measurement Equipment
      • 1.9.2Support and Handling Equipment
    • 1.10Operational/Site Activation
      • 1.10.1System Assembly, Installation and Checkout on Site
      • 1.10.2Contractor Technical Support
      • 1.10.3Site Construction
      • 1.10.4Site/Ship/Vehicle Conversion
      • 1.10.5Sustainment/Interim Contractor Support
    • 1.11Industrial Facilities
      • 1.11.1Construction/Conversion/Expansion
      • 1.11.2Equipment Acquisition or Modernization
      • 1.11.3Maintenance (Industrial Facilities)
    • 1.12Initial Spares and Repair Parts

B.3.1 Application of Common WBS Elements (Appendix L). WBS elements that are common (i.e., Integration, Assembly, Test and Checkout; Systems Engineering; Program Management; Acquisition Logistics; System Test and Evaluation; Training; and Data) should be applied to the appropriate levels within the WBS for which they support. For example, if Systems Engineering is required to support a Level 3 WBS element, the Systems Engineering WBS element would appear at Level 4 of the WBS under the Level 3 element it supports.

B.3.2 Key Principles in Constructing a WBS. In the appendices of MIL-STD-881C, the WBS is defined to Level 3 of that structure and in some cases Level 4 or 5. In order to ensure consistency across all systems and developers, WBS elements in the appendices are extended to levels 4 and 5.

  • 1) The reporting level of the WBS is typically at Level 3 except for those items considered high cost, high risk, or high technical interest. For those elements, extension of the WBS to lower levels is necessary to get needed visibility, but only for those elements. Not all WBS elements should be extended to the lowest level. In addition, for each system being defined only those WBS elements that define the system shall be used. The purpose of going below level 3 within the appendix is to ensure that the higher level elements include the proper lower level elements and when required to report at a lower level, those elements at level 4 or 5 are consistent across all systems and developers.
  • 2) A key to WBS development is the principle that if you can associate the WBS element with the element it supports, it should be included within that element. This is called the 100% rule, which states the next level of decomposition of a WBS element (child level) must represent 100% of the work applicable to the next higher level (parent level). For example, the parent level WBS (radar system) has three child elements – transmitter, antenna, and receiver. If the program manager decides he/she wants more visibility into the transmitter subsystem and pulls it out of the radar system and makes it a level equal to the radar, it distorts the effort and resources that are required to complete that radar system because it assumes the transmitter is not included (i.e., a child element to the radar is now missing within the WBS structure).
  • 3) In some cases, items cannot be specifically associated with the element they support. For example, software is a critical element of that transmitter subsystem. Under normal circumstances, software would be the child level to the parent level transmitter. However, depending on how software is developed, the software may include more functionality than just for the transmitter subsystem. It may include functionality for the receiver as well. In this case the software cannot be associated with the specific elements they support, due to an inability to determine the effort for each functionality developed. Therefore, it is appropriate to associate that software to the next highest level (radar system) of the WBS. It is still included as a part of the radar system at the child level, but we are not trying to allocate effort across multiple WBS elements where we are unable to determine what level of support each gets.
  • 4) Intelligence (Intel) efforts (security, threat, mission data) are often considered late in the acquisition cycle, even after contract award. Identifying where Intel is needed reduces risk and affords a much better opportunity to manage cost, schedule, and performance. The WBS Standard portrays systems in a product-oriented WBS, identifying and considering potential intelligence information and costs using the existing Component cost estimating processes.

B.3.3 Numbering of the WBS. In each appendix, the work breakdown structure for that commodity has been numbered for reporting purposes only. The purpose for the numbering is to provide a consistent approach to identifying and managing the WBS across like systems regardless of vendor or service. The numbering system is numeric; however, several unique issues arise across appendices which require the numbering system to be modified to accommodate the anomalies.

B.3.3.1. “Other” WBS Elements. All appendices contain a WBS element titled as “Other” at the subsystem, element (product) levels that are restricted for products that have not been envisioned or predicted within the defined WBS elements in the Appendix. If it is determined that the “other” WBS is not needed, this element and assigned WBS number should be deleted and not used in the WBS. If it is determined that the “other” element is needed, then each element must be defined and the word “other” replaced by the newly defined WBS element using the assigned WBS number from the appropriate appendix. The newly defined element must be approved by the Government Program Manager and the representative contracting officer.

B.3.3.2 (1…n) WBS Element Definitions. Several appendices identify WBS elements with (1…n) or similar to denote that one or more of that type of item may be used. Where this structure occurs, the parent WBS (e.g., 1…n) shall be decomposed to the next level and then each child WBS use the appropriate WBS title for each element as well as the WBS numbering identification. For example, if a missile system has multiple propulsion subsystems, each Propulsion Subsystem (1…n) shall have a WBS name designation (for example, “Solid Rocket Motor”), and the element Propulsion Subsystem 1 would be at the child level of the parent WBS element (Propulsion Subsystem 1…n) as would Propulsion Subsystem 2 (for example, “Liquid Rocket Engine”), and so forth. Each WBS should be detailed down to the element’s lower level (as defined in the appendices) whenever possible, and assigned the next available WBS number in sequence according to the parent child relationship as shown below.

  • 1.1.2. Propulsion Subsystem (1…n)
  • 1.1.2.1. Solid Rocket Motor
  • 1.1.2.2. Liquid Rocket Engine
  • 1.1.2.3. Backup Rocket Motor

B.4 DEFINITIONS

B.4.1 Electronic System. The complex of equipment (hardware/software), data, services, and facilities required to develop and produce an electronic system capability such as a command and control system, radar system, communications system, information system, sensor system, navigation/guidance system, electronic warfare system, support system, etc.

NOTE 1: To differentiate between the Electronic System category and other defense materiel item categories, use the following rule: When the item is a stand-alone system or used on several systems but not accounted for within the system, use the Electronic System category.

NOTE 2: When the opportunity to collect lower level information on electronic and software items exists, regardless of which defense materiel item category is selected, the structure and definitions in this appendix apply.

B.4.2 Prime Mission Product (PMP) 1…n (Specify). The hardware and software used to accomplish the primary mission of the defense materiel item. This WBS element includes the design, development, and production of complete units (i.e., the prototype or operationally configured units, which satisfy the requirements of their applicable specifications, regardless of end use) and is comprised of the sub elements listed below.

  • Includes, for example:
  • a. All integration, assembly, test and checkout, as well as all technical and management activities associated with individual hardware/software elements
  • b. Integration, assembly, test and checkout associated with the overall prime mission product (PMP). when the electronic system comprises several PMPs, each PMP will be listed separately at Level 2
  • c. All whole and partial prime contractor, subcontractor, and vendor breadboards, brass boards, and qualification test units
  • d. The design, development and production of complete units (i.e., the prototype or operationally configured units, which satisfy the requirements of their applicable specification(s), regardless of end use)
  • e. Factory special test equipment, special tooling, and production planning required to fabricate the PMP
  • Excludes, for example:
  • a. Only those “less than whole” units (e.g., test, spares, etc.) Consumed or planned to be consumed in support of system level tests
  • b. Duplicate or modified factory special test equipment delivered to the Government for depot repair (should be included in the peculiar support equipment element)

B.4.2.1 Prime Mission Product Subsystem 1…n (Specify). The hardware and software components of the specific electronic subsystem.

  • Includes, for example:
  • a. All associated special test equipment, special tooling, production planning, and all technical and management activities
  • b. Software components, consisting of the applications and system software required to direct and maintain the specific electronic subsystem
  • c. All in-plant integration, assembly, test, and checkout of hardware components and software into an electronic subsystem, including the subsystem hardware and software integration and test
  • d. Interface materials and parts required for the in-plant integration and assembly of other Level 4 components into the electronic subsystem and all materials and parts or other mating equipments furnished by/to an integrating agency or contractor
  • e. Cables, conduits, connectors, shelters, and other devices associated with the operational electronic subsystem
  • f. The design, development, production, and assembly efforts to provide each electronic subsystem as an entity
  • Excludes, for example:
  • a. All effort directly associated with the remaining Level 3 WBS elements and the integration, assembly, test and checkout of these elements into the prime mission product

NOTE: All software that is an integral part of any specific equipment system, subsystem or component specification or specifically designed and developed for system test and evaluation should be identified with that system, subsystem, component or effort. It may be appropriate to collect lower level information when it exists. In such cases, the following structure and definitions should be used:

LEVEL X LEVEL Y PMP Subsystem Hardware 1…n (Specify) PMP Subsystem Software Release 1…n (Specify) Software Product Engineering (defined per 4.2.1.2.1) Computer Software Configuration Item (CSCI) 1…n (defined per 4.2.1.2.2) Subsystem Integration, Assembly, Test and checkout (defined per 4.2.1.2.3) Subsystem Integration, Assembly, Test and Checkout B.4.2.1.1 Prime Mission Product Subsystem Hardware 1…n (Specify). The hardware and associated resource components of the specific electronic/automated software subsystem.

B.4.2.1.2 Prime Mission Product Subsystem Software Release 1…n (Specify). The resources associated with the PMP subsystem software that is associated with the PMP subsystem for release 1…n. A software release is an aggregate of one or more CSCIs that satisfies a specific set or subset of requirements. When incremental, spiral, or other software development methods are used, multiple releases may be necessary to meet program requirements. A release is a separately tested and delivered product. Within releases are CSCIs. When a release is complete, a portion or all of one or more CSCIs will be completed. Therefore, a CSCI may appear in one or more releases, but will be successively more functional as each release is completed.

  • Includes, for example:
  • a. Software product engineering,
  • b. Computer Software Configuration Item (CSCI) 1…n
  • c. Subsystem Integration, Assembly, Test and Checkout

B.4.2.1.2.1 Software Product Engineering. All of the resources associated with the PMP software product engineering efforts. Software product engineering is focused on process maturity and continuous improvement. Sound software product engineering is a systematic framework, which breaks down the software development process by relating each level to a knowledge domain and localizing exactly on those qualities that become visible in that knowledge domain.

B.4.2.1.2.2 Computer Software Configuration Item (CSCI) 1…n (Specify). An aggregation of software or any of its discrete portions that satisfies an end use function and has been designated by the Government or Contractor, if the Government did not specify, for configuration management. CSCIs are the major software products of a system acquisition, which are developed in accordance with standard DoD or commercial practices and processes.

  • Includes, for example:
  • a. Software requirements
  • b. Software architecture and design
  • c. Software code and unit test
  • d. Software Integration
  • e. Software qualification testing
  • f. Commercial off the Shelf (COTS)/Government off the Shelf (GOTS) approach
  • g. COTS/GOTS component identification
  • h. COTS/GOTS assessment and selection
  • i. COTS/GOTS prototyping
  • j. COTS/GOTS glue code development
  • k. COTS/GOTS tailoring and configuration

When software development is accomplished, items (a) through (e) are typical development activities. When COTS/GOTS is to be used and integrated, items (f) through (i) are typical integration activities.

B.4.2.1.2.3 Subsystem Integration, Assembly, Test and Checkout. The resources specifically related to evaluating the CSCIs and hardware operation as a subsystem. (ANSI/IEEE 12207)

  • Includes, for example:
  • a. All resources necessary to integrate the subsystem components as a complete subsystem
  • b. Subsystem integration management
  • c. Requirements definition, planning and scheduling
  • d. Development of integration plans and procedures
  • e. Integration test preparations, conduct and teardown and review, analysis and documentation of subsystem integration results.
  • B.4.2.2 Prime Mission Product Software Release 1…n (Specify). The resources associated with PMP subsystem software that is not associated with the PMP subsystem (i.e., Distributed SW environment) for release (1…n). Includes, for example:
  • a. Software product engineering,
  • b. Computer Software Configuration Item (CSCI) 1…n
  • c. Subsystem Integration, Assembly, Test and Checkout

B.4.2.2.1 Software Product Engineering. All of the resources associated with the PMP software product engineering efforts. Software product engineering is focused on process maturity and continuous improvement. Sound software product engineering is a systematic framework, which breaks down the software development process by relating each level to a knowledge domain and localizing exactly on those qualities that become visible in that knowledge domain.

B.4.2.2.2 Computer Software Configuration Item (CSCI) 1…n (Specify). An aggregation of software or any of its discrete portions that satisfies an end use function and has been designated by the Government or Contractor, if the Government did not specify, for configuration management. CSCIs are the major software products of a system acquisition, which are developed in accordance with standard DoD or commercial practices and processes.

  • Includes, for example:
  • a. Software requirements
  • b. Software architecture and design
  • c. Software code and unit test
  • d. Software integration
  • e. Software qualification testing
  • f. Commercial off the Shelf (COTS)/Government off the Shelf (GOTS) approach
  • g. COTS/GOTS component identification
  • h. COTS/GOTS assessment and selection
  • i. COTS/GOTS prototyping
  • j. COTS/GOTS glue code development
  • k. COTS/GOTS tailoring and configuration

B.4.2.2.3 Subsystem Integration, Assembly, Test and Checkout. The resources specifically related to evaluating the CSCIs and hardware operation as a subsystem. (ANSI/IEEE 12207)

  • Includes, for example:
  • a. All resources necessary to integrate the subsystem components as a complete subsystem
  • b. Subsystem integration management
  • c. Requirements definition, planning and scheduling
  • d. Development of integration plans and procedures
  • e. Integration test preparations, conduct and teardown and review, analysis and documentation of subsystem integration results

B.4.2.3 Prime Mission Product Integration, Assembly, Test and Checkout. This WBS element contains all of the resources in order to perform integration, assembly, test, and check out of the PMP. This is the process of combining and evaluating CSCIs and Hardware of a system or segment of a system that have undergone individual CSCI and hardware qualification test.

B.4.3 Platform Integration, Assembly, Test and Checkout. The effort involved in providing technical and engineering services to the platform manufacturer or integrator during the installation and integration of the PMP into the host system.

  • Includes, for example:
  • a. Labor required to analyze, design, and develop the interfaces with other host vehicle subsystems
  • b. Drawing preparation and establishment of equipment requirements and specifications
  • c. Technical liaison and coordination with the military services subcontractors, associated contractors, and test groups
  • Excludes, for example:
  • a. All integration effort not directly associated with the host vehicle and management liaison with the military services, subcontractors, and associated contractors

B.4.4 Common WBS Elements. Remaining Common WBS Elements. Definitions for Common WBS elements applicable to the Electronics Systems, and all other defense materiel items, are in Appendix L: Common Elements, Work Breakdown Structure and Definitions.