MIL-STD-881C WhitepaperBack to the full Whitepaper

Appendix K: Automated Information Systems

APPENDIX K: AUTOMATED INFORMATION SYSTEMS WORK BREAKDOWN STRUCTURE AND DEFINITIONS K.1 SCOPE This appendix provides the Work Breakdown Structure and definitions for Automated Information Systems. Definitions for WBS elements common to all defense materiel items are given in Appendix L: Common Elements, Work Breakdown Structure and Definitions and those unique applications are in section L.6.

K.2 APPLICABLE DOCUMENTS

K.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 and Production Service 700 Robbins Avenue Building 4/D Philadelphia, PA 19111-5094 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

K.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

The Institute of Electrical and Electronics Engineers, Inc. (IEEE) Operations Center 445 Hoes Lane Piscataway, NJ 08854-4141 www.ieee.org

K.3 WORK BREAKDOWN STRUCTURE LEVELS

1.0Automated Information System (AIS)
- 1.1Automated Information System Prime Mission Product Release/Increment X
  - 1.1.1Custom Application Software 1…n (Specify)
    - 1.1.1.1Subsystem Hardware
    - 1.1.1.2Subsystem Software CSCI 1…n (Specify)
    - 1.1.1.3Subsystem Software Integration, Assembly, Test and Checkout
  - 1.1.2Enterprise Service Element 1…n (Specify)
    - 1.1.2.1Enterprise Service Element Hardware
    - 1.1.2.2Enterprise Service Element Software CSCI 1…n (Specify)
    - 1.1.2.3Enterprise Service Element Integration, Assembly, Test and Checkout
  - 1.1.3Enterprise Information System 1…n (Specify)
    - 1.1.3.1Business Area Hardware
    - 1.1.3.2Business Area Software CSCI 1…n (Specify)
    - 1.1.3.3Business Area Integration, Assembly, Test and Checkout
  - 1.1.4External System Interface Development 1…n (Specify)
    - 1.1.4.1External System Interface Hardware
    - 1.1.4.2External System Interface Software CSCI 1…n (Specify)
    - 1.1.4.3External System Interface Integration, Assembly, Test and Checkout
  - 1.1.5AIS Platform Hardware
  - 1.1.6System Level Integration
- 1.2System Engineering
- 1.3Program Management
- 1.4Change 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.1Site Type 1
    - 1.10.1.1Deployment Hardware and Software
    - 1.10.1.2User Documentation
    - 1.10.1.3Site Activation
    - 1.10.1.4User Training
    - 1.10.1.5Data Migration
    - 1.10.1.6Management/Engineering Support
    - 1.10.1.7Interim Logistics 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

K.3.1 Application of Common WBS Elements (Appendix L). Automated Information Systems uniquely apply common elements. For application of these elements, reference Appendix L, Section L.6. WBS elements that are common (i.e., Integration, Assembly, Test and Checkout; Systems Engineering/Program Management; 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.

K.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) In each of the appendices, an element entitled “Other” is available to provide flexibility within the WBS for new or additional WBS elements that are not identified or defined in the Standard. These “other” elements would be used if, for example, a new subsystem or modified subsystem is defined and it does not currently appear in the appendices of MIL-STD-881C.

3) 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).

4) 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.

5) 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.

K.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.

K.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.

K.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

K.4 DEFINITIONS

K.4.1 Automated Information System. The complex of enterprise elements, equipment (hardware), software, legacy systems, users, business rules, data and facilities required to develop, test and deploy an automated information system.

NOTE: 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 Appendix B – Electronic Systems, apply.

K.4.2 Automated Information Systems Prime Mission Product (PMP) Release/Increment (Version) X. The hardware, software, and associated effort used to analyze, design, integrate, and test the entire automated information system (AIS) prime mission product.

K.4.2.1 Custom Application Software 1…n. This element includes all the hardware, software, and associated effort needed to analyze, design, build, and test a custom software application, at the system developer’s site, to fulfill a capability gap not captured by COTS only software packages. (COTS only are captured under K.4.2.2.2 Enterprise Service Element Software CSCI (1…n)).

Excludes, for example:
a. Software development necessary for external system interfaces

K.4.2.1.1 Subsystem Hardware 1…n. This element includes all the associated hardware equipment needed to analyze, design, build, and test a custom software application at the system developer’s site to fulfill a capability gap not captured by the COTS only software packages. Use lower levels to identify individual hardware items (servers, routers, etc.).

Includes, for example:
a. Development and test hardware

Excludes, for example:
b. Deployment hardware at each operational site

K.4.2.1.2 Subsystem Software CSCI 1…n. This element includes all the associated effort needed to analyze, design, build, and test a custom software application to fulfill a capability gap not captured by the COTS only software packages. Use lower levels to identify individual custom computer software configuration items (CSCI).

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. Software COTS/GOTS approach (requirements negotiation)
g. Software COTS/GOTS component identification
h. Software COTS/GOTS assessment and selection
i. Software prototyping
j. Software COTS/GOTS glue code development
k. Software COTS/GOTS tailoring and configuration
l. Subsystem software product engineering (e.g., configuration management, quality assurance, managed services, etc.)

K.4.2.1.3 Subsystem Software Integration, Assembly, Test and Checkout. The element includes the effort and material associated with integrating and testing subsystem software CSCIs and hardware of an individual (or group of) subsystem software application that have undergone individual CSCI qualification test.

Excludes, for example:
a. Software development efforts necessary for external system interfaces

K.4.2.2 Enterprise Service Element 1…n. This element includes all the hardware, software, and associated effort needed for developing functionality or software services: unassociated, loosely coupled units of functionality that have no calls to each other embedded in them. These services can be integrated or used by several organizations, even if their respective client systems are substantially different.

Includes, for example:
a. Enterprise service management (monitoring, fault management)
b. Machine-to-machine messaging
c. Service discovery
d. People and device discovery
e. Metadata discovery
f. Mediation
g. Service security
h. Content discovery and delivery
i. Federated search
j. Enterprise catalog service
k. Data source integration
l. Enterprise content delivery network (caching specification, distributed caching, forward staging)
m. Session management
n. Presence and awareness
o. Audio over internet protocol (IP)
p. Video over IP
q. Text collaboration (chat, instant messaging)
r. White boarding and annotation
s. Application sharing
t. Application broadcasting
u. Virtual spaces
v. Identity management (people and device discovery)
w. Content discovery
x. Collaboration
y. User profiling and customization

NOTE: Service Oriented Architecture is based on a mesh of software services as shown above. It packages functionally as interoperable services.

K.4.2.2.1 Enterprise Service Element Hardware. This element includes all the associated hardware equipment needed at the system developer’s facility for assessing and tailoring COTS software applications or modules that can be attributed to a specific software service or bundle of services within the AIS system. Use lower levels to identify individual hardware items.

Includes, for example:
a. Development and test hardware

Excludes, for example:
a. Deployment hardware at each operational site

K.4.2.2.2 Enterprise Service Element Software CSCI (1…n). This element includes all the associated effort for assessing and tailoring COTS software applications or modules that can be attributed to a specific software service or bundle of services within the AIS system.

Includes, for example:
a. Software COTS/GOTS approach (requirements negotiation)
b. Software COTS/GOTS component identification
c. Software COTS/GOTS assessment and selection
d. Software prototyping
e. Software COTS/GOTS glue code development
f. Software COTS/GOTS tailoring and configuration
g. Subsystem software product engineering (e.g., configuration management, quality assurance, managed service contract, etc.)

Excludes, for example:
a. COTS software procurement: licenses, warranties, etc. include in the operational site activation element

K.4.2.2.3 Enterprise Service Element Integration, Assembly, Test and Checkout. The element includes the effort and material associated with integrating and testing the required software and hardware of an individual (or group of) Enterprise Service Element(s).

K.4.2.3 Enterprise Information System 1…n. This element includes all the hardware equipment and effort to plan, analyze, design, build, and test functionality(s) of an enterprise information system that uses an integrated database to support typical business processes within business/functional areas and consistent information access across areas and systems.

Includes, for example:
a. Enterprise resource planning
b. Enterprise data warehouse
c. Data mart
d. Operational data store
Excludes, for example:
a. General ledger
b. Accounts payable
c. Revenue and accounts receivable
d. Funds control and budgetary accounting
e. Cost management
f. Financial reporting
g. Real property inventory and management

K.4.2.3.1 Business Area Hardware. This element includes all the associated hardware equipment needed at the system developer’s facility for planning, analyzing, designing, building, and testing functionalities that can be attributed, in whole or in-part, to a specific functional/business area or module within the EIS system. Includes, for example:
a. Development and test hardware

Excludes, for example:
a. Deployment hardware at each operational site

K.4.2.3.2 Business Area Software CSCI (1…n). This element includes all the associated effort needed at the system developer’s facility for planning, analyzing, designing, building, and testing functionalities that can be attributed, in whole or in-part, to a specific functional/business area or module within the EIS system.

Includes, for example:
a. All necessary labor and materials for analyzing, designing/building/configuring, and testing the required business objects — reports, forms, interfaces, conversions, workflows, fact tables, dimension tables, scripts, enhancements, etc. — that can be attributed, in whole or in-part, to a specific functional module or business area within the EIS system
b. Effort for assessing and tailoring COTS software applications or modules that can be attributed, in whole or in-part, to a specific functional module or business area within the EIS system

K.4.2.3.3 Business Area Integration, Assembly, Test and Checkout. The element includes the effort and material associated with integrating and testing the required software and hardware of an individual (or group of) Business Area Element(s).

K.4.2.4 External System Interface Development 1…n. The hardware equipment and effort necessary for developing the set of software artifacts (threads, reports, queries, or scripts, or data export schemas) for a specific external system interface. Use lower levels to identify each specific external system interface that must be developed or modified. Includes, for example:
a. Design of the interface specification and the development of the interface

Excludes, for example:
a. Data Migration/Cleansing

NOTE: An external system interface is required for proper transmission of data and/or control between the AIS solution and separate systems for which a mutual dependency exists.

K.4.2.4.1 External System Interface Hardware. The hardware equipment necessary at the system integrator’s facility for developing the set of software artifacts (threads, reports, queries, or scripts, or data export schemas) for a specific external system interface. Use lower levels to identify each specific hardware item.

Includes, for example:
a. Development and test hardware

Excludes, for example:
a. Deployment hardware at each operational site

K.4.2.4.2 External System Interface Software CSCI (1…n). The effort associated with developing the set of software artifacts (threads, reports, queries, or scripts, portlets, or data export schemas) needed for a specific external system interface. Use lower levels to identify specific artifacts that must be developed or modified.

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. Software COTS/GOTS approach (requirements negotiation)
g. Software COTS/GOTS component identification
h. Software COTS/GOTS assessment and selection
i. Software prototyping
j. Software COTS/GOTS glue code development
k. Software COTS/GOTS tailoring and configuration
l. Subsystem software product engineering (e.g., configuration management, quality assurance, managed services, etc.)
m. Both the design of the interface specification and the development of the interface

K.4.2.4.3 External System Interface Integration, Assembly, Test and Checkout. The element includes the effort and material associated with integrating and testing the required software and hardware of an individual (or group of) External System Interface(s).

K.4.2.5 AIS Platform Hardware. This element includes all effort and equipment to develop a hardware system to host the deliverable AIS software

K.4.2.6 System Level Integration. This element includes all effort and equipment to assemble, integrate, and test the entire AIS system as a whole at the system developer’s facility.

K.4.3 Common Elements. Remaining Common WBS Elements. Definitions for Common WBS elements applicable to the Automated Information Systems, and all other defense materiel items, are in Appendix L: Automated Information Systems (AIS) Common Elements, Work Breakdown Structure and Definitions.