Page 260 -

CHAPTER 9 SOFTWARE CONFIGURATION MANAGEMENT 231

• the SCI type (e.g., document, program, data) represented by the object
• a project identifier
• change and/or version information
Resources are "entities that are provided, processed, referenced or otherwise required
by the object [CHO89]." For example, data types, specific functions, or even variable
names may be considered to be object resources. The realization is a pointer to the
The interrelationships "unit of text" for a basic object and null for an aggregate object.
established for
configuration objects Configuration object identification must also consider the relationships that exist
allow a software between named objects. An object can be identified as <part-of> an aggregate object.
engineer to assess the The relationship <part-of> defines a hierarchy of objects. For example, using the sim-
impact of change. ple notation
E-R diagram 1.4 <part-of> data model;
data model <part-of> design specification;
we create a hierarchy of SCIs.
XRef It is unrealistic to assume that the only relationships among objects in an object hier-
Data models and data archy are along direct paths of the hierarchical tree. In many cases, objects are inter-
flow diagrams are related across branches of the object hierarchy. For example, a data model is interrelated
discussed in Chapter to data flow diagrams (assuming the use of structured analysis) and also interrelated
12.
to a set of test cases for a specific equivalence class. These cross structural relation-
ships can be represented in the following manner:
data model <interrelated> data flow model;
data model <interrelated> test case class m;
In the first case, the interrelationship is between a composite object, while the sec-
ond relationship is between an aggregate object (data model) and a basic object
(test case class m).
The interrelationships between configuration objects can be represented with a
module interconnection language (MIL) [NAR87]. A MIL describes the interdepen-
dencies among configuration objects and enables any version of a system to be con-
structed automatically.
The identification scheme for software objects must recognize that objects evolve
throughout the software process. Before an object is baselined, it may change many
times, and even after a baseline has been established, changes may be quite frequent.
It is possible to create an evolution graph [GUS89] for any object. The evolution graph
describes the change history of an object, as illustrated in Figure 9.3. Configuration
object 1.0 undergoes revision and becomes object 1.1. Minor corrections and changes
result in versions 1.1.1 and 1.1.2, which is followed by a major update that is object
1.2. The evolution of object 1.0 continues through 1.3 and 1.4, but at the same time,
a major modification to the object results in a new evolutionary path, version 2.0.
Both versions are currently supported.
Changes may be made to any version, but not necessarily to all versions. How
does the developer reference all components, documents, and test cases for ver-
sion 1.4? How does the marketing department know what customers currently have