There is a dichotomy in software configuration management. On one side, individual developers and testers need the flexibility necessary to do creative work, to modify code and tests to try out what-if scenarios, and to make mistakes, learn from them and evolve better software solutions. On the other side, teams need stability to allow code and tests to be shared with confidence, to create builds and perform testing in a consistent environment, and to ship high-quality products with confidence. This requires an intricate balance to be maintained.
Too much flexibility can result in problems including, unauthorized and/or unwanted changes, the inability to integrate software components, uncertainty about what needs to be tested and working programs that suddenly stop working. On the other hand, enforcing too much stability can result in costly bureaucratic overhead, delays in delivery, and may even require developers and testers to ignore the process in order to get their work done.
RISK BASED SOFTWARE CONFIGURATION
One mechanism for achieving this balance is to implement risk-based software configuration control for our projects and products. Configuration control provides the mechanisms for requesting, tracking and controlling changes to software work products after they have been identified and acquired (that is, after they have been baselined and placed under control).
HOW MUCH STABILITY IS REQUIRED?
So how much flexibility can we afford when it comes to controlling change to our software products, tests and components? How much stability do we need? The answer to this, like many questions in software development, depends on risk. As illustrated with the examples in Figure 1, there are many risk indicators that need to be considered when determining the amount of necessary configuration control. For example, lower risk projects with small teams that communicate constantly while implementing small increments of functionality that are built and tested frequently can safely select a more flexible configuration control philosophy. Agile software development s are typically an example of this type of project. Higher risk projects (or programs), with larger, geographically dispersed teams that are implementing large software systems following a more traditional life cycle, will typically require more stability and therefore more rigorous configuration control techniques. Projects/programs in a regulated environment or with requirements for high levels of safety or security will also typically require more stability.
But the choice isn’t really between complete flexibility (anyone can change anything at any time) and complete stability (everything is locked down so that change only happens through extremely rigorous control processes). As the software product is being created, reviewed, tested and finally released, components of that product can move through a continuum from complete flexibility, through various levels of more rigorous control, to stability at shipment to the end-users. Decisions about when and how to implement those levels of control are part of risk-based configuration control.
LEVEL OF CONTROL
It should be noted that few projects match one extreme or the other on all of the risk factors in Figure 1. The level of risk for each project/program/product should be analyzed to determine the level of control necessary at any point in time during development and test to strike the appropriate level of balance between flexibility and stability for that project/program/product. This risk-based analysis can then be utilized to make decisions about the types and levels of control, acquisition points, and number of levels of control authority that are appropriate for each software artifact produced by that project/program/ product. These choices are communicated to the team and/or documented as part of that project/program/product’s software configuration management plans.
In part 2 of this article, we will discuss making risk-based decision about the types and levels of control needed for each identified configuration item.
Bio:
Linda Westfall is the president of Westfall Team, Inc. which provides software engineering, quality, and project management training and consulting services. She has more than 35 years of experience in real time software engineering, quality, project management and metrics.
Linda is the author of The Certified Software Quality Engineer Handbook from ASQ Quality Press. She is a past chair of the ASQ Software Division and has served as the Division’s Program Chair, Certification Chair and Marketing Chair, and on the ASQ National Certification Board. Linda is an ASQ Fellow and has a PE in Software Engineering from the state of Texas. Linda is also a Grand Master of the Pyrotechnic Guild International.