"Change is inevitable; except in vending machines."

Transcription

1 Configuration Management Change is inevitable. In acquisition programs, missions, requirements, technologies, and environments change. In response, the system design will change as it evolves through the systems engineering process. Without management control, these changes could lead to chaos. In systems engineering, configuration management (CM) is the main tool used for controlling change. Program managers must have processes in place to record the initial technical baseline design and track changes as the design matures. They also need to carefully evaluate change proposals for their impacts and benefits in order to make informed decisions on whether to introduce those changes into the design process, and when and how to do so. In this lesson, we will examine how configuration management is carried out to manage technical change and mitigate its effects. You may print the Configuration Management lesson or save it for future reference. "Change is inevitable; except in vending machines." Anonymous Page 1 of 29

2 Objectives Upon completion of this lesson, you should be able to: Recognize how configuration management affects all functional disciplines (e.g., test, logistics, manufacturing, etc.) Relate the different types of program-unique specifications to their appropriate configuration baselines and technical review requirements Identify the relationship between configuration baselines, specifications, and configuration management planning Page 2 of 29

3 Configuration Management Defined Every program manager (PM) must establish a change control process to ensure an orderly and disciplined way of reviewing, approving, and implementing changes. CM is a process for controlling change while maintaining product consistency. An integral part of the systems engineering process, CM also helps to verify that changes to subsystems are considered in terms of the entire system, minimizing adverse effects. With effective CM, a product's performance, as well as its functional and physical attributes, are traceable to its requirements, design, and operational information. CM continues throughout a product's life. As requirements or design attributes change, records are updated to ensure that technical documentation accurately reflects the current product. In other words, CM helps control the design process and its documentation. Page 3 of 29

4 Why Do Configuration Management? CM permits orderly system development and ensures: Designs are traceable to requirements Changes are controlled and documented Interfaces are defined and understood Consistency is maintained between a product and its documentation CM documentation describes: What is supposed to be produced What is being produced What has been produced What modifications have been made to what was produced Page 4 of 29

5 What is a Configuration? To systems engineers, a configuration is a collection of an item's characteristics. These characteristics can be expressed in physical or functional terms. Physical characteristics concern what the item should look like and consist of once it is built. For hardware, physical characteristics include composition, materials, dimensions, finishes, form, fit, and interchangeability. For software, the physical characteristics consist of the software code. Functional characteristics concern what performance the item is expected to achieve. For both hardware and software, functional characteristics involve performance requirements, interface requirements, and logistics constraints. These include such things as speed, reliability, maintainability, availability, and other factors that correlate directly to mission requirements. Page 5 of 29

6 What's a Configuration Item? A configuration item (CI) is any separately identifiable component of a system that is treated as a self-contained unit for the purposes of identification and change control. All CIs are uniquely identified by codes and version numbers. A configuration item can be hardware, software, or a combination of both. Essentially, it is any component or aggregation of components that: Satisfies an end-use function Is worthy of maintenance, critical to engineering, or essential for logistics Is designated for configuration management Page 6 of 29

7 Configuration Management Functions Management Directive Enterprise Information Technology Configuration Management provides guidance on CM functions at DHS. The DHS Enterprise CM Program includes five functions that align with the ANSI standard EIA649B. These functions are interdependent, and they serve to identify and document what we have, control and track changes, and verify the accuracy and completeness of our documentation. Select each function from the graphic below to learn more. D Page 7 of 29 Planning and Management This function plans and manages the CM process and provides for monitoring and improvement of CM processes. This includes planning, coordinating, and managing all tasks necessary to implement CM principles and to conduct CM activities. CM planning and management occurs throughout all Systems Engineering Life Cycle (SELC) activities. Identification This function establishes a structure for products and product configuration information; selects, defines, documents, and baselines product attributes and relationships; and, assigns unique identifiers to each product and product configuration information. All configuration items are documented in a Configuration Management System (CMS). Change Management This function ensures that changes to a configuration baseline are properly identified, prioritized, documented, coordinated, evaluated, and adjudicated.

8 Status Accounting This function manages the capture and maintenance of product configuration information necessary to account for the configuration of a product throughout its life cycle. Validation and Audit This function reviews processes, documentation, and products to verify compliance with requirements, and confirms that products have achieved their required attributes and conform to released product definition information. Graphic depicting the five functions of Configuration Management: Planning and Management, Identification, Change Management, Status Accounting, and Validation and Audit.

9 CM Function: Planning and Management A CM plan describes the processes that will be used to identify, manage, control, document, and audit the system baseline. The plan defines the policy, procedures, structures, roles, and responsibilities in executing configuration management. It also identifies Configuration Control Board (CCB) members and the procedures they will use to evaluate and approve changes to the system. The CM plan should address: Identifying CIs Assessing the impacts of proposed changes Selecting CM tools and processes to be used (for example, document storage and retrieval) The PM is responsible for configuration management planning. He or she can elect to have a separate CM plan or include CM plan information in the Integrated Logistics Support Plan (ILSP). D Page 8 of 29 Reprise of the Configuration Management graphic with Planning and Management highlighted.

10 CM Function: Identification Changes during a program are expected, and baselines help track them. Baselines define system requirements and other attributes and enable configuration management as the design evolves. Baselines are also used to measure performance and progress, and provide traceability back to earlier baselines. Baselines include approved artifacts (such as design documentation, databases, and drawings that describe the system) and contain the level of detail commensurate with the solution's development progress. For incremental programs, baselines reflect the level of detail expected at that point in the program, and should be updated as the program progresses and the system design matures. DHS has identified one operational and four technical baselines: Operational Baseline Technical Baselines: Functional Allocated Developmental Production It is important to note that these baselines and their artifacts may be tailored. The following screens provide a description of each baseline and identify the relevant SELC technical review. Don't confuse configuration baselines with the Acquisition Program Baseline of cost, schedule, and performance. D Page 9 of 29 Reprise of the Configuration Management graphic with Identification highlighted.

11 Operational Baseline The Operational Baseline represents the set of operational requirements and the applicable source documents that define the system's behavioral characteristics from a user perspective. This baseline includes the Mission Needs Statement (MNS), Operational Requirements Document (ORD), and Concept of Operations (CONOPS), at a minimum. If developed, additional reference source material, including the Analysis of Alternatives (AoA)/Alternatives Analysis (AA), white papers, studies, models, and calculations that form the basis for the operational requirements are included. The intent of this baseline is to communicate the operator's needs unambiguously and completely in operational, not technical, terms. This baseline, along with the Functional Baseline, is used during Operational Test and Evaluation (OT&E) to validate the operational suitability and effectiveness of a system. The Operational Baseline is established at the Solution Engineering Review (SER) and is owned by the program sponsor. Page 10 of 29

12 Functional Baseline The Functional Baseline defines what the system has to perform, but not how. The Functional Baseline is always established and controlled by the Government. It is directly traceable to the performance requirements identified in the ORD and MNS through the system specification in the contract. The Functional Baseline comprises a set of artifacts that include: Documentation that identifies all requirements of the system Functional Non-functional Interface Interoperability Functional analysis results Initial interface control document (ICD) Means of verification Reference materials (white papers, studies, models, and calculations that form the basis of the functional requirements) The Functional Baseline is documented in the Functional Requirements Document (FRD) and System Specification. The Functional Baseline is established at the System Definition Review (SDR) during Requirements Definition activities of the SELC, and is owned by the program office. Page 11 of 29

13 Requirements Traceability Matrix As part of configuration identification, programs establish a requirements traceability matrix (RTM). The matrix is used to: Map each functional requirement to its source Verify the connection between products and requirements Ensure that all requirements are accounted for Ensure that all requirements are covered by testing The matrix is updated throughout the systems engineering life cycle. It provides traceability from user requirements to the FRD specifications and test cases. It is a best practice to use automated requirements management tools to help with requirements management and traceability. Page 12 of 29

14 Allocated Baseline The Allocated Baseline is represented by the set of artifacts that defines the architecture of the system, and consists of the CIs that comprise the system, as well as their interrelationships and primary interfaces. The Allocated Baseline defines the requirements allocated to each CI and, as such, defines the top-level design of the system. For hardware items, this is the allocation of requirements to the subsystem level. For software applications, this would equate to allocating functionality to different modules that are part of the total application. The Allocated Baseline is really a series of baselines that address each subsystem or module as a separate item. These define the functional and interface characteristics allocated to the subsystem/module from the system or higher level configuration item. Page 13 of 29

15 Allocated Baseline (continued) The Allocated Baseline requirements become the Functional Baseline for the specific subsystem or module. This becomes important when a subsystem is procured from a subcontractor or vendor, or when different teams are working on different software modules. The allocation of functional requirements is done by the contractor with Government oversight. In a true performance-based acquisition, the contractor maintains control of the Allocated Baseline. In some cases, the Government maintains control of the Allocated Baseline. The Allocated Baseline for each subsystem or module is documented in the System Requirements Document (SRD) during Design activities of the SELC. It also includes white papers, studies, models, and calculations that form the basis of the allocated design. This is a "design-to" baseline that is established at the Preliminary Design Review (PDR). The Allocated Baseline is used during the Functional Configuration Audit (FCA), if performed, to verify that the Functional and Allocated Baselines have been met. Page 14 of 29

16 Developmental Baseline The Developmental Baseline is represented by the set of artifacts that defines the final design of the system as it proceeds through development. This baseline consists of the System Requirements Document (SRD) and System Design Document (SDD), or equivalent, for software, applicable vendor-developed specifications, and detailed design drawings. It also includes white papers, studies, models, and calculations that form the basis of the design. It is established at the Critical Design Review (CDR) during the Design activity of the SELC, and is the "build-to" (or "code-to") baseline, which results in the physical realization of the system. The Developmental Baseline is owned by the program office, but is maintained under the developer's configuration control process. Page 15 of 29

17 Production Baseline The Production Baseline is where configuration identification gets down to the nitty-gritty details of physical characteristics, materials, processes, and the location of individual piece parts for each configuration item. It is the "as-built" version of the system whose CIs have undergone any required qualification testing and operational testing (OT) and have been determined to be ready for production. This is the mature Developmental Baseline and is established following the Physical Configuration Audit (PCA). The Production Baseline describes: All necessary physical or form, fit, and function characteristics Selected functional characteristics designated for production acceptance testing Production acceptance test requirements The Production Baseline also includes any functional characteristics that are designated for production acceptance testing, and all production acceptance test requirements. Page 16 of 29

18 Production Baseline (continued) The Production Baseline is documented in the System Design Document (SDD) and in the Item Detail Specification for each configuration item. Production Baseline documentation includes the complete set of released and approved engineering design documents: Engineering models Engineering drawings and associated lists for hardware Software, interface, and database design documents Representation of Computer Software Configuration Item (CSCI) source code Material and process specifications Documents are not considered a part of the Production Baseline until they are approved and released. The Production Baseline is usually created and maintained by the contractor who develops and produces the system. It is also called the detailed design. Page 17 of 29

19 Knowledge Review When do documents become part of the Production Baseline? A. When they are accepted by the contractor B. When they are approved and released C. When they are completed by the systems engineering integrated product team Correct! Documents become part of the Production Baseline only after they are approved and released. Page 18 of 29

20 Configuration Baselines and the Systems Engineering Process Configuration baselines are created as a result of the system engineering process: The Operational Baseline is created during Solution Engineering and is established at the SER The Functional Baseline is created during Requirements Definition. It is captured in a FRD that is approved at the SDR The Allocated Baseline is created early in the Design activity of the SELC and is established at the PDR The Development Baseline is created late in the Design activity of the SELC and is captured in the CDR The Production Baseline documents the "as-built" version of the system that has completed testing and is ready for production D Select the image to view an enlargement Select the D-link to read a detailed explanation of the graphic Page 19 of 29

21 Graphic depicting the entire systems engineering life cycle (SELC) framework and where baselines fit in. The Operational Baseline coincides with Solution Engineering and the SER. The Functional Baseline coincides with Requirements Definition and the SDR. The Allocated Baseline coincides with Design and the PDR. The Developmental Baseline coincides with Design and the CDR. The Production Baseline is last and coincides with Implementation around the time of the Operational Readiness Review (ORR). A detailed description of the SELC graphic follows. The process begins with Mission Analysis, which is a DHS activity that happens before and outside of both the SELC and the Acquisition Lifecycle Framework (ALF). The first activity of the SELC is Needs Analysis, which occurs during the Need Phase of the ALF. It begins with Acquisition Decision Event 0 (ADE-0) and includes the recommended Initial Technical Review (ITR). The second SELC activity is Solution Engineering, which includes the Study Plan Review (SPR) and Solution Engineering Review (SER). Solution Engineering occurs during the Analyze/Select Phase of the ALF, which starts with ADE-1 and ends with ADE 2-A. The third SELC activity is Planning, which includes the Project Planning Review (PPR). The PPR contains the SELC tailoring plan. Planning occurs during the Obtain Phase of the ALF, between ADE-2A and ADE-2B. Technology and Development, which includes research and development (R&D), happens simultaneously with the first three SELC activities. This activity is iterative between Needs Analysis and Solution Engineering. The next three major SELC activities occur during the Obtain Phase of the ALF between ADE-2B and ADE-2C. The fourth SELC activity is Requirements Definition, which includes the System Definition Review (SDR). The fifth is Design, and this SELC activity includes two documents, the Preliminary Design Review (PDR) and the Critical Design Review (CDR). The sixth is Development, which includes the Integration Readiness Review (IRR). Integration and Test activities of the SELC occur simultaneously and iteratively with Requirements Definition, Design, and Development. Integration and Test concludes with the Production Readiness Review (PRR). The next SELC activity also overlaps with the Obtain Phase of the ALF. Implementation takes place between ADE-2C and ADE-3. Implementation includes two key documents, the Operational Test Readiness Review (OTRR) and the ORR. The last two SELC activities take place during the Produce/Deploy/Support/Dispose Phase of the ALF, post ADE-3. The first one is Operations and Maintenance, which includes the Post Implementation Review (PIR). The final SELC activity is Disposition.

22 Configuration Baselines: Example The Domestic Nuclear Detection Office (DNDO) needs to develop a robotic radiation detection device to scan cargo containers. The Operational Baseline consists of the MNS, ORD, and CONOPS, as well as the AoA. The Functional Baseline consists of performance specifications, such as probability of detection, detection range, all-weather capability, ability to scan five containers per hour, ability to operate continuously for four hours, and ability to communicate. The Allocated Baseline assigns each of these functional specifications to a component of the system. For example, probability of detection would be assigned to a sensor package, and ability to operate continuously would be assigned to a power supply module. The Development Baseline includes all the planned designed elements for the product. The Production Baseline contains the "as-built" specifications and drawings for each component of the system that is actually produced. Page 20 of 29

23 Knowledge Review Which configuration baseline distributes functions among specific components or subsystems of the system under development? A. Operational B. Functional C. Allocated D. Developmental E. Production Correct! Only the Allocated Baseline allocates functions to specific components or subsystems of the system under development. Page 21 of 29

24 CM Function: Change Management Once a configuration baseline has been established, changes to that baseline must be proposed, evaluated for impact, approved, implemented, documented, and verified. Change Management, the third CM function, is the systematic process we use to ensure technical changes are properly considered, incorporated, and documented. The contractor usually submits the formal documentation to trigger a configuration change. Here are some common types of documents used to prompt or capture design changes: Engineering Change Proposal (ECP) recommends a change that, once approved, will make a permanent alteration to the established configuration baseline. The baseline documentation must be updated after the change is approved. Notice of Revision (NOR) revises configuration documentation after the ECP is approved. It is also used to inform the Government of a change to a baseline that is controlled by the contractor. Request for Deviation (RFD) requests approval to deviate from a baseline configuration for a specified period or number of production systems. It does not apply to a change that affects the entire production quantity. Specification Change Notice (SCN) proposes and records changes to a specification. D Page 22 of 29 Reprise of the Configuration Management graphic with Change Management highlighted.

25 Configuration Control Responsibility Any change to the configuration must be approved by the appropriate authority. The Government may be the authority, or authority may be delegated to the contractor. If an item is used in other applications, the approval authority may already be established. Within the Government, responsibility and authority for configuration control is vested in the program manager (PM). While some authority for approving minor changes may be delegated, the responsibility remains with the PM. The PM is assisted in this role by a Configuration Control Board (CCB) or a Change Control Board (CCB). These terms are often used interchangeably. Page 23 of 29

26 Change Control Board (CCB) The primary mechanism through which a PM implements CM is the Change Control Board (CCB). The CCB will assess the technical, cost, and schedule impacts of all proposed changes to the system. Since design changes can have a broad impact on the program, all functional areas need to have a representative on the CCB. These functional areas typically include: Program Management the PM chairs the CCB and has final approval authority over changes; the Deputy PM also participates Systems Engineering a design change will likely impact system development Test & Evaluation a design change will often require additional testing Manufacturing a design change may require manufacturing changes Logistics a design change can alter supportability and training requirements Contracting a design change often requires a contract modification Budget and Finance a design change may require additional funding Cost Estimating the cost impact of the proposed change must be assessed Scheduling schedules must be developed for implementing the change In addition to functional reps, there are two other key participants on the CCB: User the sponsor's representative evaluates the impact of the change on meeting the requirements Contractor they have to implement the change, once it's approved Page 24 of 29

27 CM Function: Status Accounting Status Accounting involves documenting all configuration information. We must establish a process to record and report all information needed to manage the configuration. That process will be used to: Record all baseline information and changes thereto Record approval of configuration items and associated details Document all proposed configuration changes and their status Provide implementation status of all approved changes Provide the current configuration information for all assets A configuration status accounting system should be implemented with a database containing all baseline information that is traceable to the requirements. The database should include the approval record for all configuration items, changes, and associated technical documentation. The contractor's configuration accounting system must be in a format that facilitates transfer of data and is compatible with the Government's system. Consistent CM data must be available to all to ensure everyone works from the same page. An automated configuration status accounting system is preferable to a manual one. D Page 25 of 29 Reprise of the Configuration Management graphic with Status Accounting highlighted.

28 CM Function: Validation and Audit The last CM function is Validation and Audit. We conduct configuration audits to ensure configuration baseline documents match the actual configuration of the system. There are two types of configuration audits: the functional audit and the physical audit. The Functional Configuration Audit (FCA) compares the prototype system to the Functional and Allocated Baseline documentation to ensure the system satisfies the performance requirements in the way in which they were allocated. The Physical Configuration Audit (PCA) compares the first production representative article to the Production baseline documentation to ensure the system is constructed and produced in accordance with the documentation. It ensures the "as built" configuration agrees with the design technical documentation and all approved changes. D Page 26 of 29 A prototype is a preproduction item produced to test a product design. Prototypes may include mathematical models, drawings, hardware, or software. They may be produced during the Obtain Phase of the ALF. A production representative article is an item produced after the Functional, Allocated and Product Baselines for a system have been established. The article accurately represents the production configuration system for both hardware and software, but has not been produced on a final production line. It is highly desirable for the article to be manufactured on a formal production line, but not required. Some components may have been hand-tooled, and some components may be from production tooling. The article may be produced just prior to, or at the beginning of, low rate initial production (LRIP). Reprise of the Configuration Management graphic with Validation and Audit highlighted.

29 Knowledge Review Which of the following is considered a best practice for configuration management? A. Use a Change Control Board (CCB) to evaluate proposed changes B. Retain Government control of the production baseline for all configuration items C. Keep contractor configuration data completely separated from Government data D. Conduct periodic configuration audits to define external interface requirements Correct! The CCB is a cross-functional team that helps a program manager consider all affected disciplines, including testing, logistics, manufacturing, engineering, and contracting. Page 27 of 29

30 Configuration Management for Agile Software Development Agile CM compresses CM activities into shorter time frames. Because Agile IT products are delivered in small increments and move fast, the CM process has to become more fluid and less rigid. CM for Agile software development applies Lean principles: Eliminate waste, build in quality, create knowledge, defer commitment, deliver fast, respect people, and optimize the whole. To accomplish this, the program manager should measure the degree of CM process formality, and the degree of CM tool automation, with the goal of increasing both. Select the D-link to read a detailed explanation of the graphic Norin, J. (2007). Lean Configuration Management: Evolving the CM Discipline Through the Agile Paradigm Shift. Retrieved from D Page 28 of 29 Graphic depicting a square divided into four boxes, each containing a type of configuration management (CM): Lean CM, Automated CM, Ad hoc CM, and Defined CM. The square is within an X and Y axis, with the Y Axis progressing from a low to a high degree of automation, and the X axis progressing from a low to high degree of process. Ad hoc CM has a low degree of defined process and low degree of automation. Defined CM has a high degree of defined process and low degree of automation. Automated CM has a high degree of defined process and high degree of automation. Lean CM has a low degree of defined process and high degree of automation.

31 Summary Configuration management is the process used by program managers and contractors to control changes to a system. An integral part of the systems engineering process, configuration management ensures that designs are traceable to requirements, hardware and software components are documented, external interfaces are defined, and all changes to the system are evaluated, approved, and recorded. Five functions are involved in configuration management. Select each one for a review You may print the Configuration Management lesson or save it for future reference. Please select the next lesson from the table of contents to continue the course. D Page 29 of 29 Planning and Management This function plans and manages the CM process and provides for monitoring and improvement of CM processes. This includes planning, coordinating, and managing all tasks necessary to implement CM principles and to conduct CM activities. CM planning and management occurs throughout all Systems Engineering Life Cycle (SELC) activities. Identification This function establishes a structure for products and product configuration information; selects, defines, documents, and baselines product attributes and relationships; and assigns unique identifiers to each product and product configuration information. All configuration items are documented in a Configuration Management System (CMS). Change Management This function ensures that changes to a configuration baseline are properly identified, prioritized, documented, coordinated, evaluated, and adjudicated.

32 Status Accounting This function manages the capture and maintenance of product configuration information necessary to account for the configuration of a product throughout its life cycle. Validation and Audit This function reviews processes, documentation, and products to verify compliance with requirements; and, confirms that products have achieved their required attributes and conform to released product definition information. Graphic depicting the five functions of Configuration Management: Planning and Management, Identification, Change Management, Status Accounting, and Validation and Audit.