Does your software development organization have a well defined and implemented configuration management (CM) process? For many organizations, they equate the CM process with having a revision control tool in place. While versioning is a necessary prerequisite to implementing a configuration management process, it is just a small part of the overall process.
Configuration management is a key systems and software engineering process for establishing and maintaining the consistency of a product’s as-built functional, performance, and physical attributes with its requirements, design, and operational information throughout the product’s lifecycle. Configuration management is the basis for many other key processes in the software development lifecycle such as; change management, defect management, and release management. It also enables the key practices of; traceability, auditing, and separation of roles within the product lifecycle. As such, it encompasses much more than just versioning of the software source code.
At its core, configuration management focuses on four practices: identification, change control, status accounting, and auditing. Identification is about defining what are the configuration items under the control of the CM process, the relationships between configuration items and providing unique, immutable identifiers for those configuration items. Providing well-defined criteria for what constitutes a configuration item — and how configuration items can be combined together to produce other configuration items — forms the basis for an organization’s variant management strategy.
For product development organizations such as automotive suppliers or medical device companies, it is not uncommon to have product families with over one hundred variants. In such situations, it is vital that the CM process be aligned with the variant management strategy. The CM process for an organization with a single or few distinct software products — and one or two versions that require active support — is very different from that with a large variant family and many versions that have to be supported.
All the practices of the CM process are required in order to have effective change, release and quality management processes, but identification and CM change control are essential; if you don’t have a handle on what it is you are planning to change, or are testing, then it is impossible to ensure that change requests are properly implemented, or that what was released was of suitable quality. Traceability, by definition, requires that the artifacts linked by the trace relationships be clearly identified and their state properly controlled.
The status accounting practice of the CM process drives the execution of the software development lifecycle, especially release management. Key metrics such as the number of outstanding defects — or the state of approved change requests — are based on the status accounting abilities of the CM process. The status accounting practice is also what provides insight into the consistency and completeness of the overall software product configuration. In modern development shops, implementing highly iterative and incremental development approaches such as Scrum or XP, the CM process is relied on even more heavily, as the rate of change is higher than in more traditional, plan-driven approaches.
In order to improve quality, time to market, and developer productivity, the software development lifecycle processes should be automated as much as possible, and this applies in particular to a key supporting process such as the configuration management process. That said, do not fall into the trap of being forced to adapt your software development methodology and processes to the constraints of a given tool. Instead, as part of the up-front planning for your software development project, define the objectives for the CM process as well as the desired workflows and environment that it must accommodate. With those criteria in place, choose the tool or tools best suited to achieve your goals.
Defining the capabilities and workflows — and implementing tools to automate the practices that implement them — is just part of the job. Documentation and training is important to ensure that the CM process is implemented correctly and consistently, and that tools are leveraged to best effect.
If you work in a regulated industry, such as medical devices, aerospace, or automotive, not only is documentation and training mandated, typically the tools used to implement the CM process must be qualified. FDA regulations 21 CFR Parts 820 and 11 mandate computer system validation of software tools involved in the development of medical devices or pharmaceuticals.
In the commercial aerospace industry, RTCA standard DO-178C defines guidelines for software assurance of airborne software, and supplementary standard DO-330 specifically addresses software development tool qualification. In the automotive industry, the ISO 26262 standard addresses functional safety for road vehicles, with section 8-11 addressing requirements for software tool qualification.
In all of the industries cited here, qualification must be done in the context of the software being developed, the SDLC being employed, and the context of the system the software will be deployed into — in particular the potential risk or safety concerns that software entails.
Finally, your organization must ensure the CM process is properly implemented and continues to deliver on its objectives. That means ensuring the tool(s) are installed and implemented correctly, that the desired workflows are being followed within those tools, that security, reliability and disaster recovery considerations have been dealt with, and the appropriate reporting mechanisms are in place to support the audit and status accounting practices.
In regulated industries, the auditors need clear, objective evidence that the right artifacts were developed using accepted processes and practices; the auditors do not have the time or the inclination to learn the details of your organization’s infrastructure to obtain that evidence. Whether it is a CDRH auditor in the case of medical devices, or an FAA Designated Engineering Representative in the case of avionics software, the configuration management system must be able to deliver the objective evidence they need, when they ask for it.
Just implementing a revision control tool may be adequate for individual developers working on stand-alone projects, or very small teams working on unregulated software deliverables, but most software development organizations require a proper configuration management process. Implementing such a process requires an understanding of what practices and capabilities are required to meet the needs of your industry, what tools are available to automate and streamline the implementation of the process, and what infrastructure and procedures are required to ensure the reliable, ongoing implementation of the CM process.