WO2022118627A1 - 計算機及びソフトウェアの修正箇所の選択方法 - Google Patents

計算機及びソフトウェアの修正箇所の選択方法 Download PDF

Info

Publication number
WO2022118627A1
WO2022118627A1 PCT/JP2021/041504 JP2021041504W WO2022118627A1 WO 2022118627 A1 WO2022118627 A1 WO 2022118627A1 JP 2021041504 W JP2021041504 W JP 2021041504W WO 2022118627 A1 WO2022118627 A1 WO 2022118627A1
Authority
WO
WIPO (PCT)
Prior art keywords
modification
organization
relationship
management information
software
Prior art date
Application number
PCT/JP2021/041504
Other languages
English (en)
French (fr)
Inventor
健二 北川
真澄 川上
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to EP21900382.9A priority Critical patent/EP4231156A1/en
Priority to US18/036,817 priority patent/US20240020217A1/en
Publication of WO2022118627A1 publication Critical patent/WO2022118627A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • the present invention relates to a technique for correcting software defects.
  • test as a general method for detecting defects.
  • the input and output are created as test cases based on the specifications or the developer's intention, and the test case is used to check whether the software returns the correct output for the input. If an output that is different from the specifications or the developer's intention is returned, or if the software stops due to the occurrence of an exception, it is determined that a defect has occurred.
  • the developer identifies the cause by analyzing in which part of the software including the defect the unexpected processing was performed, and corrects the software so that appropriate input / output is performed.
  • Large-scale and complicated software has a problem that the cost required for analysis and modification as described above is high.
  • the analysis range is often large, which tends to lead to an increase in cost.
  • Patent Document 1 describes "a specification information acquisition step in which a computer having a model format verification function acquires specification information including input interface specifications, output interface specifications, and internal specifications of software components, and an input interface in the specification information.
  • a verification step for verifying the software component by the format verification function and an example in which the output value does not satisfy the output interface specifications are found in the verification step according to the specification information in which the specification is changed to a value other than the normal value.
  • a failure propagation path storage step of associating and storing an input changed to a value other than the normal value and an output that does not satisfy the output interface specifications is executed.
  • Patent Document 1 can evaluate the behavior of software components when an abnormal input is given, but cannot analyze the cause of a defect such as an output abnormality with respect to a normal input. Further, when there are a plurality of candidates for correction points for removing defects, a method for selecting the correction points is not disclosed.
  • a typical example of the invention disclosed in the present application is as follows. That is, it is a computer including a processor and a storage device connected to the processor, and the processor is for removing a software source code including a plurality of statements composed of a plurality of elements and a defect in the source code.
  • the statement including the element to be modified is accepted as a modification location candidate information that manages the modification location candidate as an input, the modification location candidate is selected, and the modification of the element included in the selected modification location candidate is performed.
  • a score calculation process for calculating a score for evaluating time and effort is executed, the correction point candidate to be modified is selected based on the scores of the plurality of correction point candidates, and the score calculation process analyzes the source code.
  • the element of the statement other than the selected modification location candidate and the said element included in the selected modification location candidate which are affected by the modification of the element included in the selected modification location candidate. It includes a first process of specifying an element as an influence range, and a second process of calculating the score of the selected correction location candidate based on the influence range.
  • FIG. It is a figure which shows the configuration example of the defect analysis apparatus of Example 1.
  • FIG. It is a figure which shows an example of the source code of Example 1.
  • FIG. It is a figure which shows the concept of the correction part candidate stored in the correction part candidate information of Example 1.
  • FIG. It is a flowchart explaining an example of the correction part determination process executed by the defect analysis apparatus of Example 1.
  • FIG. It is a flowchart explaining an example of the correction part candidate analysis processing executed by the defect analysis apparatus of Example 1.
  • FIG. It is a figure which shows the configuration example of the defect analysis apparatus of Example 2.
  • It It is a figure which shows an example of the user / organization management information of Example 2.
  • FIG. It is a figure which shows an example of the cost management information of Example 2.
  • FIG. An example of the influence range specified by the defect analysis apparatus of Example 2 is shown. It is a figure which shows an example of the cost management information of Example 3.
  • FIG. An example of the influence range specified by the defect analysis apparatus of Example 2 is shown.
  • FIG. 1 is a diagram showing a configuration example of the defect analysis device 100 of the first embodiment.
  • the defect analysis device 100 includes a processor 110, a storage device 111, and a network interface 112. Each hardware element is connected via an internal bus.
  • the defect analysis device 100 connects to the software configuration management system 101 via a network such as WAN (Wide Area Network) and LAN (Local Area Network).
  • WAN Wide Area Network
  • LAN Local Area Network
  • the defect analysis device 100 may include a storage medium such as an HDD and an SSD, an input device such as a keyboard, a mouse, and a touch panel, or an output device such as a display and a printer. good.
  • a storage medium such as an HDD and an SSD
  • an input device such as a keyboard, a mouse, and a touch panel
  • an output device such as a display and a printer. good.
  • the processor 110 executes a program stored in the storage device 111.
  • the processor 110 executes processing according to a program, it operates as a functional unit that realizes a specific function.
  • the processor 110 is executing the program that realizes the functional unit.
  • the storage device 111 stores a program executed by the processor 110 and information used by the program.
  • the storage device 111 is also used as a work area.
  • the network interface 112 is an interface for connecting to an external device or an external system via a network.
  • the storage device 111 of the first embodiment stores the source code 130, the specification information 131, the execution log 132, and the correction location candidate information 133.
  • the source code 130 is the source code of the software to be analyzed.
  • the source code 130 includes a plurality of statements including functions, instructions, and the like as elements.
  • the source code 130 is generally divided into function units. By calling the function, the processing flow of the source code 130 is constructed.
  • Specification information 131 is information related to software specifications.
  • the specification information 131 stores, for example, the name of the function included in the source code 130, and the name, type, range, and the like of the input value and the return value of the function.
  • the execution log 132 is a software execution log.
  • the execution log 132 includes a function call record, an input value and a return value at the time of function call, and the like.
  • Correction part candidate information 133 is information for managing correction part candidates including elements to be modified for removing defects.
  • the modification location candidate information 133 of the first embodiment stores an execution path and a path condition acquired by symbol execution (Symbolic Execution).
  • the execution path consists of one or more statements.
  • one line is treated as one statement, and one statement is managed as one correction part candidate.
  • the elements such as the function included in the statement are modified.
  • the processor 110 of the first embodiment acts as an analysis unit 120, an influence range search unit 121, a modification history acquisition unit 122, a score evaluation unit 123, and a correction location determination unit 124 by executing a program stored in the storage device 111.
  • each functional unit may integrate a plurality of functional units into one functional unit, or may divide one functional unit into a plurality of functional units for each function.
  • the analysis unit 120 analyzes the source code 130 and identifies correction location candidates.
  • the influence range search unit 121 searches for the element affected by the modification of the element included in the correction location candidate, and outputs the searched element and the element included in the correction location candidate as the influence range. Specifically, the influence range search unit 121 searches for a function that calls a function included in the correction location candidate, and further searches for a function that calls the searched function. By repeatedly executing the search, the influence range search unit 121 outputs a tree of the call relations of the function starting from the correction location candidate as the influence range.
  • the influence range search unit 121 may perform the correction location search unit 121.
  • the call relationship of the function can be limited based on the information. If the call relationship of the function included in the modification location candidate is traced and the value of the variable cannot be the value when a problem occurs, it can be excluded from the range of influence. Variable constraints can be specified by using symbol execution or the like.
  • the modification history acquisition unit 122 acquires the modification history related to the function extracted as the influence range from the software configuration management system 101.
  • the software configuration management system 101 has a function of managing software versions, and holds software configuration management information 140 that stores the source code 130 of each version of software.
  • the source code 130 stored in the software configuration management information 140 is managed in association with the modified user or organization identification information, the modified date and time, and the like.
  • the version is updated, the updated source code 130 is registered in the software configuration management information 140.
  • the software configuration management system 101 manages software versions on a file-by-file basis.
  • the modification history acquisition unit 122 has a function of acquiring the modification history of each function by comparing the files before and after the modification.
  • the score evaluation unit 123 calculates a score representing the effort of modifying the elements included in the correction location candidate based on the influence range of the correction location candidate. For example, the score evaluation unit 123 calculates the number of functions included in the influence range as a score. Further, the score evaluation unit 123 calculates the total number of modification histories of each function included in the influence range as a score. The score may be calculated in consideration of the depth of the layer of the tree.
  • the correction location determination unit 124 determines the modification location candidate to be modified based on the score of each modification location candidate.
  • FIG. 2 is a diagram showing an example of the source code 130 of the first embodiment.
  • FIG. 3 is a diagram showing the concept of the correction location candidate stored in the correction location candidate information 133 of the first embodiment.
  • the source code 130 shown in FIG. 2 includes a function apel, a function bar, and a function foo.
  • the function apel calls the function bar
  • the function bar calls the function foo.
  • the execution log 132 includes a log relating to each call of the function apel, the function bar, and the function foo, and the occurrence of division by zero.
  • the variables included in the function are local variables. Therefore, the variables a and b included in each function have the same character but represent different variables.
  • the black-and-white inverted statements of the source code 130 represent the execution path.
  • the path condition is inserted as a comment in the statement included in the execution path.
  • the correction location candidate information 133 stores information for managing the relationship as shown in FIG.
  • FIG. 4 is a flowchart illustrating an example of a correction location determination process executed by the defect analysis device 100 of the first embodiment.
  • FIG. 5 is a flowchart illustrating an example of the correction location candidate analysis process executed by the defect analysis device 100 of the first embodiment.
  • the defect analysis device 100 When the defect analysis device 100 receives the input of the source code 130, the specification information 131, and the execution log 132, the defect analysis device 100 starts the correction location determination process.
  • the source code 130, the specification information 131, and the execution log 132 may be input to the defect analysis device 100 in advance. In this case, the correction location determination process is started triggered by the execution instruction by the user.
  • the analysis unit 120 executes the correction location candidate analysis process (step S101).
  • the correction location candidate analysis process will be described with reference to FIG.
  • the analysis unit 120 extracts the function call relationship using the source code 130 (step S201). Information indicating the function call relationship is stored in the work area.
  • the analysis unit 120 identifies the analysis start point based on the execution log 132 (step S202).
  • the analysis unit 120 specifies a statement in which a defect such as an exception occurs as an analysis start point. If there are a plurality of statements that can be the analysis start point, the analysis unit 120 may inquire of the developer and accept the input of the analysis start point.
  • the analysis unit 120 specifies the analysis end point based on the function call relationship and the analysis start point (step S203).
  • the analysis unit 120 identifies a function that calls a function included in the analysis start point based on the function call relationship, and presents the function to the developer.
  • the analysis unit 120 identifies the function selected by the developer as the analysis end point.
  • the analysis unit 120 executes the reverse symbol from the analysis start point (step S204).
  • the analysis unit 120 executes the symbol in the direction opposite to the direction of the program from the analysis start point.
  • the analysis unit 120 records the execution path and the path condition in the correction location candidate information 133 while the reverse symbol is being executed.
  • the analysis unit 120 ends the reverse symbol execution.
  • the engine that realizes the reverse symbol execution the engine described in Non-Patent Document 1 may be used.
  • the analysis unit 120 calculates the input parameter value of the function included in the analysis end point that satisfies the path condition by using the SMT solver (Satisfiability Modulo Theories Solver). By performing a test with this value as an input, the developer can confirm whether the modified program works properly.
  • SMT solver Stisfiability Modulo Theories Solver
  • the analysis unit 120 determines whether or not the end point of the reverse symbol execution matches the first line of the analysis end point (step S205).
  • the analysis unit 120 identifies the caller of the function at the end point (step S206), and then returns to step S204.
  • the reverse symbol is executed from the caller of the function at the end point.
  • the analysis unit 120 ends the correction part candidate analysis process.
  • the analysis unit 120 searches in the opposite direction from row 8. As a result, the analysis unit 120 updates the execution path from line 13 to line 11 and from line 8 to line 6.
  • the analysis unit 120 searches in the opposite direction from row 3. As a result, the analysis unit 120 updates the execution path from row 13 to row 11, row 8 to row 6, and row 3 to row 1.
  • the influence range search unit 121 refers to the correction location candidate information 133 and selects one correction location candidate (step S102).
  • the influence range search unit 121 specifies the influence range of the correction location candidate based on the call relationship of the function (step S103). Information indicating the range of influence is stored in the work area.
  • the modification history acquisition unit 122 acquires the modification history of each function included in the influence range by accessing the software configuration management information 140 (step S104).
  • step S104 When calculating the score without using the modification history, the process of step S104 can be omitted.
  • the score evaluation unit 123 calculates the score of the selected correction location candidate based on the acquired modification history (step S105). The score is stored in the work area.
  • the score evaluation unit 123 determines whether or not the processing of all the correction location candidates has been completed (step S106).
  • the score evaluation unit 123 calls the influence range search unit 121 and returns to step S102.
  • the score evaluation unit 123 calls the correction part determination unit 124.
  • the correction part determination unit 124 selects the correction part to be modified from the correction part candidates based on the score (step S107). For example, a method of selecting the correction part candidate having the lowest score as the correction part can be considered.
  • the correction location determination unit 124 outputs information regarding the selected correction location as a processing result (step S108). After that, the defect analysis device 100 ends the correction location determination process.
  • the correction location determination unit 124 may also output information regarding the range of influence.
  • the process of specifying the correction point candidate (analysis process) and the process of selecting the correction point (selection process) may be executed by different computers.
  • the computer that executes the selection process receives the input of the correction location candidate information 133 and the source code 130 from the computer that executes the analysis process, and executes the processes of steps S102 to S108.
  • the defect analysis device 100 can specify a plurality of correction location candidates. Further, the defect analysis device 100 can calculate the time and effort for modifying the elements included in each modification location candidate as a score based on the influence range and the modification history, and can determine the modification target modification location candidate based on the score. By using the score that evaluates the influence on other functions (statements) due to the modification of the elements included in the modification location candidate, that is, the effort of modification, the modification location is selected based on the developer's sense of burden of modification work. can. As a result, it is possible to improve the efficiency and accuracy of software debugging work.
  • the score is calculated based on the relationship between the user who modified the source code 130 and the software developer.
  • Example 2 will be described with a focus on the differences from Example 1.
  • FIG. 6 is a diagram showing a configuration example of the defect analysis device 100 of the second embodiment.
  • the hardware configuration of the defect analysis device 100 of the second embodiment is the same as that of the first embodiment.
  • the functional configuration of the defect analysis device 100 of the second embodiment is the same as that of the first embodiment.
  • the information held by the defect analysis device 100 is partially different.
  • the storage device 111 of the second embodiment newly stores the user / organization management information 134 and the cost management information 135.
  • the correction location candidate is used by using the cost management information 135 in which the cost reflecting the relationship between the organization to which the developer belongs and the organization responsible for the function is set.
  • the score is calculated.
  • FIG. 7 is a diagram showing an example of the user / organization management information 134 of the second embodiment.
  • the user / organization management information 134 is information for managing the organization to which the user belongs.
  • the user / organization management information 134 stores an entry composed of the user ID 701 and the affiliated organization 702. There is one entry for one user.
  • the user ID 701 is a field for storing user identification information.
  • the user ID 701 stores the identification information of the user registered in the software configuration management system 101.
  • the affiliated organization 702 is a field for storing a value indicating the organization to which the user belongs.
  • an organization is a concept that includes groups, teams, departments, and companies.
  • the affiliated organization 702 stores a value indicating a relative organization set based on the organization (development project) to which the software developer belongs.
  • the name of a specific organization or the like may be stored in the affiliated organization 702.
  • the responsible organization on the software configuration management system 101 can be clarified by assigning a virtual user to the organization or adding a comment to manage it.
  • FIG. 8 is a diagram showing an example of the cost management information 135 of the second embodiment.
  • the cost management information 135 is information for managing the cost set based on the relationship between the organization to which the developer belongs and the organization to which the user who has modified a certain function belongs.
  • the cost management information 135 stores an entry composed of the relationship 801 and the cost 802. There is one entry for a relationship between one organization.
  • the relationship 801 is a field for storing a value indicating the relationship between the organization to which the developer belongs and the organization to which the user who modified the function belongs.
  • the cost 802 is a field for storing the cost expressing the time and effort (for example, negotiation) required for modifying the function included in the modification location candidate, which is set based on the relationship between the organizations.
  • the cost set to the cost 802 is dimensionless and is not a numerical value representing an absolute evaluation but a numerical value expressing a sense of burden on the developer. In the second embodiment, a numerical value corresponding to the magnitude of the burden is set.
  • the processing flow of the correction location determination process of the second embodiment is the same as that of the first embodiment.
  • the user / organization management information 134 and the cost management information 135 are input together with the source code 130, the specification information 131, and the execution log 132.
  • the processing contents of step S104 and step S105 are partially different.
  • step S104 the modification history acquisition unit 122 acquires the modification history including the information of the modified user.
  • the score evaluation unit 123 identifies a user who has modified each function included in the influence range by using the modification history.
  • the score evaluation unit 123 identifies the organization to which the specified user belongs with reference to the user / organization management information 134.
  • the score evaluation unit 123 identifies the relationship between the organization to which the developer belongs and the organization to which the modified user belongs, and refers to the cost management information 135 to refer to the relationship between the identified organizations. Get the cost corresponding to.
  • the score evaluation unit 123 calculates the total value of the acquired costs as a score.
  • the score evaluation unit 123 was specified based on the range of influence from the idea that if the organization to which the developer belongs and the organization to which the user who made the modification belongs are the same, the trouble of negotiation and the like can be summarized. A score may be calculated for a set that eliminates tissue duplication.
  • the score evaluation unit 123 selects the organization having the lowest cost as the responsible organization for the function.
  • the correction part determination unit 124 selects the correction part candidate having the lowest score as the correction part.
  • FIG. 9 shows an example of the influence range specified by the defect analysis device 100 of the second embodiment.
  • the influence range search unit 121 specifies the influence range 900 as shown in FIG. 9 when the correction part candidate including the function funca () is set as the analysis start point.
  • the range of influence 900 includes the function funcB (), the function funcC (), and the function funcD (). Arrows represent function call relationships.
  • the score evaluation unit 123 identifies a user who has modified each of the function funca (), the function funcB (), the function funcC (), and the function funcD () based on the modification history.
  • “user1” is used for the function funca ()
  • "user1” is used for the function funcB ()
  • "user4" is used for the function funcC ()
  • "user5" is used for the function funcD (). It shall be identified.
  • Example 2 scoring that reflects the time and effort of negotiation between organizations becomes possible. Therefore, it is possible to select the correction part based on the feeling of the burden of the modification work of the developer.
  • Example 2 the cost was set based on the relationship between the organization to which the developer belongs and the organization responsible for the function.
  • the cost is set based on the relationship between the responsible organizations of the functions included in the scope of influence.
  • Example 3 will be described with a focus on the differences from Example 1 and Example 2.
  • the configuration of the defect analysis device 100 of the third embodiment is the same as that of the second embodiment.
  • the structure of the cost management information 135 is different from that of the second embodiment.
  • the score of the correction location candidate is calculated using the cost management information 135 in which the cost reflecting the relationship between the caller function and the callee function is set. It should be noted that the above-mentioned idea can be similarly applied to the relationship between users.
  • FIG. 10 is a diagram showing an example of the cost management information 135 of the third embodiment.
  • the cost management information 135 is information for managing the cost set based on the relationship between the organizations.
  • the cost management information 135 stores an entry composed of the relationship 1001 and the cost 1002. There is one entry for a relationship between one organization. The relationship between organizations may be changed to the relationship between users.
  • the relationship 1001 is a field for storing a value indicating the relationship between the organizations to which the user who developed the function having the call relationship belongs.
  • the cost 1002 is a field for storing the cost expressing the time and effort required to modify the correction location candidate, which is set based on the relationship between the organizations to which the user who developed the function having the call relationship belongs.
  • the cost set to the cost 1002 is dimensionless, does not represent an absolute evaluation, but is a numerical value expressing a sense of burden between organizations that have modified the function of the caller and the function of the callee. In the third embodiment, a numerical value corresponding to the magnitude of the burden is set.
  • the first entry of the cost management information 135 is set to the cost set based on the relationship between users.
  • the processing flow of the correction location determination process of Example 3 is the same as that of Example 1.
  • the user / organization management information 134 and the cost management information 135 are input together with the source code 130, the specification information 131, and the execution log 132. Further, in the third embodiment, the processing contents of step S104 and step S105 are partially different.
  • step S104 the modification history acquisition unit 122 acquires the modification history including the information of the modified user.
  • the score evaluation unit 123 identifies a user who has modified each function included in the influence range by using the modification history.
  • the score evaluation unit 123 identifies the organization to which the specified user belongs with reference to the user / organization management information 134.
  • the score evaluation unit 123 specifies the relationship between the organizations to which the user belongs for each call of the function based on the call relationship of the function.
  • the score evaluation unit 123 refers to the cost management information 135 to acquire the cost corresponding to the relationship between the identified organizations.
  • the score evaluation unit 123 calculates the total value of the acquired costs as a score.
  • the score evaluation unit 123 selects the organization having the lowest cost as the responsible organization for the function.
  • the correction part determination unit 124 selects the correction part candidate having the lowest score as the correction part.
  • the score evaluation unit 123 identifies a user who has modified each of the function funca (), the function funcB (), the function funcC (), and the function funcD () based on the modification history.
  • “user1” is used for the function funca ()
  • "user1” is used for the function funcB ()
  • "user4" is used for the function funcC ()
  • "user5" is used for the function funcD (). It shall be identified.
  • the cost is "1" because the relationship between the organizations in the calling relationship of the function funca () and the function funcB () is "the same user". Since the relationship between the organizations in the calling relationship of the function funcB () and the function funcC () is "in the same part", the cost is "5". Since the relationship between the organizations in the calling relationship of the function funca () and the function funcD () is "the same company", the cost is "10". Therefore, the score of the correction part candidate including the function funca () is "16".
  • Example 3 scoring that reflects the time and effort of negotiation between organizations is possible. Therefore, it is possible to select the correction part based on the feeling of the burden of the modification work of the developer.
  • scoring of Example 2 and Example 3 may be performed in parallel, and the total value of the score by the scoring of Example 2 and the score by the scoring of Example 3 may be calculated as the score of the correction location candidate. ..
  • the cost standards set in the cost management information 135 of the second embodiment and the cost management information 135 of the third embodiment are prepared.
  • the weighted average value calculated by multiplying each score by the weight can be compared.
  • Example 4 the cost is corrected based on the simultaneity of modification of the source code 130 and the relationship between the date and time.
  • Example 4 will be described with a focus on the differences from Example 1 and Example 3.
  • an operation is performed to register the source code 130, which is a modification of closely related functions, in the software configuration management system 101.
  • Simultaneity of modification means that the modification content of the function is registered at the same time by the commit.
  • the configuration of the defect analysis device 100 of Example 4 is the same as that of Example 1.
  • the processing flow of the correction location determination process of Example 4 is the same as that of Example 1. However, the processing contents of step S104 and step S105 are partially different.
  • step S104 the modification history acquisition unit 122 acquires the modification history including the modified user information, the simultaneity of the modification, and the date and time.
  • the score evaluation unit 123 identifies a user who has modified each function included in the influence range by using the modification history.
  • the score evaluation unit 123 identifies the organization to which the specified user belongs with reference to the user / organization management information 134.
  • the score evaluation unit 123 specifies the relationship between the organizations for each call of the function based on the call relationship of the function.
  • the score evaluation unit 123 refers to the cost management information 135 to acquire the cost corresponding to the relationship between the identified organizations.
  • the score evaluation unit 123 corrects the cost based on the simultaneity of the modification between the functions and the date and time.
  • the cost is multiplied by 1, and in the case of a combination of functions without simultaneity of modification, the cost is multiplied by 1.3. If the modification date and time interval is smaller than the threshold value, the cost is multiplied by 1, and if the modification date and time interval is larger than the threshold value, 1.2 is multiplied.
  • the score evaluation unit 123 calculates the total value of the corrected costs as a score.
  • Example 4 more accurate scoring is possible by modifying the cost based on the simultaneity of modifications and the date and time of modifications.
  • the present invention is not limited to the above-described embodiment, but includes various modifications.
  • the above-described embodiment describes the configuration in detail in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to the one including all the described configurations. Further, it is possible to add, delete, or replace a part of the configuration of each embodiment with other configurations.
  • each of the above configurations, functions, processing units, processing means, etc. may be realized by hardware by designing a part or all of them by, for example, an integrated circuit.
  • the present invention can also be realized by a software program code that realizes the functions of the examples.
  • a storage medium in which the program code is recorded is provided to the computer, and the processor included in the computer reads out the program code stored in the storage medium.
  • the program code itself read from the storage medium realizes the function of the above-described embodiment, and the program code itself and the storage medium storing the program code constitute the present invention.
  • Examples of the storage medium for supplying such a program code include a flexible disk, a CD-ROM, a DVD-ROM, a hard disk, an SSD (Solid State Drive), an optical disk, a magneto-optical disk, a CD-R, and a magnetic tape.
  • Non-volatile memory cards, ROMs, etc. are used.
  • program code that realizes the functions described in this embodiment can be implemented in a wide range of programs or script languages such as assembler, C / C ++, perl, Cell, PHP, Python, and Java.
  • the program code is stored in a storage means such as a hard disk or a memory of a computer or a storage medium such as a CD-RW or a CD-R.
  • the processor included in the computer may read and execute the program code stored in the storage means or the storage medium.
  • control lines and information lines indicate what is considered necessary for explanation, and do not necessarily indicate all the control lines and information lines in the product. All configurations may be interconnected.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Computer Security & Cryptography (AREA)
  • Game Theory and Decision Science (AREA)
  • General Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

計算機は、ステートメントを含むソフトウェアのソースコードと、改変対象の要素を含むステートメントを修正箇所候補として管理する情報とを入力として受け付け、修正箇所候補を選択して、選択された修正箇所候補に含まれる要素の改変の手間を評価するスコアを算出するスコア算出処理を実行し、スコアに基づいて、改変を行う修正箇所候補を選択する。スコア算出処理は、ソースコードを解析することによって、選択された修正箇所候補に含まれる要素の改変によって影響を受ける、選択された修正箇所候補以外のステートメントの要素と、選択された修正箇所候補に含まれる要素とを影響範囲として特定する処理と、影響範囲に基づいて、選択された修正箇所候補のスコアを算出する処理と、を含む。

Description

計算機及びソフトウェアの修正箇所の選択方法 参照による取り込み
　本出願は、２０２０年１２月１日に出願された日本特許出願第２０２０－１９９３１５号の優先権を主張し、その内容を参照することにより、本出願に取り込む。
　本発明は、ソフトウェアの不具合の修正技術に関する。
　ソフトウェア開発において、仕様書と異なる又は開発者が想定していないソフトウェアの動作は不具合と呼ばれる。ソフトウェアをリリースする前に全ての不具合が修正されていることが望ましい。
　不具合を検出する一般的な手法としてはテストがある。テストでは、仕様書又は開発者の意図に基づいて、入力及び出力をテストケースとして作成し、テストケースを用いてソフトウェアが入力に対して正しい出力を返すかを確認する。仕様書若しくは開発者の意図とは異なる出力が返ってきた場合、又は、例外の発生によってソフトウェアが停止した場合、不具合の発生と判定される。
　開発者は、不具合を含むソフトウェアのどの部分で想定外の処理が行われたかを解析することによって原因箇所を特定し、適切な入出力を行うようにソフトウェアを修正する。大規模かつ複雑なソフトウェアは、前述のような解析及び修正に要するコストが大きいという問題がある。また、ソフトウェアの完成間近で不具合が検出された場合、解析範囲が大きい場合が多く、コストの肥大化につながりやすい。
　ソフトウェアの不具合の解析及び修正を効率よく行う技術として、例えば、特許文献１に記載の技術が知られている。特許文献１には、「モデルの形式検証機能を有するコンピュータが、ソフトウェアコンポーネントの入力インタフェース仕様、出力インタフェース仕様、内部仕様を含む仕様情報を取得する仕様情報取得ステップと、前記仕様情報中の入力インタフェース仕様を正常値以外に変更した仕様情報に従って、前記形式検証機能によって前記ソフトウェアコンポーネントを検証する検証ステップと、前記検証ステップにおいて前記出力インタフェース仕様を満足しない出力値となる例が発見された場合には、前記正常値以外に変更した入力と、前記出力インタフェース仕様を満たさない出力とを、対応づけて記憶する故障伝播路記憶ステップと、を実行する。」ことが記載されている。
特開２０１２－１２８７２７号公報
Peter Dinges, Gul Agha、「Targeted Test Input Generation Using Symbolic-Concrete Backward Execution」、29th ACM/IEEE international conference on Automated software engineering、September 2014、Pages 31-36
　特許文献１に記載の技術は、異常な入力を与えた場合のソフトウェアコンポーネントの挙動を評価できるが、正常な入力に対する出力の異常等の不具合の原因を解析できない。また、不具合を取り除くための修正箇所の候補が複数ある場合に修正箇所の選択方法が開示されていない。
　本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、プロセッサ、及び前記プロセッサに接続される記憶装置を備える計算機であって、前記プロセッサは、複数の要素から構成されるステートメントを複数含むソフトウェアのソースコードと、前記ソースコードの不具合を取り除くための改変対象の前記要素を含む前記ステートメントを修正箇所候補として管理する修正箇所候補情報とを入力として受け付け、前記修正箇所候補を選択して、前記選択された修正箇所候補に含まれる前記要素の改変の手間を評価するスコアを算出するスコア算出処理を実行し、前記複数の修正箇所候補の前記スコアに基づいて、改変を行う前記修正箇所候補を選択し、前記スコア算出処理は、前記ソースコードを解析することによって、前記選択された修正箇所候補に含まれる前記要素の改変によって影響を受ける、前記選択された修正箇所候補以外の前記ステートメントの前記要素と、前記選択された修正箇所候補に含まれる前記要素とを影響範囲として特定する第１処理と、前記影響範囲に基づいて、前記選択された修正箇所候補の前記スコアを算出する第２処理と、を含む。
　本発明によれば、不具合を取り除くための修正箇所の候補の中から、改変に要する手間が少ない修正箇所を選択できる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
実施例１の不具合解析装置の構成例を示す図である。 実施例１のソースコードの一例を示す図である。 実施例１の修正箇所候補情報に格納される修正箇所候補の概念を示す図である。 実施例１の不具合解析装置が実行する修正箇所決定処理の一例を説明するフローチャートである。 実施例１の不具合解析装置が実行する修正箇所候補解析処理の一例を説明するフローチャートである。 実施例２の不具合解析装置の構成例を示す図である。 実施例２のユーザ／組織管理情報の一例を示す図である。 実施例２のコスト管理情報の一例を示す図である。 実施例２の不具合解析装置によって特定された影響範囲の一例を示す。 実施例３のコスト管理情報の一例を示す図である。
　以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
　以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を付し、重複する説明は省略する。
　本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数又は順序を限定するものではない。
　図１は、実施例１の不具合解析装置１００の構成例を示す図である。
　不具合解析装置１００は、プロセッサ１１０、記憶装置１１１、及びネットワークインタフェース１１２を備える。各ハードウェア要素は内部バスを介して接続される。不具合解析装置１００は、ＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）及びＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）等のネットワークを介して、ソフトウェア構成管理システム１０１と接続する。
　なお、不具合解析装置１００は、ＨＤＤ及びＳＳＤ等の記憶媒体を備えてもよいし、キーボード、マウス、及びタッチパネル等の入力装置を備えてもよいし、ディスプレイ及びプリンタ等の出力装置を備えてもよい。
　プロセッサ１１０は、記憶装置１１１に格納されるプログラムを実行する。プロセッサ１１０がプログラムにしたがって処理を実行することによって、特定の機能を実現する機能部として動作する。以下の説明では、機能部を主語に処理を説明する場合、プロセッサ１１０が機能部を実現するプログラムを実行していることを示す。
　記憶装置１１１は、プロセッサ１１０が実行するプログラム及びプログラムが使用する情報を格納する。記憶装置１１１はワークエリアとしても用いられる。
　ネットワークインタフェース１１２は、ネットワークを介して外部装置又は外部システムと接続するためのインタフェースである。
　実施例１の記憶装置１１１は、ソースコード１３０、仕様情報１３１、実行ログ１３２、及び修正箇所候補情報１３３を格納する。
　ソースコード１３０は、解析対象のソフトウェアのソースコードである。ソースコード１３０は、関数及び命令等を要素として含むステートメントを複数含む。ソースコード１３０は、一般的に関数単位に区切られる。関数の呼出によって、ソースコード１３０の処理の流れが構築される。
　仕様情報１３１は、ソフトウェアの仕様に関する情報である。仕様情報１３１には、例えば、ソースコード１３０に含まれる関数の名前、並びに、関数の入力値及び返り値の名前、型、及び範囲等が格納される。
　実行ログ１３２は、ソフトウェアの実行ログである。実行ログ１３２には、関数の呼出記録、並びに、関数の呼出時の入力値及び返り値等が含まれる。
　修正箇所候補情報１３３は、不具合を取り除くための改変対象となる要素を含む修正箇所候補を管理する情報である。実施例１の修正箇所候補情報１３３には、記号実行（Ｓｙｍｂｏｌｉｃ　Ｅｘｅｃｕｔｉｏｎ）によって取得された実行パス及びパス条件が格納される。
　実行パスは一つ以上のステートメントから構成される。実施例１では、一つの行を一つのステートメントとして扱い、一つのステートメントを一つの修正箇所候補として管理する。ソースコード１３０の改変では、ステートメントに含まれる関数等の要素が改変される。
　実施例１のプロセッサ１１０は、記憶装置１１１に格納されるプログラムを実行することによって、解析部１２０、影響範囲探索部１２１、改変履歴取得部１２２、スコア評価部１２３、及び修正箇所決定部１２４として機能する。なお、各機能部は、複数の機能部を一つの機能部に集約してもよいし、一つの機能部を機能毎に複数の機能部に分けてもよい。
　解析部１２０は、ソースコード１３０を解析し、修正箇所候補を特定する。
　影響範囲探索部１２１は、修正箇所候補に含まれる要素の改変の影響を受ける要素を探索し、探索された要素と、修正箇所候補に含まれる要素とを影響範囲として出力する。具体的には、影響範囲探索部１２１は、修正箇所候補に含まれる関数を呼び出す関数を探索し、さらに、探索された関数を呼び出す関数を探索する。影響範囲探索部１２１は、探索を繰り返し実行することによって、修正箇所候補を起点とする関数の呼出関係のツリーを影響範囲として出力する。
　なお、修正箇所候補情報１３３に格納される修正箇所候補に、不具合発生の原因となる変数及び値の制約に関する情報（例えば、パス条件）が対応づけられている場合、影響範囲探索部１２１は、当該情報に基づいて関数の呼出関係を限定できる。修正箇所候補に含まれる関数の呼出関係をたどって、変数の値が不具合の発生時に値になり得ないような呼出関係であれば、影響範囲から除外できる。変数の制約は、記号実行等を用いて特定できる。
　改変履歴取得部１２２は、ソフトウェア構成管理システム１０１から、影響範囲として抽出された関数に関する改変履歴を取得する。
　ソフトウェア構成管理システム１０１は、ソフトウェアのバージョンを管理する機能を有し、各バージョンのソフトウェアのソースコード１３０を格納するソフトウェア構成管理情報１４０を保持する。ソフトウェア構成管理情報１４０に格納されるソースコード１３０には、改変したユーザ又は組織の識別情報及び改変した日時等が対応付けて管理される。バージョンが更新された場合、ソフトウェア構成管理情報１４０には更新されたソースコード１３０が登録される。一般的に、ソフトウェア構成管理システム１０１は、ファイル単位でソフトウェアのバージョンを管理する。改変履歴取得部１２２は、改変前後のファイルを比較することによって関数単位の改変履歴を取得する機能を有する。
　スコア評価部１２３は、修正箇所候補の影響範囲に基づいて、修正箇所候補に含まれる要素の改変の手間を表すスコアを算出する。例えば、スコア評価部１２３は、影響範囲に含まれる関数の数をスコアとして算出する。また、スコア評価部１２３は、影響範囲に含まれる各関数の改変履歴の数の合計をスコアとして算出する。ツリーの層の深さを考慮したスコアが算出されてもよい。
　修正箇所決定部１２４は、各修正箇所候補のスコアに基づいて、改変を行う修正箇所候補を決定する。
　図２は、実施例１のソースコード１３０の一例を示す図である。図３は、実施例１の修正箇所候補情報１３３に格納される修正箇所候補の概念を示す図である。
　図２に示すソースコード１３０は、関数ｂａｚ、関数ｂａｒ、関数ｆｏｏを含む。関数ｂａｚは関数ｂａｒを呼び出し、関数ｂａｒは関数ｆｏｏを呼び出す。関数ｆｏｏで０除算が発生した場合、不具合の発生として検出される。この場合、実行ログ１３２には、関数ｂａｚ、関数ｂａｒ、及び関数ｆｏｏの各々の呼出、０除算の発生に関するログが含まれる。
　なお、関数に含まれる変数はローカル変数である。したがって、各関数に含まれる変数ａ、ｂは同じ文字であるが、異なる変数を表す。
　図３において、ソースコード１３０の白黒が反転したステートメント群が実行パスを表す。実行パスに含まれるステートメントにはパス条件がコメントとして挿入されている。
　修正箇所候補情報１３３には、図３に示すような関係を管理するための情報が格納される。
　図４は、実施例１の不具合解析装置１００が実行する修正箇所決定処理の一例を説明するフローチャートである。図５は、実施例１の不具合解析装置１００が実行する修正箇所候補解析処理の一例を説明するフローチャートである。
　不具合解析装置１００は、ソースコード１３０、仕様情報１３１、及び実行ログ１３２の入力を受け付けた場合、修正箇所決定処理を開始する。なお、ソースコード１３０、仕様情報１３１、及び実行ログ１３２は予め不具合解析装置１００に入力してもよい。この場合、ユーザによる実行指示を契機に修正箇所決定処理が開始される。
　まず、解析部１２０は、修正箇所候補解析処理を実行する（ステップＳ１０１）。ここで、図５を用いて修正箇所候補解析処理について説明する。
　解析部１２０は、ソースコード１３０を用いて関数の呼出関係を抽出する（ステップＳ２０１）。関数の呼出関係を示す情報は、ワークエリアに格納される。
　次に、解析部１２０は、実行ログ１３２に基づいて解析開始点を特定する（ステップＳ２０２）。
　具体的には、解析部１２０は、例外等の不具合が発生したステートメントを解析開始点として特定する。なお、解析開始点となりうるステートメントが複数存在する場合、解析部１２０は、開発者に問い合わせて、解析開始点の入力を受け付けてもよい。
　次に、解析部１２０は、関数の呼出関係及び解析開始点に基づいて、解析終了点を特定する（ステップＳ２０３）。
　具体的には、解析部１２０は、関数の呼出関係に基づいて、解析開始点に含まれる関数を呼び出す関数を特定し、当該関数を開発者に提示する。解析部１２０は、開発者によって選択された関数を解析終了点として特定する。
　次に、解析部１２０は、解析開始点から、逆向き記号実行を行う（ステップＳ２０４）。
　具体的には、解析部１２０は、解析開始点から、プログラムの方向とは逆の方向に記号実行を行う。解析部１２０は、逆向き記号実行中、実行パス及びパス条件を修正箇所候補情報１３３に記録する。パス条件が成立しない条件になった場合、解析部１２０は、逆向き記号実行を終了する。逆向き記号実行を実現するエンジンは非特許文献１に記載されているものを用いればよい。
　なお、解析部１２０は、ＳＭＴソルバ（Ｓａｔｉｓｆｉａｂｉｌｉｔｙ　Ｍｏｄｕｌｏ　Ｔｈｅｏｒｉｅｓ　Ｓｏｌｖｅｒ）を用いて、パス条件を満足する解析終了点に含まれる関数の入力パラメータ値を算出する。この値を入力とするテストを行うことによって、開発者は改変したプログラムが正しく動作するか否かを確認できる。
　次に、解析部１２０は、逆向き記号実行の終了地点が解析終了点の先頭行に一致するか否かを判定する（ステップＳ２０５）。
　逆向き記号実行の終了地点が解析終了点の先頭行に一致しない場合、解析部１２０は、終了地点の関数の呼出元を特定し（ステップＳ２０６）、その後、ステップＳ２０４に戻る。ステップＳ２０４では、終了地点の関数の呼出元から、逆向き記号実行が行われる。
　逆向き記号実行の終了地点が解析終了点の先頭行に一致する場合、解析部１２０は修正箇所候補解析処理を終了する。
　ここで、図２の行１３が解析開始点であり、かつ、行１が解析終了点である場合の逆向き記号実行について説明する。
　解析部１２０は、パス条件として、０除算が発生する条件「ｂ＝０」を設定する。解析部１２０は、行１３から逆方向に探索を行う。この結果、行１３から行１１を実行パスとして記録する。このとき、パス条件は「ｂ＝０」のままである。
　解析部１２０は、行１１は解析終了点ではないため、関数ｆｏｏが、ローカル変数ｂが０で呼ばれたものと判定し、関数ｆｏｏを読み出すステートメント（関数）を特定する。この結果、解析部１２０は行８を特定する。行８に条件は「ａ－ｂ＝０」である。したがって、解析部１２０は、行１３から行１１、及び行８を実行パスとして記録し、パス条件を、関数ｆｏｏの「ｂ＝０」と関数ｂａｒの「ａ－ｂ＝０」とに更新する。
　解析部１２０は、行８から逆方向に探索を行う。この結果、解析部１２０は、実行パスを、行１３から行１１及び行８から行６に更新する。行６の条件は「ａ＝ｂ」であり、行８の条件「ａ－ｂ＝０」と等価の条件である。したがって、パス条件は更新されない。
　解析部１２０は、行６は解析終了点ではないため、関数ｂａｒが、ローカル変数ａ、ｂが同じ値で呼ばれたものと判定し、関数ｂａｒを読み出すステートメント（関数）を特定する。この結果、解析部１２０は行３を特定する。行３に条件は「ａ＝ｂ」である。したがって、解析部１２０は、行１３から行１１、行８から行６、及び行３を実行パスとして記録し、パス条件を、関数ｆｏｏの「ｂ＝０」と、関数ｂａｒの「ａ－ｂ＝０」と、関数ｂａｚの「ａ＝ｂ」とに更新する。
　解析部１２０は、行３から逆方向に探索を行う。この結果、解析部１２０は、実行パスを、行１３から行１１、行８から行６、及び行３から行１に更新する。行１の条件は「ａ＝ｂ」である。したがって、パス条件は更新されない。
　行１は解析終了点であるため、解析部１２０は、解析終了点のパス条件を解いて、入力値を記録する。例えば、ａ＝０、ｂ＝０が記録される。
　以上が修正箇所候補解析処理の説明である。図４の説明に戻る。
　次に、影響範囲探索部１２１は、修正箇所候補情報１３３を参照し、一つの修正箇所候補を選択する（ステップＳ１０２）。
　次に、影響範囲探索部１２１は、関数の呼出関係に基づいて、修正箇所候補の影響範囲を特定する（ステップＳ１０３）。影響範囲を示す情報はワークエリアに格納される。
　次に、改変履歴取得部１２２は、ソフトウェア構成管理情報１４０にアクセスすることによって、影響範囲に含まれる各関数に関する改変履歴を取得する（ステップＳ１０４）。
　なお、改変履歴を用いずにスコアを算出する場合、ステップＳ１０４の処理は省略できる。
　次に、スコア評価部１２３は、取得した改変履歴に基づいて、選択された修正箇所候補のスコアを算出する（ステップＳ１０５）。スコアはワークエリアに格納される。
　次に、スコア評価部１２３は、全ての修正箇所候補の処理が完了したか否かを判定する（ステップＳ１０６）。
　全ての修正箇所候補の処理が完了していない場合、スコア評価部１２３は、影響範囲探索部１２１を呼び出し、ステップＳ１０２に戻る。
　全ての修正箇所候補の処理が完了した場合、スコア評価部１２３は、修正箇所決定部１２４を呼び出す。修正箇所決定部１２４は、スコアに基づいて、修正箇所候補の中から改変する修正箇所を選択する（ステップＳ１０７）。例えば、スコアが最も小さい修正箇所候補を修正箇所に選択する方法が考えられる。
　次に、修正箇所決定部１２４は、選択した修正箇所に関する情報を処理結果として出力する（ステップＳ１０８）。その後、不具合解析装置１００は修正箇所決定処理を終了する。なお、修正箇所決定部１２４は、影響範囲に関する情報等も出力してもよい。
　なお、修正箇所候補の特定する処理（解析処理）と、修正箇所を選択する処理（選択処理）とを別々の計算機に実行させてもよい。この場合、選択処理を実行する計算機は、解析処理を実行する計算機から修正箇所候補情報１３３及びソースコード１３０の入力を受け付け、ステップＳ１０２からステップＳ１０８の処理を実行する。
　実施例１によれば、不具合解析装置１００は、複数の修正箇所候補を特定することができる。また、不具合解析装置１００は、影響範囲及び改変履歴に基づいて、各修正箇所候補に含まれる要素の改変の手間をスコアとして算出し、スコアに基づいて改変対象の修正箇所候補を決定できる。修正箇所候補に含まれる要素の改変に伴う他の関数（ステートメント）への影響、すなわち、改変の手間を評価するスコアを用いることによって、開発者の改変作業の負担の感覚に基づく修正箇所を選択できる。これによって、ソフトウェアのデバッグ作業の効率化及び精度の向上を実現することができる。
　実施例２では、ソースコード１３０を修正したユーザとソフトウェアの開発者との関係性に基づいてスコアが算出される。以下、実施例１との差異を中心に実施例２について説明する。
　図６は、実施例２の不具合解析装置１００の構成例を示す図である。
　実施例２の不具合解析装置１００のハードウェア構成は実施例１と同一である。実施例２の不具合解析装置１００の機能構成は実施例１と同一である。実施例２では、不具合解析装置１００が保持する情報が一部異なる。具体的には、実施例２の記憶装置１１１には、新たに、ユーザ／組織管理情報１３４及びコスト管理情報１３５が格納される。
　一般に、ソフトウェア開発は複数の組織が関わることは多い。例えば、ソフトウェアの開発プロジェクトの担当部署の他に、社外へ開発を委託するケース、異なる部署が過去に開発したソースコードを再利用するケース、オープンソースを導入するケース等、様々なケースがあり得る。
　不具合の修正の観点では、ソースコードの改変及び改変に伴う影響の評価には、組織を跨がった修正作業の依頼等のネゴシエーションが必要である。担当部署の内外、同一社内外、及び開発契約の有無等でソースコードの改変に関わる作業の手間は変わりうる。
　また、他組織が開発したソースコードを、担当部署が修正及び評価を行うことも考えられる。しかし、ソースコードの理解度及び管理面から、自部署での開発と比べ、作業負担が大きい。
　実施例２では、前述した観点を考慮して、開発者が所属する組織と、関数の責任組織との間の関係性を反映したコストが設定されたコスト管理情報１３５を用いて修正箇所候補のスコアが算出される。
　図７は、実施例２のユーザ／組織管理情報１３４の一例を示す図である。
　ユーザ／組織管理情報１３４は、ユーザの所属組織を管理するための情報である。ユーザ／組織管理情報１３４は、ユーザＩＤ７０１及び所属組織７０２から構成されるエントリを格納する。一人のユーザに対して一つのエントリが存在する。
　ユーザＩＤ７０１は、ユーザの識別情報を格納するフィールドである。ユーザＩＤ７０１には、ソフトウェア構成管理システム１０１に登録されたユーザの識別情報が格納される。
　所属組織７０２は、ユーザが所属する組織を示す値を格納するフィールドである。ここで、組織は、グループ、チーム、部門、及び会社を含む概念である。所属組織７０２には、ソフトウェアの開発者が所属する組織（開発プロジェクト）を基準にして設定された、相対的な組織を示す値が格納される。なお、所属組織７０２には、具体的な組織の名称等が格納されてもよい。
　なお、社外導入等により、社外の組織が、開発者が使用するソフトウェア構成管理システム１０１上で直接改変を行わない場合も想定される。この場合、仮想的なユーザを当該組織に割り当て、又はコメントを付与して管理することによって、ソフトウェア構成管理システム１０１上における責任組織を明らかにすることができる。
　図８は、実施例２のコスト管理情報１３５の一例を示す図である。
　コスト管理情報１３５は、開発者が所属する組織と、ある関数の改変を行ったユーザが所属する組織との間の関係性に基づいて設定されたコストを管理するための情報である。コスト管理情報１３５は、関係性８０１及びコスト８０２から構成されるエントリを格納する。一つの組織間の関係性に対して一つのエントリが存在する。
　関係性８０１は、開発者が所属する組織と、関数の改変を行ったユーザが所属する組織との間の関係性を示す値を格納するフィールドである。
　コスト８０２は、組織間の関係性に基づいて設定された、修正箇所候補に含まれる関数の改変に要する手間（例えば、ネゴシエーション）を表現したコストを格納するフィールドである。コスト８０２に設定されるコストは、無次元であり、絶対的な評価を表す数値ではなく、開発者の負担の感覚を表現した数値である。実施例２では、負担の大きさに対応した数値が設定される。
　実施例２の修正箇所決定処理の処理フローは実施例１と同一である。ただし、実施例２では、ソースコード１３０、仕様情報１３１、及び実行ログ１３２とともに、ユーザ／組織管理情報１３４及びコスト管理情報１３５も入力される。また、実施例２では、ステップＳ１０４及びステップＳ１０５の処理内容が一部異なる。
　ステップＳ１０４では、改変履歴取得部１２２は、改変したユーザの情報を含む改変履歴を取得する。
　ステップＳ１０５では、スコア評価部１２３は、改変履歴を用いて、影響範囲に含まれる各関数を改変したユーザを特定する。スコア評価部１２３は、ユーザ／組織管理情報１３４を参照して、特定されたユーザが所属する組織を特定する。スコア評価部１２３は、開発者が所属する組織と、改変を行ったユーザが所属する組織との間の関係性を特定し、コスト管理情報１３５を参照して、特定された組織間の関係性に対応するコストを取得する。スコア評価部１２３は、取得したコストの合計値をスコアとして算出する。
　なお、開発者が所属する組織と改変を行ったユーザが所属する組織とが同一である場合、ネゴシエーション等の手間はまとめられるという考え方から、スコア評価部１２３は、影響範囲に基づいて特定された組織の重複を排除した集合に対するスコアを算出してもよい。
　なお、同一関数の改変履歴が複数存在する場合、一つの関数に対して複数の組織が特定される可能性がある。この場合、スコア評価部１２３は、コストが最も小さい組織を当該関数の責任組織として選択する。
　実施例２では、修正箇所決定部１２４は、スコアが最も小さい修正箇所候補を修正箇所として選択する。
　ここで、図９を用いて実施例２のスコアの算出方法の具体例を説明する。図９は、実施例２の不具合解析装置１００によって特定された影響範囲の一例を示す。
　影響範囲探索部１２１は、関数ｆｕｎｃＡ（）を含む修正箇所候補が解析開始点として設定された場合、図９に示すような影響範囲９００を特定する。影響範囲９００には、関数ｆｕｎｃＢ（）、関数ｆｕｎｃＣ（）、及び関数ｆｕｎｃＤ（）が含まれる。矢印は関数の呼出関係を表す。
　スコア評価部１２３は、関数ｆｕｎｃＡ（）、関数ｆｕｎｃＢ（）、関数ｆｕｎｃＣ（）、及び関数ｆｕｎｃＤ（）の各々について、改変履歴に基づいて改変を行ったユーザを特定する。ここでは、説明の簡単のために、関数ｆｕｎｃＡ（）については「ｕｓｅｒ１」、関数ｆｕｎｃＢ（）については「ｕｓｅｒ１」、関数ｆｕｎｃＣ（）については「ｕｓｅｒ４」、関数ｆｕｎｃＤ（）については「ｕｓｅｒ５」が特定されたものとする。
　関数ｆｕｎｃＡ（）及び関数ｆｕｎｃＢ（）は、同一プロジェクトに所属する「ｕｓｅｒ１」によって改変されているため、それぞれのコストは「１」となる。関数ｆｕｎｃＣ（）は、同じ部に所属する「ｕｓｅｒ４」によって改変されているため、コストは「３」となる。関数ｆｕｎｃＤ（）は、同じ会社に所属する「ｕｓｅｒ５」によって改変されているため、コストは「５」となる。したがって、関数ｆｕｎｃＡ（）を含む修正箇所候補のスコアは「１０」となる。
　実施例２によれば、組織間のネゴシエーション等の手間を反映したスコアリングが可能となる。したがって、開発者の改変作業の負担の感覚に基づいて修正箇所を選択できる。
　実施例２では、開発者の所属組織と関数の責任組織との間の関係性に基づいてコストを設定した。実施例３では、影響範囲に含まれる関数の責任組織間の関係性に基づいてコストを設定する。以下、実施例１及び実施例２との差異を中心に実施例３について説明する。
　実施例３の不具合解析装置１００の構成は実施例２と同一である。実施例３では、コスト管理情報１３５の構造が実施例２と異なる。
　一般的に、不具合を修正する場合、呼出先の関数の改変内容を呼出元の関数の改変者が理解し、呼出元の関数への影響を評価する必要がある。このプロセスは、呼出元の関数及び呼出先の関数の各々を同一の組織が行えば、改変の手間が最も小さくなる。一方、コミュニケーションコストが大きくなる社外組織等と共同で開発を行う場合、規則に沿った仕様書の修正、及び変更点のレビュー等が必要となり、改変の手間が大きい。
　実施例３では、呼出元の関数及び呼出先の関数の組織間の関係性を反映したコストが設定されたコスト管理情報１３５を用いて修正箇所候補のスコアが算出される。なお、前述のような考え方はユーザ間の関係性についても同様に適用できる。
　図１０は、実施例３のコスト管理情報１３５の一例を示す図である。
　コスト管理情報１３５は、組織間の関係性に基づいて設定されたコストを管理するための情報である。コスト管理情報１３５は、関係性１００１及びコスト１００２から構成されるエントリを格納する。一つの組織間の関係性に対して一つのエントリが存在する。なお、組織間の関係性を、ユーザ間の関係性に変更してもよい。
　関係性１００１は、呼出関係のある関数を開発したユーザが所属する組織間の関係性を示す値を格納するフィールドである。
　コスト１００２は、呼出関係のある関数を開発したユーザが所属する組織間の関係性に基づいて設定された、修正箇所候補の改変に要する手間を表現したコストを格納するフィールドである。コスト１００２に設定されるコストは、無次元であり、絶対的な評価を表すものではなく、呼出元の関数及び呼出先の関数を改変した組織間の負担の感覚を表現した数値である。実施例３では、負担の大きさに対応した数値が設定される。
　なお、コスト管理情報１３５の一番目のエントリはユーザ間の関係性に基づいて設定されたコストが設定されている。
　実施例３の修正箇所決定処理の処理フローは実施例１と同一である。ただし、実施例３では、ソースコード１３０、仕様情報１３１、及び実行ログ１３２とともに、ユーザ／組織管理情報１３４及びコスト管理情報１３５も入力される。また、実施例３では、ステップＳ１０４及びステップＳ１０５の処理内容が一部異なる。
　ステップＳ１０４では、改変履歴取得部１２２は、改変したユーザの情報を含む改変履歴を取得する。
　ステップＳ１０５では、スコア評価部１２３は、改変履歴を用いて、影響範囲に含まれる各関数を改変したユーザを特定する。スコア評価部１２３は、ユーザ／組織管理情報１３４を参照して、特定されたユーザが所属する組織を特定する。スコア評価部１２３は、関数の呼出関係に基づいて、関数の呼出毎に、ユーザが所属する組織間の関係性を特定する。スコア評価部１２３は、コスト管理情報１３５を参照して、特定された組織間の関係性に対応するコストを取得する。スコア評価部１２３は、取得したコストの合計値をスコアとして算出する。
　なお、同一関数の改変履歴が複数存在する場合、一つの関数に対して複数の組織が特定される可能性がある。この場合、スコア評価部１２３は、コストが最も小さくなる組織を当該関数の責任組織として選択する。
　実施例３では、修正箇所決定部１２４は、スコアが最も小さい修正箇所候補を修正箇所として選択する。
　ここで、図９を用いて実施例３のスコアの算出方法の具体例を説明する。
　スコア評価部１２３は、関数ｆｕｎｃＡ（）、関数ｆｕｎｃＢ（）、関数ｆｕｎｃＣ（）、及び関数ｆｕｎｃＤ（）の各々について、改変履歴に基づいて改変を行ったユーザを特定する。ここでは、説明の簡単のために、関数ｆｕｎｃＡ（）については「ｕｓｅｒ１」、関数ｆｕｎｃＢ（）については「ｕｓｅｒ１」、関数ｆｕｎｃＣ（）については「ｕｓｅｒ４」、関数ｆｕｎｃＤ（）については「ｕｓｅｒ５」が特定されたものとする。
　関数ｆｕｎｃＡ（）及び関数ｆｕｎｃＢ（）の呼出関係における組織間の関係は、「同一ユーザ」であるため、コストは「１」となる。関数ｆｕｎｃＢ（）及び関数ｆｕｎｃＣ（）の呼出関係における組織間の関係は、「同一部内」であるため、コストは「５」となる。関数ｆｕｎｃＡ（）及び関数ｆｕｎｃＤ（）の呼出関係における組織間の関係は、「同一会社」であるため、コストは「１０」となる。したがって、関数ｆｕｎｃＡ（）を含む修正箇所候補のスコアは「１６」となる。
　実施例３によれば、組織間のネゴシエーション等の手間を反映したスコアリングが可能となる。したがって、開発者の改変作業の負担の感覚に基づいて修正箇所の選択が可能となる。
　なお、実施例２及び実施例３のスコアリングを並列に行い、実施例２のスコアリングによるスコアと実施例３のスコアリングによるスコアとの合計値を修正箇所候補のスコアとして算出してもよい。この場合、実施例２のコスト管理情報１３５及び実施例３のコスト管理情報１３５に設定するコストの基準をそろえておくことが前提となる。
　なお、実施例２のスコアリングによるスコア及び実施例３のスコアリングによるスコアのいずれかを重視する場合、各スコアに重みを乗算して算出される加重平均値を比較することもできる。
　実施例４では、ソースコード１３０の改変の同時性及び日時の関係に基づいてコストが修正される。以下、実施例１及び実施例３との差異を中心に実施例４を説明する。
　ソフトウェア開発では、密接に関連する関数をまとめて改変したソースコード１３０をソフトウェア構成管理システム１０１に登録するための操作（コミット）が行われる。改変の同時性は、コミットによって、同時に関数の改変内容が登録されたことを意味する。
　コミットによって同時に改変された関数は関連性が高いため、これらの関数の改変に要する手間は少ないと考えられる。一方、異なるタイミングで改変された関数は、関連性が低く、ネゴシエーション等の作業が必要となるため、関数の改変に要する手間は多いと考えられる。
　二つの関数の改変の日時の間隔が短い場合、関数の関連性は高いと推測される。そこで、日時についても上記と同様の考えを適用する。すなわち、改変の日時の間隔が短い場合、関数の改変に要する手間は少なく、改変の日時の間隔が長い場合、関数の改変に要する手間は多い。
　実施例４の不具合解析装置１００の構成は実施例１と同一である。
　実施例４の修正箇所決定処理の処理フローは実施例１と同一である。ただし、ステップＳ１０４及びステップＳ１０５の処理内容が一部異なる。
　ステップＳ１０４では、改変履歴取得部１２２は、改変したユーザの情報、改変の同時性、及び日時を含む改変履歴を取得する。
　ステップＳ１０５では、スコア評価部１２３は、改変履歴を用いて、影響範囲に含まれる各関数を改変したユーザを特定する。スコア評価部１２３は、ユーザ／組織管理情報１３４を参照して、特定されたユーザが所属する組織を特定する。スコア評価部１２３は、関数の呼出関係に基づいて、関数の呼出毎に、組織間の関係性を特定する。スコア評価部１２３は、コスト管理情報１３５を参照して、特定された組織間の関係性に対応するコストを取得する。スコア評価部１２３は、関数間の改変の同時性及び日時に基づいて、コストを補正する。例えば、改変の同時性がある関数の組合せの場合、コストに１を乗算し、改変の同時性がない関数の組合せの場合、コストに１．３を乗算する。また、改変日時の間隔が閾値より小さい場合、コストに１を乗算し、改変日時の間隔が閾値より大きい場合、１．２を乗算する。スコア評価部１２３は、修正されたコストの合計値をスコアとして算出する。
　実施例４によれば、改変の同時性及び改変の日時に基づいてコストを修正することによって、より精度の高いスコアリングが可能となる。
　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
　また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｊａｖａ等の広範囲のプログラム又はスクリプト言語で実装できる。
　さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ－ＲＷ、ＣＤ－Ｒ等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。
　上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。

Claims (10)

  1. 　プロセッサ、及び前記プロセッサに接続される記憶装置を備える計算機であって、
    　前記プロセッサは、
    　複数の要素から構成されるステートメントを複数含むソフトウェアのソースコードと、前記ソースコードの不具合を取り除くための改変対象の前記要素を含む前記ステートメントを修正箇所候補として管理する修正箇所候補情報とを入力として受け付け、
    　前記修正箇所候補を選択して、前記選択された修正箇所候補に含まれる前記要素の改変の手間を評価するスコアを算出するスコア算出処理を実行し、
    　前記複数の修正箇所候補の前記スコアに基づいて、改変を行う前記修正箇所候補を選択し、
    　前記スコア算出処理は、
    　前記ソースコードを解析することによって、前記選択された修正箇所候補に含まれる前記要素の改変によって影響を受ける、前記選択された修正箇所候補以外の前記ステートメントの前記要素と、前記選択された修正箇所候補に含まれる前記要素とを影響範囲として特定する第１処理と、
    　前記影響範囲に基づいて、前記選択された修正箇所候補の前記スコアを算出する第２処理と、を含むことを特徴とする計算機。
  2. 　請求項１に記載の計算機であって、
    　改変された前記ソースコードを格納するソフトウェア構成管理情報にアクセス可能であって、
    　前記第２処理は、
    　前記ソフトウェア構成管理情報から、前記影響範囲に含まれる前記複数の要素の各々に関する改変履歴を取得する第３処理と、
    　前記改変履歴を用いて前記スコアを算出する第４処理と、を含むことを特徴とする計算機。
  3. 　請求項２に記載の計算機であって、
    　ユーザが所属する組織を管理する組織管理情報と、前記ソフトウェアの開発者が所属する組織と改変を行ったユーザが所属する組織との間の関係性及びコストの対応付けを管理するコスト管理情報と、にアクセス可能であって、
    　前記改変履歴は、改変を行ったユーザの情報を含み、
    　前記第４処理は、
    　前記改変履歴に基づいて、前記影響範囲に含まれる前記複数の要素の各々について改変を行ったユーザを特定する処理と、
    　前記組織管理情報に基づいて、前記特定されたユーザが所属する組織を特定する処理と、
    　前記特定されたユーザが所属する組織と前記開発者が所属する組織との関係性に基づいて前記コスト管理情報を参照して、前記影響範囲に含まれる前記複数の要素の各々の前記コストを取得する処理と、
    　前記取得されたコストの合計値を前記スコアとして算出する処理と、を含むことを特徴とする計算機。
  4. 　請求項２に記載の計算機であって、
    　ユーザが所属する組織を管理する組織管理情報と、前記組織間の関係性及びコストの対応付けを管理するコスト管理情報と、にアクセス可能であって、
    　前記改変履歴は、改変を行ったユーザの情報を含み、
    　前記第４処理は、
    　前記改変履歴に基づいて、前記影響範囲に含まれる前記複数の要素の各々について改変を行ったユーザを特定する第５処理と、
    　前記組織管理情報に基づいて、前記特定されたユーザが所属する組織を特定する第６処理と、
    　前記影響範囲に含まれる前記要素であって、呼出関係がある前記要素間について、当該要素の改変を行った前記ユーザが所属する前記組織間の関係性を特定する第７処理と、
    　前記特定された組織間の関係性に基づいて前記コスト管理情報を参照して、前記影響範囲に含まれる要素であって、呼出関係がある要素間の前記コストを取得する第８処理と、
    　前記取得されたコストの合計値を前記スコアとして算出する第９処理と、を含むことを特徴とする計算機。
  5. 　請求項４に記載の計算機であって、
    　前記改変履歴は、改変操作に関する値及び改変日時を含み、
    　前記第８処理は、
    　前記改変履歴に基づいて、前記影響範囲に含まれる要素であって、呼出関係がある前記要素間について、前記改変操作の関係性及び前記改変日時の関係性を特定する処理と、
    　前記特定された改変操作の関係性及び前記特定された改変日時の関係性に基づいて、前記コストを補正する処理と、を含むことを特徴とする計算機。
  6. 　プロセッサ、及び前記プロセッサに接続される記憶装置を有する計算機が実行するソフトウェアの修正箇所の選択方法であって、
    　前記プロセッサが、複数の要素から構成されるステートメントを複数含むソフトウェアのソースコードと、前記ソースコードの不具合を取り除くための改変対象の前記要素を含む前記ステートメントを修正箇所候補として管理する修正箇所候補情報とを入力として受け付ける第１のステップと、
    　前記プロセッサが、前記修正箇所候補を選択して、前記選択された修正箇所候補に含まれる前記要素の改変の手間を評価するスコアを算出するする第２のステップと、
    　前記プロセッサが、前記複数の修正箇所候補の前記スコアに基づいて、改変を行う前記修正箇所候補を選択する第３のステップと、
    　を含み、
    　前記第２のステップは、
    　前記プロセッサが、前記ソースコードを解析することによって、前記選択された修正箇所候補に含まれる前記要素の改変によって影響を受ける、前記選択された修正箇所候補以外の前記ステートメントの前記要素と、前記選択された修正箇所候補に含まれる前記要素とを影響範囲として特定する第４のステップと、
    　前記プロセッサが、前記影響範囲に基づいて、前記選択された修正箇所候補の前記スコアを算出する第５のステップと、を含むことを特徴とするソフトウェアの修正箇所の選択方法。
  7. 　請求項６に記載のソフトウェアの修正箇所の選択方法であって、
    　前記計算機は、改変された前記ソースコードを格納するソフトウェア構成管理情報にアクセス可能であって、
    　前記第５のステップは、
    　前記プロセッサが、前記ソフトウェア構成管理情報から、前記影響範囲に含まれる前記複数の要素の各々に関する改変履歴を取得する第６のステップと、
    　前記プロセッサが、前記改変履歴を用いて前記スコアを算出する第７のステップと、を含むことを特徴とするソフトウェアの修正箇所の選択方法。
  8. 　請求項７に記載のソフトウェアの修正箇所の選択方法であって、
    　前記計算機は、ユーザが所属する組織を管理する組織管理情報と、前記ソフトウェアの開発者が所属する組織と改変を行ったユーザが所属する組織との間の関係性及びコストの対応付けを管理するコスト管理情報と、にアクセス可能であって、
    　前記改変履歴は、改変を行ったユーザの情報を含み、
    　前記第７のステップは、
    　前記プロセッサが、前記改変履歴に基づいて、前記影響範囲に含まれる前記複数の要素の各々について改変を行ったユーザを特定するステップと、
    　前記プロセッサが、前記組織管理情報に基づいて、前記特定されたユーザが所属する組織を特定するステップと、
    　前記プロセッサが、前記特定されたユーザが所属する組織と前記開発者が所属する組織との関係性に基づいて前記コスト管理情報を参照して、前記影響範囲に含まれる前記複数の要素の各々の前記コストを取得するステップと、
    　前記プロセッサが、前記取得されたコストの合計値を前記スコアとして算出するステップと、を含むことを特徴とするソフトウェアの修正箇所の選択方法。
  9. 　請求項７に記載のソフトウェアの修正箇所の選択方法であって、
    　前記計算機は、ユーザが所属する組織を管理する組織管理情報と、前記組織間の関係性及びコストの対応付けを管理するコスト管理情報と、にアクセス可能であって、
    　前記改変履歴は、改変を行ったユーザの情報を含み、
    　前記第７のステップは、
    　前記プロセッサが、前記改変履歴に基づいて、前記影響範囲に含まれる前記複数の要素の各々について改変を行ったユーザを特定する第８のステップと、
    　前記プロセッサが、前記組織管理情報に基づいて、前記特定されたユーザが所属する組織を特定する第９のステップと、
    　前記プロセッサが、前記影響範囲に含まれる前記要素であって、呼出関係がある前記要素間について、当該要素の改変を行った前記ユーザが所属する前記組織間の関係性を特定する第１０のステップと、
    　前記プロセッサが、前記特定された組織間の関係性に基づいて前記コスト管理情報を参照して、前記影響範囲に含まれる要素であって、呼出関係がある要素間の前記コストを取得する第１１のステップと、
    　前記プロセッサが、前記取得されたコストの合計値を前記スコアとして算出する第１２のステップと、を含むことを特徴とするソフトウェアの修正箇所の選択方法。
  10. 　請求項９に記載のソフトウェアの修正箇所の選択方法であって、
    　前記改変履歴は、改変操作に関する値及び改変日時を含み、
    　前記第１１のステップは、
    　前記プロセッサが、前記改変履歴に基づいて、前記影響範囲に含まれる要素であって、呼出関係がある前記要素間について、前記改変操作の関係性及び前記改変日時の関係性を特定するステップと、
    　前記プロセッサが、前記特定された改変操作の関係性及び前記特定された改変日時の関係性に基づいて、前記コストを補正するステップと、を含むことを特徴とするソフトウェアの修正箇所の選択方法。
PCT/JP2021/041504 2020-12-01 2021-11-11 計算機及びソフトウェアの修正箇所の選択方法 WO2022118627A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21900382.9A EP4231156A1 (en) 2020-12-01 2021-11-11 Calculator and method for selecting correction location of software
US18/036,817 US20240020217A1 (en) 2020-12-01 2021-11-11 Computer and Method for Selecting Correction Part of Software

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-199315 2020-12-01
JP2020199315A JP7423497B2 (ja) 2020-12-01 2020-12-01 計算機及びソフトウェアの修正箇所の選択方法

Publications (1)

Publication Number Publication Date
WO2022118627A1 true WO2022118627A1 (ja) 2022-06-09

Family

ID=81853118

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/041504 WO2022118627A1 (ja) 2020-12-01 2021-11-11 計算機及びソフトウェアの修正箇所の選択方法

Country Status (4)

Country Link
US (1) US20240020217A1 (ja)
EP (1) EP4231156A1 (ja)
JP (1) JP7423497B2 (ja)
WO (1) WO2022118627A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009104252A (ja) * 2007-10-19 2009-05-14 Toshiba Corp デバッグ支援装置およびデバッグ支援方法
JP2016071774A (ja) * 2014-10-01 2016-05-09 日本電気株式会社 検証支援装置、検証支援方法およびコンピュータプログラム
JP2020199315A (ja) 2020-09-15 2020-12-17 株式会社エース電研 遊技システム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8645761B2 (en) 2011-01-13 2014-02-04 International Business Machines Corporation Precise fault localization
US10133657B2 (en) 2016-02-23 2018-11-20 Fujitsu Limited Textual similarity based software program repair

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009104252A (ja) * 2007-10-19 2009-05-14 Toshiba Corp デバッグ支援装置およびデバッグ支援方法
JP2016071774A (ja) * 2014-10-01 2016-05-09 日本電気株式会社 検証支援装置、検証支援方法およびコンピュータプログラム
JP2020199315A (ja) 2020-09-15 2020-12-17 株式会社エース電研 遊技システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PETER DINGESGUL AGHA: "Targeted Test Input Generation Using Symbolic-Concrete Backward Execution", 29TH ACM/IEEE INTERNATIONAL CONFERENCE ON AUTOMATED SOFTWARE ENGINEERING, September 2014 (2014-09-01), pages 31 - 36, XP058696264, DOI: 10.1145/2642937.2642951

Also Published As

Publication number Publication date
EP4231156A1 (en) 2023-08-23
JP7423497B2 (ja) 2024-01-29
JP2022087400A (ja) 2022-06-13
US20240020217A1 (en) 2024-01-18

Similar Documents

Publication Publication Date Title
Reder et al. Computing repair trees for resolving inconsistencies in design models
Elberzhager et al. Reducing test effort: A systematic mapping study on existing approaches
JP5207007B2 (ja) モデル検証システム、モデル検証方法および記録媒体
US7707559B2 (en) Analysis of errors within computer code
US8397104B2 (en) Creation of test plans
JP6268029B2 (ja) テストケース生成装置及びテストケース生成方法
US8898649B2 (en) Application program analysis method, analysis system and recording medium for identifying a contributing factor for an invalid operation of an application program
Felderer et al. A multiple case study on risk-based testing in industry
US9582270B2 (en) Effective feature location in large legacy systems
US20090254538A1 (en) Methods, systems, and computer program products for social based assistance in a source code control system
Bierig et al. Essentials of Software Testing
CN103678116A (zh) 用于促进自动化程序测试的方法和系统
CN113051262B (zh) 一种数据质检方法、装置、设备及存储介质
Abdeen et al. An approach for performance requirements verification and test environments generation
Ostrand et al. A Tool for Mining Defect-Tracking Systems to Predict Fault-Prone Files.
WO2022118627A1 (ja) 計算機及びソフトウェアの修正箇所の選択方法
CN111966578A (zh) 一种安卓兼容性缺陷修复效果的自动化评估方法
JP2005332098A (ja) テスト項目抽出システム、テスト項目抽出装置、及びそれに用いるテスト項目抽出方法並びにそのプログラム
US11392371B2 (en) Identification of a partial code to be refactored within a source code
Breivold et al. Evaluating software evolvability
Pitchford Embedded software quality, integration, and testing techniques
US20080195453A1 (en) Organisational Representational System
Zhou et al. A framework for early robustness assessment.
Michelon et al. Analysis and Propagation of Feature Revisions in Preprocessor-based Software Product Lines
Reid Improving Developer Efficiency through Code Reuse

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21900382

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18036817

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2021900382

Country of ref document: EP

Effective date: 20230515

NENP Non-entry into the national phase

Ref country code: DE