Method for evaluating quality of aviation airborne software based on software whole life cycle

Abstract

The application provides an aviation airborne software quality evaluation method based on a software whole life cycle, which comprises the following steps: S1, establishing an aviation airborne software development process evaluation model; S2, establishing an aviation airborne software product evaluation model; S3, determining a metric element index selection principle; S4, metric element data collection; S5, aviation airborne software quality evaluation calculation, calculating the index values at all levels according to the steps, and completing the software quality evaluation. The application provides an aviation airborne software quality evaluation method based on a software whole life cycle, which is aimed at the deficiency that metric element data is not easy to obtain when evaluating the aviation airborne software quality, analyzes the existing software quality evaluation metric elements, and proposes engineering implementable and data easy to collect metric element indexes. Moreover, based on the collection of the metric element indexes, the influence factors of aviation airborne software development process evaluation and software product evaluation can be fully integrated, so that the software whole life cycle evaluation is realized.

Description

Technical Field

[0001] This invention relates to the field of airborne software products, and more specifically to a method for evaluating the quality of airborne software based on the entire software lifecycle. Background Technology

[0002] The development of computer technology has brought about changes in all walks of life, with previously mechanical weaponry gradually evolving towards electronic and intelligent systems. As the requirements and levels of informatization continue to increase, software is gradually replacing many functions originally implemented by hardware, making its proportion, role, and status increasingly important. However, software quality issues frequently lead to accidents, resulting in casualties and significant economic losses. Therefore, high-quality software is a crucial factor in ensuring that equipment systems fulfill their mission functions, execute combat and support tasks according to regulations, and is also a vital factor in ensuring personnel safety and minimizing economic losses. As an important component of airborne products, airborne software requires quality evaluation during its operation.

[0003] Existing airborne software quality evaluation technologies have some problems in their implementation, mainly including the following three aspects:

[0004] 1) Airborne software quality evaluation does not consider the quality of the software development process: The quality of the airborne software development process is the key to the quality of airborne software. The improvement of airborne software quality is the result of the combined effect of various quality activities in the software development process. However, the existing airborne software quality evaluation process is based on the airborne software product itself. Most airborne software quality evaluation systems do not consider the impact of the airborne software development process on the quality of airborne software, and therefore cannot comprehensively and accurately reflect the quality of airborne software.

[0005] 2) Metric metadata is not easy to obtain: Some metrics in existing airborne software quality evaluation technologies are too theoretical and their definitions are too abstract, making it difficult to operate and implement airborne software quality evaluation in actual engineering applications;

[0006] 3) Inconsistent measurement standards and non-standard evaluation criteria: Existing airborne software quality evaluation models include both qualitative and quantitative metrics. Qualitative metrics rely heavily on subjective human perception and lack objective standards for measurement. Quantitative metrics have inconsistent granularity, resulting in a lack of unified standards for evaluation results. Summary of the Invention

[0007] To address the shortcomings of the existing technologies, this invention proposes a method for evaluating the quality of airborne software based on the entire software lifecycle. This method can fully integrate the influencing factors of both software development process evaluation and software product evaluation, thereby achieving full lifecycle evaluation of software.

[0008] Specifically, this invention provides a method for evaluating the quality of airborne software based on the entire software lifecycle, which includes the following steps:

[0009] S1. Establish an evaluation model for the development process of airborne software. The evaluation model includes primary indicators, secondary indicators, and metric indicators. Define the primary indicators, secondary indicators, and metric indicators of the software development process evaluation model. Establish the mapping relationship between secondary indicators and metric indicators to construct the software development process evaluation model. Based on the different degrees of influence of each metric in the software development process evaluation model on software quality evaluation, divide the metric indicators in the software development process into three categories: compliance items, indicator items, and reference items.

[0010] S2. Establish an evaluation model for airborne software products. The software product evaluation model includes primary indicators, secondary indicators, and metric indicators. Define the primary indicators, secondary indicators, and metric indicators of the software product evaluation model, establish the mapping relationship between secondary indicators and metric indicators, and construct the software product evaluation model. Based on the different degrees of influence of each metric in the software product evaluation model on the software quality evaluation, divide the software product metric indicators into three categories: compliance items, indicator items, and reference items.

[0011] S3. Determine the selection principles for metrics. The specific selection principles include the following four methods: determining based on software importance level, determining based on software development stage, determining based on software type, and determining based on software characteristics.

[0012] S4. Measurement metadata collection: Collect relevant parameter information according to the calculation formula of the measurement index;

[0013] S5. Airborne Software Quality Evaluation Calculation: The software quality evaluation calculation adopts a bottom-up approach, calculating each level of indicators layer by layer. The calculation order is as follows: metric indicator calculation, secondary software indicator calculation, and primary software indicator calculation. Then, based on the calculated indicators at each level, the software development process quality calculation and software product quality calculation are performed respectively. The average value of the metric indicators, the secondary indicator evaluation value, and the primary indicator evaluation value of the software comprehensive quality evaluation result and the software product evaluation result are calculated according to the following sub-steps:

[0014] S51. Calculate the evaluation value of the metric: Calculate the evaluation value of the metric according to the metric calculation formula;

[0015] S52. Calculate the evaluation value of the secondary indicator: Calculate the evaluation value of the secondary indicator according to the following formula (1):

[0016]

[0017] Where n is the number of metrics included in a certain software secondary indicator, V mi The evaluation value for the secondary indicator; v i w is the evaluation value of the i-th quality metric; i Let α be the weight of the i-th quality metric, and let α be the influence coefficient of the compliance item. The value of α is defined based on whether there are any metrics in the compliance items included in the secondary indicators that do not meet the threshold.

[0018] S53. Calculate the evaluation value of the primary indicator: Calculate the evaluation value of the primary indicator according to the following formula (2):

[0019]

[0020] Where m is the number of secondary indicators included in a certain primary indicator of software, and V nj V is the evaluation value of the primary indicator. mi W is the evaluation value of the i-th secondary indicator; i Let be the weight of the i-th secondary indicator;

[0021] S6. Calculate the evaluation value of the airborne software development process: Calculate the evaluation value of the software development process according to the following formula (3):

[0022]

[0023] Where p represents the number of primary indicators included in the quality evaluation of a software development process, and V1 represents the quality evaluation value of that software development process; V nj W is the evaluation value of the j-th primary indicator; j Let be the weight of the j-th primary indicator;

[0024] S7. Calculate the evaluation results of airborne software products: Calculate the evaluation results of software products according to the following formula (4):

[0025]

[0026] Where q represents the number of primary indicators included in a software product evaluation, and V2 represents the evaluation value of that software product; V nj W is the evaluation value of the j-th primary indicator; j Let be the weight of the j-th primary indicator;

[0027] S8. Calculate the overall quality evaluation result of the airborne software: Calculate the overall quality evaluation result of the software according to the following formula (5):

[0028]

[0029] Wherein, V represents the overall quality evaluation result of the software, V1 represents the quality evaluation value of the software development process, V2 represents the evaluation value of the software product, W1 represents the weight of the quality evaluation value of the software development process, and W2 represents the weight of the evaluation value of the software product.

[0030] Preferably, the value of α is in the range of 0-1.

[0031] Preferably, in step S1, the "compliance item" refers to a metric that is a necessary condition for the software, the "indicator item" refers to a metric that is a condition required by the software, and the "reference item" refers to a metric that has a relatively weak impact on the software quality; in step S2, the "compliance item" refers to a metric that is a necessary condition for the software, the "indicator item" refers to a metric that is a condition required by the software, and the "reference item" refers to a metric that has a relatively weak impact on the software quality; wherein, both the compliance item and the indicator item participate in the calculation of the software quality evaluation result.

[0032] Preferably, step S3 specifically includes the following sub-steps:

[0033] S31. Determine based on software importance level: If the software importance level is A or B, select the software failure risk analysis report preparation status and software failure risk analysis report standard compliance as the metric indicators.

[0034] S32. Based on the software development stage: Select the relevant metrics in the development process. If the stage is a third-party stage, select the completion status of third-party testing and the status of resolving third-party issues as metrics. If the stage is a delivery stage, select the status of resolving issues before delivery and the status of the delivered software product as metrics. If the stage is an evaluation and finalization stage, select the completion status of evaluation and assessment and the status of resolving evaluation and assessment issues as metrics.

[0035] S33. Determine based on software type: If the software has a human-computer interaction interface, select the software user manual compilation status and software user manual standard compliance as the metrics.

[0036] S34. Based on software characteristics: If the software level is system-level software, then the following metrics are selected: system / subsystem specification preparation status, system / subsystem specification release status, system / subsystem specification delivery status, system / subsystem design specification preparation status, system / subsystem design specification release status, system / subsystem design specification delivery status, software system test plan preparation status, software system test plan release status, software system test plan delivery status, software system test description preparation status, software system test description release status, software system test description delivery status, software system test report preparation status, software system test report release status, software system test report delivery status, system test case density, system / subsystem specification standard compliance, system / subsystem design specification standard compliance, software system test plan standard compliance, software system test description standard compliance, and software system test report standard compliance.

[0037] Preferably, the method for collecting metrics in step S4 is as follows: the measured values ​​of metrics are manually acquired during the software development process and the software product evaluation process. The method for calculating metrics is as follows: when calculating the evaluation results of secondary indicators, the measured values ​​of all metrics involved in the calculation are normalized. After normalization, the evaluation value range of each metric is [0,1] or (0,1], and the evaluation value is better when it is closer to 1.

[0038] Preferably, based on the specific software type and requirements, a threshold for the software comprehensive quality evaluation result is determined. The difference between the calculated software comprehensive quality evaluation result and the threshold is calculated, and the calculation result is judged from 0 to 1 as excellent, good, qualified, and unqualified.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] (1) In view of the shortcomings of existing airborne software quality evaluation technology that does not take into account the current status of airborne software development process, this invention proposes an airborne software quality evaluation method based on the entire software life cycle. In the evaluation process, the influencing factors of airborne software development process evaluation and airborne software product evaluation are fully integrated, thereby realizing the evaluation of the entire life cycle of airborne software, and the evaluation results are accurate and reliable.

[0041] (2) In view of the shortcomings of the difficulty in obtaining the metric metadata, this invention proposes a metric index that is feasible in engineering and easy to collect data based on the analysis of existing airborne software quality evaluation metrics. Thus, the use of metric indexes to evaluate the quality of airborne software becomes an feasible method.

[0042] (3) In view of the shortcomings of inconsistent measurement standards and non-standard evaluation criteria, this invention proposes a reasonable division of measurement elements that can objectively reflect the quality of airborne software, establishes a unified and standardized evaluation criterion for airborne software quality, and thus constructs an airborne software quality evaluation model to carry out software quality evaluation, providing a new approach for airborne software quality evaluation. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of the workflow of the present invention;

[0044] Figure 2 This is a schematic diagram of the process for evaluating the quality of airborne software based on the entire software lifecycle.

[0045] Figure 3 This is a schematic diagram of the interface relationship for the electromechanical parameter display. Detailed Implementation

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

[0047] This invention provides a method for evaluating the quality of airborne software based on the entire software lifecycle, which can be applied to the evaluation of the quality of airborne software, such as... Figure 1 and Figure 2 As shown, it includes the following steps:

[0048] Step S1: Establish an evaluation model for the development process of airborne software. The software development process evaluation model includes primary indicators, secondary indicators, and metric indicators. Each level of indicator for evaluating the software development process is defined, and the mapping relationship between each level of indicator is established, thereby constructing the software development process evaluation model.

[0049] Specifically, it includes the following sub-steps:

[0050] Step S11: Define the primary indicators of the evaluation model for the airborne software development process. The primary indicators describe the activity categories in the software development process. Referring to the practice domain categories in the GJB5000B military software capability maturity model, the quality of the software development process evaluation is divided into three primary indicators: organizational management, engineering, and support.

[0051] Step S12: Define the secondary indicators of the evaluation model for the airborne software development process. Secondary indicators describe more detailed activity information within the primary indicator activity categories of the software development process. Six practice domains specified in GJB5000B are selected as secondary indicators, and a mapping relationship between primary and secondary indicators is established. Among them, project management secondary indicators include project monitoring; engineering secondary indicators include requirements development and management, technical solutions, and verification and validation; and support secondary indicators include configuration management and quality assurance.

[0052] Step S13: Define the metrics for the evaluation model of airborne software development process. Considering the influencing factors of software development process evaluation, and referring to standards GJB2786A, GJB8000, and GJB5000B, determine the monitoring metrics for the software development process based on the data generated during the software development process. By analyzing the meaning of the metrics in the software development process evaluation, their category range is given, and the mapping relationship between secondary indicators and metrics is established, thereby constructing the software development process evaluation model.

[0053] Step S14: Based on the different degrees of influence of each metric in the evaluation model of the development process of airborne software on the software quality evaluation, the software metrics are divided into three categories: compliance items, indicator items, and reference items.

[0054] 1) Compliance Item: This metric is a necessary condition for the software. When the measured value of this metric does not meet the requirements, it directly determines that the software does not meet the software quality requirements, and it participates in the calculation of the software quality evaluation results.

[0055] 2) Indicator Item: This metric is the condition required by the software and is used in the calculation of the quality evaluation results of airborne software.

[0056] 3) Reference Item: This metric has a relatively weak impact on software quality. The measured value of this metric is not included in the calculation of the software quality evaluation results; it only provides data reference for the quality evaluation work. The software development process evaluation model is shown in Table 1.

[0057] Table 1

[0058]

[0059] Step S2: Establish an evaluation model for airborne software products. The evaluation model includes primary indicators, secondary indicators, and metric indicators. Each level of indicator for evaluating airborne software products is defined, and the mapping relationship between these levels is established, thereby constructing the evaluation model for airborne software products.

[0060] Specifically, it includes the following sub-steps:

[0061] Step S21: Define the primary indicators for software product evaluation. Primary indicators describe the categories of activities in software product evaluation. Based on GJB5236 military software quality measurement, primary software indicators are divided into six categories: functionality, reliability, efficiency, maintainability, usability, and portability.

[0062] Step S22: Define secondary indicators for product evaluation. Secondary indicators describe more detailed activity information within the primary indicator activity categories of airborne software product evaluation. Referring to the quality model specified in GJB5236 standard, each primary indicator is further divided into software secondary indicators. Select software secondary indicators suitable for the characteristics of airborne software and establish a mapping relationship between primary and secondary indicators.

[0063] Step S23: Define the metrics for evaluating airborne software products. The evaluation system for airborne software products mainly considers extracting metrics that reflect the quality of airborne software products from software product documents that have undergone external review, forming a set of metrics for evaluating airborne software products. By analyzing the meaning of the metrics in the evaluation of airborne software products, defining their category range, and establishing the mapping relationship between secondary indicators and metrics, an evaluation model for airborne software products is constructed.

[0064] Step S24: Based on the different degrees of influence of each metric in the airborne software product evaluation model on the software quality evaluation, the airborne software metrics are divided into three categories: compliance items, indicator items, and reference items.

[0065] 1) Compliance Item: This metric is a necessary condition for airborne software. When the measured value of this metric does not meet the requirements, it directly determines that the airborne software has not met the software quality requirements, and it participates in the calculation of the airborne software quality evaluation results.

[0066] 2) Indicator Item: This metric is the condition required by airborne software and is used in the calculation of the airborne software quality evaluation results.

[0067] 3) Reference Item: This metric has a relatively weak impact on the quality of airborne software. The measured value of this metric is not included in the calculation of the airborne software quality evaluation results; it only provides data reference for the quality evaluation work. The airborne software product evaluation model is shown in Table 2.

[0068] Table 2

[0069]

[0070]

[0071] Step S3: Determine the selection principles for metrics. Metrics are selected based on software importance level, software development stage, software type, and software characteristics. This includes the following methods:

[0072] The importance level of the airborne software should be determined based on its classification. If the software importance level is A or B, metrics such as the status of software failure risk analysis report preparation and compliance with software failure risk analysis report standards should be selected.

[0073] Based on the development stage of the airborne software, select relevant metrics for the development process. If the stage is a third-party stage, indicators such as the completion status of third-party testing and the resolution of third-party issues should be selected. If the stage is the delivery stage, indicators such as the resolution of issues before delivery and the status of the delivered software product should be selected. If the stage is the evaluation and finalization stage, indicators such as the completion status of evaluation and assessment and the resolution of evaluation and assessment issues should be selected.

[0074] The selection should be based on the type of airborne software. If the software has a human-machine interface, metrics such as the software user manual compilation status and software user manual standard compliance should be selected.

[0075] The criteria are determined based on the characteristics of airborne software. If the software level is system-level software, the following metrics are selected: system / subsystem specification preparation status, system / subsystem specification release status, system / subsystem specification delivery status, system / subsystem design specification preparation status, system / subsystem design specification release status, system / subsystem design specification delivery status, software system test plan preparation status, software system test plan release status, software system test plan delivery status, software system test description preparation status, software system test description release status, software system test description delivery status, software system test report preparation status, software system test report release status, software system test report delivery status, system test case density, system / subsystem specification standard compliance, system / subsystem design specification standard compliance, software system test plan standard compliance, software system test description standard compliance, and software system test report standard compliance.

[0076] S4. Measurement Metadata Collection: Collect relevant parameter information based on the calculation formulas of the measurement metrics. Table 3 shows the calculation formulas for the evaluation metrics of the software development process, and Table 4 shows the calculation formulas for the evaluation metrics of the software product.

[0077] Table 3

[0078]

[0079]

[0080] Table 4

[0081]

[0082]

[0083] S5. Airborne Software Quality Evaluation Calculation: The software quality evaluation calculation adopts a bottom-up approach, calculating each level of indicators layer by layer. The calculation order is as follows: metric indicator calculation, secondary software indicator calculation, primary software indicator calculation, software development process quality calculation, software product quality calculation, and overall software quality calculation. Specifically, it includes the following sub-steps:

[0084] S51. Calculate the metric index: Calculate the evaluation value of the metric index according to the metric index calculation formula;

[0085] S52. Calculate the evaluation value of the secondary indicator: Calculate the evaluation value of the secondary indicator according to the following formula (1):

[0086]

[0087] Where n is the number of metrics included in a certain software secondary indicator, V mi The evaluation value for the secondary indicator; v i w is the evaluation value of the i-th quality metric; i Let α be the weight of the i-th quality metric, and let α be the influence coefficient of the compliance item. The value of α is defined based on whether there are any metrics in the compliance items included in the secondary indicators that do not meet the threshold.

[0088] S53. Calculate the evaluation value of the primary indicator: Calculate the evaluation value of the primary indicator according to the following formula (2):

[0089]

[0090] Where m is the number of secondary indicators included in a certain primary indicator of software, and V nj V is the evaluation value of the primary indicator. mi W is the evaluation value of the i-th secondary indicator; i Let be the weight of the i-th secondary indicator;

[0091] S54. Calculate the evaluation value of the airborne software development process: Calculate the evaluation value of the software development process according to the following formula (3):

[0092]

[0093] Where p represents the number of primary indicators included in the quality evaluation of a software development process, and V1 represents the quality evaluation value of that software development process; V nj W is the evaluation value of the j-th primary indicator; j Let be the weight of the j-th primary indicator;

[0094] S55. Calculate the evaluation results of airborne software products: Calculate the evaluation results of software products according to the following formula (4):

[0095]

[0096] Where q represents the number of primary indicators included in a software product evaluation, and V2 represents the evaluation value of that software product; V nj W is the evaluation value of the j-th primary indicator; j Let be the weight of the j-th primary indicator;

[0097] S56. Calculate the overall quality evaluation result of the airborne software: Calculate the overall quality evaluation result of the software according to the following formula (5):

[0098]

[0099] Wherein, V represents the overall quality evaluation result of the software, V1 represents the quality evaluation value of the software development process, V2 represents the evaluation value of the software product, W1 represents the weight of the quality evaluation value of the software development process, and W2 represents the weight of the evaluation value of the software product. Specific Implementation

[0101] The airborne electromechanical parameter display of a certain type of aircraft belongs to the electromechanical integrated management system. It displays the status parameters of systems such as flight control, power supply, fuel, hydraulics, transmission, propulsion, fire suppression, lubrication, anti-icing, and active vibration control, and issues control commands via peripheral buttons. The external interface block diagram of the electromechanical parameter display of this aircraft type is shown below. Figure 3 As shown, electromechanical parameter display software, as a common type of aviation equipment software, has the following characteristics: 1) It contains many subsystems, including power supply, fire protection, hydraulics, takeoff and speed brake devices, anti-icing, environmental control, fuel, braking, and emergency power systems; 2) It has diverse interface types, with a huge amount of input and output signals, resulting in a complex interface landscape. Interface types include ARINC429 bus, RS422A bus, discrete signals, LVDS, etc.; 3) It provides a graphical human-machine interface, facilitating pilots to issue control commands and view the status parameters of various systems.

[0102] The electromechanical parameter display software A and B for this aircraft model were selected through a competitive process by manufacturers A and B, respectively. Using the airborne software quality evaluation method based on the entire software lifecycle proposed in this paper, various data generated during the development of both software programs were calculated. Based on the constructed software quality evaluation model, the quality target scoring results at each layer of the software model were analyzed, and a comprehensive score for both products was finally given. This helps the overall model unit select the better product for installation on the aircraft. The following evaluation is conducted according to the airborne software quality evaluation method based on the entire software lifecycle proposed in this invention.

[0103] Based on the specific software type and requirements, a threshold for the overall software quality evaluation result is determined. The difference between the calculated overall software quality evaluation result and the threshold is calculated, and the result is graded from 0 to 1 as excellent, good, satisfactory, and unsatisfactory. The overall software quality evaluation results are shown in Table 5.

[0104] Table 5

[0105]

[0106] For the electromechanical parameter display software, the software type is electromechanical management and has a human-computer interaction interface. Therefore, the software has the characteristics of complex interface, human-computer interaction, high reliability and high security. The importance level is important. Based on the software type, software importance level and the characteristics of the software itself, the software life cycle quality evaluation model is determined as shown in Table 6.

[0107] Table 6

[0108]

[0109]

[0110] Based on the established life-cycle quality evaluation model for electromechanical parameter display software, the metric metadata in the model was collected and normalized. Based on previous model development experience, suggested weights for each level of indicators were given, and then the comprehensive quality evaluation value of the software was calculated. The evaluation results of each level of electromechanical parameter display software A are detailed in Table 7, and the evaluation results of each level of electromechanical parameter display software B are detailed in Table 8.

[0111] Table 7

[0112]

[0113]

[0114]

[0115]

[0116]

[0117]

[0118] Note: The weights are 1, 2, 3, and 4, with the following meanings: 1 indicates that the indicator is slightly important; 2 indicates that the indicator is generally important; 3 indicates that the indicator is very important; and 4 indicates that the indicator is extremely important.

[0119] Table 8

[0120]

[0121]

[0122]

[0123]

[0124]

[0125]

[0126] Note: The weights are 1, 2, 3, and 4, with the following meanings: 1 indicates that the indicator is slightly important; 2 indicates that the indicator is generally important; 3 indicates that the indicator is very important; and 4 indicates that the indicator is extremely important.

[0127] Based on the software lifecycle evaluation results, the airborne electromechanical parameter display software A developed by Research Unit A is rated "Excellent" (score of 0.9029), while the airborne electromechanical parameter display software B developed by Research Unit B is rated "Good" (score of 0.8431). Therefore, the software developed by Research Unit A performs better. For the sake of selection, the airborne electromechanical parameter display software A developed by Research Unit A is recommended.

[0128] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for evaluating the quality of airborne software based on the entire software lifecycle, characterized in that: By establishing metrics that reflect the quality of airborne software, airborne software quality evaluation criteria are created, and an airborne software quality evaluation model is constructed to conduct software quality evaluation. This process includes the following steps: S1. Establish an evaluation model for the development process of airborne software. This model includes primary indicators, secondary indicators, and metrics. The primary, secondary, and metric indicators of the software development process evaluation model are defined, and a mapping relationship between the secondary indicators and the metrics is established. Based on the varying degrees of influence of each metric on software quality evaluation, the metric indicators in the software development process are divided into three categories: compliance items, indicator items, and reference items. Primary indicators include management, engineering, and support categories. Secondary indicators in the management category include project monitoring; secondary indicators in the engineering category include requirements development and management, technical solutions, and verification and validation; and secondary indicators in the support category include configuration management and quality assurance. S2. Establish an evaluation model for airborne software products. The software product evaluation model includes primary indicators, secondary indicators, and metric indicators. Define the primary indicators, secondary indicators, and metric indicators of the software product evaluation model, establish the mapping relationship between secondary indicators and metric indicators, and construct the software product evaluation model. Based on the different degrees of influence of each metric in the software product evaluation model on the software quality evaluation, divide the software product metric indicators into three categories: compliance items, indicator items, and reference items. S2 specifically includes the following sub-steps: Step S21: Define the primary indicators for software product evaluation. The primary indicators describe the categories of activities in software product evaluation. According to GJB5236 Military Software Quality Measurement, the primary indicators for software are divided into 6 categories, namely functionality, reliability, efficiency, maintainability, usability, and portability. Step S22: Define secondary indicators for product evaluation. Secondary indicators describe more detailed activity information in the activity categories of primary indicators for airborne software product evaluation. Referring to the quality model specified in GJB5236 standard, each primary indicator is further divided into software secondary indicators. Select software secondary indicators that are suitable for the characteristics of airborne software and establish the mapping relationship between primary indicators and secondary indicators. Step S23: Define the evaluation metrics for airborne software products. The airborne software product evaluation system mainly considers extracting metrics that can reflect the quality of airborne software products from software product documents that have been reviewed by external review, forming a set of metrics for airborne software product evaluation; by analyzing the meaning of the metrics in the evaluation of airborne software products, giving their category range, and establishing the mapping relationship between secondary indicators and metrics, the airborne software product evaluation model is constructed. Step S24: Based on the different degrees of influence of each metric in the airborne software product evaluation model on the software quality evaluation, the airborne software metrics are divided into three categories: compliance items, indicator items, and reference items. S3. Determine the selection principles for metrics. Specific selection principles include the following four methods: determination based on software importance level, determination based on software development stage, determination based on software type, and determination based on software characteristics. Step S3 specifically includes the following sub-steps: S31. Determine based on software importance level: If the software importance level is A or B, select the software failure risk analysis report preparation status and software failure risk analysis report standard compliance as the metric indicators. S32. Based on the software development stage: Select the relevant metrics in the development process. If the stage is a third-party stage, select the completion status of third-party testing and the status of resolving third-party issues as metrics. If the stage is a delivery stage, select the status of resolving issues before delivery and the status of the delivered software product as metrics. If the stage is an evaluation and finalization stage, select the completion status of evaluation and assessment and the status of resolving evaluation and assessment issues as metrics. S33. Determine based on software type: If the software has a human-computer interaction interface, select the software user manual compilation status and software user manual standard compliance as the metrics. S34. Based on software characteristics: If the software level is system-level software, then the following metrics are selected: System / subsystem specification preparation status, System / subsystem specification release status, System / subsystem specification delivery status, System / subsystem design specification preparation status, System / subsystem design specification release status, System / subsystem design specification delivery status, Software system test plan preparation status, Software system test plan release status, Software system test plan delivery status, Software system test description preparation status, Software system test description release status, Software system test description delivery status, Software system test report preparation status, Software system test report release status, Software system test report delivery status, System test case density, System / subsystem specification standard compliance, System / subsystem design specification standard compliance, Software system test plan standard compliance, Software system test description standard compliance, and Software system test report standard compliance. S4. Measurement metadata collection: Collect relevant parameter information according to the calculation formula of the measurement index; S5. Airborne Software Quality Evaluation Calculation: The software quality evaluation calculation adopts a bottom-up approach, calculating each level of indicators layer by layer. The calculation order is as follows: metric indicator calculation, secondary software indicator calculation, and primary software indicator calculation. Then, based on the calculated indicators at each level, the software development process quality calculation and software product quality calculation are performed respectively. The average value of the metric indicators, the secondary indicator evaluation value, and the primary indicator evaluation value of the software comprehensive quality evaluation result and the software product evaluation result are calculated according to the following sub-steps: S51. Calculate the evaluation value of the metric: Calculate the evaluation value of the metric according to the metric calculation formula; S52. Calculate the evaluation value of the secondary indicator: Calculate the evaluation value of the secondary indicator according to the following formula (1): （1）； Where n represents the number of metrics included in a certain secondary software metric. The evaluation value for the secondary indicator; Let be the evaluation value of the i-th quality metric; The weight of the i-th quality metric is... The impact coefficient of the compliance item. The value is defined based on whether there are any metrics in the secondary indicators that do not meet the threshold. S53. Calculate the evaluation value of the primary indicator: Calculate the evaluation value of the primary indicator according to the following formula (2): （2）； Where m represents the number of secondary indicators contained in a certain primary indicator of software. The evaluation value for the primary indicator; Let be the evaluation value of the i-th secondary indicator; Let be the weight of the i-th secondary indicator; S6. Calculate the evaluation value of the airborne software development process: Calculate the evaluation value of the software development process according to the following formula (3): （3）； Where p represents the number of primary indicators included in the quality evaluation of a software development process. This is the quality evaluation value for the software development process; Let be the evaluation value of the j-th primary indicator; Let be the weight of the j-th primary indicator; S7. Calculate the evaluation results of airborne software products: Calculate the evaluation results of software products according to the following formula (4): （4）； Where q represents the number of primary indicators included in a software product evaluation. This is the evaluation value for the software product; Let be the evaluation value of the j-th primary indicator; Let be the weight of the j-th primary indicator; S8. Calculate the overall quality evaluation result of the airborne software: Calculate the overall quality evaluation result of the software according to the following formula (5): （5）； Where V represents the overall software quality evaluation result. This is the quality evaluation value for the software development process. This is the evaluation value for the software product. The weights for the quality evaluation values ​​of the software development process. The weighting of the software product's evaluation value; Standard Item: This metric is a necessary condition for the software. When the measured value of this metric does not meet the requirements, it directly determines that the software does not meet the software quality requirements, and it participates in the calculation of the software quality evaluation results. Indicator: This metric represents the conditions required by the software and is used in the calculation of the airborne software quality evaluation results. Reference item: This metric has a relatively weak impact on software quality. The measured value of this metric is not included in the calculation of the software quality evaluation results, but only provides data reference for the quality evaluation work.

2. The method for evaluating the quality of airborne software based on the entire software lifecycle as described in claim 1, characterized in that: The value range is 0-1.

3. The airborne software quality evaluation method based on the entire software lifecycle as described in claim 1, characterized in that: The specific method for collecting metrics in step S4 is as follows: the measured values ​​of metrics are manually acquired during the software development process and the software product evaluation process. The specific method for calculating metrics is as follows: when calculating the evaluation results of secondary indicators, the measured values ​​of all metrics involved in the calculation are normalized. After normalization, the evaluation value range of each metric is [0,1] or (0,1], and the evaluation value is closer to 1, which means the evaluation is better.

4. The method for evaluating the quality of airborne software based on the entire software lifecycle as described in claim 1, characterized in that: Based on the specific software type and requirements, determine the threshold for the comprehensive software quality evaluation result. Calculate the difference between the calculated comprehensive software quality evaluation result and the threshold, and then classify the result from 0 to 1 as excellent, good, qualified, or unqualified.

Images