Software Configuration Management
Configuration Management and Change Control
One of the many challenges I have encountered in my career is one which plagues many companies involved in software development. From controlling simple edits, tracking changes, building and packaging one or more products, to the complex configuration management tasks involved in deployment of the Space Shuttle, all development efforts require some level of change control.
Even if you only provide bug fixes and enhancements to a simple application, you should know the importance of keeping a backup of your last working copy, for recovery purposes. This is the simplest form of change control.
Here, I offer a brief overview of the fundamentals behind configuration management, describe some of the philosophy, my views, and offer my experience in CM as a consultant.
Configuration Management Consulting
I have decided to share my experience and knowledge of configuration management, mainly because so few organizations (except large corporations, who know better) follow any structured CM practice. Not only are deliverables constantly in jeopardy, or corrupted due to failed or incorrect builds, but the development staff is in constant states of frustration. These small to medium organizations either have never heard of CM, or think that their application, staff or environment (way of doing business) doesn't need it. Anyone who has worked within a good, CM-controlled environment will tell you that the benefits are immeasurable compared to the haphazard, shoot-from-the-hip ways that undisciplined companies develop their software. In fact, many cannot effectively package, release or support their software, and even the initial development effort is hindered and compromised by lack of control and inadequate or non-existent processes and procedures.
If you or your organization would like to learn more about Software Configuration Management (SCM), and how I may help your organization toward a practical implementation of SCM, please contact me. If I am not available on a full time basis, I may certainly provide part-time consulting, or even an on-site seminar for your group, and recommendations for processes, tools, software and implementation of procedures to help you get your development and support under control. Contact me for details and availability.
Configuration Management Background
I am a senior Information Technology individual with a strong background in UNIX and Software Configuration Management, process improvement, task automation, PC, Windows, HTML and graphic design. I have enjoyed small company environments, as well as large corporations in the IT field for 23 years. I maintain a copy of my resume here, should you or anyone you know have an interest.
You can benefit from my 12 years of experience in SCM. As Manager of Configuration Management at one corporation, I provided the design, authorship, implementation and support of an automated software configuration management change/build control system for a multi-platform UNIX development environment. By defining a standards-based CM environment, the company was able to develop and support new and previous versions of the product, and CM enabled porting the product to several UNIX platforms with minimal effort. This SCM system was compliant with Software Engineering Institute's Capability Maturity Model (level 3), and included many administrative tools, and automated product release and installation procedures.
Software Engineering Institute
The Software Engineering Institute (SEI) is an organization known to software industry professionals. Very briefly, SEI defines and provides standards and guidelines to help software organizations achieve capability maturity. By striving to achieve compliance with various levels of capability, establishing processes and procedures, an organization is not only better able to meet the demands of development and support of their product, but gains the confidence of the marketplace. In fact, more and more contracts are won (or lost) based on a company's adherence to standards, such as IEEE and ISO-9000. Even in a small organization which isn't concerned with winning large contracts with say, the government, defining and adhering to standards and procedures can make or break a project's success.
Standards and Procedures
Standards define the way a thing must be done. Procedures insure that the standards are followed. Processes are the methods, that when used, follow the defined procedures, insuring the expected result. Even a family's household has standards (rules). How you drive your car to and from work each day follows certain procedures. These procedures are repeatable, and always produce the same result. It's amazing but true, that too many software organizations fail to define standards, have no repeatable processes, and fail more often than succeed because of it. Without configuration management, the Space Shuttle would have never succeeded. And, because standards were not adhered to, the Challenger shuttle exploded.
By defining standards and developing processes and procedures, you always know how a thing works. By refining and correcting them, you know it always works right. When your processes are right, you have repeatability, and automation of processes is possible, saving many hours of manual tasks, and your team's project has means for recovery.
Automation and Repeatability
In any organization developing software, where developers and support personnel share files, the potential for disaster exists. Even if one or few are developing or modifying dependent files, and a standards-based, repeatable process isn't in place, you have no guarantee that your product (program or project) will complete as planned. Someone will forget something, or change something that someone else (or another file) depended upon. You can count on it.
By providing a repeatable process, and automating it in such a way that everyone will use it, you guarantee that changes are known, traceable, can be undone, and shared. You will also inherit many valuable capabilities, and with the right tools, are able to provide parallel efforts, such as bug fixes and enhancements to your current product, while proceeding with new development on the next release.
Environment - Adaptability - Tools
CM should be tailored to an organizations needs. As well, it should be adaptable to the organizations growth or changing needs. Choosing the right tools, and designing the adaptive processes up front will help your group in the short and long term. You should start by identifying your needs, and laying the groundwork for the definition of standards and processes. Many of the basic processes involved in basic change control are already fairly standardized. Your specific processes and standards need to be defined. Then, choose the right tool to support them. Build your procedures and processes around the automated use of your tool(s). Remember that your product direction and development methods will affect your choice of tools, and the methods you need to provide their use.
"The first rule of intelligent tinkering
is to save all the pieces."
-Aldo Leopold
"...And remember where you put them."
-Roosl
Note: If you are viewing this page stand-alone, and would like to access all of Roosl's Graphic Design, please Go Home!