7
Most people think they know what configuration management (CM) means. And they're right. Unfortunately, they don't all think it means the same thing. So let's look at some of the basics of CM. This isn't a "how to" article, as much as it's an "at least" article: at least you'll know what to expect for the rest of this article.
The most basic function of software CM involves version control. That is, being able to identify different versions of a file and retrieve an arbitrary version by number or date. Everyone can do this.
Beyond version control, tools begin to diverge. The next level up is "labels" or "releases." This means putting a uniform name, like "product 1.1," on a whole collection of source code versions. The idea is that while file abc.c may have been at version 14 when release 1.1 shipped, file xyz.c may have been at version 1. Thus, abc.c-14 and xyz.c-1 are both recorded as having release "product 1.1" associated with them.
It turns out that versions are too small to track, but releases are usually too large. Product and project managers want to track at least one intermediate layer, which corresponds to their fundamental unit of change. Typically, these changes are called change requests, modification requests, engineering change orders, or something else with a C or R in the acronym (examples: QIR, SCP, SCR, CR, ECR, CO, ECO, MR, MMR, EMR, DR). I'll use "CR" because it's generic.
This is a fuzzy area, because many tools don't have a CR system built in. If they do, not everyone opts to use it. Instead, this is the first place where there may be a change from one vendor or toolset to a different one. Vendors like Mercury Interactive, Remedy, and Vantive all make products that aren't meant to be CR tracking tools, but that may be used that way. The key capability here is that some mechanism exists for the developers to associate the changes they make in the software with both the product release and with the CR that prompted this change.
If you don't have all these capabilities, you should look into getting them. There's at least one free package that can do each of these things, and many can do more than one. If you're already using a product from a particular vendor, visit that vendor's web site. There's probably a list of products available to you as a customer that includes all these capabilities.
Requirements Management (RQM) Basics
Let’s now discuss requirements management (RQM), starting from the very beginning: What's a requirement?
A requirement is an objective, verifiable constraint on a system. Ideally, a requirement is independent of other requirements (as much as possible) and has a very small granularity (constrains only one thing at a time). This is a requirement: The spacecraft shall weigh not more than 400 kg. This is a marketing slug pretending to be a requirement: The new model car shall be available in a range of popular and exciting colors.
Writing requirement documents is a black art. To avoid having to master "shall-do voodoo," most people copy requirements documents from an earlier product, use a vendor-provided example, or structure their requirements as a mirror-image of the RFP/CFP that initiated the product development. This is fine, but it does explain why some requirement documents are a little bit non-intuitive to the reader. Like CM tools, there is a large market space for RQM tools. All RQM tools have certain things in common:
· Requirements are mostly text. A good RQM tool has a word processor built in.
· Requirements are not entirely text. A good RQM tool will have the ability to mimic a spreadsheet or a database, to store tables and to associate arbitrary attributes with any given requirement.
Once you have an RQM tool, many things begin to look like requirements. Accordingly, RQM tools are also used to write validation plans, test documents, design specs, and the like.
As a rule, requirements are never stand-alone. An RQM tool will give you the ability to create relationships or links between a requirement in the top-level user requirements document, and a different requirement in the ergonomic compliance design (ECD) document. Plus create a different relationship between the ECD and the standards conformance validation plan.
Thus, "the device shall adjust to support users between 4'9" and 6'3" tall." can be linked to "the vertical adjust minimum shall be 10 degrees below horizontal" and to "the vertical adjust maximum shall be 22 degrees above horizontal." Those requirements can be linked to, "Measure the vertical adjust range using a protractor." In short, there is no such thing as "one requirement." There's also no such thing as a "one requirements document." They come in groups and a good RQM tool will help you create and manage a group of requirement documents as a network of related data.
As mentioned earlier, requirements are not all text. In fact, from the point of view of the requirements manager, CM manager, etc. the text is the least interesting part. RQM tools will give you the ability to associate columns of data with your requirements. Think about a spreadsheet, here. Column A is your internally generated requirement ID number. Column B is nice and wide, and is where the text of your requirement goes. What are columns C, D, E and so on, though?
One thing that goes into the database part of a RQM tool is all those links. If this is a high level requirement, then you probably have a relationship called implements which links high-level to low-level requirements. If this is a low level requirement, you probably have a relationship called tests which links low level requirements to test cases. You can use these relationships to verify that you have no unimplemented high-level requirements, and that you have no untested low-level requirements.
Another thing that goes into these columns is responsibility. Who's responsible for this requirement? If a change is proposed to the maximum gross weight of the spacecraft, who will be in charge of the review board? Requirements change management, though, is a topic for a different article.
Some more columnar data you may want: active CRs, release implemented, release changed. These can link your requirements to any active CRs involving the requirement, to the release of the software in which the first implementation of this release occurred, or to the release of the software in which the most recent update took place.
Finally, you need to be able to perform scripted updates and data extraction. You should be able to extract the data, and the relationships, from a single requirement or a group. Likewise, you should be able to update these values from a script.
As with the CM section, all these capabilities are basic. If your RQM tool cannot do these things on the platform where you need them then you should look at a different tool. Release Management (RLM) Basics
Not every CMer is an RLMer. In many organizations, RLM responsibility belongs to the project or product management team, while SCM responsibility lives at the development or tools support level. Let’s have a look over the wall.
The good news is that, unlike the CM and RQM spaces, there isn't a huge RLM space teeming with competing vendors all making disparate claims. The bad news is that there aren't any tools for RLM. Instead, RLM is handled either by using project management tools (e.g., MS Project) stretching down into the RLM space, or by using SCM tools (summary report of all changes checked in to this branch) stretching up into the RLM space. At least two vendors are frantically developing in this direction, but they're not really there yet. In the meantime, let’s look at some basic RLM issues.
In my experience as a CM/RM consultant (RQM and RLM) for a tool vendor, I noticed that even we missed this one at least once: there is a difference between what release development believes they are working on and what marketing wants to call it. It should be possible to support different internal and external labels. When marketing decides, just before the release, that 1.1 should really be called 9.0 in order to match your other products, it should be doable. You pay marketing to give you this kind of advice, so don't complain when you have to follow it.
This means, among other things, that you shouldn't be too tied up in using the marketing names for things. You really are better off using those goofy code words that you hear from other companies. Try to pick good ones, though: Avoid cities and planets: they’re boring. Use poisonous fish or carnivorous plants or something equally exciting.
Next comes scheduling. There are shops that never slip their schedules. Believe it. Condumex (Queretero, MX) is one. It’s in the automotive industry and the new model year waits for no-one. On the other hand, there are shops that can't come within three months of a target date. You can surely find an example on your desktop!
Most shops are in the middle and most RLMs are stuck trying to balance conflicting priorities (schedule, product quality, competitors, time-to-market, testing, etc.). This is why every RLM has a project management package installed on their PC, with some Gantt charts printed out hanging from their wall. They need to know who is on the critical path and who can slip. They also need to see what trade-offs are available in terms of schedule versus functionality.
The only real control that an RLM has over development is the contents of a release. Fortunately or unfortunately, the RLM cannot walk through the bullpen with a whip and a drum chanting, "Code, you developers! Code!" Instead, the RLM can negotiate schedule versus release content. "If we drop international language support, can we shave a week off testing and two weeks off development?"
Or, in cases where the contract is signed, the RLM can try to play staffing versus schedule. "If I transfer two guys off the Albatross release, can they help you shorten the test cycle?" Or, in cases where there's no time to get anyone else up to speed, and the contract's already signed, the RLM can drink coffee, sit in his or her office and make small whimpering noises while browsing dice.com for a new job.
In reality, though, RLMs aren't fools. They're as proactive as the development team and sometimes more so. Once an RLM is familiar with the development team, product and situation, you can expect that they'll be staying on top of things like "feature creep" and schedule slippage. They'll also be doing it by trying to manage the contents of the release. To this end, they need to know when dependencies exist between bug fixes and feature enhancements and will need a concrete way to present this to management, development, and the customers.
Finally, there is the matter of release content. This is the classic CM issue, except that it isn’t. When a shop is working several releases in parallel, with schedules changing and resources scarce, the ability to ensure that a bug that was fixed once stays fixed isn’t a pure CM issue anymore. It becomes an RLM issue when upper management decides that providing different critical shipments to two different customers is more important than propagating all the changes between the two. Yes, this is a short-term decision and, yes, it’s likely that a subsequent release will integrate the two. That doesn’t change the fact that these decisions have to be made, however, and that you’ll likely have to clean up after them.
So we’re looking for three capabilities in the RLM space: abstract names, flexible management of features, and effective release content reporting. To a certain extent, the last two are different sides of the same coin but different shops will have different needs, and different tools will give different capabilities. Using RQM Tools in the Software Development Process
The following are some approaches that can help with software development, especially with the RLM aspects, if you have an RQM tool in place.
Integrate your tools
The way to get maximum value from an RQM tool during the development process is to integrate the tool with your existing SCM tools. Many vendors already provide integration packages for this. If your CM tool and your RQM tool don’t have an integration already, write one. Most vendors, and all open source packages, get their tool integration packages initially from customers.
You should be able to link the requirements for a release to the CRs that are implementing those requirements. Your CR package should be able to update the RQM tool when it creates a new CR or when an existing CR changes state. It should also be able to talk to your CM tool, linking the CR to the files that actually change.
Create a release document
Next, recall that one of the key capabilities of an RQM tool is to provide you with different documents which can be linked together. Create a "release plan" or "release specification document" in your RQM tool. This document (or view) will contain exactly the requirements for the new release. This is not the same as adding a release field to the entire product design document and filtering on that, but that can serve as a starting point.
Thus, "Product user requirements for release 1.1" may contain "The product shall be extended to support the Thai language." This spills over into, "Product user requirements" which contains "The product shall be support the following languages: English, Spanish, Japanese, Thai."
Likewise, "Detailed design for product installer release 1.1" may contain, "The installer must ensure that Windows support for Thai language fonts is available when installing Thai version." This spills over into "Detailed design for product installer," which will contain the same new requirement.
In some cases, the text is the same, while in other cases, it may be slightly different. There will surely be a relationship between the entries in the release document and the master product document. What is important, however, is that the RLM has a single set of documents that can be reviewed with marketing, sales, the customer, development, testing, etc. The document can be independently retrieved by anyone with access to the RQM tool, and the document can itself be subject to CM control.
Document your dependencies
Even if you don't create a separate "release plan" document, you should document the dependencies among CRs and requirements at a level which is accessible to the RLM team. This means putting the information into the RQM tool. The easiest way is to create a relationship needs" or requires, which relates the two entries. This allows the RLM team to experiment with the release plan while not constructing an impossible package. If your release cycle is long (four months or longer) you may also want to document your implicit dependencies as well. These dependencies exist because of the order in which your code was written, rather than because of some functional requirement. The idea here is that RLM may have to manage partial releases, or shipments to a single special customer, or propagation of a change from one release to another. These cases can cause some strange release documents to be created.
Summary
What happens if you get all of this set up? Well, you have a RQM tool that is storing your product requirements. The RLM team is working with the development, product, and customer teams to produce a balanced release plan complete with schedule and associated changes. The release plan will be stored in your RQM tool as a separate document group.
The release plan documents will link to your master requirement documents. This can then be used to ensure that the changes have been incorporated into the mainstream product. It can also be used to identify regression test cases, since your test plans can also be linked to your master requirements.
The release plan documents should also be integrated with your CR tool, so that all new CRs are associated with the individual product change that spawned them. (Note: This should be validated both ways. Any "orphan" CRs either should be linked in to a release requirement, or should get closed immediately. Any change requirements without supporting CRs should be reviewed by the RLM team as potential problems.) Your CR system should relate to the files that were changed. This is another source of regression data, as for any file associated with any CR associated with any requirement in your master detailed design you can follow the verifies relationships from the detailed design to the test plan to produce a list of test cases to run.
From the top, the RLM team now has a way to monitor status. They know what the schedule says, and they have access to "drill-down" data all the way to the file level. When a CR goes past the estimated time to complete, the information should be available immediately to the RLM team.
From the bottom, development can work in the same way they are working now, by using the SCM tool and the CR tool they used yesterday. Now when they complete work, though, they get credit for that work automatically in the project plan. No more explanations and no more random visits from RLMs trying to find status.
In short, making the effort to integrate your RQM tool into your development process closes the gap between the development team and the RLM team, including project management and the customer interface. That, in turn, brings your entire team closer together and makes everyone’s life easier.
