CM: THE NEXT GENERATION of ALM Tool

see a panel pop up with a stream selector.  Add a ?/products/Product, and a Product selector appears as well.  Put a comma after the second ? (called a prompt character) and it appears on the same line.  This is definitely a fun way to learn.  And you can gradually build up your repertoire.  Now when you see a command, you specify a prompt in place of each parameter, and all of a sudden the command has a full GUI.  Use macros to combine commands or to help you specify default values for your prompts.  Then use the prompts which require data expressions: a graph, a table, a display panel, a reference list selection, etc.

The point is not to extoll the virtues of CM+.  It's to point out that when you define languages that can work together, you get a lot more than the sum of the languages.  A prompt can query the current stream context and use it as a default value.  In fact, it will automatically do this for you unless you override.  It will also remember what you previously selected and use that as a default.  The data expression language can be used with the macro language to extract data from the repository to use as a default.  Or a data expression can be used to specify what you want in a pick list.  This ramps up the power of customization dramatically.  Add in the capability to save often used prompt snippets and you've got a great, concise dashboard specification language.

Customization capabilities must be a key part of a next generation ALM tool.  And although nice GUI panels might be an easy way to perform common customizations, it will not take you nearly as far as you can go as by having a nice set of orthogonal language components that can interwork.  Yes, GUI panels don't require a lot of training (so anyone can do the basic customizations in CM+, such as inserting a field, adding a state or transition, or even creating a menu item.  But a simple and very high level language capability for defining/using macros, GUI prompts, and data expressions will give you full flexibility.  Why not use Perl and TCL?  Because they are not integrated.  You have to do programming to get the integration.  Take one of the dashboard examples above.  How long do you think it would take to convert that to a Perl/TCL combination?  A few minutes or a few hours to days?  Now write a dozen dashboards.  A day or a month?  Now pass the scripting on to someone else to maintain.  Which would they prefer?

Process
Process means a lot of things.  In a next generation ALM tool, a process engine is needed that brings commonality across all ALM functions. MKS has done a decent job here for its ALM offering.  But more than just a process engine is required.  You need the ability to customize the entire tool to the process being used, whether it's a SEI's CMMI process, ICM's CM II process, Neuma's Unified Process, or your home grown process.  Overall process look-and-feel, along with process terminology, must make its way into your ALM user interface.

Once the big picture has been settled, attention can shift to the smaller details.  In large corporations, it's typical to develop an organizational wide process (consistent with CMMI levels 3 and higher), but to let individual projects customize this.  The ability to specify roles, permissions, state flow, rules, triggers, and so forth, are an important part of customization.

CM+ supports state-transition flow for every class of item tracked in your