WO2023139822A1 - アーキテクチャ寿命推定装置及びアーキテクチャ寿命推定方法 - Google Patents

アーキテクチャ寿命推定装置及びアーキテクチャ寿命推定方法 Download PDF

Info

Publication number
WO2023139822A1
WO2023139822A1 PCT/JP2022/031302 JP2022031302W WO2023139822A1 WO 2023139822 A1 WO2023139822 A1 WO 2023139822A1 JP 2022031302 W JP2022031302 W JP 2022031302W WO 2023139822 A1 WO2023139822 A1 WO 2023139822A1
Authority
WO
WIPO (PCT)
Prior art keywords
unit
architecture
source code
age
lifetime
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2022/031302
Other languages
English (en)
French (fr)
Japanese (ja)
Inventor
翔 金子
祐希 檜皮
将輝 藤田
喜隆 井本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to US18/728,320 priority Critical patent/US20250103327A1/en
Priority to JP2023575049A priority patent/JP7621522B2/ja
Publication of WO2023139822A1 publication Critical patent/WO2023139822A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/77—Software metrics
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Definitions

  • the present disclosure relates to an architecture lifetime estimation device and an architecture lifetime estimation method.
  • Patent Literature 1 proposes a technique of calculating weighted dependency strength for each dependency between software components using weight information based on the importance of dependency types, which are types of relationships between software components, and visualizing the dependency strength.
  • Patent Document 1 the software quality such as the strength of dependence is calculated at a single point in time when the source code is input, but it does not reflect the improvement or deterioration of the software quality over the long-term development period. For this reason, the source code developer cannot know to what extent the software assets can be operated, and there is a problem that it is difficult to appropriately formulate guidelines for the development project.
  • the present disclosure has been made in view of the problems described above, and aims to provide a technology that can appropriately formulate guidelines for development projects.
  • the architecture life estimation device includes an acquisition unit that acquires source code, a software quality measurement unit that measures a software quality data value that indicates the quality of the source code based on the source code, an age calculation unit that calculates the complexity of the software structure of the source code as the diagnosis age of the source code based on the software quality data value, a data storage unit that stores the diagnosis age for each revision of the source code, and a data storage unit that stores the diagnosis age for each revision of the source code.
  • a development trend approximation formula calculating unit that calculates a development trend approximation formula that indicates the relationship with age at diagnosis, and a life expectancy estimating unit that estimates the life of the revision of the source code based on the development trend approximation formula, and outputs information based on the life.
  • the development trend approximation formula is calculated based on the diagnostic age accumulated for each revision in the data storage unit, and the lifespan of the source code is estimated based on the development trend approximation formula. According to such a configuration, since the lifetime is estimated for a period of time instead of a point in time, it is possible to appropriately formulate guidelines for the development project.
  • FIG. 1 is a block diagram showing the configuration of an architecture life estimation device according to Embodiment 1;
  • FIG. FIG. 4 is a diagram showing an example of metrics according to Embodiment 1;
  • FIG. 4 is a diagram showing an example of age at diagnosis according to Embodiment 1;
  • FIG. 4 is a diagram showing an example of software quality data values according to Embodiment 1;
  • FIG. 4 is a diagram showing an example of age at diagnosis according to Embodiment 1;
  • FIG. 4 is a diagram showing an example of software quality data values according to Embodiment 1;
  • FIG. FIG. 4 is a diagram showing an example of age at diagnosis according to Embodiment 1;
  • FIG. 11 is a block diagram showing the configuration of an architecture life estimation device according to a second embodiment;
  • FIG. 10 is a diagram showing an example of metrics according to the second embodiment
  • FIG. FIG. 12 is a diagram showing an example of age at diagnosis according to Embodiment 2
  • FIG. FIG. 10 is a diagram showing an example of software quality data values according to Embodiment 2
  • FIG. FIG. 12 is a diagram showing an example of age at diagnosis according to Embodiment 2
  • FIG. FIG. 12 is a block diagram showing the configuration of an architecture life expectancy estimation device according to Embodiment 3
  • FIG. 13 is a diagram showing an example of metrics according to Embodiment 3
  • FIG. FIG. 13 is a diagram showing an example of age at diagnosis according to Embodiment 3
  • FIG. FIG. 13 is a diagram showing an example of dependence between functional units according to Embodiment 3;
  • FIG. 12 is a diagram showing an example of software quality data values according to Embodiment 3;
  • FIG. FIG. 13 is a diagram showing an example of age at diagnosis according to Embodiment 3;
  • FIG. FIG. 13 is a block diagram showing the configuration of an architecture life estimation device according to Embodiment 4;
  • FIG. 13 is a diagram showing an example of metrics according to Embodiment 4;
  • FIG. 13 is a diagram showing an example of age at diagnosis according to Embodiment 4;
  • FIG. FIG. 13 is a diagram showing an example of skill levels of workers according to Embodiment 4;
  • FIG. FIG. 13 is a diagram showing an example of prospective development information according to Embodiment 4;
  • FIG. FIG. 12 is a diagram showing an example of work information according to Embodiment 4;
  • FIG. 13 is a diagram showing an example of software quality data values according to Embodiment 4;
  • FIG. 13 is a diagram showing an example of age at diagnosis according to Embodiment 4;
  • FIG. 14 is a diagram showing an example of a correspondence table between development prospects and age thresholds according to Embodiment 4;
  • FIG. 14 is a diagram showing an example of a correspondence table between skill values and skill levels according to the fourth embodiment;
  • FIG. 13 is a diagram showing an example of a correspondence table between skill levels and skill level coefficients according to the fourth embodiment;
  • FIG. 12 is a block diagram showing the configuration of an architecture life estimation device according to Embodiment 5;
  • FIG. 13 is a diagram showing an example of metrics according to Embodiment 5;
  • FIG. 13 is a diagram showing an example of software quality data values according to Embodiment 5;
  • FIG. 13 is a diagram showing an example of software quality data values according to Embodiment 5;
  • FIG. 21 is a diagram showing an example of age at diagnosis according to Embodiment 5.
  • FIG. FIG. 11 is a block diagram showing a hardware configuration of an architecture lifespan estimation device according to another modification;
  • FIG. 11 is a block diagram showing a hardware configuration of an architecture lifespan estimation device according to another modification;
  • FIG. 1 is a block diagram showing the configuration of the architecture lifetime estimation device 101 according to the first embodiment.
  • software diversion development is performed to generate revision-2 source code by diverting revision-1 source code
  • software diversion development is performed to generate revision-3 source code by diverting revision-2 source code.
  • a revision is a revision of the source code for repairing software such as maintenance and addition of functions, and the greater the number of revisions, the greater the number.
  • the architecture lifetime estimation device 101 estimates the architecture lifetime from revision-1, revision-2, and revision-3 source codes will be described below.
  • Fig. 2 is a diagram showing an example of metrics for each revision.
  • a metric is a numerical value or the like for quantitatively evaluating software quality, and includes, for example, the number of lines, the number of functions, the cyclomatic complexity, and the number of dependencies.
  • FIG. 3 is a diagram showing an example of revision-1 diagnostic ages calculated by the age diagnosis unit 4 and stored in the data storage unit 203.
  • FIG. Calculation of age at diagnosis for revision-2 will be described later, but calculation of age at diagnosis for revision-1 and revision-3 is similar to calculation of age at diagnosis for revision-2.
  • diagnosis age takes a numerical value from “0 to infinity”.
  • a low diagnosis age that is, a low numerical value, indicates that the software structure is low in complexity and the software quality is good.
  • Lifetime which will be described later, is the number of times the source code can be revised, which is estimated based on the accumulated change in age at diagnosis.
  • the architecture life estimation device 101 is a device such as a computer that performs software quality analysis and development trend analysis.
  • the architecture lifetime estimation device 101 estimates a numerically quantified lifetime (also referred to as an architecture lifetime) that can be used for software quality analysis and development trend analysis, and development project guideline formulation.
  • the architecture lifespan estimation device 101 in FIG. 1 includes a software quality measurement unit 2, an age diagnosis unit 4 as an age calculation unit, a development trend approximation expression calculation unit 6, a lifespan estimation unit 8, an acquisition unit as an input unit 201, 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, a diagnosis age 5, a development trend approximation formula 7, and a life span 9.
  • the input unit 201 receives and acquires the source code 1 from an external device or the like, and the storage unit 202 stores the acquired source code 1.
  • a source code is a string of characters on which software (S/W) such as a computer program is based, and defines a set of instructions for a computer.
  • the software quality measurement unit 2 extracts the total number of lines, the total number of functions, the total number of files, etc. as shown in FIG. 2 from the source code 1 as metrics. 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, and cyclomatic complexity.
  • the software quality measurement unit 2 measures the software quality data value 3 that indicates the quality of the source code based on the extracted metrics.
  • a software quality data value is a value that is an index of an element of software quality data. For example, the software quality measurement unit 2 calculates software quality data values using equations (1) to (4).
  • Equations (1) to (4) are defined to diverge to 0 when the software quality data value is the highest quality and to infinity when the software quality is the lowest.
  • the formulas for calculating the software quality data value are not limited to formulas (1) to (4). Also, for the software quality data value, for example, an index relating to the number of functions per file, an index relating to cyclomatic complexity, or the like may be used.
  • FIG. 4 is a diagram showing an example of software quality data values, specifically revision-2 software quality data values.
  • FIG. 4 shows the measured software quality data values for each software quality data element.
  • FIG. 4 also shows the 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 below, calculates the diagnosis age of the source code.
  • the coefficient is used to appropriately weight the software quality data value based on the degree of influence on the diagnostic age, and to adjust the number of digits of the software quality data value.
  • the coefficients of each software quality data are set to be 100 in total.
  • the coefficients of the four software quality data values are all set to 25, which is the total value of 100 equally distributed, assuming that the four software quality data values have the same influence on the software quality.
  • the age diagnosis unit 4 calculates the software structural complexity of the source code as the diagnosis age 5 of the source code. For example, the age diagnosis unit 4 calculates the diagnosis age of the source code using Equation (5).
  • the age diagnosis unit 4 calculates 58.06 ( ⁇ 25 ⁇ (1.00+0.10+1.00+0.22)) as the diagnosis age of revision-2.
  • Age diagnosing unit 4 stores the calculated diagnostic age in data storage unit 203 .
  • the storage of the diagnostic age of revision-2 causes the diagnostic ages of revision-1 and revision-2 to be stored in the data storage unit 203 as shown in FIG.
  • the data accumulation unit 203 accumulates the diagnosis age 5 for each revision of the source code.
  • the lifespan estimation unit 8 estimates a lifespan 9 related to the revision of the source code based on the development trend approximation formula 7.
  • the lifespan estimating unit 8 calculates the lifespan by, for example, calculating the revision when the age at diagnosis in the development trend approximation formula 7 is equal to the age threshold, which is a predetermined threshold for the age at diagnosis, and subtracting the current revision from the calculated revision.
  • the value calculated in this way is used as the life, but it is not limited to this.
  • the revision when the diagnostic age of the development trend approximation formula 7 becomes equal to the age threshold may be used as it is as the life.
  • the output unit 204 outputs information based on the lifespan 9 estimated by the lifespan estimation unit 8 to an external device, a worker, and the like.
  • the output unit 204 may output the source code 1, the software quality data value 3, the development trend approximate expression 7, the life span 9, and the diagnostic age 5 accumulated in the data accumulation unit 203.
  • the data storage unit 203 may store various information.
  • the data storage unit 203 may store source code 1, software quality data value 3, diagnosis age 5, development trend approximation formula 7, and life span 9. FIG.
  • the software quality measurement unit 2 measures the software quality data value 3 that indicates the quality of the source code based on the extracted metrics.
  • FIG. 6 is a diagram showing an example of software quality data values, specifically showing software quality data values of revision-3.
  • the age diagnosis unit 4 calculates the diagnostic 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 values 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.
  • the age diagnosis 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.
  • FIG. 8 is a block diagram showing the configuration of the architecture lifetime estimation device 101 according to the second embodiment.
  • constituent elements that are the same as or similar to the above-described constituent elements are denoted by the same or similar reference numerals, and different constituent elements will be mainly described.
  • the diagnostic age of revision-1 is stored in the data storage unit 203 in the same manner as in the first embodiment, and the architecture life expectancy estimation device 101 estimates the architecture life from the source codes of revision-1 to revision-2.
  • the lifetime of the entire software that is, the lifetime of the entire source code was estimated.
  • the source code is divided into predetermined units, and the lifetime is estimated for each division.
  • the predetermined unit is a functional unit of software, but it is not limited to this, and may be, for example, a unit that requires modification.
  • 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 diagnosis section 4 and stored in the data storage section 203.
  • the source code is divided into functional units such as function A, function B, and function C.
  • the functional unit may be set based on the folder structure, or the functional unit may be set by receiving the functional configuration definition file defining the functional configuration in the input unit 201, storing it in the storage unit 202, and referencing it in the software quality measurement unit 2.
  • the architecture life expectancy estimation device 101 of FIG. 8 has the same configuration as that of FIG. 1 with the main unit life extraction unit 10 added.
  • the storage unit 202 stores the main unit life 11 in addition to the contents stored in FIG.
  • the software quality measurement unit 2 extracts, for example, 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 as metrics for each function unit.
  • a software quality measurement unit 2 measures a software quality data value 3 for each function based on the metrics extracted for each function.
  • FIG. 11 is a diagram showing an example of software quality data values, specifically revision-2 software quality data values.
  • FIG. 11 shows software quality data values measured for each functional unit.
  • the age diagnosis unit 4 calculates the diagnostic 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 diagnostic age 5 calculated for each functional unit in the data storage unit 203, and the data storage unit 203 stores the diagnostic age 5 for each revision of the source code and for each functional unit as shown in FIG.
  • 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 life estimator 8 calculates the life of function A as 6.35, the life of function B as ⁇ 0.11, and the life of function C as 0.29.
  • the main unit lifetime extraction unit 10 extracts the main unit lifetime 11, which is the lifetime 9 of one functional unit, based on the influence of the lifetime 9 estimated for each functional unit by the lifetime estimation unit 8 on the lifetime 9 of the entire source code 1.
  • the main unit life span extracting unit 10 extracts, as the main unit life span, the life span of one functional unit that has the greatest influence on the life span of the entire source code estimated in the first embodiment, among the life spans of the functional units.
  • the main unit life span extracting unit 10 calculates a unit life scale that indicates the influence on the life span of the entire source code using equation (6).
  • the unit life is the life of each functional unit estimated in Embodiment 2
  • the total life is the life of the entire source code estimated in Embodiment 1
  • the number of unit lines is the total number of lines of each functional unit in FIG. 9, and the total number of lines is the total number of lines of each functional unit.
  • the main unit life span extracting unit 10 extracts, as the main unit life span, the life of the functional unit with the largest unit life span among the unit life spans calculated for each functional unit. For example, when the unit lifetime scales of function A, function B, and function C are 1.65, 0.39, and 0.32, respectively, the main unit lifetime extracting unit 10 extracts 6.35, which is the lifetime of function A with the largest unit lifetime scale, as the main unit lifetime.
  • 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.
  • 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 lifetime among the lifetimes of the functional units, its lifetime (-0.11 in the above example), and the software quality data value 3 of the functional unit that is the factor that made the lifetime worse.
  • the output unit 204 may output the source code 1, the diagnostic age 5, and the development trend approximation formula 7 of the functional unit with the worst life span (function B in the above example).
  • the output unit 204 may output the number of lifespans of functional units in ascending order of life span.
  • the output unit 204 outputs information based on the main unit life span extracted by the main unit life span extraction unit 10 to an external device or the like.
  • the output unit 204 may output the main unit life 11 (the life of function A in the above example).
  • the output unit 204 may output the source code 1, the software quality data value 3, the development trend approximation formula 7, the life span 9, and the diagnostic age 5 accumulated in the data accumulation unit 203 for the functional unit (function A in the above example) from which the main unit life span 11 is extracted.
  • the data storage unit 203 may store various information.
  • the data accumulation unit 203 may accumulate 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.
  • information based on the life estimated for each functional unit is output. According to such a configuration, for example, it is possible to make a notification that can recognize a functional unit with a relatively short life, so that it is possible to facilitate the formulation of a guideline for a development project.
  • the main unit life which is the life of one functional unit, is extracted based on the influence on the life of the entire source code, and information based on the main unit life is output.
  • a notification capable of recognizing a functional unit that must not impair the quality of software, so that it is possible to easily formulate guidelines for a development project.
  • FIG. 13 is a block diagram showing the configuration of the architecture lifetime estimation device 101 according to the third embodiment.
  • constituent elements that are the same as or similar to the above-described constituent elements are denoted by the same or similar reference numerals, and different constituent elements will be mainly described.
  • the diagnostic age of revision-1 is stored in the data storage unit 203 in the same manner as in the first embodiment, and the architecture life expectancy estimation device 101 estimates the architecture life from the source codes of revision-1 to revision-2.
  • the lifetime estimated for each functional unit of software is corrected in consideration of the quality of the lifetime of closely related functional units. Further, by additionally inputting design information such as an architecture design document or an architecture modularization design document, the difference between the software design and implementation in the source code is reflected in the lifetime. In addition, by additionally inputting defect information such as source code errors or warnings, the defect information is reflected in the service life.
  • 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 another function, and the number of failures.
  • FIG. 15 is a diagram showing an example of the diagnostic age of revision-1 calculated by the age diagnosis unit 4 and stored in the data storage unit 203. As shown in FIG.
  • the architecture life expectancy estimation device 101 in FIG. 13 has the same configuration as that of FIG.
  • the storage unit 202 stores design information 13, defect information 14, and life validity 17 in addition to the contents stored in FIG.
  • 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.
  • the design information is information indicating the architecture designed in advance for the source code, and includes dependencies between functional units, as shown in FIG. 16, for example.
  • a program depends on another program to mean that the other program is required to build or run the program.
  • the example of FIG. 16 shows that function B depends on function A, and function C depends on function A and function B.
  • FIG. The design information may include not only dependencies between functional units but also dependencies within functional units.
  • the defect information includes, for example, the number of defects, which is the number of errors or coding rule violation warnings that exist in the source code.
  • the software quality measurement unit 2 extracts 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, the number of defects, etc. as shown in FIG. 14 from the source code 1 as metrics for each function.
  • a software quality measurement unit 2 measures a software quality data value 3 for each function based on the metrics extracted for each function.
  • the software quality measurement unit 2 calculates software quality data values using formulas (1) to (4), formulas (7) and formulas (8).
  • the number of violation dependencies in formula (7) is the number of dependencies not described in the design document of the design information among the dependencies from one functional unit to another functional unit. If the design document of the design information includes dependencies within the functional units, the number of violation dependencies within the functional units may also be taken into account in the calculation of Equation (7).
  • Equations (7) and (8) like Equations (1) to (4), are defined to diverge to 0 when the software quality data value is the highest quality and to infinity when the software quality is the lowest.
  • the software quality measurement unit 2 calculates the value used as the software quality data value based on the difference between the architecture of the source code 1 itself and the architecture indicated by the design information 13. As a result, the lifetime 9 reflects the difference between the architecture of the source code 1 itself and the architecture indicated by the design information 13 .
  • the software quality measurement unit 2 calculates a value to be used as the software quality data value based on the defect information 14 . As a result, the defect information 14 is reflected in the life 9. FIG.
  • FIG. 17 is a diagram showing an example of software quality data values, specifically revision-2 software quality data values.
  • the coefficients of the six software quality data values are all set to 16.7, equally distributed from the total value of 100, assuming that the six software quality data values have the same effect on the software quality.
  • the age diagnosis unit 4 calculates the diagnostic 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 diagnostic age 5 calculated for each functional unit in the data storage unit 203, and the data storage unit 203 stores the diagnostic age 5 for each revision of the source code and for each functional unit as shown in FIG.
  • 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 life estimator 8 calculates the life of function A to be 3.68, the life of function B to 0.55, and the life of function C to 0.66.
  • 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 dependence of the functional unit. For example, the life correction unit 15 changes the quality of the life of a certain functional unit (hereinafter referred to as the first functional unit) according to the quality of the life of another functional unit (hereinafter referred to as the second functional unit) closely related to the given functional unit.
  • the first functional unit the functional unit
  • the second functional unit closely related to the given functional unit.
  • the lifespan correction unit 15 reduces the lifespan of the first functional unit by 10% when the lifespan of the second functional unit, on which the first functional unit most depends, is shorter than the lifespan of the first functional unit. On the other hand, if the life of the second functional unit on which the first functional unit most depends is longer than the life of the first functional unit, the life correction unit 15 increases the life of the first functional unit by 10%.
  • the number of dependencies of the metrics in FIG. 14 extracted from source code 1, for example is used.
  • 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. Therefore, among functions B and C, the function on which function A depends the most is function C. In the above example, the life of function C (0.66) is shorter than the life of function A (3.68), so the life correction unit 15 corrects the life of function A from 3.68 to 3.35, which is reduced by 10%.
  • the life correction unit 15 increases the life of function B from 0.55 by 10% to 0.61. Since the life of function B (0.55) on which function C depends most is shorter than the life of function C (0.66), the life correction unit 15 reduces the life of function C from 0.66 by 10% to 0.60.
  • the lifespan correction unit 15 corrected the lifespan of the first functional unit based on the lifespan of the second functional unit on which the number of dependencies of the first functional unit is the largest, but it is not limited to this.
  • the lifespan correction unit 15 may identify the second functional units by that number in descending order of the number of dependencies from the first functional unit, and correct the lifespan of the first functional unit based on the lives of the second functional units of this number.
  • the lifespan validity calculation unit 16 calculates lifespan validity 17, which is the validity of the lifespan, for each functional unit based on the difference between the architecture of the source code 1 itself and the architecture indicated by the design information 13 .
  • the lifespan validity calculation unit 16 may calculate the lifespan validity of a certain functional unit as 100% when there is no difference between the dependency of the source code 1 itself and the dependency indicated in the design information.
  • the lifespan validity calculation unit 16 may calculate the lifespan validity of a certain functional unit as 0% when the difference between the dependency of the source code 1 itself and the dependency indicated in the design information is equal to or greater than a threshold.
  • 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.
  • 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, the lifespan validity 17, and the diagnostic age 5 accumulated in the data accumulation unit 203.
  • the data storage unit 203 may store various information.
  • the data accumulation unit 203 may accumulate source code 1, software quality data value 3, diagnosis age 5, development trend approximation formula 7, life before and after correction by life correction unit 15 9, design information 13, defect information 14, and life validity 17.
  • the lifetime is corrected for each functional unit based on the estimated lifetime for each functional unit and the dependence of the functional unit, so the accuracy of the lifetime can be improved.
  • the third embodiment since the difference between the architecture of the source code itself and the architecture indicated by the design information is reflected in the lifetime, it is possible to improve the accuracy of the lifetime.
  • the lifetime validity which is the validity of the lifetime, is calculated for each functional unit, and information based on the lifetime validity is output. According to such a configuration, for example, it is possible to make a notification that allows recognition of the validity of the estimated life span, so that it is possible to facilitate the formulation of development project guidelines.
  • the defect information is reflected in the service life, so the precision of the service life can be improved.
  • FIG. 19 is a block diagram showing the configuration of the architecture lifetime estimation device 101 according to the fourth embodiment.
  • constituent elements that are the same as or similar to the above-described constituent elements are denoted by the same or similar reference numerals, and different constituent elements will be mainly described.
  • the diagnostic age of revision-1 is stored in the data storage unit 203 in the same manner as in the first embodiment, and the architecture life expectancy estimation device 101 estimates the architecture life from the source codes of revision-1 to revision-2.
  • the age threshold which is the intercept of the development trend approximation formula, is controlled for each functional unit based on the development prospect information for each software functional unit, including additional development prospects or maintenance prospects. Also, based on the work information including the worker who developed the software and work time, the skill level of the worker is reflected in the slope of the development trend approximation formula.
  • FIG. 20 is a diagram showing an example of metrics for each revision.
  • FIG. 21 is a diagram showing an example of the diagnostic age of revision-1 calculated by the age diagnosis unit 4 and stored in the data storage unit 203. As shown in FIG.
  • FIG. 22 is a diagram showing the skill levels of workers calculated when calculating the diagnostic age of Revision-1 and stored in the data storage unit 203.
  • FIG. 22 a case where workers ⁇ , ⁇ , and ⁇ are developing source codes will be described as an example. The calculation of the proficiency level will be described together with the calculation of the revision-2 diagnosis age, which will be described later.
  • the architecture life estimation device 101 of FIG. 19 has the same configuration as that of FIG.
  • Storage unit 202 stores development prospect information 18, work information 19, age threshold 21, and skill level 23 in addition to the contents stored in FIG.
  • the input unit 201 receives and acquires the source code 1, the prospective development information 18 and the work information 19 from an external device or the like, and the storage unit 202 stores the acquired source code 1, the prospective development information 18 and the work information 19.
  • the development prospect information includes numerical values indicating development prospects for each function.
  • the numerical value is anywhere from 1 to 5, with 1 corresponding to "rarely expected to be developed” and 5 to "very frequently expected to be developed.”
  • the work information is information about the worker, and includes, for example, the worker, the functional unit developed by the worker, and the work time required for development, as shown in FIG.
  • 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.
  • FIG. A software quality measurement unit 2 measures a software quality data value 3 for each function based on the metrics extracted for each function.
  • FIG. 25 is a diagram showing an example of software quality data values, specifically revision-2 software quality data values.
  • the age diagnosis unit 4 calculates the diagnostic 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 diagnostic age 5 calculated for each functional unit in the data storage unit 203, and the data storage unit 203 stores the diagnostic age 5 for each revision of the source code and for each functional unit as shown in FIG.
  • the threshold control unit 20 controls the age threshold 21 for each function based on the development prospect information 18 for each function. For example, the threshold control unit 20 uses the correspondence table between development prospects and age thresholds shown in FIG. 27 to set the age threshold 21 corresponding to the development prospect indicated by the development prospect information 18 as shown in FIG. In Embodiments 1 to 3, the age threshold is a fixed value of 100, but in Embodiment 4, for example, the development prospect of function B in FIG.
  • the skill level calculation unit 22 calculates the skill level of the worker based on the source code 1, the work information 19, and the diagnosis age 5 accumulated for each revision in the data accumulation unit 203.
  • the proficiency calculation unit 22 acquires from the source code the total number of lines for each functional unit in the current revision-2 and from the data storage unit 203 the total number of lines for each functional unit in the previous revision-1.
  • the skill level calculation unit 22 also acquires the diagnostic age 5 of the current revision-2 and the previous revision-1 from the data storage unit 203 and the work information 19 from the storage unit 202 . Then, the skill level calculation unit 22 calculates the skill value using Equation (9).
  • the skill values of the workers for function A, function B, and function C are calculated as -3909, 960, and -5184, respectively.
  • the workers ⁇ , ⁇ , and ⁇ are the workers for the functions A, B, and C, respectively, so the skill values of the workers ⁇ , ⁇ , and ⁇ are calculated as -3909, 960, and -5184, respectively.
  • a statistic such as an average or a weighted average of the skill values calculated for the plurality of functional units may be used as the worker's skill value.
  • the skill level calculation unit 22 identifies the skill level of only the current work corresponding to the calculated skill value, for example, using the correspondence table between skill values and skill levels shown in FIG.
  • the skill values of worker ⁇ , worker ⁇ , and worker ⁇ are ⁇ 3909, 960, and ⁇ 5184, respectively
  • the skill levels of worker ⁇ , worker ⁇ , and worker ⁇ only for the current work are specified as 4, 3, and 5, respectively.
  • the skill level calculation unit 22 calculates, as a new skill level, a value obtained by rounding off the decimal point of the average value of the worker's skill level only for this work and the worker's skill level accumulated in the data accumulation unit 203.
  • the skill levels of only the current work are 4, 3, and 5, respectively, and if the skill levels of data storage unit 203 are 3, 1, and 4 as shown in FIG. 22, the new skill levels are calculated as 4, 2, and 5.
  • the new proficiency level is not limited to the above.
  • the proficiency level of the worker only for the current work may be used as it is as the new proficiency level.
  • the new skill level is stored in the storage unit 202 and accumulated in the data accumulation unit 203 .
  • 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 skill level 23. For example, the lifespan estimating unit 8 identifies the skill factor corresponding to the new skill value by using the correspondence table between skill levels and skill factor coefficients shown in FIG. 29, for example. Life expectancy estimator 8 then calculates the life expectancy for each functional unit using development trend approximation formula 7, age threshold 21, and skill level coefficient in formula (10).
  • the lifespans of function A, function B, and function C are calculated as 9.13, -1.32, and 19.02, respectively.
  • the age threshold in the formula (10) increases as the development prospect increases, so the life span calculated by the life span estimation unit 8 increases.
  • the higher the skill level the smaller the skill level coefficient in equation (10), so the life span calculated by the life span estimation unit 8 becomes longer.
  • 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.
  • the output unit 204 may output the source code 1, the software quality data value 3, the development trend approximation formula 7, the life span 9, the development prospect information 18, the work information 19, the age threshold 21 and the skill level 23, and the diagnosis age 5 accumulated in the data accumulation unit 203.
  • the data storage unit 203 may store various information.
  • 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 skill level 23.
  • the age threshold is controlled for each functional unit based on the development prospect information for each functional unit, and the life expectancy for each functional unit is estimated based on the development trend approximation formula and the age threshold, so that the accuracy of the life expectancy can be improved.
  • the life expectancy is estimated based on the development trend approximation formula and the skill level of the worker, so the accuracy of the life expectancy can be improved.
  • FIG. 30 is a block diagram showing the configuration of the architecture lifetime estimation device 101 according to the fifth embodiment.
  • constituent elements that are the same as or similar to the above-described constituent elements are denoted by the same or similar reference numerals, and different constituent elements will be mainly described.
  • the diagnostic age of revision-1 is stored in the data storage unit 203 in the same manner as in the first embodiment, and the architecture life expectancy estimation device 101 estimates the architecture life from the source codes of revision-1 to revision-2.
  • the architecture life estimation device 101 of FIG. 30 has the same configuration as that of FIG. 1 with the addition of a life basis extraction unit 24, an improvement item selection unit 26, and an improved life expectancy simulation unit 27.
  • Storage unit 202 stores life expectancy basis 25 and improved life expectancy 28 in addition to the contents stored in FIG.
  • the data accumulation unit 203 accumulates metrics and software quality data values 3 extracted from the source code 1 by the software quality measurement unit 2 each time the source code is revised.
  • the lifespan basis extraction unit 24 extracts the metrics and the software quality data values 3 as the basis for the quality of the lifespan 9 as the lifespan basis 25 .
  • the lifespan basis extraction unit 24 extracts the software quality data value 3 that is equal to or greater than a predetermined threshold and the metrics that are the calculation source thereof as the lifespan basis 25 that adversely affects the lifespan 9 .
  • the improvement item selection unit 26 selects part or all of the lifespan bases 25 that adversely affect the lifespan 9 .
  • the improvement item selection unit 26 selects part or all of the life expectancy basis 25 extracted by the life expectancy basis extraction unit 24 .
  • the improved life expectancy simulation unit 27 estimates an improved life expectancy 28 based on the development trend approximation formula 7 calculated from the diagnostic age 5 when the life expectancy basis 25 selected by the improvement item selection unit 26 is improved. That is, the improved life expectancy simulation unit 27 simulates how much the life expectancy 9 is improved when the life expectancy basis 25 selected by the improvement item selection unit 26 is improved.
  • the improvement item selection unit 26 selects one lifespan basis 25 that has the greatest adverse effect on the lifespan 9 as the lifespan basis 25 to be improved, but it is not limited to this.
  • a plurality or all of the longevity grounds 25 that have the greatest adverse effect on the longevity 9 may be selected, automatically selected by the device, or selected by the user through the input unit 201 .
  • the degree of improvement may also be selected in the same way.
  • a case will be described in which the life 9 when one life base 25 is improved by 100% and eliminated is simulated as an improved life 28, but the life 9 when a part of it is improved can also be simulated as an improved life 28.
  • the result can be taken over and the degree of improvement of another life basis 25 can be simulated together, or the improvement degree of the other life basis 25 can be simulated separately without taking over the result.
  • processing is performed during the lifetime of the entire software, that is, during the lifetime 9 of the entire source code.
  • the source code may be divided into predetermined units, and the same processing as described below may be performed during the estimated lifetime 9 for each unit.
  • FIG. 31 is a diagram showing an example of metrics for each revision.
  • Fig. 32 shows the software quality data values that serve as the basis for the lifetime of Revision-2.
  • the lifetime basis extraction unit 24 extracts one software quality data value that has the highest value and has the worst effect on the lifetime, and the metrics that are the calculation source of the one software quality data value, as one lifetime basis.
  • the lifetime grounds extraction unit 24 determines that the software quality data value and metrics of "the number of functions with the number of lines per function exceeding the reference value" have the worst impact on the lifetime and extracts them as one lifetime grounds.
  • lifespan basis extraction unit 24 can also extract multiple software quality data values and metrics that adversely affect the lifespan.
  • service life basis extraction unit 24 can also extract one or a plurality of software quality data values and metrics that have a positive effect on service life, and present them as a model case for implementation.
  • the improvement item selection unit 26 selects the lifespan basis to be improved from the lifespan basis extracted by the lifespan basis extraction unit 24 .
  • the improvement item selection unit 26 selects the one lifespan basis as it is.
  • one or more longevity basis may be selected from the plurality of longevity basis by the improvement item selection unit 26 or the user.
  • the improvement item selection unit 26 may select one or more lifespan grounds from the plurality of lifespan grounds extracted by the lifespan grounds extraction unit 24 based on the software quality data value.
  • the improved lifespan simulation unit 27 improves the lifespan basis selected by the improvement item selection unit 26 .
  • the improved lifespan simulation unit 27 adds simulated metrics such that the software quality data value of "the number of functions whose number of lines per function exceeds the reference value" becomes 0, that is, improves it by 100%, as shown in FIG. 31 to revision-3.
  • Such a simulated metric can be obtained, for example, by solving an optimum problem with each numerical value of the metric as a variable so that the value of the formula (1) becomes 0, or the like.
  • 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.
  • FIG. 33 is a diagram showing an example of software quality data values, specifically software quality data values of revision-3. Reflecting the simulated metrics, the software quality data value of "the number of functions in which the number of lines per function exceeds the reference value" is 0.
  • the improved life simulation unit 27 created 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. Further, the value after improvement and the degree of improvement may be specified by the device, or may be specified by the user through the input unit 201 .
  • the age diagnosis unit 4 calculates the diagnostic age based on the software quality data values measured by the software quality measurement unit 2, as in the first embodiment.
  • the age diagnosing section 4 calculates 33.06 as the diagnostic age of Revision-3 and stores it in the data storage section 203 .
  • the data accumulation unit 203 accumulates the diagnostic age for each revision.
  • the improved life expectancy simulation unit 27 estimates the improved life expectancy based on the development trend approximation formula, similar to the life expectancy estimation performed by the life expectancy estimation unit 8 .
  • the output unit 204 in FIG. 30 outputs the improved life 28. Further, 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 life expectancy basis 25, the improved simulation metrics, the software quality data value 3, the diagnosis age 5, the development trend approximation formula 7, and the diagnosis age accumulated in the data accumulation unit 203.
  • the data storage unit 203 may store various information.
  • the data accumulation unit 203 may accumulate source code 1, software quality data value 3, diagnosis age 5, development trend approximation formula 7, life expectancy basis 25, improved simulation metrics, software quality data value 3, diagnosis age 5, and development trend approximation formula 7.
  • an improved life expectancy 28 when part or all of the life expectancy basis 25 that adversely affects the life expectancy 9 is improved.
  • 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 “acquisition unit etc.”.
  • acquisition unit etc. The acquisition unit and the like are realized by the processing circuit 81 shown in FIG.
  • the processing circuit 81 includes an acquisition unit that acquires the source code, a software quality measurement unit that measures the 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 expression calculation unit that calculates the development trend approximation expression based on the diagnosis age accumulated for each revision in the data accumulation unit, and a life expectancy estimation unit that estimates the life span based on the development trend approximation expression.
  • Dedicated hardware may be applied to the processing circuit 81, or a processor that executes a program stored in a memory may be applied.
  • Processors include, for example, central processing units, processing units, arithmetic units, microprocessors, microcomputers, and DSPs (Digital Signal Processors).
  • the processing circuit 81 is dedicated hardware, the processing circuit 81 is, 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 thereof.
  • Each function of each unit such as the acquisition unit may be realized by a circuit in which processing circuits are distributed, or the functions of each unit may be collectively realized by one processing circuit.
  • the processing circuit 81 When the processing circuit 81 is a processor, the functions of the acquisition unit and the like are realized by combining with software and the like.
  • Software and the like correspond to, for example, software, firmware, or software and firmware.
  • Software or the like is written as a program and stored in memory.
  • a processor 82 applied to a processing circuit 81 reads out and executes a program stored in a memory 83 to realize the function of each section.
  • the steps of obtaining the source code, measuring the software quality data value based on the source code, calculating the diagnosis age of the source code based on the software quality data value, storing the diagnosis age in the data storage unit for each revision of the source code, calculating the development trend approximation formula based on the diagnosis age stored in the data storage unit for each revision, and estimating the life span based on the development trend approximation formula are executed as a result.
  • a memory 83 is provided for storing the program to be executed. In other words, the program can be said to cause the computer to execute the procedures and methods of the acquisition unit and the like.
  • the memory 83 is, for example, RAM (Random Access Memory), ROM (Read Only Memory), flash memory, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), non-volatile or volatile semiconductor memory, HDD (Hard Disk Drive), magnetic disk, flexible disk, optical disk, compact disk, mini disk, DVD (Digital Versatile Disc), or any storage medium that will be used in the future.
  • each function of the acquisition unit, etc. is realized by either hardware or software.
  • the configuration is not limited to this, and a configuration in which a part of the acquisition unit and the like is realized by dedicated hardware and another part is realized by software and the like may be used.
  • the functions of the acquisition unit can be realized by a processing circuit 81 as dedicated hardware, an interface, a receiver, and the like, and other functions can be realized by having the processing circuit 81 as a processor 82 read and execute a program stored in a memory 83.
  • the processing circuit 81 can implement each of the functions described above by means of hardware, software, etc., or a combination thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)
PCT/JP2022/031302 2022-01-18 2022-08-19 アーキテクチャ寿命推定装置及びアーキテクチャ寿命推定方法 Ceased WO2023139822A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US18/728,320 US20250103327A1 (en) 2022-01-18 2022-08-19 Architecture lifetime estimation apparatus and method of estimating architecture lifetime
JP2023575049A JP7621522B2 (ja) 2022-01-18 2022-08-19 アーキテクチャ寿命推定装置及びアーキテクチャ寿命推定方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-005836 2022-01-18
JP2022005836 2022-01-18

Publications (1)

Publication Number Publication Date
WO2023139822A1 true WO2023139822A1 (ja) 2023-07-27

Family

ID=87348502

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/031302 Ceased WO2023139822A1 (ja) 2022-01-18 2022-08-19 アーキテクチャ寿命推定装置及びアーキテクチャ寿命推定方法

Country Status (3)

Country Link
US (1) US20250103327A1 (https=)
JP (1) JP7621522B2 (https=)
WO (1) WO2023139822A1 (https=)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002055815A (ja) * 2000-08-08 2002-02-20 Fujitsu Ltd ソフトウェア開発支援装置、および記録媒体
JP2014241021A (ja) * 2013-06-11 2014-12-25 株式会社日立製作所 ソフトウェア評価装置および方法
WO2021079496A1 (ja) * 2019-10-25 2021-04-29 日本電気株式会社 評価装置、評価方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002055815A (ja) * 2000-08-08 2002-02-20 Fujitsu Ltd ソフトウェア開発支援装置、および記録媒体
JP2014241021A (ja) * 2013-06-11 2014-12-25 株式会社日立製作所 ソフトウェア評価装置および方法
WO2021079496A1 (ja) * 2019-10-25 2021-04-29 日本電気株式会社 評価装置、評価方法及びプログラム

Also Published As

Publication number Publication date
US20250103327A1 (en) 2025-03-27
JP7621522B2 (ja) 2025-01-24
JPWO2023139822A1 (https=) 2023-07-27

Similar Documents

Publication Publication Date Title
US8707268B2 (en) Testing operations of software
US9311223B2 (en) Prioritizing test cases using multiple variables
Schneidewind Body of knowledge for software quality measurement
US8386851B2 (en) Functional coverage using combinatorial test design
US20160246287A1 (en) Probabilistic evaluation of turbomachinery design to predict high cycle fatigue failure
US8397104B2 (en) Creation of test plans
US20140365990A1 (en) Software evaluation device and method
US8397187B2 (en) Verifying the error bound of numerical computation implemented in computer systems
US20150025872A1 (en) System, method, and apparatus for modeling project reliability
CN111026433A (zh) 基于代码变更历史的软件代码质量问题自动修复方法、系统及介质
US20080307387A1 (en) Software development apparatus and method for providing performance prediction
US20050204241A1 (en) Method and device for analyzing software error
US20220358269A1 (en) Simulation execution system, simulation execution method, and computer readable medium
CN119690512A (zh) 一种基于大模型的代码缺陷检测方法及系统
CN119179642A (zh) 一种代码测试方法、装置及电子设备
KR102461180B1 (ko) 소프트웨어 안전성 분석 방법 및 장치
JP7190246B2 (ja) ソフトウェア不具合予測装置
US20050229045A1 (en) Method and device for managing software error
WO2023139822A1 (ja) アーキテクチャ寿命推定装置及びアーキテクチャ寿命推定方法
US20200167152A1 (en) Identification of a partial code to be refactored within a source code
US6950781B2 (en) Method of calculating device metrics
JP6310865B2 (ja) ソースコード評価システム及び方法
JP2013045421A (ja) 保守度測定装置
CN115113920B (zh) 演化耦合关系抽取方法、系统、计算机设备及存储介质
JP6320269B2 (ja) ソフトウェア試験支援装置およびソフトウェア試験支援プログラム

Legal Events

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

Ref document number: 22921976

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023575049

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18728320

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22921976

Country of ref document: EP

Kind code of ref document: A1

WWP Wipo information: published in national office

Ref document number: 18728320

Country of ref document: US