Improving change management in software development ... · Improving change management in software development: Integrating traceability and software conﬁguration management Kannan

Decision Support Systems 45 (2008) 922–936

Contents lists available at ScienceDirect

Decision Support Systems

j ourna l homepage: www.e lsev ie r.com/ locate /dss

Improving change management in software development: Integratingtraceability and software configuration management

Kannan Mohan a,⁎, Peng Xu b, Lan Cao c, Balasubramaniam Ramesh d

a Department of Computer Information Systems, Baruch College, The City University of New York, United Statesb Department of Management Science and Information Systems, University of Massachusetts Boston, United Statesc Department of Information Technology and Decision Sciences, Old Dominion University, United Statesd Department of Computer Information Systems, Georgia State University, United States

a r t i c l e i n f o

⁎ Corresponding author.E-mail addresses: [email protected]

[email protected] (P. Xu), [email protected] (L. Cao), bram(B. Ramesh).

0167-9236/$ – see front matter © 2008 Elsevier B.V.doi:10.1016/j.dss.2008.03.003

a b s t r a c t

Article history:Received 20 July 2005Accepted 20 March 2008Available online 28 March 2008

Software configuration management (SCM) and traceability are two prominent practices thatsupport changemanagement in software development. While SCM helps manage the evolutionof software artifacts and their documentation, traceability helps manage knowledge about theprocess of the development of software artifacts. In this paper, we present the integration oftraceability and SCM to help change management during the development and evolution ofsoftware artifacts. We developed a traceability model using a case study conducted in asoftware development organization. This model represents knowledge elements that areessential to comprehensively manage changes tracked within the change managementfunction of SCM tools. A tool that supports the integrated practice of SCM and traceability isalso presented. We illustrate the usefulness of our model and tool using a change managementscenario that was drawn from our case study. We also present a qualitative study towardsempirically evaluating the usefulness of our approach.

© 2008 Elsevier B.V. All rights reserved.

Keywords:Software configuration managementTraceabilityChange managementProcess knowledge

1. Introduction

Software configuration management (SCM) and traceabil-ity are two important practices in software development thatsupport system evolution and change management. Thoughtheir overall objectives remain interrelated, their implemen-tation varies widely. SCM is the discipline of controlling theevolution of complex software systems, helping managechanges to artifacts and ensuring correctness and consistencyof systems [7,13,18]. It includes both technical and adminis-trative practices to “establish and maintain the integrity ofwork products using configuration identification, configura-tion control, configuration status accounting, and configura-tion audits. [31] (p. 114)” Many SCM tools provide productsupport (e.g., version control and system componentsmanagement), tool support (e.g., workspace management,

u (K. Mohan),[email protected]

All rights reserved.

concurrent engineering control and building executableprograms) and process support (e.g. defining and controllingchange process) [12,13,34].

In our study, we focus on a fundamental functionality ofSCM, i.e., supporting change management in system evolu-tion. To implement a change request, SCM helps identifynecessary changes, understand the impact of changes, andprovides a facility to track the changes [13,19]. In comparison,Traceability is used to describe and follow the life of anyconceptual or physical artifact developed during the softwaredevelopment life cycle [29]. It helps developers understandthe relationships that exist within and across softwareartifacts such as requirements, design, and source codemodules and analyze the impact of changes made to theseartifacts during system development and maintenance [29].

SCM helps in the management, control, and execution ofchange and evolution of systems, while traceability helps inmanaging dependencies among related artifacts across andwithin different phases of the development lifecycle. In vastmajority of organizations, these two practices are implemen-ted in isolation. Such a practice results in fragmentation of

mailto:[email protected]




http://dx.doi.org/10.1016/j.dss.2008.03.003

http://www.sciencedirect.com/science/journal/01679236

923K. Mohan et al. / Decision Support Systems 45 (2008) 922–936

knowledge across the two environments, and negativelyimpacts change management.

In general, the objective of different change managementpractices is to ensure a systematic development process, sothat at all times the system is in a well-defined state withaccurate specifications and verifiable quality attributes. Toreach these goals, knowledge about both the artifacts of thesoftware system and the process of their development andevolution must be managed [9,20]. We characterize these twotypes of knowledge as product and process knowledge. Whileproduct knowledge refers to knowledge about artifacts of thesoftware system (models, specifications, documents, versionsof these artifacts, etc.), process knowledge refers to knowl-edge about the process followed in the development of theseartifacts (for example, how a requirement is implemented inthe design model or code and why a design decision wasmade). Components of process knowledge include:

• Design decisions: This includes reasons that explain whysystem components are designed in a specific way (and ingeneral, rationale behind design decisions).

• Dependencies among artifacts: This refers to how changesin some artifacts may impact other artifacts.

While most SCM tools provide adequate support formanaging product knowledge (as they typically focus onversion control), they do not provide adequate support formanaging process knowledge that is generated and usedduring the development and evolution of software artifacts.The lack of process knowledge makes it difficult to under-stand different viewpoints held by various stakeholdersinvolved in design process and estimate the impact ofchanges, thus hindering change management and adverselyaffecting the consistency and integrity of systems [29].Whereas version control tools are commonly used to managedependencies between versions of source code, dependenciesamong the variety of other artifacts such as requirements,design models, source code, and test cases are not adequatelymanaged. In fact, it is the presence of these dependencies thatmakes change management very complex. For example, adecision to change a user requirement may lead to multiplemodifications in design models, source code, and test cases.Without the capability to acquire and use process knowledgeabout how these artifacts are related, it is very difficult toincorporate modifications in the system. Therefore, changemanagement function of SCM should not only help managechanges to products of systems development (productknowledge), but also help trace the effects of the changeson other artifacts (dependencies) and the reasons behindsuch changes (e.g. rationale) to maintain consistency amongthe various artifacts. Recognizing the importance of trace-ability in changemanagement, past research has attempted tolink certain aspects of traceability with SCM [9,23–25,37]. Forexample, De Lucia et al. [9] and Ying et al. [37] proposealgorithms to recover traceability links from SCM tools.However, recovery tools still rely on significant amount ofmanual work to assess and tune the traceability links. It is alsodifficulty to ensure the accuracy and correctness of thesetraceability links [23]. Nguyen et al. [24], Nistor et al. [25] andMaletic et al. [23] propose tools that can maintain traceabilitylinks between different versions of system architectures andcode to ensure that right versions of the architectures map

onto the right versions of the code in SCM environments.These studies advocate integrating traceability with changemanagement functions of SCM, but mainly address thetraceability between design models and code. They do notaddress the maintenance of traceability between otherartifacts (e.g., requirements, implementation components,test cases, etc.). More importantly, design decisions, animportant component of process knowledge, are also oftenleft undocumented. Furthermore, most of the current studiescan only manage dependencies between changes andproducts at the level of documents or files (e.g., architecturedescription documents to implementation files). They are notcapable of representing finer-grained dependencies such asthe dependency between a specific requirement and a class inan object oriented design model. Fine-grained managementof dependencies is necessary to effectively support changemanagement since it helps developers to quickly identify andimplement changes.

In summary, results from prior research [29] highlight thestrong link between SCM and traceability practices. Weconclude that current change management in SCM practicefaces two challenges:

• Process knowledge support: Lack of support for managingprocess knowledge that can trace dependencies amongartifacts across different phases of development lifecycle.

• Granularity: Lack of support for the management of productand process knowledge at a fine-grained level of granularity.

We argue that these challenges constrain the ability ofdevelopment personnel to comprehensively understand theexisting artifacts and relationships among them, and there-fore affect the quality of change management. This motivatesour research question: “How can the change managementfunction of SCM be enhanced with process knowledge aboutartifacts developed in the software development lifecycle?” Inthis paper, we address this research question by proposing anapproach which augments SCM with traceability. SCMcomprises of a set of processes that are typically implementedthrough a set of tools, the most common among which areversion control tools. In this research, we illustrate ourapproach through the integration of traceability with aversion control system. However, our approach can begeneralized to other practices and tools used for changemanagement in SCM.

The paper is organized as the follows: In Section 2, wediscuss traceability and its isolation from SCM, highlightingthe knowledge fragmentation across SCM and traceabilityenvironments. It also presents the literature on knowledgeintegration as the theoretical basis for integrating knowledgeacross SCM and traceability. Section 3 presents our researchmethodology. Sections 4 and 5 present the two componentsof our approach (a model and a tool) to augmenting SCMwithtraceability. We then illustrate the application of our modeland tool with scenarios drawn from our case study (Section6). Section 7 presents the contributions and implications ofour research.

2. Theoretical basis for integrating traceability and SCM

The development of large-scale, complex software hasbeen widely recognized as a knowledge intensive activity.

924 K. Mohan et al. / Decision Support Systems 45 (2008) 922–936

Knowledge elements that are needed for shaping crucialdesign decisions exist as chunks scattered in various devel-opment environments. Integration of such distributed knowl-edge elements is considered as a key to successful softwaredevelopment [35]. In distributed software development,which is very commonplace today, knowledge integrationbecomes especially challenging when the team members areinvolved in the co-construction of ‘collective work products’[15,22]. Our research is based on the premise that while SCMassists in the management, control, and execution of changeand evolution of systems, augmenting themwith traceabilitywhich helps maintain the dependencies among relatedartifacts across and within different phases of developmentlifecycle (e.g., the dependency among requirements, designelements, source code, etc) will help achieve more effectiveknowledge integration.

In this section, we present past research on the roles oftraceability and SCM in supporting knowledge integration insoftware development.

2.1. Traceability

Traceability assists in understanding the relationships thatexist within and across software artifacts like requirements,design, and source code modules. These relationships helpdesigners ascertain whether and how the design andimplementation satisfy the requirements. Also, traceabilityhelps understand the rationale behind the design decisionsmade during system development. Traceability has beenconsidered as a quality attribute and many standardsgoverning systems development require the creation oftraceability documents [29]. The need for maintaining tracesamong artifacts to support change management in softwaredevelopment is well documented in the literature [29]. Priorliterature also describes the adverse impact of poor trace-ability practices on project cost and schedule [10]. Decrease insystem quality, increase in the number of changes, loss ofknowledge due to turnover, erroneous decisions, misunder-standing, and miscommunication are some of the commonproblems that arise due to lack of or insufficient traceabilityknowledge [10].

A traceability system helps in maintaining a semanticnetwork in which nodes represent objects among whichtraceability is established through links of different types andstrengths. The simplest traceability tools arepurely relational (i.e.in the form of relational databases or spreadsheets) and do notsystematically distinguish different node and link types. Theyaresuited only to support simple traceability practices and providelimited support for dependency analysis. A few tools allow theuser to specialize link types but it is hard to attach semantics tothem. Others offer a fixed high-end set of link types with hard-coded semantics but tend to force the user to actually supply thisdetailed information in all cases, even if a simpler model would

Fig. 1. Research f

suffice. Prior research [29] establishes the need to developsituation-specific traceability schemes that suit the unique goalsand requirements. In our research, this entails the developmentof a traceability scheme that helps integrate process and productknowledge that is fragmented across different artifactsmanagedby SCM and traceability environments.

2.2. Knowledge integration across SCM and traceability

Prior research has highlighted the relationship betweenthe integration of existing knowledge to provide a holisticpicture and the quality of problem solving and decisionmaking [1]. For example, several studies in software compre-hension have focused on assessing the impact of developer'sknowledge on understanding a system [5,26]. Links betweenthe nature of knowledge required to understand the systemand the performance of tasks by programmers have beenwellestablished [4]. Prior research on knowledge integrationfocuses on several contexts, viz., organizational knowledgeintegration, knowledge integration for new product develop-ment, knowledge integration in learning, etc. Across thesecontexts, knowledge integration has been defined as thesynthesis of individuals' specialized knowledge into situa-tion-specific systemic knowledge [1]. It is also referred to asthe pooling and recombination of individuals' tacit knowl-edge to create group level knowledge [17]. Here, in thecontext of change management practice, such individual,specialized knowledge is fragmented primarily across SCMand traceability environments (as product and processknowledge). The importance of these two dimensions ofknowledge—product and process—has been well established[14]. Also, while past research has examined the differentcontributors of quality in software development [16], knowl-edge integration has gained little attention in this context.Hence, drawing from the literature on knowledge integration,we argue that the integration of product and process knowl-edge will improve developers' understanding of the systemand thereby improve the change management process. Assummarized in the research framework in Fig.1, we argue thatsuch a synthesis of specialized knowledge will have a positiveimpact on the changemanagement process. The developmentof our approach to traceability-based augmentation of SCM istheoretically guided by this research framework.

3. Research methodology

Our research was conducted in three phases:

• Phase 1: Development of a traceability model that guidesthe integration of traceability and SCM practices.

• Phase 2: Development of a traceability tool that supportsthe use of the traceability model and is integrated with anSCM tool.

ramework.


• Phase 3: Illustration of the usefulness of our approachthrough scenarios from a case study and a qualitativeevaluation.

Table 1 summarizes the steps and sources for each of thethree phases of this research.

The development of the traceability model (phase 1)involves two steps: (1) Use of a meta-model from theliterature on traceability, and (2) development of a detailedmodel that specializes the meta-model based on the findingsfrom a case study. The development of the traceability tool(phase 2) is based on requirements drawn from the casestudy. Scenarios from the case study are used to illustrate theusefulness of our approach and a qualitative evaluation of ourapproach was conducted to examine the feasibility andusefulness of our approach as well as to identity areas inneed of further study (phase 3). In the following sections, wediscuss the case study and the three phases of this research.

We conducted a case study in an organization (referred toas HospCom) that develops telecommunication and televisionmanagement systems for hospitals (the system is referred toas HospSys). The objective of the case study was to under-stand the challenges faced by stakeholders involved in thedevelopment process and thereby inform the development ofthe traceability model and the integrated SCM and trace-ability system.

3.1. Case description

HospSys is a billing system for patients who use atelephone and a television in their rooms. The patient usuallyoperates the television by dialing preset codes from his/hertelephone. These requests are routed to a HospSys serverthrough a Private Automatic Branch Exchange (PABX).Services running on the HospSys server evaluate the patients'requests by checking patient privileges and account balances.Authorized requests are sent to the PABX or the TV controllerconnected to the television sets. Patients who have anadequate balance in their accounts can watch pay channelsand make long distance calls. HospSys controls the connec-tion of calls and the operation of the televisions. The systemwas designed to work with one specific type of telephonesystem.When different hospital clients started using differenttypes of telephones in patient rooms, the telephone manage-ment system had to be changed to accommodate the newtypes of phones. Due to the changes in the nature of messagesreceived from the telephones, the television managementsystem which was accessed by patients through telephones

Table 1The three phases of our research

Phase Steps Sources

1. Development of atraceability model

Meta-model Traceability literatureDetailed model Case study

2. Development of anintegrated tool

Requirements for the tool weredrawn from our case study

3. Preliminaryevaluation of ourapproach

Illustration Through examples drawnfrom our case study

Qualitativeevaluation

Qualitative data from practicingsoftware developers

also required changes. The system was being developed tofulfill requirements of a client located offshore. The HospSysteam had continuous interactions with the offshore coordi-nator from the client site. Rational Unified Process (RUP)®was followed in the development of HospSys. At the outset,the project manager selected MS Visual SourceSafe® as theversion control tool. HospCom was a CMM level 3 certifiedorganization and followed well documented procedures.Project management plan, SCM plan, verification and valida-tion plan, etc., were created from the templates provided bythe quality assurance department. During the execution of theproject, two major challenges were faced by the teamengaged in change management. These correspond to thetwo challenges presented in Section 1, viz., lack of processknowledge and lack of product and process knowledge atfine-grained level. The development of our traceability modeland the traceability tool are informed by the challenges facedand the knowledge needs identified through this case study.The traceabilitymodel that is developed in this study presentsan abstraction of best practices in integrating SCM andtraceability. Analogous to the Ramesh and Jarke's [29]argument that ‘reference models are condensed from casestudies’ and are subject to continuous adaptation, refinement,and evaluation, we submit that the traceability referencemodel presented in this paper which helps integrate SCM andtraceability is not categorically, ‘provably correct’, but itderives its relevance from the slice of practice it represents.Since the model is developed by studying the knowledgeneeds of an organization that follows mature developmentpractices, we argue that the model represents ‘best practices’.Also, it should be noted that this model may not be applicablein every context/situation/project. It needs to be continuouslyrefined and tailored according to project-specific needs. Suchcustomization of traceability models has been advocated bypast research on traceability [10].

3.2. Data collection and analysis

Our study was conducted over a period of about 2 years,during which structured and semi-structured interviews wereconductedmultiple times with five developers and two projectmanagers. These participants were drawn from the team thatwas responsible for the development of HospSys. The trace-ability and change management practices of the developmentteam were also observed as it went through several phases ofthe development lifecycle. The interviews were recorded andtranscribed when feasible or detailed short-hand notes takenduring the interviews were expanded in full text immediatelyafter the interviews. Observations were also documented asnotes by one of the authors.

Transcribed and documented data was analyzed usingopen, axial, and selective coding techniques that are com-monly used in qualitative research [32]. In open coding, wefocused on breaking down, examining, comparing, concep-tualizing and categorizing data on change managementpractice [32]. It was aimed at revealing essential ideas aboutchange management found in the data. Labeling anddiscovering categories are the two tasks involved in opencoding. In labeling, discrete events and ideas receive a label.Categories were discovered by finding related phenomena orcommon concepts or themes in the data. These themes were


grouped into common headings thereby leading to categoriesand sub-categories. Coding was done by making compari-sons of events, quotes, and instances. Categories and sub-categories corresponding to challenges faced in SCM practicesand knowledge needs for effective change management wereidentified. Axial coding focused on further developing thecategories and their properties, and establishing relationshipsamong the different knowledge elements. Data was put backtogether in new ways by making connections between codesto form categories. Selective coding was used to integratethe categories to form a “theoretical framework”—i.e., thetraceability model presented in Section 4. Data collection andcoding were done till ‘theoretical saturation’ was reached,when additional data does not add to the concepts and cate-gories developed [11].

During our data collection, project managers wereinvolved in communication with coordinators from anoffshore location to understand the requirements for theHospSys system. As the development process continued,changes in requirements were carefully evaluated by therelevant stakeholders, including the offshore coordinator. Asthe analysis and design phases proceeded, each deliverabledeveloped by the HospSys team was shared with the clientteam for approval. Interactions between the HospSys teammembers and the offshore coordinator were observed andused in our analyses. While the change managementprocess facilitated the documentation of changes requestedfrom the offshore team, the coarse level of granularity atwhich these changes were documented resulted in severalproblems. Team meetings, during which decisions related tochanges were discussed, revisited the decisions repeatedlybecause specific details were not documented adequately.While the HospSys team did maintain a traceability matrixthat helped it link requirements to design documents andcode modules, these links were again at a coarse level ofgranularity. Thus, when processing a change request,developers had difficulty in locating specific design deci-sions that had been made prior to the current change, and inlocating specific versions of design elements that wereaffected by the change. By examining and analyzing thepractices followed at HospSys, we developed a traceabilitymodel that represents the process knowledge required inchange management. The traceability model was developedby specializing a traceability meta-model developed by pastresearch [29]. Specifically, we specialized the primitivesfrom this meta-model (described in Section 4),—viz.,objects, sources, stakeholders, and links among them—toinclude specific elements that will facilitate the integrationof SCM and traceability. In the following sections, wepresent details on the three phases of our research: (1)traceability model development, (2) tool development, and

Fig. 2. Traceability meta-

(3) illustration of our approach using a scenario and aqualitative evaluation.

4. Phase 1: development of a traceability model

A traceability model identifies physical and conceptualelements and artifacts, and the links among them. Priorresearch suggests that to be most useful, traceability modelsshould be tailored to suit to specific project environments [10].Though much work has been done in developing environ-ment-specific traceability models, there has been a paucity ofresearch on tailoring traceability approaches to facilitateintegration with software configuration management inspite of their synergistic functions in change management.

Prior research suggests that a traceability repository willcomprise at least three layers [3,8,27]:

• A meta-model defining the language in which traceabilitymodels can be defined.

• A set of reference traceability models which can becustomized within the scope defined by the meta-model.

• A (possibly distributed) database of actual traces, recordedunder the chosen models.

In this research, we adopt a traceability meta-model thatwas developed based on an extensive empirical study ofsoftware development projects [29]. We, then, develop areference traceabilitymodel that is customized for integrationof traceability and SCM. The primitives in this referencemodel were developed on the basis of our case studypresented in Section 3. In Section 6, we present an exampleof how actual traces may be recorded using this referencemodel to illustrate how fine-grained knowledge integrationcan be achieved by augmenting SCM with traceability.

4.1. Traceability meta-model

The traceability meta-model is presented in Fig. 2. Thismodel provides the basic language with primitives forcategorizing and describing traceabilitymodels inmore detail.

Each entity and link in the meta-model can be specializedand instantiated to create organization or project specifictraceability models. OBJECTS (such as requirements, designs,system components, rationale, etc.) represent the inputs andoutputs in system development. STAKEHOLDERS are theagents such as project managers, systems analysts, designer,etc. who act in different roles in the development and use ofOBJECTS and traceability links. OBJECTS are documented bySOURCES, which may be physical media, such as documentsor intangible things, such as references to stakeholders’ tacitknowledge. Fig. 3 shows the meta-model (shown at the top)along with a detailed model (shown below the meta-model)

model (from [29]).


depicting how traceability augments SCM. The detailedmodelrepresents different spaces involved in change management,viz., product, version, and rationale spaces. Product objectsare expanded in the product space of the detailed model.Different product objects are documented in various types ofsources. For instance, requirements may be documented in arequirement specification document. Different types ofobjects that are represented in the product space includerequirement specifications, design models, system compo-

Fig. 3. Traceabili

nents, change requests, etc. Typically version control toolsmaintain only software objects such as code files. However, toensure consistency of changes, it is also important to managethe dependencies among different software objects such asthose represented in the product space. Configurationmanagement focuses on managing the evolution of variousdocuments, while traceability focuses on managing links ordependencies among product, process objects, and stake-holders. The figure also shows how the focus of traceability

ty model.


and SCM are mapped to the different spaces in the model—SCM is mapped to version space and traceability is mapped toproduct and rationale space. The primitives in these spacesand the links among them emerged through the analysis ofthe challenges faced and the practices followed by developersat HospCom. Though HospCom followed mature softwaredevelopment practices and had developed procedures fordocumenting change requests, the participants identified twosets of challenges in their practice which correspond to thoseidentified in Section 1.

4.2. Traceability reference model

4.2.1. Process knowledge supportWhen developers need to process change requests, they

typically need to understand the ramifications of the request interms of the number of different artifacts thatwould be affectedand details about past design decisions that may be relevant forthe change request. In essence, developers need processknowledge support to effectively manage changes during thesoftware development process. Change management practicesatHospComdidnot provide thenecessary structure that guidedthe effective documentation and use of process knowledge.Identifying specific primitives and links among them thatrepresent process knowledge is the first step in guidingdevelopers toward documenting and using process knowledge.Here, we identify specific knowledge elements in the trace-ability model that provide such guidance to developers.

We observed from our case study that developers weretypically unable to link details about change requests tospecific versions of artifacts that were related to the changerequest. For example, the development team faced challengeswhile processing the request to support different types oftelephone systems. Though their version control systemmanaged the different versions of the subsystem modulesthat handle communication with telephone system, thedependencies between these subsystems were not documen-ted in detail. While their version control system managedversions of specific artifacts and documented changes thatresulted in evolution of these artifacts, dependencies acrossdifferent versions of various artifacts were either undocu-mented or fragmented in different tools and documents.While the changes done to artifacts managed within theversion control system were documented, the reasons fordesign decisions that resulted in such changes were notexplicated in a way that would help developers understandthe ramifications of newer changes on the evolved artifacts.Change requests, specific changes in software artifacts thatresult in newer versions of these artifacts, the configurationsthat include these artifacts, and the rationale behind suchchanges needed to be documented and linked. This isrepresented in the traceability model with the followingprimitives: ‘change’, ‘version’, and ‘configuration’ in theversion space, linked to ‘change request’ in the productspace, and to appropriate elements in the rationale space. Tounderstand the impact of changes, developers requireddetailed knowledge of the system and prior design decisionsalong with the reasons behind these design decisions. Thiscan be achieved by documenting the rationale using arationale space and linking the rationale space to appropriateartifacts and their evolution.

Linking product, version, and rationale spaces can bevaluable in detecting the ripple effects of changes. Changesmay affect different aspects of the system including functions,structures, behaviors, and performance. The traceability modelcan be used for impact analysis, defined as the activity ofidentifying the artifacts that must be modified to accomplish achange [2].

4.2.2. GranularityAlthough the evolution of artifacts was documented and

managed through a version control system at HospCom,muchof this was done at the file level. Changes and dependencieswere not traceable to knowledge elements documentedwithin specific files—for example, to a class or a use case in aUML model. Therefore, the development team spent a lot ofeffort identifying the specific locations in the telephonesubsystem where design/code had to be changed. This canbe attributed to the coarse level of granularity of the modelthat guided their change management practice. Linkingelements of specific versions of artifacts to requirements,change requests, and other related artifacts will help devel-opers address this problem. This is facilitated by linkingspecific primitives in the product and version spaces. Everytime a developer had to make changes to a specific part of asubsystem, s/he had to get an approval from a manager whohad the higher level view and a tacit understanding of thedependencies across subsystems. However, this process didnot work very well, as lower level implementation detailsneeded a thorough understanding of the dependencies. This isaddressed by linking low level product objects with require-ments and change requests. For instance, while version spacein ourmodel specifies versions, changes that are done tomovefromone version to another, and configurations, each softwareobject in product space is related to a set of versions in versionspace. Such a software object can be specified at any level ofgranularity ranging from a class or a use case to a subsystemora module. Changes performed to fulfill change requests resultin different versions of specific software objects. The knowl-edge about these dependencies is represented at a fine-grained level by linking specific software objects or designelements to the versions of those objects managed in theversion control system.

Rationale, which is one type of process object, is alsorequired at a fine-grained level to provide developers a clearunderstanding of design decisions made. In this space,reasoning behind decisions can be represented using modelssuch as IBIS [6] and ReMap [28,29]. For example, in thereference model for rationale developed in prior research[29], ‘issues’ represent problems that need to be addressed.‘Alternatives’ suggest different solutions to ‘issues’, each ofwhich can have supporting and objecting ‘arguments’.‘Assumptions’ are represented explicitly. ‘Decisions’ aremade by evaluating ‘alternatives’. The rationale space repre-sents deliberations related to the creation and modification ofsoftware objects, versions, and configurations described inthe product and version spaces.

In summary, the lack of adequate process knowledge andthe coarse level of granularity of product and processknowledge (i.e. the two challenges identified in Section 1),result in difficulties in performing impact analyses, high costsof implementing changes, and quality issues that slow down


development. We posit that the first step in addressing thesetwo issues involves the integration of product space, versionspace, and rationale space, thereby providing traceability notonly to different software artifacts and process knowledgeassociated with these artifacts, but also provides suchtraceability at a more fine-grained level. Our traceabilitymodel includes links between product and process knowl-edge and the different spaces (product, rationale, and versionspaces). While product space documents product knowledge,rationale space documents process knowledge. Version spaceprovides a platform for managing product and processknowledge, in that it helps manage versions of the productsspecified in the product space while facilitating links to finerdetails about changes, versions, and configurations (forexample, links to detailed decisions, issues, etc. that arerelated to specific changes, versions, and configurations). Ourtraceability model depicts how product-oriented SCMmay beaugmented to represent process-oriented knowledge typi-cally represented in traceability tools, thereby providing astructure for process knowledge support at a fine level ofgranularity.

5. Phase 2: development of a traceability tool

Based on our case study, we have developed a traceabilitytool (called Tracer) that supports the acquisition and use ofprocess and product knowledge represented in model shownin Fig. 3. This tool supports the creation of a traceabilitynetwork representing the association among various knowl-edge components drawn from different tools used by soft-ware developers. Tracer is integrated with MS VisualSourceSafe®, a commonly used version control tool. Whilethe ultimate objective of our research is to integrate changemanagement practices of SCM and traceability, SCM as a set ofprocesses is typically implemented through a set of tools, themost common among which are the version control tools. Weillustrate our approach through the integration of traceabilitywith a version control system. However, our approachgeneralizes to other aspects of change management in SCM.

5.1. Requirements for the tool

When probed about specific requirements for an ideal toolto address the issues faced by the organization in managing

Table 2Mapping requirements for knowledge integration to capabilities of tracer

Issues in changemanagement

Requirement for traceability tool that augments SCM

Lack of process knowledgesupport

Supporting the traceability model developedin phase 1Integration with an SCM tool

Lack of fine-grainedmanagement of processand product knowledge

Linking change requests and versions that satisfythese requests to specific parts of artifacts that areimpacted

product and process knowledge, the stakeholders identifiedthe following three specific requirements:

1. Support for a comprehensive traceability scheme that linksproduct and process knowledge (such as the modeldeveloped in phase 1): The tool should facilitate thedefinition and instantiation of a user-defined traceabilitymodel.

2. Integration with an SCM tool: The tool should be able tocommunicate with an SCM tool so that links can beestablished across artifacts managed by the tools thatimplement SCM and the knowledge elements documentedin the traceability tool.

3. Linking change requests and versions that satisfy theserequests to specific parts of artifacts that are impacted: Thetool should facilitate linking process knowledge elementsto specific parts of artifacts (such as use cases, classes, etc.)rather than just files.

Table 2 shows the mapping between the two issuespresented in Section 1 and the capabilities of our tool thataddress these issues.

5.2. Architecture of the tool

Fig. 4 shows the architecture of the Tracer. Each layer shownin the architecture is described in the following sections.

5.2.1. User interface layerTracer's user interface layer is used to define a traceability

model such as the one shown in Fig. 3. At the beginning ofeach project, the project manager can use the “Model Editor”to develop a traceability model that suits the needs of theproject by specifying the primitives in the model. During thedevelopment life cycle, developers use the “Traceability UserInterface” to create traceability links that instantiate thismodel. In this process, they also use the “SCM CommunicationInterface” to connect to the version control tool (MS VisualSourceSafe®) to link specific versions of artifacts to processknowledge elements such as design decisions and rationale.

5.2.2. Repository layerThe “Traceability Model” that is used as the schema with

which knowledge elements are instantiated is stored in the“Model Instance” repository. Tracer communicates with MS

Capability of Tracer

Support for a traceability model as the one shown in Fig. 3. This model can betailored to suit to different kinds of projects.Managing dependencies among knowledge fragments that reside in variouswork process tools used by developers. Tracer is integrated with other toolsthat are used in software development like MS Office Suite, Rationale Rose (aCASE tool), Groove (a collaboration tool), and MS Visual SourceSafe (a versioncontrol tool)Tracer facilitates the documentation of changes implemented in specificelements within versions of various software artifacts and facilitates linkingsuch changes to change requests. Links to changes can be done at a finer levelof granularity—for example, a specific class or a use case can be linked to achange request to specific versions of this artifact in SourceSafe.

Fig. 4. Architecture of tracer.


Visual SourceSafe® through the interfaces exposed by it toaccess the version repository. Software artifacts are organizedwithin projects in SourceSafe®. Process knowledge (e.g.,design decisions and dependencies among software artifacts)is stored in the “Model Instance Repository”. Wheneverchanges are required, specific artifacts that are affected arechecked out into the developer's working folder. During thecheck out process, typically a textual description of thepurpose of the check out is created. After the changes aremade, the artifacts are checked in and the changes aredocumented textually. Using the interfaces exposed by MSVisual SourceSafe®, Tracer can communicate with it andextract data about the change history of specific artifacts.Specific knowledge elements inTracer can be linked to specificversions documented in MS Visual SourceSafe.

5.2.3. Tool service layerThe tool services layer supports the following services:

model and rules definition, change propagation, modelconformance verification, and integration with other workprocess tools. Each of these services is discussed below.

5.2.3.1. Model and rules definition. As discussed in Section 4,our approach requires the definition of a traceability modeland rules that help maintain the semantics of the elements inthe model. Model definition involves the definition of theprimitives of the traceability model and permissible linksamong them. Here, we adopt the model shown in Fig. 3.5.2.3.2. Change propagation. The definition of rules using theformat described above helps in change propagation. Anychange to a software artifact can be propagated along thedependency paths to suggest possible impacts on dependentartifacts. While simple impact analysis can be facilitated by

traceability matrices which represent relationships betweenrequirements and the design elements that satisfy them,complex and detailed analysis of the impact of changesrequires the use of more sophisticated inferencing proceduressuch as the rules defined as part of the traceability model. InTracer, visual identification of the impact of changes isenabled using a graphical browser.

Apart from just identifying elements that are impacted bychanges, the nature of the impact is described by the rulesthat specify the semantics of links. Link semantics explainhow a change affects related elements. Rationale that isdocumented as part of the traceability knowledge also helpsexplain the nature of the impact of changes.5.2.3.3. Model conformance verification. While documentingchanges, Tracer prevents stakeholders from creating strayknowledge elements and links among them that are notidentified by the model. As new knowledge elements andlinks are created, Tracer verifies the conformance of theseinstances with the pre-defined model schema (stored in“Traceability Model” repository). In fact, the graphical inter-face allows the instantiation of only the objects and links thatare specified in the traceability model.5.2.3.4. Integration with SCM and other tools. Tracer has thecapability to communicatewith a host of work productivity andwork process tools. The integration with MS Visual Source-Safe®, a version control tool, is central to the approachdiscussed here. Using Application Programming Interfaces(API) exposed by MS Visual SourceSafe®, Tracer communicateswith this tool to extract knowledge about various versions thatformdifferent configurations and the history of changesdone totheartifacts documented in it. Anyknowledge element inTracercan be linked to a specific version of a particular artifact byopening MS Visual SourceSafe® from within Tracer and


selecting the element that is to be linked. This functionality isexplained in more detail in the context of our case study in thenext section. Tracer is also integrated with other softwaredevelopment tools including Rational Rose®, a popular CASEtool, work productivity tools included in the MS Office Suite®,communication and collaboration tools like NetMeeting andGroove, and MS Project®, a project management tool. Macrosand APIs are used to enable such integration. Such anintegration of Tracer with other tools used in the softwaredevelopment process enables developers to retrieve relevantknowledge fromvarious toolsmore easily at afine-grained levelof detail.

6. Phase 3: preliminary evaluation

In this section, we describe the two steps used to provide apreliminary evaluation of our approach. First, we use a scenariodrawn from our case study to illustrate the usefulness of ourapproach. Second, we present a qualitative study involvingsoftware developers on the perceived benefits of our approach.

6.1. Illustration through an example from our case study

At the outset of the project, when traceability and changemanagement planning is done, the traceability model (asspecified in Fig. 3) is defined by the project manager using theModel editor. Users can define the names of the nodes, theproperties of the links including their semantics, and change

Fig. 5. Instantiating the t

propagation properties such as the direction of the links andthe nature of impacts of changes.

The top panel (toolbar) in Fig. 5 shows all the primitives inour traceability model. The canvas shows the instantiation ofthe traceability model for a scenario involving changes to thetelephone system in HospSys.

This scenario that is documented in the canvas as shown inFig. 5 relates to a change request for adding a new telephonesystem. Fig. 5 shows that the design rationale and documen-ted dependency of the telephone system indicates how thetelephone and television subsystems are related with respectto messaging that happens between the two subsystems.

Let us consider this scenario from the point of view of thedeveloper who is responsible for implementing the changesto support the new type of telephone system in terms of thetwo challenges, viz., process knowledge support andgranularity.

6.1.1. Process knowledge supportFirst, the developer needs to understand the change that

needs to be incorporated and the existing artifacts that may berelated to the change. The traceability network shown in Fig. 5already documents the details about a change incorporated inthe telephone system. This network was created during theinitial development of HospSys. The figure shows that the firstdependency is the telephone message interpretation featurewhich is implemented in the telephonemessage interpretationmodule. Thefigure also shows aparticular version (v-1-2) as the

raceability model.


candidate for change. This information is critical, as the latestversion of the systemmay not be the appropriate candidate forchange. In fact, later versions of this subsystem had beenmodified in such a manner that some flexibility in supportingdifferent telephone systemswas lost. The developer can furtherdrill down on this knowledge to specifically identify where thisversion of the module is located. With the integration of Tracerwith MS Visual SourceSafe®, the developer is able to view theproperties of the version node of themodule and access it in theversion control tool without exiting Tracer. The link betweenthe specific version of this module in the version control tooland the version node in Tracer was set at the time of initialdevelopment.

Fig. 6 shows this integration between Tracer andMS VisualSourceSafe®. Different versions that are involved in thescenario are shown in the dependency network in Fig. 6.These version nodes are linked to the actual source versionsmanaged in SourceSafe. For example, the instance of the‘version’ node ‘v-1-2’ of the ‘telephone message interpreta-tion module’ (a ‘component’ node) in Fig. 6 is linked to thatspecific version of that component in MS Visual SourceSafe®.Versioned items here can be linked to specific knowledgeelements (for example, rationale elements) in the traceabilitymodel, which explain why certain versions were changed.After identifying the implementation details of the telephonemessage interpretation system, the developer now turns her

Fig. 6. Linking nodes from the dependenc

attention to other dependencies. The television messageinterpretation module is documented in the traceabilitynetwork as a dependency of telephone message interpreta-tion module. This dependency is caused by the need for thetwo systems to communicate with each another (for example,when patients attempt to change a television channel, theyuse their telephone. These signals have to be sent from thetelephone message interpretation module to the televisionmessage interpretation module). Therefore, when a newtelephone type is introduced, due to the changes in themessaging process, television subsystem should also bechanged. The view in Fig. 6 shows the specific versions ofthe specific parts of the subsystems that need to be changed.Now the developer has a significant amount of knowledgeabout the change she is about to implement. This will help hermake informed decisions about what to change and how toimplement the changes. The traceability network alsocaptures the rationale behind past design decisions (notshown in the figure). This knowledge will help the developeravoid repeating any mistakes from the past and makeappropriate design decisions.

6.1.2. GranularityThe developer is able to further examine the knowledge

required for this change request at the level of specific classesin the UML model for HospSys that are affected by this

y network to SourceSafe versions.

Fig. 7. Impact of knowledge integration on change management outcomes.


change. The telephone interpretation module node in theTracer is linked to the classes that implement it. During initialdevelopment, using the integration of Tracer with RationalRose®, links had been established between this node in Tracerand the classes that implement this module. Now, thedeveloper can use these links and invoke Rational Rose®from within Tracer. Tracer is capable of showing a tree-likeview of the elements available within HospSys UML model.All the use cases, classes, components, etc., are listed in thisview. The developer can navigate directly to Rational Rose® tothe location where the dependent elements are specified (forexample, to the logical view containing the classes that needto be changed). These classes can be linked to a requirementstored in text format in aMSWord® document. Therefore, thedeveloper can trace the life of this change from therequirements (in a word document) to design elements (in aCASE tool) to source code versions (in a version control tool).This feature improves the level of granularity from theconventional file level to more detailed levels (such as class/use case/component level).

The process knowledge thatwasdescribed above is stored inthe “Model Instance and Repository”. This process knowledgehelps developers understand the current design and therationale behind dependencies. While making decisions about“adding new types of telephone systems” to satisfy the newrequirement request, this knowledge helps her identify otherpossible design modules that are affected (i.e., ‘telephonemessage interpretation’ and hence ‘television message inter-pretation’). To maintain the integrity and consistency of thesystem, developers need to update the process knowledge anddocument current changes and rationale behind these changesthat are made to implement the new telephone system.

Without access to this process knowledge, the developerrelies on her own expertise and past experience with thesystem. Since she may not possess adequate knowledge aboutall the specific dependencies, she may often make incon-sistent and incomplete changes. The approach proposed herehelps avoid such expensive mistakes.

6.1.3. SummaryThe traceability system used in conjunction with the

traceability model, addresses two challenges identified inSection 1:

1. It provides process knowledge support. Acting as a reposi-tory of process knowledge, it helps developers tracedecisions and dependencies among artifacts in changemanagement. The capability to link different types ofartifacts developed at various stages is critical since thesedecisions transcend different artifacts developed duringdifferent phases of the software development life cycle.

2. It provides the ability to manage product and processknowledge at a fine-grained level of granularity. It providesthe capability to link a particular requirement to a specificclass and/or a method and/or a use case so that when adeveloper implements a change request, he/she canidentify specific elements that are relevant for the change.

In summary, our approach to integrate SCM with trace-ability addresses the challenges currently faced in the changemanagement process. Our implementation illustrates thebenefits of this integration.

6.2. Qualitative study

We conducted a qualitative evaluation of our approach byseeking feedback from four experienced practitioners. Thisqualitative evaluation was done independent of the casestudy presented in Section 3. The capabilities of our prototypewere demonstrated and discussed with the participants inthis evaluation. After presenting our approach, semi-struc-tured interviews were conducted with questions that focusedon the usefulness and applicability of our approach inmanaging changes during software development.

Consistentwith the traceability and knowledge integrationtheories we discussed in Section 2, the qualitative evaluationillustrates that the traceability tool used in conjunction withthe traceability model provides more appropriate and valu-able information required by developers during changemanagement [33]. Specifically, our qualitative evaluationconstitutes the first step in identifying the links betweenknowledge integration facilitated through themanagement ofdependencies and fine-grained process and product knowl-edge and impact analysis accuracy and efficiency and programcomprehension (Fig. 7). Here we developed several proposi-tions that will be tested in future research.

Integrating traceability with SCM leads to better processknowledge support and provides fine-grained process andproduct knowledge support. Our study participants suggestthat this knowledge is useful when a development team istasked to make changes to the system. The study participantssuggest that the repository of process knowledge helpsdevelopers in impact analysis during change management.In our qualitative evaluation, the capability to link require-ments and design objects (such as a class /method/use case),was highlighted by the participants as helpful in improvingthe impact analysis process by identifying changes moreefficiently and accurately. Therefore, we offer the followingpropositions:

P1. Knowledge integration across traceability and SCM willimprove the accuracy of impact analysis.

P2. Knowledge integration across traceability and SCM willimprove the efficiency of impact analysis.

Our qualitative evaluation also suggests that our approach tointegrating SCM and traceability will improve program compre-hension [36]. The capability to keep track of product andprocessknowledge will help developers better understand the various


artifacts such as design fragments and code. The capability forchange propagationwas found to be useful not only to assess theimpact on software artifacts, but also during the process ofobtaining approval for changes. In the absence of a model andtool such as ours, developers often rely on their past experienceto understand rationale behind past decisions which are docu-mented in the version control tool at a high level of detail. Theparticipants reported that structured rationale documentationwith links to appropriate software artifacts improves programcomprehension (i.e. understanding of the system components)in two ways—by reducing the time required and by improvingaccuracy. Hence we propose:

P3. Knowledge integration across traceability and SCM willenhance the accuracy of program comprehension.

P4. Knowledge integration across traceability and SCM willenhance the efficiency of program comprehension.

In summary, the qualitative study identifies four proposi-tions that suggest that our approach to integrating SCM andtraceability satisfy the objectives of this research. However, acomprehensive examination of these propositions is a subjectof future research (as discussed in Section 7.4).

7. Discussion

In this section, we present the contributions of ourresearch, implications to research and practice, limitations,and future research directions.

7.1. Contributions

This research makes the following contributions bypresenting a novel approach to integrating the two criticalareas of SCM and traceability in software development.Specifically, this research:

• Presents an empirically derived traceability referencemodel that integrates knowledge in product, rationale,and version spaces.

• Presents an approach for managing process knowledgesupport by integrating knowledge about artifacts fragmen-ted across SCM and traceability environments.

• Presents an approach to manage product and processknowledge at a fine-grained level.

• Illustrates integration of version control with traceability thatcan be generalized to other practices and tools used forchangemanagement in SCM. For example, ourmodel and toolcan be extended to support integration with a tool used totrack change requests by customizing the traceability model.

7.2. Implications to theory

This research has important implications to research onSCM and traceability. Past research on SCM and traceabilityhas been isolated from one another. We propose thesynergistic integration of these areas. For example, researchon developing or improving change management may use atraceability framework to organize artifacts managed withinSCM tools. Traceability model development should includeversion and configuration management primitives and trace-

ability tool developers may exploit the commonly availableSCM infrastructure. Research on process framework develop-ment (such as Rational Unified Process) will benefit bydefining the SCM processes that are integrated with trace-ability practices. Such integration will be even more impor-tant in software development organizations that developproduct families using domain and application engineering[30] due to the complexities involved in managing commonand variable aspects. Our research also identifies futureresearch areas on the impact of this integration on impactanalysis and program comprehension.

7.3. Implications to practice

This research contributes to practice by suggesting thatsoftware developers should consider the synergistic relationshipbetween configuration management and traceability. ThoughSCM'sdefinitionencompasses traceability, inpractice, traceabilityand SCM have been practiced in isolation. By proposing a modelthat integrates SCM and traceability, we provide guidelines toproject managers and developers for documenting changes andtheir impacts during software development. Project managersmay use our unified model as a reference model. Project mana-gers should consider using version control tools that are tightlyintegrated with traceability tools to improve the process ofchangemanagement. CASE tool developers can benefit from thisresearch by understanding the interoperation of version controland traceability tools. They may develop integrated suites thatcan handle configuration management and fine-grained trace-ability documentation based on the traceability model.

Specifically, our approach to integrating traceability withSCM will help in the following situations:

1. This knowledge is usefulwhenadevelopment teamis taskedtomake changes to the system.While the benefits to a teamthat was not involved in the original development areapparent, it should be noted that even a team that didimplement the original systemmay benefit from this know-ledge, especially in large, complex projects. The knowledgewill help the team understand past decisions made and theimpact of changes on software artifacts.

2. When there is employee turnover, the knowledge docu-mented in the system will help retain at least part of theknowledge that would have been lost otherwise.

3. This knowledge can also be useful in similar design sit-uations. Certain design decisions may have pervasive im-pact on the architecture of enterprise wide systems. Otherteams will find this knowledge useful by generalizing andapplying it in different contexts. In essence, this knowledgecan lead to the development of general best practices thatcan be shared across projects.

4. It should be noted that the issues discussed above are notonly useful to novice developers, but also to experiencedstakeholders. Further, the issues addressed by our approachare common even in organizations that follow considerablymature practices [29].

7.4. Limitations and future research

Generalization of the results from this research must bedone with caution in light of its limitations. This research has


investigated the issues in SCM and traceability in only onefield setting. Further field studies are necessary to enhancethe generalizability of our approach. Several project-relatedfactors such as complexity, size, development environmentsused, etc. should be considered when applying the results ofthis research. The effectiveness of our approach should bevalidated by detailed empirical studies for various types ofsoftware development projects. The conceptual frameworkand the propositions developed needs to be validated byfuture research. Traceability typically involves significantoverhead in terms of effort required to document and usetraceability knowledge while changing system artifacts. Thisoverhead may be minimized by providing clear guidance onwhat kind of knowledge will be most valuable during laterstages of the development life cycle. The traceability modelpresented in this research may be used as a reference modelfor this purpose. Also, we have used MS Visual SourceSafe asthe version control tool in the implementation of ourapproach to integration. Further integration with morecomprehensive set of tools focusing on various areas of SCMwill be a subject of future research. Development of appro-priate incentive schemes to motivate software developers toacquire and use traceability knowledge is a subject of futureresearch. In general, future research can examine the variousfactors that affect (for instance, cultural factors [21]) developers’propensity to contribute to knowledge integration processes.Future research can also focus on addressing migration issuesthat may be involved in transitioning to a new approach tochangemanagement such as the onepresented in this research.We are currently planning a detailed study to empiricallyevaluate the propositions developed in Section 6.

References

[1] M. Alavi, A. Tiwana, Knowledge integration in virtual teams: thepotential role of KMS, Journal of the American Society for InformationScience and Technology 53 (12) (2002).

[2] R. Arnold, Impact analysis—towards a framework for comparison,Proceedings of the IEEE Conference on Software Maintenance, 1993.

[3] P.A. Bernstein, T. Bergstraesser, J. Carlson, S. Pal, P. Sanders, D. Shutt,Microsoft repository Version 2 and the open information model,Information Systems 24 (2) (1999).

[4] J.M. Burkhardt, F. Détienne, S. Wiedenbeck, Object-oriented programcomprehension: effect of expertise, Task and Phase, Empirical SoftwareEngineering 7 (2) (2002).

[5] C.E.H. Chua, S. Purao, V.C. Storey, Developing Maintainable Software:The Readable Approach, Decision Support Systems 42 (1) (2006).

[6] E.J. Conklin, M. Begeman, Gibis: a hypertext tool for exploratory policydiscussion, Proceedings of CSCW'88, 1988.

[7] R. Conradi, B. Westfechtel, Version models for software configurationmanagement, ACM Computing Surveys 30 (2) (1998).

[8] P. Constantopoulos, M. Jarke, J. Mylopoulos, Y. Vassiliou, The softwareinformation base—a server for reuse, VLDB Journal 4 (1) (1995).

[9] A. De Lucia, F. Fasano, R. Oliveto, G. Tortora, Recovering traceability linksin software artifact management systems using information retrievalmethods, ACM Transactions on Software Engineering and Methodology16 (4) (2007).

[10] R. Domges, K. Pohl, Adapting traceability environments to project-specific needs, Communications of the ACM 41 (12) (1998).

[11] K. Eisenhardt, Building theories from case study research, Academy ofManagement Review 14 (4) (1989).

[12] J. Estublier, Software configuration management: a roadmap, Interna-tional Conference on Software Engineering, ACM Press, Limerick,Ireland, 2000.

[13] J. Estublier, D. Leblang, A. van der Hoek, R. Conradi, G. Clemm, W. Tichy,D. Wiborg-Weber, Impact of software engineering research on thepractice of software configuration management, ACM Transactions onSoftware Engineering and Methodology 14 (4) (2005).

[14] B.H. Far, M. Ohmori, T. Baba, Y. Yamasaki, Z. Koono, Merging case toolswith knowledge-based technology for automatic software design,Decision Support Systems 18 (1) (1996).

[15] C. Geisler, E.H. Rogers, Technological mediation for design colla-boration, IEEE International Professional Communication Conference,2000.

[16] M. Ghods, K.M. Nelson, Contributors to quality during softwaremaintenance, Decision Support Systems 23 (4) (1998).

[17] R. Grant, Prospering in dynamically-competitive environments: organi-zational capability as knowledge integration, Organization Science 7 (4)(1996).

[18] C.A. Gunter, Abstracting dependencies between software configurationitems, ACM Transactions on Software Engineering and Methodology 9 (1)(2000).

[19] A.M.J. Hass, Configuration Management Principles and Practice, Addi-son-Wesley Pub Co, 2002.

[20] G. Joeris, Changemanagement needs integratedprocess and configurationmanagement, European Software Engineering Conference (ESEC'97),Zurich, Switzerland, 1997.

[21] A. Kankanhalli, B.C.Y. Tan, K.-K. Wei, M.C. Holmes, Cross-culturaldifferences and information systems developer values, Decision Sup-port Systems 38 (2) (2004).

[22] J.R. Katzenbach, D.K. Smith, The discipline of teams, Harvard BusinessReview 71 (2) (1993).

[23] J.I. Maletic, M.L. Collard, B. Simoes, An XML-based approach to supportthe evolution of model-to-model traceability links, the 3rd ACMInternational Workshop on Traceability in Emerging Forms of SoftwareEngineering, ACM, 2005, Long Beach, CA.

[24] T.N. Nguyen, C. Thao, E.V. Munson, On product versioning forhypertexts, the 12th InternationalWorkshop on Software ConfigurationManagement, ACM, 2005, Lisbon,Portugal.

[25] E.C. Nistor, J.R. Erenkrantz, S.A. Hendrickson, A. Van Der Hoek, Archevol:versioning architectural-implementation relationships, the 12th Inter-national Workshop on Software Configuration Management, ACM,2005, Lisbon, Portugal.

[26] N. Pennington, Stimulus structures and mental representations inexpert comprehension of computer programs, Cognitive Psychology 19(1987).

[27] K. Pohl, Process-centered Requirements Engineering, John WileyResearch Science Press, 1996.

[28] B. Ramesh, V. Dhar, Representing and maintaining process knowledgefor large-scale systems development, IEEE Expert 9 (4) (1994).

[29] B. Ramesh, M. Jarke, Towards reference models for requirementstraceability, IEEE Transactions on Software Engineering 27 (1) (2001).

[30] K. Sherif, A. Vinze, Domain engineering for developing softwarerepositories: a case study, Decision Support Systems 33 (1) (2002).

[31] Software Engineering Institute, CMMI® for Development, Version 1.2,Software Engineering Institute, 2006.

[32] A. Strauss, J. Corbin, Basics of Qualitative Research: Grounded TheoryProcedures and Techniques, Sage Publications, Newbury Park, CA, 1990.

[33] P. Todd, I. Benbasat, The use of information in decision making: anexperimental investigation of the impact of computer-based decisionaids, MIS Quarterly 16 (3) (1992).

[34] A. van der Hoek, D. Heimbigner, A.L. Wolf, A testbed for configurationmanagement policy programming, IEEE Transactions on SoftwareEngineering 28 (1) (2002) .

[35] D.B. Walz, J.J. Elam, B. Curtis, Inside a software design team: knowledgeacquisition, sharing, and integration, Commincations of the ACM36 (10)(1993).

[36] R. Watkins, M. Neal, Why and how of requirements tracing, IEEESoftware 11 (4) (1994).

[37] A.T.T. Ying, G.C. Murphy, R. Ng, M.C. Chu-Carroll, Predicting source codechanges by mining change history, IEEE Transactions on SoftwareEngineering 30 (9) (2004).

KannanMohan is anAssistant Professorof ComputerInformation Systems at Baruch College. Dr. Mohanreceived his Ph.D. degree in Computer InformationSystems from Georgia State University. His researchinterests include managing software product familydevelopment, providing traceability support for sys-tems development, knowledge integration, and agiledevelopment methodologies. His work has appearedin journals such as Communications of the ACM,Decision Support Systems, Information & Manage-ment, and Communications of the AIS.


PengXu is an assistant professor at the DepartmentofManagement Science and Information Systems ofthe University of Massachusetts Boston. She re-ceived her Ph.D. in Computer Information Systemsfrom Georgia State University. Her research areasare software process, software engineering, knowl-edgemanagement and process agility. Herwork hasappeared in journals such as Journal of Manage-ment Information Systems, Requirements Engineer-ing Journal, Communication of the ACM, andInformation and Management.

Lan Cao is an assistant professor of InformationTechnologies and Decision Sciences at Old DominionUniversity. She received her PHD on ComputerInformation Systems from Georgia State University.Her major research interests are agile softwaredevelopment and software process modeling andsimulation.Herworkhas appeared in journals suchasCommunications of the ACM, Information SystemJournal, IEEE Software, Communications of the AISand Journal of the AIS.

Balasubramaniam Ramesh is Board of AdvisorsProfessor of Computer Information Systems atGeorgia State University. Dr. Ramesh received hisPhD degree in Information Systems from NewYork University. His research work has appearedin several leading conferences and journals in-cluding the MIS Quarterly, Journal of ManagementInformation Systems, Journal of the AIS, IEEETransactions on Software Engineering, DecisionSupport Systems, Communications of the ACM,IEEE Expert, IEEE Computer, IEEE IntelligentSystems, IEEE Internet Computing, Annals of
Software Engineering, and Annals of Operations
Research among others. His research interests include supporting complexorganizational processes in areas such as requirements engineering andtraceability in systems development, concurrent engineering, NPD, knowl-edge management, and business process redesign.

Documents

Improving change management in software development ... · Improving change management in software development: Integrating traceability and software conﬁguration management Kannan