JP7370264B2 - Traceability management device, traceability management method, and traceability management program - Google Patents

Description

The present disclosure relates to a traceability management device, a traceability management method, and a traceability management program that detect traceability missing candidates during software development.

For traceability management during software development, a technology has been proposed that acquires traceability information based on special tags (identification character strings) written in specifications and source code, and displays the traceability information in tree or table format. has been done.

In addition, a technology has been proposed that takes source code or UML (Unified Modeling Language) as input, acquires the dependencies between elements of the source code or UML, and creates a table called a DSM (Design Structure Matrix) for the dependencies. There is. In addition, a concept called MDM (Multi Domain Matrix) has been proposed in which a matrix is created by connecting DSMs of multiple domains. In this MDM, a DSM that shows dependencies between elements of the same domain is placed in the diagonal area of the matrix, and a DMM (Domain Mapping Matrix) that shows the correspondence between elements of different domains is placed in other areas. Ru.

Furthermore, a technique has been proposed for detecting architecture collapse in source code using architecture dependencies, source code dependencies, and traceability information (for example, Patent Document 1). In addition to this, a technique has been proposed that uses source code dependencies and traceability information to detect locations affected by changes during software modification (for example, Patent Document 2).

Japanese Patent Application Publication No. 2008-102831 Japanese Patent Application Publication No. 2016-110330

With conventional traceability management technology, it is necessary to manually edit traceability information tags when changes occur in specifications or source code. However, in development where software specifications frequently change, there is a possibility that traceability information may be missing due to missing tag editing. When traceability information is missing, the time required to understand the specifications increases, causing an increase in the number of software development steps. Furthermore, the techniques disclosed in Patent Document 1 and Patent Document 2 do not detect missing traceability information, and there is a problem in that the software developer has to perform detection work.

Therefore, the present disclosure has been made in view of the above problems, and aims to provide a technology that can reduce the number of software development steps.

The traceability management device according to the present disclosure creates MDM information based on dependencies between specifications in software, dependencies between elements of source code, and traceability information including correspondence between the specifications and the elements. an MDM creation unit that extracts dependable elements from among the elements of the source code as dependent locations based on the dependency relationships between the specifications and the traceability information, or the MDM information. and a version management unit that extracts difference information between the MDM information and past MDM information created in the past than the MDM information, and based on the MDM information, the dependent locations, and the difference information, and a traceability missing analysis unit that extracts missing candidates in the correspondence relationship of the traceability information as traceability missing candidates.

According to the present disclosure, based on the MDM information, the dependable elements of the source code of the MDM information, the dependable locations, and the difference information between the MDM information and past MDM information, the correspondence relationship of traceability information is determined. Extract missing candidates as traceability missing candidates. This makes it possible to reduce the number of software development steps.

1 is a block diagram showing the configuration of a traceability loss detection device according to Embodiment 1. FIG. FIG. 3 is a diagram for explaining the operation of the traceability loss detection device according to the first embodiment. 1 is a diagram showing the structure of software according to Embodiment 1. FIG. 3 is a diagram showing a specification dependency list according to Embodiment 1. FIG. FIG. 3 is a diagram showing a source code dependency list according to the first embodiment. FIG. 3 is a diagram showing a traceability list according to the first embodiment. 3 is a diagram showing MDM information according to Embodiment 1. FIG. 3 is a diagram showing a list of possible dependencies according to the first embodiment; FIG. FIG. 3 is a diagram in which information on dependable locations is added to MDM information according to Embodiment 1; FIG. 3 is a diagram showing the structure of software (after the first change) according to the first embodiment. FIG. 3 is a diagram showing a source code dependency list (after first change) according to the first embodiment. FIG. 3 is a diagram showing MDM information (after first change) according to the first embodiment. FIG. 3 is a diagram showing an MDM difference list (after first change) according to Embodiment 1; FIG. 3 is a diagram in which information on dependable locations is added to MDM information according to Embodiment 1; FIG. 3 is a diagram showing a traceability missing list (after first change) according to the first embodiment. FIG. 3 is a diagram in which information on a traceability missing list is added to MDM information according to the first embodiment. FIG. 7 is a diagram showing a specification dependency list (after second change) according to the first embodiment. FIG. 3 is a diagram in which information on dependable locations is added to MDM information according to Embodiment 1; FIG. 7 is a diagram showing an MDM difference list (after second change) according to the first embodiment. FIG. 7 is a diagram showing a traceability missing list (after second change) according to the first embodiment. FIG. 3 is a diagram in which information on a traceability missing list is added to MDM information according to the first embodiment. FIG. 7 is a diagram showing a specification dependency list (after third change) according to Embodiment 1; FIG. 3 is a diagram in which information on dependable locations is added to MDM information according to Embodiment 1; FIG. 7 is a diagram showing an MDM difference list (after third change) according to the first embodiment. FIG. 7 is a diagram showing a traceability missing list (after third change) according to the first embodiment. FIG. 3 is a diagram in which information on a traceability missing list is added to MDM information according to the first embodiment. FIG. 2 is a block diagram showing the configuration of a traceability loss detection device according to Modification 1 of Embodiment 1. FIG. FIG. 2 is a block diagram showing the configuration of a lack of traceability detection device according to a second embodiment. FIG. 7 is a diagram for explaining the operation of the traceability loss detection device according to the second embodiment. FIG. 7 is a diagram showing the structure of software (after the fourth change) according to the second embodiment. FIG. 7 is a diagram showing a traceability list (after fourth change) according to Embodiment 2; FIG. 12 is a diagram in which information on dependable locations is added to MDM information according to Embodiment 2; FIG. 7 is a diagram showing an MDM difference list (after fourth change) according to the second embodiment. FIG. 12 is a diagram showing a missing dependency list (after fourth change) according to the second embodiment. FIG. 7 is a diagram in which information on a dependency relationship missing list is added to MDM information according to Embodiment 2; FIG. 7 is a diagram showing a missing dependency list (after third change) according to the second embodiment. FIG. 7 is a diagram in which information on a dependency relationship missing list is added to MDM information according to Embodiment 2;

<Embodiment 1>
<Configuration>
FIG. 1 is a block diagram showing the configuration of a traceability missing detection device 10, which is a traceability management device according to the first embodiment. Note that the traceability management device is not limited to the traceability missing detection device 10, and may have functions other than traceability missing detection.

The traceability missing detection device 10 is, for example, a computer. The traceability loss detection device 10 includes a processor 11, a memory 12, a storage 13, and a communication interface 14 as hardware.

The processor 11 is connected to other hardware of the traceability loss detection device 10 via a signal line, and controls the other hardware. The processor 11 is an IC (Integrated Circuit) that performs processing. The processor 11 is, for example, a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or a GPU (Graphics Processing Unit).

The memory 12 is a storage device that temporarily stores data processed by the processor 11. The memory 12 is, for example, SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory).

The storage 13 is a storage device that stores data that is stored in the memory 12 from time to time. The storage 13 is, for example, an HDD (Hard Disk Drive). The storage 13 also includes, for example, an SD (registered trademark, Secure Digital) memory card, a CF (CompactFlash (registered trademark)), a NAND flash, a flexible disk, an optical disk, a compact disc, a Blu-ray (registered trademark) disk, a DVD (Digital Versatile). It may also be a portable storage medium such as a disk.

The communication interface 14 is an interface for communicating with a device outside the traceability loss detection device 10. The communication interface 14 is, for example, an Ethernet (registered trademark), USB (Universal Serial Bus), or HDMI (registered trademark: High-Definition Multimedia Interface) port.

The traceability missing detection device 10 includes an MDM creation section 21, a dependent location analysis section 22, a version management section 23, and a traceability missing analysis section 24 as functional components. The functions of the MDM creation unit 21, possible dependence analysis unit 22, version management unit 23, and lack of traceability analysis unit 24 are realized by software, for example.

The storage 13 stores programs that implement the functions of the MDM creation section 21, possible dependence analysis section 22, version management section 23, and lack of traceability analysis section 24. This program is read into the memory 12 by the processor 11 and executed by the processor 11. Thereby, the functions of the MDM creation section 21, possible dependence part analysis section 22, version management section 23, and traceability omission analysis section 24 are realized.

In FIG. 1, the traceability loss detection device 10 includes one processor 11, but may include a plurality of processors in place of one processor 11. These plurality of processors share the execution of a program that implements the functions of the MDM creation section 21, possible dependence analysis section 22, version management section 23, and traceability omission analysis section 24. Each processor, like the processor 11, is an IC that performs processing.

The display device 19 is connected to the traceability missing detection device 10 via a wireless or wired connection, and the traceability missing detection device 10 can control the display on the display device 19. Although the display device 19 is provided outside the traceability missing detection device 10 in FIG. 1, the display device 19 may be provided in the traceability missing detection device 10.

<Operation>
FIG. 2 is a diagram for explaining the operation of the traceability loss detection device 10 according to the first embodiment. FIG. 3 is a diagram showing an example of the structure of software for explaining the operation of the traceability loss detection device 10 according to the first embodiment, and is a conceptual diagram showing various relationships. In FIG. 3, for example, function a corresponding to function A of the specification calls function b corresponding to function B of the specification, and function b corresponding to function B calls variable α corresponding to function B. It is shown that it can be used.

Note that the operation of the traceability loss detection device 10 according to the first embodiment corresponds to the traceability loss detection according to the first embodiment. Further, the operation of the traceability missing detection device 10 according to the first embodiment corresponds to the processing of the traceability missing detection program according to the first embodiment.

<Processing of MDM creation unit 21>
As shown in FIG. 2, the MDM creation unit 21 receives input of a specification dependency list 31, a source code dependency list 32, and a traceability list 33 via the communication interface 14, and writes these lists into the memory 12. . The MDM creation unit 21 refers to the dependency relationship at the specification level, that is, the dependency relationship between specifications in software, from the specification dependency relationship list 31. The MDM creation unit 21 refers to the dependencies at the source code level, that is, the dependencies between source code elements, from the source code dependency list 32. The MDM creation unit 21 refers to the correspondence between specifications and source code elements included in the traceability list 33.

The specification dependency relationship list 31 is a list of dependency relationships at the specification level. For example, the specification dependency relationship list 31 is a list that links a dependent function and a dependent function as shown in FIG. 4. The dependence sources and dependencies of specifications may be modules that constitute software, files, folders, etc., instead of functions. Dependency relationships refer to function calling relationships, variable reference relationships, and functional relationships caused by these relationships. For example, when a function of one function refers to a variable of another function, it means that there is a dependency relationship at the specification level between the function of one function that corresponds to the function and another function that corresponds to the variable. do. In this case, one function corresponding to the function becomes the dependent function, and another function corresponding to the variable becomes the dependent function.

Note that the specification dependency list 31 in FIG. 4 corresponds to the software structure in FIG. 3, and the function on the side without the arrow head in FIG. The functions on the side where the arrowhead is located are listed as dependencies in FIG. The specification dependency list 31 may be created manually by referring to specifications, data indicating architecture, etc., or may be created automatically using a tool or script.

The source code dependency list 32 is a list of dependencies at the source code level. For example, the source code dependency relationship list 32 is a list in which dependent elements and dependent elements are linked, as shown in FIG. The elements here include, for example, functions and variables in the source code. In the case of variable references, the dependent source is the function that references the variable, and the dependent destination is the referenced variable. In the case of a function call, the dependent is the calling function, and the dependent is the called function.

Note that the source code dependency list 32 in FIG. 5 corresponds to the software structure in FIG. 3, and the function on the side without the arrow head in FIG. The function or variable on the side with the arrow head is described as the dependent in FIG. 5. The source code dependency list 32 may be created manually by referring to the source code, or may be created automatically using a tool or script. The source code dependency list 32 may hold related information such as the type of each element of the source code and the file to which each element belongs, the dependency type, and the like.

The traceability list 33, which is traceability information, is a list of correspondence between specifications and source code elements. For example, the traceability list 33 is a list that links specifications functions and source code elements as shown in FIG. For example, a correspondence relationship between a specification and a source code element indicates that a function defined in the specification is realized by the source code element.

Note that the traceability list 33 in FIG. 6 corresponds to the software structure in FIG. 3, and there is a correspondence relationship between the functions in FIG. 3 and the functions or variables in the frame attached to the functions. is listed. The traceability list 33 may be created manually by referring to the source code, or may be created automatically using a tool or script. The traceability list 33 may hold related information such as the type of each element of the source code and the file to which each element belongs.

Now, as shown in FIG. 2, the MDM creation unit 21 creates MDM information 34 based on the specification dependency list 31, the source code dependency list 32, and the traceability list 33.

The MDM information 34 is information that summarizes the dependencies in the specification dependency list 31, the dependencies in the source code dependency list 32, and the correspondences in the traceability list 33. For example, as shown in FIG. 7, the MDM information 34 is in a tabular format in which each column of the first row is a dependency source of a dependency relationship or a function of traceability, and each row of the first column is a dependency destination of a dependency relationship or an element of traceability. etc.

In the case of a table format as shown in FIG. 7, the upper left area from the second row to the fifth row and from the second column to the fifth column is an area based on the specification dependency list 31, which shows the dependencies at the specification level. This is the DSM that shows. The lower right area from the 6th line to the 13th line and from the 6th column to the 13th column is an area based on the source code dependency relationship list 32, and is a DSM indicating dependency relationships at the source code level. The lower left area from the 6th line to the 13th line and from the 2nd column to the 5th column is an area based on the traceability list 33, and serves as a DMM indicating the correspondence between specifications and source code elements. The upper right area from the 2nd line to the 5th line and the 6th column to the 13th column may not be used, or the same information as the DMM in the lower left area may be written. The MDM information 34 is not limited to a table format, but may be in a list format, for example.

Next, an example of the processing of the MDM creation unit 21 will be specifically described with reference to FIGS. 3 to 7.

The MDM creation unit 21 extracts dependency relationships at the specification level from the specification dependency relationship list 31 shown in FIG. For example, as shown in the second line of FIG. 4, if there is a dependency relationship from the dependent function A to the dependent function B, the MDM creation unit 21 Extract B.

The MDM creation unit 21 extracts dependencies at the source code level from the source code dependency list 32 shown in FIG. For example, as shown in the second line of FIG. 5, if there is a dependency relationship from the dependent function a to the dependent function b, the MDM creation unit 21 b.

The MDM creation unit 21 extracts the correspondence between specifications and source code elements from the traceability list 33 shown in FIG. For example, as shown in the second line of FIG. 6, when function A defined in the specification corresponds to function a in the source code, the MDM creation unit 21 determines the correspondence between function A and function a. Extract.

The MDM creation unit 21 creates a matrix of the extracted dependence sources and dependencies at the specification level, the extracted dependence sources and dependencies at the source code level, and the correspondence relationships between the extracted specification and source code elements, and creates a matrix. The MDM information 34 shown in 7 is created. For example, the "○" in the 3rd row and 2nd column in Figure 7 is marked based on the extraction result in the 2nd row in Figure 4, and indicates that there is a dependency relationship from the dependent function A to the dependent function B. Show that. Further, the "○" in the 7th row and 6th column of FIG. 7 is attached based on the extraction result of the second row of FIG. 5, and indicates that there is a dependency relationship from function a to function b. Moreover, the "○" in the 6th row and 2nd column of FIG. 7 is attached based on the extraction result of the 2nd row of FIG. 6, and indicates that function A and function a correspond.

The MDM creation unit 21 writes the created MDM information 34 into the memory 12.

<Processing of the possible dependence part analysis unit 22>
As shown in FIG. 2, the dependent location analysis unit 22 creates a dependent location list 35 at the source code level based on the MDM information 34 created by the MDM creation unit 21. Here, an example will be described in which the dependent location analysis unit 22 creates the dependent location list 35 based on the dependency relationship at the specification level in the MDM information 34 and the correspondence relationship of traceability in the MDM information 34. do. Note that the dependent location analysis unit 22 may create the dependent location list 35 not based on the MDM information 34 but based on the specification dependency list 31 and the traceability list 33.

The dependable location list 35 is a list indicating dependable elements among the elements of the source code as dependable locations. Dependable means that, when dependencies at the specification level are regarded as architecture, the dependencies at the corresponding source code level do not break the architecture. For example, the list of possible dependencies 35 is a list that links the dependencies and dependencies of possible dependencies at the source code level, as shown in FIG.

The processing of the dependable location analysis unit 22 will be described with reference to FIGS. 3 to 8.

The dependent location analysis unit 22 extracts dependency relationships at the specification level and traceability correspondence relationships from the MDM information 34.

The possible dependence part analysis unit 22 comprehensively allocates source code level elements associated with traceability to each of the dependence source and dependence target of the dependency relationship at the specification level, and comprehensively identifies combinations of elements. demand. Then, the possible dependence part analysis unit 22 creates a possible dependence part list 35 showing all the combinations obtained as shown in FIG. For example, in the configuration of FIG. 3, there is a dependency relationship from function A to function B, where function A corresponds to function a and function B corresponds to function b and variable α. The dependence relationship and the dependence relationship from the function a to the variable α are written in the possible dependence location list 35.

The dependent location analysis unit 22 writes the created dependent location list 35 into the memory 12.

Note that the possible dependence location analysis unit 22 may add information on possible dependence locations to the MDM information 34 as shown in FIG. In FIG. 9, for example, hatching is added to the background of the cell in the 7th row and 6th column that indicates the dependency relationship from function a to function b, indicating that function a can depend on function b. There is. Note that the method of adding information is not limited to changing the background of the cell.

<Processing of version management unit 23>
As shown in FIG. 2, the version management unit 23 receives input of the previous MDM information 36 via the communication interface 14, for example, and writes it into the memory 12. The previous MDM information 36 is past MDM information created earlier than the MDM information 34 created by the MDM creation unit 21, and is, for example, information in the same format as the MDM information 34.

The version management unit 23 creates an MDM difference list 37 based on the MDM information 34 created by the MDM creation unit 21 and the previous MDM information 36. The MDM difference list 37 is a list of difference information between the MDM information 34 and the previous MDM information 36, and the details will be described later.

The processing of the version management unit 23 will be explained with reference to FIGS. 10 to 13.

FIG. 10 is a diagram showing an example of a software structure after changes have been made to the software structure of FIG. In FIG. 10, a dependency relationship from function a of function A to function g has been added, indicating that the function to which function g corresponds is unknown. In the following description, the change from the software structure in FIG. 3 to the software structure in FIG. 10 will be referred to as a "first change."

When the first change is made, the MDM creation unit 21 creates the source code dependency list 32 in FIG. 11 in which the dependency relationship from the dependent function a to the dependent function g is added instead of the source code dependency list 32 in FIG. MDM information 34 is created using the source code dependency list 32.

FIG. 12 is a diagram showing MDM information 34 created by the MDM creation unit 21 using the source code dependency list 32 of FIG. 11. In the explanation regarding the first change, the MDM information 34 in FIG. 12 is the MDM information 34 created by the MDM creation unit 21 after the first change, and the MDM information 34 in FIG. 7 is the previous MDM information 36. do. In the MDM information 34 in FIG. 12, an item of function g is added to each of the dependency source in the first row and the dependency destination in the first column of the MDM information 34 in FIG. ing.

The version management unit 23 extracts the difference between the MDM information 34 in FIG. 12 created by the MDM creation unit 21 and the previous MDM information 36 in FIG. 7, and creates an MDM difference list 37 as shown in FIG. . For example, the MDM difference list 37 is a list in which rows and columns of the MDM information table are associated with change types. The change types include, for example, addition or deletion of traceability correspondence, addition or deletion of dependency at the specification level or source code level, and the like. The first line in Figure 13 indicates that a change has been made at the source code level, and the second line in Figure 13 indicates that a dependency relationship has been added from function a to function g. has been done. The MDM difference list 37 may include information indicating whether each piece of difference information is specification dependency difference information, source code dependency difference information, or traceability correspondence difference information.

The version management unit 23 writes the created MDM difference list 37 into the memory 12.

Note that the previous MDM information 36 written in the memory 12 is not limited to the previous MDM information 36 received via the communication interface 14. For example, the version management unit 23 may write the MDM information 34 into the memory 12 as old MDM information. Then, during the next operation, the version management unit 23 may use the old MDM information written in the memory 12 as the previous MDM information 36.

Further, the version management unit 23 may cause the memory 12 to hold only the latest old MDM information 34, or may cause the memory 12 to hold a plurality of pieces of old MDM information 34. Further, the version management unit 23 extracts difference information between the previous MDM information 36 and the MDM information 34 by using the old MDM information 34 of a specific version among the plurality of retained old MDM information 34 as the previous MDM information 36. You may do so. Further, the version management unit 23 uses the old MDM information 34 of a specific version as the previous MDM information 36, uses the old MDM information 34 of another specific version as the MDM information 34, and uses the previous MDM information 36 and the MDM information 34. You may also extract differential information between the two.

<Processing of traceability missing analysis unit 24>
As shown in FIG. 2, the traceability missing analysis unit 24 identifies missing candidates in the correspondence relationship of traceability information, that is, the possibility of missing, based on the MDM information 34, the list of possible dependencies 35, and the MDM difference list 37. A certain combination is extracted (detected) as a traceability missing candidate. For example, the traceability missing analysis unit 24 determines a method for checking traceability missing candidates based on the MDM difference list 37. Then, the traceability missing analysis unit 24 extracts traceability missing candidates in the MDM information 34 based on the MDM information 34 and the dependent location list 35 according to the determined confirmation method.

The traceability missing analysis unit 24 creates a traceability missing list 38 indicating the extraction results, that is, traceability missing candidates. The traceability missing list 38 is a list of missing candidates when there is a possibility that there is a missing traceability correspondence due to a change in MDM, and the details will be described later.

In the first embodiment, the traceability loss analysis unit 24 controls the display device 19 (FIG. 1) to display the MDM information 34 and the traceability loss list 38 of the MDM information 34.

Next, with reference to FIGS. 13 to 16, the processing of the traceability loss analysis unit 24 when the first change is performed will be described.

The traceability missing analysis unit 24 acquires the change type of difference information from the MDM difference list 37 created by the version management unit 23. As in the example of FIG. 13, when a dependency relationship from function a to function g is added, the traceability missing analysis unit 24 acquires the addition of a dependency relationship at the source code level as the change type.

When the change type is addition of source code level dependencies, the traceability missing analysis unit 24 determines whether the added source code level dependencies are dependent based on the MDM information 34 and the list of possible dependencies 35. Check whether it is.

FIG. 14 is a diagram showing MDM information in which the contents of the dependent location list 35 are reflected when the first change is made. In FIG. 14, for convenience of explanation, the dependent locations in the dependent location list 35 are reflected by hatching, as in FIG. 9.

The added dependency cell, that is, the cell in the 12th row and 6th column indicating the dependent location from function a to function g, is marked with "O" but is not hatched. In such a case, the traceability loss analysis unit 24 determines that dependence is not possible, that is, there is an architecture violation. At this time, information indicating that the architecture is violated may be added to the MDM information 34 as shown in FIG. As an example, in FIG. 14, the frame of the cell indicating the dependency from function a to function g in the 12th row and 6th column is made into a thick frame, indicating that the dependency relationship from function a to function g is an architectural violation. It has been shown that However, the method of adding information is not limited to changing the cell border.

If the added dependency relationship does not include an architecture violation, the traceability loss analysis unit 24 determines that there is no traceability loss, and outputs an empty traceability loss list 38.

If the added dependency relationship includes an architecture violation, the traceability loss analysis unit 24 detects a traceability correspondence relationship that can be added to eliminate the architecture violation. In the case of the example in FIG. 14, since function g does not correspond to any function, the traceability missing analysis unit 24 reads function a that has a dependency relationship with function g from the MDM information, and selects function A to which function a corresponds. Read from MDM information. Next, the traceability missing analysis unit 24 extracts functions B and C on which function A is a dependency source, in the same way that function a is a dependency source of function g, and function g is a dependency source of function B and function C. It is determined that it corresponds to

The traceability missing analysis unit 24 lists the correspondence between function g and function B and the correspondence between function g and function C, and creates a traceability missing list 38 as shown in FIG. For example, like the traceability list 33 in FIG. 6, the traceability missing list 38 is a list showing the correspondence between specifications and source code elements. The traceability missing list 38 may include information on related MDM differences.

Here, if both or one of function a and function g does not correspond to any of the functions, the traceability missing analysis unit 24 outputs all functions as traceability missing candidates for each of function a and function g. You may do so.

Furthermore, if the traceability missing analysis unit 24 cannot find a correspondence that eliminates the architecture violation, it may output an empty traceability missing list 38 or output all functions as traceability missing candidates. You may do so.

The traceability loss analysis unit 24 writes the traceability loss list 38 into the memory 12. Further, the traceability missing analysis unit 24 outputs a traceability missing list 38 via the communication interface 14. The output traceability missing list 38 is displayed on the display device 19 or the like.

Note that the traceability loss analysis unit 24 may add information of the traceability loss list 38 to the MDM information 34 as shown in FIG. 16. For example, the traceability loss analysis unit 24 may make the background of the cell showing the correspondence between function B and function g and the correspondence between function C and function g in the 12th row of FIG. 16 black. This indicates that there is a possibility of lack of traceability in the correspondence between function B and function g or in the correspondence between function C and function g. The method of adding information is not limited to changing the background color of the cell. The traceability loss analysis unit 24 may output at least one of the traceability loss list 38 in FIG. 15 and the information-added MDM information 34 in FIG. 16 via the communication interface 14.

With reference to FIGS. 17 to 21, the processing of the traceability loss analysis unit 24 when a change different from the first change is made will be described. In the following, it is assumed that the specification dependency list 31 in FIG. 4 is changed to the specification dependency list 31 in FIG. 17 after adding the correspondence between function C and function g through the first change. In the following description, the change from the specification dependency relationship list 31 in FIG. 4 to the specification dependency relationship list 31 in FIG. 17 will be referred to as a "second change."

When the second change is made, the MDM creation unit 21 creates the MDM information 34 using the specification dependency list 31 of FIG. 17 instead of the specification dependency list 31 of FIG. 4. The possible dependence part analysis unit 22 creates a list of possible dependence parts 35 at the source code level based on the MDM information 34.

FIG. 18 is a diagram showing the MDM information 34 in which the contents of the dependent location list 35 are reflected when the second change is made. In FIG. 18, for convenience of explanation, the dependent locations in the dependent location list 35 are shown by hatching, as in FIG. 14.

Based on the MDM information 34 after the second change and the previous MDM information 36 before the second change, the version management unit 23 generates the information shown in FIG. Create an MDM difference list 37. The traceability missing analysis unit 24 acquires the change type of difference information from the MDM difference list 37 created by the version management unit 23. As in the example of FIG. 19, when the dependency relationship from function C to function D is deleted, the traceability loss analysis unit 24 acquires the deletion of the dependency relationship at the specification level as the change type.

When the change type is deletion of dependencies at the specification level, the traceability missing analysis unit 24 determines whether each of the dependencies at the existing source code level can depend, based on the MDM information 34 and the list of possible dependencies 35. Check whether it is.

In the example of FIG. 18, there is a dependency relationship from function c to function d, a dependency relationship from function c to function f, a dependency relationship from function e to function f, and a dependency relationship from function e to variable β. , is not included in the dependent location list 35. In such a case, the traceability loss analysis unit 24 determines that dependence is not possible, that is, there is an architecture violation.

If the existing dependency relationship does not include an architecture violation, the traceability loss analysis unit 24 determines that there is no traceability loss, and outputs an empty traceability loss list 38.

If an existing dependency relationship includes an architecture violation, the traceability missing analysis unit 24 detects a traceability correspondence relationship that can be added to eliminate the architecture violation. For example, in FIG. 3, function c corresponds to function C, and function d corresponds to function D. In this case, if function c is changed to also correspond to function D, there is no dependency relationship from function A to function D that corresponds to function a, so the dependency relationship from function a to function c is It is a violation. On the other hand, if function d is changed to also support function C, there is a dependency relationship from function A to function C that corresponds to function a, so function C can be changed to function C without causing a new architectural violation. The architectural violation of the dependency on d can be removed.

Therefore, the traceability missing analysis unit 24 extracts the correspondence between the function d and the function C. Similarly, the traceability missing analysis unit 24 also extracts the correspondence between the function f and the function C, and the correspondence between the variable β and the function C. Then, the traceability missing analysis unit 24 lists the extracted correspondence relationships and creates a traceability missing list 38 as shown in FIG. 20.

Here, if the traceability missing analysis unit 24 cannot find a correspondence that eliminates the architecture violation, it may output an empty traceability missing list 38, or it may select all functions as traceability missing candidates. You can also output it.

Note that the traceability loss analysis unit 24 may add information of the traceability loss list 38 to the MDM information 34 as shown in FIG. 21. For example, the traceability loss analysis unit 24 may make the background of the cell in the 9th row and 4th column of FIG. 21, which indicates the correspondence between the function C and the function d, black. This indicates that there is a possibility of lack of traceability in the correspondence between function C and function d. The method of adding information is not limited to changing the background color of the cell.

With reference to FIGS. 22 to 26, the processing of the traceability loss analysis unit 24 when a change different from the first change and the second change is made will be described. In the following, it is assumed that the specification dependency list 31 in FIG. 4 is changed to the specification dependency list 31 in FIG. 22 after adding the correspondence between function C and function g through the first change. In the following description, the change from the specification dependency relationship list 31 in FIG. 4 to the specification dependency relationship list 31 in FIG. 22 will be referred to as a "third change."

When the third change is made, the MDM creation unit 21 creates the MDM information 34 using the specification dependency list 31 of FIG. 22 instead of the specification dependency list 31 of FIG. 4. The possible dependence part analysis unit 22 creates a list of possible dependence parts 35 at the source code level based on the MDM information 34.

FIG. 23 is a diagram showing the MDM information 34 in which the contents of the dependent location list 35 are reflected when the third change is made. In FIG. 23, for convenience of explanation, the dependent locations in the dependent location list 35 are shown by hatching, as in FIG. 14.

Based on the MDM information 34 after the third change and the previous MDM information 36 before the third change, the version management unit 23 generates a diagram in FIG. Create an MDM difference list 37. The traceability missing analysis unit 24 acquires the change type of difference information from the MDM difference list 37 created by the version management unit 23. As in the example of FIG. 24, when a dependency relationship from function B to function D is added, the traceability missing analysis unit 24 acquires the addition of a dependency relationship at the specification level as the change type.

When the change type is the addition of a dependency relationship at the specification level, the traceability missing analysis unit 24 determines the dependence source function and dependence in the dependency relationship at the source code level based on the MDM information 34 and the list of possible dependencies 35. Check the combination of traceability information correspondences that will not cause an architecture violation with the previous function.

For example, in FIG. 3, when variable α corresponding to function B is associated with function D, a dependency relationship from function B to function D is added while the dependency relationship from function b to variable α is maintained. Therefore, the traceability loss analysis unit 24 extracts a correspondence relationship between function D and variable α that allows adding a dependency relationship from function B to function D without causing an architecture violation. Similarly, when function c corresponding to function C is associated with function B, the dependency relationship from function B to function D is added while the dependency relationship from function c to function d and function f is maintained. Therefore, the traceability loss analysis unit 24 extracts a correspondence relationship between function B and function c that allows adding a dependency relationship from function B to function D without causing an architecture violation. Similarly, the traceability loss analysis unit 24 also extracts the correspondence between function B and function e. Then, the traceability missing analysis unit 24 lists the extracted correspondence relationships and creates a traceability missing list 38 as shown in FIG. 25.

Here, if a new correspondence that does not result in an architecture violation cannot be found, the traceability missing analysis unit 24 may output an empty traceability missing list 38.

Note that the traceability loss analysis unit 24 may add information of a traceability loss list 38 to the MDM information 34 as shown in FIG. 26. For example, the traceability loss analysis unit 24 may change the frame line of the cell in the 8th row and 3rd column of FIG. 26, which indicates the correspondence between function B and function c, to a thick dashed frame. This indicates that there is a possibility of lack of traceability in the correspondence between function B and function c. Here, what distinguishes it from the black background in Figure 21 is that the MDM information 34 in Figure 21 will violate the architecture if it remains as it is, and changes are required, whereas the MDM information 34 in Figure 26 will remain as it is. However, it does not violate the architecture and the change is not required. The method of adding information is not limited to changing the background color or frame line of the cell. For example, as long as it can be distinguished from the display in FIG. 21, the background color may be changed in the same manner as in FIG. 21.

When the change type is deletion of source code dependencies, or when the change type is addition or deletion of traceability correspondence, the traceability missing analysis unit 24 according to the first embodiment deletes an empty traceability relationship. A missing list 38 may also be created.

If there are a plurality of combinations of change types in the difference information, the traceability loss analysis unit 24 performs the same process as described above for each change type. For example, a case will be described in which a specification dependency relationship from function B to function D is added and a source code dependency relationship is added from function b to function h at the same time. In this case, the traceability missing analysis unit 24 first determines the correspondence between function B and function c, the correspondence between function B and function e, and the function The correspondence between D and the variable α is recorded in the traceability missing list 38. Next, regarding the addition of the source code dependency from function b to function h, the traceability missing analysis unit 24 analyzes the correspondence between function B and function h and the correspondence between function D and function h due to traceability loss. It is described in List 38.

<Summary of Embodiment 1>
The traceability missing detection device 10 according to the first embodiment as described above can detect traceability missing candidates when the specification or source code is changed. In this way, by automatically discovering traceability defects, it is possible to reduce the time taken by software developers to visually detect traceability defects and the time required to understand specifications due to traceability defects. This makes it possible to reduce the number of software development steps.

<Modification 1>
In the first embodiment, the functions of the MDM creation section 21, possible dependence part analysis section 22, version management section 23, and traceability omission analysis section 24 of the traceability omission detection device 10 are realized by software. However, as a first modification, the functions of the MDM creation unit 21, possible dependence analysis unit 22, version management unit 23, and traceability loss analysis unit 24 may be realized by hardware. Regarding this first modification, differences from the first embodiment will be explained.

FIG. 27 is a block diagram showing the configuration of the traceability loss detection device 10 according to the first modification.

When the functions of the MDM creation section 21, possible dependence analysis section 22, version management section 23, and traceability omission analysis section 24 are realized by hardware, the traceability omission detection device 10 includes the processor 11, the memory 12, and the A processing circuit 15 is provided in place of the storage 13. The processing circuit 15 is a dedicated electronic circuit that realizes the functions of an MDM creation section 21, a dependent location analysis section 22, a version management section 23, a traceability omission analysis section 24, a memory 12, and a storage 13. be.

The processing circuit 15 includes a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, a logic IC, a GA (Gate Array), an ASIC (Application Specific Integrated Circuit), and an FPGA (Field-Programmable Gate Array). y) is is assumed.

The functions of the MDM creation section 21, the dependent part analysis section 22, the version management section 23, and the traceability missing analysis section 24 may be realized by one processing circuit 15, or the functions of the MDM creation section 21 and the dependence part analysis section 24 may be realized by one processing circuit 15. The functions of the location analysis section 22, version management section 23, and traceability loss analysis section 24 may be realized by being distributed among a plurality of processing circuits 15.

<Modification 2>
As a second modification, some functions may be realized by hardware, and other functions may be realized by software. In other words, some of the functions of the MDM creation section 21, possible dependence analysis section 22, version management section 23, and traceability missing analysis section 24 are realized by hardware, and other functions are realized by software. It's okay.

The processor 11, memory 12, storage 13, and processing circuit 15 can be collectively referred to as a "processing circuitry." That is, the functions of each functional component of the traceability missing detection device 10 are realized by processing circuitry.

<Embodiment 2>
<Configuration>
FIG. 28 is a block diagram showing the configuration of the traceability loss detection device 10 according to the second embodiment. The second embodiment, unlike the first embodiment, detects not only traceability missing but also dependency missing. Hereinafter, among the constituent elements according to the second embodiment, the points that are different from the first embodiment will be mainly explained, and the explanation of the same and similar points will be omitted.

The traceability loss detection device 10 is different from the traceability loss detection device 10 shown in FIG. 1 and includes a dependency relationship loss analysis section 25. The missing dependency analysis unit 25 may be realized by software like other functional components, or part or all of the missing dependency analysis unit 25 may be realized by hardware like other functional components. may be done.

<Operation>
FIG. 29 is a diagram for explaining the operation of the traceability loss detection device 10 according to the second embodiment.

The operation of the traceability loss detection device 10 according to the second embodiment corresponds to the traceability loss detection method according to the second embodiment. Further, the operation of the traceability missing detection device 10 according to the second embodiment corresponds to the processing of the traceability missing detection program according to the second embodiment.

<Processing of missing dependency analysis unit 25>
As shown in FIG. 29, the dependency relationship missing analysis unit 25 uses the MDM information 34, the MDM difference list 37, and the possible dependence location list 35 to determine the missing candidates in the dependency relationships between the elements of the source code, that is, the missing The possible combinations are extracted (detected) as dependency missing candidates. For example, the missing dependency analysis unit 25 determines a method for checking missing dependency candidates based on the MDM difference list 37. Then, the missing dependency analysis unit 25 extracts candidates for missing dependencies in the MDM information 34 based on the MDM information 34 and the list of possible dependencies 35 in accordance with the determined confirmation method.

The missing dependency analysis unit 25 creates a missing dependency list 39 indicating the extraction results, that is, missing dependency candidates. The missing dependency list 39 is a list of candidates for missing dependencies at the source code level due to changes in MDM, and the details will be described later.

In the second embodiment, the missing dependency analysis unit 25 controls the display device 19 (FIG. 1) to display the MDM information 34 and the missing dependency list 39 of the MDM information 34.

The processing of the missing dependency analysis unit 25 will be described with reference to FIGS. 30 to 35.

FIG. 30 is a diagram showing an example of a software structure after changes are made to the software structure of FIG. 3. FIG. 30 shows that function g is added to function C. In the following description, the change from the software structure in FIG. 3 to the software structure in FIG. 30, that is, the addition of the traceability correspondence between function C and function g, will be referred to as a "fourth change."

When the fourth change is made, the MDM creation unit 21 creates the MDM information 34 using the traceability list 33 of FIG. 31 instead of the traceability list 33 of FIG. 6. The possible dependence part analysis unit 22 creates a list of possible dependence parts 35 at the source code level based on the MDM information 34.

FIG. 32 is a diagram showing the MDM information 34 in which the contents of the list of possible dependencies 35 are reflected when the fourth change is made. In FIG. 32, for convenience of explanation, the dependent locations in the dependent location list 35 are shown by hatching, as in FIG. 14.

33 showing that the traceability correspondence relationship between function C and function g has been added, based on the MDM information 34 after the fourth change and the previous MDM information 36 before the fourth change. An MDM difference list 37 is created. The missing dependency analysis unit 25 acquires the change type of difference information from the MDM difference list 37 created by the version management unit 23. As in the example of FIG. 33, when the correspondence between function C and function g is added, the missing dependency analysis unit 25 acquires the addition of the traceability correspondence as the change type.

When the change type is addition of traceability correspondence, the missing dependency analysis unit 25 checks dependencies at the source code level related to the added traceability. For example, the missing dependency analysis unit 25 extracts the function c and the function e corresponding to the function C, and determines the dependence relationship from the function c and the function e to the function g, and the dependence relationship from the function g to the function c and the function e. are extracted as candidates for missing dependencies. Furthermore, since there is a dependency relationship from function A to function C, the dependency relationship missing analysis unit 25 extracts the dependency relationship from function a corresponding to function A to function g corresponding to function C as a dependency relationship missing candidate. do. In addition, since there is a dependency relationship from function C to function D, the dependency relationship missing analysis unit 25 determines the dependence relationship from function g corresponding to function C to function d, function f, and variable β corresponding to function D. Extract the relationship as a candidate for missing dependency.

The missing dependency analysis unit 25 lists the extracted dependencies and creates a missing dependency list 39 as shown in FIG. 34.

For example, the missing dependency list 39 is a list showing the correspondence between elements of the source code, similar to the source code dependency list 32 of FIG. Note that the dependency relationship missing list 39 may include related information such as the type of each element of the source code and the file to which it belongs, dependency type, etc., and may also include information on related MDM differences.

The missing dependency analysis unit 25 writes the missing dependency list 39 into the memory 12. Furthermore, the missing dependency analysis unit 25 outputs a missing dependency list 39 via the communication interface 14 . The output dependency relationship missing list 39 is displayed on the display device 19 or the like.

Note that the missing dependency analysis unit 25 may add information of a missing dependency list 39 to the MDM information 34, as shown in FIG. For example, the missing dependency analysis unit 25 may change the frame line of the cell in the 8th row and 12th column of FIG. 35, which indicates the dependency relationship from function g to function c, to a thick dashed frame. This indicates that there is a possibility that a dependency relationship is missing in the dependency relationship from function g to function c. The method of adding information is not limited to changing the cell border. The missing dependency analysis unit 25 may output at least one of the missing dependency list 39 in FIG. 34 and the information-added MDM information 34 in FIG. 35 via the communication interface 14.

With reference to FIGS. 22 to 26, as well as FIGS. 36 and 37, the processing of the missing dependency analysis unit 25 when the third change is performed will be described.

As in the example of FIG. 24, when a dependency relationship from function B to function D is added, the missing dependency analysis unit 25 acquires, as a change type, that a dependency relationship at the specification level has been added.

When the change type is the addition of a dependency relationship at the specification level, the missing dependency analysis unit 25 extracts the source code corresponding to the dependent function from the source code element corresponding to the dependent function of the added dependency relationship. A dependency relationship list 39 is created by extracting dependency relationships to elements as dependency relationship missing candidates. As in the example of FIG. 24, when a dependency relationship is added from function B to function D, the dependency relationship missing analysis unit 25 analyzes function b corresponding to function B, function d corresponding to function D, function f , and the dependencies on the variable β to create a list of missing dependencies 39 in FIG.

Note that the missing dependency analysis unit 25 may add information of the missing dependency list 39 to the MDM information 34, as shown in FIG. For example, the missing dependency analysis unit 25 may change the frame line of the cell in the 9th row and 7th column of FIG. 37, which indicates the dependency relationship from function b to function d, to a thick dashed frame. This indicates that there is a possibility that the dependency relationship from function b to function d is missing. The method of adding information is not limited to changing the cell border. The missing dependency analysis unit 25 may output at least one of the missing dependency list 39 in FIG. 36 and the information-added MDM information 34 in FIG. 37 via the communication interface 14.

When the change type is deletion of a dependency relationship at the specification level or deletion of a traceability correspondence relationship, the missing dependency analysis unit 25 stores the dependency relationship that violates the architecture in the missing dependency list 39 as a candidate for missing dependency relationships. You may also create

If the change type is addition of dependency at the source code level or deletion of dependency at the source code level, the missing dependency analysis unit 25 may create an empty dependency missing list 39.

If there are a plurality of combinations of change types in the difference information, the missing dependency analysis unit 25 performs the same process as described above for each change type. For example, a case will be described in which the traceability correspondence between function C and function g is added and the specification dependency relationship from function B to function D is added at the same time. In this case, the missing dependency analysis unit 25 first determines the dependency relationships from function a, function c, and function e to function g, and from function g to add traceability correspondence between function C and function g. Function c, function d, function e, function f, and dependencies on variable β are written in dependency relationship missing list 39. Next, regarding the addition of specification dependencies from function B to function D, the missing dependency analysis unit 25 adds the dependencies from function b to function d, function f, and variable β to the missing dependency list 39. Describe it.

<Summary of Embodiment 2>
The traceability missing detection device 10 according to the second embodiment as described above can detect not only traceability missing candidates but also dependency missing candidates at the source code level when changing specifications or source code. In this way, by automatically discovering missing dependencies at the source code level, software developers can prevent missing dependencies at the source code level. This can reduce source code implementation time and bug creation, and reduce software development man-hours.

Note that it is possible to freely combine each embodiment and each modification, or to modify or omit each embodiment and each modification as appropriate.

10 Traceability missing detection device, 19 Display device, 21 MDM creation section, 22 Possible dependence location analysis section, 23 Version management section, 24 Traceability missing analysis section, 25 Dependency relationship missing analysis section.

Claims (7)

an MDM creation unit that creates MDM information based on dependencies between specifications in software, dependencies between elements of source code, and traceability information including correspondence between the specifications and the elements;
a dependent location analysis unit that extracts dependent elements from among the elements of the source code as dependent locations based on the dependency relationship between the specifications and the traceability information or the MDM information;
a version management unit that extracts difference information between the MDM information and past MDM information created in the past than the MDM information;
A traceability management device comprising: a traceability missing analysis unit that extracts missing traceability candidates in the correspondence of the traceability information as traceability missing candidates based on the MDM information, the dependable locations, and the difference information. The traceability management device according to claim 1,
The version control unit is
A traceability management device that uses specific MDM information among a plurality of held MDM information as the past MDM information. The traceability management device according to claim 1 or 2,
The traceability missing analysis section
A traceability management device that performs control to display the MDM information and the traceability missing candidates of the MDM information on a display device. The traceability management device according to any one of claims 1 to 3,
Traceability management further comprising: a dependency missing analysis unit that extracts missing dependency candidates in dependency relationships between the elements of the source code as dependency missing candidates based on the MDM information, the possible dependence locations, and the difference information. Device. The traceability management device according to claim 4,
The dependency missing analysis unit includes:
A traceability management device that performs control to display the MDM information and the dependency relationship missing candidates of the MDM information on a display device. An MDM creation unit creates MDM information based on dependencies between specifications in the software, dependencies between elements of source code, and traceability information including correspondence between the specifications and the elements,
a dependent location analysis unit extracts dependent elements from among the elements of the source code as dependent locations based on the dependency relationship between the specifications and the traceability information or the MDM information;
a version management unit extracts difference information between the MDM information and past MDM information created in the past than the MDM information;
A traceability management method, wherein a traceability missing analysis unit extracts missing candidates in the correspondence of the traceability information as traceability missing candidates based on the MDM information, the dependable locations, and the difference information. Creating MDM information based on dependencies between specifications in software, dependencies between elements of source code, and traceability information including correspondence between the specifications and the elements;
Extracting dependable elements from among the elements of the source code as dependable locations based on the dependency relationship between the specifications and the traceability information or the MDM information;
Extracting difference information between the MDM information and past MDM information created in the past than the MDM information;
A traceability management program that causes a computer to extract missing candidates in the correspondence of the traceability information as traceability missing candidates based on the MDM information, the dependable locations, and the difference information.

Images