Choosing a Software Configuration System Part 3

This is the last in a series of three blog posts exploring characteristics of development projects to consider when choosing a Software Configuration Management system. 
 
Process Automation and Enforcement 
Most software projects have a defined process. Some are lightweight and may just require that code reviews be done before a significant change is delivered to the project. Others are extensive and with detailed traceability requirements, limits on what is allowed in different phases of the project, strict rules based on security requirements, etc. 
 

Teams can follow process checklists to manually ensure proper procedures are followed but this can be tedious and error prone. The degree to which the process can be automated and enforced by the tools involved can greatly increase the ease of adhering to the process and can avoid costly mistakes, especially if the process is essential to meeting regulatory requirements. 
 
Security 
Different software projects can have dramatically different security requirements. Open source projects are open to all but still need to limit who can deliver a change to a stream that will be used to build a release. A commercial product might have a patented algorithm or a critical encryption implementation that should only be accessible the subset of the team responsible for it and the build and release team. It may be necessary to encrypt data traveling over a network connection. It may be important to restrict who has access to data that was copied out of the SCM repository to a client disk. The ability for an SCM system to meet and enforce the specific security requirements of a project is usually a non-negotiable prerequisite. 
 
Classified Development 
Many military and government projects have stringent requirements that span security, process enforcement, and traceability. They are often developed on isolated networks. They may require smart-card based authentication. 
 
Some classified projects are layered on a non-classified product or use a non-classified project as a base that can be modified. This is a classic parallel development pattern but introduces significant challenges. How do you ensure that the classified code never leaks into the non-classified project contexts? How do you meet the last requirement but also support merging changes from the non-classified projects into the classified contexts? The degree to which the SCM tool provides solutions to these (and many more) challenges can greatly impact the cost of development and level of confidence that the project requirements are met. 

Subcontracting 
Many projects involve contracting at least portions of the project to an external organization. The contractors may work on-site or off-site. There are often additional security requirements that must be managed. Mechanisms to automate and enforce the development process often increase in importance because the contractors frequently function in relatively isolated environments and may unwittingly bypass important rules if not enforced by the SCM system. 
 
Scalability 
The size of the software development team and the size of the software code base affect the load placed on the SCM system. A project with hundreds or thousands of developers or with hundreds or thousands of components with frequent builds occurring can place a tremendous load on the system. It’s important not only to understand the current size of a project but also to predict what it is likely to look like as it evolves over the years. Choosing an SCM system that is flexible and powerful enough to scale to the estimated needs of at least the next few years can avoid having to risk changing an important part of the development team’s infrastructure at some inconvenient point in the future, which can be a very disruptive undertaking. 
 
“SCM Strata” 
As is evident from the topics above, there are a wide range of reasons why an SCM system is highly valuable or essential for software projects. Each project must be evaluated to determine its key characteristics and the requirements on the tools used to implement the project. Choosing an overly complex tool can introduce unnecessary cost. Choosing an inadequate tool can drive costs higher, introduce a painful migration to a better suited tool at some point in the project, or even lead to project failure.  
 
SCM systems vary widely in their capabilities. One can think of the various tools as occupying different “strata.” Basic tools are in the lowest stratum. The most sophisticated tools are in the highest stratum (but can usually meet the needs of lower strata). Many tools exist in the middle strata. A project’s characteristics and requirements will determine the stratum that is most appropriate. The more characteristics discussed in this chapter that a project would benefit from, the higher that places the project. The more stringent the requirements on the project, the higher that drives it in the strata, too. Make sure to choose an appropriate SCM system for your needs.