Does Software Configuration Management Follow CM's Core Processes?
Both hardware configuration management (HCM) and software configuration management (SCM) are variants of CM, which has five basic principles: CM planning and management, configuration identification, configuration control, configuration status accounting, and configuration verification and auditing.
In a hardware development shop, CM's core principles are front and center in the following ways: Parts need to be uniquely identified; changes need to be heavily scrutinized; baselines are carefully constructed to reflect the requirements, design and as-built configurations through the product's evolution and production; and audits are performed to ensure compliance with both functional and non-functional requirements.
So what about the software world? In his TechWell story, “The Differing Points of View About CM,” Joe Townsend states, "When one mentions the...core process of CM, it is hard to explain those concepts to a new person. The main reason is that the...core processes are no longer ‘done’ by CM folks on the software side.”
Joe goes on to ask us whether or not SCM needs to move beyond CM's basic core processes.
I’ve been involved in hardware CM, but, for the most part, my background is in software CM. While it is hard to explain CM's core concepts to a software person, a decent software shop follows these principles. However, the big difference in software shops and hardware shops is the level of automation in which the tools are responsible for ensuring the core processes reach “done.”
Software is designed to change; hardware is designed to last. So, software change is far more frequent than hardware change. !f you tell someone that his hardware will be changed multiple times after delivery, I bet you’ll lose a customer!
Remember that both the volume of software change components (i.e., files) makes automation mandatory. While a developer may want to name his files, any decent SCM tool will uniquely and automatically identify those files, distinguishing between your “makefile” and my “makefile.”
Similarly, the process for change is streamlined and largely occurs as a result of the normal development procedure like the following: Check-out for an approved reason, modify, test, check-in, peer review, demonstrate, build, integrate, verify, and release.
Because software changes are much less costly than hardware changes, you should focus more on ensuring the resulting change is solid and less on whether it is cost effective.
You might be asking yourself "What about impact analysis?" Software developers generally understand impact and how to minimize it or otherwise avoid it. Additionally, configurations are automatically generated by the SCM tool as changes are verified and promoted.
For a further discussion on the SCM process, this LinkedIn post titled “ What is CM Architecture?” has some good responses.
