• Configuration Item (CI) “An aggregation of hardware, firmware, computer software, or any of their discrete portions, which satisfies an end use function and is designated by the (Acquirer) for separate configuration management. Configuration items may vary widely in complexity, size, and type. Any item required for logistic support and designated for sepa- rate procurement is a CI.” (Source: Adapted from DSMC Glossary: Defense Acquisition Acronyms and Terms) • Configuration Management “A management process for establishing and maintaining con- sistency of a product’s performance, functional, and physical attributes with its requirements, design and operational information throughout its life.” (Source: ANSI-EIA-649-1998, p. 4) • Effectivity “A designation defining the product range (e.g., serial, lot numbers, model, dates) or event at which a change to a specific product is to be (or has been) effected or to which a variance applies.” (Source: ANSI-EIA-649-1998, p. 4) • Hardware Configuration Item (HWCI) “An aggregation of hardware that satisfies an end use function and is designated for separate configuration management by the Acquirer.” (Source: Adapted from former MIL-STD-498, p. 5) • Item Any physical component of a system such as a PRODUCT, SUBSYSTEM, ASSEM- BLY, SUBASSEMBLY, or PART. • Line Replaceable Unit (LRU) “A unit designed to be removed upon failure from a larger entity (product or item) in the operational environment, normally at the organizational level.” (Source: MIL-HDBK-470A, Appendix G, Glossary, p. G-8) • Logical Configuration Item (LCI) An optional designation assigned to a specific capability. • Physical Configuration Item (PCI) An item that represents the physical instance of a con- figuration item (CI). Each item is assigned a part number and may be serialized. • Product Structure Refer to definition provided in Chapter 9 System Levels of Abstraction and Semantics. • Requirements Baseline “Documentation describing a system’s/segments functional char- acteristics and the verification required to demonstrate the achievement of those specified functional characteristics. The system or segment specification establishes the functional baseline” (Source: DSMC Glossary: Defense Acquisition Acronyms and Terms) • Variance, Deviation, Waiver, Departure “A specific written authorization to depart from a particular requirement(s) of a product’s current approved configuration documentation for a specific number of units or a specified time period. (A variance differs from an engineer- ing change in that an approved engineering change requires corresponding revision of the product’s current approved configuration documentation, whereas a variance does not.)” (Source: ANSI/EIA-649-1998, Section 3.0, Definitions, p. 6) Items—Building Blocks of Systems Large, complex systems are developed by groups of people working as Integrated Product Teams (IPTs) or development teams with assigned roles and responsibilities for producing various system products. Depending on the size and complexity of the system or item being developed, teams are assigned tasks such as specifying, designing, developing, integrating, and verifying various com- ponents within the system. This presents some significant challenges: 1. How do you partition the architecture of the EQUIPMENT element into multiple levels and instances of manageable physical items? 42.1 Introduction 491 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 2. How can people establish semantics that enable them to communicate with others about the types of items they are developing or procuring from external vendors? 3. How can people communicate about the evolution of system components that go through various stages from abstract system specification entities into physical components used to build the system? The solution resides in integrated building blocks referred to as items, configuration items (CIs), hardware configuration items (HWCIs), and software configuration items (CSCIs). Each of these building blocks represents semantics used to identify abstract entities within a system and their evo- lution from SPS to deliverables. 42.2 UNDERSTANDING CONFIGURATION IDENTIFICATION SEMANTICS Configuration identification knowledge for most SEs typically comes from informal exposure via verbal discussions in meetings, on-the-job-training (OJT), and observation over many years. Most engineers have little or no training in the principles of configuration management; most are self- taught through observation and knowledge of general CM standards. By these means they feel able to proclaim themselves to be configuration experts. These rudimentary skills provide basic insights about system architectural configuration deci- sions. However, meanings and applications of the terms are often convoluted. Instead of seeking insightful guidance from competent CM personnel, technical leads exercise their authority, make decisions, and blunder down the road of regrets, while CM and others expend endless energy contending with the consequences of these decisions. So, to minimize the confusion, let’s begin by informally introducing key terms. Figure 42.1 depicts entity relationships to support our discussions. 492 Chapter 42 System Configuration Identification Configuration Items HWCIs CSCIs AFP Items COTS Products NDI Products Integrated into 1 * Integrated into 1 * Integrated into 1 * Consist of 1 * Consist of 1 * Consist of 1 * Consist of 1 * Consist of 1 * Where: AFP = Acquirer/User Furnished Property CSC = Computer Software Component CSU = Computer Software Unit COTS = Commercial-Off-the-Shelf CSCI = Computer Software Configuration Item HWCI = Hardware Configuration Item NDI = Non-Developmental Item System Architectural Configuration Comprise Items Consist of 1 * Internally Developed, Reusable Components CSCs CSUs Integrated into 1 * Where: = May or may not consis t of = Composition Figure 42.1 System Configuration Identification Elements Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Component Origins Every entity within a SYSTEM, regardless of level of abstraction is referred to as an ITEM. If you analyze most systems, you will discover that items originate from at least six different methods: 1. Procured from a vendor’s catalog. 2. Procured from a vendor’s catalog and customized/adapted in-house. 3. Customized or modified versions of items found in a vendor’s catalog. 4. Developed in-house by human intellect or procured as components or raw materials from suppliers. 5. Developed in-house from customizations of existing, legacy designs. 6. Provided by the Acquirer in accordance with the terms and conditions (Ts&Cs) of the system development contract and integrated into the SYSTEM design. Observe two types of themes above. First, items are procured externally, and second, items are developed internally. Externally Acquired or Procured Components As introduced in Chapter 41, items procured from a vendor’s catalog are referred to as commer- cial off-the-shelf (COTS) items. COTS items customized or modified for a specific application are referred to as nondevelopmental items (NDIs). Acquirer provided items are referred to as Acquirer furnished property (AFP). Author’s Note 42.1 When the System Developer receives contract-based AFP from the User via the Acquirer, each item must be recorded, tracked, and controlled in accordance with the terms and conditions (Ts&Cs) of the contract. Planned modifications to AFP typically require authori- zation by the Acquirer’s Contracting Officer (ACO). Make sure the Ts&Cs clearly delineate WHO is accountable for: 1. Providing AFP documentation. 2. AFP failures while in the possession of the System Developer. Configuration Items (CIs) When a System Developer decides to develop a MAJOR item such as a PRODUCT, SUBSYS- TEM, or ASSEMBLY in-house, the program designates the item as a configuration item (CI). CIs require a specification that specifies and bounds the CI’s capabilities and performance. A CI, as a major item, integrates lower level components that may consist of: AFP, COTS items, NDIs, and two other types developed by the System Developer in-house: • Hardware configuration items (HWCIs) • Computer software configuration items (CSCIs) HWCIs and CSCIs HWCIs are major hardware items and CSCIs are major software applications designated for con- figuration control. • As CIs, HWCIs and CSCIs may include COTS items, NDIs, internally developed or legacy items, or combinations of these. 42.2 Understanding Configuration Identification Semantics 493 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com • Each HWCI is specified via requirements documented in an HWCI Requirements Specifica- tion (HRS). • Each CSCI is specified via requirements docuemented in a CSCI Software Requirements Specification (SRS). Firmware Some processor-based applications such as single board computers (SBC) employ software encoded into an integrated circuit (IC) referred to as firmware. Firmware ICs, which are nonvolatile memory device types, may be implemented with single-use, read only, and reprogrammable devices. Firmware represents a hybrid instance of an item that evolves from a CSCI into an HWCI, as illus- trated in Figure 42.2. Initially, the software program executed by the SBC is developed as a CSCI software appli- cation and debugged on laboratory prototype SBC hardware, using emulators and other devices. When the software application reaches maturity and is ready for final integration, the CSCI’s code is electronically programmed into the firmware IC device. Once programmed, the firmware IC is: 1. Designated as an HWCI. 2. Assigned a part number, serial number, and version. Both the CSCI and HWCI are controlled in accordance with the CM procedures. Guidepost 42.1 The preceding discussions introduced the semantics of configuration identifi- cation. Some of these semantics apply to ANY level of abstraction. You should recall from our dis- cussion in Chapter 9 System Levels of Abstraction and Semantics that one organization’s SUBSYSTEM might be another organization’s SYSTEM. Our follow-on discussions illustrate WHY the referential nature of configuration identification semantics when applied to levels of abstrac- tion result in confusion. Configuration Semantics Synthesis To understand how configuration identification semantics relate to multi-level system architectures, Figures 42.1 and 42.3 depict the entity relationships. Table 42.1 provides a listing of entity rela- tionship rules that govern the implementation of this graphic. 494 Chapter 42 System Configuration Identification Computer Software Configuration Item (CSCI) Computer Software Configuration Item (CSCI) Hardware Configuration Item (HWCI) Hardware Configuration Item (HWCI) XXX-YYYY-2 Firmware Programming Device Figure 42.2 Evolution of Firmware from Software to Hardware Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 42.2 Understanding Configuration Identification Semantics 495 SYSTEM SYSTEM SUBSYSTEM s SUBSYSTEMs ASSEMBLY(s ) ASSEMBLY(s) SUBASSYs. SUBASSYs. PART s PARTs Item Item Commercial- Off-the-Shelf (COTS) Item(s ) Commercial- Off-the-Shelf (COTS) Item(s) Non- Developmental Item s (NDIs) Non- Developmental Items (NDIs) Configuration Items (CIs ) Configuration Items (CIs) HWCI(s ) HWCI(s) CSCI(s ) CSCI(s) Operational Solution Behavioral Solution Physical Solution Requirements Solution Where: Consists of Consists of Consists of Designated as Consists of Consists of = May or May Not Designated as Designated as Designated as Designated as Solution Set Described by Described by Consists of Consists of PRODUCTs PRODUCTs Designated as Acquirer Furnished Equipment (AFE ) Acquirer Furnished Equipment (AFE) Figure 42.3 Item/Configuration Items (CIs) Compositional Entity Relationships Table 42.1 Configuration semantics rules Rule Title Configuration Identification and Development Rule 42.1 Items Every entity within a system, regardless of level of abstraction, is referred to as an item. 42.2 Configuration Designate major items selected for internal development and configuration items control. 42.3 Configuration Items may originate from several types of sources: items 1. Replicated from existing, internally developed component designs. 2. Acquired as COTS, NDI, or AFP. 3. Acquired as COTS, NDI, or AFP and modified in-house. 4. Developed as new designs such as an HWCI(s) or CSCI(s). 42.4 CI A CI’s composition may consist of one or more COTS products, NDIs, HWCIs, composition CSCIs, AFPs, or combinations thereof. 42.5 CI Develop a performance or development specification for each item designated as a specifications CI. 42.6 HWCIs and Develop an HWCI Requirements Specification (HRS) for each HWCI; Develop a CSCIs CSCI Software Requirements Specification (SRS) for each CSCI. 42.7 CI solution Develop a Requirements Domain, Operations Domain, Behavioral Domain, and set Physical Domain Solutions for each CI, HWCI, and CSCI. 42.8 CSCIs The product structure of each CSCI consists of at least two or more CSCs that consist of at least two or more CSUs. 42.9 CI ownership Assign accountability for the design, development, and integration and verification for each CI, HWCI, and CSCI to an individual or IPT. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Guidepost 42.2 At this juncture we have established the context and composition of CIs. The question is: HOW do we determine which items should be designated as CIs. This brings us to our next topic on the selection of configuration items. Selection of Configuration Items (CIs) The preceding discussions established that CIs are MAJOR items developed in-house. While this is an important criterion, CIs often require additional considerations. The best approach for select- ing CIs is to simply establish a set of selection criteria. Then, perform a reasonableness check to ensure that the selection: 1. Is logical. 2. Provides the proper visibility for technical, cost, and schedule tracking. 3. Exposes development activities at a level that can be used for assessing risk. Some organizations establish specific criteria for selecting CIs that go beyond simply deciding to develop an item internally. These decisions should be made in collaboration with a program’s con- figuration manager, a subject matter expert (SME) in this domain. The selection of configuration items often varies from one organization or business domain to another. To standardize thinking about selecting CIs, MIL-STD-483A (cancelled) offers the fol- lowing guidance in selecting CIs: 1. Is it a critical high risk, and/or a safety item? 2. Is it readily identifiable with respect to size, shape, and weight (hardware)? 3. Is it newly developed? 4. Does it incorporate new technologies? 5. Does it have an interface with hardware or software developed under another contract? 6. With respect to form, fit, or function, does it interface with other configuration items whose configuration is controlled by other entities? 7. Is there a requirement to know the exact configuration and status of changes to it during its life cycle? (Source: Former MIL-STD-483A, para. 170.9, pp. 118–119) Configuration Item (CI) Boundaries Contrary to some beliefs, items and CIs SHOULD NOT be partitioned across physical device boundaries; this is a violation of good design practice as noted in our earlier discussion of Figure 40.4. In general, CIs: 1. Are bounded by a development specification, HWCI Requirements Specification (HRS) or CSCI Requirements Specification (SRS). 2. Reside within the boundaries of a physical item—such as SYSTEM, SUBSYSTEM, ASSEMBLY, or SUBASSEMBLY as a computer system, printed circuit board, software application, and so forth. 3. Must be verified against their respective HRS or SRS. To illustrate this point, consider the hypothetical example below: 496 Chapter 42 System Configuration Identification Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com EXAMPLE 42.1 As an example of an INCORRECT approach, an organization has a contract to develop a word processor soft- ware application. Using the INCORRECT approach, the software CSCI would have CSCs implemented across physical items: 1. A desktop computer (HWCI) 2. The printer (HWCI) 3. Other (HWCIs) on a network So, if CIs, HWCIs, and CSCIs require stand-alone performance or development specifications to specify and bound an integrated item that is SELF-CONTAINED within a physical item, How do we test the software, as an item, when it resides across several HWCIs (boundaries)? Remember, CIs are tested and verified as standalone test articles—as a black box with inputs and outputs—with all the necessary functionality self-contained. Adhering to the boundary con- straints specified above, there is an expectation that the CSCI will be tested on a single HWCI device such as a desktop computer. Obviously, this is not achievable since the CSCI’s CSCs are implemented in several HWCI devices (desktop computer, printer, network, etc.) across the system. The CORRECT approach requires a CSCI on each device. Configuration Identification Responsibility Configuration identification, as an informed, multi-discipline, decision-making process, requires collaboration with those stakeholders. Contrary to what many people believe, it IS NOT a decision by ONE individual exercising their discretionary authority in a vacuum without inputs from the key decision stakeholders. As the multi-level entity architectures evolve, the Configuration Manager (CM) / Software Configuration Manager (SCM), Lead SE, and other SEs collaborate to select the CORRECT approach for identifying items and CIs that will endure the test of time and AVOID the junk heap of POOR decisions. Guidepost 42.3 At this point we have established the basic set of configuration identification semantics and how they are applied to multi-level system architectures. These discussions high- lighted the need during internal development to prepare a development specification for each CI, HWCI, and CSCI. For the first article on Developmental Configurations, this is a straightforward process. Two key questions: 1. HOW are these specifications maintained for production systems that evolve over time as new capabilities and refinements are added to established designs? 2. How do these impacts affect systems or products that are already fielded that may require RETROFITTING? This brings us to our next topic, configuration effectivity. Configuration Effectivity Production systems may evolve over several years as newer technologies, capabilities, and improve- ments are incorporated into the evolutionary system design solution. As such, the physical config- uration changes. So the question becomes: HOW do we delineate the changes in configuration to a given CI, HWCI, or CSCI? Configuration management addresses these configurations via a concept referred to as configuration effectivity. 42.2 Understanding Configuration Identification Semantics 497 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Every CI, HWCI, and CSCI is labeled with a unique identifier that delineates it from all others. This occurs at two levels: 1) model number and 2) serial numbers. So, when physical configura- tions change over the years, some organizations simply reference the effectivity beginning with Serial Number (S/N) XXX; others append a “dash number” to the model number—such as Model 123456-1—to indicate a specific version. Most organizations today affix barcode labels to CIs, HWCIs, and CSCIs to facilitate automated version or configuration tracking. Versioning provides the System Developer a couple of options. It allows evolutionary track- ing of a product line over its life span, and it provides a means to account for special customiza- tions delivered to an Acquirer. In lieu of model numbers and versioning, some vendor’s employ contract numbers and serial numbers to designate items. You may ask: Why is this important to SE? Effectivity-Based Specifications During the development of a system or product, multi-discipline SEs prepare item development specifications (IDSs) for PRODUCTS, SUBSYSTEMS, HWCIs, and CSCIs that form the Devel- opmental Configuration. Although cost is a key constraint, most first article systems or products MAY NOT represent the most cost-effective solution due to schedule and other constraints. First articles are simply a solution that meets specification requirements. Typically, each deliverable is assigned contract/model numbers and serial numbers. If a system is planned for production, Product Engineering initiates efforts to reduce the recur- ring per unit cost via design improvements, component and material selection and procurement, manufacturing methods, and so forth. Ultimately, the improvements culminate in a revised item development specification with effectivity beginning with S/N XXX forward. Once production starts, CIs, HWCIs, and CSCIs evolve over time. Whereas during the origi- nal system development, revisions to the Developmental Configuration specifications were issued when changes occurred. So, when production item changes occur, you have to revise the specifi- cation level and the effectivity. When this occurs, the program has two choices: create a new specification unique to a configuration, or designate model and serial number effectivity on the cover page and annotate specification requirements unique to the effectivity within the document. 42.3 ALIGNING ITEMS AND CIs WITH THE SPECIFICATION TREE Once CIs are identified, the key question is: HOW do you communicate their location within the system’s product structure? The answer is: CIs should be explicitly identified in the specification tree based on derivation from the system architecture as shown in Figure 42.4. Here, the SEIT analyzes the System Performance Specification (SPS) requirements to create the SYSTEM level architecture, as shown in the lower left corner of the graphic. The architecture consists of PRODUCTs A and B. PRODUCT B, which consists of ITEMs B_1 through B_3, will be developed internally, and is designated as a CI. As the system architecture evolves, the specification tree evolves, as shown on the right side of the graphic. Based on the designation of CIs and items, item development specifications are identified. • PRODUCT A has its own PRODUCT A development specification. • PRODUCT B, as a CI, has its own unique PRODUCT B development specification that includes requirements for ITEMs B_1 through B_3. 498 Chapter 42 System Configuration Identification Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com • ITEM B_3 is designated as a CI for development and, as such, is required to have its own unique ITEM B_3 development specification. 42.4 ASSIGNING OWNERSHIP OF ITEMS AND CIs As the specification tree evolves, CI development ACCOUNTABILITY should be assigned to owners such as development teams or Integrated Product Teams (IPTs). Figure 42.5 provides an illustrative example. Note how the system architecture decomposes along product structure lines. This is a key point, especially the operative word “product.” For programs that establish Integrated Product Teams (IPTs), each IPT focuses on “product” development and collaborates with interfacing IPTs developing items that interface to their assigned product. For example, IPT 1 collaborates with IPT 2 on mutual interface design issues. Accountability for developing ONE product is assigned to ONE and only one IPT. Depending on the size, complexity, and risk of the multi-level items, an IPT may be assigned accountability for one or more products as illustrated in Figure 42.5. Accountability for developing PRODUCTs A and B, which have a moderate degree of complexity and risk, is assigned to IPT 1. In contrast, accountability for PRODUCT C is assigned to IPT 2 due to its complexity and risk. This brings us to a final point. Programs often get into trouble because SEs develop the IPT organizational structure first and then leave the IPTs to identify the architectural configuration with limited, if any, oversight by the SEIT. In this example, PRODUCTs A and B, by virtue of accountability by IPT 1 would be bundled together, regardless of the lack of physical interfaces and be idenitified as a PRODUCT or SUB- SYSTEM. Then, the IPT will attempt to develop a development specification for the conglomeration. In many cases PRODUCTs A and B are unrelated, thereby indicating NO interfaces. Yet, the IPT will be required to verify both PRODUCTs together as a “black box.” Avoid and correct these system configuration identification decisions. Often these decisions are made by local “heroes” with 42.4 Assigning Ownership of Items and CIs 499 System Performance Specification (SPS ) PRODUCT B Configuration Item PRODUCT B Configuration Item ITEM B_1 COTS ITEM B_1 COTS ITEM B_2 COTS ITEM B_2 COTS SYSTEM SYSTEM SYSTEM CI Product Structure PRODUCT A COTS Item PRODUCT A COTS Item ITEM B_1 COTS Item ITEM B_1 COTS Item ITEM B_2 COTS Item ITEM B_2 COTS Item PRODUCT A COTS Item PRODUCT A COTS Item PRODUCT B Configuration Item SYSTEM Level Architecture PRODUCT A Development or Product Specificatio n PRODUCT B Development Specificatio n Item B_3 Configuration Item Item B_3 Configuration Item ITEM B_3 Configuration Item ITEM B_3 Configuration Item PRODUCT B_3 Development or Product Specificatio n 3 Figure 42.4 System Configuration Documentation Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com an ounce of knowledge about system architecture development and IPT implementation yet wield authority and create programmatic situations that severely impact contract performance. 42.5 RECOGNIZING TYPES OF ARCHITECTURAL ITEM BOUNDARIES The Industrial Revolution introduced new concepts for standardizing and reproducing modular and interchangeable components via predictable methods in order to leverage the benefits of economies of scale. Our discussions on SYSTEM, PRODUCT, SUBSYSTEM, ASSEMBLY, SUBASSEM- BLY, and PART levels of abstraction expound on these themes. The concept of modularity can easily lead to the SE mindset that all items and CIs are con- structed as modular plug and play boxes. The System of Systems (SOS) approach further reinforces the mindset of “box” CIs integrated into a higher level system. However, there are systems whereby INTEGRATION occurs ACROSS the traditional “box” boundaries. In general, systems often consist of two classes of PRODUCTs/SUBSYSTEMs: 1. Mission specific PRODUCTs/SUBSYSTEMS. 2. Infrastructure PRODUCTs/SUBSYSTEMS that transcend the mission-specific SUBSYS- TEM boundaries. Figure 42.6 illustrates this type of architecture. Consider the following example: EXAMPLE 42.2 Office building systems, as MISSION SYSTEMs, consist of well-defined architectural “box” boundaries. Hier- archically, we could refer to the individual floors of office buildings as SUBSYSTEM level CIs. However, what about the plumbing and electrical, heating, ventilation, and air conditioning (HVAC) system CIs that 500 Chapter 42 System Configuration Identification Configuration Item Hierarchy PRODUCT B Configuration Item PRODUCT B Configuration Item ITEM B_1 ITEM B_1 ITEM B_2 ITEM B_2 SYSTEM SYSTEM PRODUCT A Configuration Item PRODUCT A Configuration Item ITEM B_3 Configuration Item ITEM B_3 Configuration Item PRODUCT C Configuration Item PRODUCT C Configuration Item ITEM C_1 ITEM C_1 ITEM C_2 ITEM C_2 IPT #1 IPT #2 CI A Lead ITEM B_1 Lead ITEM B_2 Lead CI B_3 Lead ITEM C_1 Lead ITEM C_2 Team Lead IPT #1 Lead IPT #2 Lead IPT Responsibility & Accountability IPT #1 Accountability IPT #2 Accountability Figure 42.5 CI Assigned Responsibility & Accountability Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... MISSION SYSTEM SYSTEM 1 2 3 4 5 6 7 8 9 10 Mechanical 11 12 13 14 15 16 17 18 19 20 Optical 21 22 23 24 25 26 27 28 29 30 Chemical 31 32 33 34 35 36 37 38 39 40 Biological 41 42 43 44 45 46 47 48 49 50 Acoustical 51 52 53 54 55 56 57 58 59 60 Human 61 62 63 64 65 66 67 68 69 70 Mass Properties SYSTEM OF INTEREST (SOI) Interface Attributes Electrical 71 72 73 74 75 76 77 78 79 80 Figure 43.1 SYSTEM OF... Architecture and System Engineering National Air Space System Systems Engineering Manual Washington, DC: FAA Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 43 System Interface Analysis, Design, and Control 43.1 INTRODUCTION The identification, design, and control of system interfaces are key activities for system architecture development The capability of the SYSTEM and item... How do you decide to develop and IRS, ICD, and/ or IDD? What is an Interface Control Working Group (ICWG)? Who chairs the ICWG? What are some rules for analyzing, designing, and controlling SYSTEM or entity interfaces? System Analysis, Design, and Development, by Charles S Wasson Copyright © 2006 by John Wiley & Sons, Inc 5 07 Simpo PDF 43 System Interface Analysis, Design, and Version - http://www.simpopdf.com... 42.6 System Configuration Identification with Cross-Cutting Cis TRANSCEND all of the floors and office boundaries? We can declare the floors and offices as mission-based SUBSYSTEMS Infrastructure SUBSYSTEMS such as HVAC systems, would plumbing, electrical, and other such systems, transcend each floor Systems such as aircraft and automobiles, exhibit similar configurations Fuel systems and electrical systems,... The reality is some operational system interfaces—such as military systems or networks—are vulnerable to external threats and attacks These systems must contend with the unknowns and the unknown—unknowns Acquirers and System Developers must work with the Users and their supporting organizations to thoroughly: 1 Understand and anticipate a system s threats 2 Define HOW the SYSTEM interfaces will cope with... Architecture of Systems and Chapter 21 System Operational Capability Derivation and Allocation We continue our discussion of generalized and specialized interfaces, define an interface design methodology, investigate system ownership and control, address the need for standardization, and define how interfaces are documented We conclude with a discussion of the challenges and issues in defining the system interfaces... Although we tend to think that every item in a system is unique, systems and products often have multiple instances of a single CI throughout the system One of the roles of SE and the SEIT is to reduce development cost, schedule, and risk You do this by investigating the evolving system design solution and searching for opportunities to STANDARDIZE components and interfaces The bottom line is: AVOID REINVENTING... user and the computer communicate information and by which control is commanded, including areas such as: information presentation, displays, displayed information, formats and data elements; command modes and languages; input devices and techniques; dialog, interaction and transaction modes; timing and pacing of operations; feedback, error diagnosis, prompting, queuing and job performance aiding; and. .. – A2 External System Y PRODUCT A Development Team Ownership & Control External System X A1 A1 – A2 A2 Product A ICD A1 – A3 External System Y A3 A2 – A3 A2 Interface A1 – A2 ICD Figure 43.2 SYSTEM/ PRODUCT Level Interface Definition Options Interface A2 – A3 ICD Interface A1 – A3 ICD Simpo PDF 43 System Interface Analysis, Design, and Version - http://www.simpopdf.com 518 Chapter Merge and Split Unregistered... Laboratory Laboratory SUBSYSTEM SUBSYSTEM (Configuration Item) (Configuration Item) Power Distribution Power Distribution SUBSYSTEM SUBSYSTEM (Configuration Item) (Configuration Item) Communications Communications SUBSYSTEM SUBSYSTEM (Configuration Item) (Configuration Item) HVAC HVAC SUBSYSTEM SUBSYSTEM (Configuration Item) (Configuration Item) Fire Protection Fire Protection SUBSYSTEM SUBSYSTEM (Configuration . 17 18 19 21 22 23 24 25 26 27 28 29 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 47 48 49 51 52 53 54 55 56 57 58 59 61 62 63 64 65 66 67 68 69 Huma n 10 20 30 40 50 60 70 Huma n 71 72 73 74 75 . HVAC systems, would plumbing, electrical, and other such systems, transcend each floor. Systems such as aircraft and automobiles, exhibit similar configurations. Fuel systems and electri- cal systems,. 69 Huma n 10 20 30 40 50 60 70 Huma n 71 72 73 74 75 76 77 78 79 80 SYSTEM OF INTEREST (SOI) Interface Attributes Figure 43.1 SYSTEM OF INTEREST (SOI) Interface Interactions Analysis Matrix Simpo PDF Merge and Split Unregistered