and vice versa.
15 Multiple File Retrieval: The CM tool supports retrieval of multiple files at a time. This includes the ability to retrieve either an entire product source tree, or at least entire source directories, in a single operation. Such retrieval should be possible for any baseline or for any "view" of the CM repository. Retrieval of files of a change package is also a frequently required operation. Restriction based on file type, or based on wild cards, is another important aspect of this requirement.
16 Scripting and Basic Configuration Capability: A 2G CM tool has significantly more functionality than a 1G tool. Because of this, more customization is required by each project. So 2G CM tools need some scripting and other customization capabilities to enable a project to support specific usage, data and process requierments, specific to each project. As well, scripting is often required to support implementation of triggers and integration of tools.
17 Basic Rules/Triggers Capability, including email: A 2G CM tool allows extension of process definition through rules and triggers. These are often used to integrate process across tools or to signal information to other users via email.
18 State-based Promotion Model: A 2G CM tool defines states or promotion levels for change packages (possibly as file states, but ideally not), for problem reports, and for features/tasks. These can be customized to the requirements of the project and the model is generally expressed through a state/transition diagram or equivalent. This allows state-based tracking of product/project status.
19 Basic Repository Data Security: Access to the CM repository must be controlled. Both access to data and to the ability to change the data needs to be controlled.
20 Graphical User Interface: The command line interface (CLI), while still important, gives way, in normal usage, to a GUI-based interface in 2G tools. The GUI needs to be sufficiently useful and intuitive that there is a tendency to migrate to it from the CLI interface. Ideally, a substantial amount of GUI customization can be done with a reasonable amount of effort.
21 Context View Capability: The 2G CM tool allows the user to specify a "context" through which to view files (and perhaps other information). This eliminates the need to specify specific revisions of files within the tool. Instead, the CM tool uses the context to determine which revision is implied. Context can be static (e.g. a baseline) or dynamic (e.g. the latest checked-in version for release 2).
22 Basic Reporting Capabilities: Reporting capabilities extend beyond basic file history and baseline definitions, to cover change summaries, problem and feature reports and requirements informations. Better tools will permit interactive queries with drill down capabilities. Ideally, most reports do not require an "expert" to specify or run the report.
23 Graphical Differencing/Merge Tools: Difference and merge tools supported with the 2G CM tool are more intuitive to read and are interactive, in the case of merge tools. Typically, color is used to highlight differences, and menus/mouse clicks are used to navigate differences and to support merge operations.
24 Remote Access Capabilities: Support for accessing and using the CM repository from outside its resident internet domain is provided for by 2G tools. This requirement can usually be fulfilled outside of the CM tool proper (e.g. VPN).
25 Comprehensive On-line Help: On-line help is required for all CM tools, and with the additional capabilities, even more so. Ideally, on-line help can be easily customized to reflect tool customizations made by the project.
26 Graphical Navigation of Source Tree and History: The GUI-based interface must support navigation of the source code tree (in a
About the author
Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com
