Controlling Configuration Items in
Component Based Software Development
Carl S. Lebsack, Austin J. Mroczek, Carl J. Mueller
Computer Science Department
Illinois Institute of Technology
Chicago, IL 60616 USA
lebscar@iit.edu, mrocaus@iit.edu, mueller@iit.edu
ABSTRACT
Component Based Software Development has increased
the demand to reuse software components and to integrate
software from outside sources. A configuration item
management tool is needed to track components and their
relationships. Using a configuration item database to
store information about components is a possible solution.
A prototype configuration management tool was created
to explore the characteristics of a configuration item data-
base. The prototype displayed many functions that should
be further investigated. This paper explains the possible
uses of a configuration item database and the resulting
prototype.
Keywords: Component-Based Software Development,
software reuse, Commercial-Off-The-Shelf software, con-
figuration management, configuration item.
1 INTRODUCTION
In 1968 NATO sponsored the first conference on Soft-
ware Engineering to discuss why there was a gap between
the systems that were being proposed and those that were
being successfully implemented. One of the papers intro-
duced at this conference formalized the notion of mass
produced software [9]. To accomplish his concept of
mass-produced software, McIlroy proposed reuse of com-
ponents to build new applications. Although the discus-
sion that followed the presentation was generally positive,
nothing of significance was done to implement this con-
cept until the cold war ended. At that time, NATO gov-
ernments were less inclined to spend large amounts of
money to develop new systems. This prompted defense
contractors to search for more cost-effective methods of
software production.
The concepts of Domain Engineering [6] and Component
Based Software Development (CBSD) [4] evolved out of
the need to reduce development costs. Domain Engineer-
ing provides an in-house source for components for both
the application under development and for additions to the
reuse library. One of the primary objectives of Domain
Engineering is to produce solutions to a problem that sat-
isfy the requirements for a specific application but are
general enough in nature to be reused in other applica-
tions. Component Based Software Development reduces
software development costs through the reuse of previ-
ously developed software by adapting these components
to a new application. As with most new technologies,
there are advantages and disadvantages to this approach.
The advantage is that it does appear to reduce cost and
delivery time for producing new applications. One of the
disadvantages with this faster and more cost effective
method of development is that a number of Configuration
Management problems have emerged.
One problem is the difficulty associated with the identifi-
cation of the available components. Development organi-
zations frequently spend a large amount of time develop-
ing the same functionality repeatedly. A reason for this
continuous redevelopment is that other groups within the
organization may not know that a given function has been
developed. Publishing the characteristics of the reusable
components is a solution to this problem; but when there
are a large number of reusable modules, manual searches
may take more time than building the component. Con-
structing a database identifying the properties of each
component would reduce the search time significantly [7].
Another problem with CBSD is the effort required in
building a reuse library. It could take a number of years
to develop a robust library from in-house or contracted
development. One way to reduce the time necessary to
acquire a robust reuse library is to buy the software com-
ponents. Software purchased from an outside source is
known as Commercial Off-The-Shelf or COTS software.
Using COTS software for a traditional development envi-
ronment has advantages and disadvantages [14]. Advan-
tages of using COTS components are: functionality is
instantly accessible; they cost less than in-house devel-
opment; and they frequently are built by problem domain
experts. Disadvantages of developing with COTS com-
ponents are: limited documentation is provided; there is
no guarantee of adequate testing; portability is not guaran-
teed; limited or no source code access is provided.
Traditionally, the only COTS software components used
in an application were compilers, database managers, and
operating systems. Occasionally, some components sup-
porting communications protocols or special device inter-
faces were also included. Most of the components of new
systems were developed in-house or under special con-
tracts and tailored to the application in progress. From a
configuration management perspective, not much has
been done with COTS software. In the IEEE Standard
Software Configuration Management Plans [2], COTS
components are addressed under the heading subcontrac-
tor and vendor control; but not much direction is provided
to deal with the issues of COTS components.
New development environments and tools have added to
this problem. Many of the newer programming and
scripting languages require source distribution or a pre-
compiled middle language like Java’s byte code. For
applications developed with these languages, placing the
translator and its supporting components under version,
control is frequently not practical and often not possible.
Microsoft’s new .net framework is adding to these diffi-
culties with its Just-In-Time (JIT) environment. The .net
framework is being proposed as a solution to version and
interface problems with DLL’s [13]. The primary con-
figuration management problem with COTS components,
in all forms, is controlling a configuration when individ-
ual components are outside of that control. A developer
may have no discretion in implementing modifications
required by changes made to a component by a COTS
vendor. However, it is necessary to track the COTS com-
ponent as a configuration item to know where it is used.
Identification and control of configuration items is one of
the primary activities of Configuration Management (CM)
[3]. A configuration item is defined as a collection of
hardware and software that is designated for configuration
management [1]. Some agencies extend this definition to
include the test-harness and other items. The definition is
broad because the concept is broad. Compilers, third
party libraries, requirements documents, design docu-
ments, source code, test cases, and review documents are
all configuration items that shape the resultant piece of
software. Any time a single configuration item is modi-
fied, it splits into two distinct items: the original version
and the newly created version. The purpose of configura-
tion item management is to ensure that only the
configuration items that are part of the current version of
the software are included in the release. The changing
face of software development, characterized by compo-
software development, characterized by component reuse
and integration of COTS products, has created the need
for more sophisticated control of configuration items.
This identification and control is necessary to provide the
information for performing configuration audits that are
required by a software configuration management plan.
Frequently, control of configuration items is accom-
plished using a notebook, folder or set of note cards. In
certain environments, version control systems are adopted
to track configuration items that exist as source code.
Even with version control in place, many key configura-
tion items are not automatically tracked and must be ac-
counted for manually. Configuration items, such as com-
pilers, interpreters, documentation, and many COTS
components are items that are commonly unaccounted for
within a version control system.
One of the changes to the development process when us-
ing Component Based Software Development is that there
is an additional phase for evaluation that occurs after the
requirements phase and before the components are inte-
grated into the application [4]. The Software Engineering
Institute (SEI) defines six different types of evaluations
that should be performed when selecting a COTS compo-
nent [15]. Four of these evaluations are technical or re-
quire technical information to complete them. Conduct-
ing these evaluations is usually extremely time consum-
ing, so controlling the harness that was used to conduct
the evaluation may be as important as controlling the test
cases used to validate the application. Because of the cost
of the evaluation and the possibility that the component
may be a candidate for another application, the evaluation
reports should be under configuration control in addition
to the components evaluated. As with the test harness
that supports verification and validation reports, the har-
ness used to evaluate the prospective components under
consideration should also fall under configuration item
management. The question of how CBSD affects the con-
figuration management process affects almost every con-
figuration management activity. A short list of questions
about CBSD might include:
• How does CBSD affect a configuration audit?
• Since changes to components can occur outside
the normal change control process, how are these
component changes introduced?
• How is a change impact analysis conducted in a
CBSD environment?
• How is a Software Development File [3] main-
tained in such a dynamic environment?
All of these questions revolve around configuration items
and their relationships to each other. There are two spe-
cific relationships that are critical in a CBSD environ-
ment: 1) what components comprise a configuration item
and where are these components used? 2) With these new
demands on configuration management, what properties
and/or functions should a Configuration Item Database
(CID) incorporate?
2 CONFIGURATION ITEM DATABASE
The notion of using a configuration management database
is not a new concept for automating status accounting and
auditing tasks [5, 8, 10, 11, 12]. A configuration man-
agement database is a composite of a number of databases
consisting of change control, defect tracking, version con-
trol and configuration item tracking. It is the Configura-
tion Item database that we feel can address some of the
configuration management problems in a CBSD environ-
ment.
Many companies use the Software Development File
(SDF), formerly called the Unit Development Folder, to
hold all information about a given piece of software [3].
This file contains the item’s history of changes, audits,
test reports, and other valuable information. The contents
of the SDF are very similar to the types of information
found in a Product Data Management (PDM) file. Soft-
ware Engineers benefit from maintaining the file by being
able to analyze a change request. It allows them to see
what modules are affected by a problem and helps deter-
mine if it is a recurring problem. However, these files are
difficult to keep current with the demanding workload
within many companies. Automating the SDF increases
its efficiency and usefulness. An electronic format elimi-
nates a lengthy search through cabinets full of folders or
boxes full of 3x5 cards. It also makes data available to
multiple developers at the same time.
Version control systems are often used to manage con-
figurations. The primary purpose of version control sys-
tems is to ensure only one person is modifying a docu-
ment at a time. All pieces of code are held by the system,
which allows users to check out modules. Once finished
with a module, a developer checks it back in allowing
other users to check it out. The system keeps track of all
changes to the module.
Most version control systems cannot be used to track the
dependencies between different configuration items. In-
formation about the relationships between configuration
items is necessary to conduct change impact analysis.
Also, the maintenance of the software development folder
is accomplished separately from the version control tool.
Using a configuration item database, in conjunction with
a version control system, provides a means to produce the
reports necessary for conducting change impact analysis
and configuration audits.
The directed graph in Figure 1 shows a set of "uses" rela-
tions for Configuration Item A. Each item in the database
has a similar set of relations. A graph of the "used by"
relations could be obtained by inverting the graph of the
"uses" relations. The most important aspect of the CID is
that each node in the graph does not necessarily need to
correspond directly to a physical entity under version con-
trol. It could represent a composite object, a compiler, a
hardware platform, or the individual responsible for main-
taining a particular item.
B C
A
D
F
E
Figure 1. Configuration item directed graph.
The format in which the configuration item data is stored
is extremely important to the functionality of the system.
Configuration item dependencies are recorded in the da-
tabase, enabling dependency reports, which show the pos-
sible effect of a change to a single item. The database
stores these dependencies as a many-to-many relation-
ship. It keeps track of the items that are used by a com-
ponent while at the same time storing which items the
component uses. Also, all versions of each configuration
item should be saved to allow the change history to be
traced.
Figure 2 illustrates the complex relationships between
configuration items within the CID. The configuration
item data store holds information about various properties
of configuration items. Project name, version number,
date modified, location, and many other attributes rele-
vant to the configuration item are stored in the database.
The data store also holds the relationships between con-
figuration items. A reference to the previous version of
the item enables comparisons to different versions of the
same item.
A many-to-many relationship exists among configuration
items in that each may depend on any number of other
configuration items. Dependencies may also be mutual;
meaning item A might depend on item B where item B
also depends on item A. These relationships can become
very complex when a system consists of more than a few
items. A hierarchy chart or class diagram is generally
constructed in the design phase and is used only to denote
the relationships of large components to the overall sys-
tem. This chart leaves off many of the important configu-
ration items such as header files and libraries. The result-
ing data structure, formed by the actual relationships be-
tween all of the configuration items within a piece of
software, is recursive in that a simple traversal of the
graph would result in repeated encounters of the same
configuration items. Manual tracking of these relation-
ships would be extremely difficult.
Reference to
previous version of
Configuration Item
*..1
Configuration * ity of the data structure within the configuration item da-
*..1 Item
* tion item database via the dependencies among the con-
Depends On
Software version
dependendent
set of relations
Figure 2. Configuration Item Database
Each configuration item has a one-to-one relationship
with its previous version. These references are used to
step through the history of an item to generate item his-
tory reports. This helps to provide tracking for threads of
development across several versions of a component.
3 CMPRO PROTOTYPE
A prototype CID system was recently developed in an
attempt to incorporate characteristics desirable to a mod-
ern CM tool. Figure 2 illustrates the prototype configura-
tion item database for the CMpro system, which was cre-
ated to address the issues of establishing a component
library and tracking system. CMpro allows maintenance
of configuration items that comprise an application and
provides a means of tracking the relationship between
these items.
CMpro automatically maintains consistency of relation-
ships between configuration items in the database both up
and down. If item A is updated to depend on item C
within the database, CMpro also adds the reverse depend-
ency. This allows the user to traverse dependencies of
configuration items in either direction, the items that de-
pend on the current item or the items the current item de-
pends upon.
Once the configuration item database is constructed, it
can be continually updated and maintained. This is a ne-
cessity due to the continual process of software modifica-
tion. Each configuration item may have multiple ver-
sions, as does the configuration as a whole. In order to
maintain a relation between the versions of the individual
configuration items within the system and the version of
the system as a whole, the database must be expanded to
maintain a complete representation of the system across
all versions of the software. This increases the complex-
tabase but provides a means to generate various meaning-
ful reports.
The user can navigate interactively through the configura-
figuration items or display reports, such as a listing of all
configuration items for a particular software version.
Other reports include a list of all deliverables for a soft-
ware version and a detailed report of a single configura-
tion item, including its description and version informa-
tion. By adding some simple additional queries to
CMpro, one can enable users to retrieve the entire history
or construct a dependency tree for a particular configura-
tion item. This could be useful in both change impact
analysis and determination of defect injection.
CMpro is a client server application that was written to
allow any number of separate projects to be run from the
same server in separate databases. This feature opens the
door for decomposition of larger products into separately
managed pieces of software. This means that a single
complex software project can be broken down so that
each library, executable, or even data packages, could be
split into separate databases with one database combining
each of the project pieces into the whole. The level of
abstraction is unlimited, catering very well to component
based software development by allowing a component to
be either maintained as a distinct software product or rep-
resented as a single configuration item within a larger
software system.
Two of the most important factors in determining the im- Another important investigation in continued develop-
plementation of CMpro were platform independence and ment is interaction with a defect tracking system. The
network multi-user access. Platform independence is information necessary for assisting in defect tracking is
important because software is developed on many differ- inherently built into the CID. One of the main concerns
ent platforms and CASE tools should cater to these envi- in defect tracking is the determination of injection. By
ronments. Secondly, the network multi-user access is correlating the appearance of a defect with a specific ver-
important because configuration management by defini- sion of the software, injection could be narrowed to the
tion assumes maintenance of a unique standardized set of CIs in the system that had changed from the previous ver-
components that comprise a piece of software. In a de- sion.
velopment environment where many developers are col-
Once at this stage, the tool would be ready for widespread
laborating on a single project, there must be a common
deployment. It would still run the risk of being neglected
repository used to maintain a configuration. The solution
in many environments where deadlines and release dates
to both issues was to implement CMpro as a software
often pressure developers to set process aside in the short
system that runs on a web server, thus providing the net-
term with the intention of retroactively filling in the proc-
work multi-user access and catering to all platforms with
ess requirements. An additional integration with a ver-
Internet clients. This method also provides a common
sion control system could help to ensure proper use of the
interface across platforms and simplifies the development
tool by forcing CID updates to coincide with modifica-
of the application. In addition, by running CMpro as a
tions to the Configuration Items within the version control
web application, it can be used for distributed develop-
system.
ment from separate work sites.
Once CMpro was in use, it could be very easily extended
4 FUTURE RESEARCH DIRECTIONS
to include an interface to an index of all items available
The CMpro prototype consists of a simple web interface
for reuse. Each item within the CID already contains a
to allow a user to construct and maintain a complete sys-
complete description. The records for Configuration
tem of configuration items and their relationships. The
Items could be modified to include specific reuse
CID was created as a stand-alone product, but it is not
information such as component type (e.g. data structure,
intended to be used by itself. It assumes a process based
communications interface, algorithm, etc.) as well as
development environment with certain CASE tools al-
fields denoting the flexibility of the component. All of
ready in place. Future research involves using CMpro in
the necessary information for both a reuse index and a
actual CBSD, refining the fields for configuration items
CID would be included in the same repository. The only
and their relations and integrating CMpro with other
difference is how the information is cross-referenced and
tools.
made available to the user. Once in place, this type of
This investigation would begin by refining the database system could have a dramatic impact on the development
and deploying CMpro to actively maintain a real system. of CBSD systems.
This would provide useful information needed to evaluate
The CMpro system was developed with a process envi-
CMpro’s effectiveness as a CASE tool. CMpro records
ronment in mind and aims at assisting such an environ-
several types of information about each CI stored in the
ment by automating the creation and maintenance of a
database. These fields include the CI name, description,
CID. This provides a means of generating reports neces-
version and other relevant information. The field types
sary to configuration audits and change impact analysis.
were chosen based on suspected usefulness. A deployed
To ensure the system performs as required, it should be
system would provide feedback to determine which addi-
deployed within a real environment and integrated with
tional fields would be useful and which fields could be
other CASE tools. This would provide a more thorough
removed.
investigation regarding the use of a CID within CBSD.
Another area of investigation involves integrating CMpro
5 CONCLUSIONS
with a change control system. Change control is an inte-
Component Based Software Development presents new
gral part of a development environment in that decisions
challenges to CI management because developers no
must be made in regard to which changes will be under-
longer have complete control of the system. Configura-
taken and which changes will not. All changes under-
tion audits must account for items from outside sources.
taken should be recorded to provide traceability of modi-
When a COTS component changes, a decision must be
fications made throughout the life of the product. CMpro
made on how to introduce the change. In some instances,
currently has the ability to incorporate the recording of
the decision might be to use a comparable component
changes, but this could be extended to follow a specific
from another vender. In order to make this decision, a
process.
change impact analysis must be conducted before any
subsequent cost-benefit analysis can be conducted. [8] Larson, M. Applying Configuration Management
Manually maintaining a software development file be- Techniques to Component-based Systems. Licenti-
comes extremely tedious for a CBSD user. All of these ate Thesis MRTC, December 2000.
issues revolve around maintaining a description of a sys- [9] M. D. McIlroy. “Mass Produced Software Compo-
tem in terms of its components and their relationships to nents”. Report on a Conference sponsored by the
each other. NATO Science Committee. January 1969. pp 138-
155.
There seems to be a void in this area of tools for Configu-
[10] Miller, T. C. “A schema for configuration manage-
ration Item Management. Version control tools provide a
ment”. Procd of the 2nd Intl Workshop on Software
much-needed service of controlling access to CIs within a
configuration management. October, 1989, Prince-
development environment. A problem arises however,
ton, NJ USA. Pages 26-29.
when converting to CBSD where components are modi-
[11] National Oceanographic and Atmospheric Admini-
fied outside the immediate development environment.
stration. “Configuration Management for the Na-
This presents new challenges to CI management because
tional Virtual Data System”. August 2000.
version control alone offers no safeguards against changes
http://140.90.236.89/NVDSCMdoc.html.
to COTS components. CMpro was written as a database
[12] Ploedereder, E. and Fergany, A. “The data model of
for recording information about the CIs within a system
the configuration management assistant”. Procd of
without storing the actual items. This allows for flexible
the 2nd Intl Workshop on Software configuration
tracking of any CI whether internal, COTS or even hard-
management. October, 1989, Princeton, NJ USA.
ware. This allows CMpro to generate full reports of the
pp. 5-14.
CIs within the system, useful when performing configura-
[13] Pietrik, M. “Avoiding DLL Hell: Introducing Ap-
tion audits. CMpro also maintains a set of relations be-
plication Metadata in the Microsoft .NET Frame-
tween the CIs within the system providing the additional
work”. October 2000. MSDN Magazine.
information needed to perform change impact analysis.
[14] J. Voas, "COTS Software the Economical Choice?",
The CMpro system could also be expanded to add addi-
IEEE Software, March/April 1998, pp. 16-19.
tional features including an interface to a reuse library.
[15] Wallnau, K., Carney, D., Morris, E., Oberndorf, P.,
This could make the process of evaluation much less ex-
Buhman, C., “A Tutorial on the Theory and Practice
pensive and time consuming by providing a directory of
of COTS Software Evaluation,” 20th Intl. Conf. on
the components that are tested and already available.
Software Eng., Kyoto, Japan, 1998
Once tested further to streamline the CID and the interac- http://www.sei.cmu.edu/cbs/cbs_slides/98symposiu
tion with other CASE tools, CMpro might make an ideal m/eval_tut/index.htm.
addition to a CBSD environment by automating tasks that
help to produce quality software.
REFERENCES
[1] IEEE Std 610.12-1990, IEEE Standard Glossary of
Software Engineering Terminology (ANSI).
[2] IEEE Std 828-1998, IEEE Standard Software Con-
figuration Management Plans. (ANSI).
[3] R. H. Berlack. Software Configuration Manage-
ment. Wiley and Sons, New York. 1991.
[4] Brown, A.W., Wallnau, K. “Engineering of Compo-
nent Based System”. Proceedings 2nd IEEE Intl.
Conf. on Eng. of Complex Computer Systems,
Montreal. October 1996. pp 414-441.
[5] Choi, K.J. Kim, K.B. Jin, S.L. "A Modelling
Method of Software Configuration Change Con-
trol." IEEE(PACRIM'97), August 1997 pp.430-433.
[6] Christensen, S. R. “Software Reuse Initiatives at
Lockheed”. CrossTalk, May 1995.
http://stc.hil.af.mil/CrossTalk/1995/may/Lock-
heed.asp.
[7] Hall, R. J. “Generalized Behavior-based Retreival”.
Proceedings of the 15th Intl Conf. On Software Eng,
Baltimore. May 1993. pp 371-380