I've recently noticed an increasing level of discussion on CM communities discussing software configuration management (SCM) versus hardware configuration management (HCM). Sometimes the discussion is phrased as application lifecycle management (ALM) versus product lifecycle management (PLM), or sometimes as SCM versus CM or SCM versus HCM.
As the discussion goes on, some questions arise. Are the fundamentals the same? Should there be one CM department or one for both hardware and for software? Can we use the same tools for both types of configuration management? Is SCM the same as HCM?
These are not easy questions to answer, but if we want to delve into them in more detail, it’s necessary to understand some fundamental differences between software and hardware.
But first I’d like to make an observation. The fact that there is an increased level of discussion on this topic implies that software and hardware teams are having more interaction with one another. I believe this is due to more and more software creeping into traditional hardware solutions and the fact that people are understanding that you can’t treat software as simply as being “part” of hardware. Additionally, as hardware development becomes cheaper, software further impacts hardware requirements.
I’m sure there are other drivers too, but the key point is that software and hardware teams are synergizing more than they have in the past.
Remember that there are many similarities between hardware and software, but there are certain differences that significantly impact your ability to develop and manage.
For example, hardware is built to last while software is designed to change, although this does not imply that hardware cannot be designed to change. Also, software longevity is important, but you don’t go out and build a smartphone or tablet that will need hardware improvements after the customer buys it. On the other hand, customers might not buy that phone or tablet if they thought they weren’t going to get frequent software updates.
Additionally, hardware costs tend to be production-oriented, while software costs tend to be development oriented. Once the development is completed, the hardware is then moved over into the production phase, where parts and materials have to be purchased or mass produced, then assembled, and finally tested. An efficient process is needed both for inventory management and for production to ensure cost effectiveness of the end product.
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.
So, from a CM perspective there are many differences between SCM and HCM. Consider how we track the problem and it’s resolution. In hardware, you may track the problem against the defective part; in software, you do this against the generic functional category. Your process must allow you to deal with hundreds or thousands of software problems each month. You would likely have difficultly processing that many hardware changes.
Software problems are usually allocated a fixed cost (or fixed cost per phase found), or perhaps a high, normal, or low cost after a quick analysis. Hardware problem fixes have their costs detailed after a thorough analysis. Additionally, unlike hardware, software tools result in the biggest cost of most problems (after problem impact costs) found in reproducing the problem. Fixing is relatively cheap—even delivery.
We could use the same CM tool for problem tracking in both cases. But the processes have to be different. And whereas you may try to attain zero-defect hardware, your goal in software will be to move from 1000’s to 100’s to dozens of problems per million lines of code per month.
I've barely scratched the surface in this article. There are significant differences between hardware and software development that require substantial process differences in order to adhere to the core principles of CM. Just because hardware doesn't do it the same as software or vice versa, does not mean that one or the other is not adhering to CM. Still, there is much to be gained by focusing on the similarities in process and bringing them even closer together.
Hopefully an understanding of the differences will lead to a clearer understanding of the similarities.
