JP3423098B2 - Software asset management method and system - Google Patents

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to software development using an information processing apparatus, and relates to a software asset management method and system that can be used by a plurality of developers.

[0002]

2. Description of the Related Art In software development using an information processing system such as a workstation, a plurality of developers (users) often jointly develop one piece of software. In such cases, it is important to develop efficiently while using the files created by other developers.

The original file is a software asset directly created by the developer, and indicates, for example, a source file or an include file. Further, the derived file is a provision generated from the original file, and indicates, for example, a load module or a library. The intermediate generated file is a software asset that is not directly created by the developer, but is automatically created from the original file via a utility program or the like. Specifically, it refers to dictionary files, index files of search tools, etc.,
It is used for software development work or is generated intermediately to create derivative files.

Nowadays, the number of software development tools and utilities that use intermediately generated files is increasing. Utilizing the function with such an intermediate generated file,
In an environment in which multiple developers develop software, it is desirable not only to manage the version number of original files and release management of derivative files, but also to efficiently use intermediate generated files.

[0005]

However, in the conventional asset management method, the original file and the intermediately generated file are managed separately, and there is a problem that these software assets are not sufficiently utilized by developers. is there. For example, even if the original file is stored in a location that can be shared by all developers, other developers cannot use the intermediate generated file because it is generated in the working environment of each developer.

Further, in order to update the original file, it is possible to place the original file and the intermediately generated file for each work environment, or to place them in a common place and perform the update. But,
In the former case, there is a problem that the intermediate generated file cannot be shared by the developers, and in the latter case, there is a problem that the original file in the state of being updated is shared and other developers are affected.

An object of the present invention is to provide a software asset management method and system that enables a plurality of developers to efficiently use software assets. More specifically, it is intended to allow multiple developers to share an intermediately generated file and update the original file without inconsistency.

[0008]

FIG. 1 is a principle diagram of a software asset management method according to the present invention. When the process is started in FIG. 1, first, a first software asset is created (step S1), and a second software asset is automatically generated from the first software asset (step S).
2). And those first software assets and second
And manage the software assets of
3) Letting a plurality of users commonly use (step S)
4).

The first software asset is, for example, an original file directly created by any of a plurality of users, and the second software asset is, for example, an intermediate file generated by the utility program from the original file. Is. Another of the present invention
Two Software Asset Management Methods Memorize Memorizing Information
And a process that uses the information stored in the memory.
In a system with a essa, multiple users share
This is a method of managing software developed by the same. Well
No, update target created by one of multiple users
Original file and utility program
By executing it, it will automatically generate from the original file.
Original as the file name of the generated intermediate file
Contains the file name associated with the
Intermediates containing information identifying utility programs
Store the file information and the generated file information in the memory. Next, the process
Server can refer to the intermediate file information in memory.
Launch the utility program identified by and
And have the above file name from the original file
Automatically generate the inter-generation file, the original file
For each of multiple users as a work area to update
Use the original file in the workspace provided.
Symlinks and intermediate files to use
Generate a symbolic link for use.

[0010]

The first software asset and the second software asset generated from the first software asset are associated with each other and managed. As a result, it is possible to search for the second software asset such as an intermediately generated file that accompanies the first software asset such as the original file that is directly created / updated by the user. Also, each user can easily use the first software asset and the second software asset in combination. Since a plurality of users use the common first software asset and second software asset, the second operation result of each user is reflected.
You can always refer to your software assets.

Furthermore, while one user is updating the first software asset in the work environment, another user can refer to the first and second software assets before the update.

[0012]

Embodiments of the present invention will now be described in detail with reference to the drawings. FIG. 2 shows the relationship between the storage, the project base, and the workspace in the asset management system of the present invention.

In FIG. 2, the storage is an original consisting of a group of files that can manage version numbers having all version numbers of all assets of the entire program, and a file group that stores management information such as configuration information and release information. A file tree of files. On the storage, the version number of each file is managed by difference management, for example.

In addition, the project base is composed of an original file obtained by extracting the assets of the entire program from a storage at a level at the latest time or a specific time point in the past (for example, a certain month in the past) and an intermediate generation file generated from them. It is a file tree. Each intermediately generated file is associated with the original file at the time of its generation by the extension of the file name or the like. This project base is an environment shared by each developer's workspace.

The workspace is a file tree having the same directory structure as a part of the project base and sharing files on the project base by using symbolic links. Each developer updates the original file on each workspace. Whereas the project base has the entities of the original file and intermediate files, the workspace has a tree of symbolic links to those entities.

For example, the developer A symbolically links the three original files in the latest project base and the one intermediate generated file related to the three original files in his workspace, and performs the work related thereto. Further, the developer B is working by symbolically linking the five original files in the latest project base and the three intermediately generated files related thereto into his workspace.

The asset management system shown in FIG. 2 is realized by using an information processing apparatus including a processor such as a workstation and a memory. The vault, project base, and workspace are stored in different areas of memory. Further, the processor executes various programs such as software asset registration processing, update start processing, update processing, and update completion processing by executing the program of the asset management system.

Next, referring to FIGS. 3 to 8,
Various processes by the asset management system of the present embodiment will be described. FIG. 3 shows state transitions of files in the storage, project base, and workspace at the time of asset registration, and FIG. 4 shows a flow of asset registration processing.

When the process is started in FIG. 4, first, an original file to be registered by the developer is created on the workspace (step S11). In Figure 3, Developer A
Creates an original file such as a source file on the workspace.

Next, the original file created by the asset management system is registered in the storage (step S1).
2). When registering an original file that involves the update of an intermediate generated file, the name of the related intermediate generated file (intermediate generated file name), the utility that creates the intermediate generated file, and the registered original file when the original file is updated The intermediate generation file information such as whether or not the intermediate generation file is locked in is also registered. Then, the information of the original file and the intermediately generated file is stored in the storage (step S1).
3). In this case, the original file is stored as the first version.

Next, the original file stored in the storage is taken out to the project base (step S1).
4). If there is an intermediate generation file to be updated, the utility is started based on the procedure registered on the project base, and the intermediate generation file is generated from the original file (step S15). Here, the intermediate generation file information to be updated and the utility to be started are specified by referring to the intermediate generation file information stored together with the original file.

Next, the workspace of the developer who registered the original file is updated (step S16). Specifically, a symbolic link is created between the original file on the project base and the related intermediate generated file and the developer's workspace. here,
Developer A's workspace holds a symbolic link to the project base.

Also, the workspaces of other developers having the configuration including the registered original file are updated (step S17), and the process is terminated. To update another developer's workspace, add symbolic links for the original and intermediate files to the other developer's workspace. Here, for example, a symbolic link to the project base is added to the workspace of the developer B.

In this way, not only the original file but also the intermediately generated file can be placed on the project base and shared by the symbolic links from the workspaces of a plurality of developers. FIG. 5 shows state transitions of files in the storage, project base, and workspace when updating an original file having a related intermediate generation file. Further, FIGS. 6, 7, and 8 show the flow of the update start process, update process, and update completion process of the original file, respectively.

When the processing is started in FIG. 6, the asset management system first cuts (deletes) the symbolic link of the original file to be updated in the workspace of the developer (updater) who updates. Then, the original file is checked out (updated) from the storage (step S21).

Next, the deleted symbolic link on the updater's workspace is replaced with the actual file of the original file retrieved from the storage (step S).
22). In FIG. 5, at this point, one original file on the workspace of the developer B is replaced by the symbolic link ◯ with the entity .

Further, if the intermediately generated files (symbolic links) associated with this original file exist in the workspace of the updater, the symbolic links are cut to all of these intermediately generated files.
Then, in the updater's workspace, the symbolic link of the deleted intermediate generated file is replaced with the corresponding real file on the project base (step S
23).

This enables the updater to update the original file and the intermediate file in the environment closed in the workspace. Also, during this period, other developers can use the intermediate generation file on the project base and never refer to the intermediate generation file that is being updated.

In this case, the two intermediately generated files on the workspace of the developer B are related to the original file to be updated, and these are replaced by the substance ▲ from the symbolic link Δ.

The exclusive process of access to the original file to be updated and the intermediate generation file related thereto is performed according to the intermediate generation file information at the time of registration. When the intermediate generation file is exclusive, all the original files having the intermediate generation file cannot be updated during this period. If the intermediate generated file is not exclusive, only the original file to be updated cannot be updated. Whether or not the intermediate generation file is locked is selected at the time of registration, in consideration of the nature of the intermediate generation file, the characteristics of the utility program that generated it, and the like.

Specifically, first, the original file to be updated is excluded (step S24). This makes it impossible for other developers to update the original file, but it is still possible to refer to the original file and the intermediate generated file on the project base with a symbolic link.

Next, referring to the intermediate generation file information registered in the storage, it is determined whether or not exclusion at the intermediate generation file level is performed (step S25). If there is no exclusion at the intermediate generation file level, end the process as it is,
If the intermediate generation file level is exclusive, other original files having the intermediate generation file associated therewith are not updated (step S26), and the process ends.
In the case of exclusive there intermediates file level, other developers can refer to the original file and the intermediate files in the project based symbolic links.

The exclusion process of the original file and the intermediately generated file can be realized by, for example, providing a flag indicating the exclusion / non-exclusion of each file (whether updating is possible or not) in association with the file.

When the update start process is completed, the updater executes the process shown in FIG.
Update process. When the process is started in FIG. 7,
First, the substance of the original file on the updater's workspace is updated (step S31). Then, the corresponding intermediate generation file information of the original file is referenced to find the corresponding utility, the utility is activated in the workspace, and the substance of the intermediate generation file in the workspace is updated (step S31). Here, the developer B, who is the updater, updates the original file ● on the workspace and further updates the intermediate generation file ▲ by using the utility.

After the update of the original file and the intermediate file is completed and it is confirmed on the workspace that the correction contents are correct, the updater activates the update completion process of FIG.

When the processing is started in FIG. 8, the asset management system first checks in (registers) the difference generated by the correction (update) of the original file in the storage (step S41). Next, the latest original file including the checked-in difference is taken out from the storage and the original file on the project base is updated (step S42). This will also bring the original files up-to-date on other developers' workspaces that are symbolically linked to the project base.

Then, the utility used in step S31 is started on the project base to update the intermediate generated file on the project base (step S
43). This will also bring the intermediate files up-to-date on other developers' workspaces that are symbolically linked to the project base.

At this point, other developers using the project base by using the symbolic link can refer to the latest original file and the intermediately generated file. The update information on the project base is
It is transmitted to the workspace of another developer by interprocess communication such as message communication. Here, the developer A different from the developer B refers to the latest original file updated by the developer B and the latest intermediate generation file updated based on the latest original file.

Next, the original file and the intermediately generated file on the updater's workspace are re-symbolized to restore the updater's workspace to the symbolic link state (step S44). This allows the updater himself to continue working by using the latest original file and intermediate generation file. Here, the symbolic link that has been deleted on the workspace of the developer B is added again.

When a plurality of original files are updated at the same time, in the update start process, the union of all the intermediately generated files related to those original files is set as a non-shared object on the workspace. That is,
In the updater's workspace, the update processing is performed by cutting the symbolic links of all the intermediate generated files related to the plurality of original files to be updated.

Further, when a plurality of original files are updated and only a part of them is corrected, the update completion processing relates only to the corrected original files and to the original files which are still in the process of being corrected. Restore only the intermediate files that have not been created. That is, the original file that has been updated is registered in the storage, only the intermediate generated files that are not likely to be updated any more are generated by the utility, and these are reflected in the project base.

As described above, in the present embodiment, the original file and the intermediate generated file are associated with each other and the intermediate generated file is created on the project base, thereby realizing the sharing of the intermediate generated file by a plurality of developers. There is. In addition, by switching between shared and non-shared in the workspace in synchronization with the update timing of the original file, a consistent update of the intermediate generated file is realized.

In the embodiment described above, the project-based file is associated with the workspace of the developer by the symbolic link, but the present invention can be applied to the system having no symbolic link. In that case, by copying the original file and intermediate generation file on the project base onto the workspace of each developer, these files can be shared. The updater updates the original file in his workspace, and the asset management system notifies the other developers that it needs to be copied again after reflecting the result in the vault and the project base. When the recopy is performed, the latest original file and the intermediate generated file can be shared (refresh).

[0044]

According to the present invention, efficient use of software assets is promoted in an environment in which a plurality of developers develop software. More specifically, not only the software assets created directly by each developer but also the software assets automatically generated by a utility or the like can be shared. In addition, shared software assets can be updated without contradiction.

[Brief description of drawings]

FIG. 1 is a principle diagram of the present invention.

[Fig. 2] Storage cabinet, project base, in the embodiment
It is a figure which shows the relationship of workspace.

FIG. 3 is a diagram showing file transitions during registration.

FIG. 4 is a flowchart of registration processing.

FIG. 5 is a diagram showing transition of files at the time of updating.

FIG. 6 is a flowchart of update start processing.

FIG. 7 is a flowchart of update processing.

FIG. 8 is a flowchart of update completion processing.

─────────────────────────────────────────────────── ─── Continuation of the front page (56) Reference JP-A-6-274331 (JP, A) JP-A-6-28164 (JP, A) JP-A-5-216636 (JP, A) JP-A-5- 113877 (JP, A) Toshishige Shigeshi et al., Program development environment and asset protection, Toshiba Review, Toshiba Corporation, October 1, 1994, Volume 49, No. 10, p. 717-721 Matsuno Yoshino and 2 others, Application development support in distributed computing environment, Hitachi Review, Hitachi Review, June 1, 1994, Vol. 76, No. 6, p. 47-50 Toshiyuki Moriya et al., 1 file support system for collaborative work in large-scale software development, IEICE Technical Report SSE94-81-90 Exchange System, The Institute of Electronics, Information and Communication Engineers , July 22, 1994, Vol. 94, No. 168, p. 43-48 (58) Fields investigated (Int.Cl. ⁷ , DB name) G06F 9/44 G06F 9/06

Claims (2)

(57) [Claims] 1. A memory for storing information and a memory for storing the information.
And a processor that performs processing using the stored information
A software that is jointly developed by multiple users in the system.
Software asset management method for managing software
The update target created by one of the users
Original file and utility program
Automatically from the original file by executing
The file name of the generated intermediate
Contains the file name associated with the
Including information for identifying the utility program
Intermediate generation file information is stored in the memory, and the processor stores the intermediate generation file in the memory.
Utility identified by referring to the file information
Start the program and start from the original file
The intermediate generation file having the file name is automatically generated, and the processor updates the original file.
A work area is provided for each of the plurality of users.
Use the original file in the created workspace
Symbolic link and the intermediate file
A software asset management method characterized by generating a symbolic link for use of . 2. Software developed jointly by a plurality of users
Is a software asset management system that manages
The update target created by one of the users
Original file and utility program
Automatically from the original file by executing
The file name of the generated intermediate
Contains the file name associated with the
Including information for identifying the utility program
It is specified by referring to the means for storing the intermediate generation file information and the intermediate generation file information.
Start the utility program that is
The intermediate generation with the file name from the null file
Means for automatically generating a file, the as a work area for updating the original file
Workspace provided for each of multiple users
To, symbolic of the order to use the original file
Link for using the link and the intermediate file.
And a means for generating a symbolic link .