We can distinguish two types of auditing in product development projects. Process auditing looks into the project to find evidence that the (agreed) processes have been followed. Data auditing looks into the project and product data to find evidence that the data is correct. In which category falls configuration auditing?
The configuration management activities follow a process. Compliance to the agreed CM processes can be audited. According to CMMI, the process quality assurance is a PPQA responsibility.
Configuration management controls configurations, which involves aspects like storage, distribution and retrieval, status and promotions, traceability of changes, visibility of dependencies, etcetera. Compliance to the agreed CM definitions (storage locations, distribution databases, data reference links and other metadata) can also be audited by CM. But if non-compliances are the result of process deviations, it may be more effective to audit the process (by PPQA).
And finally, the correct content of configurations must be assured. This can be audited, which is usually called a baseline audit. According to the NASA, a "baseline audit verifies that a configuration item, or a collection of configuration items that make up a baseline, conforms to the documentation that describes it" and should be done by CM. However it is part of product quality assurance and therefore the auditing should be the responsibility of PPQA.
How much does that leave for CM audit? Not much!
Therefore, there is no good reason to consider auditing a primary element of CM. Of course, CM people may and often will assist PPQA people with executing the audits, in particular to find evidence (e.g. configuration records and configuration items). In this respect I agree with Anne Mette Hass in her book Configuration Management Principles and Practices that auditing is not part of CM.
Although it is generally accepted that Configuration Identification is a basic element of Configuration Management (CM), I don't agree that is should be. Why not?
The core of CM is control of configurations. To know what configurations we are controlling, we need to identify them. To avoid confusing one configuration for another, we need to uniquely identify them. Equal configurations should not be identified differently. As you see, CM is interested in unique identification, but how the identification looks like is not relevant, as long is it is a uniquely. Of course we need naming conventions, but how it looks like depends on the requirements for humans, automation or (CM) tools.
As such configuration identification is a secondary requirement for CM, not a primary element. The identification process does not even need to be part of the CM discipline, in which case CM is a user of identifiers, just like most other people in a project, but with a different purpose than other people.
Identification and naming conventions
An important implication is that when using a version control tool or a CM tool - I assume you understand the difference, but for now that's irrelevant - the unique identification may be left to the tool. This often results in unreadable object identifiers (e.g. 23987sg2b.38h830okdh34.8827481) but this is sufficient for CM. Even if you do CM by hand, you may just keep a list of sequential numbers.
In practice it is more convenient to have human-readable identifiers such as file names or document titles (or document identifiers) and/or to have identifiers that ease automation (scripting). Also it is often practical to put semantic (meta-)information in the identifier, such as a file type or a component identification. Because identification is not primary requirement for CM, the definition of naming conventions does not have to be a primary responsibility of CM people. You may document it in the configuration management plan (CMP), you may assist in the definition of a naming convention, your may be involved in auditing the compliance to the naming convention and if you are responsible for automation/scripting you may have their own naming requirements, but ultimately you shouldn't really care (as long as identification is unique).
Identification of everything?
Another reason for not considering identification as a basic element of CM is that not every identification should be the responsibility of CM. In principle, only the configurations that are under configuration control need to be identified for CM - note the different between "for CM" and "by CM". Some identifiers are an attribute value without identifying a configuration. Attribute values are for example enumerated values that are used on forms or documents, database identifiers (e.g. PRCR numbers) or just names (e.g. person names, product family names). In practice the distinction between an attribute value and a configuration is not always clear.
So what?
The reason that this is important is that CM is often held responsible for naming conventions and for identification. Commercial names are the responsibility of Marketing or Product Management. Identification of a certain technology used in the product is the responsibility of Engineering. Identification of production lots is a responsibility of Logistics. Not everything that has to do with identification should be considered a CM responsibility. In fact, CM is not really interested in identification as long as configurations can be controlled properly.
The international Certified Configuration Manager association (iNTCCM) is founded in March 2006, with the objective of setting the standard for professionals in configuration management. Recently, I joined the iNTCCM association as a member.
The last few weeks I have been more involved in hardware CM, or more specifically hardware CM for IC (chip) development. The design process for a chip if very similar to the design process of software.
To design an analogue chip, you first make a model the electronic circuits using an modeling tool where you connect signal and power lines between standard components. This model goes into a simulator where you "test" your design. For a digital chip, modeling is even more similar to software development: you write code using a programming language. A code checker is then able to calculate the output bits based on the input bits. So in both cases, you create source files to describe the system behavior and you run a build to check the code or model, and generate files needed to feed the (chip) fab. The different between hardware (chips) and software is what happens with the build result.
So I would expect that CM for the design process of chips would be similar or even identical to the design process of software. Well, in my present experience it is not! CM for chip design is as we did it for software in the 80-ies of the previous century, which is 25 years ago. There is hardly any parallel development and the only controlled versions are the current versions (/main/latest) and the baselines (tagged versions).
From a software perspective, absence of parallel development is hard to imagine. How come that chip design can do without, and still develop multiple product variants at the same time? The answer is: reusing block designs. A chip consists of a combination of (more or less) standard blocks. These can be high level blocks (e.g. an ADC, or a Bluetooth controller) or low level blocks (e.g. a transistor, an amplifier or a FIFO). These blocks are used to compose a chip design. The challenge is to combine as many blocks as possible, on a chip as small as possible, with the best performance as possible (e.g. low noice levels, minimum power dissipation, largest temperature range, etc.). The cost of a chip is determined by the size, but the market value is determined by the functionality (maximum number of blocks) and the quality (best performance).
One of the biggest challenges of chip design is how to place and connect the blocks and get still get the chip within spec. This is a 3-D problem - because a chip consists of multiple layers - and almost all changes in the design has impact on the complete chip. Therefore, you cannot change one part of the chip in one team, which another team works on another part, and therefore there is not much parallel development.
Development of those reusable blocks (e.g. making a smaller ADC using less power and with better performance) is done separately from the chip development. These blocks are called IP blocks. The designers of an IP block don't really care about placement and connection of the block on the chip; they care about the internals of the block, making the design possible. The only reason they care about other blocks on the (test) chips is interference: for example, what is the effect if we place the ADC next to a power management block?
Since almost all changes within an IP block have impact on the whole block, there is little use to designing one part of the block in parallel with another part of the same block. And if that is feasible at all, it is more useful to make them separate IP blocks which can be used (and designed) independently.
Now let's go back to configuration management. We have seen that chip design and IP block design have little use for parallel development. So CM does not need branching or streaming. If there is a need for (for instance) product variants, it is easy enough to just design them as separate product types, reusing the ideas of one product type for the other one. It may even be sensible to design them sequentially where the first product type takes several months to design and the next one only a few weeks after it.
If we look at software development, we may notice that the use of standard blocks is not "common practice". Designing a software system involves (1) designing the software blocks and (2) integrating them into a system. So what chip design does in two separated processes (usually also separate projects), is combined in a software project. This is possible because in software you have infinitely more freedom in interconnecting "blocks" and infinitely higher speed of changing the characteristics of a blocks. If a software designer has a block that "almost" fits in a system, it is often cheaper to change to block itself than to change the system around it to make it fit. In a modular design changing the block internally has less impact on the whole system than changing the environment of the block. And therefore, software blocks are often developed in separate teams that work simultaneously, using a (more a less) fixed interconnection called the interface architecture. Variants of blocks can - and do - exist simultaneously within the same system, where at compile-time, link-time, install-time or run-time is it decided which variant of a block is actually used.
The simultaneous and concurrent existence and design of software blocks, and the dynamics of integrating those blocks into a system is so much more complex than for chip design, that it requires a lot more complex configuration management approach. The SCM approach requires parallel development in branches and streams, both on block level and system level. It also requires a lot more flexibility of dealing with integration scenarios, variants and circumstantial differences. And last but not least, chip designs require an (expensive) manufacturing process that is very expensive to change once it is established, while software is the final product after the build. Consequently, the dynamics of change in software systems is much higher then for chip designs.
In summary I would say that although the design processes for chip design and software design look very similar, the configuration management requirements are of completely different magnitudes.
In the Netherlands, there is a new configuration management initiative called CM Platform [no link to a website yet]. The initiators are from Thales and KPN. Although it is still in its early stages of exploration, there is a clear need for more and better collaboration and sharing of the configuration management knowledge.
Other initiatives in the Netherlands are:
- Dutch Rational User Group (HRUG), initiated by Bosch Security Systems and TOPIC Embedded Systems
- CM workshop organized by TOPIC Embedded Systems and Philips Applied Technologies
In a podcast on IBM developerWorks, Dave Michell explains about Software as a Service (Saas):
the customer does not take ownership of the software, but they're going to rent this solution in a subscription model, and it's delivered remotely. And that's very different from the ASP model. In the ASP model, or the application hosting model, what the customer is doing is they're buying the software.Considering a configuration management system, such as ClearCase, many customers struggle with configuring the system for optimal performance, setting up and configuring servers, network and client parameters. In many cases, the users don't really care whether it is ClearCase, Synergy or Subversion behind the scenes, as long as that can do version control, baselining (or labeling or tagging), parallel development (or branching or streaming), delivery, rebasing, releasing, status promotion, structuring, setting attributes, and all the other CM stuff. Users don't care about sufficient licenses, disk space, replication across sites and other IT issues; they just want the system to be available and to work properly to their needs.
[...]In the Software as a Service model, again, the customer does not own the software. They subscribe to an offering and they buy that offering in a subscription model per user per month. So there's no software purchase to be made.
And the other key point here is in the Software as a Service model, the customer really has no say over what the infrastructure is. They don't get to decide what the hardware is or the middleware or the database — and more to the point, they don't really care.
So in the SaaS model, the customer says "I want to buy that application functionality. I'm willing to pay this much per user per month," usually is their typical model. "And the service-level agreement meets my needs. So I'm going to acquire that application that way."
So, the CM system seems a perfect candidate to be deployed as Software as a Service. Even more, if the CM service is offered as a Web 2.0 application, the internet will be the platform allowing local and global accessibility.
If in addition there would be a standard set of CM service features, the CM back-end could be supported by just any CM vendor that complies with this standard. The front-end could even be of a different vendor or proprietary to the customer, e.g. as a dedicated integration with other systems. Customers could then focus more on the tool-vendor that suites best with their organizational and IT needs, and users could better focus on dealing with true configuration management issues, rather than being hampered by infrastructure and IT issues.
Why wouldn't a product like ClearCase be offered an SaaS model, if IBM is such a promotor of SaaS?
There are many definitions of configuration management, most of them containing four basic elements: identification, control, status accounting and auditing. Although formally correct, the translation into practice is far from easy for many organizations. I wonder why this is...
Let's have a look at a car for a minute. From a user perspective, a car is a way of transportation from point A to point B. From a technical perspective, a car is an system where you can put people and luggage in and that allows a controlled way of acceleration, deceleration and steering. Given the technical view, there is no way to define that a car brings you from any particular point to another point.
Now let's go back to configuration management. In fact, identification, control, status accounting and auditing are the technical view on CM. But what is the user view on CM? Why do we need CM?
I think that the main and possibly only reason why we need CM is that we need to communicate and share. The effectiveness of communication depends on the integrity of the information we communicate and the effectiveness of sharing depends on the integrity of the objects we share (work products). If the information and work products would be static, a (simple) library or stocking system would be enough. But in practice the information and work products are not static; they are evolving in a planned way (if the planning is followed). The integrity (or validity) of the information and work products also constantly changes.
Now because the information and work products are constantly changing, we need some guidance in determining what is correct and what is not. That's why we need concepts like streaming or branching to facilitate parallel development, we need the concept of tagging, labeling or baselining to determine the status of a particular configuration, we need the concept of promotion to visualize the state of evolution.
Communication of information, sharing of work products, and assuring the integrity of the whole while it is constantly changing, is the main challenge of configuration management. Hopefully, it is easier to understand configuration management from this angle than from its formal definition.
Jens Norin has written een article about Lean configuration management. There is a lot that I disagree with, but it also gives a lot of things to think about.
Recently, I have created a Configuration Management space with an underlying Configuration Management wiki on IBM developerWorks. Initial focus will be on IBM products (ClearCase, ClearQuest and UCM) and on CM concepts and practices. Later, it is my intention to extend it to other CM products too. The space and wiki are an extension to the existing discussion forums on dW.
The content is still in its initial stages, so bear with me to let it grow. For that purpose I am still looking for co-editors who are willing to put more content to it. Although wiki's are intended for open collaboration, I want to be careful with making it completely open for modification to the world to assure proper structure and quality.
For new events or other news and changes on the CM space portal, feel free to contact me.
In the article Writing a book is like developing software, Roy Osherove compares writing a book with writing software. Now let's assume that we would write books like we develop software.
Most books are written by a single author. Take for instance The Lord of the Rings by J.R.R. Tolkien. Suppose we would take up the assignment to write a sequel of this bestseller, but develop it like a software product. Suppose some of the requirements are
- It must appear on the market in English, Spanish and Russian simultaneously
- It must appear before Christmas 2007
- It must equal or exceed the success of the current books
To reduce intercontinental communication across timezones, we will assign different parts of the book to each team. Each team will write in its native language to assure the highest quality of writing. When one team finishes a part (or a preliminary version of it), it will be sent to the other teams for verification and translation.
The verification process will compare the story with the requirements. Which requirements? How do you make "exceed a previous success" SMART, if you cannot sell the book before finishing it? This is a job for marketing. They have to verify if the book will sell good enough.
We were talking about assigning parts to different teams. Which parts? If we divide the book into chapters, we can assign a chapter to a team. Which chapters will we have if we don't have the story yet? But the story is to-be-developed by the team. To divide into chapters we need the overall plot, in abstract form. But, who is responsible for the overall plot?
Okay, division into chapters seems to be a bad idea. Let's divide into characters (persons in the story), and assign different characters to each team. May be the cultural background of each team may even be an advantage for writing and for the overall result. But how can you write a story of characters in separate teams, if there is not plot that connects those characters? Characters need to interact in the story. Furthermore, different teams will be writing simultaneously on the same part of the story. So we need to integrate parallel updates, and we need to review the different story elements before integrating them.
Another issue is that during the story, we build up a history. If for example two characters meet in the beginning of the book and become friends, they cannot be complete strangers and enemies lateron.
Sigh! We need a story architecture that defines the development of characters and the development of time (history) across the whole book. It also defines the characteristics of the characters, the landscapes they visit, timing constraints (e.g. you cannot be at two different places in the same timeframe).
And we need configuration management to assure that the correct versions are reviewed, verified and translated. Especially translation is a dangerous one: if you translate an old Spanish section to Russian, the English and Spanish teams will not discover it because they cannot read Russian, except the people who translate from Russian. But why would a Spanish translator be bothered with reading a section that was originally in Spanish? So, CM must assure correct version and status handling.
I can go on and on, but probably you have lost faith that a book written this way will (1) be ready before Christmas 2007 and (2) exceed the success of The Lord of Rings. Yet, many companies develop their (software) products in multisite projects, with teams in America (US, Canada), Europe (UK, France, Germany, the Netherlands), Asia (India, China, Singapore), and without proper configuration management - except branched version storage and multisite replication.
Is multisite book-writing a good idea? And multisite software development?
It has been a while since I posted about the nightmare of component based development. But, I promised to revisit, so here is another one.
Component based development may be a blessing to some product developments, but it can also be a nightmare to others. In part 1, I discussed the problems of finding a stable baseline as a reference for new development when developing multiple components simultaneously. Part 2 discussed the issue of reducing scale which resulted in both early and late integration. Part 3 focussed on the issue of ownership when developing multiple incarnations of a component simultaneously.
As the title says, component based development can be a nightmare. Complexity of systems and products continuously increase, and functionality originally designed and marketed as separate products, is being integrated. For example a camera in a mobile phone, GSP tracking in car navigation systems, medical monitoring in watch integrated with cellular communication, and much more. What originally was designed as a product becomes a component within other products. Components may be split or merged into other components. And what originally was marketing by company A may becomes an integral part of a product line for company B.
Even though component based development may be a nightmare - if not done properly, the need for componentization and flexibility with components is growing. It seems unavoidable that some day we have to face the problems of component based development anyway, whether we want or not. And this day will probably be sooner than we may expect.
Trying to integrate different products and components, that were designed with different architectures, is a challenge by itself. If there is time to do it properly, we may come with a proper solution, a new architecture. But there is never enough time to do it properly, so we need a way to at least control it in a proper way. It may even become worse when the need for integrating existing products and components exceed the need for new functionality. That may lead to a completely different approach to systems design and may redefine the term "reengineering".
Now what can we do?
Well, we cannot make a chaos-beyond-control first and then hope for a generic solution to regain control over the chaos. We don't have time to do that because the competition will beat us in the meantime. it must be a controlled evolutionary path.
This means that configuration management will become more important to control product development, and it may well become the most important control discipline. It will not only control the work products (inputs, intermediate work products and outputs), but also strategic roadmaps information and the information and knowledge of the company that is required for product development. It will be too difficult and too extensive to oversee all information by a single person or even by a team of people.
The "art of integration" will be a combination of product architecture and configuration (and knowledge) management, and these two will become even inseparable and indistinguishable.
Configuration management may even become more an integration of product architecture and project architecture (or more general, the architecture of an organization and its processes).
One of the duties of configuration management is to be able to reproduce old configurations. For this purpose, configurations are baselined, labelled or committed. When you need the configuration, you just create a workspace that looks at the old baseline. Using branching, one could even make changes relative to the old configuration (if the CM system supports it).
Now surprisingly, to me at least, in the old configuration the supportive (meta) information is not reset to the old state. For example, the database of Defect records is not set to the old state. If we have solved a problem recently that was already known (and left unresolved) in the previous release, the defect remains in resolved state even though we have a workspace where the problem still exists. Isn't that plainly a wrong representation of the reproduced state?
If we then decide to resolve the problem on the old release, we need to make a new defect record. This new record will have a submission date after the release we try to solve it in although the problem itself was discovered before the release. Wrong representation of the truth again!
Wouldn't it be correct to have other (meta-information) systems support reproduction of old configurations and branching in the same way as the configuration management system does?
At one of the companies where I work, they have introduced component-based development. The total system is divided into subsystems and each subsystem is divided into components: (1) the subsystem's external interface and (2) the subsystem's internal "body". The project is divided in a number of sub-projects, each responsible for a number of subsystems.
After several months of experience with this approach, we do not seem to get the integration process right. The primary reason is that each subsystem is developed against a "stable" system baseline, where the system baseline is the integration (or composition) of individual subsystem baselines. But each of the subsystem is evolving in parallel with the other subsystems, so when trying to integrate newer baselines of all subsystems, the configuration is a composition of subsystem versions that have never worked together before.
Some consequences:
- Build failure
- Smoke test failure (verifying only basic functionality)
- Regression test failure (verifying former functionality, but not new functionality)
- Integration test failure (verifying new functionality in an integrated environment)
Our struggle is how to get this right, so if you have ideas then do not hesitate to give me some suggestions. I will follow up on this subjects in my blog.
Before going into some ideas for the integration process, let me tell you something about the history. The previous project was a monolythic system developed on a single branch. Although the intention was to have a daily build, practice showed that it was not feasible to make a stable system configuration every day. So, the cycle was delayed to a weekly cycle.
However, since we were facing a large development team (and a large system), all changes made in a week was too much to make a stable configuration on a weekly basis. Delaying more would probably make it worse.
So that is why we came up with the idea to reduce the development scope to subsystems rather than the whole system. Architecture was changed and SCM was changed too, into subsystems. But now we are facing the problem that there are too many trajectories running in parallel and delivering every week a new subsystem configuration for system integration. In addition, the number of dependencies between subsystems became unmanageably large.
So we came up with the idea to reducing the amount of configurations by clustering those subsystems, not into a single system (as we hard in the past) but into four or five subsystem clusters. For each cluster, we can make a weekly or even daily build and for integrating those clusters together we can make a weekly or (bi-)monthly cycle.
However, this approach implies that witin the clusters there is early integration, while across the clusters there is late integration. This implies that the clusters must be chosen such that the number of inter-cluster dependent changes are minimal. However, when we have an inter-cluster dependent change, it must be developed within two or more clusters at the same time and pre-integrated (and tested) before it is officially integrated at overall system level. But crossing the boundaries of clusters will increase the managerial complexity again, possibly forcing clusters to be deliver simultaneously to system integration.
As you see, the problem is not very simple. If you have any idea how the next step could look like, don't hesitate to send me a comment.
With component based development comes parallel development. Different components are developed simultaneously, and different product integrations may be performed simultaneously. This leads to the problem to determine which development activity has the highest priority. One product development (or integration) may be higher priority than another, but the technology roadmap of a component may have a long-term impact on product developments to come and thus requires a higher priority.
So even though component based development is a way to achieve efficient development, priorities may be conflicting even beyond the scope of authority of the responsible managers. In principle, the upper manager should decide, but he may have insufficient insight in the all the relevant factors. In my experience, marketing usually dominates technology and thus short-term gains dominate long-term losses.
To protect the value of technology roadmaps, many organizations adopt the concept of ownership. In my opinion, this is an artificial solution as it gives more or less unconditional priority and authority to a single department, which places a rational decision on a political agenda. One of the counter-effects is that the owner of a component does not allow anyone else to modify the component, or even access the internals (source code) of the component.
This introduces another undesirable effect, on configuration management. The owner of a component claims proprietary ownership of the component and thus any change must be performed by or authorized by the owner. But if different product developments run in parallel, product-specific changes to a component (or prototyped changes) are delayed because of limited resources (and thus prioritizing of activities) require the owner to make choices. So, the "product developers" will ask for a preliminary copy of the component to make their own changes, put those changes in the product and only if they prove that the change is viable (i.e. the customer is satisfied with it), they submit a change request at the component owner.
But since the component owner has limited resources, the (prototyped) change is likely to be "reused" and taken over almost entirely without much re-engineering to comply with the architecture. Even worse, the prototyped change may have been developered in a non-standard CM system using non-standard processes (e.g. a quick & dirty implementation). Thus, the perception grows that the standard processes are very inefficient (late results). And since the component owner does not allow "hacking" into his CM system (which increases the risk for instability of the entire code base), the perception is grown that the CM system does not support parallel development in a safe way.
In other words, component based development may be perceived as less efficient and less effective because the efficiency and effectiveness is limited to strict compliance with the rules. As a result, breaking the rules will make component based development even more ineffective and inefficient which encourages the decision makers to reject the approach altogether.
Is component based development doomed to fail by its success? How can we prevent that from happening?
Configuration management systems, like all computer applications nowadays, are become more sophisticated and more extensive in functionality. In the "old days" organizations had to consider carefully about processes and customizations of CM tools because it took them large investments in effort and time to tailor to organization specific needs. A positive effect was that organizations did actually think before they implemented a solution, and we eager to stick to it because of the difficulties to tailor the processes and tools differently.
Nowadays, CM systems are so easily customizable and tailerable to changing needs that many organizations have stopped thinking carefully about their way of working and are completely focussed on tool performance and using the features of the CM tools anyway they like. Tool vendors wisely anticipate on this trend by making it more and more easy to adapt the tool and adopt whatever process model the customer wants.
Unfortunately, CM is become more and more tool oriented rather than having focus on the underlying concepts of CM. CM systems have become versioned file systems that only perform storage and retrieval of data, support random changes by random people, copying and merging all over the place and losing track of any quality or content attributes. It is become increasingly difficult to convince engineers and managers to apply solid configuration management principles as a means to manage risks. Tool performance, database availability and uptime, reliable backup, restore and data transfers are become increasingly more important than data integrity (which is not the same as database integrity), control of configurations, correctness of status (quality, state in the workflow, responsibility, availability, etc.) or traceability of changes.
"Who care how we got here? As long as we can make money out of it, we're OK!"
"Why bother about [your] configuration control processes? We are responsible for the results, not the configuration manager!"
With pain in my heart I have to admit that the professionalism with respect to configuration management is decreasing, as a result of CM tools making it (too) easy to do everything.
On a crossing with 8 directions you have 2 times more chance of taking the wrong direction with the same amount of consideration as on a crossing with 4 directions. If you than think less because it is very easy to go any direction and return to the crossing, it is even more likely to take the wrong one. If you then have to explain to the people coming next which direction to take, you are likely to tell them a confusion story about which is the "best" direction. Finally, every generation will degradate to a level of trail & error, instead of rational thinking.
There are many different definitions of Configuration management (CM), as can be read at Brad Appleton's website. I personally like the old and short definition by Susan Darts stemming from the 90-ies:
(Software) CM is a discipline for controlling the evolution of (software) systems
I like this definition because it implies a constant change of the system (evolution), but change in an orchestrated fashion (controlling), requiring distinct knowledge and teaching (discipline) to perform. Without change there is no evolution and there is no need for CM to control it.
The big difference with Project Management (PM) is that PM controls targets, resources and activities over the course of a project, while CM controls the changing system itself. The timespan of PM is a project, while the timespan of CM is the lifespan of a system which lasts until end-of-life (i.e. end-of-evolution) of the system. And when does CM start? Well, as soon as the evolution of the system starts to be controlled, which is at or before the start of a project.
So, CM starts before a project starts and ends until after the project has finished.
Traditionally, software configuration management (CM) is concerned with version control on software modules. Many CM systems are very capable of handling source code files and files generated from those sources (derived objects) in workspaces that look very similar to the ordinary file systems.
Most of them are also able to control parallel evolutions of those files (branching and merging), attach attributes to those files as a status indicator (labels, attributes) and allow automation on particular events (triggers). Only a few CM systems support a higher abstraction level concepts like subsystems/components/modules, projects, streams, baselines, tasks/activities.
In most organizations that I have seen, there is a enormous gap between the CM for "code", the CM for "documents" and CM for "data" that is neither code or nor documents (e.g. requirements database or a test data set), not to speak of CM for physical objects (e.g. hardware components, mechanical components, books or CD-ROMs).
There are some some questions that I find very difficult to answer during development, but that I would expect a configuration manager to be able to answer. Of course, after product release, when all documents are approved and all functionality has been implemented these questions are easy, but not during development.
- Here is a test system with this software baseline installed on it. What is the corresponding document baseline that describes how the system should behave and how it should working internally (in other words: which versions of which documents)?
- Which versions of hardware boards en chips on those boards should we use?
- Which version of each of the requirements in the requirements database correspond to those software baseline?
- Which test cases, test scripts and test data sets should I use for testing, and which version of them?
- Which tools have been used to make this software baseline, and which version of them? Which tools and which versions of them should I use to analyse the system's behaviour and data output?
- Which versions of the plans (project plan, configuration management plan, quality assurance plan, integration plan, test plan, etc.) apply?
- Which problem reports apply to indicate the known problems?