More white papers:

• Going Beyond CM - A CM+ Overview
• Integrated Problem Tracking
• Change Package-based versus Task-based Change Control
• Taking the Complexity Out of Release Management (.pdf)

Find out more ...

• CM+ provides an integrated suite of Enterprise SCM applications.

Neuma White Paper:

Going Beyond CM - A CM+ Overview

Neuma's CM+ is an Integrated Project Support Environment (IPSE) which focuses on the Software Development Process and Configuration Management

CM+ is used to support the management aspects of the software development life-cycle process. Neuma is configured for out-of-the-box use for most CM applications. It can be easily configured to support the user's own specialized processes.

The CM+ configuration includes version control, change management, build and release management, configuration management and problem and activity tracking. An API is also available for accessing repository data from a C programming interface.

While focusing on the framework, Neuma has produced a high-quality effective environment which is easily adapted to both very small and very large environments. Besides having a high level of configurability, CM+ also boasts a very low maintenance product with a very responsive user interface.

CM+ is built upon the company's own open repository, accessible through its API. The repository includes capabilities for efficiently dealing with data hierarchies and revisions of data of various sizes from simple data records, to lists, notes, files and compressed files. The smart client capability improves both performance and product reliability, so that the client can continue to operate even if the server is down.

A full suite of change control, configuration management and problem tracking facilities give Neuma a prominent position in the field. With the Application Design option, customers can add to this suite, creating useful applications, complete with GUI forms, hyperdata links, graphical, tabular and detailed reporting, in a matter of a few short hours, and full integration with existing applications.

Single Project

Installation of CM+ is straight-forward and can be performed by the user in a few minutes. However, if customizations are required, additional set-up time is required to model the customer's process. Most aspects of process modeling can be done dynamically, without halting server operation. This allows a project to get up and running quickly without having to wait until the final details of the process are settled.

One of the key advantages of CM+ is that it requires a remarkably small amount of disk space for complete installation - less than 10Mbytes. This is due to the architectural nature of the product and is exclusive of the customer's project data.

Where major changes to the default set-up are required, this is usually done in advance of the creations of a project library.

Facilities are available for loading projects from existing databases or source code control systems, or to automatically load directly from a Unix file system structure. This permits users to capture historical as well as current product configurations.

Neuma recommends that the functionality of CM+ be phased in, with problem tracking being the first application used (requiring a 2-hour course), and change/version control added soon thereafter (4-hour course).

It is recommended that at least two persons attend a 4-day training session if a significant amount of customization will take place for a specific project.

One of the key features of CM+ is that users do not have to worry about configuring repository sizes. Neuma automatically extends the repository as required. In fact, there is rarely any administration required on the repository once it has been configured.

The license server and the repository server are started with very simple commands and the server has an automatic recovery feature which prevents any data loss or work interruption if the server is temporarily out of service.

Multiple Projects

Where more than one project is using CM+, elements of the project configuration can be shared partially or entirely, and if shared, may evolve in separate directions if desired.

Each project uses a separate CM+ server and may or may not share the license server.

Project configuration files are stored with the CM+ system and can be used in whole or in part by other projects. Often a single project is used as a pilot system before CM+ is used on multiple projects.

Version Control

Any object can be revision controlled in CM+. This includes text and binary files, note fields or more basic data, including lists of data. Unlike other systems, the CM+ repository has been designed to with intelligent revisioning at the core. For example, a list of "included" file names might be specified for a module. CM+ will not duplicate the list from one revision to the next unless it changes. Similarly descriptive note fields are not duplicated unless they change.

CM+ has an advanced delta compression algorithm which is adapted to work on some binary files as well. This is to allow objects such as MS-Word, Word Perfect, and Framemaker documents to be stored in a delta compressed format, with dramatic disk space savings. The delta compression is such that any revision of the file can be retrieved with equal efficiency. As well, a delta comparison (similar to Unix "diff") between any two revisions can be computed quickly, even for very large files (10,000+ lines). The CM+ delta comparison function can be customized both in operation and presentation. Any subset of files may be compared in a single command usually with one mouse click.

Files may be grouped into modules under a single revisioning scheme (e.g., the .c and the .h file of a C program). The revision bookkeeping is done at the module level, rather than at the file level, significantly reducing version control complexity, especially where interface and implementation sections are involved. Modules may be grouped into user-defined subsystems, systems, products, and the like, according to the customer's own terminology. These groups are themselves under revision control and revisioning of groups is done automatically by CM+ whenever product alignment is requested (whether or not the alignment is frozen).

CM+ permits the user to navigate through product hierarchies to quickly locate modules. A number of features have been put in place to make this navigation as simple and intuitive as possible.

CM+ can be customized to the customer's version control and naming conventions. CM+ promotes a two-dimensional revision control model, which is really a tree structure with each branch starting a new horizontal row. In this way, revision numbering is kept to a simple, customizable two-part number (branch and issue), typically of the form 1.1 or aa03. In any branch, only the latest revision may be open, though a new branch may be opened for a parallel change. A revision in the repository can be updated to the latest working copy while it is still being developed.

The revision status indicates whether the revision is frozen or still changing. There is a separate update status used to track the progress of a change through the promotion hierarchy (which may be fully defined by the customer). The creation of a revision is not done in isolation. It is done as part of the change control process defined later on in this report.

Accessing Versions

Access to module revisions may be controlled by CM+ roles and permissions. Typically, all users have some level of read access and write access is controlled through the change control process. This may involve ownership constraints if desired.

Modules are checked out against an update identifier (which identifies the designer and the unique change being made). The check-out operation ("borrow") may be configured to retrieve source or not to retrieve source.

When retrieving files from CM+ the latest version is retrieved by default, unless a context which specifies otherwise is in use, or unless the user explicitly identifies the required revision. Once the module has been borrowed, the "edit" button will automatically select the right file revision to be edited. The edit operation will look for source in the current directory, and will retrieve it if it is not found.

Files reside in the current directory once they have been retrieved (either through a borrow, get or edit operation), and Neuma provides support for operations within the directory. Users are also free to leave the CM+ environment and work with files at the operating system level until they are ready to check them in.

The CM+ browsing facilities allow any set of revisions to be browsed, grepped, word counted, etc. without the need to first retreive these into a directory. One common operation is to ask when a function was introduced into the system by "searching" through all of the revisions of the file that now contains the function definition.

Parallel Development

The branching structure allows parallel development on a module basis. The same branching structure is used with products and groups to allow parallel development environments. The good part is that users do not need to know which branch they are working on in most cases. Instead they only need to know which development stream they are working on. CM+ will automatically pick up the correct revisions based on the development stream.

When changes are created, they are targeted to a particular development stream and CM+ ensures that the revisions of a given branch are created in that stream (e.g., development stream vs. support stream). Any number of parallel streams may operate concurrently, with full support including all of the change control and configuration management features.

CM+ supports the idea of promotion levels within a stream. For example, a designer can work with the latest verified software for a given stream or the latest submitted software. CM+ supports object code environments whereby incremental directories may be used to form an object code environment. This allows various promotion level environments to be concurrently active without having to duplicate any of the common portions.

The other applications, such as problem tracking and activity management, fully support the parallel stream concept. Thus, it is possible to determine in one query the problems fixed between two releases, or the problems fixed in one stream that have not been addressed in another.

Merge, propagate and yank operations are available to merge changes from one branch to another, propagate single changes from one branch to another or remove single changes from a particular branch. CM+ allows this to be done on a file, module, update or product level, or on any collection of items. The merge algorithm is user-specified, with the default being the "diff3" algorithm of Unix.

Configuration Management Control

Configuration management in CM+ has many facets. The focus is on automation of CM activities. Because of the well-organized change control, compatible alignments can be created which reflect virtually any rule or combination of rules that the user requires.

A product alignment is created using the a set of updates which have been promoted to a user-defined state (e.g., selected). The system integration team can select updates based on the features or problems fixed, based on their status alone (e.g., all submitted updates), based on the development stream to which they apply, based on compatibility levels (e.g., only select upward compatible updates), or based on other criteria. Explicit and implicit pre-requisites can be viewed or automatically factored into the selection process.

Once selections are made, a development stream of a product may be aligned to include all of the selected updates. Selection can be done at more than one level allowing subsequent alignment to any of these levels (e.g., selected or verified levels). The levels may be user-defined to suit the environment and may change over the life of the product. Alignment is a simple, quick function and can be done with or without freezing the configuration. This allows the integration team a few attempts at stabilizing the software product before freezing the alignment that defines it. If desired, different layers of a product can be aligned and frozen at different times, or an entire product family can be aligned in a single operation.

CM+ supports the concept of contexts which can be used to give simple names to a complex set of factors which encase an environment. The context would contain the information about which stream, promotion level, object code directories and libraries, include paths, compile options, link options, and tool revisions, to use within the environment. Contexts may be end-user-defined or system-defined.

Contexts may be dynamically modified to contain any mix of revisions of the software. This allows an easy means for common search (e.g., grep) or metric (e.g., wc) operations on any pre-defined or dynamically defined product alignment, without having first to retrieve the code from the repository.

Impact Analysis and Dependency Relationships

CM+ can work with include relationships in a variety of user-configurable manners. Typically, these relationships are captured whenever a program is submitted to the system. Configuration can be specified on a per file type basis so that .c and .h files might work one way, .for files another, and .txt files not at all, for example.

Because dependency data is revisioned, these relationships affect a given environment (known as a "context") only when they have been aligned into that context. Potential relationship queries are numerous. For example, with a given context, one can ask questions such as:

When using "build" files, the relationships can be used to directly specify which files are to be compiled. For example, one might do an incremental build which compiles all files affected by all of the recently selected updates. In addition, the build hierarchy (and perhaps other hierarchies) is stored in the repository and can be queried in a number of ways, including through the use of "leaf" and "expand" operators which help traverse the hierarchy for a given operation.

Besides include dependencies, CM+ can control any number of additional dependencies. For example, it is possible to ask if one layer of the system is dependent on higher layers, or list the updates a given update is dependent upon.

Users can define their own dependency relationships and populate the repository using object specific analyzers. For example, one customer stores the "defined-in" and "calls/calledby" relationships for functions of a program. This dependency information is all kept under revision control so that historical queries can still be accurately made while the system relationships continue to change.

Change Control

Change Forms

CM+ is one of the few CM tools which provides full change control as opposed to file control. CM+ views an "update" as a change to one or more files for one or more reasons. The reasons are important to meet traceability requirements and generally consist of problem identifiers, activity identifiers, review identifiers, or other approved reasons for changes.

When an update is created, a customized form appears asking for various pieces of information including the reasons for the change, a description of the change, the compatibility, the development stream and perhaps other pieces of information.

An update moves through the system as a whole. The update is created to hold the set of files being modified. Files are borrowed (i.e., checked out) against the update according to the stream for which the update is targeted. CM+ will not let an update accidentally go into the wrong development stream. Additional checks and measures may be put in place using the rule and trigger capabilities of CM+. For example, it is easy to enforce the following types of rules:

At any time, the user can ask for a "delta" display of the update, including all of the files it includes, with a simple click of a button. By default, CM+ shows the latest update for the user, though any other can be selected as well.

Rather than submitting individual files back to the repository (also referred to as the library), the developer simply submits the update. This causes all of the files to be picked up and submitted. These files stay packaged together through the entire update promotion cycle so that all parts of a change make it into a release.

The entire update promotion flow (i.e., life cycle) can be configured in CM+ and enforced using the process tools of CM+. These include the ability to graphically display the process flow and to indicate which user roles are required in order to move the update along a particular promotion transition path. There are similar process flows for problem reports and activities and these can be fully configured to the customer's own processes.

As well as the flexibility of defining and assigning roles and permissions down to the field level if desired, CM+ permits the use of various "ownership" enforcements. For example, modules can be given group ownership so that only members of the group may make changes to them. This can be done on a branch level if desired. There are mechanisms to support stricter or more lenient forms of ownership, and these can be applied to any piece of data, including problem reports, activities, users, and products.

Change Reports

There are literally hundreds of change control reports possible with CM+, and users can customize their own. In most cases, the User Interface is customized to show a menu of most commonly used reports. A report is usually specified with a single command line, so that reports can be created easily as and when needed.

Change reports may be composed of any set of fields, sorted by any field criteria and displayed at various levels of detail for any set of problems, updates, activities, modules, users, or other objects. Common reports include:

Each of these reports can be customized individually, using a single command line of the GUI configuration file. This customization can cause a report request to prompt for the fields desired, specify graphical or tabular display where applicable, prompt for the sort fields, and various other items. The set of items can be partially specified by the configuration and more fully qualified by the prompts as desired.

Build and Release Support

Building

CM+ supports two primary methods of doing builds. The first is a flexible makefile generation capability which allows generation of the full set of dependency rules without having to traverse the source files for the information since the information is stored in the repository when the file is submitted to the library.

Include and Object/Library search paths may be specified so that the resulting make file picks up local directory files and then uses the paths to find other files that may be required for the build. This facilitates incremental builds and builds against various sets of promotion directories. It also removes the need to build intermediate archive libraries when using a promotion strategy. A peer's directory could be specified in the path(s) if the work he is doing has not yet been submitted to the repository.

The second method of doing a build is by using a generic build file. A build file is generated by Neuma by using the search paths specified to look for object files for a set of modules to be compiled. The build file generated contains the name of the directory in which the file was found, if it was found, the file name, the object file name, and various other data that the user may specify, including option class tags, variant tags, and source code type.

This build file is produced in a format that is directly executable by a simple control program which might, for each line of the file, look at the source code type and whether or not the object file already exists to decide if and how the file needs to be compiled. Rather than using a full dependency rules algorithm as is used by "make", Neuma itself may be used to specify which files need to be compiled (for example: Compile all of the files affected by the set of updates that have been selected for the build.

In an environment where there are many variants or options supported, the control program would use the information from the build file to determine which files need to be compiled and/or linked. The build files would contain only those files which were candidates for recompiling, ignoring variants and options.

Rebuilds

The make facility is used for rebuilding in the normal manner. When the build facility is being used, the CM+ query language is used to select only those programs which need to be recompiled, based on the change and dependency information which resides in the repository.

Variants and Options

CM+ uses the concept of option classes to allow the integration and development teams to work on the entire superset of software from a management perspective while still allowing particular variants with various options to be included as part of any build. Since the number of variations can grow exponentially, CM+ focuses on how to simplify the object code environments and provides consulting on how to optimize the handling of variants and options.

A makefile can be generated for a particular variant and set of options or for an entire superset. As well, generalized build files can be used to replace the complex "make" file schemes. These can be used to select dynamically the variant and options when the load build operation is to be run.

Release Support

Because CM+ has integrated problem tracking and project management, including feature specifications, it is possible to automatically generate a set of release notes which identifies problems which have been fixed, features which have been added, and outstanding problems. These can be produced to various levels of detail and require only a moderate amount of editing to add release overview information if it has not already been captured as part of the project management.

This same set of information can be browsed on-line. One need only specify a product, product family, or subsystem, and the two revisions to be compared. Once this is done the set of software updates, designers, problems fixed, and activities pertaining to the difference in the two releases can be browsed using only the mouse.

Releases generally reflect the revision structure of the products which are released. Not all revisions are released to customers, perhaps not even for internal use. Release names are independent of branch labels to allow internal development cycles to proceed in a logical sequence, yet still be coordinated with external and public releases.

If required, CM+ can be configured to track specific information about each release and can be set up to track patch releases without the overhead of maintaining separate alignments or contexts for the patches.

Usability

CM+ presents both a command line interface (CLI) and a graphical user interface (X/Motif on Unix and VMS). Both of these interfaces are customizable so that the environment may be tailored to fit the customer's needs. All command capabilities are available at the GUI level. The CLI is supported to help in cases where a display is not available (eg. VT-100 remote login).

The GUI has a Menu Bar and an Application Pallette which is used to display a menu along the left side of the display. Typically, the Pallette would include entries for Problems, Activities, Updates, Source, CM, Merging, Projects, and perhaps a few others for a system administrator.

The menu items are defined using a combination of a prompt language, CLI commands and special GUI commands. Typically, to specify an interface with 30 menu buttons would require 50 lines in the GUI configuration file.

Most menu items bring up a display panel prompting for options and parameters before performing an action. These panels may include multi-line note fields, single-line text fields, option menus, checklists, and list selectors. The dialogs are generated dynamically according to the configuration file. This allows them to be optimized for efficient behaviour. For example, when a list of updates is presented in response to the "borrow" command, the default update shown is the most recently created update, followed by other "open" updates for the user, followed by other "open" updates for other users. The integration of the dialog queries with the repository data streamlines the user interface.

As well as a graphical browser for hierarchical data such as product decomposition, update pre-requisites, work-breakdown structure, organization chart, Neuma provides a "hyperdata" browser. For example, a display panel can be created showing all updates which have been applied to create the new release. By a single click of a button from this panel it is possible to display the problems fixed by any individual update or by all of the updates. These would be listed in a display panel with similar hyperdata capabilities. By a single click on the "key" identifier (e.g., a problem identifier or an update identifier) a complete form is displayed showing all of the details of the data associated with the identifier.

CM+ has an icon browser as well which can be dynamically configured. For example, it can be run showing a set of updates represented as icons with instructions to produce a delta report showing, in a pop-up window, what was changed by an update when its icon is double clicked. The "Release" menu can be configured with a "Review Updates" button which will perform this function.

The above demonstrates that CM+ has effectively integrated process, data and user interfaces. In addition, CM+ is fast and makes efficient use of storage and network resources.

CM+ also has a number of graphical presentations for project status, GANTT charts, process flow, and general bar charts. This is supplemented by a textual data summary tabular format which is ready for export to a spreadsheet.

User Roles and Process Support

CM+ defines a number of default roles with its product, though these may be re-defined or supplemented by the user. There are some special permissions/roles which cannot be modified. These include "super" for superuser access to the data, "restrict" and "prevent" for more security, "owner" and "origby" for ownership access.

Each user may be given a set of ordinary roles and special roles. Special roles tend to override or modify the behaviour of ordinary roles. Each command may also be assigned a number of roles any of which are sufficient to execute the command. The command roles may also be defined at the application table, application field or even application record level. This can become complex and training is a definite requirement in this area.

When applied to users, roles act as privileges. When applied to commands or data, they act as access controls. Permission roles may also be applied to process flow to ensure that the right users have access to the operations.

The process flow capabilities allow control over the transition of Neuma objects. The usual case is to control the "state" of an item, providing straight-forward process flow. For example, a problem report might normally proceed through Defined, Open, Answered, and Closed states. However, this can be supplemented with a priority-based process that allows higher priority problems to flow through faster than others.

Additional process control comes through the creation of trigger scripts and rule scripts. Currently, these scripts may be attached to any command and through commands to the GUI. In the future, such scripts will be attached to process flow transitions as well. The scripts do not become separate files which need to be maintained, but are stored in the repository.

Further control is available through the CM+ command language which supports full data query capabilities, an extensive list of macro operations, all CM+ and UNIX commands, and various control structures. However, Neuma suggests that such command scripts are largely unnecessary in a well set-up repository. Command scripts can be stored under revision control within CM+ and executed directly from within CM+. This actually permits revisioning of the customer's processes, especially since rule and trigger scripts can reference revisioned scripts in an environment-dependent manner, for example, using old scripts for old releases, new scripts for new releases.

The Help System

On-line help is available for commands, macros, the GUI, system configuration parameters, data definitions, menus, and for general Neuma concepts. The on-line help is user-extensible. All help is available to both GUI and CLI users.

In addition, all user documentation is available in both hard-copy and on-line format.

User Documentation

Principal documentation on the Neuma product includes:

Additional documentation includes technical bulletins such as:

Customizing CM+

The primary requirement driving the development of the Neuma product has been the requirement of having Neuma support the customer process rather than vice versa. This requirement has been met, allowing CM+ customers to customize the following items:

Data fields and data definitions associated with each applications

Most customizations can be made dynamically, without affecting the operation of other users. This includes life-cycle processes and states, and the addition of companion applications.

CM+ defines over 100 system parameters whose values can be changed to customize operation. These range from specification of a default text editor, to parameters affecting the GUI appearance, to delta algorithm and display factors, and so on.

As well, much of the CM+ customization comes from the properties and values of fields within the repository. For example, the type of comment symbols, editor, makerule, etc. used is store against each "suffix" defined by the user. As another example, hyperdata links appear when field classes of ``list'' or "reference" appear as a property of the field.

User-defined Attributes

CM+ can be configured with up to 64 attributes attached to each application (updates, problems, activities, modules, etc.). Each attribute can be predefined or user-defined. The attribute types permitted include: numeric, symbolic, textual, reference, reference list, multi-line note, file, and delta-compressed file.

All aspects of reporting, process control, and configuration management can be applied to user-defined attributes. In addition, CM+ defines a number of "properties" which can be attached to user-defined attributes. For example, "statusdate" can be attached to a date field to cause the date to change whenever the "status" field changes. "Reply" can be attached to a "note" field to allow date-stamped, user-identified replies to be appended to a note.

Tool Integration

Neuma identifies three levels of integration for third party tools.

Loose integration - (most applications) allows for launching tools, doing revision control of its objects, and other basic functions.

Management information integration - allows for an exchange of information between tools. This can be one-way or two-way and generally involves the use of an Application Programming Interface either in Neuma or in the other tool.

Tight integration - the third party tool replaces or supplements its repository (including the OS File System), with the Neuma repository.

Most integration efforts are of type Loose. This includes integration with Framemaker and Word Perfect document packages.

Workgroup Support

Neuma/CM+ is a key project communications tool, integrating the development team with the information, interfaces, and process support appropriate to each team member.

CM+ operates as a server with smart clients. The smart clients offload the server's need to respond to queries. Instead, the server is required only for updating the repository. In this way CM+ is able to offer a high-performance product by using the computing resources on each desktop.

During a CM+ session, a "transaction" is started whenever the user updates the repository. The updates are seen only locally until the user confirms that the changes should be made permanent by issuing a "commit" request.

The CM+ server ensures that duplicate items are not created by multiple users. Users may be distributed across any number of platforms. Currently NFS or TCP/IP may be used as the client/server communication mechanism. The latter is required to support multisite operation.

Because of the smart client architecture, clients can continue to work with the repository even if the CM+ server is temporarily out of service.

Framework Standards

CM+ supports an initial level of integration with HP Softbench. CM+ is assessing the current framework standards at this time, including Tooltalk, Softbench/BMS, ODBC, OLE, OpenDoc and CORBA and is committed to moving ahead with the industry in these areas.

MultiSite Operation

During 1996, Neuma unveiled its first release of CM+ with the MultiSite offering. This option will permit a number of sites to operate with co-incident views of the repository. The CM+ distributed transaction mechanism will permit multiple sites to be continuously updated with the latest information, maintaining all sites with the latest available project information.

Supported Platforms

Please contact your local CM+ Sales Representative for details on currently supported platforms.

Neuma's Background

Neuma Technology Inc. is a privately held Canadian company based in Ottawa, Canada.

Neuma uses what it sells. Since 1989 (even before its own incorporation) the Neuma staff have been using Neuma extensively to meet their own software development needs.

Neuma has made an effort to reduce the customer's dependence upon itself as a tool vendor in several ways:

Partnering with other firms to provide additional CM+ product support

Providing a very high level of product scalability

Permitting full customization to the customer's requirements

Improving the Application Programming Interface for programmatic data access

Increasing the object-oriented characteristics allowing the user to supplement the product's functionality.

Increasing levels of third-party tool integration capabilities

Customer Support

Here at Neuma, we even use our CM+ application for customer tracking. This allows it to manage and respond to its customer's problems and feature requests in a timely and efficient manner.

Neuma has a small but growing support team and treats customers as their top priority. Email is used extensively for interaction with customers. Neuma has one major release of its product each year and supports the last two major releases. Its maintenance package includes free upgrades of the product to help ensure that its customers are able to take advantage of the most current technology.

Partnerships with consulting companies (e.g. Lansdowne Technologies, Prior Data Sciences) help ensure that Neuma's resources can support the demands of its customers.

Neuma allows its users to purchase fixed (user-based) licenses or network (floating) licenses in any mix. A fixed license permits a user to have several concurrent sessions across multiple machines.

Training

Consulting Services

Either directly, or through its partners, Neuma offers consulting services to help with code migration, application design, process engineering and customization issues. Most organizations who create custom applications (e.g. customer tracking, requirements traceability) to supplement the default application suite are eager to purchase consulting services.