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
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
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
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
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.
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.
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
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.
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
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.
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
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
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
Impact Analysis and Dependency
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:
Which files directly include files x.h or y.h?
Which files are affected by a change to x.h?
Which files are affected by a given (multi-file) software
Which files does x.c depend upon?
What is the include list for x.c?
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
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.
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
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:
Don't allow a "fixed" problem to be quoted as a reason for
Don't allow a "borrow" to be done unless a valid reason has
Don't allow more than one reason against an update.
Send mail when an update is submitted back to the
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
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.
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
Active updates for a given stream
Outstanding problem reports for a given stream
Recently fixed problems
Problems/updates for a given user or department
Problem arrival and fix rates
Activity/problem GANTT charts
Files with very high change rates
Updates performed by a given individual
Detailed code delta reports
Summary code delta reports (e.g., for an entire release)
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
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.
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
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
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
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
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
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
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
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
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.
Principal documentation on the Neuma product includes:
CM+ Concepts and Overview Guide
CM+ User Guide
CM+ GUI User and Configuration Guide
CM+ Reference Guide
CM+ Application Programming Interface Guide
CM+ Administration Guide
CM+ Application Design and Configuration Guide
CM+ Problem Tracking Guide
CM+ Configuration Management Guide
CM+ Fast-Start Tutorial Guide
Documentation to be released in the future includes:
CM+ Documentation Library Guide
CM+ Project Management Guide
CM+ Requirements Traceability Guide
CM+ Process and Work-Flow Guide
CM+ Test Case Management Guide
Additional documentation includes technical bulletins such
Automatic Project Loading Notes
Demo Installation Notes
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
GUI Menus and Operation
Life-cycle process states and flows
Roles and Access Permissions
The list of dependencies tracked between any two sets of
The types of objects under configuration control
Trigger and Rule Scripts
Third party tool integration
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.
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
Neuma identifies three levels of integration for third party
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
Most integration efforts are of type Loose. This includes
integration with Framemaker and Word Perfect document packages.
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"
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
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.
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
Please contact your local CM+ Sales Representative for
details on currently supported platforms.
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+
Providing a very high level of product scalability
Permitting full customization to the customer's
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
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.
Neuma offers the following training courses:
Overall System Concepts
Advanced User Capabilities
Application Design and Customization
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.