Planning - SCM activities must be planned for early in the lifecycle* of a software project. This includes identifying Configuration Items** (CIs), requirements for your SCM system, and personnel to fill SCM roles.
*Note: A “lifecycle” refers to all the stages of an Application as it progresses from inception to shutdown. I will be dealing with a subset of the term going from change control to production.
**Note: Configuration Item is an abstract term used to represent the domain of all objects that are known to a SCM system. The primary method by which generic objects become CIs is the Check-in function. CIs could include, but are not limited to, documents, code, makefiles, graphics, etc. Be careful not to confuse other objects that may exist on a computer system but are not known to the SCM system.
Process - You must create and understand the SCM processes that will drive your SCM system before you can automate their functions.
Most software applications we see today are multi-platform, multi-language, and operate across multiple physical environments – all of which have software that needs to be created, integrated, tested, built, released and managed. Simple software applications can sometimes get by with simple SCM systems, but with government regulations such as Sarbanes - Oxley, and requirements from other government agencies, as well as your customers, SCM systems tend to require more robust configuration tracking and reporting, even in the simplest of software applications.
The focus of this article is on the use of Software Configuration Management (SCM) and how different types of software design, development, and implementation has driven the functionality and features of the SCM tools we see today. I will discuss the processes and procedures of various design patterns starting from a simple paper-based design pattern, an automated version control design pattern, moving to more complex multi-State Design Patterns, the hotly-contested parallel development Design Pattern, and finishing with a web-based Design Pattern. By using the Design Pattern analog I hope you will come away with a greater understanding of how SCM works in various situations and what types of SCM functions are needed for those situations.
This first Design Pattern is based on the use of SCM Forms. It is a very simple Design Pattern that could be used in the following situations:
- Initial modeling of a SCM system that uses paper forms to drive the processes
- Simple document version control with no computerized SCM system
- Simple version control for a simple Application with no computerized SCM system
We will assume that we have a server that houses the CIs that make up an Application or Documentation set. There will be three groups of personnel who have access to this server and will be involved with the execution of this SCM process (See Figure 2 for a flow chart of the forms mentioned in the following section):
- Developers* – Responsible for getting approval to make a change to the Application (SCM100, See Figure 3) creating CIs, changing CIs, checking–in CIs to the Server, checking-out of CIs from the Server, filling out Form SCM200 ((See Figure 4) check-out, check-in Log) and getting approval from the Change Control Board (SCM300) on check-in (See Figure 5). For this Design Pattern we will assume that a developer could be a writer if the function of the Design Pattern is to control documents.
- Technical Team Manager* – Responsible for filling out Form SCM100 ((See Figure 3) Change Control), SCM300 (See Figure 5), approval in SCM100 (See Figure 3), approval of check-in CIs on Form SCM200 (See Figure 4), and approval in