ARCHITECTURE LIFE ESTIMATION APPARATUS AND ARCHITECTURE LIFE ESTIMATION METHOD

Abstract

The purpose of the present invention is to provide a technology which can suitably formulate the guidelines of a development project. This architecture lifetime estimation device comprises: an age calculation unit which calculates a diagnostic age of a source code on the basis of a software quality data value; a data accumulation unit which accumulates the diagnostic age for each revision of the source code; a development trend approximation equation calculation unit which calculates a development trend approximation equation on the basis of the diagnostic age accumulated for each revision in the data accumulation unit; and a lifetime estimation unit which estimates the lifetime of the source code on the basis of the development trend approximation equation.

Description

[Technical field]

[0001] The present disclosure relates to an architecture lifespan estimation device and an architecture lifespan estimation method. [Background technology]

[0002] In recent years, software has become larger and its structure more complex due to the reuse of existing software. In particular, as the number of revisions required for software maintenance and feature additions increases, the software structure becomes more complex, which can lead to a decline in the quality of the software, such as usability, maintainability, and portability, and in some cases, further revisions may not be possible.

[0003] Therefore, it is important to analyze the complicated software structure and simplify the software structure by considering the analysis results. In order to assist in simplifying the software structure, a software analysis technique has been proposed that visualizes the current software quality using a graph or the like. For example, Patent Document 1 proposes a technique that uses weight information based on the importance of the dependency type, which is the type of relationship between the software components, to calculate a weighted dependency strength for each dependency between the components of the software, and visualizes the dependency strength. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 5687122 Summary of the Invention [Problem to be solved by the invention]

[0005] The technology in Patent Document 1 calculates software quality such as dependency strength at a single point in time, i.e., when the source code is input, but does not reflect the degree of improvement or deterioration of software quality over a long-term development period. This causes a problem in that source code developers cannot know to what extent their software assets can be used, making it difficult to appropriately formulate guidelines for development projects.

[0006] Therefore, the present disclosure has been made in consideration of the above-mentioned problems, and aims to provide a technique that enables appropriate formulation of guidelines for a development project. [Means for solving the problem]

[0007] The architecture lifespan estimation device according to the present disclosure includes an acquisition unit for acquiring a source code, a software quality measurement unit for measuring a software quality data value indicating the quality of the source code based on the source code, an age calculation unit for calculating the software structural complexity of the source code as the diagnostic age of the source code based on the software quality data value, a data storage unit for storing the diagnostic age for each revision of the source code, a development trend approximation equation calculation unit for calculating a development trend approximation equation indicating a relationship between the revision and the diagnostic age based on the diagnostic age stored in the data storage unit for each revision, and a lifespan estimation unit for estimating a lifespan related to the revision of the source code based on the development trend approximation equation, and outputs information based on the lifespan. Objects, features, aspects, and advantages of the present disclosure will become more apparent from the following detailed description and the accompanying drawings. Effect of the Invention

[0008] According to the present disclosure, a development tendency approximation formula is calculated based on the diagnosis age accumulated in the data accumulation unit for each revision, and the lifespan of the source code is estimated based on the development tendency approximation formula. With this configuration, the lifespan is estimated for a period of time rather than a single point in time, so that guidelines for the development project can be appropriately formulated. [Brief description of the drawings]

[0009] [Figure 1] 1 is a block diagram showing a configuration of an architecture lifetime estimation device according to a first embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of metrics according to the first embodiment. [Diagram 3] FIG. 4 is a diagram showing an example of diagnosed age according to the first embodiment. [Figure 4] FIG. 11 is a diagram showing an example of software quality data values ​​according to the first embodiment. [Diagram 5] FIG. 4 is a diagram showing an example of diagnosed age according to the first embodiment. [Figure 6] FIG. 4 is a diagram showing an example of software quality data values ​​according to the first embodiment. [Figure 7] FIG. 4 is a diagram showing an example of diagnosed age according to the first embodiment. [Figure 8] FIG. 11 is a block diagram showing a configuration of an architecture lifetime estimation device according to a second embodiment. [Figure 9] FIG. 11 is a diagram illustrating an example of metrics according to the second embodiment. [Figure 10] FIG. 11 is a diagram showing an example of diagnosed age according to the second embodiment. [Figure 11] FIG. 11 is a diagram showing an example of software quality data values ​​according to the second embodiment. [Figure 12] FIG. 11 is a diagram showing an example of diagnosed age according to the second embodiment. [Figure 13] FIG. 11 is a block diagram showing a configuration of an architecture lifetime estimation device according to a third embodiment. [Figure 14] FIG. 13 is a diagram illustrating an example of metrics according to the third embodiment. [Figure 15] FIG. 11 is a diagram showing an example of diagnosed age according to the third embodiment. [Figure 16] FIG. 11 is a diagram showing an example of dependency between functional units according to the third embodiment. [Figure 17] FIG. 13 is a diagram showing an example of software quality data values ​​according to the third embodiment. [Figure 18] FIG. 11 is a diagram showing an example of diagnosed age according to the third embodiment. [Figure 19] FIG. 13 is a block diagram showing a configuration of an architecture lifetime estimation device according to a fourth embodiment. [Figure 20] FIG. 13 is a diagram showing an example of metrics according to the fourth embodiment. [Figure 21] FIG. 13 is a diagram showing an example of diagnosed age according to the fourth embodiment. [Figure 22] FIG. 13 is a diagram showing an example of the skill level of a worker according to the fourth embodiment. [Diagram 23] FIG. 13 is a diagram showing an example of development prospect information relating to embodiment 4. [Figure 24] FIG. 13 is a diagram showing an example of work information according to the fourth embodiment. [Diagram 25] FIG. 13 is a diagram showing an example of software quality data values ​​according to the fourth embodiment. [Figure 26] FIG. 13 is a diagram showing an example of diagnosed age according to the fourth embodiment. [Figure 27] FIG. 13 is a diagram showing an example of a correspondence relationship table between development prospects and age thresholds in the fourth embodiment. [Figure 28] FIG. 13 is a diagram showing an example of a correspondence relationship table between skill values ​​and skill levels according to the fourth embodiment. [Figure 29] FIG. 13 is a diagram showing an example of a correspondence relationship table between skill levels and skill level coefficients according to the fourth embodiment. [Diagram 30] FIG. 13 is a block diagram showing a configuration of an architecture lifetime estimation device according to a fifth embodiment. [Diagram 31] FIG. 13 is a diagram showing an example of metrics according to the fifth embodiment. [Diagram 32] FIG. 13 is a diagram showing an example of software quality data values ​​according to the fifth embodiment. [Diagram 33] FIG. 13 is a diagram showing an example of software quality data values ​​according to the fifth embodiment. [Diagram 34] FIG. 13 is a diagram showing an example of diagnosed age according to the fifth embodiment. [Diagram 35] FIG. 13 is a block diagram showing a hardware configuration of an architecture life estimation device according to another modified example. [Diagram 36]FIG. 13 is a block diagram showing a hardware configuration of an architecture life estimation device according to another modified example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] <Embodiment 1> FIG. 1 is a block diagram showing the configuration of an architecture life estimation device 101 according to the first embodiment. A case will be described below in which software reuse development is performed in which source code of revision-1 is reused to generate source code of revision-2, and in which source code of revision-2 is reused to generate source code of revision-3. Note that a revision is a revision of source code for repairing software for maintenance or adding functions, and the greater the number of revisions, the greater the number. A case will be described below in which architecture life estimation device 101 estimates architecture life from source code of revision-1, revision-2, and revision-3.

[0011] 2 is a diagram showing an example of metrics for each revision. Metrics are numerical values ​​for quantitatively evaluating software quality, such as the number of lines, the number of functions, cyclomatic complexity, and the number of dependencies.

[0012] 3 is a diagram showing an example of the diagnosed age for revision-1 calculated by age diagnosis unit 4 and stored in data storage unit 203. The calculation of the diagnosed age for revision-2 will be explained later, but the calculation of the diagnosed age for revision-1 and revision-3 is similar to the calculation of the diagnosed age for revision-2.

[0013] Here, "diagnosis age" is a value between 0 and infinity. A low diagnosis age, that is, a low numerical value, indicates that the software structure is less complex and the software quality is good, while a high diagnosis age, that is, a high numerical value, indicates that the software structure is more complex and the software quality is poor. The "lifespan" described below is the number of times that the source code can be revised, estimated based on the accumulated changes in diagnosis age.

[0014] The architecture lifespan estimation device 101 is a device such as a computer that performs software quality analysis and development trend analysis. The architecture lifespan estimation device 101 estimates a numerically quantified lifespan (also called architecture lifespan) that can be used for software quality analysis and development trend analysis, and for formulating guidelines for development projects.

[0015] 1 includes a software quality measurement unit 2, an age diagnosis unit 4 which is an age calculation unit, a development trend approximation formula calculation unit 6, a lifespan estimation unit 8, an input unit 201 which is an acquisition unit, a storage unit 202, a data accumulation unit 203, and an output unit 204. The storage unit 202 is, for example, a memory, and stores a source code 1, a software quality data value 3, an assessment age 5, a development trend approximation formula 7, and a lifespan 9.

[0016] An input unit 201 receives and acquires source code 1 from an external device or the like, and a storage unit 202 stores the acquired source code 1. A source code is a string of characters that is the basis of software (S / W) such as a computer program, and specifies a series of instructions for a computer.

[0017] The software quality measurement unit 2 extracts metrics such as the total number of lines, the total number of functions, and the total number of files as shown in Fig. 2 from the source code 1. Note that the metrics are not limited to those shown in Fig. 2, and may include, for example, the number of variables, the number of dependencies, module strength, module coupling degree, and cyclomatic complexity.

[0018] The software quality measurement unit 2 measures a software quality data value 3 indicating the quality of the source code based on the extracted metrics. The software quality data value is a value that serves as an index of an element of the software quality data. For example, the software quality measurement unit 2 calculates the software quality data value using formulas (1) to (4).

[0019]

number

[0020]

number

[0021]

number

[0022]

number

[0023] In formulas (1) to (4), the reference values ​​for the number of lines per function and the number of lines per file are set to values ​​that are considered to require refactoring, such as 100 lines and 2000 lines, respectively. Formulas (1) to (4) are specified so that the software quality data value is 0 at the highest quality and diverges to infinity at the lowest quality.

[0024] The software quality data value calculation formula is not limited to formulas (1) to (4). For example, an index related to the number of functions per file or an index related to cyclomatic complexity may be used as the software quality data value.

[0025] FIG. 4 is a diagram showing an example of software quality data values, specifically, software quality data values ​​of revision-2. FIG. 4 shows software quality data values ​​measured for each software quality data element. FIG. 4 also shows coefficients defined for each software quality data element. The software quality data values ​​and coefficients are used when the age diagnosis unit 4, which will be described next, calculates the diagnosis age of the source code.

[0026] The coefficients are used to appropriately weight the software quality data values ​​based on the degree of influence the software quality data values ​​have on the diagnostic age, and to adjust the number of digits of the software quality data values. In the example of Fig. 4, the coefficients of each software quality data are set to sum to 100. For the sake of convenience, the coefficients of all four software quality data values ​​are set to 25, which is an equal distribution of the total value of 100, assuming that the four software quality data values ​​have the same influence on the software quality.

[0027] The age diagnosis unit 4 calculates the complexity of the software structure of the source code as the diagnosis age 5 of the source code based on the software quality data value 3 measured by the software quality measurement unit 2. For example, the age diagnosis unit 4 calculates the diagnosis age of the source code using equation (5).

[0028]

number

[0029] 4, the age diagnosis unit 4 calculates 58.06 (≈25×(1.00+0.10+1.00+0.22)) as the diagnosed age of revision −2. The age diagnosis unit 4 stores the calculated diagnosed age in the data accumulation unit 203.

[0030] Since the diagnostic age of revision-1 in Fig. 3 has already been stored in data storage unit 203, by storing the diagnostic age of revision-2, the diagnostic ages of revision-1 and revision-2 are stored in data storage unit 203 as shown in Fig. 5. In this way, data storage unit 203 stores a diagnostic age 5 for each revision of the source code.

[0031] The development tendency approximation formula calculation unit 6 calculates a development tendency approximation formula 7 indicating the relationship between the revision and the diagnosis age based on the diagnosis age 5 accumulated for each revision in the data accumulation unit 203. For example, the development tendency approximation formula calculation unit 6 calculates y=29.03x-3.26 as the development tendency approximation formula 7 by performing linear approximation such as the least squares method on the coordinate points (0,0), (1,19.26), and (2,58.06) with the revision as the x-axis and the diagnosis age as the y-axis.

[0032] The lifespan estimation unit 8 estimates the lifespan 9 for the revision of the source code based on the development tendency approximation formula 7. For example, the lifespan estimation unit 8 calculates the revision when the diagnosed age of the development tendency approximation formula 7 becomes equal to the age threshold, which is a predetermined threshold for the diagnosed age, and calculates the lifespan by subtracting the current revision from the calculated revision. In the above example, the lifespan estimation unit 8 calculates 3.56 as the revision at which y=100 occurs in y=29.03x-3.26, and calculates 1.56 by subtracting the current revision 2 from the calculated revision 3.56 as the lifespan. In the following description, the value calculated in this way is used as the lifespan, but is not limited to this. For example, the revision when the diagnosed age of the development tendency approximation formula 7 becomes equal to the age threshold may be used as the lifespan as it is.

[0033] The output unit 204 outputs information based on the lifespan 9 estimated by the lifespan estimation unit 8 to an external device, an operator, etc. For example, the output unit 204 may output the source code 1, the software quality data value 3, the development trend approximation formula 7, and the lifespan 9, as well as the diagnosed age 5 stored in the data storage unit 203.

[0034] Just as the output unit 204 outputs various information, the data storage unit 203 may store various information. For example, the data storage unit 203 may store a source code 1, a software quality data value 3, a diagnosis age 5, a development trend approximation formula 7, and a life span 9.

[0035] The above operations are performed in the same way when revision 3 source code is generated by reusing revision 2 source code. This case will be described below.

[0036] The software quality measurement unit 2 measures a software quality data value 3 indicating the quality of the source code based on the extracted metrics. Fig. 6 is a diagram showing an example of the software quality data value, specifically, the software quality data value of revision-3.

[0037] The age diagnosis unit 4 calculates a diagnosis age 5 based on the software quality data value 3 measured by the software quality measurement unit 2. In the case of the software quality data value of Fig. 6, the age diagnosis unit 4 calculates 34.40 (≈25 × (0.58 + 0.08 + 0.56 + 0.17)) as the diagnosis age of revision -3.

[0038] The age diagnostic unit 4 stores the calculated diagnostic age 5 in the data storage unit 203, and the data storage unit 203 stores the diagnostic age 5 for each revision of the source code as shown in FIG.

[0039] The development tendency approximation formula calculation unit 6 calculates the development tendency approximation formula 7 based on the diagnosis age 5 stored for each revision in the data storage unit 203. For example, the development tendency approximation formula calculation unit 6 calculates y=14.20x+6.63 as the development tendency approximation formula by performing linear approximation such as the least squares method on the coordinate points (0,0), (1,19.26), (2,58.06), and (3,34.40).

[0040] The lifespan estimation unit 8 estimates the lifespan 9 for the revision of the source code based on the development trend approximation formula 7. For example, the lifespan estimation unit 8 calculates 6.58 as the revision at which y=100 in y=14.20x+6.63 occurs, and calculates 3.58 as the lifespan by subtracting the current revision, 3, from the calculated revision, 6.58.

[0041] The lifespan of revision-3, 3.58, is greater than the lifespan of revision-2, 1.56, which indicates that revision-3 has an improved source code architecture.

[0042] <Summary of the first embodiment> According to the first embodiment described above, the diagnostic age of the revision at the time of inputting the source code is calculated, so that the quality of the architecture for the current source code can be quantified. In addition, the lifespan of the architecture for the source code is estimated based on the diagnostic age accumulated for each revision, so that it is possible to quantify how long the architecture can be used for reuse development and function addition development in the future, not for a single point in time but for a period of time. This makes it easier to formulate guidelines for development projects.

[0043] <Embodiment 2> 8 is a block diagram showing a configuration of an architecture lifetime estimation device 101 according to the present embodiment 2. In the following, among the components according to the present embodiment 2, components that are the same as or similar to the components described above are given the same or similar reference symbols, and different components will be mainly described.

[0044] In the following, a case will be described in which the diagnostic age of revision-1 is stored in data storage unit 203 as in embodiment 1, and architecture life estimation device 101 performs architecture life estimation from the source code of revision-1 to revision-2.

[0045] In the first embodiment, the lifespan of the entire software, that is, the lifespan of the entire source code, is estimated. In contrast to this, in the second embodiment, the source code is divided into predetermined units, and the lifespan is estimated for each division. In the following, the predetermined units are described as software functional units, but are not limited to this, and may be, for example, units that require modification.

[0046] Fig. 9 is a diagram showing an example of metrics for each revision. Fig. 10 is a diagram showing an example of the diagnostic age of revision-1 calculated by the age diagnostic unit 4 and accumulated in the data accumulation unit 203. As shown in Figs. 9 and 10, the source code is divided into functional units of function A, function B, and function C. The functional units may be set based on the folder configuration, or the functional configuration definition file that defines the functional configuration may be received by the input unit 201, stored in the storage unit 202, and referred to by the software quality measurement unit 2 to set the functional units.

[0047] An architecture lifespan estimation device 101 in Fig. 8 has the same configuration as that in Fig. 1, with a main unit lifespan extraction unit 10 added to the configuration in Fig. 1. A storage unit 202 stores a main unit lifespan 11 in addition to the contents stored in Fig. 1.

[0048] The software quality measurement unit 2 extracts metrics for each function unit, such as the total number of lines, the total number of functions, and the total number of files, as shown in Fig. 9, from the source code 1. The software quality measurement unit 2 measures a software quality data value 3 for each function unit based on the metrics extracted for each function unit.

[0049] Fig. 11 is a diagram showing an example of software quality data values, specifically, software quality data values ​​of revision 2. Fig. 11 shows software quality data values ​​measured for each functional unit.

[0050] The age diagnosis unit 4 calculates a diagnosis age 5 for each functional unit based on the software quality data value 3 measured for each functional unit. The age diagnosis unit 4 stores the diagnosis age 5 calculated for each functional unit in the data accumulation unit 203, and the data accumulation unit 203 accumulates the diagnosis age 5 for each source code revision and each functional unit as shown in FIG.

[0051] The development trend approximation formula calculation unit 6 calculates the development trend approximation formula 7 for each function unit based on the diagnosis age 5 accumulated for each revision and for each function unit in the data accumulation unit 203. For example, the development trend approximation formula calculation unit 6 calculates y=10.02x+16.37 as the development trend approximation formula for function A by performing linear approximation such as the least squares method on the diagnosis age of function A. Similarly, the development trend approximation formula calculation unit 6 calculates y=47.76x+9.52 as the development trend approximation formula 7 for function B, and y=38.16x+12.72 as the development trend approximation formula for function C.

[0052] The lifespan estimation unit 8 estimates the lifespan 9 of the source code for each functional unit based on the development trend approximation formula 7 calculated for each functional unit. In the above example, the lifespan estimation unit 8 calculates 6.35 as the lifespan of function A, -0.11 as the lifespan of function B, and 0.29 as the lifespan of function C.

[0053] The main unit life extraction unit 10 extracts a main unit life 11, which is the life 9 of one functional unit, based on the influence of the life 9 estimated for each functional unit by the life estimation unit 8 on the life 9 of the entire source code 1. For example, the main unit life extraction unit 10 extracts, from the lifespans of each functional unit, the life of one functional unit that has the greatest influence on the lifespan of the entire source code estimated in embodiment 1 as the main unit life. As an example of this, first, the main unit life extraction unit 10 uses equation (6) to calculate a unit life scale indicating the influence on the lifespan of the entire source code.

[0054]

number

[0055] Here, the unit lifespan is the lifespan of each functional unit estimated in the second embodiment, the total lifespan is the lifespan of the entire source code estimated in the first embodiment, the unit line count is the total number of lines of each functional unit in Figure 9, and the total number of lines is the sum of the total number of lines of each functional unit.

[0056] When the overall lifespan calculated in the same manner as in the first embodiment is 4.15, the unit life scales of function A, function B, and function C are calculated to be 1.65, 0.39, and 0.32, respectively.

[0057] The main unit life extraction unit 10 extracts the life of the functional unit with the largest unit life scale among the unit life scales calculated for each functional unit as the main unit life. For example, if the unit life scales of function A, function B, and function C are 1.65, 0.39, and 0.32, respectively, the main unit life extraction unit 10 extracts 6.35, which is the life of function A with the largest unit life scale, as the main unit life.

[0058] In the second embodiment, the output unit 204 outputs information based on the lifespan 9 estimated for each functional unit by the lifespan estimation unit 8 to an external device or the like. For example, the output unit 204 may output the unit name (function B in the above example) which is the name of the functional unit with the worst lifespan among the lifespans of the functional units, its lifespan (-0.11 in the above example), and the software quality data value 3 of the functional unit which is the cause of the worsened lifespan. For example, the output unit 204 may output the source code 1, diagnosis age 5, and development tendency approximation formula 7 of the functional unit with the worst lifespan (function B in the above example) in addition to those. Also, for example, when the input unit 201 receives the number of units with a bad lifespan, the output unit 204 may output the number of units with a bad lifespan. direction The life span of the functional units may be output in that order, for example, by the number of functional units.

[0059] In the second embodiment, the output unit 204 outputs information based on the main unit life extracted by the main unit life extraction unit 10 to an external device or the like. For example, the output unit 204 may output the main unit life 11 (the life of function A in the above example). Also, for example, the output unit 204 may output the source code 1, the software quality data value 3, the development tendency approximation formula 7, and the life 9, as well as the diagnosis age 5 stored in the data storage unit 203, for the functional unit from which the main unit life 11 was extracted (function A in the above example).

[0060] Just as the output unit 204 outputs various information, the data storage unit 203 may store various information. For example, the data storage unit 203 may store source code 1, software quality data value 3, diagnosis age 5, development trend approximation formula 7, life span 9, and main unit life span 11.

[0061] <Summary of the second embodiment> According to the second embodiment described above, the life span is estimated for each function, so it is possible to quantify for each function how long the architecture can be used through reuse development and function addition development in the future. This makes it easier to formulate guidelines for development projects.

[0062] According to the second embodiment, information based on the lifespan estimated for each functional unit is output. With this configuration, for example, it is possible to give a notice that enables a functional unit with a relatively short lifespan to be recognized, which makes it easier to formulate guidelines for a development project.

[0063] According to the second embodiment, the main unit lifespan, which is the lifespan of one functional unit, is extracted based on the effect on the lifespan of the entire source code, and information based on the main unit lifespan is output. With this configuration, for example, it is possible to give a recognizable notification of functional units that must not impair software quality, which makes it easier to formulate guidelines for a development project.

[0064] <Embodiment 3> 13 is a block diagram showing a configuration of an architecture lifetime estimation device 101 according to the present embodiment 3. In the following, among the components according to the present embodiment 3, components that are the same as or similar to the components described above are given the same or similar reference symbols, and different components will be mainly described.

[0065] In the following, a case will be described in which the diagnostic age of revision-1 is stored in data storage unit 203 as in embodiment 1, and architecture life estimation device 101 performs architecture life estimation from the source code of revision-1 to revision-2.

[0066] In the third embodiment, the lifespan estimated for each functional unit of software is corrected by taking into consideration the quality of the lifespan of closely related functional units. Also, by additionally inputting design information such as an architecture design document or an architecture modularization design document, the difference between the design and implementation of the software in the source code is reflected in the lifespan. Also, by additionally inputting defect information such as errors or warnings in the source code, the defect information is reflected in the lifespan.

[0067] Fig. 14 is a diagram showing an example of metrics for each revision. As shown in Fig. 14, the metrics according to the third embodiment further include the number of dependencies, the number of dependencies on other functions, and the number of defects. Fig. 15 is a diagram showing an example of the diagnosed age of revision-1 calculated by the age diagnosis unit 4 and accumulated in the data accumulation unit 203.

[0068] An architecture life estimation device 101 in Fig. 13 has the same configuration as that in Fig. 1, except that a life correction unit 15 and a life validity calculation unit 16 are added to the configuration in Fig. 1. A storage unit 202 stores design information 13, defect information 14, and life validity 17 in addition to the contents stored in Fig. 1.

[0069] The input unit 201 receives and acquires the source code 1, the design information 13, and the defect information 14 from an external device or the like, and the storage unit 202 stores the acquired source code 1, the design information 13, and the defect information 14.

[0070] The design information is information indicating an architecture designed in advance for source code, and includes dependencies between functional units, for example, as shown in Fig. 16. A program depending on another program means that another program is required to build or run the program. The example in Fig. 16 indicates that function B depends on function A, and function C depends on functions A and B. Note that the design information may include dependencies within functional units as well as dependencies between functional units.

[0071] The defect information includes the number of defects, which is, for example, the number of errors or warnings of coding rule violations present in the source code.

[0072] The software quality measurement unit 2 extracts metrics such as the total number of lines, the total number of functions, the total number of files, the number of dependencies, the number of dependencies on other functions, and the number of defects for each function unit from the source code 1. The software quality measurement unit 2 measures the software quality data value 3 for each function unit based on the metrics extracted for each function unit.

[0073] For example, the software quality measurement unit 2 calculates the software quality data values ​​using the formulas (1) to (4), (7) and (8).

[0074]

number

[0075]

number

[0076] The number of violation dependencies in formula (7) is the number of dependencies from a functional unit to another functional unit that are not described in the design information specification. If the design information specification includes dependencies within a functional unit, the number of violation dependencies within the functional unit may also be taken into account in the calculation of formula (7). Formulas (7) and (8), like formulas (1) to (4), are specified so that the software quality data value is 0 at the highest quality and diverges to infinity at the lowest quality.

[0077] In this manner, in the third embodiment, the software quality measurement unit 2 calculates a value used as a software quality data value based on the difference between the architecture of the source code 1 itself and the architecture indicated in the design information 13. As a result, the difference between the architecture of the source code 1 itself and the architecture indicated in the design information 13 is reflected in the lifespan 9.

[0078] Furthermore, the software quality measurement unit 2 calculates a value to be used as a software quality data value based on the defect information 14. As a result, the defect information 14 is reflected in the lifespan 9.

[0079] Fig. 17 is a diagram showing an example of software quality data values, specifically, software quality data values ​​of revision 2. For convenience, in the example of Fig. 17, it is assumed that the six software quality data values ​​have the same influence on the software quality, and the coefficients of all the six software quality data values ​​are set to 16.7, which is an equal division of the total value of 100.

[0080] The age diagnosis unit 4 calculates a diagnosis age 5 for each functional unit based on the software quality data value 3 measured for each functional unit. The age diagnosis unit 4 stores the diagnosis age 5 calculated for each functional unit in the data accumulation unit 203, and the data accumulation unit 203 accumulates the diagnosis age 5 for each source code revision and each functional unit as shown in FIG.

[0081] The development trend approximation formula calculation unit 6 calculates the development trend approximation formula 7 for each function unit based on the diagnosis age 5 accumulated for each revision and for each function unit in the data accumulation unit 203. For example, the development trend approximation formula calculation unit 6 calculates y=15.97x+9.24 as the development trend approximation formula for function A by performing linear approximation such as the least squares method on the diagnosis age of function A. Similarly, the development trend approximation formula calculation unit 6 calculates y=36.64x+6.71 as the development trend approximation formula 7 for function B, and y=33.39x+11.13 as the development trend approximation formula for function C.

[0082] The lifespan estimation unit 8 estimates the lifespan 9 of the source code for each functional unit based on the development trend approximation formula 7 calculated for each functional unit. In the above example, the lifespan estimation unit 8 calculates 3.68 as the lifespan of function A, 0.55 as the lifespan of function B, and 0.66 as the lifespan of function C.

[0083] The lifespan correction unit 15 corrects the lifespan 9 for each functional unit based on the lifespan 9 estimated for each functional unit by the lifespan estimation unit 8 and the dependency of the functional unit. For example, the lifespan correction unit 15 changes the quality of the lifespan of a certain functional unit (hereinafter referred to as a first functional unit) depending on the quality of the lifespan of another functional unit (hereinafter referred to as a second functional unit) that is closely related to the certain functional unit.

[0084] As one example, when the lifespan of the second functional unit on which the first functional unit is most dependent is shorter than the lifespan of the first functional unit, the lifespan correction unit 15 reduces the lifespan of the first functional unit by 10%. On the other hand, when the lifespan of the second functional unit on which the first functional unit is most dependent is longer than the lifespan of the first functional unit, the lifespan correction unit 15 increases the lifespan of the first functional unit by 10%. The degree of dependency is determined, for example, using the number of dependencies of the metrics in FIG. 14 extracted from source code 1.

[0085] 14, the number of dependencies from function A to function B in revision-2 is 25, and the number of dependencies from function A to function C in revision-2 is 30, so of functions B and C, function A is most dependent on function C. In the above example, the lifespan of function C (0.66) is shorter than the lifespan of function A (3.68), so lifespan correction unit 15 corrects the lifespan of function A to 3.35, which is a 10% reduction from 3.68.

[0086] Similarly, the lifespan (0.66) of function C on which function B is most dependent is longer than the lifespan (0.55) of function B, so lifespan correction unit 15 corrects the lifespan of function B to 0.61, which is a 10% increase from 0.55. The lifespan (0.55) of function B on which function C is most dependent is shorter than the lifespan (0.66) of function C, so lifespan correction unit 15 corrects the lifespan of function C to 0.60, which is a 10% decrease from 0.66.

[0087] In the above example, the life correction unit 15 corrects the life of the first functional unit based on the life of the second functional unit that has the largest number of dependencies from the first functional unit, but this is not limited to the above. For example, when the input unit 201 receives the number of functional units to be used for correction, the life correction unit 15 may correct the life of the second functional unit that has the largest number of dependencies from the first functional unit based on the life of the second functional unit that has the largest number of dependencies from the first functional unit. direction The second functional units may be identified in that number in order from the first functional unit to the second functional unit, and the lifespan of the first functional unit may be corrected based on the lifespan of the second functional units in that number.

[0088] The life validity calculation unit 16 calculates life validity 17, which is the validity of the life for each functional unit, based on the difference between the architecture of the source code 1 itself and the architecture indicated in the design information 13. For example, when there is absolutely no difference between the dependency of the source code 1 itself and the dependency indicated in the design information for a certain functional unit, the life validity calculation unit 16 may calculate the life validity of the certain functional unit as 100%. On the other hand, when the difference between the dependency of the source code 1 itself and the dependency indicated in the design information for a certain functional unit is equal to or greater than a threshold value, the life validity calculation unit 16 may calculate the life validity of the certain functional unit as 0%.

[0089] The output unit 204 outputs information based on the lifespan 9 estimated for each functional unit by the lifespan estimation unit 8 and information based on the lifespan validity 17 calculated by the lifespan validity calculation unit 16 to an external device or the like. For example, the output unit 204 may output the source code 1, the software quality data value 3, the development trend approximation formula 7, the lifespan 9 before and after correction by the lifespan correction unit 15, the design information 13, the defect information 14, and the lifespan validity 17, as well as the diagnosis age 5 stored in the data storage unit 203.

[0090] Just as the output unit 204 outputs various information, the data storage unit 203 may store various information. For example, the data storage unit 203 may store source code 1, software quality data value 3, diagnosis age 5, development tendency approximation formula 7, lifespan before and after correction by the lifespan correction unit 15 9, design information 13, defect information 14, and lifespan validity 17.

[0091] <Summary of the Third Embodiment> According to the third embodiment as described above, the lifespan is corrected for each functional unit based on the lifespan estimated for each functional unit and the dependency of the functional unit, so that the accuracy of the lifespan can be improved.

[0092] Furthermore, according to the third embodiment, the difference between the architecture of the source code itself and the architecture indicated by the design information is reflected in the lifetime, so that the accuracy of the lifetime can be improved.

[0093] According to the third embodiment, the validity of the lifespan is calculated for each functional unit based on the difference between the architecture of the source code itself and the architecture indicated by the design information, and information based on the validity of the lifespan is output. With such a configuration, for example, it is possible to give a notice that allows the validity of the estimated lifespan to be recognized, which makes it easier to formulate guidelines for a development project.

[0094] Furthermore, according to the third embodiment, defect information is reflected in the life span, so that the accuracy of the life span can be improved.

[0095] <Fourth embodiment> 19 is a block diagram showing a configuration of an architecture lifetime estimation device 101 according to the present embodiment 4. In the following, among the components according to the present embodiment 4, components that are the same as or similar to the components described above are given the same or similar reference symbols, and different components will be mainly described.

[0096] In the following, a case will be described in which the diagnostic age of revision-1 is stored in data storage unit 203 as in embodiment 1, and architecture life estimation device 101 performs architecture life estimation from the source code of revision-1 to revision-2.

[0097] In the fourth embodiment, the intercept of the development trend approximation equation for each function unit is calculated based on the development forecast information for each function unit of the software, including the forecast for additional development or the forecast for maintenance. Related to The age threshold is controlled. In addition, the skill level of the worker is reflected in the gradient of the development tendency approximation formula based on the work information including the worker who developed the software and the work time.

[0098] Fig. 20 is a diagram showing an example of metrics for each revision. Fig. 21 is a diagram showing an example of the diagnosed age of revision-1 calculated by the age diagnostic unit 4 and stored in the data storage unit 203.

[0099] 22 is a diagram showing the proficiency of workers calculated when calculating the diagnostic age of revision-1 and stored in data storage unit 203. In the following, an example will be described in which workers α, β, and γ are developing source code. The calculation of the proficiency will be described together with the calculation of the diagnostic age of revision-2, which will be described later.

[0100] The architecture lifespan estimation device 101 in Fig. 19 has the same configuration as that in Fig. 1, with a threshold control unit 20 and a proficiency level calculation unit 22 added. The storage unit 202 stores development prospect information 18, work information 19, age threshold 21, and proficiency level 23 in addition to the contents stored in Fig. 1.

[0101] The input unit 201 receives and acquires the source code 1, development prospect information 18, and work information 19 from an external device or the like, and the storage unit 202 stores the acquired source code 1, development prospect information 18, and work information 19.

[0102] The development prospect information includes a numerical value indicating the development prospect for each function unit, as shown in Fig. 23. In the example of Fig. 23, the numerical value ranges from 1 to 5, with 1 corresponding to "very little development is expected" and 5 corresponding to "very frequent development is expected."

[0103] The work information is information about a worker, and includes, for example, as shown in FIG. 24, the worker, the functional unit developed by that worker, and the work time required for the development.

[0104] The software quality measurement unit 2 extracts metrics such as those shown in FIG. 20 from the source code 1. The extracted metrics may be stored in the data storage unit 203. The software quality measurement unit 2 measures a software quality data value 3 for each functional unit based on the metrics extracted for each functional unit. FIG. 25 is a diagram showing an example of the software quality data value, specifically, the software quality data value of revision-2.

[0105] The age diagnosis unit 4 calculates a diagnosis age 5 for each functional unit based on the software quality data value 3 measured for each functional unit. The age diagnosis unit 4 stores the diagnosis age 5 calculated for each functional unit in the data accumulation unit 203, and the data accumulation unit 203 accumulates the diagnosis age 5 for each source code revision and each functional unit as shown in FIG.

[0106] The development trend approximation formula calculation unit 6 calculates the development trend approximation formula 7 for each function unit based on the diagnosis age 5 accumulated for each revision and for each function unit in the data accumulation unit 203. For example, the development trend approximation formula calculation unit 6 calculates y=10.02x+16.37 as the development trend approximation formula for function A by performing linear approximation such as the least squares method on the diagnosis age of function A. Similarly, the development trend approximation formula calculation unit 6 calculates y=47.76x+9.52 as the development trend approximation formula 7 for function B, and y=38.16x+12.72 as the development trend approximation formula for function C.

[0107] The threshold control unit 20 controls the age threshold 21 for each functional unit based on the development prospect information 18 for each functional unit. For example, the threshold control unit 20 sets the age threshold 21 corresponding to the development prospect indicated by the development prospect information 18 as shown in Fig. 23 for each functional unit, using a correspondence relationship table between the development prospect and the age threshold shown in Fig. 27. In the first to third embodiments, the age threshold is a fixed value of 100, but in the fourth embodiment, for example, since the development prospect of function B in Fig. 23 is 2, the age threshold of function B is set to 50.

[0108] The skill level calculation unit 22 calculates the skill level of the worker based on the source code 1, the task information 19, and the diagnosed age 5 stored in the data storage unit 203 for each revision.

[0109] For example, the proficiency calculation unit 22 obtains the total number of lines per functional unit of the current revision-2 from the source code, and the total number of lines per functional unit of the previous revision-1 from the data accumulation unit 203. The proficiency calculation unit 22 also obtains the diagnostic ages 5 of the current revision-2 and the previous revision-1 from the data accumulation unit 203, and the work information 19 from the memory unit 202. Then, the proficiency calculation unit 22 calculates the proficiency value using formula (9).

[0110]

number

[0111] As a result, for example, the proficiency values ​​of the workers for function A, function B, and function C are calculated to be -3909, 960, and -5184, respectively. In the example of Fig. 24, the workers for functions A, B, and C are workers α, β, and γ, respectively, so the proficiency values ​​of workers α, β, and γ are calculated to be -3909, 960, and -5184, respectively. Note that when a worker is performing development work on multiple function units, statistics such as the average and weighted average of the proficiency values ​​calculated for the multiple function units may be used as the proficiency value of the worker.

[0112] Next, the proficiency calculation unit 22 specifies the proficiency of only the current task corresponding to the calculated proficiency value, for example, by using a correspondence relationship table between proficiency values ​​and proficiency levels shown in Fig. 28. When the proficiency values ​​of worker α, worker β, and worker γ are -3909, 960, and -5184, respectively, the proficiency of worker α, worker β, and worker γ for only the current task is specified to be 4, 3, and 5, respectively.

[0113] Then, the proficiency calculation unit 22 calculates the new proficiency by rounding off the average value of the proficiency of the worker only for the current task and the proficiency of the worker stored in the data storage unit 203. For example, if the proficiency of workers α, β, and γ only for the current task is 4, 3, and 5, respectively, and the proficiency in the data storage unit 203 is 3, 1, and 4 as shown in Fig. 22, the new proficiency is calculated as 4, 2, and 5.

[0114] The new proficiency level is not limited to the above, and for example, the proficiency level of the worker for the current task alone may be used as the new proficiency level. The new proficiency level is stored in the memory unit 202 and accumulated in the data accumulation unit 203.

[0115] The lifespan estimation unit 8 estimates the lifespan 9 for each functional unit based on the development trend approximation formula 7, the age threshold 21, and the new proficiency 23. For example, the lifespan estimation unit 8 identifies the proficiency coefficient corresponding to the new proficiency value using a correspondence relationship table between proficiency and proficiency coefficient shown in FIG. 29. Then, the lifespan estimation unit 8 calculates the lifespan for each functional unit using the development trend approximation formula 7, the age threshold 21, and the proficiency coefficient in formula (10).

[0116]

number

[0117] In the above example, the life spans of function A, function B, and function C are calculated to be 9.13, -1.32, and 19.02, respectively. Note that in Fig. 27, the greater the development prospects, the greater the age threshold in formula (10), and therefore the greater the life span calculated by life span estimation unit 8. Also, in Fig. 29, the greater the proficiency level, the smaller the proficiency level coefficient in formula (10), and therefore the greater the life span calculated by life span estimation unit 8.

[0118] The output unit 204 outputs to an external device or the like information based on the lifespan 9 estimated for each functional unit by the lifespan estimation unit 8. For example, the output unit 204 may output the source code 1, the software quality data value 3, the development trend approximation formula 7, the lifespan 9, the development prospect information 18, the work information 19, the age threshold 21, and the proficiency level 23, as well as the diagnosed age 5 stored in the data storage unit 203.

[0119] Just as the output unit 204 outputs various information, the data storage unit 203 may store various information. For example, the data storage unit 203 may store source code 1, software quality data value 3, diagnosis age 5, development trend approximation formula 7, life span 9, development prospect information 18, work information 19, age threshold 21, and proficiency level 23.

[0120] <Summary of the fourth embodiment> According to the above-described fourth embodiment, the age threshold is controlled for each functional unit based on the development prospects information for each functional unit, and the lifespan is estimated for each functional unit based on the development trend approximation equation and the age threshold, thereby improving the accuracy of the lifespan.

[0121] Furthermore, according to the fourth embodiment, the life span is estimated based on the development trend approximation formula and the skill level of the worker, so that the accuracy of the life span can be improved.

[0122] <Embodiment 5> 30 is a block diagram showing a configuration of an architecture lifetime estimation device 101 according to the present embodiment 5. In the following, among the components according to the present embodiment 5, components that are the same as or similar to the components described above are given the same or similar reference symbols, and different components will be mainly described.

[0123] In the following, a case will be described in which the diagnostic age of revision-1 is stored in data storage unit 203 as in embodiment 1, and architecture life estimation device 101 performs architecture life estimation from the source code of revision-1 to revision-2.

[0124] The architecture life estimation device 101 in Fig. 30 has the same configuration as that in Fig. 1, with a life basis extraction unit 24, an improvement item selection unit 26, and an improved life simulation unit 27 added. The storage unit 202 stores a life basis 25 and an improved life 28 in addition to the contents stored in Fig. 1.

[0125] The data accumulation unit 203 accumulates the metrics and software quality data values ​​3 extracted from the source code 1 by the software quality measurement unit 2 for each revision of the source code. The lifespan basis extraction unit 24 extracts the metrics and software quality data values ​​3 that are the basis for whether the lifespan 9 is good or bad, as lifespan basis 25. In this fifth embodiment, the lifespan basis extraction unit 24 extracts the software quality data values ​​3 that are equal to or greater than a predetermined threshold value, and the metrics that are the basis for calculating them, as lifespan basis 25 that have a negative impact on the lifespan 9.

[0126] The improvement item selection unit 26 selects some or all of the lifespan grounds 25 that have a negative effect on the lifespan 9. In the fifth embodiment, the improvement item selection unit 26 selects some or all of the lifespan grounds 25 extracted by the lifespan grounds extraction unit 24.

[0127] The improved lifespan simulation unit 27 estimates an improved lifespan 28 based on the development tendency approximation formula 7 calculated from the diagnosed age 5 when the lifespan basis 25 selected by the improvement item selection unit 26 is improved. In other words, the improved lifespan simulation unit 27 simulates how much the lifespan 9 will improve when the lifespan basis 25 selected by the improvement item selection unit 26 is improved.

[0128] In the fifth embodiment, the improvement item selection unit 26 is described as selecting one lifespan basis 25 having the greatest adverse effect on the lifespan 9 as the lifespan basis 25 to be improved, but this is not limited to this. For example, multiple or all of the lifespan basis 25 having the greatest adverse effect on the lifespan 9 may be selected, may be automatically selected by the device, or may be selected by the user via the input unit 201.

[0129] The degree of improvement may be selected in a similar manner. In the following, a case where the life 9 when one life basis 25 is improved 100% and eliminated is simulated as the improved life 28 will be described, but the life 9 when a part is improved can also be simulated as the improved life 28. In addition, after simulating the degree of improvement of the life 9 once, it is possible to take over the result and simulate the degree of improvement of other life basis 25 together, or it is also possible to separately simulate the degree of improvement of other life basis 25 without taking over the result. In addition, in the following, a case where processing is performed on the life of the entire software, that is, the life 9 of the entire source code, will be described, but in the second embodiment, the source code may be divided into predetermined units, and the same processing as below may be performed on the life 9 estimated for each unit.

[0130] Fig. 31 is a diagram showing an example of metrics for each revision. Of the metrics shown in Fig. 31, revision-1 and revision-2 are the same as those in embodiment 1 (see Fig. 2). Therefore, in this embodiment 5, the subsequently calculated diagnostic age of revision-1 (19.26), diagnostic age of revision-2 (58.06), their development tendency approximation formula (y=29.03x-3.26), and the lifespan of revision-2 (1.56) are the same as those in embodiment 1. Note that revision-3 will be described later.

[0131] FIG. 32 shows software quality data values ​​that are the basis for the lifespan of revision-2. The larger the software quality data value, the higher the diagnosis age in equation (5), and therefore the more adversely it affects the lifespan 9. In this fifth embodiment, the lifespan basis extraction unit 24 extracts one software quality data value that is the highest in value and has the most adverse effect on the lifespan, and the metric from which the one software quality data value is calculated, as one lifespan basis. As a specific example, the following describes a case in which the lifespan basis extraction unit 24 determines that the software quality data value and metric of "the number of functions whose number of lines per function exceeds a reference value" have the most adverse effect on the lifespan and extracts them as one lifespan basis.

[0132] The lifespan reason extraction unit 24 can also extract multiple software quality data values ​​and metrics that have a negative effect on the lifespan. Also, the lifespan reason extraction unit 24 can extract one or multiple software quality data values ​​and metrics that have a positive effect on the lifespan and present them as a model case for implementation.

[0133] The improvement item selection unit 26 selects a lifespan basis to be improved from among the lifespan basis extracted by the lifespan basis extraction unit 24. In the above example, the lifespan basis extraction unit 24 extracts one lifespan basis, and therefore the improvement item selection unit 26 selects the one lifespan basis as is. However, when the lifespan basis extraction unit 24 extracts multiple lifespan basis, one or more lifespan basis may be selected from the multiple lifespan basis by the improvement item selection unit 26 or a user. For example, the improvement item selection unit 26 may select one or more lifespan basis from the multiple lifespan basis extracted by the lifespan basis extraction unit 24 based on the software quality data value.

[0134] The improvement lifespan simulation unit 27 improves the lifespan basis selected by the improvement item selection unit 26. For example, the improvement lifespan simulation unit 27 adds simulated metrics to revision-3, as shown in Fig. 31, such that the software quality data value of "the number of functions whose number of lines per function exceeds a reference value" becomes 0, that is, such that it is improved by 100%. Such simulated metrics can be found, for example, by solving an optimization problem with the numerical values ​​of the metrics as variables, so that the value of equation (1) becomes 0.

[0135] The software quality measurement unit 2 measures the software quality data value indicating the quality of the source code based on the metrics in FIG. 31. FIG. 33 is a diagram showing an example of the software quality data value, specifically, the software quality data value of revision-3. The simulated metrics are reflected, and the software quality data value of "the number of functions whose number of lines per function exceeds the reference value" is 0. Note that, here, the improvement life simulation unit 27 creates the simulated metrics so that the software quality data value of "the number of functions whose number of lines per function exceeds the reference value" is 0, but the value after improvement and the degree of improvement are not limited to this. Also, the value after improvement and the degree of improvement may be specified by the device or by the user at the input unit 201.

[0136] As in the first embodiment, the age diagnosis unit 4 calculates the diagnosed age based on the software quality data value measured by the software quality measurement unit 2. In the case of Fig. 33, the age diagnosis unit 4 calculates 33.06 as the diagnosed age of revision-3, and stores it in the data accumulation unit 203. As a result, as shown in Fig. 34, the diagnosed age is accumulated for each revision in the data accumulation unit 203.

[0137] As in the first embodiment, the development tendency approximation formula calculation unit 6 calculates the development tendency approximation formula based on the diagnosis age accumulated for each revision in the data accumulation unit 203. For example, the development tendency approximation formula calculation unit 6 calculates y=14.20x+6.63 as the development tendency approximation formula by performing linear approximation such as the least squares method.

[0138] The improved lifespan simulation unit 27 estimates the improved lifespan based on the development trend approximation equation, similar to the estimation of the lifespan by the lifespan estimation unit 8. In the above example, the lifespan estimation unit 8 calculates 6.58 as the revision at which y=100 occurs when y=14.20x+6.63, and calculates 3.58, which is the improved lifespan, by subtracting the current revision 3 from the calculated revision 6.58.

[0139] 30 outputs the improved lifespan 28. For example, the output unit 204 may output the source code 1, the software quality data value 3, the development trend approximation formula 7, and the lifespan basis 25, the improved simulated metrics, the software quality data value 3, the diagnosis age 5, the development trend approximation formula 7, and the diagnosis age stored in the data storage unit 203.

[0140] Just as the output unit 204 outputs various information, the data storage unit 203 may store various information. For example, the data storage unit 203 may store the source code 1, the software quality data value 3, the diagnosis age 5, the development trend approximation formula 7, and the lifespan basis 25, as well as the improved simulated metrics, the software quality data value 3, the diagnosis age 5, and the development trend approximation formula 7.

[0141] <Summary of the fifth embodiment> According to the fifth embodiment as described above, by presenting the lifespan basis 25 for the current software, it is possible to clearly indicate the parts that need to be corrected as reuse development continues over the long term.

[0142] Furthermore, according to the fifth embodiment, it is possible to present an improved lifespan 28 in the case where a part or all of the lifespan basis 25 that has a negative effect on the lifespan 9 is improved, so that it is possible to easily formulate a guideline for whether the lifespan basis 25 should be improved in comparison with the lifespan 9. Also, by selecting a part of the lifespan basis 25 to be improved and repeating the estimation of the improved lifespan 28, it is possible to formulate a priority order for the lifespan basis 25 to be improved. This makes it possible to easily formulate a plan that allows improvement activities to be carried out in stages in parallel with new software development activities.

[0143] <Other Modifications> The acquisition unit including the input unit 201 in FIG. 1 described above, the software quality measurement unit 2, the age diagnosis unit 4 (diagnosed age calculation unit), the development trend approximation formula calculation unit 6, and the lifespan estimation unit 8 are hereinafter referred to as the "acquisition unit, etc." The acquisition unit, etc. are realized by a processing circuit 81 shown in FIG. 35. That is, the processing circuit 81 includes an acquisition unit that acquires a source code, a software quality measurement unit that measures a software quality data value based on the source code, a diagnosis age calculation unit that calculates the diagnosis age of the source code based on the software quality data value, a development trend approximation formula calculation unit that calculates a development trend approximation formula based on the diagnosis age accumulated in the data accumulation unit for each revision, and a lifespan estimation unit that estimates a lifespan based on the development trend approximation formula. Dedicated hardware may be applied to the processing circuit 81, or a processor that executes a program stored in a memory may be applied. The processor may be, for example, a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, a DSP (Digital Signal Processor), or the like.

[0144] When the processing circuit 81 is a dedicated hardware, the processing circuit 81 corresponds to, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a combination of these. Each function of the acquisition unit and the like may be realized by a circuit in which the processing circuit is distributed, or the functions of each unit may be realized by a single processing circuit.

[0145] When the processing circuit 81 is a processor, the functions of the acquisition unit and the like are realized by a combination with software and the like. The software and the like corresponds to, for example, software, firmware, or software and firmware. The software and the like are written as a program and stored in a memory. As shown in FIG. 36, the processor 82 applied to the processing circuit 81 realizes the functions of each unit by reading and executing a program stored in the memory 83. That is, the architecture lifespan estimation device 101 includes a memory 83 for storing a program that, when executed by the processing circuit 81, results in the execution of the steps of acquiring source code, measuring software quality data values ​​based on the source code, calculating the diagnostic age of the source code based on the software quality data values, accumulating the diagnostic age in the data accumulation unit for each revision of the source code, calculating a development trend approximation formula based on the diagnostic age accumulated in the data accumulation unit for each revision, and estimating the lifespan based on the development trend approximation formula. In other words, this program can be said to cause a computer to execute the procedures and methods of the acquisition unit and the like. Here, the memory 83 may be, for example, a non-volatile or volatile semiconductor memory such as a Random Access Memory (RAM), a Read Only Memory (ROM), a flash memory, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), an HDD (Hard Disk Drive), a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, a DVD (Digital Versatile Disc), a drive device for any of these, or any storage medium to be used in the future.

[0146] The above describes a configuration in which each function of the acquisition unit, etc. is realized either by hardware or software, etc. However, the present invention is not limited to this, and a configuration in which a part of the acquisition unit, etc. is realized by dedicated hardware and another part is realized by software, etc. For example, the acquisition unit can be realized by a processing circuit 81, an interface, a receiver, etc. as dedicated hardware, and the other functions can be realized by the processing circuit 81 as a processor 82 reading and executing a program stored in a memory 83.

[0147] As described above, the processing circuitry 81 can realize each of the above-mentioned functions by hardware, software, or a combination of these.

[0148] It should be noted that the embodiments and modifications may be freely combined, and the embodiments and modifications may be modified or omitted as appropriate.

[0149] The above description is illustrative in all respects and is not restrictive. It is understood that countless variations not illustrated can be envisioned. [Explanation of symbols]

[0150] 2 Software Quality Measurement Department, 4 Age Checkup Department , 6 development trend approximation formula calculation unit, 8 life estimation unit, 10 main unit life extraction unit, 15 life correction unit, 16 life validity calculation unit, 20 threshold control unit, 22 proficiency calculation unit, 24 life basis extraction unit, 26 improvement item selection unit, 27 improvement life simulation unit, 101 architecture life estimation device, 201 input unit, 203 data storage unit.

Claims

1. An acquisition unit for acquiring source code; a software quality measurement unit that measures a software quality data value indicating a quality of the source code based on the source code; an age calculation unit that calculates a software structural complexity of the source code as a diagnostic age of the source code based on the software quality data value; a data storage unit that stores the age at diagnosis for each revision of the source code; a development tendency approximation equation calculation unit that calculates a development tendency approximation equation showing a relationship between the revision and the diagnosis age based on the diagnosis age stored in the data storage unit for each revision; a lifespan estimation unit that estimates a lifespan of the revision of the source code based on the development trend approximation formula; Equipped with An architecture lifetime estimation device that outputs information based on the lifetime.

2. 2. The architecture lifetime estimation device according to claim 1, The source code is divided into predetermined units, the software quality measurement unit measures the software quality data value for each unit based on the source code divided into the units; the age calculation unit calculates the diagnosed age for each of the units based on the software quality data value measured for each of the units; The data storage unit stores the age at diagnosis for each revision and for each unit, The development trend approximation equation calculation unit calculates the development trend approximation equation for each unit based on the diagnosis age stored in the data storage unit for each revision and for each unit, The lifespan estimation unit estimates the lifespan for each unit based on the development trend approximation formula calculated for each unit.

3. 3. The architecture lifetime estimation device according to claim 2, an architecture lifetime estimation device that outputs information based on the lifetime estimated for each unit by the lifetime estimation unit.

4. 3. The architecture lifetime estimation device according to claim 2, a main unit lifetime extraction unit that extracts the lifetime of one of the units based on an effect of the lifetime estimated for each of the units by the lifetime estimation unit on the lifetime of the entire source code, An architecture lifetime estimation device that outputs information based on the lifetime of the one of the units.

5. 3. The architecture lifetime estimation device according to claim 2, An architecture lifetime estimation device, further comprising a lifetime correction unit that corrects the lifetime for each unit based on the lifetime estimated for each unit by the lifetime estimation unit and dependency of the unit.

6. 3. The architecture lifetime estimation device according to claim 2, The acquisition unit further acquires design information indicating an architecture that has been designed in advance for the source code; An architecture lifetime estimation device, wherein a difference between an architecture of the source code itself and the architecture indicated by the design information is reflected in the lifetime.

7. 3. The architecture lifetime estimation device according to claim 2, The acquisition unit further acquires design information indicating an architecture that has been designed in advance for the source code; a lifetime validity calculation unit that calculates the validity of the lifetime for each unit based on a difference between an architecture of the source code itself and the architecture indicated by the design information; The architecture lifespan estimation device outputs information based on the validity.

8. 2. The architecture lifetime estimation device according to claim 1, The acquisition unit further acquires defect information of the source code, The failure information is reflected in the lifetime.

9. 3. The architecture lifetime estimation device according to claim 2, The acquisition unit further acquires development prospect information for each unit, A threshold control unit controls an age threshold for each of the units based on the development prospect information for each of the units, The lifespan estimation unit estimates the lifespan for each unit based on the development trend approximation formula and the age threshold.

10. 2. The architecture lifetime estimation device according to claim 1, The acquisition unit further acquires work information related to a person who contributed to the source code; a proficiency calculation unit that calculates a proficiency level of the worker based on the source code, the work information, and the diagnosed age stored in the data storage unit for each revision, The lifespan estimation unit estimates the lifespan based on the development trend approximation formula and the proficiency level.

11. 2. The architecture lifetime estimation device according to claim 1, the data storage unit stores the metrics and the software quality data values ​​extracted from the source code by the software quality measurement unit for each revision of the source code; The architecture lifetime estimation device further comprises a lifetime basis extraction unit that extracts, as lifetime basis, the metrics and the software quality data values ​​that are basis for whether the lifetime is good or bad.

12. 12. The architecture lifetime estimation apparatus according to claim 11, an improvement item selection unit that selects a part or all of the lifespan grounds that have a negative effect on the lifespan from among the lifespan grounds; an improved lifespan simulation unit that estimates an improved lifespan based on the development tendency approximation formula calculated from the diagnosed age when the lifespan basis selected by the improvement item selection unit is improved; The architecture lifetime estimation device further comprises:

13. Get the source code, measuring, based on the source code, a software quality data value indicative of a quality of the source code; Calculating a software structural complexity of the source code as a diagnostic age of the source code based on the software quality data value; storing the age at diagnosis in a data storage unit for each revision of the source code; calculating a development trend approximation equation showing a relationship between the revision and the age at diagnosis based on the age at diagnosis stored for each revision in the data storage unit; estimating a lifespan for the revision of the source code based on the development trend approximation formula; and outputting information based on the lifetime.

Images