What Is the Real Difference between Software Configuration Management and Hardware Configuration Management?

Software is quite different. It is incrementally developed, assembled, and tested as functionality matures. Building the software is generally a fully automated process that can be repeated at the touch of a button at virtually no cost. Much of the testing is also automated and can be run on both interim and final products quite efficiently, though often some manual tests are required. But getting the software to the production state can be a very costly process.

Another difference between hardware and software is that hardware changes are typically part-centric, while software changes are usually function centric.

If a piece of hardware doesn’t meet its specification, it (or a particular part of it) has to be corrected. A part may have some new functionality developed as per a request, but that typically means creating a new part, which the design and engineering teams should center on.

Software is different. Whereas the software deliverables may be considered parts, a change in functionality may affect many of these parts, and typically does. Software is designed using files, each containing several pieces of functionality that rely on other software files. Changing a form may involve data schema changes, GUI layout changes, interaction menu and gesture changes, message changes, and a whole host of other things. These are typically found in separate files scattered throughout the design.

Software also tends to be more complex than hardware, at least from a design perspective. There are fewer standard parts, the interfaces between functional “parts” are more complex, there may be tens of thousands of files each with hundreds or lines of code implementing dozens of functions, and there are few restrictions on how the programming may proceed.

Hardware has a simpler hierarchical assembly with well-defined interfaces, using standard parts wherever possible. Software was once limited by memory, but is no more.

As a result, software “engineers” tend to give too little focus to creating compact, well-engineered software, and instead focus on just meeting the functional specs. It is rare to find a good software developer that claims there is a right way and a wrong way to do this or that.

Whereas this may be true of some hardware developers as well, they have to live with the results of their design, which could range from a product using too much power or it could be too heavy to launch. Software, on the other hand, uses little power, is light, and fits anywhere.

Let’s stop there. These are a few of the more significant differences between software and hardware, and they affect the process, including the CM process.

There are many artifacts that are common to both the HCM and SCM process. These include: Requirements, test cases design documents, customer requests, user documentation, problem reports, engineering activities and requests, waivers and deviations, item hierarchies, production/build, impact analysis, change packages/ECNs, test results, and as-designed and as-built baselines. And the list goes on. These artifacts are quite similar in both disciplines, but also have many differences.

Pick any of these artifacts and there are very significant differences in the processes surrounding them. Let’s focus one of them just to get the point across.

Regarding problem points, the key here is to be able to reproduce a problem based on the problem report itself. Software problem reports are virtually always functional in nature; the feature doesn’t work the way it should. This is largely true for hardware as well, but it’s often that the feature is replaced with specification. For example, a display may have more bad pixels per unit than specified.

The first thing to notice is that the hardware problems are generally about a part; they’re part-centric. Yes, sometime they’re expressed functionally, but a quick diagnosis can lead you to a defective part. For software, the problems are almost always functional and the diagnosis can lead you to anything from finding a typo in the software, discovering a problem in the design, stumbling on a logic issue, or misunderstanding the interface semantics. There are numerous ways to go about fixing these problems, and so there is no defective part, just a defective function.

When dealing with a problem in hardware, you might receive a bunch of hardware problem reports and the production line might be stopped. The product might even be cancelled or withdrawn from market. When you get a bunch of software problem reports like this, you might ask yourself how fast can these reports be repaired and delivered. It is quite normal to have thousands of problem reports for a software product that is in production. However, if you receive dozens of hardware reports, your product might be all but finished.