The Spectrum of Functionality Figure is intended to be a high-level snapshot of state of the art in CM features. Several "arms" in the spectrum indicate possibly different CM areas, but it is envisioned that, as experience in CM systems is gained, these "arms" will join. This means that there is probably a fundamental CM model that encapsulates all the functionality presented in the spectrum. Further analysis work is needed to validate this probability.But regardless of whether every CM system designer is trying to implement the same features, there are political and technical issues that do affect the future of CM systems. (Political issues relate to marketing and standardization; technical issues concern the feasibility of implementing certain mechanisms.)
A major political issue concerns the evolution of Computer Aided Software Engineering (CASE) tools. For instance, should CASE tool vendors ignore CM within their tools and assume that environment vendors will provide the CM support in their frameworks? Or should CASE tools builders provide CM support in their tools? If CASE vendors incorporate their own CM support, users will have to solve the problem of integrating different CM systems when they install their (different) CASE tools. Also, from the vendors' viewpoint, will they essentially be duplicating much of the work that has already been done or is now being attempted for environment frameworks?
On the other hand, if CASE vendors do not incorporate CM into their tools, can they rely on environment architects to provide a suitable framework to integrate CASE tools and simultaneously provide some sort of global CM capability? The answers to these questions are not known. In either case, there is the implication that some kind of standardization would probably be needed for CM systems in relation to environments, or vice versa.
Many technical research issues will affect the capabilities of CM systems. They include:
What is the appropriate technology on which to base a CM system? Is an object-oriented database with persistency notions for immutable objects the most suitable?
In what layer of an environment's architecture does CM fit? Should it be at the base level in the database, making it an integral part of an environment framework? Or is it all a matter of specifying CM as a process at a higher level in the architecture?
Can the mechanisms for CM be separated from all the CM functionality, that is, are there "standard" CM primitives that could be used in any environment to support all the CM functionality? Is there a common CM model?
Is it possible to provide distributed CM support? Can geographically dispersed software teams use the same CM system for local CM and for system integration? This is a major problem in industry, particularly for Department of Defense contractors.
Is it possible to support cross-development of software? Can engineers developing a product on a host machine easily move it to the target machine, while still maintaining CM control over the product?
Is scale a limiting factor for CM systems? Is the CM support for a million line product the same as that for a 100 million line product?
Is it possible to model all aspects of the CM process, including the peopleintensive parts, into a CM system?
Answers to the above questions are not yet obvious. It is likely that progress will come from various sources from CM system vendors, environment architects, tool integrators, the software process modeling forum, and particularly from the computer-aided design/engineering (CAD/CAE) and computer-integrated manufacturing (CIM) worlds.
