- SCM 300 (See Figure 5). Works with development/writing teams at the CI integration level.
- Development Project Manager* – Responsible for approval in SCM300 (See Figure 5) as well as responsible for the makeup (how the Application is organized) of the Application. This role and the Technical Team Manager may be the same person in a simple documentation situation.
*Note: The roles I have created for this Design Pattern and those that follow are for illustrative purposes only. Your development environment and SCM system/tool may call for other/different roles.
The topology of this Design Pattern is based on the roles defined above and seen in Figure 1.
Process Flow Diagram
Figure 2 shows an overview of how this Design Pattern is going to work. I have also indicated some of the external inputs that might drive a change control which is the start of the SCM process. It may require several iterations to get it right but the flow chart must show where all the forms are going to be used. Think of it as a static map with the forms as the process enablers. This first pattern is simple for ease of use and is possibly a good start to enabling SCM in a small project or even a large one prior to more complex patterns. Additional complexity will be added as we move through the Design Patterns that follow.
With the hardware topology, roles, and process flow defined lets go through the paper forms I have indicated when you start designing a SCM system.
Form SCM100: Change Control
The purpose of form SCM100 shown in Figure 3 is to document change requests, enhancements, or bug fixes related to an Application project or project documentation. This form contains information that is useful to the decision makers who will either approve or reject the change. If the change request is approved it will also be helpful to the developer who will have to make the changes. The Technical Team Manager is responsible for filling out the form. Both the Technical Team Manager and the Application Project Manager must approve the form before it is assigned to a developer to perform the work.
Form SCM200: Check-out / Check-in Log
The purpose of form SCM200 shown in Figure 4 is to record all the CIs that are checked-in and checked-out of the server to implement a change or to create new CIs. It also acts as a simple version control tool and provides sign-off by the CCB. You would have one of these forms for each change request so that a development team can refer back to them if an audit trail is needed.
Form SCM300: Change Control Board
A Change Control Board (CCB) is a group responsible for evaluating and then approving or rejecting proposed changes to existing CIs or new CIs that will be integrated back into the server. The purpose of form SCM300 shown in Figure 5 is to support the CCB process by providing all the necessary information to the CCB members. The SCM300 form is similar to form SCM100 but now it evaluates the return of changed/new CIs to the server. I have also included a reference to the change/new CIs from form SCM200.
So this paper-based SCM system is now complete and ready to try out. As you work through the process of using these forms and seeing where things work and where there are problems, you should document these issues and go back and review the roles and processes. It may take several tries to work out the bugs but it is time well