How to Implement CM and Traceability in a Practical Way

Software development can often be a very complex endeavor, so it is no wonder that important details can sometimes get lost in the process. My own work involves implementing configuration management (CM) tools and processes across many technology platforms, including mainframes, Linux/Unix, and Windows. I may be implementing an enterprise application lifecycle management (ALM) solution one day and supporting an open source version control tool the next. It can be difficult to remember all of the details and yet that is precisely what I need to do. The only way to ensure that I don’t lose track of my own changes is to use the tools and processes that I teach developers for my implementation work and thereby ensure traceability and history of everything that I do. I have known lots of very smart developers who made mistakes due to forgetting details that should have been documented and stored for future reference. This article will discuss how to implement CM and traceability in a practical and realistic way.

The most basic form of traceability is establishing baselines to record a specific milestone in time. For example, when you are checking changes into a version control tool, there is always a point in which you believe that all of the changes are complete. To record this baseline you should label or tag the version control repository at this point in time. This is basic version control and essential in order to be able to rebuild a release at a specific point in time (usually when the code was released to QA for testing). But how do you maintain traceability when the code has been deployed and is no longer in the version control solution?

In fact, you need to also maintain baselines in the production runtime area and ensure that you can verify that right code has been deployed. You also must ensure that unauthorized changes have not occurred, either through malicious intent or just an honest mistake. Maintaining a baseline in a runtime environment takes a little more effort than just labeling the source code in a version control repository because you need to actually verify the correct binaries and other runtime dependencies have been deployed and have not been modified without authorization. It is also sometimes necessary that you find the exact version of the source code that was used to build the release that is running in production in order to make a support change, such as an emergency bug fix. Best practices in version control and deployment engineering are very important, but there is also more to traceability than just labeling source code and tracking binaries.

When software is being developed it is important to develop the requirements with enough detail so that the developers are able to understand the exact functionality that needs to be developed. Requirements themselves change frequently and it is essential that you can track version control requirements themselves. In many industries, such as the medical field and other mission-critical systems, there is often a regulatory requirement to ensure that all requirements have been reviewed and were included in the release. If you were developing a life support system, then obviously requirements tracking could be a matter of life or death. Dropping an essential requirement for a high-speed trading firm can also result in serious consequences; it is just not feasible to rely upon testing to ensure that all requirements have been met. As W. Edwards Deming noted many years ago, quality has to be built in from the beginning [1].

There are also times when all requirements cannot be included in the release and choices have to be made, often based upon risk and the return on investment for including a specific feature. This is when it is essential to know who requested the specific requirement and who has the authority to decide on which requirements will be approved and delivered.  

Robust version control solutions allow you to automatically track the sets of changes, often called changesets, to the work items that described and authorized the change. Tracking work items to changesets is known by some authors as task-based development [2]. In task-based development you define the work items up front and then assign them to resources to complete the work.

Work items may be defects, tasks, requirements or for agile enthusiasts, epics and stories. Some tools allow you to specify linkages between work items such as a parent-child relationship. This is very handy when you have a defect come in from the help desk that results in other work items, such as tasks and even test cases, to ensure that the problem does not happen again in the next release.

Traceability helps to maintain these details and also links the work items to the changesets themselves. Establishing traceability does not really take more time, and it does help to organize and implement iterative development. In fact, it is much easier to plan and implement agile Scrum-based development if your version control tool implements task-based development and the resulting traceability.

Traceability can help you and your team manage the entire CM process by organizing and tracking the essential details that must be completed in order to successfully develop the release with all of its essential details and complexities. Picking the rights tools and processes can you implement effective CM and maintain much needed traceability. It can also help you develop software that has better quality while meeting that deadlines that often change themselves!