JP2009104291A - Software product management system, method, and its program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a software product management system, method and its program, for improving the efficiency of software development. <P>SOLUTION: A computer stores a plurality of software products generated by creating data included in another software product based on data for achieving the behavior of software included in an already created software product, in a product repository 13, and stores the data of each software product in a concept system repository 14 in a state where the data are associated with the data of the other software product created based on the data, and when the content of the data of the software product stored in the concept system repository 14 is changed by an information input part 12, the computer extracts the data of the other software product associated with the changed data from the concept system repository 14. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a software product management system, a method, and a program therefor, which use a computer to identify an influence point of another software product based on a change in contents included in a software product created in software development.

  In software development, not only source code but also a user request, a simplified flow of software operation, and a document such as a design document for creating source code (hereinafter referred to as upstream product) are created as software products. Is done. These upstream deliverables are important for developing software that helps developers understand and meets user requirements during software development. However, when a software product that has already been created is changed due to a change in functionality during software development or operation, the software's functions must be accurately reflected. Other software artifacts related to the product will also need to be changed. In this case, there is a problem that as the number of software products increases, it becomes difficult to specify related software products and to specify a changed part in the software products. Therefore, various identification methods have been studied so far.

  By the way, software deliverables define dynamic deliverables that express dynamic information (tasks) for defining the behavior of the software to be developed, and data information necessary for the software to execute the behaviors. Static artifacts exist. However, in the prior art, when a static product is changed, it is difficult to specify another static product that is affected by the change and the affected part.

  For example, with the UML (Unified Modeling Language) tool described in Non-Patent Document 1, it is possible to save each created software product in an electronic folder for each function, so it is possible to grasp other related software products. Is possible. However, only the software product affected by the change can be specified by this, and it is difficult to specify which part of the description contents of the product is affected.

  In Non-Patent Document 2, it is possible to specify the software product affected by the change and the affected part, but the target software product is limited only to the screen transition diagram and struts-config.xml. It is difficult to handle various software products created during software development.

  Furthermore, in Non-Patent Document 3, as in Non-Patent Document 2, it is possible to specify the software product affected by the change and the affected part, but the software product to be specified is only the source code, It is difficult to specify upstream deliverables such as user requirements and design documents.

  Furthermore, Non-Patent Document 4 proposes a method for identifying software deliverables and their affected parts, with the upstream deliverables such as user requirements and design documents, and the downstream deliverables such as source code as identification targets. However, there is no specific description on how to associate each software product.

Further, in Non-Patent Document 5, it is possible to specify a change place between dynamic deliverables representing the functional operation of software, such as a UC description or a sequence diagram, but as in a glossary or a class diagram, When the static product representing the data handled by the software function is changed, it is difficult to specify the static product affected by the change and the affected part.
“ENTERPRIZE ARCHITECT”, [online], Spark Systems Japan Co., Ltd., [Search February 21, 2007], Internet <URL: http://www.sparxsystems.jp/ea.htm> Ohira et al. “Proposal of Traceability Realization Method Using Metamodel in Struts Framework”, Information Processing Society of Japan Research Report, November 2005, pages 33-40 Yamada et al. "Software change support based on functional model", IEICE Transactions D-2, vol. J73-D-2, no. 10, October 1990, pp. 1770-1778 Table et al. "Support of system evolution by link between UML models (2)", IEICE Technical Report, KBSE 2004-1, May 2004 Inoue et al. “Proposal of Propagation Location Identification Method in Product Change”, IEICE General Conference Proceedings, March 2007, p.549

  As described above, in the conventional example, it is difficult to identify other static artifacts affected by the change of the static artifacts and the affected parts, which hinders efficient software development. Yes.

  The present invention has been made in view of the above problems, and an object of the present invention is to provide a software product management system, method, and program thereof that can improve the efficiency of software development.

  In order to achieve the above object, the software product creation system according to the present invention uses a computer to identify an influence location of another software product based on a change in content included in the software product created in software development. A software product management system that includes information input means and other software products based on data for realizing the behavior of the software included in the already created software product Storage means for storing a plurality of software products generated by creating the data in a state in which data of each software product is associated with data of other software products created based on the data And the contents of the software product data stored in the storage means Once modified by the broadcast input unit, and a specific means for extracting data of other software artifacts associated with the modified data from the storage means.

  In addition, in order to achieve the above object, the software product creation method of the present invention uses a computer to determine the influence points of other software products based on changes in the contents included in the software product created in software development. A software product management method for identifying the software product, wherein the computer stores the data contained in the other software product based on the data for realizing the behavior of the software contained in the already created software product. A plurality of software products generated by the creation are stored in a predetermined storage unit in a state in which the data of each software product and the data of other software products created based on the data are associated with each other. The contents of the software product data stored in the storage unit are stored in the predetermined information input unit. Once changed me, and extracts data of other software artifacts associated with the modified data from the storage unit.

  Furthermore, the software product management program of the present invention causes the computer to execute the software product creation method in order to achieve the object.

  Thereby, since the data for realizing the behavior of the software included in each software product is stored in a state associated with the data of other software products created based on the data, When the content of the data is changed, it is possible to extract data of another software product associated with the changed data.

  According to the software product creation system, method, and program thereof of the present invention, when the content of data for realizing the behavior of software is changed, the data of other software products associated with the changed data Can be extracted, it is possible to easily identify other static artifacts affected by the change of the static artifacts including the data and the affected parts. Therefore, the quality of the software product can be improved and the efficiency of software development can be greatly improved.

  An embodiment of the present invention will be described below with reference to the drawings.

<Premise>
Software deliverables include dynamic software deliverables (hereinafter referred to as dynamic deliverables) expressing dynamic information (tasks) for defining the behavior of software to be developed, and the software to be developed. There is a static software product (hereinafter referred to as a static product) that defines data information necessary for realizing the above, and in this embodiment, when the content of the static product is changed A software artifact management system that identifies other static artifacts that are affected by and their affected locations is described.

  A software product management system 10 according to the present invention comprises a computer mainly composed of a well-known CPU. As shown in FIG. 1, a display unit 11, an information input unit 12, a product repository 13, a concept system repository 14, and a control. It consists of part 15.

  The display unit 11 is a module for displaying information, such as a liquid crystal display, and displays a product drawing screen 20 as shown in FIG. 2 under the control of the control unit 15.

  The information input unit 12 is a module for inputting information, such as a keyboard and a mouse, and transmits input information to the control unit 15.

  The product repository 13 is a module for storing dynamic products and static products created in the software development process.

  The concept system repository 14 is a module for storing a parameter dependency structure to be described later.

  The control unit 15 is a module that is connected to the modules 11 to 14 and delivers information between the modules 11 to 14 or information obtained by combining information between the modules 11 to 14. The control unit 15 is provided with a storage device such as a ROM, and the control unit 15 controls the modules 11 to 14 by executing a program stored in the storage device.

  In addition, the artifact drawing screen 20 displays an artifact selection unit 21 for selecting a static artifact to be created or changed, and a static artifact that is a basis of the static artifact to be created. Consists of a reference unit 22 and a drawing unit 23 for displaying a static product to be created or changed, and creates a static product, selects data defined in the static product, and The change can be performed using the information input unit 12. In addition, the drawing unit 23 is provided with a registration instruction unit (not shown) for registering the created static product in the product repository 13, and instructing registration using the information input unit 12 Can be done.

<Formalization of static artifacts>
The static product describes data information (parameters) for realizing the behavior of the software. In this embodiment, as shown in FIG. 3, the parameter 30 is expressed as including three elements of a set 31, an element 32, and a relation 33. For example, when a class diagram is expressed as an example of a static product, as shown in FIG. 4, the class name is set to parameters 41a, 41b, 41c with parameters 40a, 40b, 40c, and the class attributes are elements 42a-42e. In addition, the relationship between the classes corresponds to the relations 43a and 43b, respectively.

  A set 41a called “Class-A” is connected to an attribute 42a called “attr-a1” and an element 42b called “attr-a2”, and an attribute 42b called “attr-a2” is connected to the set 41b called “Class-B”. Class-B attribute, that is, an element 42c “attr-b1” is connected. Furthermore, a Class-C attribute 41c, that is, an element 42d “attr-c1” and an element 42e “attr-c2” are connected to the set 41c “Class-C”.

  A set 41a called "Class-A" and a set 41b called "Class-B" are connected to each other by a relation 43a called "relation". A set 41a called "Class-A" and a set called "Class-C" 41c are connected to each other by a relation 43b called "relation".

  The structure expressed in this way is referred to as a parameter structure, and each parameter included in the static product is stored in the concept system repository 14 in a state converted to the parameter structure. In this case, all the parameters included in the static artifacts are formalized and stored, so that static artifacts expressed in various forms such as natural language, UML, unique graphics, etc. can be shared. It becomes possible to handle.

  The relations 43a and 43b may be generated when a developer creates a relation line between classes when creating a class diagram, or when the relations 43a and 43b are stored in the product repository 13 after the class diagram is created. It may be generated. Accordingly, whether or not the relations 43a and 43b are generated is determined by the developer arbitrarily setting.

  Even if the static deliverables have the same parameters to be expressed, the viewpoint to be expressed is different for each software development process. For example, the parameters described in the static product of the upstream process are created based on the viewpoint that it is easy for humans to understand, but the parameters described in the static product of the downstream process are implemented as software It is created based on the viewpoint of ease of implementation and the operation speed at the time of software execution. However, even if the expressed viewpoints are different, the parameters of the static product of the downstream process are based on the parameters of the static product of the upstream process, such as using the parameter of the static product of the upstream process. Created. In the present embodiment, information relating the parameters of the static product of the upstream process and the parameters of the static product of the downstream process created based thereon is expressed as a dependency.

  This dependency will be described with reference to FIG. First, a glossary as a static product created in the upstream process, a data analysis model as a static product created in the process after the glossary is created, and a process after the data analysis model is created When there is a table design drawing as a static product, parameter structures 50, 60, and 70 corresponding to the glossary, the data analysis model, and the table design drawing are stored in the concept system repository 14, respectively. Here, when one parameter of the parameter structure 60 corresponding to the data analysis model is created based on one parameter of the parameter structure 50 corresponding to the glossary, the set, element, and relation that constitute each parameter. Are related by dependency 80. The same applies to the case where one parameter of the parameter structure 70 corresponding to the table design drawing is created based on one parameter of the parameter structure 60 corresponding to the data analysis model. In this way, the relationship between the parameters of each static product is referred to as a parameter dependency structure, and the parameter dependency structure is stored in the concept system repository 14.

<Product creation>
The developer creates a static product in the drawing unit 23 after selecting the static product to be created in the product selection unit 21 of the product drawing screen 20. In this case, the format of the static product to be created may be a diagram based on UML such as a natural language, a class diagram, a table design diagram, and an object diagram. At this time, the control unit 15 converts the created static product into a parameter structure. In addition, the control unit 15 causes the reference unit 22 to display the static product created in the process upstream of the static product selected by the product selection unit 21.

  Next, the developer associates the parameter element of the static product displayed on the reference unit 22 with the parameter element of the static product displayed on the drawing unit 23. This association is performed by the developer selecting the parameter of the static product parameter displayed on the drawing unit 23 after selecting the parameter of the static product parameter displayed on the reference unit 22. In the present embodiment, using the existing GUI function, after moving the pointer to the parameter element displayed in the reference unit 22 and clicking the mouse, the parameter element of the static artifact displayed in the drawing unit 23 By clicking, it is possible to associate the elements of each parameter.

  At this time, the control unit 15 sets the interval between the parameter element selected by the reference unit 22, that is, the set, element, or relation, and the parameter element selected by the drawing unit 23, that is, the set, element, or relation. Dependency 80 is generated.

  Create the required static deliverables by repeating the above operations.

<Product registration>
After creating the static product, the developer instructs registration of the static product in the registration instruction unit of the product drawing screen 20. At this time, the control unit 15 stores the created static product in the product repository 13. The control unit 15 also includes a parameter structure corresponding to the created static product, a parameter structure corresponding to the static product displayed in the reference unit 22, and a dependency relationship 80 generated between the parameter structures. The parameter dependency structure created based on the above is stored in the concept system repository 14. In this way, the elements included in the parameter structure of each static product and the elements included in the parameter structure of another static product created based on the element are conceptually associated with each other. It is stored in the system repository 14.

  Similarly to the above, another static product is created on the product drawing screen 20 and registered. The registration of static artifacts may be performed after all static artifacts are created, or may be performed every time one static artifact is created.

<Identification of change deliverables / changes>
Identify other static artifacts that need to be changed based on some changes to the static artifacts that have already been created and registered, and their affected locations, assuming that the above artifacts have been registered The method will be described with reference to FIGS.

  First, the product designated by the developer is acquired and displayed on the product drawing screen 20 (step S1). Specifically, when the developer specifies a static product to be changed in the product selection unit 21 of the product drawing screen 20, the control unit 15 adds the specified static product to the product repository 13. And a parameter structure corresponding to the static product is obtained from the concept system repository 14. Further, the control unit 15 displays the static product acquired from the product repository 13 on the drawing unit 23 of the product drawing screen 20. Then, the developer corrects the static product in the drawing unit 23. For example, when a table design drawing is selected from the static artifacts shown in FIG. 6, the table design drawing is displayed on the drawing unit 23, and the parameter structure 70 corresponding to the table design drawing is displayed in the concept system repository 14. Obtained from.

  Next, the element corresponding to the corrected location of the static product corrected by the developer is specified using the parameter structure stored in the concept system repository 14 (step S2). Specifically, when a developer modifies an element constituting a parameter of a static product in the rendering unit 23 of the product rendering screen 20, the control unit 15 uses the existing GUI function to modify the modified element. To identify. For example, when the developer modifies the part “attr-b1” (the part surrounded by the alternate long and short dash line in the drawing) of the table design drawing of FIG. The element corresponding to “attr-b1” (the one surrounded by a bold line) is specified.

  Next, an element related to the specified element is specified based on the dependency relationship 80 (step S3). Specifically, the control unit 15 extracts an element (hereinafter referred to as a related element) associated with the identified element by the dependency relationship 80 from the concept system repository 14. In this case, the control unit 15 identifies the extracted element as an affected part. For example, among the parameters of the parameter structure 60 corresponding to the data analysis model of FIG. 6, the elements connected by the dependency relationship 80 with the elements identified in step S2 (those surrounded by bold lines) are related elements. Extracted as In addition, among the parameters of the parameter structure 50 corresponding to the glossary, elements connected with the dependency relationship 80 with the elements extracted as the related elements (those surrounded by bold lines) are also extracted as related elements. The

  Then, a static product including the related element is acquired from the product repository 13 and displayed on the product drawing screen 20, and a portion corresponding to the related element is highlighted (step S4). Specifically, the control unit 15 acquires a static product including the related element extracted in step S3 from the product repository 13, and displays the static product on the reference unit 22. At this time, the control unit 15 highlights and displays the portion corresponding to the related element in the static product displayed on the reference unit 22 so as to stand out from the portion corresponding to the other element. For example, when the data analysis model of FIG. 6 is displayed on the reference unit 22, a portion corresponding to the related element extracted in step S3 (a portion surrounded by a two-dot chain line in the drawing) is highlighted. Further, when the glossary is displayed on the reference unit 22, the part corresponding to the related element (the part surrounded by the broken line in the figure) is highlighted as described above.

  Here, after describing the operation when creating a static product, the operation when specifying a static product that is affected by the change of the static product and its affected part will be described. As a static product, a glossary, a data analysis model, and a table design drawing are created as shown in FIG. The operation for creating a data analysis model based on the glossary will be described below.

  The developer selects a data analysis model in the product selection unit 21 of the product drawing screen 20. At this time, the control unit 15 extracts, from the product repository 13, the static product created in the process upstream of the static product selected by the product selection unit 21, that is, the glossary, and refers to the glossary. This is displayed on part 22. In this case, the control unit 15 acquires the parameter structure corresponding to the glossary from the concept system repository 14.

  Next, the developer creates a data analysis model in the drawing unit 23 using the information input unit 12. In this case, the form of the product drawing screen 20 is shown as shown in FIG. Then, the developer associates the parameter element of the glossary displayed on the reference unit 22 with the parameter element of the data analysis model displayed on the drawing unit 23. For example, after the developer moves the pointer to a small item “device name” displayed in the reference unit 22 and clicks the mouse, the column “device name” of the data analysis model displayed in the drawing unit 23 is displayed. When clicked, the control unit 15 includes the parameter element selected by the reference unit 22, that is, the element “device name”, and the parameter element selected by the drawing unit 23, that is, the element “device name”. Generate dependencies between them.

  A data analysis model is created by repeating the above operation. The operation when creating the table design drawing based on the data analysis model is the same as described above.

  When the developer instructs the registration instruction unit to register the deliverable, the control unit 15 stores the glossary, the data analysis model, and the table design drawing of FIG. 8 in the deliverable repository 13 and the parameters of FIG. Register the dependency structure in the concept system repository 14.

  Here, the parameter-dependent structure of FIG. 10 will be described. The parameter structure 100 corresponding to the glossary has a set 101 called “device information” and a set 102 called “line information”. In addition, an element 101a “device name” and an element 101b “vendor name” are connected to the set 101 “device information”, and an element 102a “line ID” is connected to the set 102 “line information”. Is connected. It should be noted that no relation is set between the set 101 called “device information” and the set 102 called “line information”.

  The parameter structure 110 corresponding to the data analysis model includes a set 111 called “device information”, a set 112 called “IF information”, and a set 113 called “line information”. An element 111a called “device name” and an element 111b called “vendor name” are connected to the set 111 called “device information”, and the set 111 called “device information” corresponds to “ It is connected with a set 101 called “device information” by a dependency relationship 80. Further, the element 111a “device name” is connected to the element 101a “device name”, and the element 111b “vendor name” is connected to the element 101b “vendor name” by the dependency 80.

  To the set 112 called “IF information”, an element 112 a called “IF type” and an element 112 b called “band” are connected.

  A set 113 called “line information” is connected to an element 113a called “line ID”, and the set 113 called “line information” depends on the set 102 called “line information” in the parameter structure 100 corresponding to the glossary. Connected by relationship 80. Further, the element 113a “line ID” is connected to the element 102a “line ID” by the dependency relationship 80. The set 111 called “device information” and the set 112 called “IF information” are connected by a relation 114 called “relation”, and the set 112 called “IF information” and the set 113 called “line information” are connected to each other. They are connected by a relation 115 called “Relation”.

  Further, the parameter structure 120 corresponding to the table design drawing has a set 121 called “NE-Table”, a set 122 called “IF-Table”, and a set 123 called “Link-Table”. An element 121a called "neId", an element 121b called "neName", and an element 121c called "venderName" are connected to the set 121 called "NE-Table". The set 121 called "NE-Table" The parameter structure 110 corresponding to the data analysis model is connected to a set 111 called “device information” by a dependency relationship 80. The element 121b “neName” is connected to the element 111a “device name”, and the element 121c “venderName” is connected to the element 111b “vendor name” by the dependency 80.

  An element 122a called “ifId”, an element 122b called “ifType”, and an element 122c called “bw” are connected to the set 122 called “IF-Table”, and the set 122 called “IF-Table” The parameter structure 110 corresponding to the data analysis model is connected to a set 112 called “IF information” by a dependency relationship 80. The element 122b “ifType” is connected to the element 112a “IF type” and the element 122c “bw” is connected to the element 112b “band” by the dependency relationship 80.

  An element 123a called “linkId” is connected to the set 123 called “Link-Table”, and the set 123 called “Link-Table” is a set 113 called “line information” of the parameter structure 110 corresponding to the data analysis model. And is tied by dependency 80. The element 123a “linkId” is connected to the element 113a “line ID” by the dependency relationship 80. The set 121 called “NE-Table” and the set 122 called “IF-Table” are connected by the relation 124 called “relation”, and the set 122 called “IF-Table” and the “link-table” are called. The set 123 is connected by a relation 125 called “Relation”.

  Assuming that the above-mentioned deliverable registration has been performed, operations for identifying static deliveries that are already created and affected by changes in the data contained in the registered static deliveries and their affected locations Will be described with reference to FIG.

[Procedure 1]
When the developer specifies a table design drawing in the product selection unit 21 of the product drawing screen 20, the control unit 15 acquires the table design drawing from the product repository 13 and also sets the parameter structure 120 corresponding to the table design drawing. Is acquired from the concept system repository 14. Further, the control unit 15 displays the table design drawing acquired from the product repository 13 on the drawing unit 23 of the product drawing screen 20. Then, the developer uses the information input unit 12 to correct the table design drawing. In this example, the column “venderName” (portion surrounded by a one-dot chain line in the figure) is changed in the table design diagram of FIG.

[Procedure 2]
When the developer changes the column “venderName” in the drawing unit 23 of the product drawing screen 20, the control unit 15 acquires the parameter element corresponding to the correction location of the table design drawing from the concept system repository 14. Use structure 120 to identify. In this case, the control unit 15 specifies the correction location of the table design drawing using the GUI function, and specifies the parameter element corresponding to the location from the parameter structure 120. In this example, the element 121c “venderName” is specified in the parameter structure 120 of FIG.

[Procedure 3]
The control unit 15 specifies the parameter element “venderName” related to the element 121c based on the dependency relationship 80. Specifically, the control unit 15 extracts from the concept system repository 14 a related element that is associated with the element 121c “venderName” by the dependency relationship 80. In this example, in the parameter structure 110 corresponding to the data analysis model of FIG. 11, an element 111b “vendor name” is extracted as a related element. Further, in the parameter structure 100 corresponding to the glossary of FIG. 11, an element 101b “vendor name” is extracted as a related element.

[Procedure 4]
The control unit 15 acquires a static product including the related element from the product repository 13 and displays it on the product drawing screen 20, and highlights a portion corresponding to the related element. Specifically, the control unit 15 acquires the data analysis model and the glossary including the related elements extracted in the procedure 3 from the product repository 13 and displays them on the reference unit 22. At this time, the control unit 15 highlights the portion corresponding to the related element in the data analysis model and the glossary displayed on the reference unit 22, and thereby displays the highlighted portion more than the portion corresponding to the other element. . In this example, in the data analysis model of FIG. 11, a portion corresponding to the extracted related element (a portion surrounded by a two-dot chain line in the drawing) is highlighted. In the glossary of FIG. 11, a portion corresponding to the extracted related element (a portion surrounded by a broken line in the drawing) is also highlighted.

  In this way, when the information input unit 12 changes the data for realizing the behavior of the software, that is, the contents of the column of the table design drawing, the data analysis model and the glossary data associated with the column are extracted. It becomes possible to do.

  As described above, in the above embodiment, when the content of the data for realizing the behavior of the software is changed, data of other software artifacts associated with the changed data can be extracted. It is possible to easily identify another static product that is affected by the change of the static product including the data and its affected part. Therefore, the quality of the software product can be improved and the efficiency of software development can be greatly improved.

  Further, since the static product including the element identified as the affected part is displayed on the display unit 11, the developer can be notified of other static products that are affected by the change of the static product.

  In addition, when displaying other static artifacts, the location corresponding to the element identified as the impact location is highlighted, so the developer is surely informed of the location affected by the change of the static artifact. be able to.

  In addition, said embodiment is only a specific example of this invention, and this invention is not limited only to the said embodiment. For example, the present invention can also be realized by installing a program having the above-described creation procedure via a recording medium or a communication line in a known computer.

The figure which shows the structure of the software product management system in one Embodiment of this invention. Figure showing the product drawing screen Diagram showing parameter structure Diagram showing the relationship between static artifacts and parameter structure Diagram showing parameter-dependent structure The figure which shows the outline of the identification method of the influence part using a parameter dependence structure Flow diagram showing the operation when identifying the location affected by the change Diagram showing examples of glossary, data analysis model and table design Diagram showing the product drawing screen when creating a static product Diagram showing parameter-dependent structure The figure which shows the outline of the identification method of the influence part using a parameter dependence structure

Explanation of symbols

  10 ... Software deliverable management system, 11 ... Display section, 12 ... Information input section, 13 ... Product repository, 14 ... Concept repository, 15 ... Control section, 30,40a-40c ... Parameter, 31,41a-41c ... Set, 32, 42a to 42e ... element, 33, 43a, 43b ... relation, 80 ... dependency.

Claims (7)

A software product management system for identifying, using a computer, an affected part of another software product based on a change in content included in a software product created in software development,
The computer
Information input means;
A plurality of software artifacts generated by creating the data included in other software artifacts based on the data for realizing the behavior of the software included in the already generated software artifacts, each software Storage means for storing the product data in association with data of other software products created based on the data;
When the content of the data of the software product stored in the storage means is changed by the information input means, a specific means for extracting the data of other software products associated with the changed data from the storage means is provided. Software deliverable management system characterized by The computer
The software product management system according to claim 1, further comprising display means for displaying a software product including data extracted by the specifying means. The display means includes
The software product management system according to claim 2, wherein when displaying the software product, a portion corresponding to the extracted data is displayed more prominently than a portion corresponding to other data. A software product management method for identifying, using a computer, an affected area of another software product based on a change in content included in a software product created in software development,
The computer
A plurality of software artifacts generated by creating the data included in other software artifacts based on the data for realizing the behavior of the software included in the already generated software artifacts, each software Store the product data in association with the data of other software products created based on the data in a predetermined storage unit,
When the content of the software product data stored in the storage unit is changed by a predetermined information input unit, the data of another software product associated with the changed data is extracted from the storage unit. Software deliverable management method. The computer
The software product management method according to claim 4, wherein a software product including the extracted data is displayed on a predetermined display unit. The computer
6. The software product management method according to claim 5, wherein a portion corresponding to the data extracted when displaying the software product is displayed more prominently than a portion corresponding to other data.   A software product creation program for causing a computer to execute the method according to any one of claims 4 to 6.

Images