Configuration Management Based on Best Practices

Configuration Management Based on Best Practices
CM Manchester, UK, FEB 2000 Europe Seminar A1 – Establishing Industry Best Practices Configuration Management Based on Best Practices Alan E. Lager MLR Associates 2801 Park Center Drive, #A1612, Alexandria, VA 22302, USA Voice: ; Fax:

Agenda Configuration Management Based on Best Practices
What is CM -- Really? What are Best CM Practices? ANSI/EIA-649 Perspective Fundamental CM Principles Planning and Management Configuration Identification Configuration control Configuration Status Accounting Configuration Verification and Audit Measuring and Benchmarking CM Practices Agenda

What is Configuration Management - Really?
First... A Formal Definition (MIL-STD-973) As applied to Configuration items, CM is a discipline applying technical and administrative direction and surveillance over the life cycle of items to: (1) Identify and document the functional and physical characteristics of configuration item (2) Control changes to configuration items and their related documentation (3) Record and report information needed to manage configuration items effectively, including the status of proposed changes and the implementation of approved changes (4) Audit configuration items to verify conformance to specifications, drawings, interface control documents and other contract requirements

What is CM - Really! Updated Configuration Known Current Configuration CM IN OUT Change Requests Improve design Increase reliability Enhance Maintainability Reduce Cost Etc. Don’t get the idea that it’s all change control. In order to exercise change control you need an identified configuration, and you need status accounting throughout the life cycle. Status Controlling changes from idea inception to incorporation in all affected items

What is CM - Really? CM makes sure that:
The configuration of a product is known and reflected in product information Product change is beneficial and effected without adverse consequences Change is managed from idea inception to incorporation in all items affected What do you think I mean when I say “Configuration of a product? What parts; what changes; which options; which performance capabilities; the right identification How do you distinguish a beneficial change from an adverse one? It improves performance, reduces cost or fixes a problem; adverse creates a problem How do you assure that adverse consequences won’t result? Evaluate impact before deciding to do a change When we say “Change is managed,” what do we mean? Method of documenting, reviewing, evaluating impact, and verifying implementation

What is CM - Really? CM is an amalgamation of a set of best industry practices Properly applied, CM Serves both the provider (developer, producer, supplier) and the user (customer) of a product Facilitates Logistic Support (Product Support) and product maintenance Is a Cost Avoider NOT a Cost Driver!!! What does CM do for the Provider? Prevents technical anarchy Avoids trial and error engineering and program management Avoids embarrassment of customer dissatisfaction and complaint Captures information needed to make later decisions Avoids cost and catastrophe! What does CM do for the user? Provides customer choice on changes affecting customer interests Guarantees continued support of a product, or at least notice of obsolescence Assures consistency between the product and the information about the product Enables user and service person to distinguish between product versions and correlate to related instructions How does CM facilitate ILS? Make sure support elements are considered Provide identification discipline Cost Avoidance The next time someone refers to Cm as a cost driver, ask him what the impact would be if there were no part identification system, or no process for managing changes, or no release system

What are Best CM Practices?

What are “Best Practices”
Practices that are the benchmark by which similar activities are judged Methods that Are effective and efficient Meet customer requirements Have rational performance goals Include performance measurement standards Align with corporate business objectives Position the organization as a leader Best Practice success stories … Exhibit a high degree of organizational acceptance Tend to be learning organizations Foster cross-functional learning Use total cost in decision making and process improvement Address the entire value-chain for their products In most cases, they initiate best practices efforts as a result of external influences Listen to their employees and their customers

What are Best CM Practices?
Applicable CM Principles Customer Environment Supplier Environment Assess Measure Benchmark Documented CM Process Integrated in Organizational Process Best CM Practices are NOT: Fixed procedures applicable to every circumstance. Best CM Practices ARE: Based on fundamental CM principles; A principle is the what. A practice is how the principles are implemented in the process. Practices that fit the Product & Customer-Supplier environment; Documentation, identification and control to the appropriate degree CM Best Practices Are documented and measurable Can be justified in common-sense terms Allow for flexibility and judgement CM Best Practices are integrated into the overall organizational process Recognized as the normal course of business; Accepted as the way things are done Aid the process; CM is a lubricant that allows the engines of development, production, supply, and support and to run smoothly and in sync.

ANSI/EIA-649 Perspective
ANSI/EIA 649 “National (US) Consensus Standard on Configuration Management” ANSI American National Standards Institute EIA Electronic Industries Alliance

EIA-649 Presents Industry View 649 View MIL-STD View Buyer imposed Requirements Industry “Best Practices” employing CM principles #36, Para. 1 Page 1 This illustrates a major difference between MIL-STD-973 and EIA-649. You may end up doing all the same things -- but you arrive at the need for doing them in a different way The standard states what industry does for itself in managing a quality product. When the MIL STD was imposed, all the rationale ever needed was to say, “It’s required.” Now that crutch is gone. We must sell CM on it’s value adding aspects. One very necessary tool is going to be metrics. /We must learn to measure and determine value. Additionally 649 does not identify that activities are to be performed by a CM group, or any other specific group. Whether something in this standard should be done by engineering or the corner grocer, is not our purview. Responsibilities have to be assigned IAW the enterprises own policy. EIA- 649 Rationale for Performing CM Provides Benefit Avoids Cost Best Value

Allows common sense application of CM principles De-fuses the terminology issue using Aliases Sells CM on its Merits Example: Product attributes are defined Measurable Performance Parameters Both Buyer & Seller have common basis for acquisition & use of the product Purpose Benefits Allows common sense application of CM principles Robust, integrated CM systems Variability and flexibility Evolution to an automated data environment Digital data interchange and sharing Accommodation of commercial methods Selling on merits: CM makes sure that the product attributes are defined/documented. As a result: There are measurable performance parameters for the program and both buyer and seller have a common agreed-to basis for the acquisition and use of the product. Without this no procurement has a chance to be successful. Like the couple on the slide. Can you ident who is the buyer, the seller, the lawyer.

Fundamental CM Principles CM Planning & Management

CM Planning & Management
Purpose and benefits To assure that the appropriate CM processes and activities are applied To establish CM organizational responsibilities To determine the necessary resources and facilities To provide a basis for continuous improvement To enhance the maturity of the enterprises process

Configuration Management Processes (ANSI/EIA 649)
CM PLANNING & MANAGEMENT CONFIGURATION STATUS ACCOUNTING CONFIGURATION IDENTIFICATION Selection, tailoring, guidance, oversight Attributes, identifiers, baselines CM information & status CONFIGURATION CHANGE MANAGEMENT CM OF DIGITAL DATA #73, Para. 5 Page 15 p/o Fig 3. CM Process and also the “requirements” section of the book is subdivided into these topics SCM is integral to the Project CM Process; Accomplished through a modern automated SW engineering process CONFIGURATION VERIFICATION/AUDIT Manage changes Assure data integrity Verify performance & consistency

CM Planning & Management
EIA CM Principle #1 Plan CM processes for the context and environment in which they are to be performed and manage in accordance with the planning: Assign Responsibilities/Document procedures Train personnel Measure Performance; and Assess measurements/trends to effect process improvements Be Prepared! PRIN4. Prepare procedures to define how each configuration management process will be accomplished. Provide “how-to” Apply to a product or range of products Are at skill level of using personnel Evaluated for consistency with planning PRIN5.Conduct training so that all responsible individuals understand their roles and responsibilities and the procedures for implementing CM processes. >Training provides understanding of: Objectives & processes Organizational interfaces & interactions PRIN6. Assess the effectiveness of CM plan implementation and performance of the CM discipline with defined metrics (performance indicators). >Typical Metrics concern: Configuration Documentation releases Engineering Changes, Variances, Action Items >Data derived from metrics is used to: Understand & quantify problems and inefficiencies in products and processes Provide insight into how to make necessary corrections and improvements) >CM Metrics also indicate program performance

Consistent with ISO10007 - CM Plan
CM Planning & Management Consistent with ISO CM Plan 7.7 Configuration Management Plan A CMP provides the CM procedures that are to be used and states who will undertake these and when 8. Configuration Management System Audit Determine conformity of the applied CM practice to the procedures described in the CM plan 1. Plan 2. Document Procedures 3. Do what you plan

Fundamental CM Principles
Configuration Identification

Configuration Identification
EIA CM Principle #8 Configuration identification is the basis from which the configuration of products are defined and verified; products and documents are labeled; changes are managed; and accountability is maintained. Benefits are realized only if there is consistency between the product and the information about the product Product attributes are Defined in configuration documentation Achieved in the product Verified for consistency between product and documentation First define, then Achieve, then Verify Consistency Configuration Identification has three faces: A function or process The CM process that results in establishment of Baselines for configuration control A set of documents Current approved technical documentation for a configuration item consisting of specifications, engineering and associated lists, and software documentation Configuration Identifiers The set of numbers/letters that provide unique identity to each item of documentation, hardware or software

Purpose and Benefits of Configuration Identification
Determines structure of the product & documentation Defines performance, interface & other attributes Provides unique identity to product, components and documentation Prescribes identification marking Modifies product and document identifiers to reflect incorporation of major changes 5.2 Configuration Identification

Purpose/Benefits, continued
Maintains release control and baseline definition Provides reference for changes & corrective actions Correlates document revision level to product configuration Enables user to distinguish between product versions Enables service person to correlate product to instructions Correlates units to warranty/service life

Configuration Identification Process Activity Model
Contract Provisions Systems Engineering -Reqmts/Functional Analysis -Allocation & Synthesis Product Structure CM Planning Documented CM Process Configuration Items selected and Requirements allocated Determine CIs Appropriate Configuration Document Types and Baselines selected Select Config. DocTypes/ Baselines Logistics Maintenance Plan Document and Item Identifiers assigned Identify Documents & Items Approved Engineering Changes Configuration Documentation Approved, Released and Baselined for Change Control by the appropriate Configuration Control Authority Prin 10. The product composition (i.e., relationship and quantity of parts that comprise the product) is determinable from its configuration documentation. The product structure shows relationships among parts from top down to the lowest level. Each level includes:All parts, Quantity of each part, Associated configuration documentation The product structure is used to:Visualize relationships, Determine the level(s) to apply CM, Evaluate impact(s) of proposed changes. CIs are the basic units of configuration management; The THINGS we apply Configuration Management to. In EIA-649, CI is alias for product. EIA-649 defines a “Product” as “Anything that is used or produced to satisfy a need, for example, facilities, systems, hardware, software, firmware, data, processes, materials, or services. Approve, Release & Baseline Document-ation Configuration Documentation Configuration Identification Process Activity Model

EIA CM Principle #9 Configuration documentation defines the performance, functional and physical attributes of a product. Other product information is derived from configuration documentation. Two major sets of product information are: Configuration documentation Operational Information Configuration documentation is the product-defining documentation from which operational information and other product information is derived 5.2.1 Product information Page 21

The Product Information Universe
Distribution Configuration Documentation Operational Information Sales Operate Maintain Reqmts Design Configuration documentation includes: Requirements documentation Performance (capabilities) & functional boundaries Physical and functional interfaces Examples are: Specifications and Interface Control Documents Design documentation Physical and functional attributes completely defining design details Implements requirements documents Examples are: Engineering Drawings, Parts lists Operational Information Information necessary to use the product Operate Service and maintain Examples are: Operation Manuals, Service Manuals, Illustrated Parts Breakdown Manuals Build and Test Information Information to create the product and verify its performance Fabricate, manufacture, assemble, code, etc. Test the product for conformance to requirements Examples are: Manufacturing Operation Sheets, Tooling Drawings, Pseudo code Build & Test

EIA CM Principle #15 All documents reflecting product performance, functional, or physical requirements and other product information are uniquely identified so that they can be correctly associated with the applicable configuration of the product. Document identification enables retrieval Common identifiers include: Date Assigned alpha numeric Revision Type of document Title/subject Originator/Organization Customer’s contract or PO (if applicable) Document Identification page 24

EIA CM Principle #11 All products are assigned unique identifiers so that One product can be distinguished from other products One configuration of a product can be distinguished from another The source of the product can be determined The correct product information can be retrieved. 5.2.3 Product identifiers Page 22 Levels of Product identification Visible to customer/user during operation phase Identify product Identify spare/replacement parts Identify parts that have service life attributes or warranties Necessary for development, manufacture All parts comprising the product What this all means is that every part has to be identified.

EIA CM Principle #12 Individual units of a product are assigned a product unit identifier when there is a need to distinguish one unit of the product from another unit of the product. Typically by Serial Number Units serialized, e.g., when: Customer options Warranties Individual testing or screening Identifying individual units of a product

EIA CM Principle #13 When a product is modified, it retains its original unit identifier even though it’s part identifying number is altered to reflect a new configuration. It is essential that serialization take place using a non-changing identifier as a base Nothing degrades CM as much as two products with the identical part numbers and identical serial numbers!! P/N XYZ, S/N 1???

EIA CM Principle #14 A series of like units of a product are assigned a product group identifier when it is unnecessary or impractical to identify individual units but nonetheless necessary to correlate units to a process, date, event or test. Typically, by batch or lot number; In high production, a date code Enables unit to be correlated to test or process records for the group Also non-changing base Identifying Groups of units of a product page 24

EIA 649 Principle #16: A baseline identifies an agreed-to description of the attributes of a product at a point in time and provides a known configuration to which changes are addressed. EIA 649 Principle #17: Baselines are established by agreeing to the stated definition of a product’s attributes. Baselines provide Assurance of stability & consistency Common communication of product definition Ability to transfer authority 5.2.5 Baselines Page 25 Baseline = Agreed point of departure Initial baseline = Desired performance or definition of characteristics Intermediate baselines = allocation of requirements to sub-divisions of the product Eventually baseline = Detailed description of product Additional detailed baselines when different attributes are stable, greater detail is necessary, change authority is transferred N S W E

EIA 649 Principle #18: The configuration of any product, or any document, plus the approved changes to be incorporated is the current baseline. Product Configuration Baseline Requirements Requirements Baseline (Multi-Level) Requirements Implemented in Design Design Release Baseline Verified Product Configuration Requirements baseline Often a product of conception phase Departure configuration for definition phase Documents common understanding of what product is expected to do Subordinate (allocated) requirements baselines are established for major elements of complex products Design Release Baseline Once design information is released, it becomes part of the Design Release Baseline Process includes Initial release of design information Release of approved engineering changes Verification of product configuration Data base of current and historical information concerning the configuration of the product Product Configuration Baseline Normally occurs after verification that the product is in compliance with its requirements Defined by complete set of product configuration documentation Becomes basis for commitments Considered a “customer” baseline, where customer could be an internal change authority

EIA 649 Principle #20: For product interfaces external to the enterprise, establish an interface agreement and a mutually agreed-to documentation of common attributes. In Buyer/Seller relationship, interface definition is part of purchase agreement If no direct relationship exists, an interface agreement is negotiated Documentation = ICD Procedures may include an ICWG Let’s interface 5.2.7 Interface control page 28

Understanding the Levels of Interface
System Interfaces SYSTEM A CI a CI b CI c Assembly Part 12 P4 P3 P2 P1 Interfaces within CIs Interfaces Between CIs SYSTEM B A-B Same Contract SYSTEM C A-C Same Customer Different Contract CI c P4 Part from Supplier CI from Supplier Supplier Interfaces SYSTEM D A-D Different Customer Different Contract Understanding the Levels of Interface

Configuration Control (Configuration Change Management)

Configuration Change Management
EIA 649 Principle # 21 Changes to a product are accomplished using a systematic, measurable change process. Process includes Identifying need for change Documenting impact Evaluation & Coordination Incorporation of approved change Verification Also encompasses management of variances 5.3 Configuration change Management page 29/30

EIA 649 Configuration Change Management
Purpose and Benefits Enable change decisions to be based on knowledge of complete change impact Limit changes to those which are necessary or offer significant benefit Facilitate evaluation of cost, savings & trade-offs Ensure customer interests are considered Provide orderly communication of change information Preserve configuration control at product interfaces Maintain and control a current configuration baseline Maintain consistency between product and documentation Document and limit variances Facilitate continued supportability of the product after change

Current Baseline New Current Baseline Change Identification Need for Change Approved Change Evaluation & Coordination Documented Change Request 5.3 Configuration change Management page Fig. 7 Model is valid for Changes to current requirements, design release and product configuration baselines Changes resulting from Discovery of a problem Suggestion for product improvement or enhancement Customer request Condition dictated by the marketplace Public Law Internal change management or products under customer configuration control EIA Change Management Process Model Implementation & Verification

Configuration Control Process Activity Model
Contractual Provisions Govt. Need for Change Request for ECP Government Configuration Control Initiation Need for Change to Government Baseline Current Configuration Control Authority Approved Configuration Documentation (Current Baselines) Status & Configuration Information Documented CM Process C CM Mgmt Communication Contractor- Responsible Change Ident, Documentation & Disposition Contractor Need for Change Contractor Configuration Control ECPs, RFDs Approved ECPs, RFDs & Implementing Direction/ Authorization C Government Configuration Control Evaluation & Disposition (Fig. 4-4) Configuration Control Process Activity Model

EIA 649 Principle #22 Each change is uniquely identified Objectives of change identification Description and impact sufficient for evaluation Choose appropriate format Provide unique identifier for the change 5.3.1 Change Identification Page 31

EIA 649 Principle #23 Changes represent opportunities for improvement Changes initiated to: Provide new capabilities Enhance product support Insert technology Effect improvements Correct defects or deficiencies Reduce cost, improve efficiency Requesting Changes Summary of the various reasons for change given in the text Judgments either by “requester” or “sponsor” Need for requested change Basic scope and description Definition of impacts Desired effectivity Urgency and importance

EIA 649 Principle #24 Classify changes to aid in determining the appropriate levels of review and approval. Tabulated “best practice” factors differentiate between: Major & Minor changes Requirement for external customer review in addition to internal review Classifying Changes page 32 Best practice factors are characteristics of an engineering change Table (Fig 9. in the standard) shown 3 slides from now.

EIA 649 Principle #26 Consider technical, support, schedule, and cost impacts of a requested change before making a judgment as to whether a change should be approved for implementation and incorporation in the product and its documentation. Change evaluation and coordination process Reviewing the preliminary impact assessments Determining change effectivity Establishing the cost/price Dispositioning the change I thought I knew it all ! Change Evaluation and Coordination page 34

EIA 649 Principle #27 Determine all potential effects of a change and coordinate potential impacts with the impacted areas of responsibility. Impact Assessment Details what is affected Ensures that all potential effects are known Is essential to determine effectivity Change Impact Assessment page 35

Change Boards are a common means of achieving coordination necessary for impact assessment and change evaluation Change Board characteristics: Chaired by someone with authority to commit the resources of the enterprise to implementing the change Members represent functional activities or product development teams... and have authority to commit the group they represent Agendas & documents ....distributed in advance Board direction & decisions ...documented and disseminated Board actions commonly accomplished electronically Change Impact Assessment page 35

I like this date, it’s my birthday. EIA 649 Principle #28 Change documentation delineates which unit(s) of the product are to be changed. Change effectivity includes production break-in and retrofit/recall, as applicable. A changed product should not be distributed until its support and service areas are able to support it. Effectivity determination requires Knowledge of lead times Balancing of many factors EIA 649 Principle #29 Change Effectivity Determination page 36 Urgency Parts/materials on hand Need to support multiple configurations Timing with respect to: Customer needs & preferences Competition Marketing strategies, etc. Where’s the instructions?

Effectivity delineates which units are to be changed Effectivity is commonly expressed by Product unit identifying number (e.g., serial number) Production date Product group identifier (e.g., lot, batch) Model Year Model Designation Version number Change Effectivity Determination page 36

EIA 649 Principle #30 The decision maker is aware of all cost factors in making the decision. Prerequisites: Impact assessment Effectivity CM process identifies Immediate cost of change Expected cost/savings in future All cost factors are considered Change Cost/Price Determination Page 36

EIA 649 Principle #31 Change approval decisions are made at an appropriate organizational level with the authority to commit necessary resources to implement the change. Approval authority delegated to different levels, based on classification As the life cycle progresses, authority typically transitions toward higher fiscal responsibility Each organization establishes its own change authority levels Change Approval Authority page 36 Each organization establishes change authority levels taking some or all of the following factors into consideration: The phase of product life cycle Technical, cost and schedule impacts The Customer involvement Product attributes subject to formal control Organizational structure & relationships Various levels at which change authority is vested The period of performance during which that level of control applies

EIA 649 Principle #32 Implement an approved change in accordance with documented direction approved by the appropriate level of authority. Planning for change implementation is Initiated during change evaluation Detailed after change is approved Implementation involves Release of new or revised configuration documentation and other affected product information Change incorporation into product Update of operation and support elements Change Implementation and Verification Page 37 Change implementation & verification can be very simple or can involve many complex and inter-related considerations

EIA 649 Principle #33 Verify implementation of a change to assure consistency between the product, its documentation and its support elements. Verification may be means of: Detailed audit of product to documentation Validation of installation or modification instructions Validation of operation and maintenance instructions Testing or, a simple inspection Product Product Information Change Implementation and Verification p37/38

EIA 649 Principle #34 If it is considered necessary to temporarily depart from specified baseline requirements, a variance is documented and authorized by appropriate level of authority. Products that incorporate a known departure from requirements should not be delivered to a customer unless a request for variance has been documented and authorized. Authorized variances do not constitute a change to configuration documentation Who sez I’m different? Change Management Process applied to Variances page 39

ANSI/EIA-649 Request for Variance
The term “variance” is the alias for what is commonly referred to as Deviation Waiver Variances are requested Prior to manufacture During manufacture After manufacture Deviation!! Deviation, I think! Poor Form Waiver... NO FORM!!!

Configuration Status Accounting

Configuration Status Accounting
EIA 649 Principle #35 An accurate, timely information base concerning a product and its associated product information is required throughout the product life cycle. CM effectiveness is linked to information flow Information collected while performing CM activities CSA correlates, stores, & maintains an organized collection of information CSA provides readily available views 5.4 Configuration Status Accounting page 39 EIA 649 Principle #36 Configuration information, appropriate to the product, is systematically recorded safeguarded, validated and disseminated. Decisions about information to be captured based on factors such as: Nature of the product Environment in which it will be operated Anticipated volume & complexity of change activity Information needs of the Customer CSA provides access to information about: The Product Configuration Documentation Operational Product Information Product Configuration The CM process CSA satisfies both seller and customer needs Everything you ever wanted to know, but were afraid to ask!

Configuration Status Accounting Tasks
Contractual Provisions Configuration Status Accounting Tasks Approved Configuration Documentation Change Identification, Documentation, Disposition Configuration Verification Change Verification & Validation Action Items Record the current approved configuration documentation and configuration identifiers associated with each System/CI(s). Record and report the status of proposed engineering changes from initiation to final approval to contractual implementation Record and report the status of all critical and major requests for deviation which affect the configuration of a system/CI(s). Record and report the results of configuration audits to include the status and final disposition of identified discrepancies and action items Record and report implementation status of authorized changes Provide the traceability of all changes from the original released configuration documentation of each System/CI(s) Report the effectivity and installation status of configuration changes to all system/CI(s) at all locations, including design, production, modification, retrofit and maintenance changes Record the digital data file(s)identifiers and document representations of all revisions/versions of each document and software which has been delivered, or made accessible electronically, in support of the contract. Status Configuration Information Performance Measurement CSA Activity Model Communication Automated CM System based on CM Data Model & Data Element Dictionary Documented CM process CM Planning

Configuration Status Accounting
EIA 649 Purposes and benefits Enables retrieval of information concerning change decisions Supports inquiries concerning future planning of design changes, investigation of design problems, warranties, shelf and operating life calculations, etc. Access to complete configuration information on a product, any individual product unit, or group of product units Access to accurate identification of each delivered product unit Improves capability to identify, produce, inspect, deliver, operate, maintain, repair, and refurbish products Enhances availability of accurate information on spare parts and maintenance support Source for configuration history 5.4 Configuration Status Accounting Page 39

Configuration Status Accounting over a System Life Cycle
Supporting Physical Design Performance Definition Solution Configuration Element Concepts I STATUS STATUS ACCOUNTING CAPABILITY II III Concept Studies Prog. Def & Risk Reduct . Eng & Mfg Dev Prod, Field/Deploy & Op Support SYSTEM/CI LIFE CYCLE ACCOUNTING OBJECTS Mission Need CSA evolves over the product life cycle capturing more detailed information and enhancing its value as an information resource Configuration Status Accounting over a System Life Cycle

Configuration Verification and Audit

Configuration Verification & Audit
EIA 649 Principle #39 Verification that a product’s requirement attributes have been met and the product design meeting those attributes has been adequately documented is required to baseline the product configuration. Configuration verification and audit establishes that: The performance requirements have been achieved by the design, and The design has been accurately documented in configuration documentation We did it! 5.5 Configuration Verification and Audit page 44

Purpose and Benefits Ensure the product design provides the agreed to performance capabilities Validate the integrity of the configuration documentation Verify the consistency between a product and its configuration documentation Determine that an adequate process is in place to provide continuing control of the configuration Provide confidence in establishing a product baseline Ensure a known configuration as a basis for operation and maintenance instructions, training, spares and repair parts. 5.5 Configuration Verification and Audit page 44

Configuration Verification and Audit Activity Model
Contractual Provisions Verification, Validation, Action Items (To CSA) Status (via CSA) VERIFICATION & AUDIT PLANNING* Confidence; Verified Product & Validated Process • Verification Reqd Audit Schedule Status & Config Info (From CSA) Documented CM Process C CONFIGURATION VERIFICATION PROCESS • Verified Configuration Verified Changes Open Items (Action Items) (To CSA) Approved Config Doc. Mfg. & Engrg. Tools Documentation • Agenda Facilities, Tools Personnel Documentation Availability of Audit Objects Certifications PRE- AUDIT AUDIT Audit Report Verification, Validation, Action Items Physical CI /CSCI Test Results POST-AUDIT Configuration Verification and Audit Activity Model

Change Implementation and Verification
Authorization to implement approved change Update Config Documentation Revise Mfg/Prod/Test Instructions Accomplish & Verify Change Product Mfg & Retrofit Other Affected Support Elements Operating & Maintenance Instructions Update Ordering Data * * Orders for • Support equipment Trainers Training Spares Tech. Manuals Change Implementation and Verification

EIA 649 Principle #40 Verification that a design achieves its goals is accomplished by a systematic comparison of requirements with the results of tests, analysis or inspection. Incremental Systematic Incorporate in process flow Requirements flow-down tools Matrix (Results vs Requirement) Design and Document Verification page 44

EIA 649 Principle #41 Documentation of a product’s definition must be complete and accurate enough to permit reproduction of the product without further design effort. The design output must be captured and documented adequately Documentation content and formality influenced by future procurement and maintenance needs Verifying the documentation assures that it is adequate for its intended purpose Design and Document Verification page 44

EIA 649 Principle #42 Where necessary, verification is accomplished by formal configuration audit. Resources and material to perform functional and physical audit include: Audit plan and agenda Adequate facilities and unencumbered access Availability of personnel Applicable documentation, schedules, test results, inspection records, etc. Tools and inspection equipment Isolation of the product and parts to be reviewed Configuration Audit page 45

EIA 649 Principle #43 Periodic reviews verify continued achievement of requirements, identify and document changes in performance, and ensure consistency with documentation. Ongoing production and processes, are reviewed periodically to determine continued suitability Operation of products or facilities are reviewed to identify and monitor changes or degradation of performance Methods range from manual inspection to statistical process control and trend analysis Continuing Performance Audits and Surveillance page 45

Measuring and Benchmarking CM Practices
Process Assessment

Process Assessment Why Process Assessment?
Quantify process as baseline for measuring improvements/Benchmarking Competitiveness; Product Quality; Process Improvement Options to evaluate the effectiveness of CM Process Established Assessment Framework SEI SW-CMM EIA-731 Capability Maturity Model Integration (CMMI) Develop Internal Assessment Immediate Benefits See where your people think improvements can have major impacts Quantify where your process is right now Baseline to measure improvement efforts against SW-CMM Developed by SEI, Staged Model, Focused on SW Development Process EIA-731 Several sources, Continuous Model, All Systems Engineering Elements Capability Maturity Model Integration (CMMI) Project Reduce redundancy & eliminate inconsistency when using separate stand alone models Use models that integrate disciplines such as Systems Engineering & S/W Engineering Same structure & similar output models as existing CMMs

Process Assessment Capability Maturity Model (CMM)
Yardstick for judging maturity of an organization’s process Identify Areas for Process Improvement CMM Components Model (Based on Documented Standard) Framework for Process Definition Process requirements (“What” not “How”) Key elements of an effective process Assessment Process - - “How we measure it” Process Elements - - “What you do” Maturity Elements - - “How well you do it” How do we define “CDM” Process Rqmts ANSI/EIA-649 National Consensus Standard for Configuration Management ANSI/ASQC Q9001 (para 4.5) Document & Data Control DoD Handbook - Data Management Guidance The Approach Capability Maturity Models should be more closely aligned with documented standards/requirements for CM and DM ANSI/EIA National Consensus Std for CM ISO & DoD DM Handbook Industry Best Practices G-33 Task to bring these requirements into CMMI development

Internal Assessments More focused and detailed than CMM’s
Detailed Internal Assessment Model EIA Process Analysis Tool (PAT) Ver 1.4 Questionnaires and Scoring Sheets Assessment Plan / Schedule Training Material (Team & Participants) Briefing material (Opening & Findings) Final Report Internal or Subcontractor Assessment Checklists

Product Structure Evaluation Checklist
Is the product (System/CIs) structured into a rational hierarchy? Can the composition of each System/CI be determined from the configuration documentation? Are subordinate CIs identified at a reasonable level for: Specification of and measurement of performance? Management of the effectivity of changes? Obtaining spare parts using performance or design documents?

Measuring and Benchmarking CM Practices

Does someone do it better?
Benchmarking Process Plan Establish Team Identify What is to be Benchmarked Identify Comparative Companies Determine Data Collection Method Collect Data Analyze Determine/quantify Performance Difference Set Improvement Goals Project future performance level and timeframe Establish Functional Goals Develop Action Plans (including metrics) Gain Acceptance Implement and Monitor Progress Re-assess Include people/functional experts who are involved in the process What is the product or service? What organizational entity is recognized as the BEST and why? What do our current processes fall short Project Future Performance Levels - “close the gap” or “leapfrog” State achievable operational principles What is the potential return on investment Communicate Benchmark Findings, Goals and Action Plan and Gain Acceptance (and of course – Resources) Demonstrate findings are correct and based on valid data?

Configuration Management Based on Best Practices

Similar presentations

Presentation on theme: "Configuration Management Based on Best Practices"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Configuration Management Based on Best Practices

Similar presentations

Presentation on theme: "Configuration Management Based on Best Practices"— Presentation transcript:

Similar presentations

About project

Feedback