CM: THE NEXT GENERATION of ALM Tool

Promotion Dependencies
Update promotion can cause dependency problems.  Suppose "black.123" depends on "jones.321" and "jones.321" is not yet ready.  Promoting black.123 would raise a dependency exception that would have to be addressed - either eliminate the dependency, roll-back black.123 or ensure jones.321 is also promoted.  A dependency may be expressed explicitly (e.g. black.123 depends on jones.321), or implicitly (e.g. black.123 changes timer.c which was earlier changed by jones.321).  Similarly, rolling back (i.e. un-promoting) an Update can cause dependency issues.

Some shops eliminate dependencies by stating that a changes cannot be checked in unless they (and all of their dependencies) are ready for the build.  This delays checkin and creates the need for more parallel change and merging.  CM+ detects both implicit and explicit dependencies and identifies them (in the default process) first to the developer (when (s)he says the Update is "ready"), and then to the CM Manager (when the Update is promoted for the Build operation).

Other ALM Functions
A next generation system must handle the full range of ALM functions.  It is not sufficient to treat documentation and test cases as simply more source code.  For example, some documentation is much like source code, in that it follows the same release evolution, and requires the same checkout/checkin and traceability through a change package.  

But other documentation is quite different.  Quality reports, technical notes, customer documents, etc. all have different sets of requirements.  They don't typically follow a parallel stream "development" path.  Often it is preferred to have their identifiers allocated automatically (e.g. TN.115 for a tech note), and grouped together, rather than to have someone devise a name.  Sometimes their sequential in nature, like the PRB meeting reports.  Sometimes they need multiple revisions (e.g. customer document reissued), sometimes they only need one (e.g. 2012 Federal Budget).

Test cases are often better off as non-revisioned short tests (e.g. commands to be entered), with changes to a test case appearing as a new test case (i.e. tc.2143 replaces tc.1399), rather than imposing a version control mechanism on them.  In other cases, where a test case is often of significant substance, it might be better to have some  version control as well.  In any case, there does need to be version control of the test case configuration.  Typically a tree structure is needed to group test cases into test modules and suites.

Requirements have text, and perhaps attachments.  They may use "note" fields (i.e. database large objects) for the text, rather than storing each requirement in a separate file.  Requirements definitely need version and change control.  They are typically arranged in a tree structure.  Often one of the most useful capabilities is to be able to compare baselines of requirements.

Tasks and problem reports (aka. defects, bugs) tend to be more data-like in nature, although tasks are often grouped into WBS (Work Breakdown Structure), for organization and for roll-up purposes.

With all of these different requirements for management data across the ALM, some tool suites pull together the best of breed and then provide integration glue.  But then there's the management of the glue, the dealing with new releases of each functional point tool, the array of administration, global access, user interface, etc. processes specific to each tool.

CM+ addresses these functions by providing a flexible base through its STS Engine.  You can create a function by starting with a data record description, adding whatever type of fields are necessary into the record.  These can include, for example, sub-tables (e.g. a document has a set of document-branches, and each document-branch has a set of document-revisions), notes, attachments (i.e. files), title,