JP2018005535A - Software development assist method and system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To assist in eliminating omissions of check for effects of changes when source code is changed.SOLUTION: Provided is a software development assist method including a storage device for storing source code that includes a plurality of elements constituted of a function and/or a variable, an input/output device for inputting/outputting information and a controller for managing the storage device and the input/output device, wherein the controller includes: a first step for storing, when a first change request indicating a change of an element included in the source code is accepted from the input/output device, first change management information that indicates whether or not other elements affected by the accepted first change request are changed, and first change schedule information that indicates the presence of a change schedule for other elements affected by the first change request; and a second step in which the input/output device outputs an element for which a change is indicated by the first change request, other elements affected by the first change request, the first change management information and the first change schedule information.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a software development support method and system for supporting work in developing software.

  When developing large-scale software, the source code is often analyzed and new functions are added. At this time, if the source code is added or changed without sufficient understanding of the parent source code, it may cause problems due to oversight of parts to be corrected or conflicts with changes made by other developers in parallel. There are things to do. In order to solve this problem, a method of analyzing a parent source code has been proposed (see Patent Document 1). Patent Document 1 proposes a method for supporting analysis of a maternal source code by searching for dependency relationships between functions and variables in the maternal source code.

Japanese Patent Laid-Open No. 5-289862

  The method of Patent Document 1 is not sufficient to eliminate omissions in checking the influence of changes when changing the source code, and it assumes a single developer and takes into account work conflicts between multiple developers. It has not been.

  An object of the present invention is to assist in eliminating omissions in checking for changes when changing source code.

  In order to solve the above-described problems, the present invention provides a storage device that stores a source code including a plurality of elements configured by at least one of a function and a variable, an input / output device that inputs and outputs information, and the storage device And a software development support method in a system including a controller that manages the input / output device, wherein the controller receives from the input / output device a first change request that instructs to change an element included in the source code. The first change management information indicating whether or not other elements affected by the received first change request have been changed, and whether or not there are plans to change other elements affected by the first change request A first step of storing in the storage device the first change schedule information indicating the element, the input / output device is an element instructed to change in the first change request, Other factors affected by one change request, the first change management information and is characterized by having a second step of outputting the first change schedule information.

  According to the present invention, it is possible to eliminate the check omission of the change effect when changing the source code. Problems, configurations, and effects other than those described above will become apparent from the description of the following examples.

1 is an overall configuration diagram of a system showing Embodiment 1 of the present invention. FIG. 4 is a configuration diagram of a table and a database, where (a) is a configuration diagram of a table showing an example of element dependency, (b) is a configuration diagram of a table stored in a source code database, and (c) is a configuration diagram. Configuration diagram of the management database, (d) is a configuration diagram of a table stored in the check flag database. It is a flowchart for demonstrating the process of a source structure management part. It is a flowchart for demonstrating the process of a source dependence analysis part. It is a flowchart for demonstrating the process of a source metrics analysis part. It is a flowchart which shows the typical development flow which adds a function to a base source code. It is a block diagram which shows the legend of the symbol managed by a user interface display part. It is a figure for demonstrating the state when the flag which needs a change is set with respect to a function, Comprising: (a) is a block diagram which shows the example of a display, (b) is a block diagram of a change flag table. is there. It is a flowchart for demonstrating the process of a flag management part. It is a figure for demonstrating the state of the flag at the time of design completion, Comprising: (a) is a block diagram which shows the example of a display of a display, (b) is a block diagram of a change flag table. It is a figure for demonstrating the state which implemented the change of a source code after designing, (a) is a block diagram which shows the example of a display of the display in Example 2, (b) is Example 2. It is a block diagram of the change flag table in FIG. 12 is a flowchart for explaining a process in the third embodiment when the check flag database is not referred to. It is a flowchart for demonstrating the process in Example 3, when the data of a check flag database are utilized. FIG. 10 is a configuration diagram of a system according to a third embodiment and intended for a plurality of developers. It is a figure for demonstrating the state where the collision occurred by the change of several developers, Comprising: (a) is a block diagram which shows the example of a display of the display in Example 3, (b) is a change in Example 3. It is a block diagram of a flag table.

  Hereinafter, embodiments will be described with reference to the drawings. In the drawings, the same reference numerals indicate the same or corresponding parts. Further, the present invention is not limited to the illustrated example.

  In the present embodiment, an operation of a design process will be described in a typical development flow for adding a function to a parent source code.

  FIG. 1 is an overall configuration diagram of a system showing Embodiment 1 of the present invention. In FIG. 1, the system (software development support system) includes a development machine 10 and a management server 12, and the development machine 10 is connected to the management server 12. The development machine 10 includes a display 102, peripheral devices 103, a central processing unit 104, and a storage device 105. The display 102 is configured as a display device that displays information or an output device that outputs information, and the peripheral device 103 includes a keyboard and the like, and is configured as an input device that inputs information. At this time, the display 102 and the peripheral device 103 can be configured as an input / output device for inputting and outputting information. The central processing unit 104 is configured as a computer device including information processing resources such as a CPU (Central Processing Unit), a memory, and an input / output interface, and includes software 14 executed by the CPU. An information storage unit 16 is provided. The software 14 includes a user interface display unit 108, a source configuration management unit 109, a source dependency analysis unit 110, a source metrics analysis unit 111, and a flag management unit 112. The information storage unit 16 includes a source code 113 being changed and a source code database 114. At this time, the central processing unit 104 functions as a controller that manages the storage device 105 and transmits / receives information to / from the input / output device.

  The management server 12 used by one or a plurality of development machines 10 includes a central processing unit 106 and a storage device 107, and manages the storage device 107 by transmitting / receiving information to / from the development machine 10. The storage device 107 includes an information storage unit 18. The central processing unit 106 is configured as a computer device having information processing resources such as a CPU, a memory, and an input / output interface, for example. The information storage unit 18 includes a configuration management database 115 and a check flag database 116. At this time, the developer 101 uses the development machine 10 through the display 102 and the peripheral device 103.

  The user interface display unit 108 displays, on the display 102, the processing contents and processing results of any of the source configuration management unit 109, the source dependency analysis unit 110, the source metrics analysis unit 111, and the flag management unit 112. Software (program). The source configuration management unit 109 is software for managing the version of the source code. The source configuration management unit 109 is connected to the source code 113 being changed and the configuration management database 115, and a plurality of users (developers) changed which source code when and when. I manage. The source dependency analysis unit 110 is software for analyzing a reference relationship between functions and variables included in the source code, and is connected to the source code 113 being changed and the source code database 114. Processing is basically performed based on a static analysis technique of source code, but there is also an implementation form in which processing is performed based on an algorithm such as logical coupling. The source metrics analysis unit 111 is software for measuring metrics (numerical information) related to each function and variable belonging to the source code, and is connected to the source code 113 being changed and the source code database 114. In the embodiment described later, only the number of other dependencies is displayed, but there is also an implementation form that handles metrics such as complexity and change frequency. The flag management unit 112 is connected to the check flag database 116 and is software for managing check flag data recorded in the check flag database 116. The configuration management database 115 performs source code configuration management in cooperation with the source configuration management unit 109. The check flag database 116 stores check flag data in cooperation with the flag management unit 112.

  2A and 2B are configuration diagrams of a table and a database, in which FIG. 2A is a configuration diagram of a table showing an example of element dependency, FIG. 2B is a configuration diagram of a table stored in a source code database, and FIG. ) Is a configuration diagram of the configuration management database, and (d) is a configuration diagram of a table stored in the check flag database.

  In FIG. 2A, a table 201 showing an example of element dependency is a table stored in the storage device 105, and is a graph showing the dependency of functions and variables in the source code targeted by the tool. As the information regarding, “function: func1”, “function: func2”, “variable: value1”, “function: func3” are configured. In this embodiment, functions and variables existing in the source code are called elements. In the table 201, “function: func2” refers to “variable: value1” and “function: func3”, and “function: func2” is a dependency referenced from “function: func1”. . The dependency relationship is indicated by an arrow 202.

  2B, the source code database 114 stores an element table 203 and a change influence table 204. The element table 203 includes an element ID 205, a file 206, a function / variable 207, and another dependency number 208. The element ID 205 stores an identifier for uniquely identifying the element. The file 206 stores information such as a file name that identifies the file. The function / variable 207 stores information (function name, variable name) for specifying the function or variable. The other dependency number 208 stores information (numerical information) indicating the number of items having a dependency relationship with an element in addition to the function or variable recorded in the function / variable 207.

  The change influence table 204 includes a change source element ID 209, a change influence element ID 210, and a change influence type 211. The change source element ID 209 and the change influence element ID 210 are IDs corresponding to the ID defined by the element ID 205, and the change source element ID 209 stores an identifier for identifying the change source element indicating the change source of the element. Is done. For example, when “element 2” in the element ID 205 is changed (when it is scheduled to be changed), “2” is stored in the change source element ID 209. The change influence element ID 210 stores an identifier for identifying an element that is affected by the change of the change source element. For example, when the elements affected by the change of “element 2” in the element ID 205 are “1”, “3”, and “4”, the change affecting element ID 210 includes “1”, “3”, “4”. Is stored. In the change influence element ID 210, when the element stored in the change influence element ID 210 is a type that is called by the change source element, information of “call” is stored, and the element stored in the change influence element ID 210 is the change source element. In the case of a type that calls, “invoked” information is stored.

  In FIG. 2C, the source code 212 is stored in the configuration management database 115. The source code 212 is managed by a plurality of versions 213. Each version 213 stores the update date and time, and the source code 212 of the latest version 213 can be extracted.

  In FIG. 2D, the change flag table 214 is stored in the check flag database 116. The change flag table 214 includes a file 215, a function / variable 216, a source configuration management state 217, a scheduled change state 218, a change collision state 219, an updater 220, and an update date / time 221. The file 215 stores information similar to that of the file 206, such as a file name that identifies the file. The function / variable 216 stores information (function name, variable name) that is the same information as the function / variable 207 and identifies the function or variable. The source configuration management state 217 stores “unchanged” information when the source configuration management has not been changed, and stores “changed” information when the source configuration management has been changed. The change schedule state 218 stores “unconfirmed” information when the change schedule (element change schedule) is unconfirmed, and stores “unchange required” information when the change schedule does not need to be changed. When a change schedule is necessary, “change necessary” information is stored. The changed collision state 219 stores information indicating whether or not there is a collision (information indicating whether or not a collision (overlap) has occurred between elements). The updater 220 stores information indicating the name of the updater who changed the source code. The update date / time 221 stores information indicating the update date / time when the source code was changed. In FIG. 2D, the change flag table 214 stores information on the initial state of the table 201.

  FIG. 3 is a flowchart for explaining the processing of the source configuration management unit. In FIG. 3, when the developer 101 changes the source code, the local source code on the storage device 105 is changed instead of the source code on the configuration management database 115. When the developer 101 instructs the registration of the source code at the stage where this change is completed, the processing by the source configuration management unit 109 is started (step 301). First, the source configuration management unit 109 compares the source code being changed (source code being changed) 113 with the source code 212 of the latest version 213 in the configuration management database 115 (step 302), and whether there is a difference. If there is no difference, the processing in this routine is terminated. If there is a difference, the changing source code is registered in the configuration management database 115 as the latest version (step 304). The processing in this routine is terminated. This process is a process of a general source code configuration management tool.

  FIG. 4 is a flowchart for explaining the processing of the source dependency analysis unit. In FIG. 4, the source dependency analysis unit 110 calls a list screen (change impact check screen) 801, which will be described later, or a timing when the source code 113 being changed is changed, or a regular schedule. Source (source code) dependency analysis is started (step 401). When the processing is started in step 401, the source dependency analysis unit 110 performs a loop with all the elements of the changing source code 113 (step 402), and measures the dependency of each element of the changing source code 113. Then, the measurement result is stored as information indicating the dependency in the change influence table 204 of the source code database 114 (step 404). The source dependency analysis unit 110 performs this process for all elements, and ends the process in this routine (step 405). This process is a process of a general source dependency analysis tool.

  FIG. 5 is a flowchart for explaining processing of the source metrics analysis unit. In FIG. 5, the source metrics analysis unit 111 selects a source at a timing when a list screen (change impact check screen) 801, which will be described later, is called, when a source code 113 being changed is changed, or at a regular schedule. Metric analysis of (source code) is started (step 501). When the process is started in step 501, the source metrics analysis unit 111 performs a loop with all the elements of the source code 113 being changed (step 502), and measures the metrics of each element of the source code 113 being changed ( Step 503), and the measurement result is stored in the element table 203 of the source code database 114 as information indicating the metrics of each element (step 504). The source metrics analysis unit 111 performs this process for all elements, and ends the process in this routine (step 505). This process is a process possessed by a general source metrics analysis tool.

  FIG. 6 is a flowchart showing a typical development flow for adding functions to the parent source code. In FIG. 6, when the developer 101 starts processing from the starting point 601 of the development process and executes an operation for reading the parent code (source code), the user interface display unit 108 is configured via the source configuration management unit 109. The mother code (source code) is read from the management database 115, and the read mother code (source code) is displayed on the display 102. At this time, the developer 101 designs the addition of the function by operating the keyboard or the like of the peripheral device 103 with respect to the base code (source code) displayed on the display 102 (step 602). For example, a design for changing “func2” is performed. At this time, for example, in step 602, the flag management unit 112 performs a change influence check when changing “func2”, and obtains a check result (information on a function or variable affected by the change of “func2”). Register in the check flag database 116.

  Next, the developer 101 operates the keyboard or the like of the peripheral device 103 to implement the function added in step 603 on the source code (step 603). Thereafter, when the developer 101 executes an operation for reading the matrix code (source code) and the check flag, the user interface display unit 108 reads the matrix code (source code) from the configuration management database 115 via the source configuration management unit 109. ), The check flag is read from the check flag database 116 via the flag management unit 112, and the read base code (source code) and the check flag are displayed on the display 102. At this time, the developer 101 refers to the base code (source code) displayed on the display 102 and the check flag, and performs a function implementation completion check (step 604). For example, the developer 101 performs a change impact check by comparing the displayed parent source code with a check flag. At this time, the developer 101 further corrects the source code if a problem occurs in the check result. If the check result is good, an operation for registering the changed code (source code) in the configuration management database 115 is executed. As a result, the development process ends at the end point 605.

  FIG. 7 is a configuration diagram showing a legend of symbols managed by the user interface display unit. In FIG. 7, the user interface display unit 108 uses the flag management unit 112 to change the source configuration management state 217 information in the change flag table 214 of the check flag database 116 as the source configuration management state 701 information. Information of 218 is managed as information of the scheduled change state 702, information of the changed collision state 219 is managed as information of the changed collision state 703, each information is managed in association with a symbol, and the managed information and symbol are displayed on the display 102. On the screen. The information and symbols of the source configuration management state 701 are composed of unchanged (check mark) and changed (!). The information and symbols of the scheduled change state 702 are composed of unconfirmed (?), Change unnecessary (N), and change required (C). The information and symbol of the changed collision state 703 are composed of a changed collision state (×). Within each category, only one symbol can be displayed at the same time, but information and symbols related to the source configuration management state 701, scheduled change state 702, and change collision state 703 are displayed simultaneously for one element. there is a possibility.

  FIGS. 8A and 8B are diagrams for explaining a state when a flag that needs to be changed is set for a function, where FIG. 8A is a configuration diagram showing a display example of the display, and FIG. 8B is a change flag table. FIG. In FIG. 8, the developer 101 operates the peripheral device 103 to display the list screen 801 on the screen of the display 102, and a flag indicating that “func2” needs to be changed (to be changed) through the user interface display unit 108. When it is instructed to establish (C), the source dependency analysis unit 110 refers to the source code database 114 based on the instructed information, and as a function or variable having a relationship of calling or called with “func2”. For example, a process for setting an unconfirmed flag (?) In “value1”, “func3”, and “func1” is executed. When this processing result is transferred to the display 102 via the user interface display unit 108, the reference result of the source dependency analysis unit 110 is displayed on the list screen 801 of the display 102. At this time, the developer 101 can refer to the contents of the displayed list screen 801.

  The list screen 801 displays the file (FileA.c) of “func2” and the function / variable “func2” as information about the change source (element change source) 802, and changes “func2” as the change effect 803. Files and functions / variables affected by the file, file names (FileA.h, FileB.c, FileC.c) and function / variable names (value1, func3) registered in the element table 203 and the change impact table 204 , Func1) is displayed, “call” or “callee” registered in the change impact table 204 is displayed as the change impact type 804, and information registered in the other dependency number 208 of the element table 203 as the metrics 805 (Number of other dependencies: 15 etc.) is displayed. At this time, in the function / variable “func2” of the change source 802, a symbol point indicating no change and a symbol (C) indicating a change necessary (to be changed) are displayed as a flag (check flag). In addition, in the function / variable (value1, func3, func1) of the change influence 803, a symbol check point indicating no change and a symbol (?) Indicating no check are displayed as flags (check flags).

  The developer 101 refers to the list screen 801 and examines a change range of the base code (source code) necessary for the function he / she wants to design. In examining the change range, the impact of the change impact can be referred to by referring to the change impact type 804 and the metrics 805. The change impact type 804 and the metrics 805 shown here are only a part of examples, and there are implementations in which various items useful for analysis of the change impact are added.

  The file name (FileA.h, FileA.c, FileB.c, FileC.c) is registered in the file 215 of the change flag table 214, and the function / variable 216 has a function or variable name (value1, func2, func3, func1) are registered, and in the source configuration management state 217, “unchanged” information is registered in order to indicate that each file has not been changed. "Only" column indicates that change is necessary (to be changed), "change required" information is registered, and other columns indicate whether change is necessary or not In addition, information of “unconfirmed” is registered, the name of the developer 101 is registered in the updater 220, and information on the update date / time by the developer 101 is registered in the update date / time 221. Note that element ID information can be registered in the change flag table 214 corresponding to the file 215.

  FIG. 9 is a flowchart for explaining the processing of the flag management unit. This process is started when the developer 101 executes an operation for setting an unconfirmed flag (?) (Step 901). When the process is started, the flag management unit 112 refers to the element table 203 based on information obtained by an operation for setting an unconfirmed flag (?), And starts a loop with all element IDs in the element table 203 ( In step 902), a row corresponding to the element ID being looped (a row corresponding to the file specified by the element ID) is acquired from the change flag table 214 based on the element ID of the element table 203 (step 903).

  Next, the flag management unit 112 refers to the change flag table 214 to determine whether or not the element needs to be changed (scheduled to be changed), that is, the file specified by the element ID needs to be changed (scheduled to be changed). If a negative determination result is obtained in this step, the processing in this routine is terminated. If a positive determination result is obtained in this step, the element ID of the element table 203 is set. Based on the change influence table 204, a plurality of lines having the same change source element ID are acquired (step 905), and a loop is started on the acquired plurality of lines (step 906).

  Next, the flag management unit 112 acquires the change influence element ID of the corresponding line from the obtained plurality of lines as the process in the loop from the change influence table 204 (step 907), and based on the acquired change influence element ID. The line with the same element ID (the line with the matching file specified by the element ID) is acquired from the change flag table 214 (step 908), and it is determined whether or not the planned change state is “change required (C)”. (Step 909), if a positive determination result is obtained in this step, the planned change state is changed to unconfirmed (?) (Step 910), and then the processing in this routine is terminated, and a negative result is obtained in Step 909. When the determination result is obtained, that is, when the change is necessary (scheduled for change) (C), the loop is continued without doing anything, and then the processing in this routine is terminated. Finally, the process is performed with the element IDs included in all the element tables 203, and the process ends in step 911. Since the algorithm shown here shows a basic flow, there is actually an implementation form having an application algorithm or the like that minimizes the unconfirmed (?) Range.

  10A and 10B are diagrams for explaining the state of the flag at the time when the design is completed, in which FIG. 10A is a configuration diagram illustrating a display example of the display, and FIG. 10B is a configuration diagram of a change flag table. . In FIG. 10, the design has been completed for the developer 101 to operate the peripheral device 103 to display the list screen 801 on the screen of the display 102 and to change “func2” and the like through the user interface display unit 108. , The source dependency analysis unit 110 refers to the source code database 114 based on the instructed information, and calls a function or variable (value1, func3, func1) that is in a calling or called relationship with “func2”. The process for displaying the symbol is executed. When this processing result is transferred to the display 102 via the user interface display unit 108, the reference result of the source dependency analysis unit 110 is displayed on the list screen 801 of the display 102. At this time, the developer 101 can refer to the contents of the displayed list screen 801.

  The list screen 801 displays the name of the file “func2” (FileA.c) and the name of the function / variable (func2) as information about the change source 802, and the change effect 803 indicates the effect of the change of “func2”. Files and functions / variables received in the element table 203 and the change impact table 204 (FileA.h, FileB.c, FileC.c) and function / variable names (value1, func3, func1) is displayed, “invocation” or “invoked” registered in the change impact table 204 is displayed as the change impact type 804, and information registered in the other dependency number 208 of the element table 203 as the metrics 805 ( Other dependence number: 15 etc.) is displayed. At this time, in the function / variable “func2” of the change source 802, a symbol point indicating no change and a symbol (C) indicating a change necessary (to be changed) are displayed as a flag (check flag). In addition, in the function / variable (value1, func3, func1) of the change influence 803, a symbol point indicating no change and a symbol (N) indicating no change or a symbol (C) indicating a change necessary are flags (check flags). Is displayed.

  At this time, the developer 101 can confirm whether or not all unconfirmed flags (?) Are replaced with the change schedule flag (C) or the change unnecessary flag (N) by looking at the list screen 801. Therefore, when the unconfirmed flag remains, all the unconfirmed flags (?) Are highlighted (displayed in black and white in the drawing) by the user interface display unit 108. As a result, the lack of consideration of the change effect at the design time of the developer 101 is suppressed.

  The file names (FileA.h, FileA.c, FileB.c, FileC.c) are registered in the file 215 of the change flag table 214, and the function / variable names (value1) are registered in the function / variable 216. , Func2, func3, func1) are registered, and in the source configuration management state 217, “unchanged” information is registered in order to indicate that each file has not been changed. Only the "func2" and "func3" fields are registered to indicate that they need to be changed (scheduled to be changed), and other fields are registered to indicate that no changes are required. “No change necessary” information is registered, the name of the developer 101 is registered in the updater 220, and the update date / time information by the developer 101 is registered in the update date / time 221. The change flag table 214 stores information related to the flag (check flag) displayed on the list screen 801. At this time, since the information on the updater and the update date / time is stored, design evidence indicating who made what and what determination is stored.

  According to the present embodiment, the developer 101 who adds a new function supports the change of the source code without omission (without checking the effect of the change) by using this system in the design process before mounting. can do. Specifically, when the design is completed, information on the change source 802 and information on the change impact 803 are displayed on the list screen 801, so that the developer 101 refers to the list screen 801, so that the sword Among the elements belonging to the code, the relationship between the change source element and the element affected by the change source element can be confirmed. In addition, since the unconfirmed flag, the change schedule flag, or the change unnecessary flag are displayed as symbols on the list screen 801, the developer 101 can easily confirm whether or not an element belonging to the sword code has been changed. it can. Further, if an unconfirmed flag remains on the list screen 801, the unconfirmed flag is displayed in an emphasized manner, so that it is possible to prevent the developer 101 from considering the change effect at the design time. In addition, since the number of other dependencies is displayed as numerical information in the metrics 805 of the list screen 801, the developer 101 changes the element having the number of other dependencies larger than the set value (the number of other dependencies: 15). Since the impact is large, it can be judged that it is better not to change.

  A present Example is an example of the operation | work of the mounting process which changes a source code among the typical development flows which add a function to a base source code.

  FIG. 11 is a diagram for explaining a state in which the source code is changed after the design is performed. FIG. 11A is a configuration diagram illustrating a display example of the display in the second embodiment, and FIG. FIG. 10 is a configuration diagram of a change flag table in the second embodiment. In FIG. 11, after the developer 101 operates the peripheral device 103 to display the list screen 801 on the screen of the display 102 and the design for changing “func2” and the like through the user interface display unit 108 is completed. When the source code change is instructed, the source dependency analysis unit 110 refers to the source code database 114 based on the instructed information, and calls a function or variable (value1) having a relationship of calling or called with “func2”. , Func3, func1) executes processing for displaying symbols. When this processing result is transferred to the display 102 via the user interface display unit 108, the reference result of the source dependency analysis unit 110 is displayed on the list screen 801 of the display 102. At this time, the developer 101 can refer to the contents of the displayed list screen 801.

  In the list screen 801, the file (FileA.c) of “func2” and the function / variable “func2” are displayed as information about the change source 802, and the file affected by the change of “func2” Function / variable, file names (FileA.h, FileB.c, FileC.c) and function / variable names (value1, func3, func1) registered in the element table 203 and the change impact table 204 are displayed. Then, “Change” or “Called” registered in the change impact table 204 is displayed as the change impact type 804, and information registered in the other dependency number 208 of the element table 203 as the metric 805 (number of other dependencies: 15 etc.) is displayed. At this time, in the function / variable “func2” of the change source 802, a symbol (!) Indicating changed and a symbol (C) indicating change necessary (to be changed) are displayed as flags (check flags). In addition, the function / variable (value1, func3, func1) of the change effect 803 includes a symbol point indicating no change, a symbol indicating change (!), A symbol (N) indicating no change, or a symbol indicating change necessary ( C) is displayed as a flag (check flag).

  At this time, the developer 101 can confirm whether or not it has been changed as designed by looking at the list screen 801. For example, when the element (func2) is scheduled to be changed (C) and has been changed (!), And the element (value1) is not required to be changed (N) and not changed (R), it is implemented as designed. This is a desirable example. On the other hand, when the element (func2) is scheduled to be changed (C) and has been changed (!), And the element (func3) is not changed (score) despite the scheduled change (C), If (func2) is scheduled to be changed (C) and has been changed (!), And the element (func1) has been changed (!) Even though no change is required (N), it is changed as designed. This is an undesirable example. In the case of an undesired flag combination, the symbol is highlighted by the user interface display unit 108. However, even in an undesired example, there is often a change due to mounting reasons, and thus there are no operation restrictions. The newly added change element is changed to the change schedule (C), and the re-check is performed to suppress omission of consideration of change effects, and the fact that the wrong design has been performed is a check flag along with the developer ID. It is registered in the change flag table 214 of the database 116.

  The file name (FileA.h, FileA.c, FileB.c, FileC.c) is registered in the file 215 of the change flag table 214, and the function or variable name (value1) is registered in the function / variable 216. , Func2, func3, func1) are registered, and in the source configuration management state 217, “func1” is registered as “changed” information, and other than that, “unchanged” information is registered, and each file is registered. “Unchanged” information is registered to indicate that it has not been changed. In the change schedule state 218, only “func2” and “func3” fields are registered with “change required” information. In the column, information of “no change required” is registered, the name of the developer 101 is registered in the updater 220, and information on the update date and time by the developer 101 is registered in the update date and time 221.

  According to the present embodiment, the developer 101 who adds a new function can support changing the source code without omission by using this system after implementation. Specifically, when the source code is changed after the design is performed, the list screen 801 includes an unconfirmed flag, a change schedule flag, or a change unnecessary flag along with information on the change source 802 and information on the change influence 803. In the case of a combination of flags that are displayed as symbols and not changed as designed among these symbols, the symbols are displayed with emphasis, so that the developer 101 can change the elements belonging to the sword code as designed. It can be easily confirmed that no change has been made.

  This embodiment is an example when a plurality of developers add functions in parallel. The following describes problems and solutions when multiple developers add functions in parallel.

  FIG. 12 is a flowchart for explaining the processing in the third embodiment when the check flag database is not referred to. In FIG. 12, when the developer A starts processing from the start point 1201 of the development process and the developer A executes an operation for reading the matrix code (source code), the user interface display unit 108 displays the source configuration management unit. The matrix code (source code) is read from the configuration management database 115 via 109, and the read matrix code is displayed on the display 102. At this time, the developer A designs the addition of the function A by operating the keyboard or the like of the peripheral device 103 with respect to the base code (source code) displayed on the display 102 (step 1202). For example, a design for changing “func2” is performed. Next, the developer A operates the keyboard or the like of the peripheral device 103 to implement the function A (addition of the function A) added in step 1202 on the source code (step 1203). After that, the developer A executes an operation for reading the parent code (source code) from the configuration management database 115, and refers to the parent code displayed on the display 102 to check the implementation completion of the function A ( Step 1204) After checking, an operation for registering the changed code (source code) in the configuration management database 115 is executed. As a result, the development process ends at the end point 1205.

  On the other hand, the developer B starts processing from the start point 1211 of the development process. When the developer B executes an operation for reading the mother code (source code), the user interface display unit 108 reads the mother code (source code) from the configuration management database 115 via the source configuration management unit 109 and reads the mother code (source code). The mother code is displayed on the display 102. At this time, the developer B designs the addition of the function B by operating the keyboard or the like of the peripheral device 103 with respect to the matrix code displayed on the display 102 (step 1212). For example, a design for changing “func2” is performed. Next, the developer B operates the keyboard or the like of the peripheral device 103 to implement the function B (addition of the function B) added in step 1212 on the source code (step 1213). Thereafter, the developer B executes an operation for reading the parent code (source code) from the configuration management database 115, and refers to the parent code displayed on the display 102 to check the implementation completion of the function B ( Step 1214). At this time, before the development process is terminated at the end point 1215, there is a case where a correction reversion occurs or a collision occurrence detection delay occurs.

  For example, the process by the operation of developer A is completed earlier than the process by the operation of developer B. In step 1204, the code registration after the change of function A is performed before the implementation completion check of function B in step 1214. When implemented, the function B is changed because the function B matrix code read in step 1214 reads a code (source code) different from the matrix code read in step 1212 performed when designing the addition of function B. Affected by source code (source code). Specifically, when a file that is not scheduled to be changed for developer B is changed, it is necessary to redo the change impact check. At this time, in some cases, it is necessary to redo the correction of the source code. The collision caused by this change cannot be detected until the matrix code is read in step 1214, resulting in a collision detection delay. It will be long. In addition, in the case where the function A and the function B are the same change, in step 1213, a double work is performed, and the work for implementing the addition of the function B performed by the developer B is wasted. End up.

  FIG. 13 is a flowchart for explaining the processing in the third embodiment when the data in the check flag database is used. In FIG. 13, when the developer A starts processing from the start point 1301 of the development process and the developer A executes an operation for reading the matrix code (source code), the user interface display unit 108 to which information associated with the operation is input. Reads the matrix code (source code) from the configuration management database 115 via the source configuration management unit 109 and displays the read matrix code on the display 102. At this time, the developer A operates the keyboard of the peripheral device 103 on the base code displayed on the display 102 to design the addition of the function A (for example, a design for changing “func2”). (Step 1302), and an operation for registering the designed check flag in the check flag database 116 is executed.

  Next, the developer A operates the keyboard or the like of the peripheral device 103 to implement the function A (addition of the function A) added in step 1302 on the source code (step 1303). Thereafter, when the developer A reads the base code (source code) and executes an operation for reading the check flag, the user interface display unit 108 that has input information associated with the operation passes through the source configuration management unit 109. Then, the base code (source code) is read from the configuration management database 115, the check flag is read from the check flag database 116 via the flag management unit 112, and the read base code and check flag are displayed on the display 102. At this time, developer A refers to the base code and check flag displayed on display 102 to check the completion of implementation of function A (step 1304), and configures the changed code (source code) after the check. An operation for registering in the management database 115 is executed. As a result, the development process ends at the end point 1305.

  At this time, when the flag management unit 112 receives from the peripheral device 103 a first change request instructing to change a symbol included in the source code, the other symbols affected by the received first change request are displayed. Information indicating whether or not a change has been made (first change management information) is stored in the check flag database 116 as information of the source configuration management state 217, and other symbols scheduled to be changed that are affected by the first change request. Information indicating presence / absence (first change schedule information) is stored in the check flag database 116 as information of the change schedule state 218. In the user interface display unit 108, whether the symbol instructed to be changed by the first change request, other symbols affected by the first change request, or other symbols affected by the first change request has been changed. Information indicating whether or not (first change management information) and information indicating whether or not other symbols affected by the first change request are to be changed (first change schedule information) are displayed on the screen of the display 102. Let

  On the other hand, the developer B starts processing from the start point 1311 of the development process. When the developer B reads the base code (source code) and executes an operation for reading the check flag, the user interface display unit 108 that has input information associated with the operation receives the configuration management database via the source configuration management unit 109. The matrix code (source code) is read from 115, the check flag is read from the check flag database 116 via the flag management unit 112, and the read matrix code and check flag are displayed on the display 102. At this time, the developer B designs the addition of the function B by operating the keyboard or the like of the peripheral device 103 with respect to the matrix code displayed on the display 102 (step 1312). For example, a design for changing “func2” is performed. At this time, when the flag management unit 112 detects a collision (collision between elements), it is displayed on the display 102 that a change collision has occurred in any element. In this case, developer B discusses with developer A to adjust the implementation content and timing (step 1313).

  At this time, when the flag management unit 112 receives from the peripheral device 103 a second change request instructing to change a symbol included in the source code, the other symbols affected by the received second change request are displayed. Information indicating whether or not there is a change (second change management information) is held as information of the source configuration management state 217, and information indicating whether or not other symbols that are affected by the second change request are scheduled to be changed ( Second change schedule information) as the information of the change schedule state 218, the first change management information and the first change schedule information stored in the check flag database 116, the held second change management information, Compare with the second scheduled change information, and from this comparison result, determine whether there is a change conflict between any of the information, and display this determination result in the user interface 108 transferred to the display 102 via the. The user interface display unit 108 displays the symbol instructed to be changed by the second change request, the other symbols affected by the second change request, the second change management information, and the second change schedule information. Is displayed on the screen.

  Next, developer B operates the keyboard or the like of peripheral device 103 and implements the function added in step 1312 (including the function added after adjustment) B (addition of function B) on the source code. (Step 1314). Thereafter, when the developer B reads the base code (source code) and executes an operation for reading the check flag, the user interface display unit 108 that has input information associated with the operation passes through the source configuration management unit 109. Then, the base code (source code) is read from the configuration management database 115, the check flag is read from the check flag database 116 via the flag management unit 112, and the read base code and check flag are displayed on the display 102. At this time, the developer B refers to the base code and check flag displayed on the display 102 and checks the completion of the implementation of the function B (step 1315), and configures the changed code (source code) after the check. An operation for registering in the management database 115 is executed. Thus, the development process ends at the end point 1316. At this time, the flag management unit 112 stores the held second change management information and second change schedule information in the check flag database 116 on the condition that it is determined that there is no change collision between any pieces of information. .

  If the flag management unit 112 detects a collision in step 1312, the collision can be detected at an early stage, and the developer B can be warned by blinking (highlighting) the flag. At this time, the developer B can see the warning and talk with the developer A to adjust the contents and timing of implementation. According to this discussion, when the addition of the function B is implemented in step 1314, the same work need not be performed twice (suppression of double work), and man-hours can be reduced. In addition, when the implementation completion check of the function B is performed in step 1315, it is already considered in the design that the function A has already been registered, so that unexpected work rework does not occur (suppression of correction rework), Man-hours can be reduced.

  FIG. 14 is a configuration diagram of a system according to the third embodiment and intended for a plurality of developers. In FIG. 14, when the developer 101 targets a plurality of developers A and B, a development machine 10 is prepared for each developer A and B. Each development machine 10 is connected to a management server 12. Since each development machine 10 and the management server 12 are configured in the same manner as in FIG. In the system of FIG. 14, since the storage device 107 is shared by each development machine 10, each development machine 10 accesses each check flag database 116 stored in the storage device 107, so that each developer It is possible to detect the presence or absence of an element collision accompanying the change of A and B (necessary to change).

  FIG. 15 is a diagram for explaining a state in which a collision has occurred due to a change of a plurality of developers. FIG. 15A is a configuration diagram illustrating a display example of the display according to the third embodiment, and FIG. It is a block diagram of the change flag table in Example 3. In FIG. 15, when a plurality of developers 101 operate the peripheral devices 103 to display the list screen 801 on the screen of the display 102 and change “func2” or the like through the user interface display unit 108, The analysis unit 110 refers to the source code database 114 based on the instructed information, and displays a symbol on a function or variable (value1, func3, func1) that has a relationship of calling or called with “func2”. Execute the process. When this processing result is transferred to the display 102 via the interface display unit 108, the reference result of the source dependency analysis unit 110 is displayed on the list screen 801 of the display 102. At this time, each developer 101 can refer to the contents of the displayed list screen 801.

  In the list screen 801, the file (FileA.c) of “func2” and the function / variable “func2” are displayed as information about the change source 802, and the file affected by the change of “func2” Function / variable, file names (FileA.h, FileB.c, FileC.c) and function / variable names (value1, func3, func1) registered in the element table 203 and the change impact table 204 are displayed. Then, “Change” or “Called” registered in the change impact table 204 is displayed as the change impact type 804, and information registered in the other dependency number 208 of the element table 203 as the metric 805 (number of other dependencies: 15 etc.) is displayed. At this time, in the function / variable “func2” of the change source 802, the unchanged symbol point and the symbol (C) that needs to be changed are displayed as flags (check flags). In addition, the function / variable (value1, func3, func1) of the change influence 803 indicates an unchanged symbol point, a change-unnecessary symbol (N) or a change-needed symbol (C), and a change collision (with collision) A symbol (x) is displayed as a flag (check flag).

  The file name (FileA.h, FileA.c, FileB.c, FileC.c, FileB.c, FileC.c) is registered in the file 215 of the change flag table 214, and the function / variable 216 is registered. , Function or variable names (value1, func2, func3, func1, func3, func1) are registered, information of “not changed” is registered in the source configuration management state 217, and the planned change state 218 includes "No change required" is registered in the "FileA.h" field, "Change required" is registered in the "FileA.c" and "FileB.c" fields, and "No change is required" in the "FileC.c" field Is registered, “Change Required” is registered in “FileB.c” and “FileC.c”, and the change conflict state 219 includes “FileB.c”, “FileC.c”, “FileB.c”, “ “Change conflict” is registered in the “FileC.c” field, the name of the developer 101 (developer A or developer B) is registered in the updater 220, and each developer is registered in the update date 221. Information update date developers A or developer B) 101 is registered.

  Here, the flag management unit 112 refers to the change flag table 214 and compares the information registered in the source configuration management state 217 with the information registered in the planned change state 218 regarding the element ID3 “FileB.c”. Then, it is determined whether there is a change conflict between any pieces of information. At this time, “unchanged” is registered in the source configuration management state 217 as information by the operation of the developer A, “necessary to change” is registered in the planned change state 218, and the source configuration is stored as information by the operation of the developer B. When “not changed” is registered in the management state 217 and “change required” is registered in the scheduled change state 218, the flag management unit 112 determines “change conflict” because “change required” is duplicated. Then, the information of “change collision” is registered in the change collision state 219.

  In addition, the flag management unit 112 refers to the change flag table 214 and compares the information registered in the source configuration management state 217 with the information registered in the planned change state 218 regarding “FileC.c” of the element ID 4. , It is determined whether there is a change conflict between any of the information. At this time, “Unchanged” is registered in the source configuration management state 217 as information by the operation of the developer A, “Unchanged” is registered in the planned change state 218, and the source configuration is stored as information by the operation of the developer B. When “not changed” is registered in the management state 217 and “change required” is registered in the planned change state 218, the developer A is “change required” and the developer B is “change not required”. Therefore, the flag management unit 112 determines “change collision”, and registers “change collision” information in the change collision state 219.

  When information of “change collision” is recorded in the change collision state 219, the change management 803 of the list screen 801 has a change effect 803 on the list screen 801 by the processing of the flag management unit 112 and the user interface display unit 108. , The symbol (x) of the change collision state 703 is highlighted with respect to the files (FileB.c, FileC.c) of the element IDs 3 and 4. This is directly affected by elements with a change collision (x) on an element with a change schedule (C), but it is determined that no change is necessary (N), but it may be indirectly affected. Therefore, a warning is given to an element in which a change conflict has occurred. In this case, each developer A and B can easily confirm that a collision has occurred due to the change of the element by looking at the list screen 801. In this case, it is necessary to discuss between the developers A and B about the specific content of the change. It is possible to avoid problems caused by the content change and the conflict between the changes due to this discussion.

  According to the present embodiment, it is possible to detect a collision early when a plurality of developers add a new function in parallel, and to reduce double work.

  In addition, this invention is not limited to an above-described Example, Various modifications are included. For example, instead of the central processing unit 106 of the management server 12 managing the storage device 107, the central processing unit 104 of the development machine 10 can also manage the storage unit 107 as a controller. The above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.

  Further, each of the above-described configurations, functions, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit. Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor. Information such as programs, tables, and files that realize each function should be recorded in a recording device such as a memory, hard disk, or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD. Can do.

  DESCRIPTION OF SYMBOLS 10 Development machine, 12 Management server, 101 Developer, 102 Display, 103 Peripheral device, 104 Central processing arithmetic device, 105 Storage device, 106 Central processing arithmetic device, 107 Storage device, 108 User interface display part, 109 Source configuration management part 110 source dependency analysis unit, 111 source metric analysis unit, 112 flag management unit, 113 source code being changed, 114 source code database, 115 configuration management database, 116 check flag database, 203 element table, 204 change impact table, 212 Source code, 214 Change flag table, 701 Source configuration management status, 702 Scheduled change status, 703 Change collision status, 801 List screen

Claims (9)

A storage device for storing source code including a plurality of elements constituted by at least one of a function and a variable;
An input / output device for inputting / outputting information;
A software development support method in a system including a controller that manages the storage device and the input / output device,
When the controller receives from the input / output device a first change request for instructing a change in an element included in the source code, other elements affected by the received first change request are changed. A first step of storing, in the storage device, first change management information indicating whether or not and first change schedule information indicating whether or not there is a change schedule of other elements affected by the first change request;
The input / output device is an element instructed to change by the first change request, another element affected by the first change request, the first change management information, and the first change schedule information. A software development support method characterized by comprising: A software development support method according to claim 1,
When the controller receives from the input / output device a second change request that instructs to change an element included in the source code, other elements affected by the received second change request are changed. A third step of holding second change management information indicating whether or not and second change schedule information indicating whether or not there is a change schedule of other elements affected by the second change request;
The input / output device is an element instructed to change by the second change request, another element affected by the second change request, the second change management information, and the second change schedule information. And a fourth step of outputting the software. A software development support method according to claim 2,
The controller is
In the third step, the first change management information and the first change schedule information stored in the storage device, the held second change management information and the second change schedule information, A software development support method comprising: determining whether there is a change conflict between any of the information from the comparison result, and transferring the determination result to the input / output device. A software development support method according to claim 3,
The controller is
In the third step, the stored second change management information and the second change schedule information are stored in the storage device on the condition that it is determined that there is no change conflict between any one of the pieces of information. A software development support method characterized by: A software development support method according to claim 3,
The input / output device is
A software development support method comprising emphasizing and outputting an element specified by a determination result with a change collision when receiving a determination result with a change collision between any of the pieces of information from the controller. A software development support method according to claim 1 or 2,
The input / output device is
In the second step or the third step, the first numerical information indicating the number of other elements affected by the first change request or the other elements affected by the second change request. A software development support method characterized by outputting second numerical information indicating a number. A storage device for storing source code including a plurality of elements constituted by at least one of a function and a variable;
An input / output device for inputting / outputting information;
A software development support system comprising: a controller that manages the storage device and the input / output device;
The controller is
When a first change request instructing a change of an element included in the source code is received from the input / output device, it indicates whether another element affected by the received first change request has been changed. Storing first change management information and first change schedule information indicating whether or not there is a change schedule of other elements affected by the first change request in the storage device;
The input / output device is
The element instructed to change by the first change request, another element affected by the first change request, the first change management information, and the first change schedule information are output. Software development support system. The software development support system according to claim 7,
The controller is
When a second change request for instructing a change in an element included in the source code is received from the input / output device, it indicates whether another element affected by the received second change request has been changed. Holding second change management information and second change schedule information indicating whether or not there is a change schedule of other elements affected by the second change request,
The input / output device is
The element instructed to change by the second change request, another element affected by the second change request, the second change management information, and the second change schedule information are output. Software development support system. The software development support system according to claim 8,
The controller is
The first change management information and the first change schedule information stored in the storage device are compared with the held second change management information and the second change schedule information, and the comparison result To determine whether or not there is a change conflict between any of the pieces of information, and transfer the determination result to the input / output device.

Images