GB2457552A

GB2457552A - Management of artifacts in collaborative software development

Info

Publication number: GB2457552A
Application number: GB0900779A
Authority: GB
Inventors: Jan Paul Buchwald; Andreas Nauerz; Ingo Schuster; Holger Waterstrat
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2008-02-20
Filing date: 2009-01-19
Publication date: 2009-08-26
Also published as: GB0900779D0

Abstract

Development tasks for new software in a multi-user computing programming environment are managed in a workflow server system and distributed between workflow clients associated with a respective software developer. Each task has a task identifier, and each task uses a respective set of software artifacts as common data inputs. Each version of the software artefacts is managed in a versioning system. Each software artifact has an artifact identifier. For each task, the task identifier is associated with artifact identifiers of the respective set of input artifacts. In response to determining that a software artifact is changed in the versioning system, a set of tasks that use the changed software artifact as a shared input is determined and corresponding revisioning tasks are generated in order to notify programmers that parts of the program need to be revised due to changed input. A change tracker client may be used, and the revision message may lead to a develop accepting or rejecting a change.

Description

1 -2457552

DESCRIPTION

Change Propagation in Software Engineering By Automatically opened Revisioning Tasks

1. BACKGROUND OF THE INVENTION

1.1. FIELD OF THE INVENTION

The present invention relates to the field of networked software development, and in particular to a method and respective system for developing software in a multi-user computing environiTlellt, wherein a workf low server system is used for managing a plurality of development tasks and distributing said tasks between a plurality of workf low client systems.

1.2. DESCRIPTION AND DISADVANTAGES OF PRIOR ART

Figure 1 illustrates schematically how a workf low supported software development process is usually organized in prior art.

A prior art Workf low Management System 10 is used for project planning and for tracking the completion of software development tasks which are done by a plurality of programmers. Each software development task usually engages a common repository where all project related files or documents (artifacts) are stored. The common repository is preferably implemented using a Versioning System 12, which holds a copy of each artifact not only in its latest version but also in all precedent versions thereof.

In this state of the art method, the workf low management system and the versioning system are separate units. So each user works on his tasks and stores the products of his work without taking care of the relation between the tasks and the artifacts he is d working on. A task generally needs some data to work on and roduces some other data. Those data and respective formats incorporated in the artifacts are in general specific for each task.

If an artifact changes that might have been used as an input by a further developer, the developer performing the change needs to know who is affected and must inform the respective persons by e-mail, phone, or any other kind of communication.

This disadvantageously involves on the one hand the risk that some necessary adaptations to changes might be overlooked; on the other hand, it may as well account for a loss in productivity due to the delay caused by unstructured communication.

1.3. OBJECTIvES OF THE INVENTION The objective of the present invention is to provide a method which is more user-friendly and improves the consistency between the before-mentioned artifacts and software development tasks.

2. SUMMARY AND ADVANTAGES OF THE INVENTION

This objective of the invention is achieved by the features stated in enclosed independent claims. Further advantageous arrangements and embodiments of the invention are set forth in the respective dependent claims. Reference should now be made to the appended claims.

According to a first aspect the present invention, there is provided a method for developing software in a multi-user computing environment, the method comprising managing a plurality of development tasks in a workf low server system and distributing said development tasks between a plurality of workf low clients, each workf low client being associated with a respective software developer, each task having a task identifier and each task using a respective set of software artifacts as input; managing said software artifacts and a plurality of versions thereof in a versiorling system, each software artifact having an artifact identifier, associating for each task the task identifier together with artifact identifiers of the respective set of software artifacts; and in response to determining that a software artifact is changed in the versioning system, determining a set Of those tasks that use the changed software artifact as input and generating corresponding revisioning tasks in order to notify that the set of tasks needs to be revised due to changed input.

Relationships between registered changes and respective determined tasks are stored persistently, including meta information characterizing the changes and meta information characterizing the involved tasks, then the programmers may more easily approve to a change and are better instructed about the background underlying the change. For example, if the input artifact is an architectural design document used as a basis for an implementation task, the meta information could include the statement that a particular part of the design changed due to a design review, and give some suggestions on what area is affected.

A known Workf low Management System may be used for the overall task handling of a software development project, just referred to as "project". It provides interfaces to create and assign tasks as well as to retrieve information about tasks. Each task has a unique identifier. A known Versioning System may act as a epository for all kinds of artifacts, i.e., project related computer data files. It provides an interface to retrieve artifacts from the repository and to put new artifacts or new versions of artifacts to it. Also, each artifact has a unique identifier.

A Change Tracker Component may be provided that implements and thus realizes the basic logic of the embodiments of the invention. It stores the relations between the input artifacts and the tasks. It triggers an automatic opening of revision tasks, if an input artifact changes due to the work of a software developer.

A respective Change Tracker Client component is preferably provided at each computer of each software developer that interacts with all other components to coordinate the flow of actions to realize the proposed mechanism. This change tracker client component also provides the user interface to a respective software developer.

Further, advantageously, what-if-scenarios can be performed, e.g. before committing a desired change of an artifact, all the tasks being involved by the desired change are determined and displayed to the software developer. Then, the user is prompted to input a response telling if or if not said change shall be committed to the versioning system and is thus binding for all other determined tasks. If the change is evaluated to be not desired, a canceling of the desired change of artifact will be performed.

This mechanism creates additional business information as to the consequences -costs, time effort -of a change of an artifact and thus helps to decide if or not a change should be done.

3. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and is not limited by the shape of the figures of the drawings in which: Figure 1 illustrates the most basic structural components of a prior art hardware and software environment used for a prior art method, Figure 2 illustrates the most basic structural components of a proposed hardware and software environment used for an embodiment of the invention, Figure 3 illustrates the control flow including interaction between functional software components illustrating the most important steps of an embodiment of the invention, when a change of an artifact is made, and Figure 4 illustrates the control flow including interaction between functional software components illustrating the most important steps of an embodiment of the invention, when the change of the artifact of figure 3 is detected and processed for a further task referencing the same artifact.

4. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT With general reference to the figures and with special reference now to figure 2 the workf low management system and the versioning system are again depicted. Instead of a plurality of software developers, only one is depicted in order to increase clarity. A change tracker server component 24 is provided preferably central in the network, and a change tracker client 26 is implemented for each software developer, locally at his esktop.

Figure 2 also illustrates the particular interfaces implemented to realize the proposed system. The workf low Management System and the Versioning System 12 are supposed to provide interfaces containing operations that are semantically equivalent to the following description. The numbering of the interfaces used below is shown in the figure.

The Workf low Management System 10 contains information about the tasks. Typically, the following information is stored for each task: task identifier (unique at least within the Workf low Management System), task owner (user), and task status.

Additionally, properties like task name, due date, task description, or other meta information can be used to extend the functionality or user experience of the Workf low Management System. In most workf low systems, task names are not necessarily unique; they are used as a kind of semantic description of a task. The task identifier is usually not exposed to the end user but handled internally.

At the Workf low Management System 10 an interface 201 implements functionality logic that retrieves tasks for a particular owner, gets meta information (like task name or due date) for particular tasks when the task identifier is given, and changes the state of a particular task, e.g. from,,open", or,,working", to the,,complete" state as triggered by the user. An interface providing the equivalent functionality like interface 201 is supposed to be part of any state of the art Workf low Management System.

For example, the interface 201 comprises calls like: <list of task IDs> getTasksForUser(owner) task object> getTaskNetalnformation(task id) changeTaskState(task id, new state) The Workf low Management System 10 contains further an Interface 202 that implements functionality logic that opens new tasks and assigns them to particular owners. This interface 202 may be implemented as similar known interfaces to Workf low Management Systems.

For example, an interface call like createNewTask(taskname, owner)causes the Workf low Management System 10 to create a new task with the name and owner specified in the call.

The Versioning System 12, on the other hand, stores versions of software development project related files or documents (artifacts). Typically, each artifact has a unique artifact identifier. For each new version of the artifact, the system maintains additional information about the associated change (e.g. the user who checked in the new version, the date and time of change, textual comments etc.).

At the Versioning System 12 an interface 223 implements functionality logic that retrieves artifacts based on some search criteria and stores a new version of an artifact in the repository.

For example an interface call like <list of artifact ids> getArtifacts(search criteria) returns a list of artifacts matching to the search criteria.

Such search criteria typically comprise a filter for particular artifact types (e.g. word files or XML files), text pattern based search on artifact names, or any artifact meta information (e.g. latest update, size etc.).

call like comrnitLocalChanges(artifact Id, additional information) transfers all the changes of the specified artifact to the versioning system, where they are stored by incrementing the respective version number of the artifact and associating the change to the additional information passed in -for example the user who did the change, a respective tracking number, comment etc. The Change Tracker component 24 associates tasks monitored by the Workf low Management System 10 and artifacts stored in the Versioning System 12 together, and monitors changes in the artifacts to determine whether there is need to update tasks that use the changed artifact. The Change Tracker component 24 could be implemented as an enhancement of either the Versioning System 12 or the Workf low Management System 10. If done so, the Change Tracker component would nonetheless be a logically separate component in either system, so the description of the basic functionality in the following limits to the case of a separate component.

The Change Tracker component 24 introduces the following new interfaces. The interface 244 can be called to track the input artifacts for a particular task. This interface contains an operation like tracklnputArtifactForpask(artifact Id, task id, owner) that causes the Change Tracker 24 to store the relationship for the specified input artifact to the given task and owner. The interface 245 implements functionality logic that signalizes the Change Tracker 24 that a particular artifact has changed. This interface 245 contains an operation like artifactHasChanged(artifact id). The Change Tracker component 24 contains a repository to store all relationships between input artifacts and tasks. It keeps track of changes to artifacts and triggers a revision task if an input artifact of a task has been changed. A revision task is triggered independently of the task tate.

The Change Tracker Client 26 is responsible for coordinating the flow of operations triggered by the user in the user interface 226. In most cases it acts like a combined Workf low Management System client (that retrieves the list of tasks for a particular user and allows changing the state of particular tasks) and Versioning System client (that retrieves artifacts and allows to commit changes), extended by the possibility to notify the Change Tracker component 24 about task and input artifact relationships as well as artifact changes. Thus it could be implemented by extending either a Workf low Management System client or versioning System client, adding the respective other functionality.

The Change Tracker Client 26 provides a user interface 226 implementing the following functions: display all open and working tasks for a particular user; allow the user to mark particular tasks for being worked On; allow the user to complete particular tasks; give the user access to artifacts from the versioning system; display artifacts based on certain criteria (permissions, relevance for the current task etc.); allow the user to commit changes to artifacts; and allow the user to mark particular artifacts as input for a task.

By these functional features of the interfaces and the Change Tracker 24 and the Change Tracker Client 26 it is possible to execute the methods according to embodiments of the present invention.

Based on the previous component and interface descriptions, the following two sequence diagrams of figures 3 and 4 give detailed examples of the control flow in embodiments of the invention.

The sequence diagram of figure 3 shows the flow of actions and nteraction for a user "Bob" working with the Change Tracker Client 26 user interface with interfaces 226 and 244: Bob requests his task list from the Change Tracker Client 26 in step 305. The Change Tracker Client 26 retrieves the tasks from the Workf low Management System 10 via the interface 201, step 310, and displays the tasks 123, 345, and 789 in the user interface 226, step 315. Bob selects to work on task 123, step 320. The Change Tracker Client 26 changes the state for the task 123 in the Workf low Management System 10 to "working" via the interface 201, step 325. Bob requests a list of artifacts that contain the search string "xyz", step 330, e.g. all word documents that have the expressions "access control" and "use cases" in their file name. The Change Tracker Client 26 retrieves those tasks from the versioning System 12, step 335, step 340, and displays the list of matching tasks in the user interface 226, step 345. Bob recognizes that he needs artifact abc as an input to perform task 123 and marks the artifact 123 as an input artifact for the task 123 in the user interface 226, step 350. The Change Tracker Client 26 calls the Change Tracker 24 to track the association of the artifact abc with the task 123 and the current task owner "Bob", step 355. The task owner can be considered as an optional parameter that is convenient for later usage as the owner of a revision task. The Change Tracker 24 stores the relationship of artifact abc to task 123 and the owner Bob, step 360. Bob continues his work and commits his changes to a new artifact jkl step 3651. The Change Tracker Client 26 commits the change to the Versioning System 12, step 370, and notifies the Change Tracker 24 of the change, step 375.

As the change tracker 24 has not stored the artifact jkl to be an input artifact of any task, the change does not trigger further actions, step 380. Bob completes task 123, step 385. The Change Tracker Client 26 changes the state for the task 123 in the Workf low Management System 12 to "complete", step 390.

-11 -igure 4 shows the flow of actions and interaction for user "Alice" working with the Change Tracker client 26 and causing a revision task to be automatically opened for the task of user Bob accomplished according to Figure 3.

Alice requests her task list, step 405. The Change Tracker Client 26 retrieves the tasks from the Workf low Management System 10, step 410 and displays the tasks in the user interface 226, step 415. Alice selects to work on task 124, step 420. The Change Tracker Client 26 changes the state for the task 124 in the Workf low Management System 10 to "working", step 425. Alice requests list of artifacts that contain the search string "xyz", step 430. The Change Tracker Client 26 retrieves those artifacts from the Versioning System 12, step 440, and displays the list of matching artifacts in the user interface 226, step 445. Alice performs some changes on artifact abc and commits those changes, step 450. The Change Tracker Client 26 commits the change to the Versioning System 12, step 455, and notifies the Change Tracker 24 of the change in the artifact abc, step 460. The Change Tracker 24 now recognizes that the artifact abc has been used as an input for task 123 and owner Bob, step 465. It retrieves the meta information of task 123 from the Workf low Management System 10, step 470, to determine the task name, step 475, and creates a revision task for it, step, 480, in form of a new task for user Bob that references the former task in the task name. This way Bob can recognize in the task name to which of his former activities the revision task relates.

In an alternative implementation of the invention, the Change Tracker 24 could obtain the information of artifact changes directly from the Versioning System 12. This requires the Versioning System to provide an interface that allows either listening on particular events related to artifact changes or regularly pulling information about changes. In this alternative -12 -implementation, the Change Tracker Client 26 only calls the ersioning System 12 when the user commits changes to an artifact. Various other implementation alternatives also exist.

Further modifications of the methods and systems according to embodiments of the invention may also be implemented. Instead of using the Change Tracker Client 26 component by the user, the Change Tracker server component 24 may notify the user directly, e.g via an E-mail, indicating that a revision task has been created or that a certain artifact has been changed.

Further, the Change Tracker Client 26 can track artifacts that have been opened or modified on the local client system of the user to automatically determine the set of necessary input artifacts for a given task.

Further, the Change Tracker Client 26 can automatically open the set of artifacts that has been modified for a specific task on the local client system if the user selects to work on this specific task, thus providing the user the necessary artifacts to complete the task automatically.

Further, the Change Tracker Client 26 can automatically track time usage histories for tasks and artifact modification, thus enabling business relevant analysis of working time and change frequencies for artifacts.

Further, the Change Tracker can additionally analyze the changed artifacts and open further tasks based on the result of the analysis -e.g. due to findings of a static code analysis or based on a rule set for particular change patterns that require certain additional steps.

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment -13 -containing both hardware and software elements. In a preferred Lithodiment, the invention is implemented in software, which inludes 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 (RAN), 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.

-14 -Input/output or I/O devices (including but not limited to eyboards, 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 the foregoing has been with reference to particular embodiments of the invention, it will be appreciated by those skilled in the art that changes in these embodiments may be made without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims. * *1

Claims

-15 -CLAIMS1. A method for developing software in a multi-user computing environment, the method comprising managing a plurality of development tasks in a workf low server system and distributing said development tasks between a plurality of workf low clients, each workf low client being associated with a respective software developer, each task having a task identifier and each task using a respective set of software artifacts as input; managing said software artifacts and a plurality of versions thereof in a versioning system, each software artifact having an artifact identifier, associating for each task the task identifier together with at least artifact identifiers of the respective set of software artifacts; in response to determining that a software artifact is changed in the versioning system, determining a set of those tasks that use the changed software artifact as input and generating corresponding revisioning tasks in order to notify that the set of tasks need to be revised due to changed input.
2. The method according to claim 1, comprising storing for each task information about the task owner and generating said revisionirig tasks for notifying task owners of the set of tasks that use said changed software artifacts.
3. The method according to claim 1 or 2, comprising the steps of: committing a change of a software artifact to said versioning system; and generating said revisioning tasks in response to committing said change of a software artifact.

-16 -
4. The method according to claim 3, further comprising the steps of: before committing a desired change of a software artifact, determining a set of tasks that use the changed software artifact as input; displaying said set of tasks to said user; receiving a user response telling whether said change is a desired; and if not desired, canceling said desired change.
5. An electronic data processing system for a multi-user computing environment including a workf low server system for managing a plurality of development tasks and distributing said development tasks between a plurality of workf low clients, each workf low client being associated with a respective software developer, each task having a task identifier and each task using a respective set of software artifacts as input; and a versioning system for managing said software artifacts and a plurality of versions thereof, each software artifact having an artifact identifier; said electronic data processing system comprising at least one component for associating for each task the task identifier together with at least artifact identifiers of the respective set of software artifacts, for determining that an artifact is changed in the versioning system, and for determining a set of tasks that use the changed software artifact as input and generating corresponding revisioning tasks in order to notify that the set of tasks needs to revised due to changed input.
6. The electronic data processing system of claim 5, wherein said at least one component includes a change tracker client and a change tracker, said change tracker client responsible for associating task identifiers together with I, ( -17 -artifact identifiers, f or determining that an artifact has changed and for triggering a change tracker to generate said revisioning tasks.
7. The electronic data processing system of claim 6, wherein said change tracker client provides a workf low system client functionality and a versioning system client functionality.
8. The electronic data processing system of claim 6 or 7, wherein said change tracker is one of the following: a component separate from said workf low system and said versioning system, a part of said workf low system, and a part of said versioning system.
9. A computer program product for a multi-user computing environment including a workf low server system for managing a plurality of development tasks and distributing said development tasks between a plurality of workf low clients, each workf low client being associated with a respective software developer, each task having a task identifier and each task using a respective set of software artifacts as input; and a versioning system for managing said software artifacts and a plurality of versions thereof, each software artifact having an artifact identifier; said computer program product comprising a computer useable medium having a computer readable program, wherein the computer readable program when executed on a computer causes the computer to associate for each task the task identifier together with at least artifact identifiers of the respective set Of software artifacts; determine that a software artifact is changed in the versioning system; and a * -18 -in response to determining that a software artifact is changed in the versioning system, determine a set of tasks that use the changed software artifact as input and generate corresponding revisioning tasks in order to notify that the set of tasks needs to be revised due to changed input.