JP5201068B2 - Risk determination program, risk determination device and method - Google Patents

Description

  The present invention relates to a risk determination program, a risk determination device, and a method. In particular, the present invention relates to technology for improving the efficiency of development work, reducing risk, and improving quality in software development.

  In software development, a technique for evaluating a place where a failure is likely to occur or a place where work is difficult is proposed. For example, Patent Document 1 proposes an apparatus that inspects whether or not a developed application correctly uses an API (Application Program Interface) by using information on how to use the API passed from the application. . Patent Document 2 proposes a system that supports the efficient design of test items for software system testing.

JP 2004-334541 A JP 2001-337846 A

  There are various causes of failure. Particularly problematic is the failure that occurs when various parts of the software are intricately intertwined and interact. In this failure, the location where the failure has occurred and the location that caused the failure are not always the same, and there are many cases where there are a plurality of causes. For example, a location where a fault occurs due to an API does not always appear only at a location where the API is used. Such a failure is hereinafter referred to as a software structural failure. If it is possible to predict a high-risk location where such a structural failure of software occurs, it is useful for improving the efficiency of development work, reducing risk, and improving quality. Patent Documents 1 and 2 also do not disclose a technique for predicting a location where a software structural failure occurs due to the use of an API.

  The present invention has been made in view of the above circumstances, and an object thereof is to provide a risk determination program, a risk determination device, and a method capable of predicting a location where a structural failure of software occurs.

  The risk determination program disclosed in the present specification analyzes a computer, and the influence of the execution of the program in the software and the data handled by the program affects other programs and other data in the software. The model construction means for obtaining the model to be performed based on the dependency relationship between the program and the data, and the use of the API used by the software by using the model, the location where the fault has occurred in the software in the past As an influence degree calculating means for obtaining the degree of influence to be affected, and using the degree of influence, an estimation means for estimating the probability that the use of the API has caused a distant cause of the failure and obtaining the degree of risk due to the use of the API. It is characterized by functioning.

  According to the risk determination program disclosed in this specification, it is possible to predict the location where a structural failure of the software occurs.

It is a figure which shows an example of a structure of a risk determination apparatus. It is a figure which shows an example of a structure of the functional block implement | achieved by the control part. It is a block diagram which shows an example of a structure of a source code analysis part. It is a figure which shows an example of a structure of a code entity and a data entity. It is a figure which shows an example of a structure of a relationship. It is a figure which shows an example of a source code. It is a figure which shows an example of the list | wrist of a code entity. It is a figure which shows an example of the list | wrist of a data entity. It is a figure which shows an example of the list | wrist of a relationship. It is a figure which shows an example of a structure of a software model construction part. It is a figure which shows an example of a software model. It is a figure which shows an example of a structure of a propagation matrix calculation part. It is a figure which shows an example of an influence spread model. It is a figure which shows an example of a structure of influence influence relationship. It is a figure which shows an example of an API list. It is a figure which shows an example of the failure log | history which generate | occur | produced. It is a figure which shows an example of a propagation matrix. It is a figure which shows an example of a structure of an API risk degree calculation part. It is a figure which shows an example of API risk. It is a flowchart which shows the process sequence of a control part. FIG. 10 is a diagram illustrating an outline of processing according to a third embodiment. It is a figure which shows an example of a structure of the danger determination apparatus of Example 3. FIG. It is a figure which shows an example of a man-hour correction table.

  Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings.

FIG. 1 shows a configuration of a risk determination apparatus 1 to which the present invention is applied.
The risk determination device 1 includes a control unit 2, a storage device 6, an operation unit 8, an input interface 7, a display unit 10, and a graphic interface 9. The control unit 2 includes a CPU (Central Processing Unit) 3, a ROM (Read Only Memory) 4, and a RAM (Read Only Memory) 5.

  First, the control unit 2 will be described. The ROM 4 stores a program used by the CPU 3 for control. The CPU 3 reads the program recorded in the ROM 4 and performs control according to the read program. In the RAM 5, data used by the CPU 3 for calculation and data of calculation results are recorded. The functional blocks of the control unit 2 realized by the cooperation of hardware such as the CPU 3 and the RAM 5 and the program stored in the ROM 4 will be described later.

  The storage device 6 stores data used by the control unit 2 for control. A database to be described later (hereinafter, the database may be abbreviated as DB) is constructed in the storage device 6 under the control of the control unit 2, and the data stored in the storage device 6 as a database under the control of the control unit 2 is stored. It can be taken out. The database includes a source code DB 15, an API list DB 16, a sample software failure history DB 17, an API risk DB 18, a data entity list DB 19, a code entity list DB 20, a relation list DB 21, a software model DB 22, an influence propagation model DB 23, and a propagation matrix DB 24. Etc. are included. Details of these databases will be described later.

  The operation unit 8 is a reception unit that receives a user operation input, and the input information received by the operation unit 8 is output to the control unit 2 via the input interface 7. For example, the user inputs settings of APIs used for software development using the operation unit 8.

  The determination result of the control unit 2 is displayed on the display unit 10 via the graphic interface 9. For example, calculation results of risk points, estimation of man-hours corrected based on the risk points, and the like are displayed (details thereof will be described later).

Next, functional blocks of the control unit 2 realized by cooperation of hardware such as the CPU 3 and RAM 4 and a program recorded in the ROM 4 will be described with reference to FIG.
The control unit 2 includes a source code analysis unit 11, a software model construction unit 12, a propagation matrix calculation unit 13, and an API risk level calculation unit 14 as executable function blocks.
The control unit 2 inputs a program from software created in the past (hereinafter referred to as sample software). The program includes not only a machine language translated program that is actually processed by a computer according to a processing instruction but also source code that is not translated into a machine language. Hereinafter, a case where source code is input as a program will be described as an example. In addition, the control unit 2 inputs a list of APIs used in each sample software (hereinafter referred to as API list) and a list of failures that have occurred in each sample software (hereinafter referred to as failure history). The control unit 2 inputs these pieces of information, and calculates the API risk level of each API by performing processing to be described later in each functional block shown in FIG. The calculated API risk level is stored in the API risk level DB 18.

Each functional block will be described.
The source code analysis unit 11 receives the source code of the sample software for calculating the API risk level, and extracts information such as control dependency information and data dependency information by static analysis or the like.

  The software model construction unit 12 constructs a model of sample software (hereinafter referred to as a software model) using the information extracted by the source code analysis unit 11.

  The propagation matrix calculation unit 13 inputs the software model constructed by the software model construction unit 12, the API list to be subjected to risk determination, and the failure history of the sample software. The propagation matrix calculation unit 13 constructs an influence propagation model based on the input information. Further, the propagation matrix calculation unit 13 calculates a propagation matrix that represents the relationship between the API and the failure occurrence location based on the constructed influence propagation model.

  The API risk level calculation unit 14 determines the API risk level from the propagation matrix and the failure history of the sample software.

  Next, details of the source code analysis unit 11 will be described with reference to FIG. And will be described in detail. FIG. 3 is a configuration diagram of the source code analysis unit 11. The source code analysis unit 11 includes a syntax analysis unit 111 and a model element extraction unit 112.

  The syntax analysis unit 111 receives the source code of the sample software from the outside and performs syntax analysis to obtain syntax analysis information. The syntax analysis unit 111 analyzes the source code and outputs syntax information. The syntax analysis unit 111 uses an existing technology used by a compiler or the like.

The model element extraction unit 112 receives the syntax analysis information output from the syntax analysis unit 111 and extracts a list of code entities, data entities, and “relationships”, which are each element constituting a software model described later.
A code entity corresponds to a certain part of source code. The granularity of the “part of the source code” can take various ranges such as a source file, a class, a method (or a function, a subroutine), or a block.
An API is a public interface provided by a library or framework for application software. In many cases, this is a method (or function, subroutine) call. An API is a code entity.
The data entity indicates data handled by software. Can take a diverse range of databases, files, fields or variables. Hereinafter, the code entity and the data entity are collectively referred to as an entity.

There may be some relationship between an entity and an entity. At this time, the “relationship” indicates what kind of relationship exists between which entity and which entity.
FIG. 4 shows an example of the structure of the code entity. It consists of two items: entity name and entity type. The entity name is information that can uniquely identify the range indicated by the code entity in the entire software. The entity type holds the type of this code entity.
Also, the structure of the data entity is as shown in FIG. 4 and consists of two items, an entity name and an entity type. The entity name is information that can uniquely identify the range indicated by the data entity in the entire software. The entity type holds the type of this data entity.

FIG. 5 shows an example of the “relation” structure. It consists of three items: the start entity name, the end entity name, and the relationship type. The start entity name and the end entity name are the entity names of two entities having a certain relationship. The relationship type holds the type of the relationship. When “A has a relationship of X to B”, the start entity name is A, the end entity name is B, and the relationship type is X. If the meaning changes when A and B are interchanged, the order of the start entity name and the end entity name is essentially important.
Further, when “C and D have a relationship of Y”, the start entity name is C, the end entity name is D, and the relationship type is Y. If the meaning does not change even if C and D are interchanged, the order of the start entity name and the end entity name is not essential and is interchangeable. Whether each type of exchange is commutative or not is determined automatically.

FIG. 6 is a part of source code of software. It should be noted that parts unnecessary for the description of the operation of this embodiment are omitted and simplified. In addition, a four-digit line number is attached to the beginning of the line for convenience of explanation.
The parsing unit 111 analyzes the source code shown in FIG. 6, cuts out lexical elements, discriminates syntactic meaning, and outputs analysis information to the model element extracting unit 112 as a discrimination result. The model element extraction unit 112 extracts items corresponding to the code entity and the data entity based on the analysis information. Further, the model element extraction unit 112 extracts a syntax structure corresponding to a predefined “relation” as “relation”. Here, it is assumed that three types of “relation” are defined: “call relationship”, “read relationship”, and “write relationship”. However, in addition to this, it is possible to increase the types of relationships beyond three types, such as “delegation relationships”.

FIG. 7 shows a list of code entities extracted from the source code of FIG. Similarly, FIG. 8 shows a data entity list, and FIG. 9 shows a “relation” list.
In FIG. 6, there are eight code entities A, B, C, D, E, F, API1, and API2, and one data entity Q. The line 0400 to line 0420 in FIG. 6 is the function C, and the function API1 is called in line 0410. Therefore, there is a “relationship” that the code entity C “calls” the code entity API1. Similarly, in line 0410, the variable Q is substituted. Therefore, there is a “relationship” that the code entity C “writes” to the data entity Q.

Next, the software model construction unit 12 will be described in detail. FIG. 10 is a configuration diagram of the software model construction unit 12.
The software model construction unit 12 inputs a list of code entities, data entities, and “relationships”, and constructs a software model. The software model construction unit 12 stores the constructed software model in the software model DB 22. FIG. 11 shows an example of the software model. The software model construction unit 12 constructs the software model shown in FIG. 11 with reference to the code entity list shown in FIG. 7, the data entity list shown in FIG. 8, and the “relationship” list shown in FIG. A software model is represented by a directed graph. The vertices of the graph are code entities or data entities, and the directed edges of the graph are relationships. The software model construction unit 12 constructs this software model from the input list and stores it in the software model DB 22.

Next, the propagation matrix calculation unit 13 will be described in detail. FIG. 12 shows the configuration of the propagation matrix calculation unit 13. The propagation matrix calculation unit 13 includes an influence propagation model construction unit 131 and a propagation matrix construction unit 132.
The influence spread model construction unit 131 inputs a software model from the software model construction unit 12 and constructs an influence spread model according to a procedure described later.
The propagation matrix construction unit 132 receives the constructed influence propagation model from the influence propagation model construction unit 131. Further, the spread matrix construction unit 132 inputs an API list and a list of failures (failure history) that occurred in the sample software from the outside. The propagation matrix construction unit 132 constructs and outputs a propagation matrix from the input information according to the procedure described later.

The process in which the influence spread model construction part 131 constructs an influence spread model is demonstrated.
FIG. 13 shows an example of the influence propagation model. This influence propagation model is constructed based on the software model of FIG. The influence propagation model takes a graph structure like the software model. The vertex is the same as the entity of the software model, and the entire entity included in the software model or a part thereof is included in the influence propagation model. Unlike the “relationship” of the software model, the directed side is called an influence spillover relationship and has a structure shown in FIG. In the influence propagation relationship, the start entity is the same as the start entity of the “relation”. Similarly, the end entity is the same as the “relation” end entity. The attenuation coefficient is a multiplier that indicates how much the influence spread attenuates in the influence spread from the start point entity to the end point entity. In FIG. 13, the attenuation coefficient is shown with the directed side. An influence propagation model corresponding to the whole or part of the “relationship” included in the software model (= same start entity and end entity) is included in the influence propagation model. However, in some cases, the influence spread relationship may be replaced with one in which the start point and the end point are inverted, or one in which the start point and the end point are inverted may be added.

Conversion rules are prepared in advance for “relationships” with software models.
For example, in the case of conversion from FIG. 11 to FIG. 13, the following rules 1, 2, and 3 are prepared, and the influence spread model construction unit 131 sets rules 1 and 2 for all “relationships” in FIG. 3 is applied to construct the influence propagation model of FIG. In the influence propagation model, since the code entity and the data entity are not distinguished, the two types are not distinguished in the example shown in FIG.

(Rule 1)
Rule 1 is when the entity type of the entity specified by the start entity name is “function”, the entity type of the entity specified by the end entity name is “function”, and the relationship type is “call” Applies to In this case, an influence spillover relationship is generated in which the start entity name has the end entity name, the end entity name has the start entity name (that is, the direction is inverted), and the attenuation coefficient is 0.5.
(Rule 2)
Rule 2 is that the entity type of the entity specified by the start entity name is “function”, the entity type of the entity specified by the end entity name is “variable”, and the relationship type is “lead” Applies to In this case, an influence spillover relationship is generated in which the start entity name has the end entity name, the end entity name has the start entity name (that is, the direction is inverted), and the attenuation coefficient is 0.1.
(Rule 3)
Rule 3 is that the entity type of the entity specified by the start entity name is “function”, the entity type of the entity specified by the end entity name is “variable”, and the relationship type is “light”. Applicable to the case. In this case, an influence spillover relationship is generated in which the start entity name has the start entity name, the end entity name has the end entity name (that is, the direction is unchanged), and the attenuation coefficient is 0.5.
In accordance with such rules, the influence propagation model construction unit 131 constructs an influence propagation model.

Next, processing in which the propagation matrix construction unit 132 constructs a propagation matrix will be described.
The API list input from the API list DB 16 is a list of entity names of code entities that are APIs. FIG. 15 shows an example of an API list. The software failure history is a list of entity names indicating locations where failures have occurred in the past. FIG. 16 shows an example of a software failure history.
FIG. 17 shows an example of a propagation matrix constructed corresponding to the influence propagation model shown in FIG. 13, the API list shown in FIG. 15, and the software fault history shown in FIG. The row of the propagation matrix means each API, and the column means each entity. The order of rows and the order of columns are arbitrary, and the order may be changed.

The propagation matrix construction unit 132 constructs a propagation matrix in the following procedure.
(1) For each API, the following steps (2), (3), and (4) are repeated starting from the API.
(2) For each entity, repeat the steps (3) and (4) with the entity as the target. (3) Perform a graph search on the influence propagation model from the API entity that is the starting point, and change from the starting point to the target entity. Find the shortest path. The distance for each directed edge when calculating the distance of the route can be variously determined. In this example, “logarithm of the reciprocal of the attenuation coefficient” is selected, but a constant 1 may be simply used.
(4) A value obtained by multiplying all the directed side attenuation coefficients along the determined shortest path is a value of a term that intersects the row of the starting API of the propagation matrix and the column of the target entity. When there is no route from the origin API to the target entity, the value of the corresponding term is set to 0. When the starting API and the target entity are the same, the value of the corresponding term is 1.

  For example, the value of the API1 row and D column term in FIG. 17 is 0.025. This is because the shortest path from API1 to D is API1 → C → Q → D in FIG. Multiply by the attenuation coefficient of the directed side to obtain 0.5 × 0.5 × 0.1 = 0.025. The value of this term is called the ripple coefficient. For example, when the row is API1 and the column is D, it is called a ripple coefficient from API1 to D. In this way, the propagation matrix construction unit 132 constructs a propagation matrix.

  In the description of the propagation matrix calculation unit 13 described above, an example in which the propagation matrix is calculated in two phases of the influence propagation model construction unit 131 and the propagation matrix construction unit 132 has been shown. However, the conversion rule described above is used. If this becomes complicated, the influence propagation model may be different for each API. In such a case, it is necessary to construct an influence propagation model for each API and calculate each value of the row of the propagation matrix. Therefore, the influence propagation model construction unit 131 and the propagation matrix construction unit 132 are not divided. It is good to build in one phase.

  Next, the API risk level calculation unit 14 will be described in detail. FIG. 18 shows the configuration of the API risk level calculation unit 14. The API risk level calculation unit 14 inputs the propagation matrix and the software fault history, and calculates the API risk level. The API risk level calculation unit 14 stores the calculated API risk level in the API risk level DB 18.

  The API risk level is a degree of ease of failure when using the API. The propagation matrix obtained previously indicates the magnitude of the influence spread caused by direct or indirect influence from each API to each entity. If the probability of occurrence of a failure when using a certain API is high, there is a high possibility that a failure will occur in an entity having a large influence spread from this API. However, since it is not possible to directly know the probability of failure when using the API, there is no other way than to estimate from the obtained information.

  Here, the maximum likelihood estimation method is used as the estimation method. The maximum likelihood estimation method is an estimation method based on the fact that “the observed event must be the event having the highest occurrence probability”. This probability of occurrence is called likelihood. Likelihood is also called a likelihood function because it has as a parameter a variable to be estimated (in this case, the likelihood of failure when an API is used). If a parameter that maximizes the likelihood function is found, that parameter becomes the “most likely” estimate. Details of the maximum likelihood estimation method are described in, for example, “Natural Science Statistics” edited by the Department of Statistics, Faculty of Liberal Arts, the University of Tokyo.

A specific procedure for estimation using the maximum likelihood estimation method will be described.
First, the symbols are defined as follows.
Let N be the number of APIs in the API list. The i-th API in the API list is APIi. Naturally, 1 ≦ i ≦ N. APIi corresponds to the i-th row of the propagation matrix.
Also, let M be the number of software entities. Let the jth entity be Xj. Naturally, 1 ≦ j ≦ M. Xj corresponds to the j-th column of the propagation matrix.
Further, the propagation coefficient from APIi to Xj is assumed to be Eij. Eij corresponds to each term of the propagation matrix.
Further, Fj represents whether or not a failure has occurred in the entity Xj. If Fj = 1, a failure has occurred. If Fj = 0, this means that no failure has occurred. This information is determined from the software failure history.
Also, let Ai be the degree of ease of failure when APIi is used. Ai is in the range of less than 1 and 0 or more. Let θ be a set of Ai, ie {A1, A2,... AN}. The purpose is to estimate this θ.
Here, it is assumed that the probability that a failure occurs in Xj due to the use of APIi can be expressed as Eij · Ai. When the probability that a failure does not occur in the entity Xj is written as Q (Xj), Q (Xj) becomes the following expression (1).

  Further, if the probability that a failure occurs in the entity Xj is written as P (Xj), P (Xj) is expressed by the following equation (2).

  If the probability (likelihood) that a failure (failure history) occurs in the input sample software is a function L (θ), the likelihood function L (θ) can be expressed by the following equation (3).

  In order to obtain θ that maximizes the expression (3), an appropriate numerical solution method such as the Nelder-Mead method may be used. For the Nelder-Mead method, see J.A.Nelder and R.Mead "A simplex method for function minimization" Computer Journal, vol.7, pp.308-313 (1965).

  An example in which a likelihood function is actually obtained from the example of the propagation matrix in FIG. 17 and the fault history of the software in FIG. The likelihood function L (θ) is expressed by the following equation (4), where θ1 is A1 and the degree of failure of API2 is A2, and the degree of failure of API2 is A2 and θ = {A1, A2}. It becomes as follows.

When θ that maximizes L (θ) is numerically solved using the Nelder-Mead method, A1 = 0.669 and A2 = 0.118 are obtained.
The API risk level calculation unit 14 outputs the obtained θ = {A1, A2,..., AN} as the API risk level. FIG. 19 shows an actual example of API risk level output according to the above-described example. The API risk value is meaningful as a relative value, but the meaning as an absolute value is not defined. That is, when A1 is larger than A1 when A1 is larger, A1 is more dangerous, but just because A1 is 0.3, the failure rate and its expected value are not always 0.3.

The processing procedure of the control unit 2 will be described with reference to the flowchart shown in FIG.
First, the control unit 2 inputs the source code of sample software for calculating the API risk, and analyzes the syntactic meaning of the source code by static analysis (step S1). Next, based on the analysis result, the control unit 2 extracts those corresponding to the code entity and data entity, and further extracts a syntax structure that satisfies a predefined relationship (step S2). The control unit 2 stores the extracted data entity in the data entity list DB 19, the code entity in the code entity list DB 20, and the syntax structure that satisfies the relationship in the relationship list DB 21.

  Next, the control unit 2 inputs a code entity, a data entity, and a list of relationships, and constructs a software model (step 3). An example of the software model constructed by the control unit 2 is shown in FIG. The control unit 2 stores the constructed software model in the software model DB 22. Further, the control unit 2 inputs a software model from the software model DB 22 and constructs an influence propagation model (step S4). An example of the influence propagation model constructed by the control unit 2 is shown in FIG. The control unit 2 stores the constructed influence propagation model in the influence propagation model DB 23.

Next, the control unit 2 inputs the API list and the list of failures (failure history) that occurred in the sample software, and constructs a propagation matrix (step S5). An example of the constructed propagation matrix is shown in FIG. The control unit 2 stores the constructed propagation matrix in the propagation matrix DB 24.
Next, the control unit 2 inputs the propagation matrix and the software failure history, and calculates the API risk (step S6). The control unit 2 stores the calculated API risk level in the API risk level DB 18.

  As described above, in this embodiment, a graph structure (software model) based on data dependency and source code control dependency is constructed, and the occurrence of a fault that has occurred in the past is received by using the API. The degree of influence is being sought. Based on the degree of this influence, the probability that the use of the API has become a cause of the failure occurrence is estimated. Therefore, it is possible to predict the occurrence of a structural failure of the software, not the surface problem that can be removed in the initial stage.

  In the first embodiment described above, the API risk level is obtained from the influence spread model using the maximum likelihood estimation method. In the present embodiment, a method of obtaining the API risk using another method will be described. In addition, since many processes are the same as Example 1, description of the same location is abbreviate | omitted.

  The present embodiment is different from the above-described first embodiment in the processing in the API risk level calculation unit 14. Therefore, the processing of the API risk level calculation unit 14 will be described in detail. In the present embodiment, the API risk level calculation unit 14 obtains the degree Ai of the probability of failure according to the following equation (5).

  In the first embodiment described above, Eij is a ripple coefficient from APIi to entity Xj, but this is used as a substitute for the degree of influence ripple from entity Xj to APIi. In other words, in this embodiment, the degree of influence that the fault occurrence location is affected by the use of the API is used as the degree of influence of the fault occurrence location on the API, and the degree of influence of all fault occurrence locations that have occurred in the past is added. Thus, the risk level of the API used by the software is calculated.

  When {A1, A2} is calculated from the propagation matrix shown in FIG. 17 and the example of the software failure history shown in FIG. 16, A1 = 0.775 and A2 = 0.500. The API risk level calculation unit 14 outputs {A1, A2,..., AN} thus obtained as the API risk level. The output format of the API risk level is the same as that of the first embodiment shown in FIG.

  The API risk value is meaningful as a relative value, but the meaning as an absolute value is not defined. That is, when A1 is larger than A1 when A1 is larger, A1 is more dangerous, but just because A1 is 0.3, the failure rate and its expected value are not always 0.3. In this embodiment, it is possible to obtain the same effects as those of the first embodiment described above, and it is possible to easily calculate the API risk level.

In the first embodiment and the second embodiment described above, the method of obtaining and outputting the API risk level has been described. In this embodiment, a method for applying the output API risk level to an actual software development project will be described.
The operation mode of the present embodiment is divided into a preparation stage and an operation stage as shown in FIG. In the preparation stage, the sample software and its failure history are input, and the risk level of each API is obtained and stored in the database. The specific contents have been described in the first and second embodiments.
In the operation stage, development projects that develop different software different from the sample software referenced in the preparation stage are targeted. In a software development project, the entire software is divided into several parts, and the work is divided into fine work accordingly. Here, the divided work is called a task. The amount of work required for a task varies with each task and rarely matches the amount of work originally estimated. If the task difficulty level is high, more man-hours than expected are required, and if the potential risk of the task is high, a process delay due to a trouble occurs. Therefore, it is necessary to have a technique for accurately estimating the amount of work required for the task or a technique for estimating with the highest possible accuracy. In the present embodiment, the work man-hour is estimated using the API risk.

  The configuration of this example is shown in FIG. This embodiment further includes a risk point calculation unit 25 and an estimate correction unit 26 as shown in FIG. The risk point calculation unit 25 acquires the API risk level from the API risk level DB 18 and calculates risk points for the entire software or task. The estimate correction unit 26 corrects the estimation of the work man-hour based on the risk points calculated by the risk point calculation unit 25.

  In a certain task Ti, the risk point calculation unit 25 calculates a risk point based on the API risk level when the design proceeds to a stage where an API to be used is determined. A set of APIs to be used is {API1, API2,..., APIM}. By referring to the API risk DB 18, the API risk of each API can be known. Let API be the API risk of APIj. The risk point Ri is obtained by the following equation (6).

  Function f and function g in equation (6) are set according to the development process. In a standard case without special intention, the following equation (7) (that is, identity transformation) is used. Another promising alternative candidate is Equation (8) shown below.

  The estimate correction unit 26 corrects the initial estimate based on the obtained risk points. As a result, the accuracy of man-hour estimation and risk determination is improved. FIG. 23 shows an example of a table for obtaining the man-hour estimation correction value from the risk point. This table is given to the project in advance, and may be stored in the storage device 6, for example.

There are various types of software, such as a web application and a built-in application for device control, and the nature of the software can vary depending on the type. Therefore, if a database of “API risk” is prepared separately for each type of software to be developed, the optimal database can be selected according to the type of software to be developed at the start of the project. It is possible to improve accuracy. Examples of the type of software to be developed include a web application and an embedded application for device control.
The above processing functions can be realized by a computer. In that case, a program describing the processing contents of the functions that the processing apparatus should have is provided. By executing the program on a computer, the above processing functions are realized on the computer. The program describing the processing contents can be recorded on a computer-readable recording medium.
When distributing the program, for example, portable recording media such as a DVD (Digital Versatile Disc) and a CD-ROM (Compact Disc Read Only Memory) on which the program is recorded are sold. It is also possible to store the program in a storage device of a server computer and transfer the program from the server computer to another computer via a network.
The computer that executes the program stores, for example, the program recorded on the portable recording medium or the program transferred from the server computer in its own storage device. Then, the computer reads the program from its own storage device and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program. Further, each time the program is transferred from the server computer, the computer can sequentially execute processing according to the received program.

  The embodiment described above is a preferred embodiment of the present invention. However, the present invention is not limited to this, and various modifications can be made without departing from the scope of the present invention.

DESCRIPTION OF SYMBOLS 1 Risk determination apparatus 2 Control part 11 Source code 12 Software model construction part 13 Spread matrix calculation part 14 API risk degree calculation part 15 Source code DB
16 API list DB
17 Sample software failure history DB
18 API risk DB
19 Data entity list DB
20 Code entity list DB
21 Relation list DB
22 Software Model DB
23 Influence propagation model DB
24 Ripple matrix DB
111 Syntax Analysis Unit 112 Model Element Extraction Unit 131 Influence Ripple Model Building Unit 132 Ripple Matrix Building Unit

Claims (7)

Computer
Analyzing the software, a model in which the execution of the program in the software and the influence of the data handled by the program spread to other programs and other data in the software is based on the dependency relationship between the program and the data. The model building means we want,
Using the model, an influence degree calculating means for obtaining a degree of influence of an occurrence location of a fault that has occurred in the software in the past by using an API used by the software;
A risk determination program that uses the degree of influence to estimate the probability that the use of the API has become a cause of failure, and functions as an estimation means that obtains the risk by using the API.   The risk determination program according to claim 1, wherein the model construction unit constructs the model with a graph structure based on a dependency relationship of data used in the software and a control dependency relationship of the program.   The risk estimation program according to claim 1 or 2, wherein the estimation means estimates a probability that the use of the API has become a distant cause of the occurrence of a failure using a maximum likelihood estimation method.   The estimation means uses the degree of influence that the failure occurrence location is affected by the use of the API as the degree of influence of the failure occurrence location on the API, and the influence degree of the failure occurrence location that occurred in the past in the software The risk determination program according to claim 1 or 2, wherein the risk level of the API used by the software is calculated by adding. The risk level of the API used in the software or a part of the software is calculated by using each means, and the risk level included in the software or a part of the software is calculated based on the calculated risk level of each API. Calculating means for
The risk determination program according to any one of claims 1 to 4, further comprising correction means for correcting a development man-hour of the software or a part of the software according to the risk calculated by the calculation means. Analyzing the software, a model in which the execution of the program in the software and the influence of the data handled by the program spread to other programs and other data in the software is based on the dependency relationship between the program and the data. The model building means we want,
Using the model, an influence degree calculating means for obtaining a degree of influence of an occurrence location of a fault that has occurred in the software in the past by using an API used by the software;
Estimating means that estimates the probability that the use of the API has caused a distant cause of the occurrence of failure using the degree of influence, and obtains the degree of risk due to the use of the API;
A risk determination device having A risk determination method executed by a risk determination device,
Analyzing the software, a model in which the execution of the program in the software and the influence of the data handled by the program spread to other programs and other data in the software is based on the dependency relationship between the program and the data. Seeking steps,
Using the model to determine the degree of influence of the location of the fault that has occurred in the software in the past by using the API used by the software;
Using the degree of influence to estimate the probability that the use of the API has become a distant cause of the occurrence of a failure, and determining as a risk due to the use of the API;
A risk determination method having

Images