Finding the right SCM tool for your organization is not that much different than finding the right car for yourself. If you complete a project of researching products thoroughly, you should not be disappointed with your purchase long after the sale is completed. Yet, not every organization approaches the selection of an SCM tool as a project that requires resources, planning, research, and hands-on investigation.

Approaching the Selection of an SCM Tool as a Project

You could select an SCM tool by asking others, “What are the top tools available today?” Experienced SCM tool users will probably answer, “It depends.” This is because the choice of an SCM tool depends largely on your needs and expected use. It is difficult for others to make this choice if they are not intimately familiar with your software development environment.

The way you develop software now, or plan to develop software in the future, greatly affects your choice of an SCM tool. Each SCM tool employs an underlying model. Even if a tool vendor (or tool enthusiast) tells you otherwise, no SCM tool is completely detached from an operating model.

You need to approach SCM tool selection as a project to understand both your software development process and the underlying model used by the SCM tool. You can make an informed selection when you understand how candidate SCM tools operate in the context of your software development process.

Initiating the Project

The first step in an SCM tool selection project is to identify stakeholders and convince them of the need for the project. Stakeholders are those who will use the SCM tool and those who will authorize the purchase of the tool. Stakeholders include technical staff and managers, especially those who provide technical and project leadership.

To gain support for the project, you need to argue that the cost of an SCM tool is not only the purchase price. Since an SCM tool needs to work within the context of your organization’s software development process, there is a cost associated with using the SCM tool to develop software. (There is also a cost associated with performing SCM without the use of a tool.) The only way to make an informed purchase, that recognizes both the purchase price and operating cost of an SCM tool, is to establish a project to identify, research, and evaluate candidate tools.

Experienced technical and project leaders should understand and appreciate this argument. They should realize that any tool that is integral to the organization’s software development process needs to work as part of that process. Additionally, they should recognize that finding an SCM tool that works with the software development process requires resources, planning, research, and hands-on investigation that are only accomplished as part of an appropriately funded project.

Staffing the Project

To be successful, the SCM tool selection project needs to be staffed with the right people. The right people are those who have strong technical and interpersonal skills. Specifically, project members should understand and appreciate team software development from the perspective of

• gathering and specifying requirements,
• planning releases,
• designing and coding software systems,
• branching and merging codelines,
• building and deploying software systems, and
• testing software systems.

While not every member of the SCM tool selection project needs to have experience in each area, the experience across the team should include these areas.

In additional to technical skills, the team members need the appropriate people skills. Strong people skills are absolutely essential since an SCM tool selection effort involves working with various members of the software development organization, including developers, testers, and project managers. Each discipline that comprises the software development organization has specific needs to be met by an SCM tool. Members of the SCM tool selection team must take into account these needs when evaluating candidate tools.

Even after careful evaluation, it is unlikely that one SCM tool will be viewed as providing the best solution for every need. For this reason, members of the SCM tool evaluation team must be able to build consensus across the software development organization.

Diagram the Software Development Process to Identify Requirements

While the ultimate goal of an SCM tool selection project is to select and adopt the SCM tool, the first milestone for the project team is to determine the requirements for the tool. This is no easy task because the SCM tool affects virtually every member of the software development organization.

A practical approach for gathering requirements is to start by documenting the organization’s software development process. Interview members of the software development organization who comprise different technical disciplines. Ideally, you should talk to project managers, analysts, software designers, software developers, testers, release managers, and configuration managers. Even if the organization has an established software development process, staff from different disciplines will view the process from different perspectives.

Document the software development process using inputs from the cross section of the organization. You may find it useful to diagram your process. A diagram will delineate the different phases in your process, as well as illustrate the transition from one phase to another. The diagram will also show if your software development process follows a waterfall approach or an iterative approach.

Using the diagram of your software development process, ask those who you interview to describe what they require to support each phase of the process. The automation desired or required to support each phase of your software development process will help you identify the features you need in an SCM tool.

Keep in mind that today’s SCM tools offer far more than version control. They support parallel development with facilities for branching and merging codelines. Additionally, SCM tools provide defect tracking and workflow automation (i.e., change management) either as a built-in capability or through an integration with another product. Some SCM tools (or suites of integrated tools) also support requirements management.

Products whose capabilities encompass version control, change management, and requirements management are now known as application lifecycle management (ALM) tools. The name signifies the ability of these tools (or tool suites) to manage key aspects of the software development lifecycle.

Identify Required High-Level Capabilities

Based on the initial requirements that you defined as a result of diagramming your software development process, you should have an idea of the top two or three key features that will narrow your search. Rather than developing a long list of detailed features (that many tools will offer) focus on key high-level capabilities. Examples of key high-level capabilities include the following:

• flexible parallel development model
• integrated defect tracking and change management
• integrated requirements management
• lightweight administration
• management of configuration items other than source code files
• support for geographically distributed development

Research Products

After identifying the top two or three high-level capabilities that you need in an SCM or ALM tool, research products to find those that excel in these areas. For example, if your development takes place on different platforms focus on tools that provide strong cross-platform support. If parallel development is a key aspect of your software development process focus on tools that offer a flexible parallel development model. If integrated change management is at the top of your list narrow your search to products that combine version control and change management in one tool. If comprehensive traceability from requirements to code is important narrow your search to tools that can provide this degree of traceability.

Where do you begin your research? CM Crossroads is a good place to start. Specifically, start by reviewing the product reviews forum and the discussion forums devoted to CM products. The product reviews forum contains concise reviews of CM products that are written by CM practitioners who evaluated the products. The discussion forums devoted to CM products cover the operational issues of many popular CM tools.

If you are shopping for a commercial tool, vendor web sites can provide you with detailed information about products. You may even be able to download an evaluation copy of the tool from the vendor’s web site.

Third-party reviews of products can be helpful if they are current. Since the SCM and ALM market evolves rapidly, product reviews that are more than a year old are likely to be somewhat dated.

Evaluating Candidate Tools

As you narrow your tool search, develop scenarios that you will use to evaluate candidate tools. These scenarios should be based on the top two or three high-level capabilities that you identified. For example, if the tool must support geographically distributed development create a scenario that involves installing and using the tool at different locations. If you need to manage requirements and source code files in the same space develop a scenario that involves creating and modifying both requirements and the source code files that implement them.

The most useful tool evaluation scenarios are those that are based on your software development process. Since you will be using the SCM or ALM tool to facilitate your software model, it is absolutely essential that you determine how well the tool will support your model. Like test driving a car on the road, you must test drive a candidate SCM or ALM tool in the environment in which it will be used.

After researching candidate tools, work with vendors to obtain evaluation copies. Vendors will provide you with both the tool and the support that you need to install and evaluate the tool. Rather than judging the effectiveness of a tool by watching a demonstration of your evaluation scenario, set up and use the tool in your environment.

Even if you start with a clear and concise set of requirements, you may refine the requirements as you try out candidate tools. This is to be expected. Once you see how tools perform under realistic conditions you will have a better idea of what tool features are most important to your software development process.

Selecting the Tool

You could select the SCM or ALM tool by creating an extensive matrix that ranks tools by the features they offer. You may need to create this type of matrix to support the tool recommended by the project team. However, the best way to select the tool that is most appropriate for your organization is to review the outcome of the evaluation scenarios.

Like forming an impression of a car from a test drive, what was your impression of each tool after evaluating it in your environment? What aspects of the evaluation surprised you? In what areas of the evaluation scenarios did the tool exceed your expectations? In what areas did the tool fall short of your expectations? By answering these questions, your team will have a good feel for the tool you want to select.

Conclusion

Selecting an SCM or ALM tool is no easy task. It requires a project that is staffed with a cross section of the software development organization. The members of the tool evaluation team should begin by documenting requirements. High-level requirements can be gleaned from diagramming the organization’s software development process. The top two or three high-level capabilities required can be used to narrow the tool search. Once the team identifies candidate tools, the most effective way to evaluate them is thorough a test drive. The test drive for an SCM or ALM tool is to exercise a scenario based on how the organization develops software. The results of exercising these scenarios will give the members of the tool evaluation team a picture of how each candidate tool will perform under realistic project conditions.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment