Software development is typically performed as group projects. A subject software system is developed through design efforts, test efforts, implementation efforts and maintenance efforts. There may be different groups and different group members participating in each of these efforts. Throughout these efforts and among the work group members, various modeling and other development tools are used for increased communication and consistency in developing the subject software system. A software configuration management system is one such tool.
Software configuration management systems provide an interface for users (software developer/engineer) to work with artifacts of a subject software system. An “artifact” is the persistent result of work done by a user, typically persisted in a file system such as a model and source code.
When a software development artifact is modified, the developer would like to know what other artifacts need to be modified in order for the subject system to remain consistent. Being able to perform impact analysis before changing an artifact has been a longstanding (but elusive) need in software development for years. One of the main issues is managing change to software/system requirements. Without the ability to perform impact analysis, artifacts produced as part of the development process drift apart and become inconsistent. This leads to misunderstandings, wasted time, schedule slips and non-conformance to requirements. In short, failure to manage change leads to higher development costs.
For example, when two software artifacts are connected by a dependency traceability relationship, a change to the first artifact might require a change to the second artifact in order to maintain the semantics of that relationship. These dependency traceability relationships are an essential mechanism for determining impact analysis, i.e., determining what other artifacts need to be updated following a change to a given set of artifacts. When the artifacts are placed under version control, many different configurations of those artifact versions are maintained, and changes occur in parallel in a variety of those configurations. When changes from one configuration are merged into another configuration, it appears that all of the dependency traceability relationships to the updated artifacts are suspect, i.e., have to be inspected to see if changes are required, even if the originator of those changes has verified that in fact all of these traceability relationships are valid.
Traditional solutions attempt to solve the problem using manually created and maintained traceability links. Links are manual because the variety of artifact types spans domains: for example, requirements are human readable while code is written in a formal technical language. Complex software systems have hundreds, if not thousands of requirements, and there are many to many relationships between artifact types: requirements, needs, designs, tests, code, etc.
Past attempts to maintain the validity of the traceability relationships fail because the cost to the development team outweighs the benefit. Maintaining the validity of traceability links is an arduous task even for a relatively small development effort and this is one of the main reasons existing traceability solutions fail. There are many accounts that document this issue and the difficulty in solving it.
The present invention addresses the problems of the prior art and provides improved dependency traceability that enables version-aware impact analysis in software configuration management. There is a relatively reduced effort to maintain traceability links in embodiments of the present invention.
In a preferred embodiment, a computer implemented method and apparatus provide dependency traceability in a software configuration management system by:
for a given configuration of a subject software program formed of one or more artifacts, determining respective version of each artifact;
maintaining a version history of each artifact;
for each artifact, including in the respective version history of the artifact (1) an indication of the determined version, and (2) status indication of traceability relationship for the determined version such that dependency traceability relationship of each artifact is determinable in each configuration employing the artifact.
The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
a-1b are schematic views of a preferred embodiment of the present invention.
A description of preferred embodiments of the invention follows.
Illustrated in
For each configuration, the present invention provides traceability relationship information between pairs of artifacts 15 and specifically between particular versions of artifacts 15 as follows and illustrated in
Each traceability object 10 stores a respective table 12 indicating the valid pairs of versions of the respective artifacts 15 (that is, the pairs of versions for which the dependency traceability relationship is valid). In the illustrated example, the traceability object 10a (effectively between artifacts 15a and 15b) indicates that the dependency traceability relationship between version V1a of artifact 15a and version V1 of artifact 15b is valid. Likewise traceability object 10a indicates the dependency traceability relationship between version V1b of artifact 15a and version V2 of artifact 15b is valid. Similarly traceability object 10b indicates (in its table 12b) that the dependency traceability relationship between version V1 of artifact 15b and version V1 of artifact 15c is valid, and so forth.
In other embodiments, tables 12 list both valid and invalid pairs of versions of respective artifacts 15. A data column specifies ‘valid’ or ‘invalid’ accordingly per table entry.
In the foregoing ways, the present invention stores an indication of status of a dependency traceability relationship in a view-independent fashion. As a result, any information created in one configuration as to the validity of a dependency traceability relation is immediately available (through traceability objects 10 and in particular status indications in entries of tables 12) in any other configuration for which that information is relevant and valid.
With reference to a preferred embodiment of
In other embodiments, if the user determines the traceability relationship to be invalid, then processor routine 63 marks the table 12a entry accordingly (i.e., indicating that the traceability relationship between version V1a of artifact 15a and version V3 of artifact 15b is “invalid”).
The user proceeds similarly for each pair of artifacts 15 (according to respective version) in the subject software program 13. See step 21 in
In addition, (step 23) a heuristic is applied based on the tables 12 of traceability objects 10. In particular, if there are no table 12 entries (status indications) for the exact versions of two artifacts 15 selected in a configuration, if there are entries 19, 29 in respective traceability object 10 table 12 for both predecessor and successor versions of an artifact 15, the status indication of those entries 19, 29 is given a degree of probability (based on the number of successor links separating the selected versions from the versions identified by the entry 19, 29). A user can then obtain a “probability range” or confidence rating, i.e., the probability above which the valid/invalid information is to be believed.
In the illustrated example of
Accordingly, dependency traceability relationship information is stored and maintained independent of view in the configuration management system 11. As such, embodiments of the present invention reduce the effort required to maintain traceability links.
Client computer(s)/devices 50 and server computer(s) 60 provide processing, storage, and input/output devices executing application programs and the like. Client computer(s)/devices 50 can also be linked through communications network 70 to other computing devices, including other client devices/processes 50 and server computer(s) 60. Communications network 70 can be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computers, Local area or Wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth, etc.) to communicate with one another. Other electronic device/computer network architectures are suitable.
In one embodiment, the processor routines 92 and data 94 are a computer program product (generally referenced 92), including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROM's, CD-ROM's, diskettes, tapes, etc.) that provides at least a portion of the software instructions for the invention system. Computer program product 92 can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. In other embodiments, the invention programs are a computer program propagated signal product 107 embodied on a propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s)). Such carrier medium or signals provide at least a portion of the software instructions for the present invention routines/program 92.
In alternate embodiments, the propagated signal is an analog carrier wave or digital signal carried on the propagated medium. For example, the propagated signal may be a digitized signal propagated over a global network (e.g., the Internet), a telecommunications network, or other network. In one embodiment, the propagated signal is a signal that is transmitted over the propagation medium over a period of time, such as the instructions for a software application sent in packets over a network over a period of milliseconds, seconds, minutes, or longer. In another embodiment, the computer readable medium of computer program product 92 is a propagation medium that the computer system 50 may receive and read, such as by receiving the propagation medium and identifying a propagated signal embodied in the propagation medium, as described above for computer program propagated signal product.
Generally speaking, the term “carrier medium” or transient carrier encompasses the foregoing transient signals, propagated signals, propagated medium, storage medium and the like.
The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include, a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.
For example, any computer architecture and/or network configuration is suitable for executing embodiments of the present invention. The computer network of
Version history 17 for each respective artifact 15 may be implemented as a table, a list or other log-like technique that allows appending of entries.
Number | Name | Date | Kind |
---|---|---|---|
4853843 | Ecklund | Aug 1989 | A |
5278979 | Foster et al. | Jan 1994 | A |
5574898 | Leblang et al. | Nov 1996 | A |
5649200 | Leblang et al. | Jul 1997 | A |
5701472 | Koerber et al. | Dec 1997 | A |
5898872 | Richley | Apr 1999 | A |
6112024 | Almond et al. | Aug 2000 | A |
6385768 | Ziebell | May 2002 | B1 |
6442754 | Curtis | Aug 2002 | B1 |
6536037 | Guheen et al. | Mar 2003 | B1 |
6698013 | Bertero et al. | Feb 2004 | B1 |
6701514 | Haswell et al. | Mar 2004 | B1 |
6934716 | Bradley et al. | Aug 2005 | B2 |
7069547 | Glaser | Jun 2006 | B2 |
7133874 | Hill et al. | Nov 2006 | B2 |
7191435 | Lau et al. | Mar 2007 | B2 |
7409676 | Agarwal et al. | Aug 2008 | B2 |
7480893 | Berenbach et al. | Jan 2009 | B2 |
7490319 | Blackwell et al. | Feb 2009 | B2 |
7735062 | de Seabra e Melo et al. | Jun 2010 | B2 |
20030084425 | Glaser | May 2003 | A1 |
20030120678 | Hill et al. | Jun 2003 | A1 |
20030121024 | Hill et al. | Jun 2003 | A1 |
20030204538 | Keene | Oct 2003 | A1 |
20040268302 | Srivastava et al. | Dec 2004 | A1 |
20050172306 | Agarwal et al. | Aug 2005 | A1 |
20050210445 | Gough et al. | Sep 2005 | A1 |
20060010425 | Willadsen et al. | Jan 2006 | A1 |
20060130040 | Subramanian et al. | Jun 2006 | A1 |
Entry |
---|
Conradi, R. and B. Westfechtel, “Version Models for Software Configuration Management,” ACM Computing Surveys, vol. 30, No. 2, Jun. 1998 (pp. 232-282). |
Lindvall, M. and Sandahl, K. (1998), Traceability aspects of impact analysis in object-oriented systems. Journal of Software Maintenance: Research and Practice, 10: 37-57 Jan. 1998. |
Chen, Y. et al., “Specification-based Regression Test Selection with Risk Analysis,” Proceedings of the 2002 Conference of the Centre for Advanced Studies on Collaborative Research, Toronto, Canada (14 pp.). |
Hayashi, K. et al., Temporally-threaded Workspace: A Model for Providing Activity-based Perspectives on Document Spaces, Hypertext 98: Ninth ACM Conference on Hypertext and Hypermedia, Pittsburgh, PA, Jun. 20-24, 1998 (pp. 87-96). |
Estublier, J. et al., “Impact of the Research Community on the Field of Software Configuration Management, Summary of an Impact Project Report,” ACM SIGSOFT, Software Engineering Notes, vol. 27, No. 5, Sep. 2002 (pp. 31-39). |
Conradi, R. and B. Westfechtel, “Version Models for Software Configuration Management,” ACM Computing Surveys, vol. 30, No. 2, Jun. 1998 (pp. 232-241). |
Micallef, J. and G.M. Clemm, “The Asgard system: activity-based configuration management” in Software Configuration Management, ICSE 96 SCM-6 Workshop, Berlin, Germany, Mar. 25-26, 1996, Selected Papers, pp. 175-186. |
Cohen, E.S. et al., “Version management in Gypsy,” SIGSOFT Software Engineering Notes, vol. 13, No. 5, Nov. 1998 (pp. 201-215). |
Number | Date | Country | |
---|---|---|---|
20070143744 A1 | Jun 2007 | US |