JP2014157598A - Software asset management device, software asset management method, and software asset management program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To appropriately extract an information node even in a case where a relational link between information nodes disposed in blocks compartmentalized by a degree of abstraction and that of granularity is inadequate.SOLUTION: An information retention part 8 places, in a block compartmentalized by a degree of abstraction and that of granularity, an information node that is an individual information unit constituting a software asset, and retains an asset management matrix set by a relational link that is a directional link indicating relationship between individual links. An information input part 5 receives inputs of start-point information related to a search start point and end-point information related to a search end point. An information search part 6 calculates one or more search path from the information node derived on the basis of the start-point information to an information node derived on the basis of the end-point information by tracking the relational link in a forward direction or reverse direction and the relational link in an axial direction of the degree of abstraction and that of granularity.

Description

  The present invention relates to a software asset management device, a software asset management method, and a software asset management program.

  When an organization such as a company operates an IT system over a long period of time, it is common to expand or modify the system according to the purpose of the company activity. As a result, a situation where various old and new software and hardware are mixed can occur. Under such circumstances, it is difficult to grasp the IT system, and as a result, system expansion or the like has become difficult. Due to the difficulty of system expansion, there may occur a situation where it is not possible to quickly make an optimal system change in accordance with business changes. This has led to the problem of losing business opportunities.

  The above-mentioned problem of difficulty in extending the IT system is considered to be caused in detail by the following three main problems.

  First, the relationship between the business processing (business process) implemented in the IT system and the IT system implementation is not necessarily clearly written (documented). In other words, the relationship between business processes and IT system implementation is often formed as tacit knowledge. Therefore, there is a problem that when the system is renewed, the time required for the designer to specify the correction range becomes very long.

  Secondly, there are cases where the design specification (design document) of the IT system does not match the actual implementation of the IT system, or the design specification itself does not exist. In such a case, the designer (or developer) needs to decipher the program source code that constitutes the IT system to specify the affected range, and there is a problem that it takes a lot of time and money.

  Third, even if the IT system has been successfully renewed, the documents obtained in the process may not be properly managed. More specifically, there are cases where documents obtained when the IT system is renewed are not managed in a reusable (or maintainable) state. As a result, there is a problem that it is difficult to renew the IT system again.

  In view of the various problems described above, tools for managing software assets (for example, development environment tools and BPM (Business Process Management) tools) are used. However, these tools generally manage only source code or only manage document files for specific users. In other words, software assets (design specifications, source programs, test scripts, etc.) of the entire IT system are not handled in an integrated manner. As a result, software assets could not be used effectively.

  Patent Document 1 discloses a reuse system mainly for software source code.

JP 2009-276911 A

  As described above, the commonly used tools do not handle the software assets of the entire IT system in an integrated manner. Therefore, it is desirable to use a repository that manages software assets in an integrated manner. This repository is a storage device that accumulates user input regarding software assets. The repository stores information nodes indicating individual information units constituting each software asset, relationship links that define relationships between information nodes, and the like. These information nodes are appropriately arranged in blocks divided according to abstraction or detail.

  The user inputs information nodes and relationship links to the repository via the system. Specifically, the user inputs information nodes and related links one by one using an input means such as a mouse or a keyboard. However, this input method may cause a setting error of the related link. As a result, there is a problem that it is impossible to follow the relational link, and it is impossible to acquire information of various information nodes between a certain information node and a target information node.

  The present invention has been made in view of the above-described problems, and even when information links between information nodes arranged in blocks divided according to abstraction or detail are insufficient, information nodes can be appropriately displayed. The main object is to provide a software asset management device, a software asset management method, and a software asset management program that can be extracted.

One aspect of the software asset management device according to the present invention is:
Information blocks, which are individual information units that make up software assets, are placed in blocks that are classified according to abstraction and detail, and an asset management matrix is set in which the relationship between each information node is set by relationship links An information holding unit;
An information input unit that receives input of start point information related to a search start point in the asset management matrix and end point information related to a search end point;
Tracing one or more search paths from the information node derived on the basis of the start point information to the information node derived on the basis of the end point information, in the forward or reverse direction, and the relationship An information search unit that calculates a link by following the abstraction axis direction and the detail axis direction;
Is provided.

One aspect of the software asset management method according to the present invention is:
Information blocks, which are individual information units that make up software assets, are placed in blocks divided according to abstraction and detail, and set with relational links, which are directed links that indicate the relationships between information nodes. A search method for a repository that holds an asset management matrix,
An information input step for receiving input of start point information related to the search start point and end point information related to the search end point;
Tracing one or more search paths from the information node derived on the basis of the start point information to the information node derived on the basis of the end point information, in the forward or reverse direction, and the relationship An information search step for calculating by tracing the link in the direction of abstraction axis and the degree of detail axis;
Is to execute.

One aspect of the software asset management program according to the present invention is:
Information blocks, which are individual information units that make up software assets, are placed in blocks divided according to abstraction and detail, and set with relational links, which are directed links that indicate the relationships between information nodes. A program that executes a search for a repository that holds an asset management matrix,
On the computer,
An information input step for receiving input of start point information related to the search start point and end point information related to the search end point;
Tracing one or more search paths from the information node derived on the basis of the start point information to the information node derived on the basis of the end point information, in the forward or reverse direction, and the relationship An information search step for calculating by tracing the link in the direction of abstraction axis and the degree of detail axis;
Is to execute.

  In the present invention, a software asset management apparatus and software capable of appropriately extracting information nodes even when the relationship links between information nodes arranged in blocks divided according to abstraction or detail are insufficient An asset management method and a software asset management program can be provided.

1 is a block diagram showing a configuration of a software asset management apparatus 1 according to a first embodiment. It is a conceptual diagram which shows the matrix which the software asset management apparatus 1 concerning Embodiment 1 assumes. FIG. 3 is a conceptual diagram showing a table configuration of a repository 7 according to the first embodiment. FIG. 3 is a diagram illustrating a matrix according to the first embodiment. It is a figure which shows the table structure holding the relationship link concerning Embodiment 1. FIG. It is a figure which shows the matrix in which two relationship links of the equality relationship and detailed relationship concerning Embodiment 1 are contained. It is a figure which shows the matrix in which two relationship links of the equality relationship and detailed relationship concerning Embodiment 1 are contained. It is a figure which shows the matrix in which two relationship links of the equality relationship and detailed relationship concerning Embodiment 1 are contained. It is a figure which shows the matrix containing the relationship link of the actualization relationship concerning Embodiment 1. FIG. 3 is a matrix showing software assets to be managed according to the first embodiment; 3 is a matrix showing software assets to be managed according to the first embodiment; 3 is a matrix showing software assets to be managed according to the first embodiment; 3 is a matrix showing software assets to be managed according to the first embodiment; 3 is a matrix showing software assets to be managed according to the first embodiment; 3 is a matrix showing software assets to be managed according to the first embodiment; 3 is a matrix showing software assets to be managed according to the first embodiment; It is a figure which shows a mode that the information node is registered into the repository 7 concerning Embodiment 1. FIG. It is a figure which shows an example of the table structure for implement | achieving the correlation of the information node and keyword concerning Embodiment 1 concretely. It is a figure which shows the example of the search path | route between the blocks concerning Embodiment 1. FIG. It is a figure which shows the example of the search path | route between the blocks concerning Embodiment 1. FIG. It is a figure which shows the example of the search path | route between the blocks concerning Embodiment 1. FIG. 4 is a flowchart showing a flow of search processing by the information search unit 6 according to the first exemplary embodiment. 4 is a flowchart showing a flow of search processing by the information search unit 6 according to the first exemplary embodiment. It is a conceptual diagram which shows the link relationship of the block used as a current block and a target block. FIG. 3 is a conceptual diagram showing search processing by the information search unit 6 according to the first exemplary embodiment. FIG. 3 is a conceptual diagram showing search processing by the information search unit 6 according to the first exemplary embodiment. FIG. 3 is a conceptual diagram showing search processing by the information search unit 6 according to the first exemplary embodiment. FIG. 3 is a conceptual diagram showing search processing by the information search unit 6 according to the first exemplary embodiment. FIG. 3 is a conceptual diagram showing search processing by the information search unit 6 according to the first exemplary embodiment. FIG. 3 is a conceptual diagram showing search processing by the information search unit 6 according to the first exemplary embodiment. FIG. 3 is a conceptual diagram showing search processing by the information search unit 6 according to the first exemplary embodiment. FIG. 3 is a conceptual diagram showing search processing by the information search unit 6 according to the first exemplary embodiment. FIG. 3 is a conceptual diagram showing search processing by the information search unit 6 according to the first exemplary embodiment. It is a block diagram which shows the structure of the software asset management apparatus 1 concerning Embodiment 2. FIG. 10 is a flowchart showing a flow of search processing by the information search unit 6 according to the second exemplary embodiment. It is a conceptual diagram which shows the priority setting using the overlap degree of the search path | route concerning Embodiment 2. FIG. It is a conceptual diagram which shows the priority setting using the overlap degree of the search path | route concerning Embodiment 2. FIG. It is a conceptual diagram which shows the priority setting using the overlap degree of the search path | route concerning Embodiment 2. FIG. It is a conceptual diagram which shows the priority setting using the overlap degree of the search path | route concerning Embodiment 2. FIG. It is a conceptual diagram which shows the priority setting using the overlap degree of the search path | route concerning Embodiment 2. FIG. It is a conceptual diagram which shows the priority setting using the overlap degree of the search path | route concerning Embodiment 2. FIG. It is a figure which shows the weight information of the related link concerning Embodiment 2. FIG. It is a conceptual diagram which shows the priority setting of each search path | route according to the keyword concerning Embodiment 2. FIG. It is a conceptual diagram which shows the priority setting of each search path | route according to the keyword concerning Embodiment 2. FIG. It is a conceptual diagram which shows the priority setting of each search path | route according to the keyword concerning Embodiment 2. FIG. FIG. 10 is a block diagram showing a configuration of a software asset management apparatus 1 according to a third embodiment. FIG. 10 is a diagram illustrating a detailed configuration example of a usage history holding unit 11 and a change history holding unit 12 according to the third embodiment. FIG. 10 is a diagram illustrating a detailed configuration example of a usage history holding unit 11 and a change history holding unit 12 according to the third embodiment. 10 is a flowchart showing a flow of processing of the information search unit 6 according to the third exemplary embodiment. 10 is a flowchart showing a flow of processing of the information search unit 6 according to the third exemplary embodiment. 10 is a flowchart showing a flow of processing of the information search unit 6 according to the third exemplary embodiment. 10 is a flowchart showing a flow of processing of the information search unit 6 according to the third exemplary embodiment. 10 is a flowchart showing a flow of processing of the information search unit 6 according to the third exemplary embodiment. 10 is a flowchart showing a flow of processing of the information search unit 6 according to the third exemplary embodiment. It is a figure which shows the search path | route of the information search part 6 concerning Embodiment 3. FIG. It is a figure which shows the search path | route of the information search part 6 concerning Embodiment 3. FIG. It is a figure which shows the search path | route of the information search part 6 concerning Embodiment 3. FIG. It is a figure which shows the search path | route of the information search part 6 concerning Embodiment 3. FIG. It is a block diagram which shows the hardware constitutions of the software asset management apparatus 1 concerning this invention.

<Embodiment 1>
Embodiments of the present invention will be described below with reference to the drawings. First, an information system handled by the software asset management apparatus 1 according to the present embodiment will be described. In order to construct and operate these information systems, various information, for example, information that defines the content of the business that the information system is used (business definition information), system design information, source code, test specification information, operation Specification information is required. These pieces of information are generally called software assets. Software assets may or may not be documented inside a company or the like that performs the business.

  Next, the configuration of the software asset management apparatus according to the present embodiment will be described with reference to FIG. The software asset management apparatus 1 includes a processing unit 4 and a repository 7. The software asset management device 1 is connected to the input device 2 and the output device 3. The processing unit 4 includes an information input unit 5 and an information search unit 6. The repository 7 has an information holding unit 8.

  The software asset management device 1 is a so-called server device, and is connected to the input device 2 and the output device 3 via the Internet.

  The input device 2 is a device for inputting various data such as an information node described later to the repository 7 via the processing unit 4. The input device 2 may be a computer including a keyboard, a mouse, and the like, for example. The output device 3 is a device that displays a search route of the information search unit 6 described later, and is, for example, various output devices such as a computer device and a printer device connected to a liquid crystal display device.

  The information input unit 5 receives an input from the input device 2 and operates as an interface for registering data in the information holding unit 8. The information input unit 5 is a processing unit having a capability such as packet processing via the Internet, for example. Search conditions are input to the information search unit 6 via the input device 2 and the information input unit 5. The information search unit 6 searches the repository 7 using the input search conditions.

  The repository 7 is a logical storage unit provided in a storage medium (not shown) included in the software asset management apparatus 1. Actually, the information holding unit 8 stores various data. Details of the repository 7 will be described below with reference to FIGS. 2-1 to 2-9.

  As described above, a software asset is a collection of various pieces of information. Individual information units constituting these software assets are called information nodes. For example, an information node is a unit of information constituting business definition information, system design information, source code, test specification information, operation specification information, and the like. When documented software assets exist, all or part of the document data is an information node entity. On the other hand, for information that is not documented, it is possible to create a so-called empty information node that has no entity such as document data. For example, even if there is no document describing the A function, if the information system requires the A function, the user can create an information node related to the A function and store it in the repository 7.

  The repository 7 stores each of these information nodes after classification according to two evaluation criteria of “abstract level” and “detail level”. The “abstract level” and “detail level” are each provided with a plurality of levels. Information nodes are assigned to any of these multiple levels. That is, the repository assigns and stores information nodes at any position on the matrix defined by the two axes of “abstract level” and “detail level”.

  FIG. 2A illustrates a matrix assumed in the present embodiment. In this example, the vertical axis of the matrix indicates “abstraction” and the horizontal axis indicates “detail”. The “abstract level” and “detail level” increase as the distance from the origin increases. That is, an information node including more abstract or detailed contents is stored at a position further away from the origin. In the present embodiment, the level of “abstract level” and “detail level” is identified by a level number. That is, the level with the smallest “abstraction” and “detail” is called level number “1”. Hereinafter, as the “abstract level” and “detail level” increase, the level numbers “2”, “3”,.

  Note that the vertical and horizontal sizes (number of levels) of the matrix are not fixed, and can be set freely by the user according to the size and complexity of the software assets to be managed.

  The position on the matrix to which the information node is assigned is called a block. In the present embodiment, each block is specified by a set of two numbers in the format of “abstraction level number-detail level level number”. For example, in FIG. 2A, the block to which the information node X is assigned is “1-2”.

  Here, the significance of “abstraction” and “detail” will be described. The “abstraction level” is a scale for classifying information nodes according to the strength of dependency between information contents and system implementation. For example, when the five types of information nodes of business definition information, system design information, source code, test specification information, and operation specification information are classified into five levels of abstraction levels 1 to 5, the dependency on the implementation is the lowest. The business definition information is assigned to the highest abstraction level (abstraction level = 5). Thereafter, in order of increasing dependency on the implementation, abstraction level = 4 for system design information, abstraction level = 3 for source code, abstraction level = 2 for test specification information, and abstraction for operation specification information. Assign a degree level = 1.

  The “detail level” is a scale for classifying information nodes according to the level of design detail. For example, as shown in FIG. 2-3, as system design information, a function description in which the outline of the AA function is described in natural language, and a data relation diagram in which data transition in the AA function is described in, for example, a DFD (Data Flow Diagram). When assigning the two types of information nodes to the two levels of detail levels 1 and 2, the data relation diagram having the highest design detail is assigned to the highest detail level (detail level = 2). On the other hand, a detail level = 1 is assigned to a function description having a relatively low design detail.

  In the repository 7, although the level of detail is different, the same level of abstraction is assigned to information nodes having the same level of abstraction, and the same level of detail is assigned to information nodes having different levels of abstraction. Is preferably assigned.

  FIG. 2-2 shows an example of a table structure for concretely realizing the repository 7. The software asset management apparatus 1 can include, for example, an information holding unit 8 having the above table structure in a storage area on a storage medium (not shown). The information holding unit 8 stores an information name for identifying an information node stored in the repository 7, a block indicating the position of the information node, and an actual storage location of the information node entity (information entity, for example, document data). It is possible to hold a plurality of records having at least the location of the information entity indicated. In the present embodiment, the entity of the information node is stored in an arbitrary storage location outside the information holding unit 8. The entity of the information node may be held in the record of the information holding unit 8.

  The repository 7 can hold information regarding the relationship between individual information nodes. This relationship is called a relationship link. The relational link can be set between a certain information node and another information node existing in the same block as the information node, a block having a different abstraction level, and a block having a different detail level only.

  In the present embodiment, at least the following four types of relational links can be set. This type is also called a link attribute. The equality relationship is a relationship link that associates information nodes that represent the same object or event based on different purposes or viewpoints. The subordinate relationship is a relational link that associates an information node that is a certain superordinate concept with an information node that is a subordinate concept or component of the information node. The refinement relationship is a relationship link that associates a certain information node with an information node that is a more detailed information node. The materialization relationship is a relationship link that associates an information node that represents an abstract concept with an information node that further materializes the information node. In addition to the above, an arbitrary relation link can be set in order to express the relevance of data between information nodes, the processing order, and the like. As described above, the relational link is a link that can connect information nodes with directionality (directed link. However, in the case of a relationship of equality, the directionality may be unnecessary).

  Note that the refinement relationship may be set between information nodes having different detail levels, or may be set between information nodes having the same detail level. The materialization relationship may be set between information nodes having different abstraction levels, or may be set between information nodes having the same abstraction level. In addition, it is preferable that the repository 7 holds a flag indicating whether the detailed relationship or the specific relationship is across the detail level or the abstract level.

  FIG. 2-3 shows an organization structure and a business structure of a virtual company using two relationship links of a subordinate relationship and “related”. Here, it is assumed that “related” is a relational link indicating input / output information related to a certain business. This figure shows the following facts: This company has software assets (eg, documented manuals) related to “business flow”. This “business flow” includes a business flow related to the “sales department”. The business flow of the “sales department” is composed of three tasks, “order received”, “inventory check”, and “shipment instruction”. The input / output information in each business is “Order Form”, “Manufacturing Instruction”, and “Shipping Instruction”.

  2-4 is an example of a table structure for specifically realizing the relational link of FIG. 2-3. The information holding unit 8 in FIG. 2-4 has “outgoing link” and “incoming link” elements. Here, “outgoing link” specifies a related link starting from the information node by a number defined in a link table (described later). The “incoming link” specifies a related link whose end point is the information node by a number defined in a link table (described later).

  The outgoing link and incoming link elements are not essential elements in the configuration of the information holding unit 8. The element overlaps with an element included in a link table, which will be described later, and can be acquired by searching the link table with the information node number. However, in actual operation, as the amount of information registered in the repository 7 increases, the link table search time increases, and it is expected that the performance of the entire processing unit 4 will be greatly affected. Therefore, it is effective to have the outgoing link and incoming link elements directly in the information holding table as a means for speeding up.

  The link table is a table for defining and storing relational links established between a plurality of information nodes. The link table has at least one record having at least a number, an attribute, start point information, and end point information as elements. The number is an identifier for uniquely identifying the related link. The attribute indicates the type of relationship link. In the start point information, the information node that is the start point of the related link is specified by the number defined by the information holding unit 8. In the end point information, the information node that is the end point of the related link is specified by the number defined by the information holding unit 8.

  Fig. 2-5 (Fig. 2-5-1 to Fig. 2-5-3) shows the organizational structure and business structure of a certain virtual company using two relational links: a equality relation and a refinement relation. Is. Lines with arrows at both ends indicate equality. The equality relationship is set between information nodes having essentially the same meaning content in the same block. A line with an arrow on one side indicates a refinement relationship. In this example, the refinement relationship is set between information nodes located in blocks having different refinement levels.

  FIG. 2-6 shows an organization structure and a business structure of a virtual company using a relational link of materialization relations. One line with an arrow indicates a materialization relationship. In this example, the materialization relationship is set between information nodes located in blocks having different abstraction levels.

  FIG. 2-7 (FIGS. 2-7-1 to 2-7-7) shows an example in which the entire software asset related to the organizational structure and business structure of a certain virtual company is registered in the repository 7. FIG. 2-3, FIG. 2-5 (FIG. 2-5-1 to FIG. 2-5-3), and FIG. 2-6 described above are a part of this figure.

  Next, a search path between blocks by the information search unit 6 will be described with reference to FIGS. 3-1 to 3-3. Here, the search refers to a process of calculating a route from a specified block (or information node) to a specified block (or information node).

  FIG. 3A is a diagram illustrating a search route when a block of abstraction level 2 / detail level 1 is designated as start point information and a block of abstraction level 2 / detail level 5 is designated as end point information. FIGS. 3-2 and 3-3 are diagrams illustrating search paths when a block of abstraction level 2 / detail level 2 is designated as start point information and a block of abstraction level 1 / detail level 3 is designated as end point information. . As shown in FIGS. 3-2 and 3-3, a plurality of search paths may be calculated.

  A specific use example of the search process will be described. In the following explanation, it is assumed that the repository 7 has already registered information nodes and related links of an information system in operation. Assume that a function is added to a specific subsystem of the system. In this case, consider the case where you want to examine the scope of influence of the change in the subsystem.

  The user designates a block in which the external specification of the subsystem is stored as search starting point information via the input device 2, and designates a block in which the subsystem implementation program is stored as end point information. The information search unit 6 calculates a search route connecting the start point block and the end point block. The user refers to the information node included in the search route to check the influence range associated with the change of the subsystem. Hereinafter, a specific flow of search processing will be described with reference to the flowcharts of FIGS. 4-1 and 4-2.

  The information search unit 6 receives start point information, end point information, and the like via the input device 2 and the information input unit 5 (S1). For example, the user inputs a block serving as a start point and a block serving as an end point from a matrix-like user interface illustrated in FIG.

  The information search unit 6 calculates a search path that connects the shortest blocks from the start block to the end block (S2). In the case of FIG. 3A, the information search unit 6 calculates one search route. In the case of FIGS. 3-2 and 3-3, the information search unit 6 calculates two search paths. At this time, the information search unit 6 calculates the shortest search route regardless of whether there is an information node in the block or whether the blocks are connected by a related link.

  Subsequently, the information search unit 6 sets a search path between blocks to be used in the subsequent processing (S3). For example, when there is one calculated search route as shown in FIG. 3A, the information search unit 6 sets the search route. When there are two calculated search routes as shown in FIGS. 3-2 and 3-3, the information search unit 6 selects and sets one from the search route group.

  The information search unit 6 determines an information node as a starting point from the starting point block of the selected search route (S4). For example, the information search unit 6 performs the determination process by comparing the keyword input via the input device 2 with the attributes and keywords of each information node.

  The information search unit 6 sets the block being processed (the block at the current position) in the selected search path as the current block, and sets blocks around the current block as target blocks (S5). When the detour in S12 described later has not been performed once, the information search unit 6 sets the next block connected from the current block as the current block. When detouring is being performed, the information search unit 6 sets a block in the direction opposite to the detouring direction or a block in a direction approaching the end point block as the target block. The information search unit 6 extracts all the forward paths from the current node (information node to be processed) in the selected current block to the target block (S6). The information search unit 6 holds all the information on the related links on the route extracted in S6. FIG. 5 is a conceptual diagram showing the link relationship between the current block and the block that becomes the target block.

  The information search unit 6 determines whether one or more routes extracted in S6 exist (that is, whether the current node and the target node are connected by one or more forward relation links) (S7). When the number of extracted routes is 0, the information search unit 6 extracts all routes to the target block including the case where the related link is traced in the reverse direction (S8). When there is a forward or reverse route (S7: Yes, S9: Yes), the information search unit 6 continues the process up to the end point block (S14).

  When neither the forward search path nor the reverse search path exists (S9: No), there is no related link to the target block. In this case, when there are a plurality of search routes connecting the blocks extracted in S2 described above (S10: Yes), the information search unit 6 sets a search route that is not set as a search target as a processing target. The process is redone (S11).

  When there is only one search route connecting the blocks extracted in S2 described above or when there is no search route that has not been processed (S10: No), the information search unit 6 performs a vertical direction (abstraction degree axis direction) from the current block. ) Is set to the target block (S12). And the information search part 6 recalculates a path | route from the target block set in S11 (S13).

  The information search unit 6 performs the above-described processes of S5 to S13 until the end point block is reached (S14). When the end point block is reached (S14: Yes), the information search unit 6 outputs a search route from the detected start point to the end point (S15).

  Hereinafter, the operation shown in the flowchart will be described with reference to specific examples (FIGS. 6-1 to 6-9). FIG. 6A is assumed to be actual data registered in the repository 7. In this case, the search by the information search unit 6 when the block of abstraction level 2 / detail level 1 is set as the start point block and the block of abstraction level 2 / detail level 5 is set as the end point block will be described.

  FIG. 6B is a diagram illustrating the shortest inter-block search path in S2 described above. The information search unit 6 calculates a search route that linearly connects the blocks of abstraction level 2 / detail level 1 to the blocks of abstraction level 2 / detail level 5 as shown in the figure. In FIG. 6B and subsequent figures, for the sake of convenience, the number of block passages when the starting point block is 1 is also displayed. In this case, since there is only one shortest search route, the information search unit 6 sets the search route shown in FIG. 6-2 as it is in S3 described above.

  FIG. 6C is a diagram illustrating search processing when the current block is a block of abstraction level 2 / detail level 2. As illustrated in FIG. 6A, no related link is set in the abstract level 2 / detail level 2 block and the abstract level 2 / detail level 3 block. Therefore, the information search unit 6 determines that the search route in which the forward related link exists is 0 (S7). Further, the information search unit 6 determines that there is no reverse related link (S9: No). Also, since the shortest path is one as shown in FIG. 6A (S10: No), the information search unit 6 performs a search in the vertical direction (abstract level axis direction) (S12).

  FIG. 6-4 is a diagram illustrating a state in a case where a search process in the vertical direction is performed from the current block of abstraction level 2 / detail level 2. The information search unit 6 performs a search in the vertical direction, and sets the current block to a block of abstraction 1 / detail 2 (S12). The information search unit 6 sets a block of abstraction level 1 / detail level 3 in which a forward relation link exists from the current block as a target block (S6).

  FIG. 6-5 is a diagram illustrating a search process subsequent to FIG. 6-4. The information search unit 6 searches forward from the current block (abstraction level 1 / detail level 3), and sets a block of abstraction level 1 / detail level 4 as a target block (S6).

  FIG. 6-6 is a diagram illustrating a search process subsequent to FIG. 6-5. As shown in FIG. 6-6, the information search unit 6 determines that there is no relational link from the current block (abstraction level 1 / detail level 4) to abstract level 1 / detail level 5 (S7: No, S9: No). ).

  Therefore, the information search unit 6 performs a search in the vertical direction (abstraction level direction) as shown in FIG. 6-7, and sets the target block to a block of abstraction level 2 / detail level 4 (S12). Subsequently, as shown in FIG. 6-8, the information search unit 6 ends the search using the block of abstraction level 2 / detail level 4 as the current block and the block of abstraction level 2 / detail level 5 as the end block as the target block. To do. The information search unit 6 may output the search route to a display or the like with screen information as shown in 6-8, and outputs various information related to the search route in a file format such as CSV (Comma-Separated Values). May be.

  The information search unit 6 also performs a search for setting a target block in a direction opposite to the detour direction after detouring (moving in the direction of abstraction). FIG. 6-9 is a diagram illustrating one aspect of the search after the state of FIG. 6-4. As shown in the figure, the information search unit 6 sets the target block in the direction opposite to the detour direction (that is, the direction of the original current block). Here, the block of abstraction level 2 / detail level 2 that has passed once becomes the target block again, but there is no problem as long as the route follows different information nodes even in the same block. However, as is clear from FIG. 6A, there is no relational link from the abstract level 2 / detail level 2 block to the abstract level 2 / detail level 3 block. Therefore, only the search route shown in FIGS. 6-8 is extracted.

  The information search unit 6 performs the search process according to the above flow. Note that the above processing flow is merely an example. That is, the information search unit 6 may calculate a search route from the start point to the end point by tracing the related link from a certain information node in the forward direction, reverse direction, detail level direction, and abstraction level direction. In the case of many systems, it is desirable that the information search unit 6 performs a search so that when the detour is performed, the information search unit 6 immediately returns in the direction opposite to the detour.

  In the above description, the start point and the end point are designated by blocks. However, the present invention is not limited to this, and the start point and end point may be designated by information nodes.

  Next, effects of the software asset management apparatus 1 according to the present embodiment will be described. When the repository 7 is configured, a relation link setting error or information node registration omission may occur due to the size of the repository 7. In the initial stage of using the repository 7, it is often difficult to set all information nodes and related links.

  As described above, the information search unit 6 searches not only in the forward direction of the related link but also in the reverse direction and the abstraction axis direction (vertical direction). This makes it possible to extract a necessary search route even when information nodes are not sufficiently registered or there is a setting failure of related links. As a result, the user can refer to the entity information associated with the extracted search route.

  In addition, the information search unit 6 gives priority to proceeding the related link in the forward direction and the detail direction, and when the related link does not exist, the information search unit 6 searches in the reverse direction or the abstraction direction of the related link (S7). (S8 to S12 are performed after the above determination is made, and if one or more routes are extracted in S6, S8 to S12 are not performed.) As a result, a search is performed with priority given to a route having a strong relationship, and a more useful search route can be calculated.

<Embodiment 2>
The software asset management apparatus according to the present embodiment is characterized in that, when there are a plurality of search paths from the start point to the end point, a plurality of search paths are given priority and displayed and selected according to various criteria. Hereinafter, the software asset management apparatus according to the present embodiment will be described while referring to differences from the first embodiment.

  The configuration of the software asset management apparatus 1 according to the present embodiment will be described with reference to FIG. In addition to the configuration of FIG. 1, the repository 7 further includes a keyword holding unit 9 and a link weight holding unit 10.

  Hereinafter, the keyword information held by the keyword holding unit 9 will be described. In the repository 7, a keyword can be assigned to each information node. The relationship between information nodes and keywords will be described with reference to FIGS. 2-8 and 2-9.

  2-8 shows a state in which information nodes AA, BB, CC, and DD are registered in the two blocks (1-1 and 1-2) of the information holding unit 8, respectively. The same logical configuration and terminology are used for the information entity (for example, function description) of the information node included in block 1-1 and the information entity (for example, data relation diagram) of the information node included in block 1-2. Such an event can occur because it is often the case. Here, the information node AA in the block 1-1 and the information node AA in the block 1-2 often have some semantic relationship. Therefore, in the repository 7, the same keyword can be given to these information nodes as a tag for identifying such a semantic relation.

  FIG. 2-9 shows an example of a table structure for specifically realizing the association between information nodes and keywords. The information holding unit 8 in FIG. 2-9 is given a unique number to each information node (record) as compared to the information holding unit 8 in FIG. 2-2, even if there are a plurality of information nodes having the same information name. They are different in that they are configured to be identifiable. In this example, there are two information names AA, two BBs, two CCs, and two DDs.

  The keyword management unit 9 is a table including at least one record that associates at least a keyword name with an information number list. The information number list specifies a plurality of information nodes associated with a keyword by numbers in the information holding unit 8.

  When there are a plurality of search routes from the start point to the end point, the information search unit 6 according to the present embodiment sets a priority for each of the plurality of search routes. The priority setting method will be described below.

  FIG. 8 is a flowchart showing the flow of search processing according to this embodiment. Since the processing from S1 to S14 is the same as that of the first embodiment, the illustration is omitted. Further, the processes denoted by the same reference numerals are the same as those in the first embodiment, and the description thereof is omitted.

  After completing the search to the end point block (S14: Yes), the information search unit 6 determines whether there are two or more search paths connecting the start point to the end point (S16). When the extracted search route is not 2 or more (S16: No), the information search unit 6 outputs the search result (S15) and ends the process.

  On the other hand, when the number of extracted search routes is 2 or more (S16: Yes), the information search unit 6 determines whether or not to set the priority of each search route according to the overlap of the search routes (S17). . The determination is performed according to a search condition input from the input device 2, for example. That is, the user designates whether or not to set priority according to the overlap of the search routes via the input device 2.

  The information search unit 6 sets the priority of each search route according to the overlap of the search routes by the following method (S18). Details will be described with reference to FIGS. 9-1 to 9-6. As shown in FIG. 9A, it is assumed that the relational link in the detailed axis direction is broken in the second block from the start point block.

  At this time, the information search unit 6 calculates a total of six search routes as shown in FIGS. 9-2 to 9-4. FIG. 9-5 is a conceptual diagram in which all extracted search paths are displayed in an overlapping manner. The information search unit 6 calculates the number of overlapping search paths as shown in FIG. 9-5. And the information search part 6 sets a big priority with respect to the search path | route (namely, path | route shown to FIGS. 9-6) with many overlaps. The priority to be set can be set to any numerical value as long as it is determined according to the number of overlaps.

  Reference is again made to the flowchart of FIG. The information search unit 6 determines whether or not to set the priority of each search route according to the weight of the related link (S19). The determination is performed according to a search condition input from the input device 2, for example.

  The information search unit 6 sets the priority of each search route according to the weight of the related link by the following method (S20). The information search unit 6 assigns weights to related links included in each searched route based on the related link weight information as shown in FIG. 10, and calculates the total weight (cumulative addition value) of each searched route.

  The relation link weight information shown in FIG. 10 will be described below. The related link weight information shown in FIG. 10 is stored in the link weight holding unit 10. The weight is an index value indicating the ambiguity of information. It is stipulated that the ambiguity of information increases regardless of the link attribute and the direction of the link by following the related link in principle. That is, if there are five related links in the search path, the ambiguity increases by 5 at a minimum. The table shown in FIG. 10 defines the magnitude of ambiguity according to the link attribute and the direction of the link based on this idea. Note that the size of the weight shown in FIG. 10 is merely an example, and the user may be able to change the setting as appropriate.

  The magnitude of the weight is set in consideration of the strength of the relationship, and the smaller the weight, the stronger the relationship. A link attribute (attribute indicating what kind of relationship the link is) can be set for the relationship link. For example, “concept-detail relationship” of the link attribute indicates an is-a relationship, and “abstract-concrete relationship” indicates a whole-part relationship. Since these relationships are strong relationships that can be mechanically extracted from registered information such as a design document, the weight is set to 1 at the minimum. The weight in the reverse direction indicates a value when tracing in the direction opposite to the direction of the relational link connecting the information nodes. When the relational link is traced in the reverse direction, the process proceeds in a weaker relation, so the weight is doubled to 2. Since the direction of “abstract-concrete relationship” and “summary-detail relationship” changes depending on which information node is considered as a starting point, the direction of the relationship link is treated as “none”. However, when specifying the search, in the case of searching in the detailed direction, the detailed direction (direction in which the degree of detail increases) may be set as the forward direction.

  The link attribute “coincidence related” indicates the same information with different viewpoints, such as the relationship between the function description and the function relationship diagram, and the relationship between the class diagram and the object diagram. Since the relationship is difficult to extract mechanically from a document such as a design document, the weight value is set to 2. Note that the weight in the reverse direction is also 2 because they are equivalent.

  The link attribute “message” is a relationship representing data exchange between information nodes. The message relationship is more ambiguous than the related information and has a weight of 3. The message only indicates the data input / output relationship and does not affect the ambiguity. Therefore, the reverse weight is also set to 3.

  The link attribute “sequence” is a relationship indicating the execution order. For example, the relationship represents the execution order of programs. The link attribute indicates only a relationship in which execution processing is performed after execution processing is performed on a certain information node. For this reason, the relationship between information nodes is assumed to be the least sparse, and the weight is set to 4. The weight in the reverse direction is doubled to 8.

  The information search unit 7 refers to this table (FIG. 10) and assigns weights to all the related links of the extracted search route. And the information search part 7 calculates the sum total of the weight of each search path | route. After calculating the sum of the weights, the information search unit 7 assigns a higher priority in ascending order of the sum of the weights.

  Refer to FIG. 8 again. The information search unit 6 determines whether or not to set the priority of each search route according to the keyword (S21). The determination is performed according to a search condition input from the input device 2, for example.

  The information search unit 6 sets the priority of each search route according to the keyword by the following method (S22). The priority setting of each searched route according to the keyword will be described with reference to FIGS. 11-1 to 11-3.

  FIG. 11A is a diagram illustrating a search result when the processing of S14 in FIG. 8 ends. As shown in the figure, it is assumed that two search paths have been extracted. A keyword is assigned to each information node. The keyword is stored in the keyword holding unit 9. The user inputs a keyword for the information node via the input device 2 at an arbitrary timing. In the example of FIG. 11A, a keyword related to “A” or “B” is given to each information node.

  The information search unit 6 extracts keywords assigned to information nodes included in each search route. As illustrated in FIG. 11B, the information search unit 6 detects a search route (FIG. 11C) in which the keyword “A” is assigned to both the information node serving as the start point and the information node serving as the end point. . Therefore, the information search unit 6 gives a high priority to the search route (FIG. 11-3). Note that the information search unit 6 may determine the priority by referring not only to the information node serving as the start point and the information node serving as the end point but also to keywords assigned to the information node group located in the middle.

  In addition, the information search part 6 should just calculate a final priority based on the priority calculated by each method, when two or more methods of said three priority setting methods are used. For example, the information search unit 6 may calculate the final priority by an arbitrary method such as adding or multiplying the calculated priorities.

  The information search unit 6 performs display output of the search route after the processing of S16 to S22. At this time, the information search unit 6 performs display output according to the assigned priority. For example, the information search unit 6 may output only the search route with the highest priority (or the highest N priority routes) to the output device 3 in a graph format (for example, a display format shown in FIG. 2-7). Good.

  Moreover, the information search part 6 may sort according to a priority, and may display the search path | route which rearranged as a text (or file output). That is, the information search unit 6 may perform output processing according to the calculated priority.

  Next, effects of the software asset management apparatus 1 according to the present embodiment will be described. As described above, when a plurality of search paths are extracted, the information search unit 6 assigns a priority to each search path and performs output according to the priority. Thereby, the user can grasp | ascertain the search path | route which should be referred with higher priority.

  As shown in FIGS. 9-1 to 9-6 described above, the information search unit 6 can give priority according to the overlapping degree of search routes. As a result, the user can refer to it with priority from a search path that seems to be more general.

  Moreover, the information search part 6 can give a priority to a search path | route according to the weight of a related link, as shown in FIG. The weight is determined according to the strength of the relationship between the information nodes as shown in FIG. As a result, the user can refer to the search routes with priority in order from the search route that is assumed to be closely related.

  As shown in FIGS. 11-1 to 11-3, the information search unit 6 can also assign priorities in consideration of keywords assigned to each information node. The keyword is information indicating the characteristics of each information node. Therefore, the user can refer to the information with priority in order from the search path that is presumed that the information nodes in the search path are strongly related to each other according to the keyword.

  In addition, the information search unit 6 assigns the priority of the search route according to the weights of the related links and assigns the priority of the search route according to the overlapping degree of the search routes when the priority is given by a plurality of methods. In the case of granting), the final priority is calculated in consideration of the priorities of both methods (for example, by adding and multiplying priorities). Thereby, the user can refer to the search route that should be given the highest priority from a plurality of viewpoints.

<Embodiment 3>
The software asset management apparatus 1 according to the third embodiment of the present invention has a search function (further information node narrowing function) for utilizing registered software assets. A difference of the software asset management apparatus 1 according to the present embodiment from the second embodiment will be described below.

  First, a case where a problem may occur in the software asset management apparatus 1 according to the first and second embodiments will be described. When design information related to the system is registered in the repository 7, the amount of information to be registered becomes enormous depending on the scale of the system. When the search according to the first embodiment is performed in a state where a large amount of registrations are made in the repository 7, for example, all of the search results are defined as “starting from a specific information node in the end point block (having a connection relationship)” Information node ". That is, the number of search results becomes enormous, and it may take time and effort for the user to specify information nodes that are really necessary.

  In addition to the skill of the person in charge of development, the system implementation has the property of reflecting implementation preferences and habits, and defects in quality also reflect the habits of the developer. Therefore, there are cases where the problem cannot be extracted only by determining the direct influence range by the relational link in the repository 7. For example, there may be a case where a code portion having a similar problem that is not related to a call in the program cannot be extracted.

  In view of such a problem, the software asset management apparatus 1 according to the present embodiment is characterized in that the information search unit 6 performs narrowing down in consideration of the usage history and the like. Details will be described below. FIG. 12 is a block diagram illustrating a configuration of the software asset management apparatus 1 according to the present embodiment.

  The repository 7 in the software asset management apparatus 1 according to the present embodiment includes a usage history holding unit 11 and a change reason holding unit 12 in addition to the configuration of the first embodiment.

  The usage history holding unit 11 holds a history when the repository 7 is used (data addition / reference / update / deletion). Here, operations (addition / update / deletion) of the use of the repository 7 other than the reference are determined by a commit operation as in the case of a general configuration management tool. It is assumed that a comment is registered regarding the commit content at the time of this commit. The change history holding unit 12 holds the type of update reason at the time of commit.

  “Used (added / referenced / updated / deleted information node)”, “comment character string input at the time of commit (added / updated / deleted), and designation by the usage history holding unit 11 and the change history holding unit 12 (Or extracted) keywords "," search condition character strings specified at the time of reference ", etc. are managed so that the characteristics of how the system is used can be grasped. Detailed configuration examples of the usage history holding unit 11 and the change history holding unit 12 will be described with reference to FIGS. 13A and 13B.

  The usage history holding unit 11 manages three types of tables: a usage history table, an information node usage history table, and a keyword usage history table. The usage history table manages the usage date / time, comment character string, search condition, and reason for updating (pointer to). The information node usage history table manages a pointer to the usage date and a pointer to the ID of the information node. The information node history table is a table for associating the usage history table with the table managed by the information holding unit 8. The keyword use history table manages a pointer to the use date and a pointer to the keyword. The keyword usage history table is a table for associating the usage history table with the table managed by the keyword holding unit 9.

  The change history holding unit 12 holds the update history input at the time of commit in the rear wheel reason table. Each update history is assigned a coefficient as shown. It is determined that the larger the coefficient is, the more important it is in narrowing down the search results described later.

  Next, search processing by the information search unit 6 using data of the usage history holding unit 11 and the change history holding unit 12 will be described with reference to FIGS. FIG. 14 (14-1 to 14-6) is a flowchart showing the flow of search processing by the information search unit 6 according to this embodiment.

  First, the user inputs start point information (start point block) and end point information (end point block) via the input device 2 (S31). For example, in FIG. 15A, the user designates the abstraction level 2 / detail level 1 as the start block and the abstract level 1 / detail level 3 as the end point block.

  The information search unit 6 extracts a search route from the start point block to the end point block by the method shown in FIGS. 4-1 and 4-2, and extracts information nodes included in the extracted search route (S32). The information search unit 6 extracts a search route that traces between information nodes as shown in FIG. 15-2, for example.

  The information search unit 6 starts from the information node in the end point block, traces the relation link having the information node as the end point node, and extracts the information node until the reverse relation link appears (S32). In the example of FIG. 15B, the information search unit 6 starts a search from an information node at an abstraction level 1 / detail level 3 and traces a relational link having the information node as an end point. Then, the information search unit 6 follows the direction of the relation link (follows the relation link having the target information node as the end point). In the example of FIG. 15B, the information search unit 6 determines that there is no related link having this information node as the end point when it reaches the third information node after starting the search. Therefore, the information search unit 6 extracts three information nodes (S32).

  The user selects an information node as a search starting point based on the information node extracted by the information search unit 6 in S32 (S33). FIG. 15C is a diagram illustrating the size of the search range when each information node is selected. As shown in the figure, the search range varies depending on the information node to be selected.

  The information search unit 6 starts searching from the search origin node specified in S33 (in the example of FIG. 13, abstraction level 2 / detail level 1, abstract level 2 / detail level 2, abstract level 1 / detail level 2, abstract level). All information nodes in which related links are installed in each block of degree 1 / detail 3) are extracted (S34). FIG. 16 shows all information nodes extracted when module A is the starting point. All the information nodes indicated with diagonal lines in the figure are extracted.

  If the extraction node is 0, the process is terminated (S35: extraction node = 0). When the number of extracted nodes is 1 or more (S35:> = 1), the information search unit 6 executes the processes after S36.

  The user sets an analysis rule for analyzing a comment input at the time of commit (a comment input separately from the update reason) (S36). An analysis rule is a syntax definition for analysis, such as “identifier = value” in which the left side between “=” is an identifier and the right side is a value.

  The information search unit 6 narrows down the extracted information node (S34) by node name or keyword matching search according to the input from the user (S37).

  The user adjusts the coefficient for each change reason used for the subsequent narrowing down according to the purpose of the search (S38). The example of FIG. 13 shows a situation in which a bug correction coefficient is set to 5 and a function enhancement coefficient is set to 2.

  Further, when narrowing down information nodes by importance, the user sets a coefficient to be applied as necessary (S38). The usage scenario will be described below. For example, the user assumes that there are many searches for correction points for bug correction, and the default setting is to apply only the update reason coefficient. On the other hand, when the user wants to narrow down based on the use of an information node related to a specific keyword rather than the reason for change, the keyword coefficient (coefficient 1 in FIG. 13) is set.

  The information search unit 6 sets importance by using the coefficient set in S38 for all the information nodes extracted by narrowing down in S37. The information search unit 6 calculates the importance for each information node by multiplying, for example, the number of updates (the number of records stored in the usage history table within a predetermined period) and a coefficient (S39). The information search unit 6 displays the importance of each information node on the output device 3.

  The user selects a specific information node from the information nodes displayed together with the importance. Then, the user performs necessary update work (S40). For example, the user corrects a bug in a program associated with the selected information node. The user inputs the reason for the update (such as “bug correction” in FIG. 13) after the update work is completed (S41). Also, the user inputs the value of each attribute according to the commit analysis rule set in S36 (S42). The information search unit 6 analyzes the attribute value according to the analysis rule (S43), and when there is an error in the input (S44: Yes, for example, there is no “=”), the information search unit 6 prompts the input again. If there is no error in the input (S44: No), execution of commit is confirmed (S45).

  To summarize the above operations, the information search unit 6 calculates the importance for each information node from the information nodes (information nodes extracted in S37) included in the search path using various coefficients and usage frequencies, and the importance Is presented to the user. The user selects an information node based on the importance and performs necessary processing, and inputs an update reason and each attribute value at the time of commit. By calculating the importance, the user can appropriately grasp the information node that is to be corrected.

  The user inputs whether to perform a similar search (S46). The information search unit 6 searches for an information node (hereinafter referred to as a similar information node) similar to the information node that has committed. The similar information node is an information node that is similar to the committed information node but has no relationship between the nodes by the relationship link. Note that the following similarity search process is not limited to searching for a similar information node to a committed information node, but can also be applied to searching for a similar information node of an information node explicitly specified by the user. Can do.

  When searching for similar information nodes, the user selects a specific information node and a revision of the information node from among the information nodes that have been committed (S47). Search for similar information node is, for example, “A program corresponding to an information node corrected by a certain commit has a bug, so a revision selected at the time of commit is selected, and a program created at the same time has a similar weakness This is done for the purpose of “extracting information nodes”.

  When there are a plurality of information nodes selected in S47 (S48: Yes), the information search unit 6 selects a narrowing-down condition AND or OR (S49). Thereafter, the user sets a period for extracting an attribute value serving as a search key for the information node designated in S47 (S50). The reason for setting the period is as follows. For example, it is possible to identify one revision that has a bug in the program related to the information node to be committed. However, development for the same version may involve multiple commits or commits over multiple dates. Since there is a possibility of a time lag in the timing at which commit is performed in this way, the user designates a period.

  After that, the user designates from what point of view the similarity is determined. Specifically, the user designates which attribute values related to the information node are similar if they are the same. When the update user ID is designated by the user, the information search unit 6 reads the update user ID of the information node extracted in S47 (S51). The information search unit 6 reads the update date and time of the information node extracted in S47 (S52). The information search unit 6 extracts attribute values (for example, bug management number, development management number, project name, etc.) of other identifiers of the information node extracted in S47 (S53). The information search unit 6 validates the keyword (allows reading of the keyword usage history table). In addition, the user sets coefficients for other attribute values as necessary (S54).

  The user selects an attribute value used for narrowing down from the acquired attribute values (S55). Thereafter, the information search unit 6 narrows down the period for searching for similar information nodes. For example, when the update user targets the same information node, the search period of the information node is narrowed down according to the enrollment period of the corresponding update user.

  The information search unit 6 includes each of the search target blocks (for example, in the case of FIG. 13, abstraction level 2 / detail level 1, abstraction level 2 / detail level 2, abstraction level 1 / detail level 2, abstraction level 1 / detail level 3 Block information nodes are taken out one by one (S56). The information node to be compared is also referred to as a comparison target information node in the following description. Then, the information search unit 6 reads each attribute value of the oldest revision of the comparison target information node (S57).

  The information search unit 6 specifies a condition (target period, identifier (user ID, bug management number, project name)) for each read attribute value and each attribute value of the information node extracted in S47. Etc. are evaluated (S58). When it is determined that both satisfy the conditions (for example, have the same value) (S59: Yes), the information search unit 6 stores the comparison target information node and its revision as a similar information node (S60).

  The information search unit 6 determines whether there is a revision that is newer than the revision of the compared comparison target information node (S61). When a new revision exists (S61: Yes), the information search unit 6 evaluates S58 for the new revision of the comparison target information node (S62). When there is no new revision (S61: No), the information search unit 6 determines whether there is a comparison target information node that has not been evaluated (S63). When it exists (S63: Yes), the information search part 6 performs a process again from S56 for another comparison object information node. When there is no comparison target information node that has not been evaluated (S63: No), the information search unit 6 displays the extracted similar information node (S64). At this time, the information search unit 6 calculates importance based on the coefficient (for example, the sum of the corresponding coefficient 1 (FIG. 13) and coefficient 2 (FIG. 13) is used as the importance), and sorts in order of importance. The similar information node is displayed (S64). The user sets whether to search for similar nodes again by changing the search condition (S65). When the search is performed again (S65: Yes), the information search unit 6 executes the process from S46 under the newly set conditions. When the search is not performed again (S65: No), the information search unit 6 ends the process. Thereafter, the user refers to the similar information node and performs necessary processing (for example, a similar bug correction operation).

  Next, effects of the software asset management apparatus 1 according to the present embodiment will be described. As described above, the information search unit 6 performs a similar search for determining matching of attribute values (comparison using the above-described usage history and user ID), and in a case where no relation link is set between information nodes. Even if it exists, an information node similar to a certain information node can be extracted. As a result, information nodes having similarities in system development characteristics can be appropriately extracted, and the efficiency of system development can be improved. Further, by converting the importance into numerical values, the user can obtain necessary information more easily.

  Furthermore, the above-described embodiment is merely an example relating to application of the technical idea obtained by the present inventors. That is, the technical idea is not limited to the above-described embodiment, and various changes can be made.

  It can be realized as a program that operates in any computer of the information input unit 5 and the information search unit 6 in the software asset management apparatus 1 of the first or second embodiment. The program may be stored using various types of non-transitory computer readable media and supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic recording media (for example, flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (for example, magneto-optical disks), CD-ROMs (Read Only Memory), CD-Rs, CD-R / W and semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (random access memory)) are included. The program may also be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. The temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.

  FIG. 17 shows an example of a hardware configuration of a computer that executes the processing of the information input unit 5 and the information search unit 6 in the software asset management apparatus 1 as a program. The computer includes a central processing unit (CPU) 100 and a memory 101. The CPU 100 and the memory 101 are connected to a hard disk device (HDD) 102 as an auxiliary storage device via a bus. A storage medium such as the hard disk device 102 can store a computer program for giving instructions to the CPU 100 or the like in cooperation with the operating system and executing the processes of the software asset management device 1 described above.

  A part or all of the above embodiment can be described as in the following supplementary notes, but is not limited thereto.

(Appendix 1)
Information blocks, which are individual information units that make up software assets, are placed in blocks divided according to abstraction and detail, and set with relational links, which are directed links that indicate the relationships between information nodes. An information holding unit for holding an asset management matrix;
An information input unit that accepts input of start point information related to the search start point and end point information related to the search end point;
Tracing one or more search paths from the information node derived on the basis of the start point information to the information node derived on the basis of the end point information, in the forward or reverse direction, and the relationship An information search unit that calculates a link by following the abstraction axis direction and the detail axis direction;
A software asset management device comprising:

(Appendix 2)
The software asset according to appendix 1, wherein the information search unit calculates a degree of overlap of each of the calculated search routes, and sets a priority according to the calculated degree of overlap. Management device.

(Appendix 3)
A keyword holding unit for holding a keyword for the information node in the asset management matrix;
The information search unit sets priority for each of the calculated search routes based on matching of keywords assigned to each of the information nodes included in the route. Software asset management device.

(Appendix 4)
A link weight holding unit that holds a table in which weight values according to the attribute and direction of the related link in the asset management matrix are set;
For each of the calculated search routes, the information search unit cumulatively adds the weight values of each of the related links included in the route, and sequentially sets a high priority in order of increasing the cumulative addition value. The software asset management apparatus according to appendix 1.

(Appendix 5)
The software asset according to claim 4, wherein the table is set such that a weight value for tracing the relational link in the backward direction is set smaller than a weight value for tracing the relational link in the forward direction. Management device.

(Appendix 6)
The information search unit traces the related link in the forward direction in the direction of detail, and calculates the search route by following the related link in the reverse direction in the direction of detail when there is no forward link. The software asset management apparatus according to any one of appendix 1 to appendix 5.

(Appendix 7)
The information search unit traces the related link in the detail level direction, and calculates the search route by following the related link in the abstract level direction when there is no link in the detailed level direction. The software asset management device according to any one of appendix 6.

(Appendix 8)
The software information management device according to any one of appendix 1 to appendix 7, wherein the information search unit displays and outputs the search route having the highest priority.

(Appendix 9)
8. The software asset management apparatus according to any one of appendix 1 to appendix 7, wherein the information search unit sorts and displays the search paths using the priority.

(Appendix 10)
A usage history holding unit that holds the usage history of each of the information nodes included in the asset management matrix;
The information search unit calculates an importance level for each of the information nodes included in the search route based on the usage history held by the usage history holding unit, and presents it to the user. The software asset management apparatus according to any one of?

(Appendix 11)
A change history holding unit for managing the information node included in the asset management matrix in association with a change reason and a coefficient of the change reason;
The information search unit obtains the number of uses of each information node included in the search route from the use history held by the use history holding unit, and the change history holding unit corresponding to the update reason at each use holds the information search unit. The software asset management device according to any one of appendices 1 to 10, wherein the importance is calculated by accumulating coefficients.

(Appendix 12)
The information search unit compares the matching of attribute values of a target information node that is a predetermined information node and a comparison target information node that is an arbitrary information node. 12. The software asset management apparatus according to any one of appendix 1 to appendix 11, wherein a comparison target information node is extracted as a similar information node.

(Appendix 13)
13. The software asset management apparatus according to appendix 12, wherein the target information node is an information node that has been immediately committed to the software asset management apparatus.

(Appendix 14)
Information blocks, which are individual information units that make up software assets, are placed in blocks divided according to abstraction and detail, and set with relational links, which are directed links that indicate the relationships between information nodes. A search method for a repository that holds an asset management matrix,
An information input step for receiving input of start point information related to the search start point and end point information related to the search end point;
Tracing one or more search paths from the information node derived on the basis of the start point information to the information node derived on the basis of the end point information, in the forward or reverse direction, and the relationship An information search step for calculating by tracing the link in the direction of abstraction axis and the degree of detail axis;
Software asset management method that executes

(Appendix 15)
(Supplementary note 14) characterized in that, in the information search step, the degree of overlap of the routes is calculated for each of the calculated search routes, and the priority of each of the search routes is set according to the degree of overlap. The described software asset management method.

(Appendix 16)
The repository further includes a keyword holding unit that holds a keyword for the information node in the asset management matrix,
In the information search step, for each of the calculated search routes, a priority of each of the search routes is set based on matching of keywords assigned to each of the information nodes included in the route. The software asset management method according to appendix 14.

(Appendix 17)
The repository further includes a link weight holding unit that holds a table in which weight values according to attributes and directions of the related links in the asset management matrix are set;
15. The software according to appendix 14, wherein, in the information search step, the weights of the related links are cumulatively added for each of the calculated search routes, and priorities are set in the order of the cumulative addition value being small. Asset management method.

(Appendix 18)
The software asset according to appendix 17, wherein the table is set such that a weight value for tracing the relational link in the reverse direction is set smaller than a weight value for tracing the relational link in the forward direction. Management method.

(Appendix 19)
In the information search step, the search path is calculated by tracing the related link in the forward direction in the detail direction, and when there is no forward link, tracing the related link in the reverse direction in the detail direction. The software asset management method according to any one of appendix 14 to appendix 18.

(Appendix 20)
In the information search step, the search path is calculated by tracing the related link in the direction of detail, and when there is no link in the direction of detail, tracing the related link in the direction of abstraction. The software asset management method according to any one of appendix 19.

(Appendix 21)
The software asset management method according to any one of Supplementary Note 14 to Supplementary Note 20, wherein in the information search step, the search route with the highest priority is displayed and output.

(Appendix 22)
The software asset management method according to any one of Supplementary Note 14 to Supplementary Note 20, wherein in the information search step, the search routes are sorted and displayed using the priority.

(Appendix 23)
The repository includes a change history holding unit that manages the information node included in the asset management matrix in association with a change reason and a coefficient of the change reason,
In the information search step, the number of uses of each information node included in the search route is obtained from the use history held by the use history holding unit, and the change history holding unit corresponding to the update reason at each use holds The software asset management method according to any one of appendix 14 to appendix 22, wherein the importance is calculated by accumulating coefficients.

(Appendix 24)
The repository includes a change history holding unit that manages the information node included in the asset management matrix in association with a change reason and a coefficient of the change reason,
In the information search step, the number of uses of each information node included in the search route is obtained from the use history held by the use history holding unit, and the change history holding unit corresponding to the update reason at each use holds The software asset management method according to attachment 23, wherein the importance is calculated by accumulating coefficients.

(Appendix 25)
In the information search step, the matching of attribute values of a target information node that is a predetermined information node and a comparison target information node that is an arbitrary information node is compared, and when it is determined that the comparison is similar, 25. The software asset management method according to any one of appendix 14 to appendix 24, wherein the comparison target information node is extracted as a similar information node.

(Appendix 26)
26. The software asset management method according to appendix 25, wherein the target information node is an information node that has been immediately committed to the software asset management apparatus.

(Appendix 27)
Information blocks, which are individual information units that make up software assets, are placed in blocks divided according to abstraction and detail, and set with relational links, which are directed links that indicate the relationships between information nodes. A program that executes a search for a repository that holds an asset management matrix,
On the computer,
An information input step for receiving input of start point information related to the search start point and end point information related to the search end point;
Tracing one or more search paths from the information node derived on the basis of the start point information to the information node derived on the basis of the end point information, in the forward or reverse direction, and the relationship An information search step for calculating by tracing the link in the direction of abstraction axis and the degree of detail axis;
Software asset management program that executes

(Appendix 28)
(Supplementary note 27) characterized in that, in the information search step, the degree of overlap of the route is calculated for each of the calculated search routes, and the priority of each of the search routes is set according to the degree of overlap. The described software asset management program.

(Appendix 29)
The repository further includes a keyword holding unit that holds a keyword for the information node in the asset management matrix,
In the information search step, for each of the calculated search routes, a priority of each of the search routes is set based on matching of keywords assigned to each of the information nodes included in the route. The software asset management program according to appendix 27.

(Appendix 30)
The repository further includes a link weight holding unit that holds a table in which weight values according to attributes and directions of the related links in the asset management matrix are set;
28. The software according to appendix 27, wherein in the information search step, for each of the calculated search routes, the weights of the related links are cumulatively added, and priorities are set in order of increasing the cumulative added value. Asset management program.

(Appendix 31)
31. The software asset according to appendix 30, wherein the table is set such that a weight value for tracing the relation link in the backward direction is set smaller than a weight value for tracing the relation link in the forward direction. Management program.

(Appendix 32)
In the information search step, the search path is calculated by tracing the related link in the forward direction in the detail direction, and when there is no forward link, tracing the related link in the reverse direction in the detail direction. The software asset management program according to any one of appendix 27 to appendix 31.

(Appendix 33)
The information search step traces the relational link in the direction of detail, and if there is no link in the degree of detail, traces the relational link in the direction of abstraction to calculate the search route. The software asset management program according to any one of appendix 32.

(Appendix 34)
34. The software asset management program according to any one of supplementary notes 27 to 33, wherein in the information search step, the search route having the highest priority is displayed and output.

(Appendix 35)
34. The software asset management program according to any one of appendixes 27 to 33, wherein in the information search step, the search paths are sorted and displayed using the priority.

(Appendix 36)
The repository includes a change history holding unit that manages the information node included in the asset management matrix in association with a change reason and a coefficient of the change reason,
In the information search step, the number of uses of each information node included in the search route is obtained from the use history held by the use history holding unit, and the change history holding unit corresponding to the update reason at each use holds The software asset management program according to any one of supplementary notes 27 to 35, wherein the importance is calculated by accumulating coefficients.

(Appendix 37)
The repository includes a change history holding unit that manages the information node included in the asset management matrix in association with a change reason and a coefficient of the change reason,
In the information search step, the number of uses of each information node included in the search route is obtained from the use history held by the use history holding unit, and the change history holding unit corresponding to the update reason at each use holds 37. The software asset management program according to attachment 36, wherein the importance is calculated by accumulating coefficients.

(Appendix 38)
In the information search step, the matching of attribute values of a target information node that is a predetermined information node and a comparison target information node that is an arbitrary information node is compared, and when it is determined that the comparison is similar, The software asset management method according to any one of appendix 27 to appendix 37, wherein the comparison target information node is extracted as a similar information node.

(Appendix 39)
39. The software asset management program according to appendix 38, wherein the target information node is an information node that has been a target of commit to the software asset management apparatus immediately before.

DESCRIPTION OF SYMBOLS 1 Software asset management apparatus 2 Input device 3 Output device 4 Processing part 5 Information input part 6 Information search part 7 Repository 8 Information holding part 9 Keyword holding part 10 Link weight holding part 11 Usage history holding part 12 Change history holding part 100 CPU ( Central Processing Unit)
101 Memory 102 Hard disk device

Claims (10)

Information blocks, which are individual information units that make up software assets, are placed in blocks that are classified according to abstraction and detail, and an asset management matrix is set in which the relationship between each information node is set by relationship links An information holding unit;
An information input unit that receives input of start point information related to a search start point in the asset management matrix and end point information related to a search end point;
Tracing one or more search paths from the information node derived on the basis of the start point information to the information node derived on the basis of the end point information, in the forward or reverse direction, and the relationship An information search unit that calculates a link by following the abstraction axis direction and the detail axis direction;
A software asset management device comprising:   2. The software according to claim 1, wherein the information search unit calculates a degree of overlap of each of the calculated search routes, and sets a priority according to the calculated degree of overlap. Asset management device. A keyword holding unit for holding a keyword for the information node in the asset management matrix;
2. The information search unit according to claim 1, wherein the information search unit sets a priority for each of the calculated search routes based on matching of keywords assigned to each of the information nodes included in the route. The software asset management device described. A link weight holding unit that holds a table in which weight values according to the attribute and direction of the related link in the asset management matrix are set;
For each of the calculated search routes, the information search unit cumulatively adds the weight values of each of the related links included in the route, and sequentially sets a high priority in order of increasing the cumulative addition value. The software asset management device according to claim 1.   5. The software according to claim 4, wherein in the table, a weight value for tracing the relational link in the reverse direction is set to be larger than a weight value for tracing the relational link in the forward direction. Asset management device.   The information search unit traces the related link in the forward direction in the detail axis, and calculates the search path by tracing the related link in the reverse direction in the detail axis when there is no forward link. The software asset management apparatus according to claim 1, wherein the software asset management apparatus is a software asset management apparatus.   The information search unit traces the relational link in the direction of detail, and calculates the search route by following the relational link in the direction of abstraction when there is no link in the direction of detail. The software asset management apparatus according to claim 6.   The software information management device according to any one of claims 1 to 7, wherein the information search unit displays and outputs the search route having the highest priority. Information blocks, which are individual information units that make up software assets, are placed in blocks that are classified according to the abstraction level and the level of detail, and an asset management matrix is created in which the relationship between each information node is set with relationship links A search method for a repository,
An information input step for receiving input of start point information related to the search start point and end point information related to the search end point;
Tracing one or more search paths from the information node derived on the basis of the start point information to the information node derived on the basis of the end point information, in the forward or reverse direction, and the relationship An information search step for calculating by tracing the link in the direction of abstraction axis and the degree of detail axis;
Software asset management method that executes Information blocks, which are individual information units that make up software assets, are placed in blocks that are classified according to abstraction and detail, and an asset management matrix is set in which the relationship between each information node is set by relationship links A program for performing a search on a repository,
On the computer,
An information input step for receiving input of start point information related to the search start point and end point information related to the search end point;
Tracing one or more search paths from the information node derived on the basis of the start point information to the information node derived on the basis of the end point information, in the forward or reverse direction, and the relationship An information search step for calculating by tracing the link in the direction of abstraction axis and the degree of detail axis;
Software asset management program that executes

Images