Mr. Langston. I'm not quite sure where you're coming from with some parts of your response, but I'll try to clarify things. Perhaps you're less familiar with the software side of CM, especially as standards have done a rather poor job in addressing software development, which is very different from hardware development. (That's another story.)
[quote]If the premise is false, then any conclusion that follows is false. [/quote]
Actually, more accurately, if the premise is false, anything (true or false) can be proven to be true from that premise (which means the conclusion may be false or true).
[quote]Does this mean that the definition of CM is dependent upon the tools one is using? (Or did you mean that an employees specific tasks are so dependent?)[/quote]
It does not mean or imply that the definition of CM is dependent upon the tools one is using. It does imply that what the CM Manager DOES(specific tasks) is dependent upon the tools one is using.
[quote]"CM is first a discipline; then a tool." (or something close to that).[/quote]
CM is a discipline - it's not a tool at all. Tools support the CM process. They are just software - not CM. Tools can help automate, organize, present, etc. But that's what they do, they HELP. CM is a discipline. A CM Manager is not a discipline. It is a role within the CM discipline. And this topic deals with what a CM Manager does and which tools (s)he uses to help do them.
[quote]<Builds> may have a little or a lot "to do with CM," and certainly the CM discipline is associated with or riding herd on these things, but that is a far cry from builds being CM.[/quote]
Specifically, there are three contexts for the noun "build" within software CM. The first is the "build" as a definition of what is to be built (and implicitly or explicitly how). The second is the "compiling and linking" part. The third is the artifacts of the build, including the build results.
As I mentioned before, the "compiling and linking" have little to do with CM, but certainly not nothing to do with CM, with the dependence being higher for languages that require a certain compile and/or build ordering. (e.g. Modula 2 required interfaces be compiled prior to implementation sections. Same with ADA). Unless these compile relationships are identified within the CM repository, the compiling and linking become less and less manageable. It is therefore necessary as part of CM Identification to not only give a label to these "sections" to be compiled, but also to be able to identify their attributes.
Futhermore, within the CMDB, it is normal to give these "sections" (generally files) unique identifiers, as required by CM discipline. However, such unique identifiers are different than those understood by the compilers and linkers. Hence, it is also necessary to be able to translate this identification into compiler/linker friendly identifiers (typically file names, each with a directory prefix). Furthermore, the directory prefix can change from one revision of a baseline to another (or from one build to another). Therefore, CM identification requires that we be able to relate the internal CM identification to this friendly (external) identification in a context-sensitive manner. (E.g. which directory prefix do I use on a file for build A vs build B ). This is quite a complex part of CM Identification that the vast majority of tools cannot cope with fully, and so short cuts are often taken which limit the functionality of the CM tool with respect to the required CM Identification.
Furthermore, it is necessary to be able to, given a build identifier, identify exactly which revisions of each object are in the build. This can be done from the CM repository with many tools. But it is sometimes necessary to be able to ask the same question of the software while disconnected from the repository. As such, some CM tools have the ability to insert identity information into the executables (through the build process) so that the file revision identifiers can be determined even when there is no access to the CM repository. This identification is still part of CM, even though it's not performed with access to the CM tool.
Also notice the need for unique identification of each "system" build (i.e. each significant, and hence recorded, build). One key use here is to ensure that the build artifacts are linked to a specific build definition, giving traceability from the actual deliverable back to the constituent components.
But this is only the start of the use of a build id. Let's look at the CM Audit Function. In software, a CM audit is not done by sitting down with someone and executing every functional case before their eyes and verifying the results. This would take an insane, unacceptable amount of time. Instead, the functional audit is done by ensuring that the requirements have all been addressed successfully. This in turn requires a record, not only of test cases and how they relate to the requirements (requirements traceability matrix), but also, of which test cases have been successfully/unsuccessfully run against a specific build, identified by its build identifier. If this specific capability is not present, then, except for very, very small software projects, you will not have adequate means to complete a functional audit. It is these build records, that is, which requirements have passed functional audit for a specific build, that help determine whether or not a build is going to pass the audit. Now in a large software project either the set of test cases is insufficient, or you will never get all test cases to pass for a given build. But that's OK - because it's software and can be fixed in place if necessary. So the passing of the functional audit has more to do with confidence of the software. This in turn is deduced from the Build's test case metrics, along with careful analysis of the types of failures that occur.
And it gets a lot more complex because requirements change over time, and so do the test cases, and the set of test cases that apply to a specific build (i.e. set of build artifacts).
In short, if the CM Manager does not take responsibility for the various aspects of performing builds, you will not be able to complete a software functional audit. As well, given that you can, you still need to ensure that you can identify the build, and verify that the components of the build match the physical audit (which revisions of which files are in the build executables, which in turn is traceable to which changes have gone into the build and which requirements are ultimately addressed by those changes). Tools HELP immensely here, but tools are not CM. It is also critical that builds do not go downstream (from development to integration to verification to validation to alpha to beta to production, etc.) without the proper criteria being defined for such promotions. Otherwise, although you have identified builds and failed their audits, they very well could end up in customer sites. So this promotion level, including the criteria, are an integral part of the Configuration Audit.
In software, the physical audit may be done manually for very small projects, but ultimately, you have to have confidence in your tools that it is putting into the builds what you expect is going into them. This confidence is gained in two ways: inspecting components of builds, and inspecting the tools and process that cause the components to end up in the build (i.e. artifacts).
[quote]Why is it "critical" that the CM Manager take responsibility for the activities you list?
[/quote]
I've dealt with some of the activities above... to continue:
One specific facility for doing these inspections is Build comparisons. At a low level, you might compare which file revisions went into build B that weren't in build A (and vice versa). But higher level build comparison tools allow you to compare which outstanding problems were addressed in B since A, which features and requirements were addressed in B that weren't in A, and which test cases passed (or failed) in B that did not (or did) pass in A. These are crucial for configuration audits. Build Frequency affects how easily such comparisons can be done. Incremental builds, as opposed to full builds, can be used (if done properly) to minimmize the re-creation of artifacts that aren't affected by the changes between builds. This may or may not make comparisons, and hence audits, easier, depending largely on your tools.
There are many other aspects of builds that affect status accounting. The state of a revision of a file is either in-progress or completed. Not so for the state of the build, which has a much more complex life cycle than a file revision. The integration and verification steps on a build allow us to identify the state of the changes that have been applied (often tagged against the file revision instead of the change package). But let's leave that for now.
Configuration control does not just deal with how change occurs to a configuration, but also who has access to perform such change. As such, things like roles, enforced process and access control are an integral part of configuration control.
In the same way, status accounting is not just a recording of "states". It covers an important "reporting" capability so that the "accounting" can be done. And it is important to be able to make decisions in a timely manner using the capabilities of the tools to provide status information. In this sense, the more you can adjust your tools to present the information each role requires with as little effort or change for error as possible, the more successful your status accounting capabilities will be. This is why we equip our CM guys with the ability to improve things like traceability navigation, build comparisons, process visibility, summaries, etc. Often this is done through the creation of dashboards, with a dashboard satisfying a particular aspect of a role (whether a CM Manager role, a product owner role, a developer role, or otherwise). Status accounting affects all roles because all roles need the communication of information which allows for proper configuration control, context-sensitive identification and various audits.
But you're right. If a CM Manager has to turn on his own light, electrician is not part of the CM Manager role. But even if it were, that has nothing to do with the definition of CM. So I'm not sure how you got to "What is CM" from "What does your CM Manager do".
But you sure raised some good questions that, when answered, help to clarify how my "carelessly tossed out" examples relate directly to the CM discipline. So thank you for the opportunity to clarify these. Sorry if it's not crystal clear - there's only so much time I can spend on such clarification. And there's tons more to add, but hopefully the picture is sufficiently painted here.
Now back to the Topic: What does your CM Manager do, and which tool(s) does (s)he use?
