Transcription
Decision Support Systems 45 (2008) 922–936Contents lists available at ScienceDirectDecision Support Systemsj o u r n a l h o m e p a g e : w w w. e l s e v i e r. c o m / l o c a t e / d s sImproving change management in software development: Integratingtraceability and software configuration managementKannan Mohan a,⁎, Peng Xu b, Lan Cao c, Balasubramaniam Ramesh dabcdDepartment of Computer Information Systems, Baruch College, The City University of New York, United StatesDepartment of Management Science and Information Systems, University of Massachusetts Boston, United StatesDepartment of Information Technology and Decision Sciences, Old Dominion University, United StatesDepartment of Computer Information Systems, Georgia State University, United Statesa r t i c l ei n f oArticle history:Received 20 July 2005Accepted 20 March 2008Available online 28 March 2008Keywords:Software configuration managementTraceabilityChange managementProcess knowledgea b s t r a c tSoftware configuration management (SCM) and traceability are two prominent practices thatsupport change management 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.1. IntroductionSoftware configuration management (SCM) and traceability are two important practices in software development thatsupport system evolution and change management. Thoughtheir overall objectives remain interrelated, their implementation 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 administrative practices to “establish and maintain the integrity ofwork products using configuration identification, configuration control, configuration status accounting, and configuration audits. [31] (p. 114)” Many SCM tools provide productsupport (e.g., version control and system componentsmanagement), tool support (e.g., workspace management,⁎ Corresponding author.E-mail addresses: kannan mohan@baruch.cuny.edu (K. Mohan),peng.xu@umb.edu (P. Xu), lcao@odu.edu (L. Cao), bramesh@cis.gsu.edu(B. Ramesh).0167-9236/ – see front matter 2008 Elsevier B.V. All rights reserved.doi:10.1016/j.dss.2008.03.003concurrent 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 evolution. 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 implemented in isolation. Such a practice results in fragmentation of
K. Mohan et al. / Decision Support Systems 45 (2008) 922–936knowledge 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 knowledge 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 understand 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 traceability in change management, 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 map923onto 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 therefore 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 SCM withtraceability. 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 SCMThe development of large-scale, complex software hasbeen widely recognized as a knowledge intensive activity.
924K. Mohan et al. / Decision Support Systems 45 (2008) 922–936Knowledge elements that are needed for shaping crucialdesign decisions exist as chunks scattered in various development environments. Integration of such distributed knowledge 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 them with 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. TraceabilityTraceability 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 traceability practices on project cost and schedule [10]. Decrease insystem quality, increase in the number of changes, loss ofknowledge due to turnover, erroneous decisions, misunderstanding, 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 are purely relational (i.e.in the form of relational databases or spreadsheets) and do notsystematically distinguish different node and link types. They aresuited 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 hardcoded semantics but tend to force the user to actually supply thisdetailed information in all cases, even if a simpler model wouldsuffice. 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 artifacts managedby SCM and traceability environments.2.2. Knowledge integration across SCM and traceabilityPrior 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 comprehension 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 been wellestablished [4]. Prior research on knowledge integrationfocuses on several contexts, viz., organizational knowledgeintegration, knowledge integration for new product development, knowledge integration in learning, etc. Across thesecontexts, knowledge integration has been defined as thesynthesis of individuals' specialized knowledge into situation-specific systemic knowledge [1]. It is also referred to asthe pooling and recombination of individuals' tacit knowledge 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], knowledge 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 knowledge 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 change management process. The developmentof our approach to traceability-based augmentation of SCM istheoretically guided by this research framework.3. Research methodologyOur 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.Fig. 1. Research framework.
K. Mohan et al. / Decision Support Systems 45 (2008) 922–936 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 understand the challenges faced by stakeholders involved in thedevelopment process and thereby inform the development ofthe traceability model and the integrated SCM and traceability system.3.1. Case descriptionHospSys 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 connection 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 management 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 telephonesTable 1The three phases of our researchPhaseStepsSources1. Development of atraceability model2. Development of anintegrated tool3. Preliminaryevaluation of ourapproachMeta-modelDetailed modelTraceability literatureCase studyRequirements for the tool weredrawn from our case studyThrough examples drawnfrom our case studyQualitative data from practicingsoftware developersIllustrationQualitativeevaluation925also required changes. The system was being developed tofulfill requirements of a client located offshore. The HospSysteam had continuous interactions with the offshore coordinator 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 validation plan, etc., were created from the templates provided bythe quality assurance department. Du
function of SCM tools. A tool that supports the integrated practice of SCM and traceability is . In comparison, Traceability is used to describe and follow the life of any conceptual or physical artifact developed during the software de
