Configuration Management - Change Request Number Traceability

I would like your help with understanding the following subject:

A change request is processed in a change control tool. Each change request has a number. If a proposed change is accepted, a schedule is created for making the change.

When it is necessary to store the configuration items modified in the configuration system, we have the option of describing what we have done. We record the implemented changes and the reasons for the changes, however we don't track the change request number.

Will the lack of tracing the change request number create a weakness in the Configuration Management Process Area? Is just recording the historical information about the changes in the comments and using the change control tool sufficient?

How important to your projects and business is it to track the change request number? Have you encountered issues with change control on the projects because you have not maintained this information? Recording and tracking the change request number is a very easy thing to do and I am wondering why you haven’t done that.

What also concerns me is that you imply that recording a description of the change made to a baselined item may be optional. If this is true, then it is then possible for someone to decide not to record this information. Recording the information should be mandatory.

Not tracing the change request number and the possibility of not recording a description of the change sound like high risk items that can cause you difficulties in the future. As a risk mitigation, I would record all change numbers and require that all changes made are clearly described in the event that someone else in the future needs to understand the nature and reasons for the change.

And since you are using a tool, which I assume is an off-the-shelf product, you may in fact be tracing the change request number and not even realize it. But from an appraisal point of view, it sounds like you might have most of Configuration Management covered and the problem you are asking about might be viewed by the appraisal team as a weakness. But is it a Goal breaking weakness? This a question that must be answered by the appraisal team.

Configuration Management - SP 1.3-1 , SP 2.2.-1

I would like your opinion in relation to situation below.

Once a change was been verbally approved, is there some problem in relation to CM SP 1.3 (Create or Release Baselines) - sub-practice 1 and CM SP 2.2 (Control configuration items) - sub-practice 2, if the record of the modification in the schedule and the change control tool are done in subsequent periods until a maximum limit of time of the defined period for monitoring of the project?

Example:

Verbal approval of the change - Monday

Beginning of the work - Tuesday, with storage of the configuration items in the configuration system (without baseline).

Register of the change in the change control tool and record of the activities in the project schedule - Friday

Collection of the progress and effort - Next Monday (weekly Monitoring, all monday)

In advance, thank you very much.

The first problem I see is the verbal approval. Verbal approvals are difficult to document or provide as evidence and over time can be forgotten or misremembered, not to downplay the risks associated by not documenting decisions.

Secondly, since you are asking about the sub-practices, that makes me wonder if you have taken the SEI’s Introduction to CMMI class. If you have taken the class, your instructor should have made clear to you the distinction between the required, expected, and informative components of the model. The sub-practices are informative components and are therefore provided only as information to help you understand the intent of the Specific and Generic Practices and Goals. To be clear, you are neither required nor expected to implement the sub-practices.

If the weekly schedule you described works for your projects, then you should be able to map it to the Configuration Management (CM) Specific Practices (SPs). However, the described weekly schedule sounds like it may have some gaps.

I strongly suggest that you have an SEI-certified Lead Appraiser conduct a Gap Analysis (Class C appraisal) of your organization, especially CM, to determine the gaps between your implementation and the CMMI.

Requirements Development/Management Question

I was slightly confused after reading this statement in the Requirements Development (RD) Process Area (PA), Specific Practice (SP) 2.1 states "Establish and maintain product and product component requirements, which are based on the customer requirements"

The informative material goes on to say "The modification of requirements due to approved requirement changes is covered by the "maintain" function of this specific practice; whereas, the administration of requirement changes is covered by the Requirements Management process area."

I do not understand the difference between maintenance of requirements in RD and administration of requirement changes in REQM. How are they different?

The Requirements Management (REQM) Process Area (PA) is there to help an organization manage changes to an agreed to set of requirements (baseline). So, no one makes any changes to the requirements (add/modify/delete) without following the documented requirements change control process, which should include review and approval by the relevant stakeholders of the requirements.

And actually, REQM is a specific instance of Configuration Management (CM). But REQM is such an important and vital practice that it is its own Process Area. So it is entirely possible for an organization to have one Change Management process that it uses to manage changes to requirements, documents, plans, test scripts, code, etc.

In contrast the intent of Requirements Development (RD) is to actively elicit and further refine the requirements that are then agreed to and incorporated into the requirements baseline. Specific Practice 2.1 contains the phrase “establish and maintain,” which has a special meaning within the context of the CMMI. If you have taken the Introduction to CMMI class you would have learned what this phrase means. This phrase is also defined in the CMMI Glossary and it means formulate, document, and use. For SP 2.1, this means that the product and product component requirements are formulated (elicited, discussed, refined, reviewed, etc.), documented (written down in a requirements specification, requirements management tool, etc.), and used (develop the project plan, design, code, tests, etc.).

So the connection between REQM and RD is that proposed requirements changes are reviewed, analyzed, approved, and processed by REQM and the authorized and approved changes are propagated through the baselined requirements by RD.

I would not get too focused on trying to understand the separation between REQM and RD. You have identified one of the many areas in the CMMI where there is a tight coupling between PAs, if not overlap. What is important is that you

1. create a requirements baseline that does not change unless there is an approved change request,
2. investigate, impact, review, and disposition all proposed requirements changes with the relevant stakeholders (approved or rejected), and
3. only make approved changes to the baselined requirements and appropriately update the traceability

CM SP 3.2 Evidence Guidance

The release of CMMI v1.2 included a change to the examples for CM SP 3.2, Perform configuration audits to maintain integrity of the configuration baselines.
Examples of audit types include the following:

• Functional Configuration Audits (FCA) – Audits conducted to verify that the as-tested functional characteristics of a configuration item have achieved the requirements specified in its functional baseline documentation and that the operational and support documentation is complete and satisfactory.
• Physical Configuration Audit (PCA) – Audits conducted to verify that the as-built configuration item conforms to the technical documentation that defines it.
• Configuration management audits – Audits conducted to confirm that configuration management records and configuration items are complete, consistent, and accurate.

Are projects now required to provide evidence for each of these examples?

As the Configuration Management (CM) Specific Practice (SP) states, these are examples of Configuration Audits and are part of the informative material of the model. Therefore these examples are neither required nor expected. As long as the organization and projects are performing some kind of configuration audit(s) that assesses the integrity of the baseline(s), that meets the intent of the practice. For a SCAMPI Appraisal projects are not required to provide evidence for each type listed in the examples.

What is the Difference Between a Physical Configuration Audit and a Functional Configuration Audit?

A Physical Configuration Audit (PCA) is a Configuration Management (CM) audit that verifies that whatever you have built conforms to the technical documentation that defines the build. What that means is that CM must compare the configuration of the as-built product to the design documentation of the product. For example, CM looks at the list of all the configuration items (versions, etc.) in the as-built product and compares that list to the list of what is supposed to be in the product.

A Functional Configuration Audit (FCA) is a CM audit that verifies that the functions of the as-built product match the baselined functional requirements and that the operational and support documentation is complete and satisfactory.