Configuration Management Body of Knowledge The Complete Text

$ This page is automatically generated from the CMBoK page and its corresponding CMBoK chapter pages
for the purpose of conveniently viewing and printing as a single document
-- BradAppleton? - 13 Mar 2003 :

---

Table of Contents #TopOfPage

---

Section I: The Configuration Management Framework

---

Chapter 1: Introduction

Overview

The Configuration Management Body of Knowledge (CMBoK) is an inclusive term that describes the sum of knowledge within the profession of Configuration Management. It includes what is known as Software Configuration Management and Hardware Configuration Management. As with other professions, the body of knowledge rests with the practitioners, technicians, and academics that apply and advance it. The full Configuration Management Body of Knowledge includes knowledge of proven traditional methodologies that are widely applied, as well as knowledge of innovative and advanced practices that have seen more limited use. It includes both published and unpublished material.

This chapter defines and explains several key terms and provides an overview of the rest of the document.

-- SmKershaw? - 07 Feb 2003

(It seems redundant to include the sections here when they are generated automatically just above) -- NealFreeman? - 13 Mar 2003 {I'm not sure what Neal is driving at here. This section works the same as the others. -- SmKershaw? - 09 Apr 2003 }

1.1 PURPOSE OF THIS GUIDE

A project’s success is highly dependent on effective Configuration Management (CM). CM is necessary to enable a large team to work together in a stable and controlled environment, yet still have the flexibility needed for creative work. All too often, CM is viewed only as a costly and time-consuming effort to be either ignored or thrown together at the last minute. However, not doing CM guarantees that a project will be plagued by chaos, errors, permanent damage, low productivity, and unmanageable product evolution. A project in this sense is the sum total of all work carried out to create a product, whether software or hardware. Projects are normally organizationally defined and established to create, develop, deploy, and maintain products. -- SmKershaw? - 15 Feb 2003

Configuration Management concerns the whole life-cycle, which may or may not involve several consecutive and parallel projects. Many projects fail because Configuration Management is not taken seriously enough as an intrinsic factor. It is placed too low organizationally in the project/organization and not given enforcement authority. The purpose of CM is to ensure that the controlled items have life beyond the project. This also has an impact to the way CM activities are organized; CM responsibility is often carried by the line organization, because it cannot be left for each project separately.

Naturally, CM implementation that does not provide any support to the project's work is doomed to fail. CM cannot be added on top after the project is finished. CM activities must be carried out throughout the project, from beginning to end. Those activities must be meaningful and reasonable to all project members. This is the key to the success of CM, and also an ingredient of the success of the project. Constricting the mission of CM to portions of the project/organization scope rather than the whole can be an expensive mistake.

Above to paragraphs Edited and incorporated into text - -- SmKershaw? - 15 Feb 2003 { Edited and slightly reworded. } -- CarildaAThomas? - 15 Feb 2003

There are numerous industry and military standards (i. e., US industry standards ANSI/EIA-649 “National Consensus Standard for Configuration Management,” EIA-836, “Consensus Standard for CM Data Exchange and Interoperability”, military standards like MIL-STD-973 “Configuration Management” or MIL-STD-2549 “Data Management”, MIL-HDBK-61 ”Configuration Management Guidance” or the NATO Allied Configuration Management Procedures “ACMPs 1-7” and ISO 9000 standards) that can be referenced as guides for establishing an effective and efficient CM process. Instituting CM Best Practices is the key to the successful development and maintenance of a product.

The primary purpose of this document is to identify and describe that subset of the CMBoK that is generally accepted. Generally accepted means that the knowledge and practices described are applicable to most configured environments most of the time, and that there is widespread consensus about their value and usefulness. Generally accepted does not mean that the knowledge and practices described are or should be applied uniformly on all configuration efforts; the Configuration Management team is always responsible for determining what is appropriate for any given configuration effort. -- SmKershaw? - 15 Feb 2003

This CMBoK was created to provide information to those interested in Configuration Management and/or those assigned the responsibility for Configuration Management, to implement and maintain the application of product and data Configuration Management to hardware, software and firmware materiel items, as well as the respective documentation, in each phase of their life cycle, by consolidating Best Practices from the most common Configuration Management documents.

-- DirkWessel? - 09 Feb 2003 {edited by -- SmKershaw? - 15 Feb 2003 )

This document provides a basic reference for anyone interested in the profession of configuration management. This includes, but is not limited to:

• Executives
• Project Managers
• Team members
• Other managers
• Educators
• Consultants

This document is also to be used by the Configuration Management community as a basic reference about Configuration Management knowledge and practices for its professional development programs including:

• Certification of Configuration Management Professionals (CM Cert)
• Accreditation of educational programs in configuration management.

-- SmKershaw? - 07 Feb 2003

1.2 WHAT IS CONFIGURATION?

According to The Random House College Dictionary (1980), configuration is defined as "1. the relative disposition of the parts or elements of a thing. 2. external form, as resulting from this; conformation." A configuration is established through analysis performed by people. A configuration is constrained by limited resources. A configuration is identified, controlled, reported, and audited. Configuration environments are often established as a means of achieving an organization's strategic plan or an organization's project plan. -- SmKershaw? - 07 Feb 2003

The PMI PMBOK® states that "projects are undertaken at all levels of the organization." Configuration efforts are as well. Unlike projects per se, configuration efforts do not involve thousands of configuration professionals. Rather, configuration efforts may involve a single person or perhaps a dozen being led by a configuration professional. Configuration efforts can have durations from a few months to several years. The time required to set up a configuration environment does take time and it is best to plan on having one at the beginning of a project as compared to attempting to establish one part way through a project.

Configuration efforts may involve a single entity or project within an organization or may cross organizational boundaries. Configuration efforts are critical to the realization of the performing organization's business strategy because it is through configuration efforts that strategic plans and projects are implemented. Here are some examples where configuration efforts are used:

• Developing a new product or service
• Effecting a change in structure, staffing, or style of an organization
• Designing a new transportation vehicle
• Developing or acquiring a new or modified information system
• Constructing a building or facility
• Building a water system for a community

-- SmKershaw? - 07 Feb 2003

1.3 WHAT IS CONFIGURATION MANAGEMENT?

There are many different potential definitions. The IEEE Standard 828-1990 defined Configuration Management "as a formal engineering discipline that, as part of overall system configuration management, provides the methods and tools to identify and control the (hardware/)software throughout its development and use." But in today's fast paced world, this definition falls short.

("Configuration Management" is included as part of the definition of "Configuration Management" here - is this a definition of Software Configuration Management - the brackets around the word hardware would suggest so - in which case the IEEE Standard must contain a complete definition somewhere else?) -- NealFreeman? - 17 Mar 2003 {Neal, are you suggesting that we should define the word 'hardware'? Or am I missing your point (again). Perhaps if you offer an alternative to consider...-- SmKershaw? - 09 Apr 2003 }

Like PMI's Definition of Project Management in the PMBOK®, Configuration Management is the application of knowledge, skills, tools, and techniques to configuration activities to meet project and organization requirements. But unlike Project Management, Configuration Management is accomplished through the use of processes such as: Planning, Identification, Controlling, Communicating, Executing, Negotiating, Reporting, and Auditing. Like Project Management, Configuration Management has a lot of processes that are iterative in nature, too. This is in part due to the existence of and the necessity for progressive elaboration in a Configuration Management effort throughout the life cycle; i.e., the more you know about your configuration, the better you are able to manage it. -- SmKershaw? - 07 Feb 2003

Knowledge about Configuration Management can be organized in many ways. This document, has two major sections and __ chapters. -- SmKershaw? - 07 Feb 2003

Configuration Management is the process of managing the full spectrum of an organisation's products, facilities and processes by managing all requirements, including changes, and assuring that the results conform to those requirements. A project’s success or lack thereof, is highly dependent on CM, the way CM is performed and the affects on risks regarding those projects.

Samaras and Czerwinski in the preface to their text Fundamentals of Configuration Management, published in 1971, define Configuration Management as "the discipline of ensuring that equipment or hardware meets carefully defined functional, mechanical, and electrical requirements and that any changes in these requirements are rigidly controlled, carefully identified, and accurately recorded." -- NeilSteeman? - 16 Feb 2003 {Edited by -- SmKershaw? - 23 Feb 2003 )

(Contribution moved to Appendix A -- CarildaAThomas? - 24 Feb 2003)
-- NeilSteeman? - 22 Feb 2003

1.4 HOW DOES CONFIGURATION MANAGEMENT RELATE TO OTHER MANAGEMENT DISCIPLINES?

Much of the knowledge needed to perform Configuration Management is unique to the profession (e.g., version control, builds, parts identification). However there is overlap into other management disciplines.

The relationship between Configuration Management and Quality Assurance has oscillated back and forth over the last 20 years. Nearly 20 years ago, Configuration Management was limited primarily to version control, library maintenance, builds all within a predefined set of Standards, Plans and Procedures. Back then, Quality Assurance was put in the position of monitoring the activities of Configuration Management while assuring that the library contents were legitimate for engineers to use.

As recently as 1990, the roles began to change as the Standards changed. Configuration Management began to take a more vital role in the scheme as compared to Quality Assurance. Eventually, the standards and practices changed to have Configuration Management responsible for most things relating to a project, while Quality Assurance declined in perceived importance.

Today, Quality Assurance is still responsible for the monitoring of the process, the identification of problems, providing guidance for change, and to assure that the documentation agrees with the configured items. One might ask how does Quality Assurance differ from Quality Control or Quality Test. It is simple. Quality Assurance doesn't test or control - it assures that all appears to be proper and going according to plan. Quality Control and Quality Test are self defining and don't assure, they identify problems when they exist.

Project Management and Configuration Management have some common areas of responsibility. Project Management is hard pressed to be successful without good Configuration Management. And it is largely because of the work of the Project Management Institute that the scope of Configuration Management has been made to encompass so much more than it did 20 years ago. Now, projects have to configure requirements, design, project planning records, processes, problem reports etc. It is Configuration Management that facilitates and services the needs of project managers. -- SmKershaw? - 07 Feb 2003

1.5 RELATED ENDEAVORS

There are, obviously, lots of organizations without any official resource dedicated to Configuration Management. There are those organizations that establish Configuration Management on only the sub-project level. There are organizations that elect to establish Configuration Management at the project level, and then there are those organizations that address Configuration Management at the corporate level. It is also obvious that Configuration Management can exist in any number of organizational levels.

In recent years, the official standards of the past have been made obsolete. Projects are frequently in the unfortunate position of having to set standards without any guidelines. Therefore, each configuration effort is potentially radically different. There is a need for a common approach to Configuration Management, not just at the knowledge level, which this document is attempting to establish, but a common methodology across projects in a given organization. This has many benefits. Start-up cost savings of new projects in environments where both the methods and the tools are identical to existing efforts is huge. -- SmKershaw? - 07 Feb 2003

Can we make a statement like the one in this last sentence without qualifying it with an example or a reference? -- NealFreeman? - 17 Mar 2003 {As an example you would like me to site a source of a survey or something like that, right? I cannot site a specific survey, because I have not looked for one. However, I believe there are mountains of evidence in 'common' that shows that standardization saves time, resources and costs. It borders on common sense. Doesn't it?-- SmKershaw? - 09 Apr 2003 }

1.6 TAILORING

The effectiveness, and therefore the success of a CM implementation relies very much on the adaptation of the different CM requirements to the specific project. The main CM functions cannot be used independently. Each main function should be used; however, the details have to be tailored to suit the life-cycle phase, the complexity, the size, the intended use, the degree of criticality, and the ability to support of the configured itesm. -- DirkWessel? - 09 Feb 2003 {-- NealFreeman? - 17 Mar 2003} {Deleted phrase "joint and combined interoperability" and edited just a bit at Neal's suggestion. Hope you don't mind. -- SmKershaw? - 09 Apr 2003.

(Chapter split) -- CarildaAThomas? - 18 Feb 2003

---

Chapter 2: The Configuration Management Context

Overview

In this chapter the Configuration Management context is explored. Two examples, acquisition and development life cycle diagrams are illustrated and discussed. The phases of the life cycle are identified with discussions concerning impacts upon it by Configuration Management. The key players in the configuration organization are described along with how the organization can influence configuration activities. Certain general management skills are required and described. -- SmKershaw? - 11 Feb 2003 added which life cyle diagrams are discussed. KjMangan? - 18 Feb 2003

2.1 ACQUISITION LIFE CYCLE PHASES AND CONFIGURATION MANAGEMENT

Configuration Management operates in all phases of the product’s existence, starting from the Conception to disposal of the hardware, software and firmware items.

The framework in which the different phases occur is called the “Acquisition life cycle”. The generic model for this process is illustrated in Figure 1.

* Acquisition Life Cycle Phases:

Figure 1 Acquisition Milestones and Phases

The life cycle process consists of decision points, or milestones, and periods of time, or phases. The project will approve passage from one phase to the next by officially accepting the phase upon completion of a successful milestone review.

2.1.1 Phase 0, Concept Exploration Phase

The concept exploration phase, Phase 0, is the first phase of a product’s life cycle. If it occurs at all, it typically consists of competitive, parallel short-term concept studies performed to investigate alternative operations and design concepts. The purpose is to identify, define, and evaluate the advantages/disadvantages, risks, costs, etc. of promising operational concepts and product design alternatives. The studies result in project characteristics and costs of total systems as reflected by their conceptual designs. The results are reviewed at the Milestone I decision point where promising candidates may be selected for further definition and development. The design characteristics of the selected alternatives generally provide a functional baseline of the system.

This phase is also considered as the Inception phase or Business Opportunity Feasibility Study and Business plan phase. -- DenisRoy? - 17 Feb 2003

2.1.2 Phase I, Program Definition and Risk Reduction Phase

Phase I is used to further define and refine the operational concept or concepts and those alternative design approaches determined by the Milestone I decision process to be the most promising. The functional baselines are further decomposed into their lower-tiered subsystems. The performance requirements of the product are then allocated down to the lower level functions (allocated baseline).

This phase is also know as the Analysis and is part of the Elaboration phase. -- DenisRoy? - 17 Feb 2003

2.1.3 Phase II, Engineering and Manufacturing Development Phase

Phase II of the acquisition process is used to complete a stable design for a product which meets the performance requirements and is producible, supportable, and affordable. Product capabilities are demonstrated through testing to validate design assumptions, and deployment planning is initiated. Low rate initial production is begun during this phase to provide the minimum quantities required to support operational testing and other design validation activities and to establish an initial production base for the product. The allocated baseline of a product is transitioned into a full product baseline during this phase.

This phase is also known as the Design phase and is defined as the Elaboration phase with the Analysis phase. -- DenisRoy? - 17 Feb 2003

2.1.4 Phase III, Production, Fielding/Deployment, and Operational Support Phase

Phase III includes all design activities needed to:

• Correct deficiencies identified during Phase II test and evaluation activities and low-rate initial production.
• Produce and deploy a product.

Support activities respond to changes resulting from correction of noted deficiencies and other product baseline changes made to enhance producibility or otherwise improve the product. Additionally, they prepare for transition of the product to operations. Phase III is used to achieve and sustain an operational capability that satisfies mission needs.

This phase consist of the Construction and Transition phases together or Implementation and test phases. -- DenisRoy? - 17 Feb 2003

-- DirkWessel? - 09 Feb 2003

2.1.5 Pros and Cons of this Cycle

This model is great for static projects such as building a submarine or an airplane, and it is probably well suited to projects based primarily on acquisition rather than creation. Although these types of projects (generally government-funded) may consume the bulk of money spent. Organizations that manage these types of projects generally have a well-defined, if not entrenched, concept of CM with a large force reasonably well-trained in the particular CM implementation. This Life Cycle Model does not port well to today's dynamic development environments. -- CarildaAThomas? - 12 Feb 2003 {Edited. -- SmKershaw? - 18 Apr 2003 }

2.2 DEVELOPMENT LIFE CYCLE STAGES, TRANSITIONS AND CONFIGURATION MANAGEMENT

The traditional description of System Life Cycle, often known as the Waterfall model, is characterized by specific stages, generally summarized as:

1. Concept exploration
2. System architecture and risk definition
3. System detailed design and documentation
4. Development and unit testing
5. Integrated testing
6. Deployment
7. End of life

Each stage has a definite completion point, a Milestone, at which the current stage is considered finished and the next stage is entered. If the integrated testing stage fails, it may be necessary to back up into one of the earlier stages, or the project may have to be abandoned.

This type of project is expected to span years, and, according to sources such as Archwise Architectural Consulting and AntiPatterns author William J. Brown:

• Almost one third of all software projects are cancelled
• Two thirds of all software projects have cost overruns greater than 200%
• 80% of projects are deemed failures because they have not met one or more major goals

In contrast, the competitiveness of the various industries may demand a turn-around time measured in weeks, not years, and even firmware-based hardware projects may expect to have revisions to ship before End-Of-Life. These demands cannot be satisfied by a Waterfall model; instead they require a continuous development model comprised of Stages with Transitions. Traditional projects can be mapped onto this model, but it also allows for incremental development, quick release schedules, and it demands tight integration with Configuration Management at every Stage and Transition. A diagram of such a model is given in Figure 2. {Edited to make more generic -- SmKershaw? - 18 Apr 2003 }

Figure 2 - Life Cycle Model

{You included End-of-Life or product retirement in the list of stages for the Waterfall model, but not in your diagram nor below in your Stages description. There are CM tasks associated with product retirement so for completeness it should be included. -- HelenHogan? - 20 Feb 2003}

In the incremental model, different increments of the overall project can be at different stages in the Life Cycle, and transitions take place according to the defined Configuration Management process.

2.2.1 Life Cycle Stages

Each Stage has some subset of the project team working on it, some set of Configurable Items to manage, and will follow certain processes of the Configuration Management plan that is in place.

2.2.1.1 Stage 1: Requirements Definition and Validation Criteria

A requirement is a well-defined statement of a testable or provable desired result that will cause the creation or change of some element(s) of the project. Requirements need to be documented, often by a Subject Matter Expert(s) on the project team. Validation criteria must be determined for each requirement so that its fulfillment can be tested, a function of either QA, The SME or both. Requirements and validation criteria are the Configurable Items that need to be managed at this stage.

2.2.1.2 Stage 2: Architecture and Design

Traditional models may split these two functions, while many Agile and RAD methodologies envision them as proceeding more or less in parallel. Project team members will be architects, analysts and designers. The Configurable Items will be the models and the detailed design documents. Some UML tools produce executable (testable) models; in this case, the test results will also be Configurable Items.

{Use case documents, from which QA tests are derived, are also generated during this stage and are also Configurable Items. -- HelenHogan? - 20 Feb 2003}

2.2.1.3 Stage 3: Development and Unit Test

At this stage, the different development methodologies diverge radically. At one pole, Extreme Programming dictates that each developer should create incremental tests corresponding to requirements (strictly, story outcomes) and perform them regressively as the development proceeds. At the other pole, unit tests will have been developed, probably by QA, in Stage 1, and will be executed in a development "sandbox" different from the individual developer's workspace and containing the most current development versions, possibly after a nightly (or regular) build. This sandbox is maintained by the CM team, and it is here that development check-ins will reside. There probably exists every imaginable permutation in between. The project team members are the developers and possibly QA. If there is a nightly build, this may be the responsibility of QA, or of the CM team. Configurable Items will be the developed entities (code, firmware, components, etc.), and results of the nightly/regular build.

{Configurable Items also include any compilers, applications, tools used to create the nightly/regular builds, as well as any third party components linked into or packaged with the build output. -- HelenHogan? - 20 Feb 2003} {I put an etc. in the list, because the term is already defined in the glossary. I hope that's acceptable. -- SmKershaw? - 09 Apr 2003 }

For smaller projects, or for defect fixes, this Stage may sometimes be bypassed in an effort to keep costs down, but there is a risk. {How is this possible? -- HelenHogan? - 20 Feb 2003} {modified to address your concern. Is this ok to you? -- SmKershaw? - 09 Apr 2003 }

In most cases, this Stage should also include rudimentary integration, installation and configuration testing performed by the developers. Stage 4 QA testing validates that the product works as designed, not that it works at all. -- HelenHogan? - 20 Feb 2003

2.2.1.4 Stage 4: QA Build, Integration/Regression Testing

Where Stage 3 had a "dev" sandbox, this Stage has a "QA" or "test" sandbox. Any components not previously integrated will be integrated here. Unit tests will be regressed, system tests (integration tests) will be performed, and the system will be both verified and validated. That is, it will be proven to perform correctly and according to specifications. Performance testing, destruction testing, non-functional requirement testing (such as security) belong to this stage. The team members will be QA, and the Configurable Items will be any tests not already configured, and all relevant test results.

2.2.1.5 Stage 5: Deployment/Production

Deployment results in an actual release version; there must be a Release Description that enumerates all Configurable Items from the previous stages, as well as the versions of any tools used to create the deployed product, where applicable. Team members for deployment will vary according to the actual product.

2.2.2 Life Cycle Transitions

Transitions of development sets, which may be software or a combination of software and hardware, should occur according to and controlled by the processes within the Configuration Management plan.

Traditional development models can be emulated by only recognizing the forward moving arrows in Figure 2 (those pointing downward), and inserting a "Milestone" event next to each arrow. Any time an upward-pointing path is followed, the whole development effort is brought back to that stage, and a serious project problem is likely.

Upward-pointing arrows in Figure 2 represent an action by some team member at the Stage where the arrow originates. The project manager or some part of the project team will determine the transitions from Stage 1 to Stage 3, but thereafter, forward-moving transitions (3 to 4 and 4 to 5) are managed by the CM team.

2.2.2.1 Transition A: Original Requirements

This is a transition in the sense that, before there were requirements, there was no project. It is included here for completeness.

2.2.2.2 Transition B: Enhancement/Modification Request

This transition is triggered by one of two events. A deployed product may have planned enhancements (revisions, project release phases, increments in development). Or, the existing requirements definition as embodied in the architectural models may be incomplete or inconsistent, necessitating redefinition (modification) of the requirements. It is up to the Change Control Board (or its equivalent) to determine whether the request will be honored, rejected or deferred.

2.2.2.3 Transition C: Defect Report

A defect report may stem from:

• A build error in the nightly/regular build in Stage 3
• An integration error or test failure in Stage 4
• A user-reported defect in a deployed product

The defect report will be reviewed, assigned a status (accepted, rejected, deferred), and other characteristics such as severity, criticality, impact, and possible assignment, by the CM CCB.

(Bullet 1: Most Stage 3 build errors are handled very informally by direct discussion with the responsible developer. Very few require design modification and need to be elevated to a defect report as described here. I interpret your wording to mean every build error results in a defect report. -- HelenHogan? - 20 Feb 2003 {Dirk, please address this. -- SmKershaw? - 23 Feb 2003 }

2.2.3 Summary

Configuration Management is necessary and important at every stage of a project's Life Cycle. For very complex projects, Figure 2 may be an oversimplification. Other projects will require fewer stages than it depicts. However, the diagram is general enough that it can be expanded as necessary, compacted when feasible, and even mapped onto a project which is entirely or almost entirely acquisition.

-- CarildaAThomas? 13 Feb 2003 (Excellent Software CM Life-cycle model. You are also absolutely correct concerning the Acquisition model. I hope that we can maybe find something general which can be used for software and hardware or we have to separate -- DirkWessel? 13 Feb 2003 )

{I hope to have us create a general model with illustrations how it can be adapted to fit hardware, acquisition, software, integrated products. The CMMI is supposed to do just that, and I am going to troll it for ideas. } -- CarildaAThomas? 14 Feb 2003

2.2.4 Pros and Cons of this Cycle

2.3 WHO ARE THE KEY PLAYERS?

A CM plan should designate certain roles that assume particular responsibilities within the CM team. In a large project, each role may be assigned to a distinct individual. Smaller projects may merge some roles within a single individual. Nevertheless, the roles and responsibilities are distinct and should be defined, however the roles are implemented in practice.

2.3.1 Media Librarian

The Media Librarian is responsible for the entire media library, its completeness, its integrity, its procedures, and the acquisition of the material retained therein. A media library or media storage area is a physical location - not storing them magnetically or electronically. While said library can contain magnetic material, the physical devices or media upon which it resides must be retained. Thus the term 'media' was selected. Anything referencing the term "configuration repository" means a soft-repository such as a repository kept through a vendored tool. A Media Librarian serves a different function from a Repository Manager. Specifically, the librarian:

• provides a method by which media can be checked in and out of the Library
• provides for and maintains an automated Library record listing all items on file
• logs new documents into the Library and database records
• prepares reports of Library contents as necessary
• notifies members of the project team when new media items are available
• controls baseline media with proper version control

A media librarian, manages items which pertain to, but do not precisely belong to, the configuration effort. This could be training material, including reference books on tools used, standards manuals, even the media (CDs) containing the version(s) of the tools used for development and/or deployment.

-- SmKershaw? - 10 Feb 2003 -- KjMangan? - 18 Feb 2003 -- CarildaAThomas? - 21 Feb 2003 -- SmKershaw? - 23 Feb 2003

2.3.2 Tool Technician

The Tool Technician (DBA) supports all database needs for the CM group. This includes:

• making authorized changes to tools
• facilitating the automation of various functions
• taking direction from the Software Configuration Manager

The responsibility for the automation of build processes and other CM processes falls first to the CM Manager, but it could be delegated to the Tools Technician to facilitate, and then to the Build manager to use them in accordance with procedures that would be developed. -- SmKershaw? - 20 Feb 2003 -- HelenHogan? - 20 Feb 2003}

2.3.3 Data Manager

The Data Manager:

• supports all Problem Reporting functions
• monitors and provides problem report assessments
• facilitates the CCB(s)
• carries responsibility for the integrity of all CM databases and tables

2.3.4 Release Manager

The Release Manager is responsible for proper execution of the process, and controls releases by:

• tracking all STRs assigned to a release as they move through the process
• having the capability of reporting the status of any one problem report to Management regarding its position in the process queue
• generating reports on the overall status of any given release (a collection of problem reports)
• determining when milestones have been met
• being able to anticipate and notify interested parties that an event is pending for one problem report or an entire release
• monitoring and maintaining the release cycle through automated routines and databases

The Release Manager has the responsibility to assure that there is a deployment plan, a complete Release Description, and that the deployment/release is done accordingly for each Release.

-- CarildaAThomas? - 21 Feb 2003 {agreed and added. -- SmKershaw? - 23 Feb 2003 -- ElisabethEk? 11 Feb 2003

2.3.5 Build Manager

The Build Manager is responsible for creating the final deliverable and its documentation. The Build Manager is also responsible for creating the ‘as-built’ prior to initial testing by Quality Test and Evaluation, and any "nightly" or regular builds in a development sandbox. The Build Manager, with coordination from the Configuration Manager assists in the final production and packaging efforts of approved deliverables. Depending on the magnitude of the effort, these duties can be delegated to other groups in the organization, but the CM team is ultimately responsible for it. {Incorporated Helen's ideas into this paragraph. -- SmKershaw? - 20 Feb 2003 -- HelenHogan? - 20 Feb 2003}

2.3.6 Configuration Manager

The Configuration Manager ensures that answers are always available for such questions as: What product/version is this? What changed? What tests were run? What were the test results? and Where is the product located? The Configuration Manager is the central point for system change and has the following responsibilities:

• Develop, document and distribute the CM procedures, policies and plans
• Establish the system baseline, including backup provisions
• Ensure that no unauthorized changes are made to the baseline
• Provide the focal point for exception resolution
• Provide leadership and guidance to CM team

2.3.7 Director of Configuration Management

The Manager/Director of Configuration Management is obviously required only in large environments where there are multiple projects to guide. This person is responsible for the processes, procedures, tools, training, etc. to be streamlined and standardized. The Manager/Director of CM has responsibilities for budget and personnel, too.-- SmKershaw? - 10 Feb 2003 -- CarildaAThomas? 15 Feb 2003 -- SmKershaw? - 23 Feb 2003

2.4 WHAT ARE THE ORGANIZATIONAL INFLUENCES?

There are many forces that influence Configuration Management. There are favorable influences and influences that hinder. This section will describe some of those influences and provide some information concerning organizational structures. -- SmKershaw? - 10 Feb 2003

2.4.1 What are some of the hindering influences?

There are any number of things that can hinder a Configuration Management effort. Some of those things include funding, training, schedule, lack of management savvy, poor customer service attitude, and territoriality.

Some of these things in the list have a fairly obvious cause and effect. For instance, it is obvious that if the project is underfunded, the Configuration Management team may be the third group reduced or eventually eliminated to save costs (after the process improvement and documentation teams). Also, like new businesses that are undercapitalized - they don't last long - and CM efforts don't either.

When it comes to Training, one can look at the training of the Configuration Management team just as easily as the entire project team. Without proper training in processes, procedures, tool usage, etc, there will be problems, albeit not as catastrophic as a lack of funding, but troublesome at best.

Scheduling is listed because all too often, projects are ruled and governed by schedules, and CM is rarely in a position to alter them. Therefore CM efforts and CM personnel are hard pressed to comply. Working too quickly and cutting corners, while not advised, is often required and encouraged of CM Professionals. CM Professionals must be ready for these demands and address them in a way that minimizes the negative impact on the Configured Item(s).

The lack of Management Savvy is another road block all too frequently encountered. If upper management has not been convinced of the role of CM in correct and timely delivery, it will not be supportive of CM, and the CM team's efforts will be difficult. The role of the CM Professional in this case is to educate, sell, and persuade key members of the management team in an effort to gain their support. Another problem with management when they are not very CM savvy is that management tends to make choices and decisions without consulting CM. As CM Professionals, we must be aware that this can happen and to be prepared for those times.

Poor Customer Service Attitude, apart from the funding concern, is perhaps one of the worst things that can happen to a CM team. It used to be called the "Total Quality Concept": the notion that everyone on your CM Team must treat everyone with whom they work (bosses and peers alike) as customers. A bad attitude can drive a team and a project down faster than a bad rumor.

Lastly, territoriality is the sense that some people have that their job is theirs and their work is theirs and no one shall interfere. It is also known as a strong sense of 'ownership'. The problem with this is that when members of your CM team have this isolationist attitude, the team relationships will be strained and will eventually break down. For efficiency, CM teams cannot abide this personality/practice/style in team members.

-- SmKershaw? - 10 Feb 2003

2.4.2 What are some of the favorable influences?

The aforementioned hindering influences all have opposites that apply here, and there are some specific favorable influences that can be mentioned. These would be good planning, common practices, and knowledgeable team members.

Good Planning from the beginning that includes Configuration Management will help ensure that a Configuration Management effort will succeed.

Having common practices between configuration efforts within an organization has great benefit not just from a cost savings perspective, but from an employee portability perspective, too. Those involved in development also enjoy unparalleled benefit from standard methods across projects.

Having team members aware of Configuration Management concerns makes the job of CM easier in that fewer problems will arise. Also, having CM team members aware of the development arena, the nature of the project, etc., makes for better communication and keeps favorable things happening.

-- SmKershaw? - 10 Feb 2003

2.4.3 What are some common organizational structures?

There are at least three organizational structures in use by Configuration Management teams and organizations.

The traditional hierarchical organization chart would put a Director of CM at the top. Then each Configuration Manager reporting to the Director would be on the second level followed by each Team member reporting to the configuration manager on the third.

There are smaller firms that have only one Configuration Manager and there isn't any true CM organization within which he/she fits.

The third is a matrixed organization where a Director of CM is responsible for the assignment of Configuration Managers (and associated teams) to projects out of a "pool" of Configuration Managers. A single CM may be responsible for multiple projects.

-- SmKershaw? - 10 Feb 2003 (Minor editing, grammar and rewording for all of Section 2.4) -- CarildaAThomas? - 17 Feb 2003

There is a fourth organization structure. It consists of one manager of a CM group with team members reporting directly to him. This team handles all projects. The responsibility is distributed by functionality instead of projects. -- DenisRoy? - 17 Feb 2003

(Chapter split) -- CarildaAThomas? - 18 Feb 2003

---

Chapter 3: Configuration Management Processes

Overview

Configuration Management processes describe, organize, and complete the work of the project. Configuration-oriented processes specify and create the configuration's product. -- SmKershaw? - 08 Feb 2003

The best CM process is one that can best (1) accommodate change, (2) optimise the reuse of standards and best practices, (3) assure that all requirements remain clear, concise and valid, (4) communicate (1), (2) and (3) to each user promptly and precisely and (5) assure conformance in each case. {Moved from above - written by Dirk Wessel--- SmKershaw? - 14 Feb 2003 }

3.1 ESSENTIAL CM PROCESSES

There are some common processes that are essential to initiate, plan for, execute, control, and to close Configuration Management efforts. Because every organization's environment is different, even the best intentions have difficulty coming to fruition. With proper managerial support, the processes required are much easier to develop and implement. -- SmKershaw? - 08 Feb 2003 {Ref to PMBOK®}

3.1.1 What does it take to initiate CM?

There are some things that must be in place prior to consideration for the initiation of CM processes. The first and foremost is funding and the second is management support and direction.

Once management selects a Configuration Manager for the project at hand (CM per project) or a new project is created (CM for the whole enterprise), the Configuration Manager begins to be actively engagedin the project's planning and scheduling. This task is a lot easier if performed at the start of a project. Coming in after the fact, the Configuration Manager's effort will be constrained by existing plans and schedules without much hope of modification.

The CM will need to understand the environment of configuration effort, the nature of testing, who the primary players are, and what are the processes for development.

Once these are understood, the CM can begin to develop appropriate Configuration Management Plans, operational charters for review boards, desk level procedures, automation routines for builds and deliverables, etc.

3.1.2 What Planning processes should be used?

There are three methods for such planning. One is where the Configuration Manager develops the entire set of processes in a vacuum without involvement from other team members. Sometimes this works, but only because the selling job which follows is extraordinary.

A second approach is where project team members are encouraged to contribute and evaluate plans for the processes. The developers and other team members will be the ones using these processes the most, and so have a vested interest in establishing good and functional ones.

A third is applicable to large organizations where the Configuration Management approach and the processes therein have been standardized. Only minor tailoring would need to be addressed by the Configuration Manager, making the planning effort very minor.

-- SmKershaw? - 10 Feb 2003

3.1.3 Executing the CM processes - What works Best?

Executing or implementing the proposed CM processes that have been developed can be done in two different ways. First is the dictatorial approach which requires the deployment of the processes with very little fanfare. The second is generally more satisfactory.

Prepare presentations at two levels. Create one presentation with the managers in mind. Create a second with the developers and other non-management project team members in mind. Demonstrate and 'train' the team members and explain the transition from current methods to the new one and tell when the transition will take place. Also be prepared to take suggestions for changes and implement those changes as appropriate.

Once presented, make the switchover to the process quick and as painless to the team members as possible.

-- SmKershaw? - 10 Feb 2003

3.1.4 How are the processes controlled?

Processes are tough to control in practice, while easy to control physically. The documentation for the processes can be easily versioned and controlled. The hard part is where the Configuration Manager is unaware that processes aren't being followed until it is too late - if at all. One way to mitigate a perception of lack of control is to keep the training effort current, and repeat it for all team members periodically. Another way to mitigate this perception is to encourage and support an active Quality Assurance Team and/or an active Process Improvement Team to monitor processes. The reasons why processes break usually are because they are not used properly, they are not understood, or they were circumvented without CM knowledge. This is why CM must be constantly and actively involved in the project's efforts at all levels.

-- SmKershaw? - 10 Feb 2003 { Edited and slightly reworded. } -- DenisRoy? - 18 Feb 2003

3.1.5 What process should be followed for closure?

Just as there are processes used during the life of the project, processes for closure must also be developed. Most of the time, projects just stop being funded and they end very abruptly. The proper closure incorporates the storage of at least the last release of the product, support equipment, documentation, databases, etc. The main objective of a good closure is to allow the project to be restarted where it was halted if required. This makes for a potentially costly closure effort which a lot of projects probably do not enjoy. -- SmKershaw? - 10 Feb 2003 { Edited and slightly reworded. } -- DenisRoy? - 18 Feb 2003

3.2 CONFIGURATION PROCESS INTERACTIONS

Configuration Managers coordinate the planning of their processes with other key project personnel. The persons include project, quality, and development leads. Once the processes are defined, CM, along with project personnel, coordinate the deployment of the processes. CM will maintain control over the processes, making modifications where appropriate.

At the end of the life of the project, Configuration Management must also define how the project will be closed out. Working with project management staff, CM determines what material/information shall be retained, eliminated or stored. -- SmKershaw? - 11 Feb 2003

3.3 MAKING IT HAPPEN

Putting a process for configuration into action, as described above requires training, coordination, and cooperation. One method for implementing requires that training materials be developed and project personnel be semi-formally trained in the process. As soon as training begins, the configuration management team should be ready to put it into action immediately. Each team member should be given a copy of the process - even if it simply an outline. The entire process should eventually be written down and published to the team.

Some of the problems that can be expected include a lack of willingness on the part of team members to comply with the processes, or to even attend the training classes.

Sometimes, management forgets their original commitment to the effort and may need to be reminded.

3.3.1 Case Study: US Armed Forces

Here is how it was originally caused to happen in the US armed forces.

CM has been employed to control changes to products used in the defense of our country for many years. It has evolved from typed documents, handwritten logs and punched cards to use of sophisticated databases and networks.

During all these years of evolution, the basic core criteria have not been altered.

The criteria involves four (4) activities which are performed separately but in parallel.

• Identifying the product. This activity involves four steps, three of which you probably haven't done this way before now.
  • Write the customer's requirements for your product into a document that you and the customer agree on.
  • Identify your product by establishing a number for each item in it. This is the step you may already be doing.
  • Create an address for each item which relates each item number to every other item number in the product. The address is similar to your home address. It does not change even though the item number that resides there may change.
  • Relate each document that is used to design, develop, produce and support each item to the same address as the item.

• Controlling changes to the product: Each change is described in relation to the four steps in the first activity:
  • The impact on the customer's requirements document
  • The item number of the changed item
  • The address of the changed item
  • The documents related to that address

• Accounting for the changes when they are made to the items and the related documents: Each change is accounted for by identifying the revised documents which relate to the changed item.
• Auditing: Auditing the product for compliance with customer requirements before it is delivered. Each item in the product is compared to the documents that relate to it.

-- As related by NeilSteeman? - 13 Feb 2003

3.3.2 Case Study:

{Need some more case studies here -- a good writeup on problems encountered, or problems averted, maybe a top-down (corporate process -> CM process) or bottom-up (CM process as a first step into Enterprise process management) -- CarildaAThomas? - 18 Feb 2003

(Chapter split and minor formatting and editing) -- CarildaAThomas? - 18 Feb 2003

---

Section II: The Configuration Management Knowledge Areas

---

Chapter 4: Configuration Management Planning

Overview

The planning for a Configuration Management effort is not trivial nor should it be taken lightly. This section outlines the process, procedures, guidelines and outlines used for planning a Configuration Management effort. -- SmKershaw? - 15 Feb 2003

4.1 GENERAL

Any Organisation, in order to be efficient, has to identify its core business processes.

These core business processes, used to run the business, must be clearly identified and documented. Each core process must have its assigned owner who is responsible continuously to ensure the reliability and efficiency of the owned processes.

Not only must CM be established as one of the core business process, but CM also can provide the perfect framework upon which the business process infrastructure can be effective.

Giving this new perspective, it is necessary not to see CM anymore as limited to being a pure engineering discipline. Providing a framework for the business process infrastructure lifts CM to an organizational-wide perspective.

The purpose of this section is to give an understanding about the importance of the role of Configuration Management Planning. The goal is to provide guidance of how a CM solution can be implemented and what are the key elements to be established. -- SmKershaw? - 11 Feb 2003

4.2 CONCEPT

Configuration management embodies two concepts:

1. The Configuration Management of products/services and their defining technical data
2. The Configuration Management of the business process infrastructure.

Configuration Planning can be best achieved using a four-phased approach consisting of: Preparation, Transition, Implementation and Adaptation/Continuous Improvement.

To successfully initiate a CM Planning process, Cross-functional teams need to be established. They should be organized in a hierarchy. A higher level team, comprised of members of the top-level management should act as a steering committee providing guidance, rules and regulations and decisions.

The subordinated teams usually report to the higher level team and should be constituted by collecting members from all required disciplines within the organization to perform the day-to-day business. The members of the subordinate-level team are responsible for preparing plans, obtaining approvals, coordinating implementation, problem resolution, plan maintenance and progress reports. -- SmKershaw? - 11 Feb 2003

4.3 IMPLEMENTATION STRATEGY

The preparation phase accumulates in a “12 Step” approach to prepare an effective CM Solution.

Step 1 – Top-Management Buy-in

The establishment and implementation of an efficient CM Solution and its required Business Process Infrastructure is best achieved when top-management buys the idea and backs it up. This can be achieved by using a Top-down approach.

Top-down means that the effort is driven by upper management.

If the support from upper-management is lacking, a bottom-up approach can be a viable option, but requires much more effort than the top-down approach.

Since a Top-down approach is highly preferred, it might be necessary to get better management buy-in; that is, give management an understanding of the complexity of the solution and hence the costs and tradeoffs. This enables a better commitment of resources such as tools, people, and funds to the solution.

A possible solution to get better buy-in is to perform management information sessions to inform upper management on the following points:

• Overview about CM concept
• A brief overview about the principles of Configuration Management and the concept to be applied
• Objectives and Requirements (Goals)
• Benefits and Risks.

Configuration Management provides knowledge of the correct current configuration of material, assets and services, the relationship to the associated documents and . The CM process efficiently accommodate changes, ensuring that all impacts to operation and support are addressed. The benefits of the process should be obvious but are often overlooked. CM benefits can be summarized as follows:

{The previous paragraph needs to be explain/rephrase} -- DenisRoy? - 27 Feb 2003

• Product attributes are defined. Measurable performance parameters are provided. Both purchaser and contractor have a common basis for acquisition and use of the product.

• Product configuration is documented and a known basis for making changes is established. Decisions are based on correct, current information. Production repeatability is enhanced.

• Products are labeled and correlated with their associated requirements, design and product information. The applicable data (such as for procurement, design or servicing the product) is accessible, avoiding guesswork and trial and error.

• Proposed changes are identified and evaluated for impact prior to making change decisions. Downstream surprises are avoided. Cost and schedule savings are realized.

• Changes can be accommodated. Change activity is managed using a defined and fast process. Costly errors of ad hoc, erratic change management are avoided.

• Configuration information, captured during the product definition, change management, product build, distribution, operation, and disposal processes, is organized for retrieval of key information and relationships, as needed. Timely, accurate information avoids costly delays and product down time, ensures proper replacement and repair and decreases maintenance costs.

• Actual product configuration is verified against the required attributes. Incorporation of changes to the product is verified, authorized and recorded throughout the product life. A high level of confidence in the product information is established.

• Well defined, stable and transparent business process infrastructure results.

These benefits are equally applicable to purchaser and contractor. Additionally, the effective application of CM principles to acquired products contributes to and enhances the partnering environment desired between the Purchaser and its suppliers.

In the absence of CM, or where it is ineffectual, the attendant risks are:

• Customer expectation are not met
• Equipment/Software fails due to incorrect part installation or replacement
• Product does not comply to requirements
• Product Documentation is incomplete or not correct
• There are schedule delays and increased cost due to unanticipated changes
• There are operational delays due to mismatches with support assets
• Uncontrolled changes introduce defects implying the need for corrective action
• Maintenance problems, down-time, and increased maintenance cost are caused by inconsistencies between equipment/software and its maintenance instructions
• High intervention rate is required, and consequently high cost due to corrective action
• Numerous other circumstances which decrease operational effectiveness, and add cost may occur

The severest consequence is catastrophic loss of expensive equipment and human life. Of course these failures may be attributed to causes other than poor CM, but effective CM may often avert these.

The overall objective of CM is to move out of the corrective action mode, which avoids preventable costs, to minimize risk, and to expedite transition into a continuous improvement mode.

Those who consider the small investment in the CM process a cost-driver may not be considering the compensating benefits of CM and may be ignoring or underestimating the cost, schedule and technical risk of an inadequate or delayed CM process.

-- DirkWessel? - 11 Feb 2003 {Dirk, can we find another word than "sensibilization"? I'm guessing that you are trying to avoid the word "education" since upper management might take affront, and I did not want to just plug in a word because the word should say exactly what you mean, not what I think you mean.} -- CarildaAThomas? - 18 Feb 2003

(Maybe "coaching" although that I like sensibilization more. Any suggestions?) -- DirkWessel? 18 Feb 2003 { How about "evangelizing"? One has to do more than just sell upper management on the idea, one has to make True Believers out of them so they will support CM over the long haul. } -- CarildaAThomas? - 21 Feb 2003

Step 2 – Establish CM Policy

Before you can start with the development of a CM policy it has to be clear which position and importance the CM organization will take within the organizational structure. So before starting with the CM policy you need to have guidance from your higher management.

The CM policy document should reflect the strategic objectives adapted to the different phases in the projects life-cycle.

Step 3 – Define Requirements

In order to produce a product/service which survives in the market an organization has to define its requirements.

The main objective during the definition of those requirements should be to establish clear, concise and valid requirements.

• Clear means that they are easy to understand.
• Concise means free from all elaboration and superfluous detail.
• Valid means that they meet the expectations and can be tested.

In an Acquisition environment the purchaser and the contractor requirements should be congruent. During the CM Planning phase for each life-cycle, the purchaser must articulate its vision and transform it into clear, concise and valid requirements for the contractor. Before the requirements are going to be implemented, they should be coordinated with the contractor.

Business Requirements

Before starting to define the business requirements the Organisation has to establish, based on existing regulations and the Customer needs, a Mission Statement. This Mission Statement indicates the purpose of the Organisation.

Following the Mission Statement, a Strategic Business Plan has to be established describing how to accomplish the Mission Statement.

The business requirements should describe the overall organizational business infrastructure the business core processes, relationship to other disciplines and the working conditions within your Organisation.

Make sure that the employees understand and identify themselves with the business requirements.

The business requirements should be documented in a Strategic Business Plan.

Product/Service Requirements

All developmental projects are governed by requirements. For your products/services, identify all the user needs and convert them into clear concise and valid requirements. Once you have converted them, try to coordinate with the user and see if they match with the users needs.

The requirements do not have to be perfect in the first instance, it is more important that they reflect what the user expects.

The product/service requirements should be documented in a System Specification.

Step 4 – Document Requirements

ISO 9000 says:" Document what you do; Do what you documented."

CMII, for example, goes beyond this statement and says:" A Requirement is not a requirement unless it is documented, validated and released."

Once you have defined your requirements they need to be documented.

Product Requirements will be documented in the Design basis.

Business Requirements in the Strategic Business Plan, Policies, Standards, Procedures etc.

Requirements Management

Requirements Management provides visibility on behalf of project leadership. Applying familiar Configuration Management (CM) principles to a set of data that includes the comprehensive scope of work enables a systematic tracking of requirements wherever they are found and however they may have changed.

The Requirement Management approach provides a clear view of information, which enables projects to:

• relate the configuration of technical baselines to corresponding cost and schedule requirements
• synchronize the project-wide flow and content of requirements and changes to requirements
• network all interfacing project activities at the review, approval, and distribution interfaces; and
• provide a requirements visibility resource for interfacing design, procurement, production/remediation, logistics support and other activities.

The result is an integrated view of the project configuration (including cost and schedule) which provides up-to-date performance and quality measurement criteria for early warnings of off-course trends.

To keep an entire project apprised of the configuration and application of rapidly evolving requirements, it is necessary to:

• Identify requirements with naming and numbering attributes that facilitate traceability to parent-child relationships, and support configuration tracking and reporting
• Control the content, review and approval of changes to requirements
• Describe the changes in terms of both individual requirements
• Depict and maintain in hierarchical document trees the configuration baselines in which requirements are resident
• Account for and report the configuration status of individual requirements and requirements
• Manage the timely flow of evolving requirements and changes, across multiple functions/departments/organizations

Develop Organisational and CM policies

A Policy paper defines the requirements for interactions between individuals and groups within and outside the Organisation.

Develop Operating Standards and Procedures

Every Organisation works on Requirements. Without Requirements there is nothing to be done. Requirements to be achieved by a core business process are outlined in an operating standard. Procedures describe how to achieve such requirements. A possible documentation structure could be the one proposed by ISO 9000.

{Image added - DirkWessel?}

The Quality Manual specifies the requirements. Procedures for accomplishing those requirements are the next lower tier.

Work / Job Instructions are standard processes which reside at the third tier and which can be referenced for reuse in any number of procedures.

The “other documents” residing at the fourth tier are equivalent to “records” which provide evidence that conformance was achieved.

Step 5 – Establish a standardized Acronyms and Terminology dictionary

Some of the biggest problems within a project execution are communication problems. Very often, inappropriate words are used or words are wrongly interpreted.

To achieve a high level of efficiency it is important to standardize terminology. This is best accomplished by creating a dictionary and a glossary of commonly used acronyms, words and terminologies. Furthermore operation procedures have to be established describing how the dictionary and glossary are to be used and kept up-to-date.

Step 6 – Create a CM Plan

CM planning is a vital part of the preparation for each phase of a project life cycle. The Configuration Management plan documents the results of that planning to enable the usage of the Plan as a basis in managing the project configuration management activities.

For more details on how to create a CM Plan, please refer to the chapter X below.

Step 7 – Structuring Requirements

An organization can only operate efficiently if they manage their requirements correctly. This correlates with the ability to accommodate changes and keep the requirements clear, concise and valid.

All requirements should be uniquely identified, structured and linked. Each requirement exists in a hierarchy of requirements. This applies to the product/service requirements as well as the business requirements.

CM's primary role is to maintain those requirements.

Step 8 – Implement a Change process

In order to keep requirements clear, concise and valid, every organization needs to have an effective change mechanism in place.

A common change process shall be implemented.

Step 9 – Measure Performance

Effective measurements are a prerequisite to achieving consistent conformance and avoiding the need for corrective action.

Metrics are key to continuous process improvement and to manage the CM-related risks.

Metrics constitute the data for improvement, i.e. the facts of the process. They enable problems that need attention to be quantified, stratified and prioritized and also provide a basis for assessing the improvements, and assessing trends. A constituted set of CM metrics supports both the CM objectives and process.

Only a few critical items should be used at one time. They should be designed to positively motivate, rather than keep score, and should be forward focused (where are we going) as opposed to merely a compilation of past history.

A metric involves more than a measurement; it consists of:

• An operational definition of the metric which defines what is to be measured, why the metric is employed, when, where and how it is used. It can also help to determine when a metric has outlived its usefulness and should be discontinued.

• The collection and recording of actual measurement data. In the case of the CM process, this step can often be accomplished by query to the status accounting data base, which normally can provide a great deal of process flow information

• The reduction of the measurement data into a presentation format (e.g., run chart, control chart, cause and effect diagram, Pareto charts, histogram) to best illuminate problems or bottlenecks and lead to the determination of root cause or largest constraint.

An effective metric has the following attributes:

• It is meaningful in terms of customer relationships (where the “customer” can be any user of information that is provided.)
• It relates to an organization’s goals and objective, and tells how well they are being met by the process, or part of the process, being measured
• It is timely, simple, logical and repeatable, unambiguously defined, economical to collect.
• It shows a trend over time, which will drive the appropriate forward focused action, which will benefit the entire organization.

Both the purchasers and the contractors CM processes should be measured and evaluated using metrics, project reviews.

Step 10 – Institute an internal CM Audit Plan and perform internal Pre-Audits

It is essential to learn from effective measurements and metrics if the process is or is not meeting objectives. We also learn which part of the process is currently the biggest contributor to detected backlogs, bottlenecks, repeat effort, or failures/errors. By focusing on that weakest link, we can isolate the problem and trace it to its root cause. Often the cause can be corrected by streamlining the process (eliminating redundancy or non-value adding steps, modifying sequence, performing tasks in parallel rather than in series) or improving communications.

Measurements should continue as is or be altered to fit the new solution for a period of time sufficient to assess if the revised process is resulting in improved performance. This measurement/improvement cycle is an iterative process. Once a weak link is improved, the process metrics are again reviewed to determine and improve other parts of the process that stand out as contributors to deficiencies or lengthy cycle time.

The key personnel involved in the process must be participants in defining the improvements. Their “buy in” is essential if the improvements are to be implemented effectively. Detailed procedures and effected automated systems must be modified and personnel must be re-trained, as required. These “total quality management aspects” of the job are best performed as an integral part of the process of managing, rather than as isolated exercises.

It is also a waste of effort to expend effort in improving processes without clearly documenting the lessons learned to leverage the efficiency of future applications. Changes made in the process, over time, should be recorded along with the reasons the changes were made and the measured results.

A suggested place to record process changes is in the Configuration Management Plan. Initially the CM plan was a projection of the expected implementation of Configuration Management over the project life cycle. As a minimum, it is updated during each phase for application during the next. Including process change and lessons learned information makes the plan a working document reflecting the transition from anticipated action (planning) to completed action (reality). It can then serve as a better reference to use in planning for the next project phase and in the initial planning for future projects.

Internal CM Audit Plan

In order to effectively analyse the current processes it is required to conduct in coordination with Quality Management internal Audits. These internal audits should be frequently conducted, planned and documented in an Internal CM Audit Plan which has to be coordinated with Quality Management.

Step 11 – CM Staffing

The CM Staffing should Consist of Individuals with technical expertise to support the Development and Maintenance of the Product. When staffing the CM area, be sure the individuals have the technical expertise to develop and implement sound processes and procedures.

CM should be staffed with technically skilled individuals who can develop methodologies for control, re-creation and release of models, product build/compile structures, subcontractor monitoring and managing, and authoring of CM-related documentation (including, CM Plan, baseline documentation, and so on.)

Be cautious when evaluating the staffing required to administer the CM system. While a mature system doesn’t require a large staff, the project should not cut CM staff simply because things appear to be going well.

The CM process must be institutionalized, not just written down. The tool set must be complete, in use, and no longer in need of constant maintenance. Several milestones — major deliveries to system integration, large test events, or audits — all become successful when supported by a fully utilized and reliable CM process.

Step 12 – Select best Automated CM System

-- DirkWessel? 18 Feb 2003

4.4 CM PLAN

According to the IEEE STD 828-1990, a plan documents what CM activities are to be done, how they are to be done, who is responsible for doing specific activities, when they are to happen, and what resources are required. It can address CM activities over any portion of a product's life cycle.

It is important to keep in mind the hierarchy where the CM Plan fits. Policies are typically at the highest level, requiring that directives be written. Directives generate Plans. Plans are implemented by procedures. Plans are not to address procedural concerns, rather they are directive, envisioning, guiding all in response to policies and directives. So when CM plans are written - regardless of style of outline - they must address the current state of the configuration and show how things need to move through into the future. -- SmKershaw? - 11 Feb 2003

4.4.1 CM PLAN - INTEGRATION WITH OTHER PLANS AND STANDARDS

Project/organizations utilizing Configuration Management will also utilize a variety of plans. These additional plans include (but are not necessarily limited to) project management plans, quality assurance plans, development plans, release management plans and software improvement plans. All of these must work together along with the CMP.

Project Plans should refer to the CMP, and describe where Configuration Management fits into Project Management. Conversely, the CMP should address Project Management needs.

Quality Assurance Plans should refer to the CMP, and describe its involvement with Configuration Management. The CMP should address quality assurance plan needs for Configuration Management.

Development Plans, regardless of the product (software or hardware), should demonstrate that the effort is configured in accordance with the Configuration Management plan and should address all CM Plan issues and concerns. The CMP should address the development plan needs for Configuration Management.

All must be auditable from a document trail perspective and be in agreement. -- SmKershaw? - 14 Feb 2003

4.4.2 CM PLAN - DEVELOPMENT

{How do you go about writing one? What determines the guidelines selections? What should be considered for inclusion and what should be excluded?}-- SmKershaw? - 11 Feb 2003

In writing a CM Plan, it is best to first to have identified and have approved a standard by which the configuration effort shall be guided. Such standards usually have a predefined outline that is to be followed - within reason - and tailored to fit the needs of the configuration effort. A few of these are provided in the sections that follow.

As a Configuration Manager you will be drawing upon your talent and skill to fill in the 'unknowns' in the plan. If you don't know the schedule, then you will need to get it. If it isn't defined, then it is your job to follow-up with management and encourage them to get one. The same can be said for any aspect of the plan for which you are missing pieces or parts.

You may put anything into the plan, as long as those inclusions do not detract from the mission of your configuration effort and the plan serving as a plan. Procedural issues should be detailed in a separate text.

-- SmKershaw? - 14 Feb 2003

4.4.3 CM PLAN - STANDARDS GUIDING DEVELOPMENT

Below are some samples of CM PLAN outlines. However, it should be pointed out, that there are some common parts of all of these outlines, and so it could be derived that at a minimum, a CM PLAN should include these sections:

• Introduction
  • Scope
  • Definitions
  • Acronyms List
  • References
• Configuration Management
  • CM Organization
  • CM Responsibilities
• CM Schedules and Milestones
• CM Activities
  • Identification
  • Control
  • Status Accounting
  • Auditing
• Interface Management
• Data Management
• Sub Contractor/Vendor Control

-- SmKershaw? - 14 Feb 2003

4.4.3.1 Outline of a typical Purchaser CM Plan

   1.0 INTRODUCTION 
   1.1 Scope
   1.2 Definitions
   1.3 Acronym List
   1.4 References
   1.5 Tailoring 
   2.0 CONFIGURATION MANAGEMENT 
   2.1 CM organization 
   2.2 CM responsibilities 
   2.3 Relationship of CM to the process life cycle
       2.3.1 Interfaces to other organizations, disciplines on the project 
       2.3.2 Other project organizations' CM responsibilities
   2.4 Relationship with Purchaser CM Plan
   3.0 CONFIGURATION MANAGEMENT PHASING AND MILESTONES
       * Release and submittal of configuration documentation in respect to project events
       * Define all CM project milestones (e.g., baselines, reviews, audits) 
       * Describe how the CM milestones tie into the development process 
       * Identify what the criteria are for reaching each milestone 
   4.0 CONFIGURATION MANAGEMENT ACTIVITIES 
   4.1 Configuration Planning
       4.1.1 Configuration Management Implementation Procedure
   4.2 Configuration Identification
       4.2.1 CI Selection and Description
             * A description of the selection criteria and the associated rationale employed to select the CIs
             * A description of key lower level CIs (hardware and software) including training devices and simulators showing their relationship to the work breakdown structure of the complete project;  
             * A description of the function of the top level CI and its interrelationship to other system functions; and
             * Government Furnished Equipment/Property. (May be specified in a separate appendix, if necessary). 
       4.2.2 Configuration Documentation Identification 
             * Labeling and numbering scheme for documents and files 
             * How identification between documents and files relate 
             * Description of identification tracking scheme 
             * When a document/file identification number enters controlled status 
             * How the identification scheme addresses versions and releases 
             * How the identification scheme addresses hardware, application software system software, COTS products, support software (e.g., test data and files), etc. 
             * Configuration Control Authority designation for each configuration document
       4.2.3 Change Control Form Identification 
             * Numbering scheme for each of the forms used 
       4.2.4 Project Baselines 
             * Identify various baselines for the project 
             * For each baseline created provide the following information: 
                 * How and when it is created 
                 * Who authorizes and who verifies it 
                 * The purpose 
                 * What goes into it (software and documentation) 
       4.2.5 Library 
             * Identification and control mechanisms used 
             * Number of libraries and the types 
             * Backup and disaster plans and procedures 
             * Recovery process for any type of loss 
             * Retention policies and procedures 
             * What needs to be retained, for whom, and for how long 
             * How the information is retained (on-line, off-line, media type and format) 
       4.2.6 Engineering Release process, to include the following information: 
             * What is the structure of the Engineering Release System
             * What is in the release 
             * To whom is the release is being provided and when 
             * The media the release is on 
             * Any known problems in the release 
             * Any known fixes in the release 
             * Installation instructions 
   4.3 Configuration Control 
       4.3.1 Procedures for changing baselines (procedures may vary with each baseline) 
             4.3.1.1 Procedure for changing Contract Baseline
             4.3.1.2 Procedure for changing Functional, Allocated and Product baseline
       4.3.2 Procedures for processing Engineering change proposals and approvals-change classification scheme for both Hardware and Software.
             * Procedure for processing Notice of Revisions (NORs)
             * Change reporting documentation
             * Change control flow diagram 
       4.3.3 Procedures for processing Requests for Waivers/Deviations (RFW/Ds)
       4.3.4 Organizations assigned responsibilities for change control 
       4.3.5 Change Control Boards (CCBs) – for each, describe and provide the following information: 
             * Terms of references (TOR) or Charter 
             * Members 
             * Roles 
             * Procedures 
             * Approval mechanisms 
       4.3.6 Interfaces, overall hierarchy, and the responsibility for communication between multiple CCBs, when applicable 
       4.3.7 Level of control – identify how it will change throughout the life cycle, when applicable 
       4.3.8 Document revisions – how they will be handled 
       4.3.9 Procedure to describe rule for Parts substitution
       4.3.10 Automated tools used to perform change control 
   4.4 Configuration Status Accounting 
       4.4.1 Methods for collecting, recording, processing and maintaining data necessary to provide status accounting information via reports and/or database access.
       4.4.2 Storage, handling and release of project media 
       4.4.3 Types of information needed to be reported and the control over this information that is needed 
       4.4.4 Reports to be produced (e.g., management reports, QA reports, CCB reports), who the audience is for each and the information needed to produce each report 
       4.4.5 Document status accounting and change management status accounting that needs to occur 
   4.5 Configuration Auditing 
       4.5.1 Number of audits to be done and when they will be done (internal audits as well as configuration audits); for each audit provide the following: 
             * Which baseline it is tied to, if applicable 
             * Who performs the audit 
             * What is audited 
             * What is the CM role in the audit, and what are the roles of other organizations in the audit 
             * How formal is the audit 
             * Contents and delivery date of Audit plans
       4.5.2 All reviews that CM supports; for each review, provide the following: 
             * The materials to be reviewed 
             * CM responsibility in the review and the responsibilities of other organizations 
       4.5.3 Technical Reviews
             * Outline CMs participation and role in technical reviews.
   5.0 INTERFACE MANAGEMENT
       * Develop procedures for the identification of interface requirements
       * Establishment of interface agreements
       * Participation in Interface Control Working Groups (ICWG)
   6.0 DATA MANAGEMENT
       * Description of the methods for meeting the configuration management technical data requirements.
   7.0 TRAINING 
       * Identify the kinds and amounts of training (e.g., orientation, tools) 
   8.0 SUBCONTRACTOR/VENDOR SUPPORT 
       * Describe any subcontractor and/or vendor support and interfacing, if applicable 

-- DirkWessel? 11 Feb 2003 -- SmKershaw? - 11 Feb 2003 - formatted.

4.4.3.2 IEEE CM Plan Outline

Below is an abbreviated version of the IEEE CM Plan. A complete copy of the standard is in an appendix.

   1.  Introduction
   2.  CM Management
       2.1 Organization
       2.2 CM Responsibilities
       2.3 Applicable Policies, directives and procedures
   3.  CM Activities
       3.1 Configuration Identification
       3.2 Configuration Control
       3.3 Configuration Status Accounting
       3.4 Configuration Audits and Reviews
       3.5 Interface Control
       3.6 Subcontractor/Vendor Control

   4.  CM Schedules
   5.  CM Resources
   6.  CM Plan Maintenance

-- SmKershaw? - 11 Feb 2003

4.4.3.3 Mil-STD-973 CM Plan Outline

The outline below is reproduced with modification from MIL-STD-973 Appendix A. The original is targeting the Government's relationship with Vendors and their associated Configuration Management efforts. The outline below has been modified to be more generic in use. Also, those parts of the original Plan that are no longer being practiced by the Government have been removed.

In an effort to keep the theme that Plans should Plan, and not detail procedures, it should be noted that it is sufficient (in accordance with tailoring rules of this Mil-Std) to reference procedural documentation where appropriate.

Section 1. Introduction

• Includes purpose, scope and specific contractual applicability of the CM Plan and program phase(s) to which it is applied;
• A brief description of the system or top level configured item, and of the component lower level configured items, using approved configuration item nomenclatures when available, to which the CM Plan pertains;
• References to applicable directives or glossaries containing definitions of terminology and acronyms used in the plan; and
• A description of the plan's major features and objectives and a concise summary of the contractor's approach to CM, including any special conditions (such as large number of organizations, security constraints, interoperability constraints, unique contracting methods, non-developmental items, etc.) upon which the approach is based.

Section 2 - Reference Documents - lists the specifications, standards, manuals, and other documents, including policy directives, referenced in the Plan by title, document number, issuing authority, revision, and when applicable, change notice, amendment number, and date of issue.

Section 3 - Organization - Describes and graphically portrays the organization with emphasis on the CM activities, and which shall include:

• The relationships and integration of the project organization and functional organization;
• Responsibility and authority for CM of all participating groups and organizations including their role in configuration control boards, and the integration of CM functions with other program activities such as technical reviews;
• Identification of the CM organization and its responsibilities; and
• Interfaces between the CM organization and the Project/Program Owners, subcontractors, and associate contractors.

Section 4. Configuration Management phasing and milestones. - Describes and graphically portrays the sequence of events and milestones for implementation of CM in phase with major program milestones and events, including as a minimum:

• Release and submittal of configuration documentation in relation to program events (e.g., technical reviews);
• Establishment of internal developmental configuration and contractual baselines;
• Implementation of internal and project configuration control;
• Establishment of configuration control boards;
• Implementation of a status accounting information system and provision of reports/or access to the status accounting information; and
• Conduct of configuration audits.

Section 5. Data Management - Describes the methods for meeting the Configuration Management technical data requirements under the computer-aided acquisition and logistic support (CALS) requirements of the project.

Section 6. Configuration Identification. Describes the procedures for meeting the requirements of Section 5, including:

• Selection of Configured Items (hardware configured items and computer software configured items);
• Establishment and management of developmental configuration including documents, drawing and software development libraries and corrective action process;
• Establishment of the Functional, Allocated, and Product baselines, definition of the configuration documentation required for each and graphic illustration of configuration documentation relationships;
• Engineering release and correlation of manufactured products;
• and assignment and application of configuration identifiers including document numbers, nomenclatures, serial numbers and part numbers to hardware and software identifiers to software and firmware.

Section 7. Interface Management - Describes the procedures for identification of interface requirements, establishment of interface agreements and participation in interface control working groups.

Section 8. Configuration Control. Describes the procedure for meeting the requirements of Section 5, including:

• Functions, responsibility, and authority of configuration control boards;
• Classification of changes, and the level of authority for change approval/concurrence;
• Processing of "Out-Of-Scope" Changes;
• Processing of "In-Scope" Changes;
• Processing of requests for deviations and waivers.

Section 9. Configuration Status Accounting - Describes the procedures for meeting the requirements of Section 5 including:

• The methods for collecting, recording, processing and maintaining data necessary to provide contractual status accounting information via reports and/or data base access;
• Description of reports/information system content related to, as applicable:
  • Identification of current approved configuration documentation and configuration identifiers associated with each CI;
  • Status of proposed engineering changes from initiation to implementation;
  • Results of configuration audits; status and disposition of discrepancies;
  • Status of requests for critical and major deviations and waivers;
  • Traceability of changes from baselined documentation of each CI; and
  • Effectivity and installation status of configuration changes to all CIs at all locations.
• methods of access to information in status accounting information systems and/or frequency of reporting and distribution.

Section 10. Configuration Audits - Describes the approach to meeting the requirements of section 5, including: Plans, procedures, documentation, and schedules for functional and physical configuration audits; and format for reporting results of in-process configuration audits.

Section 11. Subcontractor/Vendor control - Describes the methods used by thecontractor to ensure subcontractor/vendor compliance with configuration management requirements. -- SmKershaw? - 14 Feb 2003

4.4.3.4 SEI Example of CM Plan

   1.  Overview
       * CM objectives
       * System overview
   2.  CM Organization
       * CM Responsibilities
       * CCB members
       * CCB Charter
       * Product Assurance Relationship
   3.  CM Methods
       * Baselines and Contents
       * Identification system
       * Control system
       * Auditing
       * Status Accounting
       * CM Support Tools
   4.  CM Procedures
       * Procedures manual
       * Forms and Records
   5.  CM Implementation
       * Personnel plan
       * System support plan
       * Budget
       * Key Implementation checkpoints

-- SmKershaw? - 11 Feb 2003

4.4.3.5 Outline of CM Plan following RUP model

This Outline has been modified to be applicable to any CM environment.

   1  GENERAL
      1.1   Table of Contents
      1.2   List of Tables
      1.3   List of Figures
      1.4   Document History
      1.5   Issue Control
      1.6   Authors
      1.7   Copyright Notice
      1.8   References
      1.9   Purpose of this Document
      1.10  Document Responsibility
      1.11  Change Process CM Plan
      1.12  Acronyms & Glossary
      1.13  Projects’ values
   2   INTRODUCTION
   3   INCEPTION PHASE
      3.1   Introduction
         3.1.1   Purpose
         3.1.2   Scope
      3.2   Management
         3.2.1   Organization
         3.2.2   Responsibilities
         3.2.3   Implementation
         3.2.4   Policies, directives and procedures
            3.2.4.1   Policies
            3.2.4.2   Directives
            3.2.4.3   Procedures
            3.2.4.4   Tools & OEMs
      3.3   Configuration Identification
         3.3.1   Conventions
            3.3.1.1   Labels
            3.3.1.2   Naming Restrictions
         3.3.2   Baselines
      3.4   Configuration Control
         3.4.1   Code, Hardware, Document Control
         3.4.2   Change Control
            3.4.2.1   Levels of Authority
            3.4.2.2   Change Procedures
            3.4.2.3   Review Board
            3.4.2.4   Interface Control
      3.5   Configuration Status Accounting
      3.6   Tools, techniques and methods for SCM
      3.7   Supplier Control
      3.8   Records collection and retention
   4   ELABORATION PHASE
      4.1   Introduction
         4.1.1   Purpose
         4.1.2   Scope
      4.2   Management
         4.2.1   Organization
         4.2.2   Responsibilities
         4.2.3   Implementation
         4.2.4   Policies, directives and procedures
            4.2.4.1   Component structure
            4.2.4.2   Branching and Labeling Concept
            4.2.4.3   Disk usage monitoring
            4.2.4.4   Login policy
            4.2.4.5   Profile policy
            4.2.4.6   Home policy
            4.2.4.7   New/Old user Policy
      4.3   Configuration identification
         4.3.1   Conventions
            4.3.1.1   Branches
            4.3.1.2   Label Types
         4.3.2   Baselines
      4.4   Configuration Control
         4.4.1   Code, Hardware, and Document control
         4.4.2   Change Control
            4.4.2.1   Levels of authority
            4.4.2.2   Change procedures
            4.4.2.3   Review board
            4.4.2.4   Interface Control
      4.5   Configuration Status accounting
      4.6   Tools, techniques and methods for CM
      4.7   Supplier Control
      4.8   Records collection and retention
   5   CONSTRUCTION PHASE
      5.1   Introduction
         5.1.1   Purpose
         5.1.2   Scope
      5.2   Management
         5.2.1   Organization
         5.2.2   Responsibilities
         5.2.3   Implementation
         5.2.4   Policies, directives and procedures
            5.2.4.1   Maintenance of makefiles, compilation procedures, and build procedures
            5.2.4.2   Branching/merging policies
            5.2.4.3   ConfigSpec
            5.2.4.4   Hardware Policy
            5.2.4.5   Coding processes
            5.2.4.6  Announcement of builds
            5.2.4.7  Promotion of builds
            5.2.4.8  Type of builds
            5.2.4.9  Status Build flag
            5.2.4.10  Version number
            5.2.4.11  Fault reporting systems
            5.2.4.12  Contact Points
      5.3   Configuration identification
         5.3.1   Conventions
         5.3.2   Baselines
      5.4   Configuration Control
         5.4.1   Code and Document control
         5.4.2   Change Control
            5.4.2.1   Levels of authority
            5.4.2.2   Change procedures
            5.4.2.3   Review board
            5.4.2.4   Interface Control
      5.5   Configuration Status Accounting
      5.6   Tools, techniques and methods for CM
      5.7   Supplier Control
      5.8   Records collection and retention
   6   TRANSITION PHASE
      6.1   Introduction
         6.1.1   Purpose
         6.1.2   Scope
      6.2   Management
         6.2.1   Organization
         6.2.2   Responsibilities
         6.2.3   Implementation
         6.2.4   Policies, directives and procedures
            6.2.4.1   Code Freeze Procedures (If required for the project)
            6.2.4.2   Overall Version Load Number
            6.2.4.3   Release notes
            6.2.4.4   Creation of the Release
            6.2.4.5   Patch Releases
            6.2.4.6   Release of loads
            6.2.4.7   Release to other test sites (System Test)
            6.2.4.8   Release Archive
            6.2.4.9   Incoming third parties
            6.2.4.10  New bugs process
      6.3   Configuration identification
         6.3.1   Conventions
         6.3.2   Baselines
      6.4   Configuration Control
         6.4.1   Code, Hardware, and Document control
         6.4.2   Change Control
            6.4.2.1   Levels of authority
            6.4.2.2   Change procedures
            6.4.2.3   Review board
            6.4.2.4   Interface Control
      6.5   Configuration Status accounting
      6.6   Tools, techniques and methods for CM
      6.7   Supplier Control
      6.8   Records collection and retention

DenisRoy? - 17 Feb 2003 {modified outline to be more generic -- SmKershaw? - 08 Apr 2003}

4.4.4 CM PLAN - IMPLEMENTATION

Much like the general CM Processes already discussed, the implementation of the CM Plan requires education and selling.

The first step is to get the plan reviewed and approved by members of management. It is recommended that the signatories include the managers of the project, quality assurance, development, and at least one other manager above the project manager - in addition to yourself. Once signed, the plan can then be 'rolled-out' to the team.

The CM Team should develop training materials for two different audiences. One for Management, and one for project team members. The intent is to a) show it with a positive style, b) train all players in what the plan covers and c) what it means to the audience(s) in their day-to-day work.

The Plan should be made available to all attendees in either hard copy or soft copy. The CM Team needs to invite suggestions for changes, with the caveat that the CM Team has the right to disagree.

-- SmKershaw? - 14 Feb 2003

4.4.5 CM PLAN - MAINTAINED

CM Plans need to be reviewed and updated periodically. We do this to keep our plans current with current activities, but also to assure that the 'vision' for the future is still good and still aligned with the project/organization authorizing it. Also, the CM team should keep a record of suggestions for changes to the PLAN. When the Plan is reviewed, those changes can be evaluated and if deemed appropriate, can be incorporated.

-- SmKershaw? - 14 Feb 2003

(Split and edited) -- CarildaAThomas? - 18 Feb 2003

---

Chapter 5: Configuration Tool Management

Overview

The management of CM Tools varies considerably and the tools themselves are very diverse. Today's CM environments contain a vast array of tools and methods by which the day-to-day jobs are performed. There are dozens of vendors, offering a variety of tools and functional support. Many CM environments, working on limited budgets, are forced to create their own tools out of things like Microsoft Access or other programming tools they might have at hand. Still other CM environments are so strapped for funding, that they are forced to do everything by hand, using spreadsheets and email. -- SmKershaw? - 15 Feb 2003

It is not our intent to describe specific vendor tools. This section will describe the nature of the CM activities and the kinds of tools that can be used to automate them. We will describe the capability needed, and the tool resources required to manage the tools once selected.-- SmKershaw? - 15 Feb 2003

5.1 TOOL KIT

Beyond the project management tools that could be implemented, Configuration Management has needs for tools to support the plan's requirements. These tools often fail to integrate with project management tools, and as such are seen as additional expendatures which must be justified to the project/organization.

Probably the first tool incorporated into the CM Tool Mix is a tool which automates Version Control for the product at hand. Usually, these are related to Software efforts, but hardware CM benefits from similar tools. Version Control Automation Tools (VCATs) have a wide range of pricing from free to over $600 per seat. Some of the VCATs interface with other tools. Some are home grown. Most every VCAT does the basic check-out/check-in function in a reliable fashion. VCATs can benefit most any size of project, and reduce risk by controlling versioning of items recorded in the VCAT. VCATs also enhance CM's ability to provide accurate reports on change activity.

Another tool incorporated into the CM Tool Mix is a tool which automates problem report tracking. Automated Problem Report Tracking Tools (APRTT) have a wide range of pricing from free to over $600 per seat. There are vendors which sell APRTTs which interface with other tools. Some are home grown by specific projects. Most every APRTTs does the basic problem report data entry and tracking reliably, but the functionality can vary dramatically. Serious evaluation of the candidates for acquisition is encouraged. For large projects, APRTTs eliminate, or greatly reduce the nightmare and flood of huge quantities of problem reports. Such systems also streamline reporting and enhance CM's ability to provide accurate status accounting.

Library Automation Tools (LATs) don't seem to be as common as the aforementioned tools. These tools automate the tracking systems for physical libraries or storage areas. Normally these are home-grown tools using what ever database or software is available to the configuration team. LATs benefit CM efforts by allowing users of a library or storage area to quickly identify the location of a stored item and retrieving it.

Work Flow Management Tools (WFMTs) are tools which automate and streamline the process for the entire project. There are some Vendored tools which incorporate this feature into existing tools, while other CM projects work to develop their own. WFMTs can have had dramatic savings in processing of problem reports, by reducing the 'wait' time for the next step in the process to be initiated.

Requirements Management Tool (RMT) is a tool that can be developed locally or purchased. It can be as simple as a spreadsheet or as complicated as cross-linked requirements management tools generating Requirement documents. It is very useful to make sure that all CM requirements are fulfilled.

-- DenisRoy? - 27 Feb 2003

The key to tool selection is to a) understand your environment, b) find what would benefit from automation, c) specify needs and requirements, d) test drive the tool and evaluate, e) make a decision.

-- SmKershaw? - 15 Feb 2003

Refer to an appendix for web site addresses for the various tools. Be sure to include CM tools for both hardware and software applications. -- SmKershaw? - 11 Feb 2003

5.2 REQUIRED RESOURCES

The kinds of resources required to support these tools go beyond simple funding issues for the tools themselves. Whether the tools are developed in-house or vended, there will need to be resources (time and energy) dedicated to training of project team members or CM team members or both in the use of these tools.

Many of the vended tools do not strictly follow the standards out-of-the-box. This is due to a particular school of thought which says that vended tools should be flexible enough to allow modification to the tools so they can be made to fit any business structure or process. Modification will be required in what is known as trigger development and manipulation. Sometimes Application Program Interfaces (APIs) are made available. There are many Configuration Managers who are not inclined or proficient at coding at this level and therefore may find the tools difficult to control. They may even find themselves unhappy with the results. If a Tools DBA is available on the teams operated by those Configuration Managers, then there will be success. Many have found that businesses frequently alter how they do business with CM Teams, and therefore trigger manipulation can be frequent. Those Configuration Managers fortunate enough to understand triggers and what has to be performed, may not feel the need for a Tools DBA, because they take on the role. The more trigger manipulation is required, the more resource time will be required, potentially taking too much of the Configuration Manager’s attention.

Tools developed in-house will definitely benefit from a dedicated resource working closely with the Configuration Manager to hone the functionality of those tools.

Another school of thought is that vended software should have an ‘out-of-box’ option that upon installation is ready to behave in accordance with a set of standards or life cycle methodology. Most vended tools these days do not have this feature. -- SmKershaw? - 16 Feb 2003

(Split and edited) -- CarildaAThomas? - 18 Feb 2003

---

Chapter 6: CM Activities and Schedules

Overview

In this section we will discuss the various activities, schedules with definitions, their sequences in the life cycle, and the nature of the duration for these activities. -- SmKershaw? - 18 Apr 2003

6.1 WHAT ARE CRITICAL CM ACTIVITIES?

There are traditionally six critical CM activities that are required for a successful Configuration Team to practice. Those six areas are

• Planning
• Acquisition and Support
• Configuration Identification
• Configuration Control
• Configuration Status Accounting
• Configuration Audits

-- SmKershaw? - 16 Feb 2003

6.1.1 Planning Activities

Planning of a Configuration Management program in accordance with a specified standard tailored appropriately for the particular configured item is important. Planning should be consistent with the objectives of a continuous improvement program which includes the analysis of identified problem areas. This planning should also include procedures for correction. The planning effort needs to include:

• the identification of objectives of the Configuration Management program;
• discussions about the Configuration Management organization and organizational relationships;
• defining responsibilities and authority of Configuration Management managers,
• discussions about CM resources such as tools, techniques and methodologies;
• descriptions of the coordination with internal and external groups like program managers, contractors, government agencies, CCBs, etc.;
• policies, processes, procedures, methods, records, reports and forms
• guidelines about acquisitions and support.

This planning effort will result in the development of a formal Configuration Management Plan, a Work Breakdown Structure (WBS), and technical reviews.

-- SmKershaw? - 16 Feb 2003

6.1.2 Acquisition and Support

All requirements for technical data with the effort to support the data handling, processing, storage, integrity, transfer, security and maintenance need to be described in the Configuration Documentation. This documentation needs to be maintained over the life of the project.

• Access to this information shall be limited in accordance with appropriate distribution statements, as well as by data rights, and Contract Data Requirements List (CDRL), distribution (if used) and security requirements.

• Automated processing and electronic submittal techniques should be used whenever possible.

• This integrated technical information service shall accommodate pre-defined queries and extraction of data.

-- SmKershaw? - 16 Feb 2003

6.1.3 Configuration Identification

The purpose of configuration identification is to incrementally establish and maintain a definitive basis for control and status accounting for a Configured Item throughout its life cycle.

Configuration identification shall include the selection of Configured Items. The determination of the types of configuration documentation required for each configuration item is all made. Configuration Management shall issue numbers and other identifiers affixed to the configured items and to the technical documentation that comprises the configured items configuration documentation.

Other things to be considered are the creation of a documentation/drawing/software/equipment library and associated procedures.

Specific Baselines also need to be defined. The Configuration Manager needs to define and document the content of configuration baselines. This would include creating a list of all items and support items for the product being configured for Functional, Allocated, Approved, and Product Baselines.

Any interface requirements need to be identified, tracked and managed, too.

-- SmKershaw? - 16 Feb 2003

6.1.3.1 CONFIGURATION IDENTIFICATION ACTIVITY

The sections that follow detail some concepts, principles, and activities concerning configuration identification as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.3.1.1. Configuration Identification General Concepts and Principles

The basic principles of configuration identification are citing the following purposes and benefits of configuration identification:

• Determines the structure (hierarchy) of a product and the organization and relationships of its configuration documentation and other product information

• Document the performance, interface, and other attributes of a product

• Determines the appropriate level of identification marking of product and documentation

• Provides unique identity to a product or to a component part of a product

• Provides unique identity to the technical documents describing a product

• Modifies identification of product and documents to reflect incorporation of major changes

• Maintains release control of documents for baseline management

• Enables a user or a service person to distinguish between product variantions

• Enables a user or a service person to correlate a product to related user or maintenance instructions

• Facilitates management of information including that in digital format

• Correlates individual product units to warranties and service life obligations

• Enables correlation of document revision level to product version/configuration

• Provides a reference point for defining changes and corrective actions.

-- DirkWessel? - 27 Feb 2003

6.1.3.1.2. Configuration Identification General Activity Guides

Configuration identification incrementally establishes and maintains the definitive current basis for Configuration Control and Status Accounting of a system and its configuration items (CIs) throughout their life cycle development, production, deployment and operational support, until they are no longer needed and disposed. {Edited. -- SmKershaw? - 27 Apr 2003 }

The Configuration Identification process ensures that all acquisition and efforts to sustain the project have common sets of documentation as the basis for developing a new system or modifying an existing component. This would include buying a product for operational use, and providing support for the system and its components. {edited. ---- SmKershaw? - 27 Apr 2003 }

The Configuration Identification process also includes using identifiers that are shorthand references to items and their documentation. Good configuration control procedures assure the continuous integrity of the configuration identification. The configuration identification process includes:

• Selecting configuration items at appropriate levels of the product structure to facilitate the documentation, control and support of the items and their documentation

• Determining the types of configuration documentation required for each CI in an effort to define its performance, functional and physical attributes, including internal and external interfaces. Configuration documentation provides the basis to develop and procure software/parts/material, fabricate and assemble parts, inspect and test items, and maintain systems {edited. -- SmKershaw? - 27 Apr 2003 }

• Determining the appropriate configuration control authority for each configuration document consistent with logistic support planning for the associated CI

• Issuing identifiers for the CIs and the configuration documentation

• Determine the Configuration hierarchy of an End-item.

• Maintaining the identification of CIs to facilitate effective logistics support of items in service {edited. -- SmKershaw? - 27 Apr 2003 }

• Releasing configuration documentation; and

• Establishing configuration baselines for the control of CIs. {Edited. -- SmKershaw? - 27 Apr 2003 }

Effective configuration identification is a pre-requisite for the other configuration management activities (configuration control, status accounting, audit), which all use the products of configuration identification. If CIs and their associated configuration documentation are not properly identified, it is impossible to control the changes to the items, configuration, to establish accurate records and reports, or to validate the configuration through audit. {edited. -- SmKershaw? - 27 Apr 2003 }

Inaccurate or incomplete configuration documentation may result in defective products, schedule delays, and higher maintenance costs after delivery.

6.1.3.2 CONFIGURATION ITEMS

Selected items of system hardware or software (or combinations of hardware and software), in which the customer or acquiring organization has configuration management concern, are designated as Configuration Items (CIs). {edited. -- SmKershaw? - 27 Apr 2003 }

The sections that follow detail some concepts, principles, and activities concerning configuration items as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.3.2.1. Configuration Item Concepts

CIs are the basic units of configuration management. They may vary widely in complexity, size and type, from an aircraft, ship, tank, electronic system or software program to a test meter or a round of ammunition. Regardless of form, size or complexity, the configuration of a CI is documented and controlled. CI selection separates system components into identifiable subsets for the purpose of managing further development. For each CI:

• There will be associated documentation (which may range from a performance specification to a detailed drawing to a commercial item description)

• Configuration changes will be controlled

• Configuration status accounting records will be maintained

• Configuration audits will be conducted to verify performance and product configuration (unless the CI has an already established product baseline).

To define and control the performance of a system or CI, does not mean that all of its hardware and software components must be designated as CIs, nor does it mean that the performance requirements for the non-CI components must be under configuration control. It depends on the overall requirements of the project or company configuration plan. If, for instance historical builds are required for the life of the project, ALL aspects of both the operational, test, developmental and production environments must be retained to provide for successful recreation. Albeit this is an extreme part of configuration management, but there are projects, specifically, military projects that require this kind of retention. {Edited. -- SmKershaw? - 27 Apr 2003 }

The requirements to be met by a lower-level component (which is not designated as a CI) are established and controlled via the Contractor’s design and engineering release process.

Control occurs only when changes to the lower level components impact the baselined performance specification for the CI. {Edited. -- SmKershaw? - 27 Apr 2003 }

Initial CI selection should reflect an optimum management level during early acquisition. Initially, for Engineering and Manufacturing Development (Phase II), CIs usually are the deliverable, and separately installable units of the system and other items requiring, significant management attention at Buyer/Seller interfaces (i.e., Purchaser/Prime Contractor, Prime Contractor/Subcontractor, etc.). During, production, fielding/deployment and operational support (Phase III), individual items required for logistics support and designated for separate procurement are also CIs. {edited. -- SmKershaw? - 27 Apr 2003 }

Computer software items, because they typically control the functionality of a system, are almost always designated as CIs. The term CI encompasses hardware, software and firmware. When a statement in this handbook applies only to hardware, or only to software, or only to firmware, the terms HWCI, CSCI and FWCI are used. {Edited. -- SmKershaw? - 27 Apr 2003 }

Typically the top tier of CIs directly relate to the line items of a contract and the Work Breakdown Structure (WBS). The determination of the need to designate them as CIs is normally simple and straight forward. However, there are many cases in which other lower-level items should also be selected based on the management needs of the project. Some of the primary reasons for designating separate CIs are:

• Critical, new or modified design

• Independent end use functions

• Sub-assembly factors such as the need for separate configuration control or a separate address for the effectivity of changes

• Components common to several systems

• Interface with other systems, equipment or software

• Level at which interchangeability must be maintained

• Separate delivery or installation requirement

• Separate definition of performance and test requirements.

• High risk and critical components

Although the initial CI selection generally occurs early in the acquisition process, its consequences are lasting and affect many aspects of project management, systems engineering, acquisition logistics, and configuration management.

CI selection establishes the level of configuration control throughout the system life cycle. {Edited. -- SmKershaw? - 27 Apr 2003 }

Selecting CIs separates a system into individually identified components for the purpose of managing their development and support. CI designation should reflect the optimum level for both acquisition and support. During acquisition, this is the level at which a contracting activity specifies, contracts for, and accepts individual components of a system, and at which the logistics activities organize, assign responsibility and report modification and maintenance actions during support. {Edited. -- SmKershaw? - 27 Apr 2003 }

During the concept exploration and the project definition and risk reduction phases, the system architecture is established, the project work breakdown structure is developed, and major CIs are selected. These activities provide the basis for the Supportability Plan for the project, which, in turn, dictates the selection of lower-level CIs.

Development, acquisition, retrofit, and hardware and software interfaces are all affected by the breakout of the key system elements into CIs during the early stages of the development effort.

-- DirkWessel? - 28 Feb 2003

6.1.3.2.2. Configuration Item Activity Guide

Many engineering requirements or considerations can influence the selection of CIs. Throughout development and support, the allocation of engineering and organization efforts are rooted in the selection of CIs. {edited. -- SmKershaw? - 27 Apr 2003 }

Developers should participate in the selection process and provide recommendations based upon engineering or other technical considerations.

Either the customer or acquiring organization may make initial recommendations of top-level CI candidates as a result of their system engineering analyses; however the developers are normally tasked to provide the comprehensive recommendations. {edited. -- SmKershaw? - 27 Apr 2003 }

CI selection criteria are applied to recommendations to decide on the items to be managed as CIs by the Configuration Management Team. {edited. -- SmKershaw? - 27 Apr 2003 }

Decisions to designate specific candidates as CIs and decisions on the time when they will come under CM control normally involve an integrated team of acquisition project management, systems engineering, and acquisition logistics working with configuration management. In addition, the configuration management team determines those items in the system that are not configured CIs, but which will be subject to lower tier configuration management by the CM team.

-- DirkWessel? 03 Mar 2003

6.1.3.2.3. CONFIGURATION DOCUMENTATION

The term configuration documentation characterizes the information that defines the performance, functional and physical attributes of a product.

All other product documentation (such as operation and maintenance manuals, illustrated parts breakdowns, test plans and procedures) are based on and relate to information in the configuration documentation.

The configuration documentation associated with each CI provides the basis for configuration control , logistics support, post-deployment software support, and re-procurement.

Usually a Purchaser/Customer/Project Manager specifies performance and, in most cases, leaves design solutions to the engineers. The Purchaser/Customer/Project Manager determines the system product structure level at which to specify, baseline and control item performance and the specification type to be used. Below this level the Project Management Team chooses the types of documentation to use. {edited. -- SmKershaw? - 27 Apr 2003 }

-- DirkWessel? 03 Mar 2003

6.1.3.3. Documentation Types

The sections that follow detail some concepts, principles, and activities concerning documentation as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.3.3.1. Specification Concepts

The selection of the appropriate specification document types is dependent upon a number of factors such as the maturity of the item, and the context and environment in which it must operate.

The order of precedence defined by policy should strongly indicate preference for the use of existing commercial products, wherever possible, and the choice of products meeting Performance rather than Detail Specifications

Program Unique Specifications, of both a performance and detailed nature, are at the bottom of the preference hierarchy and are used when the other choices are not available or applicable.

Nonetheless, acquisition projects dealing with the development of new systems will continue to see the use of program unique specifications where the specifications are being prepared for a single system or item and have little potential for future use except for repetitive fiscal year production and spares purchases.

Both the Purchaser/Customers/Project Managers and engineers should seize opportunities at lower levels of the specification tree (where developed items, referred to as non-developmental items (NDI) may be used) to select higher preference specification types, and to specify only performance and interface requirements rather than design solutions in those specifications, whenever possible. {edited. -- SmKershaw? - 27 Apr 2003 }

6.1.3.3.2. Specification Activity Guides

Industry

Standards or specifications published by industry associations or societies recognized as standards making bodies by the American National Standards Institute (ANSI), which define minimum acceptable performance and quality, or precise interface requirements for a category of product. Examples of industry associations are DIN, ASME, SAE, EIA; example of performance/quality standard is SAE 50 Motor Oil; examples of standard interfaces are electronic connectors, screw thread sizes.{Edited. -- SmKershaw? - 27 Apr 2003 }

Commercial

Commercial Item Descriptions (CID) are standard descriptions that by definition, are performance-based because they facilitate competitive bid for products meeting a stated functional requirement. Also commercial product descriptions (such as a manufacturer’s catalog or specification sheet) and commercial purchase descriptions (item descriptions to be spelled out directly in a purchase order) qualify under this category. {edited. -- SmKershaw? - 27 Apr 2003 }

Federal	Standards or specifications applicable to all agencies of the federal purchasing for items widely used. (They may be either performance or detail based){edited. -- SmKershaw? - 27 Apr 2003 }

Military

Specifications prepared for standard items with use in many different applications in weapons systems and their support equipment. These specifications are intended mainly for the competitive procurements of identical items for use as spares and for use in new weapons systems. Military Specifications are prepared in accordance with MIL-STD-961 and are listed in the DoD? Index of Specifications and Standards (DODISS). They are subject to the requirements of the Defense Standardization Program.

Standard Performance

Standard Performance Specifications (MIL-PRF) are performance specifications for items common to a number of different systems and subsystems. They follow the same guidelines as other performance specifications (see category b. below). They differ from Military specifications in that different, perhaps competing products that are not identical but meet the same form fit and function requirements may satisfy them.

Program Unique

Specifications for a system, item, software, process or material, unique to a specific acquisition program, prepared by either Purchaser/Customer/Project Manager or engineer to define and baseline requirements for development, production (including repetitive fiscal year production and spares purchases), support and re-procurement. Program unique specification format and content are defined in MIL-STD-961D.{edited. -- SmKershaw? - 27 Apr 2003 }

Table: Specification Types Categorized by Source

General, Associated and Specification Sheets

A general specification is one which facilitates the preparation of specifications for a number of items that are common except for specific variables such as size, power, range, etc. The General Specification defines the common requirements; the specific variables of each item are defined in either associated specifications or specification sheets. Associated specifications are used when the variables require a number of pages of specification language to define. Specification sheets are used when the variables can be numerically tabulated. Both are linked by specification number to the related general specification. Typically the general specification number followed by a slash and a serially assigned identifier identifies the associated Specification, or specification sheet. (Example: MIL-PRF-18/25)Where there is ambiguity (conflict) between the General Specification and the Associated Specifications or Specification Sheets, the latter governs because it describes the specifics of a product while the general specification encompasses a family of products.

Generic or Guide

A Generic or Guide Specification is a tool for preparing a number of similar specifications for a class of like end items to be developed. The guide specification is a “template,” which identifies all of the essential performance parameters normally associated with the class of item, but does not provide the specific performance capabilities. The specification is then tailored to fill in the blanks to create a specific system or item specification.

Table: Specification Types Categorized by Utility

System	A system specification defines the overall performance and mission requirements for a system, allocates requirements to lower level components of the system, and identifies system interface and inter-operability constraints. It is the top-level functional requirements specification for the system. A system specification is used to establish a functional baseline for the system. Large systems are usually decomposed; level two system components are often complex enough to be called "systems" themselves (although, for configuration management purposes, they are designated as Subsystems or CIs)
Item	The Item specification for a CI defines the performance and interface requirements and design and inter-operability constraints that have been allocated to the CI from a system or higher level CI. Item specifications provide the contractual basis for the development and verification of CI Performance. The item performance(development) specification(s)will normally be used to establish the allocated baseline for the CI.
Software	Computer Software Configuration Items (CSCIs) are documented with software specifications prepared in accordance with MIL-STD-961. A Software Performance Specification is similar to the Software Requirements Specification (formerly required by MIL-STD-2167A, and MIL-STD-498). A Software Detailed Specification is similar to the Software Requirements Specification plus the set of design documents describing the software, interface and database design.
Material	Material specifications are used where a raw material, mixture, or semi-fabricated material has been developed specifically for use with a particular item or system and is critical to the performance or design of the item. (Example a missile rocket motor solid propellant chemical mixture.) The material specification is called out in the CI(s) design documentation. It therefore becomes part of the product baseline of the CI(s). An item performance (product)specification(essentially the same document)or an item detailed specification(containing specific design requirements)isused to provide the contractual basis for acquisition of production quantities of the CI.
Process	Process specifications are used where a process (or service) has been developed specifically for use with a particular system/item and is critical to its performance or design. (A common Example – the curing process for the missile rocket motor solid propellant.) The process specification forms a part of the product baseline of the CI(s)

Table: Specification Types Categorized by Object

-- DirkWessel? 03 Mar 2003

6.1.3.3.3. Design Solution Document Concepts

The requirements of the functional and allocated baseline are basically design constraints on the development contractor.

The design solution evolves from the contractor’s design and development process during the engineering and manufacturing development phase of the life cycle. This process essentially converts the performance requirements of the baseline specification into a specific product definition that can be manufactured to produce a hardware item or compiled to produce a software item.

It is documented in design documentation for the hardware and the software comprising each CI.

For hardware, the design documentation may be in the form of engineering drawings and associated part lists (e.g. Bill of Material BOM), and the material and process documents that are referenced by the drawings.

In the current information environment, the primary design documentation source may be in the form of two or three-dimensional engineering models. In that case, a drawing is simply a two dimensional view of a model that exists in a data base file. Various models and product modeling tools may be employed. Engineering drawings may or may not exist as a central part of the product manufacturing process, depending on the product and the degree of automation technology employed.

In an automated development and production environment, an item is designed on the engineer’s workstation, manufacturing instructions are added at the manufacturing planner’s workstation and the results are fed directly to automated machinery that produces the item.

Commonly, items are designed using computer-aided design tools (like AUTOCAD, etc.) and engineering drawings are plotted for human checking and review. Where engineering drawings are required as a contract deliverable, they should be delivered in place, in a CALS compliant format.

For software, the design evolves through a software engineering process, using a variety of integrated tools, often called the software engineering environment, e.g., Computer-aided software engineering (CASE).

The process results in computer based versions of documentation, source, and executable code for every CSCI. The process the contractor employs to manage the automated software documentation (e.g., software library management and archiving) is similar to the process used to manage automated hardware documentation, although different tools may be employed.

Upon close examination, it is fundamentally the same process used to manage the files, which contain software code. The same business rules apply to both software and documents in terms of their identification and relationships to other entities.

The developmental configuration documentation to be managed by the development contractor consists of the design and technical data under the contractor's internal control. Some of this data may transition to Purchaser configuration control and be designated as the Purchaser Product Baseline; some of it may remain under Contractor configuration control and be designated as Contractor Product Baseline.

The developmental configuration management process implemented by the development contractor consists of a formal process to control the documentation and repositories containing the elements of the developmental configuration.

The contractor's engineering release system and engineering release records are an important part of this management process. Each and every version of all elements of the developmental configuration released, for whatever purpose, should be maintained, along with the reasons the version was released, and the rationale for superseding the previous version.

6.1.3.3.4. Design Solution and Software Documentation Activity Guide

The below tables provide detailed information concerning the documentation used to document the design solution.

They also contains a complete set of software documents that are used for planning, system and software requirements analysis, software integration and testing, software product definition, operation and maintenance in addition to design description.

Several software design description documents can evolve from earlier versions used to support one or more of these other functions. The Purchaser needs access to some of these documents to the extent necessary for logistic support and software maintenance during the operational support period. This activity guide therefore addresses the documentation that can evolve over the full life cycle of a system/CSCI.

Detailed design documents for the CIs and CSCIs that the Purchaser will support will be made accessible from a Purchaser repository. Meta-data concerning these documents will be available from CM Automated Management Information System (CAIMS) provided that the information that the Purchaser requires the contractor to load into these systems is specified in the contract.

Definition
A drawing is an engineering document or digital data file that discloses the physical and functional requirements of an item (directly by means of graphic and textual presentations, or by reference). Drawings communicate a variety of information, both textual and graphic. All drawings have certain common elements. Normally several types of engineering drawings combined into sets with associated lists are required to completely define the end-product requirements of an item. Drawings may be categorized into the following MIL-DTL-31000 Technical Data Package(TDP) elements: * Conceptual design drawings * Developmental design drawings * Product drawings * Commercial drawings * Special inspection* equipment drawings * Special tooling drawings.
Drawing Types & Applications
* Detail, assembly, control, installation and diagrammatic drawings, as necessary, provide engineering description and control of product attributes. * Ancillary drawings (drawings supplementing end-product drawings) and special application drawing types aid logistics, configuration management, manufacturing, or other functions. * Additional project-unique types: procurement control, design control, vendor item control, microcircuit drawing set, paint scheme, software, transportability, camouflage basis and pattern, combination of adopted items, kits, package content.
Common Drawing Sheet Sizes and Format
* Drawing sheet sizes, Standard sizes for engineering drawing sheets, e.g., A, B, C, etc. * Title block - Design activity name and address, drawing title, drawing number, drawing size, CAGE Code, drawing scale, drawing sheet size, number of sheets (for a multi-sheet drawing). Most formats include drawing approval authority and angle of projection symbols. * Revisions block – Usually in the upper right hand corner. See Revisions to drawings, below. * Optional blocks – Additional blocks may be included on a drawing format adjacent to the Title Block. Examples: Application Block and Mechanical Properties Block.
Drawing Variables
* Media -Hard copy – Single sheet, multi-sheet, tabulation, book-form, drawings for microcircuits -Digital - Magnetic tape, Raster Image, IGES, PDES/STEP representations. * Format -Contractor – Contractor title block, CAGE code and process -Purchaser - For repetitive re-procurement of identical items, Purchaser title block, CAGE code and release control * Detail options -Mono-detail - Each drawing covers a single part or assembly -Multi-detail - A drawing may cover an assembly and detail parts - Dimensioning and tolerancing - Several conventions may be chosen - Drawing notes – Short, concise statements providing clarification. They may apply to the entire drawing or any portion of the drawing. Notes do not include contractual requirements or Requirements for data submission, approval or distribution. Preferably Notes are located on sheet 1 of the drawing, or direction is included on sheet 1 indicating location of notes, i.e., on parts list, or separate associated list.
Associated Lists

|- Parts list - a tabulation of all parts and bulk materials (except those materials which support a process) used in the item to which the list applies. Parts Lists may be Integral Parts Lists, prepared and maintained as part of the actual engineering drawing, or Separate Parts Lists, prepared as a document separate from the drawing with which it is associated and maintained independently from that drawing. - Data list - a tabulation of all engineering drawings, associated lists, specifications, standards, and subordinate data lists pertaining to the item to which the data list applies - Indentured data list - that is structured by successive assembly level - Index list -- a tabulation of data lists and subordinate index lists pertaining to the item to which the list applies - Wire list - a tabulation of all the wires in an assembly which indicates their identification and terminations - Application list - a tabulation of parts and the next higher assemblies into which they install. (Commonly referred to as a where used list.)|

Revisions to Drawings
- Drawing revision identification - Any change to a drawing, including a change to Rights-in-Data, must be recorded in the revisions block of the affected drawing. - Record revision status, identification of change authorization documents, or description of changes, and change approvals, and if multi-sheet, revision status of sheets Note: If revision history is maintained in a data base, common practice is to provide it as part of an associated list (e.g. parts list) or via data base access rather than on the field of the drawing
Numbering Coding and Identification

|- Drawing and part identification rules liberal enough to accommodate a wide variety of industry practices. Any keyboard characters allowed. - Limited to precise drawing and part identification discipline necessary to provide unique identification for military equipment (e.g., use of CAGE codes, part identity keyed to drawing identity) - Original and current design activity; design disclosure, delivery of drawing originals - Drawing title conventions - Special markings, symbols and part/item replacement notations - Marking for shipment and storage - Special items and processes (e.g., system safety, electrostatic discharge) - Type designators|

Drawing Requirements Manual (DRM)

Tailoring and Application Guides. -Drawing or Drafting Manuals are a reference defining in-house practices and extent of applicability of Standards. Purchaser activities use tailoring or application guides. -The DRM guides and standardizes drawing form and presentation, facilitate communication (of intent and technical detail), assure consistent quality, simplify training, and provide a basis for improving practices.

Table: Engineering Drawings and Associated Lists

Process Implementation - Planning

Acronym	Description	MIL-STD-961 Equivalent	Config. Doc?Baseline Doc?
OCD	Operational Concept Document – proposed system; user needs	No MIL-STD-961 Equivalent: These Documents are not Specifications	Not configuration documentation. Data Control Only (i.e., Baseline internal to developer for document, document representation and file management purposes only).
SDP	Software Development Plan - development effort; process, methods, schedules, organization, resources. (Includes or refers to SCM & SQA plans)
STP	Software Test Plan – Qualification testing; SW item; SW system; environment, tests, schedules
SIP	Software Installation Plan - installing SW; user sites; preparations; training; conversion
STrP?	Software Transition Plan – transitioning to maintenance Organization; HW; SW; resources; life cycle support.

System Requirements Analysis & Architectural Design

Acronym	Description	MIL-STD-961 Equivalent	Config. Doc?Baseline Doc?
SSS	System/Subsystem Specification – Specifies system or subsystem Requirements; requirement verification methods. (May be supplemented with system level IRS)	-Program Unique System Performance specification	- Functional or Allocated Baseline
SSDD	System/Subsystem Design Description – system/subsystem-wide design; architectural design; basis for system development. (May be supplemented with IDD, DBDD)	Part of Program Unique System Detail specification	Design release

Software Requirements Analysis & Design

Acronym	Description	MIL-STD-961 Equivalent	Config. Doc?Baseline Doc?
SRS	Software Requirements Specification - specifies SW requirements; verification methods. May be supplemented with IRS)	Part of Program Unique Software Performance or Detail Specification -Purchaser or Contractor)	Allocated Baseline for CSCI
IRS	Interface Requirements Specification - specifies interface requirements for one or more systems, subsystems, HW items, SW items, operations or other system components; any number of interfaces (Can supplement SSS, SSDD, SRS)	Part of Program Unique Software Performance or Detail Specification	-( Purchaser or Contractor)Allocated Baseline for CSCI

Software Architectural and Detailed Design

Acronym	Description	MIL-STD-961 Equivalent	Config. Doc?Baseline Doc?
SDD	Software Design Description – SW item-wide design decisions; SW item architectural design; detailed design, basis for implementing; information for maintenance (May be supplemented by IDD, DBDD)	- All are part of Program Unique Software Detail Specification	-All are Config Doc - Design release
IDD	Interface Design Description – interface characteristics; one or more systems, subsystems, HW items, SW items, operations or other system components; any number of interfaces; detail companion to IRS; communicate and control interface design decisions (Can supplement SDD, SDD)	- All are part of Program Unique Software Detail Specification	- All are Config Doc -Design release
DBDD	Data Base Design Description – data base design; related data, files, SW/data base management system for access, basis for implementation and maintenance	- All are part of Program Unique Software Detail Specification	- All are Config Doc -Design release

Software Integration and Qualification Testing

Acronym	Description	MIL-STD-961 Equivalent	Config. Doc?Baseline Doc?
STD	Software Test Description - test preparations; test cases; test procedures; qualification testing SW item, SW system or subsystem	- No MIL-STD-961 equivalent. These documents are not specifications	-Not configuration documentation. - Data Control - Evaluate change to config docs for impact on these test docs
STR	Software Test Report - record of test performed; assess results.	- No MIL-STD-961 equivalent. These documents are not specifications	-Not configuration documentation. - Data Control - Evaluate change to config docs for impact on these test docs

As-Built Software Product Definition

Acronym	Description	MIL-STD-961 Equivalent	Config. Doc?Baseline Doc?
SPS	Software Product Specification – Contains or references executable SW, source files; SW maintenance information; “as-built” design information, compilation, build, modification procedures; primary SW maintenance document	- Part of complete Program Unique Product Detail specification	- Product baseline; either Purchaser or Contractor
VDD	Version Description Document – identifies and describes a SW version; used to release, track and control each version	- No MIL-STD-961 equivalent: This document is not a spec	- Not baselined. Status Accounting record for released SW Version

Table: Software Documentation

-- DirkWessel?- 11 Mar 2003

6.1.3.4. DOCUMENT AND ITEM IDENTIFICATION

This section describes the concepts for the assignment of identifiers to CIs, component parts and their associated configuration documentation. Clearly identified items and documentation are essential to effective configuration management throughout the life cycle, particularly during the deployment and operational support period when the marking on a part is the key to installing a correct replacement part and finding the proper installation, operation and maintenance instructions.

Identification consists of Numbering and Naming.

The sections that follow detail some concepts, principles, and activities concerning document identification as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.3.4.1. Document Identification Concepts

A document identification principle is that each configuration document (as well as other documents) must have a unique identifier so that it can be associated correctly with the configuration of the item to which it relates.

In the principle the following three elements are used to assure the unique identity of any document: source of document, document type and document identifier. In addition, revision identifier and/or date clearly specifies a specific issue of a document.

A document can have many representations, as for example a word processor file and a paper copy; a CAD file and a representation of that CAD file inserted in a document.

In addition to the identification assigned to each document, the digital files for each version of each representation of the document, and its component files must be identified and managed.

It is the responsibility of each individual assigned to manage an item of configuration documentation to employ the appropriate procedures of his organization which ensure:

- The assignment of identifiers to the configuration documentation, including revision and version identifiers, when appropriate, and procedures to control the engineering release of new/revised data.

- The application of applicable restrictive markings.

6.1.3.4.2. Document Identification Activity Guide

Document Identifier

CAGE Code or NSCM (NATO Supply Code for Mfg.)

CAGE (and NSCM) Codes identify the source of the document The codes are affixed to all CIs, and their replaceable subordinate parts and assemblies. They are also part of the identification marking of each item of configuration documentation, software media and software product.

Document Identifier

The document Identifier distinguishes one document produced by the organization referenced by the CAGE code from another. Each document and each revision thereto, requires the document identifier. There are as many schemes for identifying documents as there are organizations producing them, so there is no standard format for all documents. There are however, a few common sense constraints on the numbering content for some specifications, and engineering drawings, as defined in applicable standards

Revision/Version identifier

Revision Identifier	Revision Identifier clearly establishes which issue of a particular document is current or applicable.
Version Identifier	Conceptually the same as revision, version is the term typically used for files
Date	Date is an additional discriminator. It is good common sense business practice to date every document and every revision

Restrictive Markings:

These requirements apply to digital data files and digital media as well as to paper documents and are all intended to limit the access to such data to those entitled to access them.

Security Markings	Security markings are required to be clearly marked on all classified data and special handling requirements apply. Each contract contains classification guidance and direction, which must be strictly adhered to.
Distribution Statements	Specific distribution statements and export restrictions must be marked on information subject to secondary distribution limitations as prescribed by law and as indicated by the contract. The purpose of these markings is to inform the secondary distributor, such as a Purchaser repository whether they can legally provide the subject information to third parties, and if the data are allowed to be exported to foreign countries.
Data Rights	Documents which contain data for which the Purchaser or other parties do not have unlimited rights, must be appropriately labeled to indicate the data rights limitations, so that proprietary information disclosed to the Purchaser for specific purposes is protected.

6.1.3.4.3. Item Identification Concepts

The following principles apply to the Identification of Configuration Items:

- All products (Configuration Items) are assigned unique identifiers (e.g., Nomenclature, Cage Code, Part/Item Number) so that one product can be distinguished from other products; one configuration of a product can be distinguished from another; the source of a product can be determined; and the correct product information can be retrieved.

- Individual units of a product are assigned a unique product unit identifier (Serial Number) when there is a need to distinguish one unit of the product from another unit of the product.

- When a product is modified, it retains its original product unit identifier (Serial Number) even though its part identifying number is altered to reflect a new configuration.

- A series of like units of a product is assigned a unique product group identifier (Lot Number or Date Code) when it is unnecessary or impracticable to identify individual units but nonetheless necessary to correlate units to a process, date, event, or test.

Contractors assign identifiers including serial and lot numbers to CIs and their component parts, as necessary to establish the CI effectivity of each configuration of each item of hardware, software and firmware.

Items are marked or labeled with their applicable identifiers to enable correlation between the item, its configuration documentation, and other associated data, and to track maintenance and modification actions performed.

Thus, serial and lot numbers are also known as tracking identifiers. For software, applicable identifiers are embedded in source and, when required, in object code and in alterable read-only memory devices (firmware).

-- DirkWessel? - 18 Mar 2003

6.1.3.4.3.1. Software Identification

The identification of software is performed for Computer Programs, Software Files, File Identifier Fields, Source Files, Object Files, Executable Files, and Patches.

When we speak of Computer Program Identification we recognize that software is identified at two levels. It is identified at the configuration item level and at the file level.

The table below shows the typical identifiers at the computer program level.

Name	Acronym	Identifier
Operation System	OS	Partnumber
Office Package	OP	Partnumber

These identifiers provide common identification for the collection of items that make up the computer program, and serve as an address for all actions and documentation applicable to that computer program.

Software File Identification includes the identification of the code itself. Code is usually identified at the individual file level, and there are three different types of software files to be identified (Source, Object and Executable). Software is identified at the file level, and each file identifier has three fields that can be used:

- the filename number,

- the file type and the

- version number.

Source Files are the input to the code generation process and are uniquely identified using the file name number, file type and version number. Object files result from passing the source code through a compile or assembler, which changes the statements of the source code to machine language. In this transformation: - The file name number remains the same as the source file name

- The file type is changed

- The version number is changed to the next higher number from the highest version number of the existing object file

An executable file results from the linking of a number of object files and its identified by file name number, file type and version number. Recognizing, that many object files will be merged into one executable file, it is considered best to specify the executable file name at the time of generation. This is usually a name and number meaningful in the computer program’s context.

The use of patches (code introduced into executable files) should be limited to the really necessary extent needed, however there are circumstances in which there is no other choice. If patches are to be used, an identification scheme is required. Patches are identified as executable files, and the identification fields include the filename number, file type and the version number.

{This section consolodated and edited -- SmKershaw? - 25 Jul 2003 }

6.1.3.4.3.2. Hardware Identification

The other major component that is typically configured is Hardware. Hardware identification includes identifying through the use of Part/Item Identification Numbers (PN) and Additional Identifiers.

The developing contractor assigns a discrete part/item identification number (PN), generally referred to as a part number, to each CI and its subordinate parts and assemblies. The part number of a given part is changed whenever a non-interchangeable condition is created.

The format of the Part number is optional and a wide variety of formats are employed. Some contractors employ a mono-detail system in which one part is detailed on one drawing, and the drawing and the part number is the same.

For practical reasons, some employ a multi-detailing system in which the drawing number may detail several parts and assemblies. Others use tabulated mono-detail drawings in which a drawing includes several iterations of a part. In the latter two cases, the drawing number is a base to which dash numbers are assigned for discrete parts controlled by that drawing.

The significant criteria are as expressed in the principles above: The part number must uniquely identify the specific part and unless otherwise specified, all CIs including parts, assemblies, units, sets and other pieces of military property are marked with their identifiers.

In combination with the Part Number the manufactures code (Cage Code, NSCM) should be used to clearly identify an item. Manufacturers normally produce items in lots. A lot, is a collection of identically manufactured items that have been treated as a unique entity. If, due to some anomaly in the manufacturing process, items from a particular lot have failures, they can be identified easily by its lot number For this reason items are usually marked with the manufactures lot number and the date of manufacture.

Items that are repairable are usually assigned a serial number. It enables a unique identification of repairable items and allows to track this item through a logistic system. End-items have usually in addition a model-number

{This section consolodated and edited -- SmKershaw? - 25 Jul 2003 }

6.1.3.4.3.3. Firmware Identification

Firmware is a combination of a hardware device and computer instructions, or data, which resides as read-only software on it, where the software can not readily being modified. Both the hardware as the software needs to be identified as well as the firmware itself.

There are three items that require consideration. First, the basic hardware item, which is identified as any other hardware item. Second, the Software to be embedded in the hardware part. Third, the production of an image file from the previously produced executable file.

{This section consolodated and edited -- SmKershaw? - 25 Jul 2003 }

6.1.3.4.3.3.1. Image File considerations

An image file is an structured collection of executables, formatted in accordance with the requirements of the device that places the image file on the hardware.

The formats can vary widely, but there are two items that require configuration management attention. First, the format is a manufacturing interface and must be stated explicitly. Second, there are advantages to some formats in terms of being able to add headers, which include the image file identifier. Should the external markings on the hardware part itself be obscured, the use of the software header provides additional insurance.

{This section consolodated and edited -- SmKershaw? - 25 Jul 2003 }

6.1.3.4.3.4. Serial and Lot Numbers

CIs are the address for effectivity of subordinate parts, and for the effectivity of changes to subordinate parts. This means that the effectivity of a part is expressed in terms of the range of serial numbers of the CI end item into which it is assembled.

Note: There are other ways of expressing the effectivity, particularly in commercial industry, but whether lot, block, FY contract, date or other term is used, it must translate as closely as possible to which serial numbered CIs will have the part installed.

There are also several kinds of related serial numbers that are employed in a CI production phase. The Purchaser normally identifies the serial numbers to be affixed by the contractor on Purchaser designated deliverable CIs.

Purchaser serial numbers are in a variety of formats depending upon the type of equipment and the policy of the acquisition command. The issuance of Purchaser serial numbers should be avoided where the contractor has an acceptable process for assigning unique serial numbers. Among other impacts, it increases Purchaser administrative expenses in maintaining serial number block assignment logs for numbers of items (and for multiple suppliers of those items) for the Purchaser inventory.

Contractors assign serial numbers to units in production. All engineering, manufacturing and quality data will refer to the serial numbers.

These serial numbers may or may not correspond directly to the serial numbers to be marked on parts or nameplates (delivery numbers), because for various reasons the shop units may not complete the manufacturing process in sequence, or some units in the flow may be sent to another customer.

Where impractical to serialize individual units, because of quantity or composition of the part or material, lot numbers are employed to identify a group of identical parts.

Typically lot numbers are employed for subordinate parts below the CI level, but occasionally, they are appropriate at the CI level, as for example with rounds of ammunition.

The lot numbers are controlled and are subject to the same constraints as the serial numbers.

The important factors, in evaluating a contractor’s system of item identification is that there must be an effective process for controlling the effectivity of parts by serial number (either shop number or delivery number). A comprehensive cross-reference must be maintained between the shop number of an item and its delivery serial number, or for lot-controlled items, between the manufacturing lot and the delivery lot.

{This section consolodated and edited -- SmKershaw? - 25 Jul 2003 }

6.1.3.4.4. Naming Activity Guide

Naming Conventions are often weak or nonexistent because it is difficult to maintain consistency in the way various items are described.

A physical item should be described after it has been assigned a proper name. A generic noun which best describes the item is the proper name. Consistency is hereby essential.

The first step is to select a noun which may or may not be a preferred noun. It may be an alias of a preferred noun. The system will respond in either case and confirm the preferred noun or identify the preferred noun if the initial entry was an alias.

Once this first step is achieved, the system should provide step-by-step “prompts” for describing key attributes of the item. There may still be uncertainty after selecting a noun from the aliases.

The descriptive attributes must be identified in their describing order of significance for each preferred noun.

The following example shows how one organisation chose to describe the attributes of “Bolts” in their descending order of significance.

Preferred Noun	First Attribute	Second Attribute	Third Attribute	Fourth Attribute	Fifth Attribute	Sixth Attribute
Bolt,	Steel,	Hex,	SAE5	CAD	0.50-20	X3.00

6.1.3.4.5. Item Identification Activity Guide

The below Table provides details about item identification, including hardware, software and firmware.

Identifier Element	Definition/Requirement
Item Identifiers
Nomenclature	- Contract must specify items or types of items to be assigned nomenclature - Nomenclature requested from Purchaser: in accordance with specified requirements - Contractor assigns nomenclature in accordance with guidelines - Purchaser approves nomenclature - Nomenclature is revised when necessary to account for a non-interchangeable condition
Part/Item Identification Number (PN)	- Uniquely identify the item (when combined with the item's design CAGE code) - All CIs, parts, assemblies, units, sets - PN is the same as, or contains, drawing or other design document number - Assigned by developing contractor - Changed (e.g. new dash number) when part is modified and a non-interchangeable condition is created
Serial and Lot Numbers (Product tracking identifiers)	- Uniquely identify an individual unit or specific group of units of an item (when combined with the manufacturer's identifier, e.g., CAGE Code, and the basis for serialization -- product-tracking base identifier.) - When applied to CIs, are the basis for effectivity of subordinate parts - Purchaser may designate serial numbers for deliverable CIs. If the Purchaser provides no serial numbers, the contractor will serialize each delivery unit according to his own system and convention. - Serial and Lot numbers are unique, consecutive, and non-duplicating for a specific nomenclature or part identifier. - The original serial number of a unit/item/CI is not changed even when a change affecting interchangeability may require rework and re-identification. - Once assigned, serial numbers and lot numbers are never re-used for the same item. This rule applies to all types of serial numbers including delivery serial numbers and shop numbers as well. - It applies to lot numbered items to the extent practicable; if rework occurs by lot, in different lots than original manufacture, this rule is may be broken with the understanding that traceability to the original lot must be recorded.. - There should never be two items with the same part number and the same serial number produced by the same manufacturer. - Serial and Lot Numbers must be assigned against a non-changing base, known as a product tracking base-identifier.
Software Identifier	- Each CSCI shall have an identifier consisting of a name and number. It uniquely identifies the software when combined with the CAGE code or name of the company that developed it. - Each Version of the Software CSCI shall have a version identifier supplementing the software identifier - Software units, at and below the CSCI level, are identified using developing contractor convention, typically the conventions of the software language in which it is written
Firmware Identifiers	- Where both the hardware device and the embedded code are documented and controlled via the same engineering design document (drawing), the PN for the device with code embedded identifies the firmware - Where the hardware device and the software to be embedded are documented and controlled separately, the device is identified by a PN and serial number; the embedded software is identified as a CSCI
Hardware Marking and Labeling
Items with assigned Nomenclature, Nameplated Items	- Contain the following identification information on their nameplates: - Nomenclature - Design Activity CAGE code and name - Part Number - Serial Number (Normally applicable; Lot Number if Serial Number is not applicable) - Manufacturer - Acquiring Purchaser Activity - Contract Number under which it is acquired - National Stock Number, if applicable - Bar-coding, if specified, typically containing NSN and selected information above such as part and serial numbers
All Items large enough to legibly mark	- Design CAGE code (or other industry source identifier, if applicable) - Part Number - Manufacturer (CAGE code or name) - Serial or Lot Number, if applicable - Standard Number (MIL or commercial) if applicable
Small items	- Reference designator (on part or adjacent to it, as on a circuit board) relating the item to a documented record, or as in the case of electronic components, to an element on a schematic diagram - Striping, and or color coding, as on resistors and capacitors and other components, which indicate their values and tolerances according to industry standards
Software Marking and Labeling
Software identifier and version identifier	- Are embedded in the source code for the CSCI - Means are provided to display identifiers for installed software to user upon software initiation or upon specific command - In mission critical situations, identification of the correct software version may be verified as part of system self-check; as well as during system test following equipment repair or maintenance.
Software media identifiers	- Each software medium (for example, magnetic tape, disk) containing copies of tested and verified software entities is marked with a label containing, or providing cross-reference to, a listing of the applicable software identifiers of the entities it contains. - Media for deliverable CSCIs are labeled with the Purchaser contract number, the CAGE code and CSCI software identifier, the PN (if any), and the media number (for example, 1 of 2, 2 of 2) if there are multiple units per set and copy number (Copy No. 1, 2, etc.) of the medium or media set (if there is more than one copy being delivered).
Firmware Marking and Labeling
Non-re-programmable	- PN representing the device with software embedded is marked on device, or if device is too small on an adjacent assembly
Programmable	- PN of device (without software) and serial number of device, if applicable, is marked on the device - For software labeling, see "Software identifier and version identifier" above. Device marking does not change when software is loaded or reprogrammed.

Table: Item Identifier Guideline

6.1.3.4.6. Achieving Valid Documentation

Signatures are used to signify that a document has been reviewed and validated. Gathering the required signatures is an important process.

Sometimes it is also a heavy burden to obtain the various signature levels.

Very often the number of signatures on a document is used to demonstrate its integrity.

6.1.3.4.6.1. Documentation Signatures

Signatures are used to signify that a document has been validated. Gathering the required signatures is an important process. The importance sometimes implies the implementation of various signature levels. Very often the number of signatures on a document is used to demonstrate its integrity.

The different types of documentation often include signature blocks.

This signature block is used for validation and release of the document.

Although the signature block may include any number of spaces for signatures, it does not mean that each space must be used.

The adequate level of signatures can be achieved by answering the following questions:

- How many signatures are really required to revise a single document?

- Should separate signatures be required for each affected document regardless of how many documents are affected by the same change?

- Should required signatures be determined on a change-by-change basis or on a document-by-document basis or both?

A general answer can not be given. The required number of signature depends on various issues.

To facilitate and improve the release process the following points could be considered:

- Relatively complex documents (residing at End-Item Level and above) should be validated by each member of a cross-functional team.

- Less complex documents (below End-Item level) should be validated by only two individuals, the “creator” of the document as the first signature and a “user” of the document as the second required signature. The creator is the one who best understands the higher level requirements and is the co-owner.

Once a newly created document or a revised document is ready for validation, an actual user should have that responsibility.

If the document has more than one user, one of those users should be designated representing the user community.

The designated user is responsible for assuring that the document will be free of difficulties for all users.

Such signatures serve as a proof that the document is clear concise and valid for all who use it for its intended purpose.

--Main.DirkWessel - 18 Mar 2003

6.1.3.5. CONFIGURATION HIERARCHIES

Configuration Hierarchies, also referred to as system / administrative architecture, refers to the identifiers, internal structure, and relationship of components and associated documentation. Configuration Hierarchies may be depicted graphically as a tree structure or as an indentured listing.

The sections that follow detail some concepts, principles, and activities concerning configuration hieracharies as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.3.5.1. Configuration Hierarchy Concepts

6.1.3.5.1.1. Physical Item Hierarchy

During its early phases, the systems engineering process produces the optimized functional and physical composition of the system architecture to the level that it is necessary for the Purchaser to specify and control item performance.

This is typically the lowest level at which CIs are designated during the Engineering and Manufacturing Development Phase of the life cycle.

During acqusition the Engineering environments is using often specification and drawing trees, and work breakdown structures are to display the views of the product structure which are directly related at the CI level.

Project and contract Work Breakdown Structures (WBS) are views of the product family tree structure showing the hardware, software, services, data, and facilities against which costs are collected. The WBS relates the elements of work to be accomplished to each other and to the end product. CIs are identified as work breakdown structure elements. Uniform element terminology, definition, and placement in the upper three levels of a WBS are common for many categories of defense materiel.

The WBS is extended to lower levels by the purchaser component and contractor(s).

Each end item product represents a hierarchy of physical items. Each item has at each level its own unique set of supporting documentation.

Such a hierarchy provides an ideal framework within which all supporting documents and/or data sets can be efficiently managed.

Figure: Physical Item Hierarchy

Hierarchies can be established for products, services, facilities, IT Solutions etc.

6.1.3.5.1.2. The “WHERE-USED” Problem

Lets take an practical example to describe this problem.

A computer system fails and causes a major delay in a production line.

There is an intense interest in allocating the problem which causes this situation and taking the necessary steps to overcome this problem.

After analysing the situation, it may be determined that lately someone replaced a part in the system with a alternate part. Engineering analysis indicates later that the overall system design is sound, but the system failed because of an unreliable component used.

The question immediately arising is, where else is that alternate part used? Identifying all the assemblies where the alternate part is used can only be done if that configuration identification capability has already been implemented in the Configuration Management System.

From this where used example you can see also the need to provide additional information on the “as-build” documentation such as the manufactures code, lot number, and date of manufacture.

The “WHERE-USED” problem is already very complex, but think about it how difficult it might be in the area of software, when the software reuse grows.

What happens when:

(1) a vendor of a group of mathematical algorithms discovers that, under certain conditions, a particular release of a product produces incorrect results;

(2) hardware manufactures have purchased and incorporated those algorithms in their products as either firmware or support software; those products have been used to compute flight data of a missile. Immediate corrective is required, and the first thing to look at is the “Where used”.

6.1.3.5.1.3. Administrative Hierarchy

Above we have seen the Physical Item Hierarchy which describes the paren-child relation from the End-Item to the lower level items.In order to achieve the business objectives ,an Enterprise has also to establish a hierarchy of administrative requirements.

Regulations for running the business are the highest level.

The business requirements will be flown-down from a high level mission statement and a Strategic Business Plan into lower-level Standards, Procedures and Work Instructions.

Figure: Administrative Hierarchy

6.1.3.5.1.4. Linkage of Primary Items to Documents

Each item residing at each indenture level in a physical item hierarchy should have its own unique set of supporting documentation and data. Although the type of documents or data sets vary with the type of items, items of the same type usually require the same types of data sets.

Each item, is linked by its Partnumber to each of its supporting documents by type, identifier and revision level.

Following the CMII concept, Physical items that reside within the hierarchy of the End-item are categorized as primary items.

The supporting documents that are linked directly to a primary item are categorized as primary documents.

Secondary items are represented by equipment and tools used to develop, produce, operate and/or maintain primary items.

There are two types of secondary documents.

• The documentation which support secondary items such as tools and equipment is one type.

• Standard instructions for performing repetitive processes such as painting, soldering, compiling etc. are a second type.

Secondary items should be linked to the process plan for the primary item on which they are used. The process plan describes how the tools and equipment are to be used to accomplish the process.

6.1.3.5.1.5. Administrative Hierarchy and Linkages

The proper structuring and linking of administrative requirements from the mission statement and strategic business plan at the higher levels to the operating standards and supporting procedures at the lower levels, are important.

6.1.3.5.1.5.1. Mission Statement and Strategic Business Plan

A mission statement serves to state the purpose of the organisation. It is followed by a Strategic Business Plan, describing how the purpose will be accomplished.

The plan should consists of, but not limited to:

• Mission Statement which is a High level statement of the business objectives

• Relationship to other divisions/sites/partners that discusses interdependencies

• Organizational Hierarchy and personnel policies

• Products, services and customers and their perceptions in market-place and market share.

• Core business processes and operating standards that address how the day-to-day operations are conducted.

• Financial performance and projections for the past, present and future.

• Human resource development and training, education and career developement.

• Compensation and incentive plans

• Internal and external audits, performance measurements.

• Introduce a CM Controlling and Reporting System

• Product, process and administrative improvements

--Main.DirkWessel - 25 Mar 2003 {This section consolodated and edited -- SmKershaw? - 25 Jul 2003 }

6.1.3.5.1.6. As-Designed versus As-Build Hierarchies

6.1.3.5.1.7. Logistic Concept Influence Structure

6.1.3.5.1.8. Bills of Material

6.1.3.5.1.9. As-Planned Hierarchy for the End-Item

6.1.3.5.1.10. Reidentification

6.1.3.5.1.11. Exchangeable Items

6.1.3.5.1.11.1. Use of exchangeable items

6.1.3.5.1.11.1.1. Interchangeable Items

6.1.3.5.1.11.1.2. Substitute Items

6.1.3.5.1.11.1.3. Replacement Items

6.1.3.5.1.11.2. Considerations in using exchangeable items

6.1.3.6. CONFIGURATION BASELINES

The sections that follow detail some concepts, principles, and activities concerning configuration baselines as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.3.6.1. Configuration Baseline Concepts

6.1.3.6.2. Configuration Baseline Activity Guides

6.1.3.6.2.1. As-Planned and As-Released Baseline

6.1.3.6.2.1.1. Content, Format and Application

6.1.3.7. Libraries

The sections that follow detail some concepts, principles, and activities concerning libraries as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.3.8 INTERFACE MANAGEMENT

The sections that follow detail some concepts, principles, and activities concerning interface management as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.3.8.1. Interface Management Concepts

6.1.3.8.2. Interface Management Activity Guide

6.1.3.8.3. Interface Control Working Group (ICWG)

-- DirkWessel? 20 Feb 2003

6.1.4 Configuration Control

Configuration Control is the systematic proposal, justification, evaluation, coordination, approval or disapproval of proposed changes, and the implementation of all approved changes, in the configuration of a Configured Item after establishment of the configuration baseline(s) for the Configured Item.

The Configuration Manager shall apply internal configuration control measures to all Configuration Items prior to the time that it is baselined. These control measures shall also be applied to each baselined configuration item as well. This control program should:

• Ensure effective control of all Configured Items and their approved documentation.
• Provide effective means for proposing changes, requesting deviations or waivers, preparing notices of revisions, and preparing change notices.

-- SmKershaw? - 16 Feb 2003

6.1.4.1. CONFIGURATION CONTROL ACTIVITY

The sections that follow detail some concepts, principles, and activities concerning configuration control activities as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.1.1. Configuration Control - General Concepts and Principles

6.1.4.1.1.1. Configuration Control Authority

6.1.4.2. CONFIGURATION CONTROL BOARD (CCB).

The sections that follow detail some concepts, principles, and activities concerning CCBs as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.2.1. CCB Authority.

6.1.4.2.2. CCB Membership.

6.1.4.2.3. CCB Charter.

6.1.4.2.4. CCB Operating procedures.

6.1.4.2.5. Splitting Responsibilities

6.1.4.3. CHANGE PROCESS AND KEY DECISION POINTS

The sections that follow detail some concepts, principles, and activities concerning change processes and decision points as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.4. TRACEABILITY

The sections that follow detail some concepts, principles, and activities concerning traceability as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.5. CONFIGURATION CONTROL CATEGORIES AND FAST TRACK OPTIONS

The sections that follow detail some concepts, principles, and activities concerning configuration control categories and options as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.6. JOINT PROJECT CONFIGURATION CONTROL CATEGORIES (CCC)

The sections that follow detail some concepts, principles, and activities concerning Joint Project CCCs as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.7. CM ADMINISTRATION FUNCTIONS

The sections that follow detail some concepts, principles, and activities concerning CM Administration Functions as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.8. EFFECTIVITIES VERSUS EFFECTIVE DATES

The sections that follow detail some concepts, principles, and activities concerning effectivities as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.8.1. Effectivities

6.1.4.8.2. EFFECTIVE DATES VERSUS RELEASE DATES

6.1.4.9. ENGINEERING CHANGE PROPOSAL

The sections that follow detail some concepts, principles, and activities concerning ECPs as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.9.1. ECP Concepts and Principles

6.1.4.9.2. ECP Initiation.

6.1.4.9.2.1. Unsolicited ECPs.

6.1.4.9.3. Change Classification

6.1.4.9.4. ECP Preparation and Submittal.

6.1.4.9.4.1. Automated Processing of ECPs.

6.1.4.9.4.1.1. Unrelated engineering changes. 6.1.4.9.4.1.2. Revisions of ECPs. 6.1.4.9.4.1.3. Amendments of ECPs.

6.1.4.9.4.2. ECP Supporting Data.

6.1.4.9.5. Implementing ECPs.

6.1.4.9.6. ECP Activity Guides

6.1.4.9.6.1. Class I ECP Types and their function

6.1.4.9.6.2. ECP priorities

6.1.4.9.6.3. Class I ECP justification codes.

6.1.4.10. NOTICE OF REVISION (NOR)

The sections that follow detail some concepts, principles, and activities concerning NORs as it applies to a government - government contractor environment. {added. -- SmKershaw? -

6.1.4.10.1. NOR Concepts and Principles

6.1.4.11. REQUEST FOR DEVIATION/WAIVER (RFD/W)

The sections that follow detail some concepts, principles, and activities concerning deviations and waivers as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.4.11.1. RFD/W Classification.

6.1.4.11.2. RFD/W effectivity.

6.1.4.11.3. RFD/W preparation and submittal.

6.1.4.11.4. RFD/W approval/disapproval decisions.

6.1.4.11.5. Recurring RFD/Ws.

6.1.4.12. Modification Work Order

The sections that follow detail some concepts, principles, and activities concerning work order modification as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 } -- DirkWessel? - 20 Feb 2003

6.1.5 Configuration Status Accounting

The purpose of Configuration Status Accounting (CSA) is to assure accurate identification of each Configured Item and delivered unit so that the necessary support elements can be correctly programmed and made available in time to support the Configured Item. An adequate and accurate CSA will enhance the program and functional mangers' capabilities to identify, produce, inspect, deliver, operate, maintain, repair, refurbish, etc., Configuration Items in a timely, efficient and economical manner in satisfying their assigned responsibilities.

The Configuration Manger shall implement a Status Accounting System. This system should:

• identify the current approved configuration documentation and identification number associated with each CI.
• Record and report the status of proposed changes from initiation to final approval/contractual implementation.
• Record and report the results of configuration audits to include the status and final disposition of identified discrepancies.
• Record and report the status of all critical and major requests for deviations and waivers which affect the configuration of any particular configuration item.
• Record and report implementation status of authorized changes.
• Provide the traceability of all changes from the original baselined configuration of each configured item.
• Report the effectivity and installation status of configuration changes to all Configured Items at all locations.

-- SmKershaw? - 16 Feb 2003

6.1.5.1. CONFIGURATION STATUS ACCOUNTING ACTIVITY.

The sections that follow detail some concepts, principles, and activities concerning configuration status accounting as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.5.1.1. CSA CONCEPTS AND PRINCIPLES.

6.1.5.1.2 METRICS MODEL

6.1.5.1.2.1. Characteristics of a Good Metric

6.1.5.1.2.2. Developing Good Metrics

6.1.5.1.2.3. Feedback Loop

6.1.5.2. Technical Data Management

The sections that follow detail some concepts, principles, and activities concerning technical data management as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.5.2.1. Automated Configuration Management System

6.1.5.2.1.1. TBD

6.1.5.3. TBD

6.1.5.4. DATA INTEGRITY AND ACCURACY

The sections that follow detail some concepts, principles, and activities concerning data integrity and accuracy as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.5.4.1. Data Base Audits and Error Removal

-- DirkWessel? - 20 Feb 2003

6.1.6 Configuration Audits

Configuration audits are performed before establishing a product baseline for the item in question. Configuration audits consist of the Functional Configuration Audit (FCA) and the Physical Configuration Audit (PCA). The Configuration Manager is tasked with conducting the FCA/PCA and to participate in the resolution of discrepancies identified therein.

-- SmKershaw? - 16 Feb 2003

The objective of the FCA is to verify the product's functionality as defined by specification and change requests is demonstrated via operation and testing. The objective of the PCA is to verify that the physical location of the pieces and parts of the product, where it resides, its versioning, associated tools and documentation, and the 'as-built' are in agreement. FCA/PCA Efforts are very labor intensive.

-- SmKershaw? - 16 Feb 2003

A Baseline audit can be performed by CM at any time and serves to show problems before they become serious ones. One should be scheduled immediately prior to the start of each major phase in the life cycle. It is during this baseline audit that documents are audited, the product is audited, CM Records are audited, Tool audit trails are exmained, and a report is produced.

-- SmKershaw? - 16 Feb 2003

6.1.6.1. CONFIGURATION VERIFICATION AND AUDIT ACTIVITY.

The sections that follow detail some concepts, principles, and activities concerning configuration verification and auditing as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.6.2. CONFIGURATION VERIFICATION AND AUDIT CONCEPTS AND PRINCIPLES

The sections that follow detail some concepts, principles, and activities concerning configuration verification and audiing as it applies to a government - government contractor environment. {added. -- SmKershaw? - 27 Apr 2003 }

6.1.6.2.1. Configuration Verification.

6.1.6.2.2. Configuration Audit

6.1.6.2.2.1. Functional Configuration Audit.

6.1.6.2.2.2. Physical Configuration Audit.

-- DirkWessel? - 20 Feb 2003

6.2 HOW DO THESE ACTIVITIES FIT INTO LIFE CYCLE?

Configuration Identification is usually performed during the intitial setting of a configuration environment. However, as new things are added to the configuration or removed, Configuration Identification issues will be addressed.

Configuration Control is active over the entire life cycle, as is status accounting and Audits. A day should not go by without an audit of some kind being performed.

-- SmKershaw? - 16 Feb 2003

6.3 OTHER ACTIVITIES

Some of the daily functions required of a Configuration Manager or Configuration Team could include - but not be limited to - Problem Report functions, CCB Functions, Change Proposal Functions, Document Library Functions, Configuration Handling, Customer Service Functions, and other in-house functions.

Problem Reporting Functions include but are not limited to:

• Receiving problems reports
• Document problem reports, number them, record them
• Evaluate level of urgency of new problem reports
• Perform administrative review of problem reports for completeness
• Assign and update the status of problem reports
• Provide copies of problem rpeorts to quality assurance, and programming managers
• Receive and process problem report updates or continuation sheets
• Assist in QA and project evaluation of problem reports getting them scheduled for a CCB.
• Prepare problem reports for CCB
• Problem report filing
• Updating problem reports with CCB and QA dispositions.

CCB Functions include but are not limited to:

• Preparing CCB agendas
• Attending CCB Meetings
• Taking CCB Minutes
• Keep CCB Distribution lists up to date
• Producing CCB Minutes
• Maintain CCB Charter

Change Proposal Functions include by are not limited to:

• Initiating Change Proposal packages and documentation
• Incorporation of User Group Comments into Change Proposals
• Entering Change Proposals and logging them
• Implementing Project funding direction changes in Change Proposals
• Keeping the Change Proposal database current

Document Library Functions include but are not limited to:

• Check in/out documents to/from the Library
• Log new documents into the library and database
• Prepare inventory of recorded material
• Prepare reports as required
• Prepare requests for reproduction of material

Configuration Handling Functions include but are not limited to:

• Compile source code/link/build
• Control configured software
• Create test baseline
• Create approved baseline from test baseline
• Create developmental baseline
• Forward changes and developmental baselines to QA
• Foward copy of preliminary release package to project management and QA
• Create final developmental baseline
• Create final release package
• Identify items for final configuration
• Identify and correct differences between final released item and preliminary versions.
• Make copies and distribute final release package to Project Management
• Perform Baseline Configuration Audits
• Perform PCA
• Replace old products
• Store final released products
• Verify final released product matches preliminary product
• Automate build procedures where possible.

Customer Service Functions include but are not limited to:

• Making copies of production product for various customers.
• Coordinate validation of production copies
• Prepare shipment orders
• Keep list of deliveries
• Service all customers

In-House Functions include but are not limited to:

• Providing input to procedure development
• Develop and follow procedures for day-to-day functions
• Maintain Tools
• Keep CM Data current
• Maintain databases
• Order raw materials for CM productions
• Perform various internal audits
• Provide training to project team for tools
• Maintain CMP

-- SmKershaw? - 16 Feb 2003

(split and edited) -- CarildaAThomas? - 18 Feb 2003

---

Chapter 7: Configuration Management Contributions to Projects

Overview

{ Discuss how CM contributes and benefits project managers in resource planning, Estimating, budgeting, and cost controls. }

7.1 CM's CONTRIBUTIONS AND BENEFITS TO PROJECT MANAGEMENT

Address things like planning, estimating, metrics, budgeting, cost controls etc.

7.2 CM's CONTRIBUTIONS TO QUALITY

The Handbook of Software Quality Assurance's summary of Chapter 11 written by William Bryan, D.Sc and Stanley Siegel, Ph.D, best speaks to the contributions that CM has upon quality. It says that "Software Configuration Management offers the buyer, user and seller protection against the myriad problems that often beset software development and maintenance projects -- problems that, if left unaddressed, can easily spell project disaster. To address these problems, the four" CM "functions -- identification, control, auditing, and status accounting -- must be practiced in, and indeed integrated into, the software development process throughout the project life cyle."

Stanley and Bryan remind us that "Establishment of" a CM "program on a project of any size is practicable and economically justifiable. Management commitment to installing the checks and balances provided by SCM is of paramount importance. A" CM "program should be established gradually, molded to the organization and functions of the company and its projects and to available personnel. An early endeavor should be the establishment of a Configuration Control Board periodically meeting to maintain change control for the project. Other areas of importance for" CM "are the conduct of audits of the software products, particularly early in the life cycle, and of acceptance testing of the completed software code prior to its delivery to its users."

They finish the chapter by saying that with "the installation of such a program, a large measure of protection will be provided to a project through an increase in visibility and traceability, through the establishment of project control and change control, and through provision of a capability to monitor project events. The end result is an increased likelihood of developing ... systems that satisfy user needs and that are delivered on time and within budget." -- SmKershaw? - 18 Feb 2003 {From Handbook Of Software Quality Assurance, Chapter 11}

Configuration Management should in essence be the safety valve, to use an engineering cliche, by which projects are watched, reviewed, audited, and reported. The metrics generated by CM efforts can be valuable to Quality Assurance efforts, as QA is charged with serving as the watchdog. When both the CM and QA are strong organizations the two being present and engaged on a project create an environment wherein quality products are achieved.-- SmKershaw? - 18 Feb 2003

7.3 CM's CONTRIBUTIONS TO DEVELOPMENT EFFORTS

The contributions made by configuration management toward development efforts are surprisingly small in quantity, but huge in value. Developers are assured, through competent and confident configuration management that their efforts will not be 'lost' or 'scrambled'. That with a safe, and repeatable process, CM contributes to the sanity of developers in what seems often times to be an insane development arena. CM brings order in the chaos. CM brings peace of mind to the worried. CM simplifies and improves business patterns for the good of projects. CM adds value to the development effort, it isn't just a required overhead expense.

Through the identification efforts of CM, developers and managers alike, know what they are working on and where it is. It is through CM's efforts to control configurations that order is brought to the project. It is through CM's auditing efforts that the developers and managers alike are 'assured' that all is well. Lastly, it is through status accounting (reporting) that concerns, issues (positive and negative) are made known to all interested parties.

-- SmKershaw? - 09 Mar 2003

7.3.1 Agile Development and CM

A fairly new term and technique is now being applied to configuration management in software development. It is known as "agile". The name "agile" is fairly recent in its use for describing a category of software development methods. The term "lightweight" was previously being used, but some felt that wasn't quite an accurate word, and since the term "organizational agility" was (and is) fairly popular, they felt it fit in this case as well. But that is neither here nor there.

It is important to note that "agile" isn't simply repacking of 100% old ideas. There are a few new elements thrown into the mix with all that older and more familiar stuff. Some of the methods classified as "agile" are old methods that have been around for awhile (like DSDM). And there is a big intersection of RAD and Agile, such as DSDM and RADical Software Development.

It is very true that many of the ideas that go into it have been around a very long time, such as iterative development, evolutionary delivery, and a spiral-like lifecycle.

One fundamental characteristic of agile methods is that not only are they iterative, but the iterations are typically very short: as little as one week, to possibly 14 weeks (but with a more typical range of 1-4 weeks).

Probably the key differentiating factor of "agile" methods has to do with the so-called "cost of change" curve. The usual thinking is that, the more lifecycle phases that pass between the introduction and correction of a fault, the cost of rework to fix it is about an order of magnitude more expensive for every phase it escaped. Agile methods turn this on its ear and challenge this thinking, and suggest that under certain circumstances, this "cost of change" need not be exponentially increasing, and in fact could be flattened somehow.

The best "succinct" description of it would be the article Retiring Lifecycle Dinosaurs from STQE magazine (Software Testing and Quality Engineering, July/Aug. 2000.)

Another good and concise introduction would be Martin Fowler's The New Methodology. Martin also has a short article The Agile Manifesto: where it came from and where it may go that does a good job of explaining its ideas and principles.

Another element of Agility (not just for software, but organizationally as well) is the concept of "emergence" and "self-organization" from the sciences of complex adaptive systems and complexity theory. Some of these elements are present in something like RAD, but it's not an intentional part of it the way it is for so called "Agile" methods (see Agile Software Development: The Business of Innovation)

Another element related to the complexity theory is the premise that software development should not be considered to be like Manufacturing in its models and processes (which is what CMM and others are premised upon - Crosby's writings and the Manufacturing Maturity Model (MMM)). The agile premise is instead that software is more like the scientific method of new discovery, due to rapid and volatile change, and a model of hypothesize-experiment-adapt/adjust is more appropriate.

This leads to a different mind-set that relies more heavily on feedback that is more frequent. Instead of focusing more on end-of-phase reviews to try and catch faults before going to the next phase, it's almost as if the mind-set is one of embracing constant change/adjustment rather than trying to prevent it.

Rather than laboring so hard during a phase or lifecycle to get spend a lot more time making sure I get it right after every phase, accept that I won't get it right the first time (or the second time), and instead, simply fail much sooner, more frequently, and learn from it and make corrective action much earlier and more frequently. Elements of this are also present in Boehm's risk-based spiral model, but its not quite so blatant there as it seems to be in the most popular agile methods.

Some of the agile methods are more blatant about this than others (e.g., Extreme Programming, SCRUM, Crystal, ASD) and tend to be the newer ones. Some of them are more moderate and its harder to see the difference between them versus highly iterative spiral model (FDD, Agile Modeling, DSDM).

Some of the more "flagrant" or "extreme" agile methods are that way in part due to a violent counter-response to the Software CMM and similar frameworks. This reaction isn't quite necessary. Running all the way to the other end of the spectrum is just as imbalanced as the (mis)application of CMM that is being rejected.

So while there is certainly a lot of "old stuff" and existing best-practices in "Agile" software methodologies - there are one or two (maybe even three) very different things which flagrantly challenge some of the prevailing wisdom that gave us Formal Inspections, SQC, and the CMM.

Other references for agile can be found at:

• The Agile Alliance's "Agile Articles" Index
• Agile Software Development, by Alistair Cockburn (pronounced "Coh-burn")
• Agile Software Development Ecosystem's, edited by Cockburn and Highsmith.
• Highsmith's book Adaptive Software Development

Agile is an important thing to understand, and not simply write-off as "what's old is new again". A lot of its current popularity is from the classic vicious cycle of bouncing back and forth between extremes. Before CMM, there was not enough emphasis on process. Then many started taking it too far in the other direction as people clamored for CMM-ratings (passing the test and having the appropriate docs & bureaucracy became more important than the process and its effectiveness for many shops that misapplied the CMM).

Now the swing is going back in the other direction, and "agile" is a big part of that. But there is something new underlying a lot of the old stuff making a "comeback". Configuration Management is going to be critical "fulcrum" in leveraging a balanced and effective set of processes and criteria. With such a large emphasis on "lean" and "lightweight", CM on agile projects will need to be less intrusive/invasive (what Grady Booch would call "low-friction") to allow agile projects to succeed while at the same time not being so non-existent (due to overreaction) as to contribute to their failure.

{ Brad Appleton? from CMCrossRoads Community Forum on Agile Development, Repeated here with permission and with slight modification -- SmKershaw? - 09 Mar 2003}

7.3.2 Rapid Development and CM

The web site, http://www.webopedia.com, defines Rapid Application Development as: “A programming system that enables programmers to quickly build working programs. In general, RAD systems provide a number of tools to help build graphical user interfaces that would normally take a large development effort. Two of the most popular RAD systems for Windows are Visual Basic and Delphi.“

“Historically, RAD systems have tended to emphasize reducing development time, sometimes at the expense of generating efficient executable code. Nowadays, though, many RAD systems produce extremely fast code. Conversely, many traditional programming environments now come with a number of visual tools to aid development. Therefore, the line between RAD systems and other development environments has become blurred."

{Copied from the www.webopedia.com site. -- SmKershaw? - 08 May 2003 }

7.3.3 Extreme Programming

According to information found at http://www.xprogramming.com, “Extreme Programming, or XP, is a lightweight discipline of software development based on principles of simplicity, communication, feedback, and courage. XP is designed for use with small teams who need to develop software quickly in an environment of rapidly-changing requirements.”

“XP was developed by Kent Beck, who wrote the original book on the subject, Extreme Programming Explained. Two new books will reach the market by October, Extreme Programming Installed, by Ron Jeffries (your host), Ann Anderson, and Chet Hendrickson; and Planning Extreme Programming, by Kent Beck and Martin Fowler. Ultimately, any team's software development methodology needs to be customized to the team and their circumstances. No methodology is just a collection of rules to be performed in rote fashion, and XP - in spite of its famous rules - is no exception.”

For more information you should explore the web site listed above in this section.

{The above section was copied from the www.xprogramming.com web site. -- -- SmKershaw? - 08 May 2003 }

7.3.4 SCRUM

According to the Web site, www.controlchaos.com, Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. It's attributes are:

• Scrum is an agile process to manage and control development work.
• Scrum is a wrapper for existing engineering practices.
• Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing
• Scrum is a process that controls the chaos of conflicting interests and needs.
• Scrum is a way to improve communications and maximize co-operation.
• Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.
• Scrum is a way to maximize productivity.
• Scrum is scalable from single projects to entire organizations.
• Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.
• Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

Scrum naturally focuses an entire organization on building successful products. Without major changes -often within thirty days - teams are building useful, demonstrable product functionality. Scrum can be implemented at the beginning of a project or in the middle of a project or product development effort that is in trouble. Scrum is a set of interrelated practices and rules that optimize the development environment, reduce organizational overhead, and closely synchronize market requirements with iterative prototyes. Based in modern process control theory, Scrum causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.

Scrum as applied to product development was first referred to in "The New New Product Development Game" (Harvard Business Review 86116:137-146, 1986) and later elaborated in "The Knowledge Creating Company" both by Ikujiro Nonaka and Hirotaka Takeuchi (Oxford University Press, 1995). Based on their ideas and research in process theory performed in collaboration with DuPont? Advanced Research Facility, Scrum was first formulated and presented to the Object Management Group in 1995. The Scrum process is fully described in a recent book from Ken Schwaber and Mike Beedle, Agile Software Development with Scrum (Prentice Hall, 2001).

{The above is a complete quote taken directly from the www.controlchaos.com website.-- SmKershaw? - 08 May 2003 }

7.3.5 CMM

The Capability Maturity Model, as described in The Capability Maturity Model by Carnegie Mellon University Software Engineering Institute, is defined as a "description of the stages through which software organizations evolve as they define, implement, measure, control, and improve their software processes. This model provides a guide for selecting process improvement strategies by facilitating the determination of current process capabiliites and the identification of the issues most critical to software quality and process improvement." CMM guidelines advocate and support configuration management fairly early as part of implementation of the model. As a result, organizations focused on following and implementing CMM guidance frequently are put in positions of supporting configuration management efforts better than before the effort. The reason for this is that without proper configuration management, CMM 'levels' of success cannot be achieved.

So in essence, both CMM efforts and CM efforts are mutually beneficial to each other.

-- SmKershaw? - 27 Apr 2003

7.4 CM's CONTRIBUTIONS TO FUTURE PROJECTS

One of the benefits of a well defined and practiced CM effort, is the project's historical records or history library. One of the things practiced as part of Project Management is an evaluation at the conclusion of a project. One of the goals of this evaluation is to create a lessons learned document that can be used for future projects. Also, all the processes developed, if not made project specific, can easily port over to other projects. This reuse of CM processes and procedures has the added benefit of reducing new project start-up training and definition costs.

It takes a special organization to have the foresight to plan and require the reuse of processes and procedures which work. More often than not, projects are in the position of having to reinvent those items. As CM Professionals, we must act and do our part to bring all the experience into play for new projects.

-- SmKershaw? - 20 Feb 2003

(split and edited) -- CarildaAThomas? - 18 Feb 2003

---

Chapter 8: CM and Risks

Overview

Risk Management, according to the PMBOK®, is "the systematic process of identifying, analyzing, and responding to risk." It includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of adverse events to objectives. Risk management for a managed configuration has these processes.

Risk Management Planning – deciding how to approach and plan the risk management activities.

Risk Identification – determining which risks might affect the configuration and documenting their characteristics.

Qualitative Risk Analysis – performing a qualitative analysis of risks and conditions to prioritize their effects on configuration management activities.

Quantitative Risk Analysis – measuring the probability and consequences of risks and estimating their implications and reduce threats to the configuration effort’s objectives.

Risk Response Planning – developing procedures and techniques to enhance opportunities and reduce threats to the configuration effort’s objectives.

Risk Monitoring and Control – monitoring residual risks, identifying new risks, executing risk reduction plans, and evaluating their effectiveness throughout the life cycle.

Quoting from the PMBOK®, “these processes interact with each other and with the processes in the other knowledge areas. Each process generally occurs at least once in every” configuration management effort.

PMI in the PMBOK® says that “Risk is an uncertain event or condition that, if it occurs, has a cause and if it occurs, a consequence.” For example, a cause may be requiring the acquisition of a new tool or having limited personnel assigned to the configuration effort. The risk event is that the acquisition of the new tool may take longer than planned or the personnel may not be adequate for the task. If either of these uncertain events occur, there will be a consequence on the configuration cost, schedule, or quality. Risk conditions could include aspects of the configuration environment that may contribute to risk such as poor configuration management practices, or dependency on external participants that cannot be controlled.

Configuration risk includes both threats to the objectives of the configuration effort and opportunities to improve on those objectives. It has its origins in the uncertainty that is present in all configuration efforts. Known risks are those that have been identified and analyzed, and it may be possible to plan for them. Unknown risks, according to the PMBOK®, “cannot be managed”, although configuration managers may address them by applying a general contingency based on past experience with similar configuration management efforts.

The PMBOK® has great insight concerning risk and organizations that can be applied to configuration management efforts. It says, “organizations perceive risk as it relates to threats to …success. Risks that are threats to the [configuration management effort] may be accepted if they are in balance with the reward that may be gained by taking the risk. For example, adopting a fast-track schedule that may be overrun is a risk taken to achieve an earlier completion date. Risks that are opportunities may be pursued to benefit the [configuration effort’s] objectives.”

For a very complete discussion, we recommend the excellent discussion provided by the PMBOK it’s chapter 11. In the subsections below we have provided some guidelines for CM using the PMBOK as a guide. -- SmKershaw? - 28 Feb 2003 {text mostly from PMBOK}

8.1 RISK MANAGEMENT PLANNING

Risk management planning is the process of deciding how to approach and plan the risk management activities for a project. It is important to plan for the risk management processes to ensure that the level, type, and visibility of risk management are commensurate with both the risk and importance of the configuration effort.

It is suggested that things like the project charters, CM charters, QA charters, organizational policies, the defined roles and responsibilities, information on risk tolerances, a template for the risk management plan, a work breakdown structure all be at hand when doing risk management planning. The outputs from risk planning should be a risk management plan that describes the methodology, roles and responsibilities, budgeting, timing, scoring and interpreation of risks, risk thresholds, reporting formats and tracking of risks.

-- SmKershaw? - 28 Feb 2003 {Test mostly from PMBOK}

8.2 RISK IDENTIFICATION

One of the base duties in Configuration Management is that of identification. Identification of risks should not be all that different from identification of configured items. Just like the latter, risk identification involves determining which risks might affect the configuration and documenting their characteristics.

Anyone on the team can be a participant in risk identification from the management to the developer/manufacturing employee.

Risk identification is an iterative process. The first interaction, according to the PMBOK, "may be peformed by a part of the ...team or by the risk management team. The entire CM team and project management may make a second iteration. To achieve an unbiased analysis, persons who are not involved in the project may perform the final iteration."

"Often simple and effective risk responses can be developed and even implemented as soon as the risk is identified."

When we perform risk idnetification, some of the items which must be at our disposal include:

• a copy of the risk management plan
• Project planning and configuration management planing documentation
• Risk categories
• Historical information

These things are used along with various tools and techniques to identify genuine risks and their triggers.

-- SmKershaw? - 28 Feb 2003 {text mostly from PMBOK}

8.3 CM AND RISK AVOIDANCE

Many times configuration managment and project management are at odds with one another. Configuration managers, by definition, need to act conservatively and carefully regarding the configuration effort. Therefore, we tend to avoid risk. Project managers, on the other hand are frequently put in positions of having to make adjustments in either schedule, funding, resources, or requirements to make deadlines. This is one of the primary reasons why the PMBOK is so frequently cited as a source reference in this effort. Configuration Managers must know and understand the environment (product and personnel) within and for whom they work. Project Management plays a significant roll in defining the scope of configuration management responsibilities. Therefore, configuration managers must know about risks, and understand the importance of them.

-- SmKershaw? - 28 Feb 2003

8.4 QUALITIVATIVE VERSUS QUANTITATIVE RISKS

The PMBOK defines Qualitative risk analysis "as the process of assessing the impact and likelihood of identified risks." For our purpoese here, this process prioritizes risks according to their potential effect on configuration objectives. "Qualitative risks analysis is one way to determine the importance of addressing specific risks and guiding risk responses. The time-criticality of risk-related actions may magnify the importance of a risk. An evaluation of the quality of the available information also helps modify the assessment of the risk. Qualitative risk analysis requires that the probability and consequences of the risks be evaluated using established qualitative-analysis methods and tools."

"_Quantitative Risk Analysis_ process aims to analyze numerically the probability of each risk and its consequence on project objectives, as well as the extent of overall risk to the" configuration management effort.

"Quantitative risk analysis generally follows qualitative risk analysis. It requires risk identification. The qualitative and quantitative risk analysis processes can be used separately or together."

-- SmKershaw? - 28 Feb 2003 {text mostly from PMBOK} See the PMBOK for more detail.

8.5 CONTROLLING AND MONITORING RISK

"Here's another professional 'overlap'. Both configuration managers and project managers must control and monitor risk. This is the process of keeping track of the identified risks, monitoring residual risks and idnetifying new risks, ensuring the execution of the plans, and evaluating their effectiveness in reducing risk. Risk monitoring and control records risk metrics that are associated with implementing contingency plans. Risk monitoring and control is an ongoing process for the life of the project. The risks change as the project matures, new risks develop, or anticipated risks disappear." --PMBOK {-- SmKershaw? - 28 Feb 2003 }

-- SmKershaw? - 14 Feb 2003

(split and edited) -- CarildaAThomas? - 18 Feb 2003

---

Chapter 9: CM Procurement

Overview

{ Describe the planning process involved in procuring CM consultants, tools, systems. How to plan for solicitations. How to make a selection. How to deal with contract administration. How to close out a contract. }

9.1 PROCUREMENT OF CONSULTANTS

{I would like for someone experienced in this area explain, in general CM terms how consultants/contractors are identified and how the hiring firm goes about engaging CM professional consultants - or any consultant for that matter. What does the hiring group have to do? what does the consultant have to do/show etc that they know how to do the job? What kind of contractual issues should be paramount in the procurement of consultants? What kind of post-procurement evaluations should be done to determine continued success or termination of the arrangement? -- SmKershaw? - 20 Feb 2003 }

9.2 PROCUREMENT OF CM TOOLS

Earlier we discussed the CM Tool Kit. In this section we discuss issues and concerns relating to procurement of those tools.

First, the Configuration Manager must have a good understanding concerning the task at hand. Things like the size of the project in terms of personnel, the quantity of Configuration Items to control, how the builds are to be performed, what metrics should be gathered, etc., must all be known.

Then, begin searching and evaluating different tools. This can be done through test driving tools, which can be time consuming, or the Configuration Manager can seek out published comparative studies. Such studies can be found on various WEB sites. However, beware of Vendor Specific sites, for you will find bias rather than objectivity. Include in your search for evaluation, inquiries of other CM Professionals and their experience with specific tools. It is very likely, that someone else on another project has already done what you are trying to do. Besure to try to get multiple opinions. If you have selected a Vendored Tool, be sure to get a CM Technical demonstration from the vendor - not the 'fluff' demo sales people give to management personnel.

Ultimately, you will need to select the tool(s). Be sure to test it in your environment prior to formal acquisition. If it proves satisfactory, then you are ready to begin formal acquisition procedures. As there are potentially so many different variations on actual purchases of these tools, we refer you to your organizations purchase and acquisition procedures. Make sure you understand the warranties and agreements.

Once the tool(s) arrive, install it in a private arena so that your CM team can get proficient at using it. Develop your training materials for the project team and deploy it. -- SmKershaw? - 20 Feb 2003

9.3 PROCUREMENT OF CM SYSTEMS

The procurement of CM Systems may involve the receipt of bids or proposals and the application of the evaluation criteria to select a provider. There are many factors aside from cost or price that need evaluation in the selection decision process.

• Price
• Proposal approach (technical vs commercial)
• Multiple sources may be required depending on criticallity

The PMBOK® suggests that the "tools and techniques described here may be used singly or in combination.

• Select a single source to sign a standard contract
• Rank order of all proposals to establish a negotiating sequence.

PMBOK® urges that "on major procurement items, this process may be repeated. A short list of qualified sellers may be selected based on a preliminary proposal, and then a more detailed evaluation will be conducted based on a more detailed and comprehensive proposal." -- SmKershaw? - 04 Mar 2003

9.4 CONTRACT ADMINISTRATION

{address the administration of contracts in general and as they relate to CM kinds of contracts. What are some key issues or concerns that are relevant to success? Someone with Contract Admin know how - please contribute to this one.-- SmKershaw? - 20 Feb 2003 }

The PMBOK® describes contract administration as "the process of ensuring that the seller's performance meets contractual requirements. On larger projects with multiple product and service providers, a key aspect of contract administration is managing the interfaces among the various providers. The legal nature of the contractual relationship makes it imperative that the ...team be acutely aware of the legal implications of actions taken when administering the contract.

PMBOK® continues, "Contract administration includes application of the appropriate ... management processes to the contractual relationship(s) and integration of the outputs from these processes into the overall management of the project. This integration and coordination will often occur at multiple levels when there are multiple sellers and multiple products involved."

-- SmKershaw? - 04 Mar 2003

9.5 CLOSING OUT A CONTRACT

Guidance from the PMBOK® suggests that contract closout in terms of procurement efforts is "similar to administrative closure in that it involves both product verification (Was all work completed correctly and satisfactorily?) and administrative closeout (updating of records to reflect final results and archiving of such information for future use). The contract terms and conditions may prescribe specific procedures for contract closeout. Early termination of a contract is a special case of contract closout."

-- SmKershaw? - 04 Mar 2003

(split and edited) -- CarildaAThomas? - 18 Feb 2003

---

Chapter 10: Metrics for CM

Overview

One of the major benefits coming from CM's work in monitoring processes and procedures and keeping things automated are metrics. Metrics, if used by management, can play a significant part in planning and scheduling. They can also provide a tool by which management can verify their 'perceptions' of a problem. Metrics can also alert management to potential trends and problems.

10.1 TYPES OF METRICS

The metrics listed here are but a few of the metrics that can be utilized by Configuration Management Teams.

• Life Cycle Promotions illustrate the number of promotions performed by CM on a monthly basis. This is an indicator of the work load. The quantity of life cycle promotions also serves as an indicator of merge code activity where more than one release is being worked by the team. Another variation of this particular metric is the number of promotions made per day on average in a month.

-- SmKershaw? - 25 Feb 2003

• Average Process Time Per Month Metrics can also be helpful in monitoring work flow effectiveness. Graphing the times, for instance, that it takes to completely process a problem report from the time CM begins to track it to the time it is corrected and put into production and be of great value in providing clues concerning the overall process. The diagram below shows actual data from a real project. The X axis contains the month/year, and the Y axis shows the average number of days it took to close a Problem Report opened in that month.

-- SmKershaw? - 24 Feb 2003

• Configuration Item Change Activity Illustrates the ratio of the number of changes per configuration item on a monthly basis. On the 'Y' axis, plot the ratio (Changes/CI). The 'X' axis shows the months. This can provide significant insight on the quantity of repeat 'visits' a developer makes against a particular CI. The greater the frequency, the greater the problem.

-- SmKershaw? - 24 Feb 2003

• Database Changes Per Release is normally associated with Software Configuration efforts. The 'Y' axis shows the quantity of data base changes and the 'X' axis has a column for each release. Such diagrams as the one below make it readily known which releases have had the most impact on the overall product from a database change perspective. It also provides some clue as to the quality (or lack of quality) of the initial planning efforts prior to the initial release being put into production.

-- SmKershaw? - 24 Feb 2003

• A Release Status Report should report the date that the first change was made, when the last one was made, the number of days open, the number of configuration items changed, the number of total changes, the change/CI ratio, the number of Problem reports Issued, The Problem Report/CI ratio, the Days to Complete a Problem Report, and the current status for each release.

-- SmKershaw? - 16 Feb 2003

• Frequently Changing Files Report is a software CM specific report that can be used to analyze files that are being potentially too frequently. Such a list can provide unique insight to both CM, PM, and QA groups in that these files could then be targetted for special investigations. Such questions as these need to be answered for each file on such a list:
  • Why are these changing so often?
  • Is it because requirements are not clear?
  • Is it because testing is inaccurate?
  • Is it a training issue?
  • Is it an overall design problem?

-- SmKershaw? - 24 Feb 2003

• Monthly Rework Metrics can be used to track the success or failure of methods applied to the project in effort to control rework. The diagram below shows the rework value from a particular project over a part of the life of that project. One has to ask:
  • Why is the trend going up so fast?
  • What is driving this so that it looks so out of control?
  • What can be done to slow the trend and reverse it?

-- SmKershaw? - 24 Feb 2003

• Change Completion Metrics can be used to analyze handling of changes. Actual work expended can be plotted against severity, and should show a direct relationship. Calendar time to completion vs criticality should show an inverse relationship. Violation of either of these relationships may indicate incorrect classification of change requests, or non-optimal scheduling of time. Estimated time vs actual time can be used both by developers as a tool to improve their estimation capability (as in SEI's Personal Software Process(SM)), or by project managers to evaluate the accuracy of developer estimates when planning and costing future efforts.

-- CarildaAThomas? - 18 Feb 2003

10.2 METRICS COLLECTION

The collection of data for metrics is driven by three factors. First, what information does project management require to make proper decisions in a timely manner. Second, what information does the CM Team require to monitor the work flow, processes, quality etc of their own efforts. The third factor driving metric collection is the overall direction and motivation to achieve such status as CMM Level 4.

Data for metrics comes from the tools at hand. Where tools do not provide the required information, CM is tasked with making the acquisition and retaining the data. Regardless of the nature of the data obtained, it is crucial to be conservative in applying 'meaning' to any and all metrics generated. For the saying is quite true: "Liars figure and figures lie."

It is also very beneficial to have, as part of your staff - at least part time, a statistician that can aid in more complicated metric research and development in the realm of multiple correlation analysis.

-- SmKershaw? - 24 Feb 2003

(split and edited) -- CarildaAThomas? - 18 Feb 2003

---

Section III: Appendices

---

Appendix A: Standards, Process, Resources

A.1 Standards

• IEEE 828
• ITIL
• MIL-STD-973
• MIL-STD-2549
• MIL-STD-1521
• ISO 9000
• ISO 10007

-- SmKershaw? - 7 Feb 2003 -- NealFreeman? - 19 Feb 2003 -- NeilSteeman? - 21 Feb 2003

A.2 Processes

A.3 Resources

• CMII
• SEI
• Change Management Solutions, Inc.
• A Configuration Management Training slide set by ESA

-- SmKershaw? - 7 Feb 2003 -- CarildaAThomas? - 18 Feb 2003 -- NeilSteeman? - 20 Feb 2003 -- NeilSteeman? - 22 Feb 2003 (moved from Chapter 1 by CarildaAThomas? - 24 Feb 2003)

(split and edited) -- CarildaAThomas? - 18 Feb 2003

---

Appendix B: A Brief Description of our Efforts to Make the CMBoK

Warning: Can't find topic CM.CMBoKEfforts

Appendix C: CMBoK Contributors and Reviewers

• Steven M. Kershaw has served as the Software Configuration Manager on the ES-3A Navy Aircraft, EP-3E Navy Aircraft, Defense Joint Accounting System, and the Deployable Disbursing System projects. Other areas include Quality Assurance and Management, Software Development and Database System Design. He holds an MS in Management from Indiana Wesleyan University, a BS in Computer Programming Technology from Purdue University and an AS in Data Processing Technology -DeKalb Community College. He is a member of the Project Management Institute (PMI) and a member of the Association of Configuration Data Managers (ACDM)-- SmKershaw? - 07 Feb 2003

• Dirk Wessel, Configuration Management Engineer for NATO Air Command and Control System Management Agency, Brussels -- DirkWessel? - 09 Feb 2003

• Carilda A. Thomas, CM designer, implementer, team member and lead, Project Leader, Designer, Architect, kernel and applications Programmer, QA Analyst, Trainer, Systems Engineer, System Administrator, Consultant and single mother of two teenagers but alas! I did not invent the Internet. Educated at Princeton University, Florida Atlantic U, Miami-Dade CC, and all I got out of it was a Bachelor's -- CarildaAThomas? - 12 Feb 2003

• Neal Freeman, Configuration Manager and Process Improvement Specialist. Educated at Oxford University and Imperial College London. Member of the British Computer Society's Configuration Management Specialist Group -- NealFreeman? - 19 Feb 2003

• Denis Roy, Configuration Management and Customer Documentation group manager. Educated at Sherbrooke College, Quebec. Member of the Association for Configuration and Data Management Group -- DenisRoy? - 19 Feb 2003

• Neil Steeman, President of Change Management Solutions, Inc., graduated from the University of Maryland as a Mechanical Engineer. He has been involved in configuration and data management of airborne electronic equipment for the Department of Defense, as well as shipboard and nuclear equipment. -- NeilSteeman? - 19 Feb 2003

---

(split) -- CarildaAThomas? - 18 Feb 2003

---

Appendix D: Summary of CM Knowledge Areas

CM Knowledge Areas

Configuration Integration Management

A subset of configuration management that includes the processes required ensuring that the various elements of the configuration effort are properly coordinated. It consists of:

• Configuration Management Plan development – integrating and coordinating all project related plans to create a consistent, coherent document
• Configuration Management Plan execution – carrying out the configuration management plan by performing the activities included therein.
• Integrated change control – coordinating changes across the entire project.

Configuration Scope Management

A subset of configuration management that includes the processes required to ensure that the configuration effort includes all the work required, and only the work required, completing the effort successfully. It consists of:

• Initiation – authorizing the configuration effort or phase
• Scope planning – developing a written scope statement as the basis for future configuration management decisions.
• Scope definition – subdividing the major configuration deliverables into smaller, more manageable components.
• Scope verification – formalizing acceptance of the configuration effort’s scope.
• Scope change control – controlling changes to configuration effort’s scope.

Configuration Time Management

A subset of configuration management that includes the processes required to ensure timely completion of the configuration effort. It consists of:

• Activity definition – identifying the specific activities that must be performed to produce the various configured deliverables.
• Activity sequencing – identifying and documenting interactivity dependencies.
• Activity duration estimating – estimating the number of work periods that will be needed to complete individual activities.
• Schedule development – analyzing activity sequences, activity duration, and resource requirements to create the configuration portion of the project schedule.
• Schedule control – controlling changes to the configuration effort’s schedule.

Configuration Cost Management

A subset of configuration management that includes the processes required ensuring that the configuration effort is completed within the approved budget. It consists of:

• Resource Planning – determining what resources (people, equipment, and materials) and what quantities of each should be used to perform project activities.
• Cost estimating – developing an approximation (estimate) of the costs of the resources needed to complete configuration activities.
• Cost budgeting – allocating the overall cost estimate to individual work activities.
• Cost control – controlling changes to the configuration management budget.

Configuration Human Resource Management

A subset of configuration management that includes the processes required making the most effective use of the people involved with the Configuration Management Team(s). It consists of:

• Organizational planning – identifying, documenting, and assigning configuration management team roles, responsibilities, and reporting relationships.
• Staff acquisition – getting the needed human resources assigned to and working on the CM Team.
• Team Development – developing individual and group skills to enhance CM Team performance.

Configuration Communications Management

A subset of configuration management that includes the processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of configuration management information. It consists of:

• Communications planning – determining the information and communication needs of the project team members: who needs what information, when they will need it, and how it will be given to them.
• Information distribution – making needed information available to project team members in a timely manner.
• Performance reporting – collecting and disseminating performance information. This includes status reporting, progress measurement, and forecasting.
• Administrative closure – generating, gathering and disseminating information to formalize phases, configuration, or project completion.

Configuration Risk Management

Risk Management is the same for Configuration Managers as it is for Project Managers. It is the systematic process of identifying, analyzing, and responding to project risk. It includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of adverse events to project objectives. It includes:

• Risk Management Planning – deciding how to approach and plan the risk management activities for a CM effort.
• Risk Identification – determining which risks might affect the CM Effort and documenting their characteristics.
• Qualitative risk analysis – performing a qualitative analysis of risks and conditions to prioritize their effects on CM objectives.
• Quantitative risk analysis – measuring the probability and consequences of risks and estimating their implications for CM objectives.
• Risk response planning – developing procedures and techniques to enhance opportunities and reduce threats from risk to the CM’s objectives.
• Risk monitoring and control – monitoring residual risks, identifying new risks, executing risk reduction plans, and evaluating their effectiveness throughout the life cycle.

Configuration Procurement Management

A subset of configuration management that includes the processes required acquiring goods and services to attain the effort’s scope from outside the performing organization. It consists of:

• Procurement planning – determining what to procure and when
• Solicitation planning – documenting product requirements and identifying potential sources.
• Source selection – choosing from among potential sellers
• Contract administration – managing the relationship with the seller
• Contract closeout – completion and settlement of the contract, including resolution of any open items.

Configuration Metrics Management

A subset of configuration management that includes the processes required to develop and produce metrics that serve to verify perceptions of activities or serve to alert team members of problems. It consists of:

• Planning – determining the nature of metrics required by management
• Acquisition of tool(s) – choosing tools that will provide the desired metrics.
• Data generation – assuring that the data is entered, accurate, and meaningful
• Communication – Metric charts and diagrams and information must be related to management for proper action.
• Training – those who will use the metric data should be trained to understand the complexities of the metric(s) in question.

-- SmKershaw? - 26 Feb 2003

-- CarildaAThomas? - 18 Feb 2003

---

Section IV: Glossary and Index

---

Definitions and Terminology

---

1. DEFINITIONS AND TERMINOLOGY

Since a major goal of acquisition streamlining is to use commercial and industry practices to the greatest extent possible, there is no single correct set of CM terminology that must be rigidly adhered to. This section contains many aliases that are commonly used in different environments. It is appropriate to allow the use of common (local) terms to a given industry when dealing with that industry. The following acronyms and definitions are provided for reference.

Can "acquisition streamlining" be explained or reworded? -- NealFreeman? 20 Feb 2003

1.1. Acronyms

AA	Application Activity
ABL	Allocated Baseline
ACD	Allocated Configuration Documentation
ACSN	Advance Change Study Notice
ACO	Administrative Contract Officer
AECMA	Association Europeene des Constructeurs de Materiel Aerospatial
AIS	Automated Information System
AMSDL	Acquisition Management Systems and Data Requirements Control List
ANSI	American National Standards Institute
CAGE	Commercial and Government Entity
CAO	Contract Administration Office
CCB	Configuration Control Board
CCBD	Configuration Control Board Directive
CCC	Configuration Control Classes
CDCA	Current Document Change Authority
CDR	Critical Design Review
CDRL	Contract Data Requirements List
CI	Configuration Item
CITIS	Contractor Integrated Technical Information Service
CLIN	Contract Line Item Number
CM	Configuration Management
CMDB	Configuration Management Database
CMIS	Configuration Management Information System
CMP	Configuration Management Plan
CMO	Contract Management Office
CSA	Configuration Status Accounting
CSAR	Configuration Status Accounting Report
CSCI	Computer Software Configuration Item
DID	Data Item Description
DSL	Definitive Software Library
DUI	Data Use Identifier
ECN	Engineering Change Notice
ECO	Engineering Change Order
ECP	Engineering Change Proposal
EMD	Engineering and Manufacturing Development
FBL	Functional Baseline
FCA	Functional Configuration Audit
FCD	Functional Configuration Documentation
GFD	Purchaser Furnished Data
GFE	Purchaser Furnished Equipment
HWCI	Hardware Configuration Item
ICD	Interface Control Drawing
ICWG	Interface Control Working Group
IDD	Interface Design Document
ILS	Integrated Logistics Support
IPT	Integrated Project Team
IRS	Interface Requirements Specification
ISO	International Organization for Standardization
LSA	Logistics Support Analysis
MIL-STD	Military Standard
MRB	Material Review Board
MWO	Modification Work Order
NDI	Non-Developmental Item
NOR	Notice of Revision
OPEVAL	Operational Evaluation
PBL	Product Baseline
PCA	Physical Configuration Audit
PCD	Product Configuration Documentation
PCO	Procurement Contracting Officer
PDI	Privately Developed Item
PDM	Product Data Management [System]
PDR	Preliminary Design Review
PIN	Part or Identification Number
PLAA	Purchaser Lead Application Activity
PPSL	Program Parts Selection List
RAC	Rapid Action Change [order]
RFD/W	Request For Deviation
RFP	Request for Proposal
RFW	Request For Waiver
SPS	Software Product Specification
SDL	Software Development Library
SCN	Specification Change Notice
SOW	Statement of Work
SRR	System Requirements Review
SSR	Software Specification Review
TCTO	Time Compliance Technical Order
TM	Technical Manual
TRR	Test Readiness Review
VDD	Version Description Document
VE	Value Engineering
VECP	Value Engineering Change Proposal
WBS	Work Breakdown Structure

1.2. Definitions

Advance Change Study Notice (ACSN)

A document which may be used, instead of a preliminary Engineering Change Proposal (Appendix ?), to identify an idea or problem in order to obtain authorization to submit a formal routine Engineering Change Proposal.

Allocated Baseline (ABL)

The initially approved documentation describing an item's functional, interoperability, and interface characteristics that are allocated from those of a system or a higher level configuration item, interface requirements with interfacing configuration items, additional design constraints, and the verification required to demonstrate the achievement of those specified characteristics.

Allocated Configuration Documentation (ACD)

The documentation describing a CI's functional, performance, interoperability, and interface requirements that are allocated from those of a system or higher level configuration item; interface requirements with interfacing configuration items; and the verifications required to confirm the achievement of those specified requirements.

Allocated Configuration Identification (ACI)

Allocated configuration identification (allocated baseline and approved changes) consists of all specifications defining the requirements including functional, for each major configuration item. -- SmKershaw? - 18 Feb 2003 {From Mil-STD 490A}

Application Activity (AA)

An activity that has selected an item or a document for use on projects under its control. However, it is not the current document change authority for the document(s).

Approval/contractual implementation

The acceptance by the Purchaser of a document as complete and suitable for its intended use. Approval/contractual implementation of configuration documentation means that the approved documentation is subject to the Purchaser's configuration control procedures.

Assembly

A number of basic parts or subassemblies, or any combination thereof, joined together to perform a specific function. Typical examples are: electric generator, audio-frequency amplifier, power supply.

Authentication.

Determination by the primary customer that specification content is acceptable. -- SmKershaw? - 12 Mar 2003

Block change concept

For hardware configuration items, an engineering change implementation concept that designates a number (i.e., a block) of consecutive production units of the configuration item to have an identical configuration on delivery and in operation. (Using this concept, the production run is divided into "blocks" of units. The production line incorporation point for a proposed ECP is delayed to coincide with the first unit of the next block, or retrofit is required at least for all already delivered units of the current block.)

For computer software configuration items, once the product baseline has been established, the concept requires the accumulation and the simultaneous implementation of a number of routine software changes to minimize the number of interim versions and related documentation.

Classification of defects

See MIL-STD-109.

Commercial and Government Entity (CAGE) Code

A five-position alphanumeric code with a numeric in the first and last positions (e.g., 27340, 2A345, 2AA45, 2AAA5), assigned to United States and Canadian organizations which manufacture and/or control the design of items supplied to a Purchaser Military or Civil Agency or assigned to United States and foreign organizations, primarily for identifying contractors in the mechanical interchange of data required by MILSCAP and the Service/Agency Automated Data Processing (ADP) systems. The CAGE data provides the data base for the Cataloging Handbook H4/H8 Series.

Computer data base

A collection of data in a form capable of being processed by a computer.

Computer data definition

A statement of the characteristics of the basic elements of information operated upon by hardware in responding to computer instructions. These characteristics may include, but are not limited to, type, range, structure and value. {from DoD?-STD-2167} -- SmKershaw? - 12 Mar 2003

Computer software

A combination of associated computer instructions and computer data definitions required to enable the computer hardware to perform computational on control functions. {from DoD?-STD-2167}-- SmKershaw? - 12 Mar 2003

Computer Software Component (CSC)

A distinct part of a computer software configuration item (CSCI). CSCs may be further decomposed into other CSCs and Computer Software Units (CSUs). {from DOD-STD-2167}-- SmKershaw? - 12 Mar 2003

Computer Software Configuration Item (CSCI)

A configuration item that is computer software.

Computer software documentation

Technical data or information, including computer listings, regardless of media, which documents the requirements, design, or details of computer software; explains the capabilities and limitations of the software; or provides operating instructions for using or supporting computer software during the software's operational life cycle.

Computer Software Unit (CSU)

An element specified in the design of a Computer Software Component (CSC) that is separately testable. {from DoD?-STD-2167} -- SmKershaw? - 12 Mar 2003

Configuration

The functional and physical characteristics of existing or planned hardware, firmware, software or a combination thereof as set forth in technical documentation and ultimately achieved in a product.

Configuration audit

See "Functional configuration audit" and "Physical configuration audit".

Configuration baseline

1. An agreed-to description of the attributes of a product, at a point in time, which serves as a basis for defining change.
2. An approved and released document, or a set of documents, each of a specific revision; the purpose of which is to provide a defined basis for managing change.
3. The currently approved and released configuration documentation.
4. A released set of files comprising a software version and associated configuration documentation.

See: Allocated Baseline (ABL), Functional Baseline (FBL), and Product Baseline (PBL).

Configuration control

The systematic proposal, justification, evaluation, coordination, approval or disapproval of proposed changes, and the implementation of all approved changes, in the configuration of a CI after establishment of the configuration baseline(s) for the CI.

Configuration Control Board (CCB)

A board composed of technical and administrative representatives who recommend approval or disapproval of proposed engineering changes to a CI's current approved configuration documentation. The board also recommends approval or disapproval of proposed waivers and deviations from a CI's current approved configuration documentation.

Configuration documentation

The technical documentation that identifies and defines the item's functional and physical characteristics. The configuration documentation is developed, approved, and maintained through three distinct evolutionary increasing levels of detail. The three levels of configuration documentation are the functional configuration documentation, the allocated configuration documentation, and the product configuration documentation.

Configuration identification

Configuration identification includes the selection of CIs; the determination of the types of configuration documentation required for each CI; the issuance of numbers and other identifiers affixed to the CIs and to the technical documentation that defines the CI's configuration, including internal and external interfaces; the release of CIs and their associated configuration documentation; and the establishment of configuration baselines for CIs. {Can we work this in, or is it redundant.. "Configuration Identification is established by baseline configuration identificationi documents and all effected changes. Configuration identification documents include all those necessary to provide a full technical description of the characteristics of the configuration item that require control at the time that the baseline is established." from Mil-Std 490A -- SmKershaw? - 18 Feb 2003 }

Configuration Item (CI)

A configuration item is an aggregation of hardware or software that satisfies an end use function and is designated by the Purchaser for separate Configuration Management.

Configuration Management (CM)

a. As applied to configuration items, 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 items.
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 implementation status of approved changes.
4. Audit configuration items to verify conformance to specifications, drawings, interface control documents, and other contract requirements.

b. As applied to digital data files (See MIL-HDBK-59), the application of selected configuration identification and configuration status accounting principles to:

1. Uniquely identify the digital data files, including versions of the files and their status (e.g., working, released, submitted, approved).
2. Record and report information needed to manage the data files effectively, including the status of updated versions of files.

Configuration Management Plan (CMP)

The document defining how Configuration Management will be implemented (including policies and procedures) for a particular acquisition or project.

Configuration Status Accounting (CSA)

The recording and reporting of information needed to manage configuration items effectively, including:

a. A record of the approved configuration documentation and identification numbers.

b. The status of proposed changes, deviations, and waivers to the configuration.

c. The implementation status of approved changes.

d. The configuration of all units of the configuration item in the operational inventory.

Contractor

An individual, partnership, company, corporation, association or other service, having a contract with the Purchaser for the design, development, manufacture, maintenance, modification, or supply of items under the terms of a contract. A Purchaser activity performing any or all of the above functions is considered to be a contractor for Configuration Management purposes.

Control Point (Project Control Point)

A project agreed on point in time or times when specified agreements or controls are applied to the configuration items being developed, e.g., an approved baseline or release of a specified document/code. -- SmKershaw? - 18 Feb 2003 {From IEEE Std 828-1990}

Critical item

A Critical Item is a configuration item which is below the level of complexity of a prime item but which is engineering critical or logistics critical.

a. A critical item is engineering critical where one or more of the following applies:

1. The technical complexity warrants an individual specification.
2. Reliability of the critical item significantly affects the ability of the system or prime item to perform its overall function, or safety is a consideration.
3. The prime item cannot be adequately evaluated without separate evaluation and application suitability testing of the critical item.

b. A critical item is logistics critical where the following apply:

1. Repair parts will be provisioned for the item.
2. The contracting agency has designated the item for multiple source reprocurement.

Current Document Change Authority (CDCA)

The authority currently responsible for the content of a drawing, specification, or other document and which is the sole authority for approval of changes to that document. (See also: Application Activity [AA], Approval, Document Custodian Activity.)

Data

Recorded information, regardless of medium or characteristics, of any nature, including administrative, managerial, financial, and technical.

Defect

Any nonconformance of a characteristic with specified requirements.

Deficiencies

Deficiencies consist of two types;

a. Conditions or characteristics in any item which are not in accordance with the item's current approved configuration documentation; or

b. Inadequate (or erroneous) item configuration documentation which has resulted, or may result, in units of the item that do not meet the requirements for the item.

Design change

See "Engineering change".

Developmental configuration

The contractor's design and associated technical documentation that defines the evolving configuration of a configuration item during development. It is under the developing contractor's configuration control and describes the design definition and implementation. The developmental configuration for a configuration item consists of the contractor's internally released hardware and software designs and associated technical documentation until establishment of the formal product baseline.

Deviation

A specific written authorization, granted prior to the manufacture of an item, to depart from a particular requirement(s) of an item's current approved configuration documentation for a specific number of units or a specified period of time. (A deviation differs from an engineering change in that an approved engineering change requires corresponding revision of the item's current approved configuration documentation, whereas a deviation does not.)

Distribution Statement

A statement used in marking a technical document to denote the extent of its availability for distribution, release, and disclosure without need for additional approvals and authorizations from the controlling office.

Document

A self-contained body of information or data that can be packaged for delivery on a single medium. Some examples of documents are: drawings, reports, standards, databases, application software, engineering designs, virtual part-models, etc.

Document custodian activity

The custodian of a document is the activity which is charged with the physical and electronic safekeeping and maintenance of the "original" document.

Engineering change.

A change to the current approved configuration documentation of a configuration item at any point in the life cycle of the item.

Engineering Change Directive (ECD)

An internal performing activity document that indicates the approval of, and direction to incorporate or implement engineering change.

Engineering change justification code.

A code which indicates the reason for a Class I engineering change.

Engineering change priorities

The priority (emergency, urgent, routine) assigned to a Class I engineering change which determines the relative speed at which the Engineering Change Proposal is to be reviewed, evaluated, and, if approved, ordered and implemented.

Engineering Change Proposal (ECP)

A proposed engineering change and the documentation by which the change is described, justified, and submitted to the Purchaser for approval or disapproval.

Engineering Change Proposal types

A term covering the subdivision of Class I Engineering Change Proposals on the basis of the completeness of the available information delineating and defining the engineering change. They will be identified as preliminary or formal.

Engineering release

An action whereby configuration documentation or an item is officially made available for its intended use.

Engineering Release Record (ERR)

A record used to release configuration documentation.

Evaluation

The process of determining whether an item or activity meets specified criteria. {from DoD?-STD-2168} -- SmKershaw? - 12 Mar 2003

Exchangeability of items

See Interchangeable item, Replacement item, and Substitute item.

First Article Inspection and Configuration Review (FAICR)

The first article Inspection and Configuration Review is the operation or set of operations by which the first item produced in a series is verified for conformity to the contractual requirements applicable, in concurrence with a thorough review of all the documents defining the configuration to be considered.

FAR Clause

The FAR clause specifies that the Purchaser normally should accept "non-conforming material" only when it is in the Purchaser's best interests, and there is appropriate consideration.

Firmware

The combination of a hardware device of a hardware devices and computer instructions or computer data that reside as read-only memory software on the hardware device. The software cannot be readily modified under program control. {From DoD?-STD-2167} -- SmKershaw? - 12 Mar 2003

Fit

The ability of an item to physically interface or interconnect with or become an integral part of another item.

Form

The shape, size, dimensions, mass, weight, and other visual parameters which uniquely characterize an item. For software, form denotes the language and media.

Function

The action or actions which an item is designed to perform.

Functional area.

A distinct group of system performance requirements which, together with all other such groupings, forms the next lower-level breakdown of the system on the basis of function.

Functional Baseline (FBL)

The initially approved documentation describing a system's or item's functional, interoperability, and interface characteristics and the verification required to demonstrate the achievement of those specified characteristics.

Functional characteristics

Quantitative performance parameters and design constraints, including operational and logistic parameters and their respective tolerances. Functional characteristics include all performance parameters, such as range, speed, lethality, reliability, maintainability, and safety.

Functional Configuration Audit (FCA)

The formal examination of functional characteristics of a configuration item, prior to acceptance, to verify that the item has achieved the requirements specified in its functional and allocated configuration documentation.

Functional Configuration Documentation (FCD)

The approved functional baseline plus approved changes.

Functional Configuration Identification (FCI)

Functional configuration identification (functional baseline and approved changes) will include all specifications necessary to specify 1) all essential system functional characteristics; 2) necessary interface characteristics; 3) specific designation of the functional characteristics of key configuration items; and 4) all of the tests required to demonstrate achievement of each specified characteristic. -- SmKershaw? - 18 Feb 2003 {From Mil-Std 490A}

Hardware

Items made of material, such as weapons, aircraft, ships, tools, computers, vehicles, and their components (mechanical, electrical, electronic, hydraulic, pneumatic). Computer software and technical documentation are excluded.

Hardware Configuration Item (HWCI)

A configuration item that is hardware.

Integrated Logistics Support (ILS)

See MIL STD 1388 1.

Interchangeable item

A product which possesses such functional and physical attributes as to be equivalent in performance to another product of similar or identical purposes. It is capable of being exchanged for the other product without selection for fit or performance, and without alteration of the products themselves or of adjoining products, except for adjustment.

Interface

The functional and physical characteristics required to exist at a common boundary.

Interface control

The process of identifying, documenting, and controlling all functional and physical characteristics relevant to the interfacing of two or more items provided by one or more organizations.

Interface Control Documentation (ICD)

Interface control drawing or other documentation which depicts physical and functional interfaces of related or co-functioning items.

Interface Control Working Group (ICWG)

For projects which encompass a system, configuration item, or a computer software configuration item design cycle, an ICWG is established to control interface activity among the Purchaser, contractors, or other agencies, including resolution of interface problems and documentation of interface agreements.

Interoperability

The ability of the systems and organizations to exchange information with each other (joint operations) or with an allied system (combined operations) to enable them to operate effectively together.

Should a general term like interoperability be defined by specifically mentioning "defense services and agencies"? -- NealFreeman? - 05 Mar 2003 {- modified according-- SmKershaw? - 12 Mar 2003}

Item

A nonspecific term used to denote any product, including systems, material, parts, subassemblies, sets, accessories, etc.

Life cycle

A generic term covering all phases of acquisition, operation, and logistics support of an item, beginning with concept definition and continuing through disposal of the item.

Life cycle cost

The total cost of acquisition and ownership of a system over its life cycle to the purchaser of that system. The life cycle cost includes the cost of development, acquisition, support and where applicable, disposal.

Lot number

An identifying number consisting of alpha and numeric characters which, in conjunction with a manufacturer's identifying code and a Product-Tracking Base-Identifier, uniquely identifies a group of units of the same item which are manufactured or assembled by one producer under uniform conditions and which are expected to function in a uniform manner.

"Product-Tracking Base-Identifier" anyone? -- NealFreeman? - 05 Mar 2003

Manufacturer's code

See "Commercial and Purchaser Entity (CAGE) code".

Material

A generic term covering systems, equipment, stores, supplies, and spares, including related documentation, manuals, computer hardware, and software.

Nomenclature

1. The combination of a Purchaser-assigned designation and an approved item name. In certain cases, the designation root serves as the basis for assignment of serial and/or lot numbers.
2. Names assigned to kinds and groups of products.
3. Formal designations assigned to products by customer or supplier (such as model number, or model type, design differentiation, specific design series or configuration.)

Non-conformance

The failure of a unit or product to conform to specified requirements.

Non developmental Item (NDI)

Non-developmental item is a broad generic term that covers material available from a wide variety of sources with little or no development effort required by the Purchaser. NDIs include:

a. Items obtained from a domestic or foreign commercial marketplace.

b. Items already developed and in use by the Services, other Defense activities, and Purchaser agencies.

c. Items already developed by foreign Purchasers which can be supplied.

Non-recurring costs

As applied to ECPs, these are one time costs, which will be incurred if an engineering change is approved and which are independent of the quantity of items changed, such as cost of redesign, special tooling, or testing.

Nonrepairable Item

Any part or assembly for which user-maintenance is limited to replenishment of consumables and replacement of the part or assembly upon failure or malfunction.

Notice of Revision (NOR)

A document used to define revisions to drawings, associated lists, or other referenced documents which require revision after Engineering Change Proposal approval.

Original

The current design activity document or digital data file(s) of record.

Performing activity

Denotes an activity performing any of the requirements contained in a contract or tasking directive. A "Performing Activity" can be either a contractor or Purchaser activity.

Physical characteristics

Quantitative and qualitative expressions of material features, such as composition, dimensions, finishes, form, fit, and their respective tolerances.

Physical Configuration Audit (PCA)

The formal examination of the "as built" configuration of a configuration item against its technical documentation to establish or verify the configuration item's product baseline.

Prime Item

A Prime Item is a complex item such as an aircraft, missile, launcher equipment, fire control equipment, radar set, training equipment, etc.

Product Baseline (PBL)

The initially approved documentation describing all of the necessary functional and physical characteristics of the configuration item and the selected functional and physical characteristics designated for production acceptance testing and tests necessary for support of the configuration item. In addition to this documentation, the product baseline of a configuration item may consist of the actual equipment and software.

Product Configuration Documentation (PCD)

The approved product baseline plus approved changes.

Product Configuration Identification (PCI)

The product configuration identification (product baseline and approved changes) will include all specifications, engineering drawings and related data, as necessary, to provide a set of documents adequate for the procurement, production, test, evaluation, and acceptance of a configuration item without requireing further development work. This set of documents provides that technical description which describes the required physical characteristics of a configuration item; the functional characteristics designated for production acceptance testing; and required acceptance tests. -- SmKershaw? - 18 Feb 2003 {From Mil-Std 490A}

Recurring costs

Costs which are incurred for each item changed or for each service or document ordered.

Release

The designation by the contractor that a document is complete and suitable for use. Release means that the document is subject to the contractor's configuration control procedures. The formal notification and distribution of an approved version. {partially from IEEE Std 828-1990. -- SmKershaw? - 18 Feb 2003 }

Repair

A procedure which reduces, but does not completely eliminate, a nonconformance. Repair is distinguished from rework in that the characteristic after repair still does not completely conform to the applicable drawings, specifications, or contract requirements.

Repairable Item

Any part or assembly which, upon failure or malfunction, is intended to be repaired or reworked.

Replacement item

An item which is interchangeable with another item, but which differs physically from the original item in that the installation of the replacement item requires operations such as drilling, reaming, cutting, filing, shimming, etc., in addition to the normal application and methods of attachment.

Retrofit

The incorporation of new design parts resulting from an approved engineering change to an item's current approved product configuration documentation into already accepted and/or operational items.

Retrofit Instruction

The document that provides specific, step-by-step instructions about the installation of the replacement parts to be installed in delivered units to bring their configuration up to that approved by an ECP. (Sometimes referred to Alteration Instruction, Modification Work Order, Technical Directive, or Time Compliance Technical Order.)

Rework

A procedure applied to a product to eliminate a nonconformance to the drawings, specifications, or contract requirements that will completely eliminate the nonconformance and result in a characteristic that conforms completely.

Serial number

An identifying number consisting of alpha and numeric characters which is assigned sequentially in the order of manufacture or final test and which, in conjunction with a manufacturer's identifying CAGE code, uniquely identifies a single item within a group of similar items identified by a common product-tracking base-identifier.

Software

Computer programs and computer databases.

Specification

A document that explicitly states essential technical attributes/requirements for a product and procedures to determine that the product's performance meets its requirements/attributes.

Specification Change Notice (SCN)

A document used to propose, transmit, and record changes to a specification.

Substitute item

An item that possesses such functional and physical characteristics as to be capable of being exchanged for another item only under specified conditions or in particular applications and without alteration of the items themselves or of adjoining items.

Support equipment

Equipment and computer software required to maintain, test, or operate an item or facility in its intended environment.

Survivability

The capability of a system to avoid or withstand a hostile environment without suffering an abortive impairment of its ability to accomplish its designated mission.

System

A self-sufficient unit in its intended operational environment, which includes all equipment, related facilities, material, software, services, and personnel required for its operation and support.

Systems Development Life Cycle

The activities in developing a computer systems project beginning with perception of a need for the project. Next a feasibility study is performed. If a project is accepted, the analysis, logical and physical design, and testing stages occur. When the system has been tested and errors corrected, it is implemented. During use, the system is evaluated, possible leading to maintenance changes. -- SmKershaw? - 18 Feb 2003 {From Information Systems Management, by James A. Senn}

Technical data

Technical data is recorded information (regardless of the form or method of recording) of a scientific or technical nature (including computer software documentation) relating to supplies procured by an agency. Technical data does not include computer software or financial, administrative, cost or pricing, or management data or other information incidental to contract administration.

a. Technical data is required to define and document an engineering design or product configuration (sufficient to allow duplication of the original items) and is used to support production, engineering, and logistics activities.

b. A technical data package should include all engineering drawings, associated lists, process descriptions, and other documents which define the physical geometry, material composition, performance characteristics, manufacture, assembly, and acceptance test procedures.

c. Technical data which provides instructions for the installation, operation, maintenance, training, and support of a system or equipment can be formatted into a technical manual.

1. 1. A technical manual normally includes operation and maintenance instructions, parts lists or parts breakdown, and related technical information or procedures exclusive of administrative procedures.
   2. This data may be presented in any form (e.g., hard copy, audio and visual displays, magnetic tape, disks, or other electronic devices).
   3. Technical orders that meet the criteria of this definition may also be classified as technical manuals. (Title 10, United States Code, Section 2302, "Definitions")

Technical data package

See "Technical data".

Technical documentation

See "Technical data".

Technical reviews

A series of system engineering activities by which the technical progress on a project is assessed relative to its technical or contractual requirements. The reviews are conducted at logical transition points in the development effort to identify and correct problems resulting from the work completed thus far before the problems can disrupt or delay the technical progress. The reviews provide a method for the contractor and Purchaser to determine that the development of a configuration item and its documentation have met contract requirements.

Training equipment

All types of maintenance and operator training hardware, devices, audio-visual training aids, and related software which:

a. Are used to train maintenance and operator personnel by depicting, simulating, or portraying the operational or maintenance characteristics of an item or facility.

b. Are kept consistent in design, construction, and configuration with such items in order to provide required training capability.

Unit

See MIL-STD-280.

Version

An identified and documented body of software. Modifications to a version of software (resulting in a new version) require configuration management actions by either the contractor, the Purchaser, or both.

Waiver

A written authorization to accept an item, which during manufacture, or after having been submitted for Purchaser inspection or acceptance, is found to depart from specified requirements, but nevertheless is considered suitable for use "as is" or after repair by an approved method.

Work Breakdown Structure (WBS)

A work breakdown structure is a product-oriented family tree composed of hardware, software, services, data and facilities which results from engineering efforts during the acquisition of a material item. A workbreakdown structure displays and defines ther product(s) to be developed and/or produced and relates the elements of work to be accomplished to each other and to the end product(s).

Work breakdown structure element

A work breakdown structure element is a discrete portion of a work breakdown structure. A work breakdown structure element may be an identifiable item of hardware, sorftware, service, data or facilities.

---

-- DirkWessel? - 09 Feb 2003

---

Other Resources

Some other resources to consider while trying to come up with the content for the above are the following works which also attempt to achieve a similar purpose:

• Active discussions on CMBoK content in the CM Community Forum.

• Chapter 7 of the SWEBOK is devoted to Software Configuration Management

• The Arlie Software Council's Little Book of Configuration Management,
  available under the "Products" section of the Software Program Manager's Network

• Handbook of Software Quality Assurance, edited by Schulmeyer and McManus, ISBN 0-442-28015-7.
  {-- SmKershaw? - 07 Feb 2003}

• MIL-HDBK-61 Configuration Management Guidance.
  {-- DirkWessel? 13 Feb 2003}

• CMII for Business Process Infrastructure, by Vincent C Guess, ISBN 0-9720582-0-6.
  {-- CarildaAThomas? - 18 Feb 2003}

• A Guide to the Project Management Body of Knowledge, by the Project Management Institute, 2000 Edition,
  ISBN 1-880410-22-2. (For more information about the PMBOK® or PMI, see http://www.pmi.org).
  {-- SmKershaw? - 12 Mar 2003}

• The Capability Maturity Model Guidelines for Improving the Software Process, Carnegie Mellon University Software Engineering Institute, ISBN 0-201-54664-7 {-- SmKershaw? - 27 Apr 2003 }

---