CM: THE NEXT GENERATION of ALM Tool

reference lists (including to the same table, forming a tree), etc.  CM+ provides a default layout for the data, and the rest of the application definition (state-transition flow, object-oriented pop-up menus, pull-down menu, dashboards, etc.).  In some cases, it provides more than one application definition to choose from.

But you can take any starting point and very easily customize it to the requirements.  The STS Engine supplies the bulk of the capabilities needed for the application.  And as a result, it can take advantage of the same backup procedure, disaster recovery, multiple site operation, process definition language, schema definition language, GUI customization capability, etc. as used by the other ALM applications.  Traceability, reporting, forms, browsers, and other common aspects all come for free.  Customization becomes a specification process:

• What data fields are needed, and what properties do they have (e.g. owner, status, etc.)
• What reference fields are needed - this defines traceability, history and tree structures.
• What states does a data record go through.
• What are the state transitions, including rules, triggers, permissions, etc.
• What items are in the pull-down menu (usually starting from a recommended list)
• What items are in the pop-up menu (from a recommended list, plus others dependent upon state flow)
• What dashboards are needed for each role involved in the application
• What quick-reference information should be on the main panel (quick links, report tabs, process guidance)

In each case, CM+ allows you to manually specify each item in a single command line (add a field, define a state transition, define a menu item, define a quick link, specify a dashboard, specify a report tab, add a set of process guidance slides).

Because each item can be specified in a single line, it's fairly easy for CM+ (or for the customer) to create menu items to do these things graphically.  And the CM+ Process menu is usually the place that this is found.  A bit later, when we talk more about customization, we'll look at a couple of examples to make this clear.

Platform Architecture
Platform architecture of a tool speaks, not just of which platforms it can support, and which can inter-operate successfully, but also of how quickly the ALM tool can be ported to a new platform.  After all, in 10 years, when your project is still going strong, will Windows still be the dominant client, or Linux the dominant server architecture?  Hard to know.

CM+ was initially designed as a CLI-only tool, because Windows 3 and X-Windows were in their early evolution when CM+ was being designed.  The goal was, though, to support the CLI (client and server), on any platform with the ability to port from one platform to another in a day or less.  [Until the appearance of the GUI, this worked well.]

This meant that the STS Engine had to be independent of big-endian/little-endian issues, and eventually 32-bit/64-bit issues.  This was designed into the engine - stop a server, move the files to a different platform, restart the server and it had to continue working without any user conversion.  The (smart) client had to work regardless of what architecture the server was on.  When multiple site operation came about in the mid-90s, it had to support multiple servers on different architectures working with the same repository, and clients connected from any architecture to any server.  The focus remained on Unix/Linux and Windows platforms, as well as OpenVMS (which posed its own set of issues).

When the GUI came along, there was X/Motif and Windows (MFC). Only then, did GUI technology really start to take off.  CM+ then decided to converge it's