An enterprise software system evaluation method and device based on a full link

Abstract

This invention discloses a method and apparatus for evaluating enterprise software systems based on the entire lifecycle, relating to the field of software evaluation technology. The method includes: first, acquiring enterprise software system construction requirements information to initially define key stages throughout the entire lifecycle; second, defining the core evaluation objectives and scope of each stage; identifying stages that generate chain reactions based on the objectives and scope, and constructing a stage synergy matrix; determining a synergy effect coefficient matrix accordingly, judging the gain impact of stage synergy on the entire lifecycle, and determining the sub-stage quality index; finally, combining the stage synergy matrix and the sub-stage quality index to perform a full-chain evaluation. The apparatus includes modules for acquiring requirements information and defining key stages, defining evaluation objectives and scope, identifying chain reaction stages and constructing a matrix, and executing the full-chain evaluation, achieving a comprehensive and accurate evaluation of the entire software system lifecycle and providing a basis for system optimization.

Description

Technical Field

[0001] This invention relates to the field of software evaluation technology, specifically to a method and apparatus for evaluating enterprise software systems based on the entire value chain. Background Technology

[0002] As enterprises deepen their digital transformation, software systems have become the core carriers supporting business operations. Their stability, efficiency, and collaboration throughout their entire lifecycle directly impact an enterprise's market competitiveness. Enterprise software systems typically encompass multiple stages, including requirements analysis, development, testing, deployment, and maintenance. These stages are highly interconnected, and a defect in any stage can propagate through the chain, causing a complete failure. Therefore, conducting a full-chain assessment of the software system to identify collaboration issues, pinpoint performance bottlenecks, and optimize resource allocation has become a critical requirement for ensuring the continuous and stable operation of enterprise businesses.

[0003] Existing enterprise software system evaluation methods and devices based on the entire value chain often focus on a single link during evaluation, ignoring the chain reaction between links. This makes it difficult to reflect the true quality of the entire value chain. At the same time, they lack quantitative synergy analysis, rely on subjective experience to evaluate the positive / negative impact between links, and lack accuracy. Furthermore, their evaluation scope is vaguely defined, which easily leads to duplication or omissions, resulting in limited guiding value for system optimization. Therefore, there is a need to provide an enterprise software system evaluation method and device based on the entire value chain to solve the above-mentioned problems. Summary of the Invention

[0004] To address the aforementioned technical problems, this paper provides a method and apparatus for evaluating enterprise software systems based on the entire value chain. This technical solution solves the problems of existing enterprise software system evaluation methods and apparatuses based on the entire value chain mentioned in the background art, which often focus on a single link during evaluation, ignoring the chain reaction between links, making it difficult to reflect the true quality of the entire value chain. At the same time, they lack quantitative synergy analysis, rely on subjective experience to evaluate the positive / negative impact between links, resulting in insufficient accuracy. Furthermore, their evaluation scope is vaguely defined, which easily leads to duplication or omission, resulting in limited guiding value of the evaluation results for system optimization.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A method for evaluating enterprise software systems based on the entire value chain includes:

[0007] Obtain information on the enterprise's software system construction requirements and initially draft the key stages of the software system's entire lifecycle;

[0008] Define the core evaluation objectives for each key stage of the software system's entire lifecycle, and simultaneously define the evaluation scope;

[0009] Based on the core assessment objectives and assessment scope of each key link, the key links that will cause chain reactions between links are identified, and a link synergy matrix is ​​constructed.

[0010] Based on the link coordination matrix, the coordination effect coefficient matrix is ​​determined. Simultaneously, based on the coordination effect coefficient matrix, it is determined whether the link coordination has a positive impact on the gain of the whole link, thereby determining the sub-link quality index of the software system.

[0011] Based on the link coordination matrix and the sub-link quality index of the software system, a full-link evaluation of the software system is conducted.

[0012] Furthermore, obtain information on the enterprise's software system construction requirements and initially define the key stages of the software system's entire lifecycle, specifically including:

[0013] The basic requirements for building the software system are obtained through internal enterprise research. These basic requirements include the enterprise's business objectives, business processes, data scale, number of users, and the status of the existing system. This information is then stored in a requirements information database.

[0014] The basic requirements information in the requirements information database is classified and filtered to identify the core requirements information that are directly related to the construction of the software system. The core requirements information includes business function requirements, performance requirements, security requirements, scalability requirements, and compliance requirements.

[0015] Based on core requirements information, we identified the key stages of the entire lifecycle of similar software systems in the industry and initially compiled a candidate list of key stages. The stages in the candidate list cover requirements analysis, system design, development and coding, testing and verification, deployment and implementation, operation and maintenance, iterative upgrades and retirement.

[0016] For each link in the candidate list of key links, a correlation analysis is performed to analyze the degree of correlation between each link and each requirement in the core requirement information. The correlation value between each link and the core requirement is calculated. The correlation value ranges from 0 to 1. The higher the correlation value, the closer the link is to the core requirement.

[0017] Set a correlation threshold, keep links with correlation values ​​greater than or equal to the threshold in the candidate list, and remove links with correlation values ​​less than the threshold to obtain a preliminary shortlist of key links;

[0018] The shortlist of key links is adjusted, necessary links that were omitted are added, and redundant or unreasonable links are deleted, forming a preliminary list of key links for the entire life cycle of the software system. This preliminary list of key links is then stored in the key link database.

[0019] Furthermore, define the core evaluation objectives for each key stage of the software system's entire lifecycle, and simultaneously define the evaluation scope, specifically including:

[0020] Retrieve a preliminary list of key lifecycle stages of the software system from the key stage database;

[0021] The functional points of each key link are obtained and classified according to different dimensions to obtain a set of functional points to be evaluated.

[0022] The ratio of the number of function points in the core requirements information to the total number of function points for each set of candidate evaluation function points is used as the evaluation index, and the set of candidate evaluation function points with the largest evaluation index is used as the core evaluation target.

[0023] Based on the core assessment objectives and indicators, the assessment scope of each key link is defined. The assessment scope includes the business process segments, data scope, participants, time span, and related system components involved in that link.

[0024] Define the boundaries of the assessment scope for each key step, clarify the boundaries between this step and other steps, and avoid overlapping or omissions in the assessment scope;

[0025] The core assessment objectives, assessment indicators, and assessment scope of each key link are compiled into an assessment objective and scope specification and stored in the assessment document database.

[0026] Furthermore, based on the core assessment objectives and scope of each key link, the critical links that will cause chain reactions between links are identified, and a link synergy matrix is ​​constructed, specifically including:

[0027] Obtain the core assessment objectives and scope for each key stage from the assessment document database;

[0028] Analyze the outputs of each key stage to determine the type, form, and function of each output; analyze the input requirements of each key stage to clarify the input content that each stage needs to obtain from other stages.

[0029] Based on the output and input requirements of each stage, determine whether there is a direct relationship between the stages. If the output of one stage is the input of another stage, then the two stages are directly related.

[0030] For directly related links, further analysis is needed to determine the extent to which a change in the quality of one link affects the other, in order to determine whether a chain reaction will occur.

[0031] Key links with chain reactions are marked as related link pairs, and the relationship between the two links in each related link pair and the direction of their influence are recorded.

[0032] Construct a process coordination matrix, where the rows and columns of the matrix are key processes. The elements in the matrix indicate whether there is a coordination relationship between the key processes in the corresponding row and the key processes in the corresponding column. If a coordination relationship exists, the element value is 1, otherwise it is 0. At the same time, the relationship and the direction of influence are marked next to the elements.

[0033] Furthermore, based on the link coordination matrix, a coordination effect coefficient matrix is ​​determined. Simultaneously, based on the coordination effect coefficient matrix, it is determined whether the link coordination has a positive impact on the overall link gain, thereby determining the sub-link quality index of the software system, specifically including:

[0034] Extract all pairs of links that have a collaborative relationship from the link collaboration matrix;

[0035] Obtain the synergy effect coefficient corresponding to each link with a synergy relationship. The synergy effect coefficient is used to measure the strength and direction of the synergy between the two links. A positive coefficient indicates positive synergy, a negative coefficient indicates negative synergy, and the larger the absolute value of the coefficient, the stronger the synergy.

[0036] Based on historical data, expert experience, and simulation test results, the synergy effect coefficient of each link pair is calculated. Historical data includes performance data of link synergy in similar software systems in the past, and simulation test results are data obtained by constructing a simulation environment to test the synergy effect of links.

[0037] Construct a synergy effect coefficient matrix, where the rows and columns of the matrix represent key links, and the elements in the matrix are the synergy effect coefficient values ​​of the corresponding link pairs. For link pairs that do not have a synergy relationship, the coefficient value is 0.

[0038] Based on the synergy effect coefficient matrix, calculate the sum of the synergy effect coefficients of all links in each sub-link. A sub-link is a local link in the whole link consisting of multiple interrelated key links.

[0039] Determine the sign of the sum of synergy effect coefficients. If the sum is positive, it indicates that the synergy of the links in this sub-link has a positive impact on the overall link gain. If the sum is negative, it indicates a negative impact.

[0040] The calculation rules for the sub-link quality index are set: when the sum of the synergy effect coefficients is positive, the sub-link quality index is positively correlated with the sum; when the sum is negative, the sub-link quality index is negatively correlated with the absolute value of the sum.

[0041] Obtain the quality index of each sub-link of the software system and store it in the sub-link quality database.

[0042] Furthermore, based on the link coordination matrix and the software system sub-link quality index, a full-link evaluation of the software system is conducted, specifically including:

[0043] Obtain the collaborative relationships and correlation directions between all key links from the link collaboration matrix, and clarify the connection methods of each link in the entire chain;

[0044] Retrieve the quality index of each sub-link from the sub-link quality database;

[0045] The structure of the entire link is determined based on the link coordination matrix, and the various sub-links are combined into a complete full-link model according to their coordination relationships.

[0046] Assign weights to the quality index of each sub-link;

[0047] The preliminary quality index of the entire link is calculated by weighted summation. The preliminary quality index is equal to the sum of the products of the quality indices of each sub-link and their corresponding weights.

[0048] The negative collaboration relationships existing in the collaboration matrix of the analysis links are analyzed, and the deduction index of negative collaboration on the quality of the entire link is calculated. The deduction index is determined based on the absolute value of the negative collaboration effect coefficient and the scope of influence.

[0049] Subtracting the deduction index from the preliminary quality index yields the final evaluation index for the entire software system chain.

[0050] Based on the final evaluation index, the quality of the entire software system is classified into levels, including excellent, good, qualified, and unqualified, and a full-link evaluation report is generated.

[0051] Furthermore, obtaining enterprise software system construction requirements and initially outlining the key stages of the software system's entire lifecycle also includes the following processing steps:

[0052] Standardize the acquired enterprise software system construction requirements information, and convert requirements information in different formats and expressions into a unified format;

[0053] Natural language processing technology is used to perform semantic analysis on the standardized demand information to extract key entities, attributes and relationships from the demand information.

[0054] Establish a network of connections for demand information, and connect the extracted key entities, attributes and relationships through network nodes and edges;

[0055] Redundancy analysis is performed on the network of demand information associations to identify and remove duplicate or redundant information in the network, thereby simplifying the demand information.

[0056] Perform a completeness check on the processed requirement information to check for any missing information. If any information is missing, return to the information acquisition stage to acquire it again.

[0057] The verified requirement information is version-marked, and the time, source, and personnel who processed the requirement information are recorded.

[0058] Based on the importance and frequency of change of the demand information, the demand information is classified and stored. The demand information with high importance and low change frequency is stored in the core database, and the rest is stored in the extended database.

[0059] The requirement information database is updated and maintained regularly. Based on changes in business operations and new requirements, the original requirement information is supplemented, modified, or deleted.

[0060] Furthermore, a full-link enterprise software system evaluation device is proposed to implement the evaluation method described above, characterized in that it includes:

[0061] The module for obtaining requirements information and defining key steps is used to obtain enterprise software system construction requirements information and initially define the key steps of the entire software system lifecycle.

[0062] The evaluation objectives and scope definition module is used to define the core evaluation objectives for each key stage of the software system's entire lifecycle, and simultaneously define the evaluation scope.

[0063] The Chain Reaction Link Identification and Matrix Construction Module is used to identify key links that will cause chain reactions between links based on the core evaluation objectives and evaluation scope of each key link, and to construct a link synergy matrix.

[0064] The end-to-end evaluation execution module is used to determine the synergy effect coefficient matrix based on the link synergy matrix, and simultaneously determine whether the link synergy has a positive impact on the end-to-end gain based on the synergy effect coefficient matrix, thereby determining the sub-link quality index of the software system; and to perform end-to-end evaluation of the software system based on the link synergy matrix and the sub-link quality index of the software system.

[0065] Furthermore, the module for demand information acquisition and key process definition includes:

[0066] The requirement information collection unit is used to comprehensively collect the requirement information for the construction of the software system through internal enterprise surveys, covering various basic information related to the enterprise's business, and providing raw data support for subsequent stages;

[0067] The requirement information processing unit is used to sort and filter the collected requirement information, extract the core content closely related to the construction of the software system, and ensure the effectiveness and relevance of the information.

[0068] The preliminary identification unit for key links is used to initially screen and propose key links based on the organized core requirements information and the general rules of the software system's entire life cycle, forming a list of key links and defining the basic scope for subsequent evaluation work.

[0069] Furthermore, the assessment objectives and scope definition module includes:

[0070] The process objective analysis unit is used to analyze and clarify the core evaluation objectives for each initially proposed key process, taking into account the overall requirements of the software system and the characteristics of each process, to ensure that the evaluation objectives match the functions of the process.

[0071] The assessment scope delineation unit is used to simultaneously define the assessment scope of each key link based on the core assessment objectives of each key link, clarify the specific content and boundaries involved in the assessment work, and avoid omissions or exceeding the scope of the assessment.

[0072] The Objectives and Scope Documentation Generation Unit is used to organize the core assessment objectives and corresponding assessment scope of each key stage into a standardized document, providing clear guidance for subsequent assessment stages.

[0073] Compared with the prior art, the beneficial effects of the present invention are:

[0074] This solution proposes a full-chain enterprise software system evaluation method. By acquiring enterprise software system construction requirements and identifying key lifecycle stages, and combining core requirements to select highly relevant stages, it achieves a precise match between the evaluation scope and the enterprise's actual needs. This ensures the evaluation focuses on the core chain and avoids wasting resources on redundant stages. By defining the core evaluation objectives and scope of each key stage, and clarifying the correspondence between stage functionalities and core requirements, it achieves quantification of evaluation objectives and clear boundary definition, providing a unified standard for subsequent stage collaborative analysis and reducing the subjectivity and ambiguity of the evaluation. Furthermore, by identifying chain reactions between stages and constructing a collaborative matrix, it quantitatively analyzes the pairings between stages. The synergy effect coefficient accurately depicts the positive / negative synergy relationships throughout the entire chain, intuitively presenting the interrelationships between links and providing data support for identifying bottlenecks across the entire chain. By calculating the sub-link quality index and the final evaluation index of the entire chain, combined with the negative synergy deduction mechanism, a comprehensive quantitative evaluation of the quality of the entire software system chain is achieved. The grading results can directly guide the system optimization priority, improving the stability and operational efficiency of enterprise software systems. By setting up standardized processing, version marking, and classified storage mechanisms for requirement information, standardized management and dynamic updates of requirement information are achieved, ensuring the timeliness and accuracy of evaluation data and providing a reliable foundation for continuous iteration of the entire chain evaluation. Attached Figure Description

[0075] Figure 1 This is a flowchart of an enterprise software system evaluation method based on the entire value chain proposed in this invention;

[0076] Figure 2 This is a flowchart illustrating the construction of the link coordination matrix in this invention;

[0077] Figure 3 This is a flowchart illustrating the process of obtaining the sub-link quality index of the software system in this invention.

[0078] Figure 4 This is a system framework diagram of an enterprise software system evaluation system based on the entire value chain proposed in this invention. Detailed Implementation

[0079] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.

[0080] Reference Figure 1 - Figure 4 As shown, an enterprise software system evaluation method based on the entire value chain includes:

[0081] Obtain information on the enterprise's software system construction requirements and initially draft the key stages of the software system's entire lifecycle;

[0082] Define the core evaluation objectives for each key stage of the software system's entire lifecycle, and simultaneously define the evaluation scope;

[0083] Based on the core assessment objectives and assessment scope of each key link, the key links that will cause chain reactions between links are identified, and a link synergy matrix is ​​constructed.

[0084] Based on the link coordination matrix, the coordination effect coefficient matrix is ​​determined. Simultaneously, based on the coordination effect coefficient matrix, it is determined whether the link coordination has a positive impact on the gain of the whole link, thereby determining the sub-link quality index of the software system.

[0085] Based on the link coordination matrix and the sub-link quality index of the software system, a full-link evaluation of the software system is conducted.

[0086] Furthermore, obtain information on the enterprise's software system construction requirements and initially define the key stages of the software system's entire lifecycle, specifically including:

[0087] The basic requirements for building the software system are obtained through internal enterprise research. These basic requirements include the enterprise's business objectives, business processes, data scale, number of users, and the status of the existing system. This information is then stored in a requirements information database.

[0088] The basic requirements information in the requirements information database is classified and filtered to identify the core requirements information that are directly related to the construction of the software system. The core requirements information includes business function requirements, performance requirements, security requirements, scalability requirements, and compliance requirements.

[0089] Based on core requirements information, we identified the key stages of the entire lifecycle of similar software systems in the industry and initially compiled a candidate list of key stages. The stages in the candidate list cover requirements analysis, system design, development and coding, testing and verification, deployment and implementation, operation and maintenance, iterative upgrades and retirement.

[0090] For each link in the candidate list of key links, a correlation analysis is performed to analyze the degree of correlation between each link and each requirement in the core requirement information. The correlation value between each link and the core requirement is calculated. The correlation value ranges from 0 to 1. The higher the correlation value, the closer the link is to the core requirement.

[0091] Set a correlation threshold, keep links with correlation values ​​greater than or equal to the threshold in the candidate list, and remove links with correlation values ​​less than the threshold to obtain a preliminary shortlist of key links;

[0092] The shortlist of key links is adjusted, necessary links that were omitted are added, and redundant or unreasonable links are deleted, forming a preliminary list of key links for the entire life cycle of the software system. This preliminary list of key links is then stored in the key link database.

[0093] Specifically, obtaining basic requirements for software system construction through internal enterprise research requires designing standardized questionnaires and conducting interviews with enterprise management, business unit heads, and IT operations personnel. For example, confirming "enterprise business goals" with management (e.g., "increasing transaction volume by 50% in the next 3 years"), outlining "business processes" with business personnel (e.g., "12 steps from order creation to shipment"), and compiling "existing system status" (e.g., number of servers, database types, historical fault records) with IT personnel. Collecting existing business manuals, process specifications, IT architecture diagrams, data reports, etc., and extracting quantitative information such as "data scale" (e.g., 100,000 daily orders, 5 million user data entries) and "number of users" (e.g., 2 million registered users, 300,000 daily active users). The existing system status should be assessed, such as whether manual intervention is required during peak order periods. Use relational databases (such as MySQL) or document-oriented databases (such as MongoDB) to store information, and create data tables according to "information type": Business target table (including target description, time node, responsible department); Business process table (including process ID, step description, involved systems, and time consumption); Data information table (including data type, magnitude, and growth trend); User information table (including user role, quantity, and operation frequency); Existing system table (including system name, function, deployment method, and defect records). The screening rule based on "software construction relevance" establishes screening dimensions and judgment criteria, retaining requirements directly related to the software system, including: business function requirements: screening content related to the core functions that the software must implement (e.g., "e-commerce systems must support coupon deductions"), excluding business strategies not supported by the software (e.g., "marketing promotion plans"); performance requirements: extracting requirements related to system response speed and concurrency capabilities (e.g., "page loading time ≤ 2 seconds" "supports 100,000 users online simultaneously"); security requirements: screening requirements such as data encryption, access control, and attack prevention (e.g., "user passwords must be stored encrypted" "payment information transmission requires SSL protocol"); scalability requirements: retaining content related to system expansion and function iteration (e.g., "supports expansion capability of 50% annual user growth"); compliance requirements: extracting industry regulations or corporate policies (e.g., "complies with GDPR data protection provisions" "financial data must be retained for 10 years"). The candidate list is presented in the format of "stage name - core task - output".

[0094] The correlation between each link and the core requirement is calculated using a "multi-factor weighted method". Step 1: Set weights for the five dimensions of the core requirement (e.g., business functionality 40%, performance 20%, security 15%, scalability 15%, compliance 10%).

[0095] Step 2: Assess the degree to which each step supports each dimension of demand (score on a scale of 0-1, with 1 indicating strong support).

[0096] Step 3: Calculate the weighted sum according to the weights, using the following formula:

[0097]

[0098] For example, if the "testing and verification phase" has a performance requirement support level of 0.9, a security requirement support level of 0.8, and other dimensions of 0.6, then the correlation value = 0.4×0.6+0.2×0.9+0.15×0.8+0.15×0.6+0.1×0.6=0.69.

[0099] The determination of the relevance threshold needs to be based on the "core requirement coverage" threshold: statistically analyze the relevance value distribution of all links (e.g., maximum value 0.9, minimum value 0.3, average value 0.6); with "covering 80% of core requirements" as the standard, set the threshold to be 10%-20% higher than the average value (e.g., 0.6×1.2=0.72) to ensure that links that strongly support core requirements are retained.

[0100] Next, remove links with a relevance value below the threshold (e.g., the "retirement and elimination" link with a relevance value of 0.5 can be temporarily excluded in small and medium-sized enterprises), and retain highly relevant links (e.g., requirements analysis, development coding, testing and verification) to form a preliminary shortlist. The adjustment rules based on "full lifecycle integrity" need to check whether the shortlist covers the complete link from "build to run": if a key link is missing (e.g., "deployment and implementation" is not included, causing a disconnect between development and operation), it still needs to be added even if the relevance value is slightly below the threshold; if there are redundant links (e.g., "requirements analysis" and "requirements review" functions overlap), they are merged into a single link (e.g., "requirements analysis and review").

[0101] Furthermore, define the core evaluation objectives for each key stage of the software system's entire lifecycle, and simultaneously define the evaluation scope, specifically including:

[0102] Retrieve a preliminary list of key lifecycle stages of the software system from the key stage database;

[0103] The functional points of each key link are obtained and classified according to different dimensions to obtain a set of functional points to be evaluated.

[0104] The ratio of the number of function points in the core requirements information to the total number of function points for each set of candidate evaluation function points is used as the evaluation index, and the set of candidate evaluation function points with the largest evaluation index is used as the core evaluation target.

[0105] Based on the core assessment objectives and indicators, the assessment scope of each key link is defined. The assessment scope includes the business process segments, data scope, participants, time span, and related system components involved in that link.

[0106] Define the boundaries of the assessment scope for each key step, clarify the boundaries between this step and other steps, and avoid overlapping or omissions in the assessment scope;

[0107] The core assessment objectives, assessment indicators, and assessment scope of each key link are compiled into an assessment objective and scope specification and stored in the assessment document database.

[0108] Specifically, the "List of Key Stages in the Entire Lifecycle of a Software System" is retrieved from the key stage database and presented in a structured table format. This list includes basic information such as stage ID, name, and core tasks (e.g., "Requirements Analysis," "System Design," "Development Coding," etc.). Database query tools (such as SQL) are used to filter valid stages, excluding records marked as "redundant" or "to be deleted," ensuring the retrieved list matches the initially planned results. For each key stage, functional points are extracted through "process decomposition + document analysis": the core tasks of each stage are broken down into specific operational steps; for example, the "testing and verification stage" can be broken down into functional points such as "functional test case design," "performance stress test execution," "security vulnerability scanning," and "regression test execution." Implicit functional points are extracted from stage outputs (such as design documents and operation manuals); for example, the "system design stage" needs to include functional points not explicitly stated in the core tasks, such as "interface compatibility design" and "data backup strategy design." A functional point list template is used to record these points, including fields such as "functional point ID, stage name, functional description, execution entity, and dependencies," ensuring no omissions. Classifying functional points according to different dimensions requires establishing multi-dimensional classification standards, such as classifying functional points according to three dimensions: "core requirement matching degree," "technical attributes," and "business relevance."

[0109] Core requirement dimensions: Five sub-items corresponding to core requirements (business functions, performance, security, scalability, and compliance), such as "data encryption function" belonging to "security requirement" and "concurrency stress testing" belonging to "performance requirement".

[0110] Technical attribute dimensions: divided into "design" (such as architecture design), "development" (such as code writing), "testing" (such as defect repair and verification), and "operation and maintenance" (such as system monitoring).

[0111] Business relevance dimension: Classified by business process module (such as "order management related functions" and "payment related functions"). Each function can be assigned to multiple dimensions. For example, "order data encrypted storage" belongs to both "security requirements" and "order management business".

[0112] The set of candidate evaluation features is formed by aggregating features along a single dimension, generating multiple sets of candidate features. For example, five sets are generated based on the core requirement dimension: business function requirement feature set, performance requirement feature set, security requirement feature set, scalability requirement feature set, and compliance requirement feature set. Each set clearly specifies the feature ID and quantity it contains. For example, the "security requirement feature set" contains three features: "data encryption, permission verification, and vulnerability scanning".

[0113] The quantitative calculation of the evaluation index involves calculating the "core requirement matching rate" as the evaluation index for each set of candidate evaluation function points. The formula is as follows:

[0114]

[0115] For example, the "performance requirement feature set" contains 5 feature points, of which "concurrency testing and response time monitoring" directly match the performance requirement of "supporting 100,000 users online at the same time" in the core requirements. Therefore, the evaluation index = 2 / 5 = 40%.

[0116] Compare the evaluation metrics of all candidate sets and select the set with the largest value as the core evaluation target for this stage: for example, in the "system design stage", the evaluation metric of the "scalability requirement function point set" is 60% (3 / 5), which is higher than other sets, so it is determined as the core evaluation target; if multiple sets have the same metric, a second screening is carried out in combination with the "weight of the impact of function points on business" (such as giving priority to the set containing "high priority function points").

[0117] The multi-dimensional definition of the assessment scope is based on the core assessment objectives and indicators, clarifying the specific scope of each key link: For business process segments, the business steps involved in the core assessment objectives are associated with them, such as the scope corresponding to the core assessment objectives of "security requirements" including the process segment of "user login → data transmission → storage encryption"; for data scope, the data types and quantities to be assessed are determined, such as "order data (100,000 records per day), user information (5 million records)"; for participating personnel, the roles that execute or are associated with the link need to be listed, such as the "testing and verification link" involving test engineers, development engineers, and business acceptance personnel; for time span, the start and end time nodes of the link need to be clearly defined, such as the "deployment and implementation link" from "1 working day after the test is passed" to "the end of the 72-hour monitoring period after the system goes live"; for related system components, including hardware (servers, network equipment), software (databases, middleware), tools (deployment scripts, monitoring platforms), etc., such as the "operation and maintenance link" involving "application servers, Prometheus monitoring system, log analysis tools".

[0118] The boundary confirmation mechanism uses the "link interface mapping method" to clearly define the boundaries with other links:

[0119] First, draw a boundary diagram of each stage, marking the "input interface" (such as documents and data received from upstream stages) and the "output interface" (deliverables to downstream stages). For example, the input of the "development and coding stage" is "system design documents," and the output is "testable source code." The boundary is from "design document received" to "source code submitted for testing." Then, organize the heads of adjacent stages (such as development and testing heads) to cross-review and confirm that there is no overlap in the boundaries (such as avoiding "defect fixing" from being included in both development and testing) or omissions (such as clarifying that "data migration verification" belongs to the deployment stage rather than the operation and maintenance stage).

[0120] The generation and storage of the assessment objectives and scope statement includes:

[0121] The standardized preparation of the instruction manual requires the use of a unified template to organize information, including the following core sections: basic information of the process (ID, name, core task); core evaluation objectives (candidate set name, evaluation indicator value, matching core requirements); evaluation scope details (specific description of business process segments, data, personnel, time, and system components); boundary description (interfaces and boundaries with upstream and downstream processes); and attachments (function point list, boundary diagram, approval records).

[0122] Document database storage and management: Store the manuals in a structured format (such as PDF+XML) in the evaluation document database, and set access permissions (e.g., developers can view the manual for the "development and coding phase", while testers can only view the manual for the "testing and verification phase"); link the key phase database with the evaluation document database, and enable cross-database queries through the phase ID (e.g., when querying the "deployment and implementation phase", the corresponding manual will be automatically retrieved) to ensure data consistency.

[0123] Furthermore, based on the core assessment objectives and scope of each key link, the critical links that will cause chain reactions between links are identified, and a link synergy matrix is ​​constructed, specifically including:

[0124] Obtain the core assessment objectives and scope for each key stage from the assessment document database;

[0125] Analyze the outputs of each key stage to determine the type, form, and function of each output; analyze the input requirements of each key stage to clarify the input content that each stage needs to obtain from other stages.

[0126] Based on the output and input requirements of each stage, determine whether there is a direct relationship between the stages. If the output of one stage is the input of another stage, then the two stages are directly related.

[0127] For directly related links, further analysis is needed to determine the extent to which a change in the quality of one link affects the other, in order to determine whether a chain reaction will occur.

[0128] Key links with chain reactions are marked as related link pairs, and the relationship between the two links in each related link pair and the direction of their influence are recorded.

[0129] Construct a process coordination matrix, where the rows and columns of the matrix are key processes. The elements in the matrix indicate whether there is a coordination relationship between the key processes in the corresponding row and the key processes in the corresponding column. If a coordination relationship exists, the element value is 1, otherwise it is 0. At the same time, the relationship and the direction of influence are marked next to the elements.

[0130] Specifically, this step first retrieves the "Assessment Objectives and Scope Specifications" for each key stage from the assessment document database using database queries (such as SQL). Core assessment objectives (e.g., "compliance rate of security requirement functional points") and assessment scope (e.g., involved business process segments, data scope, system components, etc.) are extracted by "stage ID". A document parsing tool (e.g., Python's PyPDF2 library) is used to extract the content of the structured specifications, converting it into analyzable fields. For example: Stage A: The core assessment objective is "business function requirement matching degree ≥ 90%", and the assessment scope includes "order creation process, user payment data, development engineers and test engineers, 3 days before deployment to 1 week after launch, and the order system server". The extracted core assessment objectives are compared with the previously defined core requirement information to verify whether there are any discrepancies (e.g., the assessment objective of a certain stage does not cover the corresponding core requirement). The completeness of the assessment scope is checked to ensure that no elements such as business process segments and participating personnel are missing for each stage. If any information is incomplete, the database is returned to retrieve the missing information. Based on the core assessment objectives and scope of each stage, and combined with its core tasks, the output deliverables are broken down into: 1. Type classification: divided into "documents" (such as requirements specifications, system design diagrams), "code" (such as source code, executable programs), "data" (such as test reports, log files), and "services" (such as deployed system environments, monitoring and alarm services); 2. Format definition: specifying the carrier of the output deliverables (such as paper documents, electronic files, database tables, API interfaces), for example, the output deliverable of the "development and coding stage" is "Java source code (electronic files) stored in a Git repository"; 3. Function description: explaining the purpose of the deliverables in relation to the core assessment objectives, such as the "defect list" output deliverable of the "testing and verification stage" being used to "support the development stage in fixing code vulnerabilities and ensuring that the system functions meet the standards." The final output deliverable list is formed, containing fields such as "stage ID, deliverable name, type, format, function, and deliverable object."

[0131] The process involves reverse engineering to derive the input content required from other stages for each step: extracting from the "dependent resources" within the evaluation scope, such as the "deployment and implementation stage" requiring a "test pass report" from the testing stage as a prerequisite; and deriving from the achievement conditions of the core evaluation objectives, such as the "system design stage" requiring a "requirements specification" from the requirements analysis stage to complete the architecture design. Clearly define the "source stage, form, and key information points" of the input content; for example, the input requirement for the "test verification stage" is "testable version code (Git branch tag v1.0) delivered by the development and coding stage, including interface documentation and unit test reports." A "Stage Input Requirements List" is then created and stored in association with the output deliverables list.

[0132] Establish an "output-input" mapping table to match the outputs of all stages with the input requirements of other stages: if the output of stage X (e.g., "requirements specification") perfectly matches the input requirements of stage Y (e.g., "requirements specification for system design"), then X and Y are directly related. For example, if the "requirements analysis stage" outputs "requirements specification" and the "system design stage" includes this specification as an input requirement, then the two stages are directly related. These relationships need to be visualized using a directed graph tool (e.g., Visio) to create a stage relationship diagram. Nodes represent stages, arrows indicate the direction of the relationship (from the output stage to the input stage), and the basis for the relationship is labeled (e.g., "output A of X is input B of Y").

[0133] The identification of chain reactions and the identification of related links include a quantitative analysis of the degree of quality impact. For link pairs (X→Y) with direct correlation, the probability of a chain reaction is assessed using an "impact factor": The impact factor is defined as (the probability that substandard quality in X leads to substandard quality in Y) × (the weight of the impact of substandard quality in Y on its core evaluation objective). The probability is calculated using historical data; for example, if "for every 10% increase in the defect rate in the requirements analysis stage, the defect rate in the system design stage increases by an average of 8%", then the probability is 0.8. The impact weight is set according to the importance of Y's core evaluation objective (e.g., 0.1-1.0). For example, if Y's core evaluation objective is "performance compliance" (weight 0.8), then the impact factor = 0.8 × 0.8 = 0.64. A threshold is set (e.g., 0.3). Link pairs with an impact factor ≥ the threshold are considered to have a chain reaction. Mark links with chain reactions as “related links” and record: type of relationship (e.g., “document dependency”, “code dependency”, “data dependency”); direction of influence (X→Y means X affects Y, Y→X means bidirectional influence, e.g., “bidirectional feedback exists between development and testing”); key points of influence (e.g., “document ambiguity of X will lead to design deviation of Y”).

[0134] The steps for constructing the process coordination matrix include:

[0135] The matrix dimension and element definition are based on a two-dimensional matrix constructed using the list of key steps as rows and columns, with a matrix dimension of N×N (N being the number of key steps). Matrix element value rules: if a row and column step have a synergistic relationship (i.e., a direct connection and a chain reaction), the element value is 1; otherwise, it is 0. The type of relationship and direction of influence are indicated next to the element; for example, the element corresponding to "(Requirements Analysis, System Design)" is labeled "Document Dependency, X→Y".

[0136] Furthermore, based on the link coordination matrix, a coordination effect coefficient matrix is ​​determined. Simultaneously, based on the coordination effect coefficient matrix, it is determined whether the link coordination has a positive impact on the overall link gain, thereby determining the sub-link quality index of the software system, specifically including:

[0137] Extract all pairs of links that have a collaborative relationship from the link collaboration matrix;

[0138] Obtain the synergy effect coefficient for each link with a synergistic relationship. The synergy effect coefficient is used to measure the strength and direction of the synergy between the two links. A positive coefficient indicates positive synergy, a negative coefficient indicates negative synergy, and the larger the absolute value of the coefficient, the stronger the synergy.

[0139] Based on historical data, expert experience, and simulation test results, the synergy effect coefficient of each link pair is calculated. Historical data includes performance data of link synergy in similar software systems in the past, and simulation test results are data obtained by constructing a simulation environment to test the synergy effect of links.

[0140] Construct a synergy effect coefficient matrix, where the rows and columns of the matrix represent key links, and the elements in the matrix are the synergy effect coefficient values ​​of the corresponding link pairs. For link pairs that do not have a synergy relationship, the coefficient value is 0.

[0141] Based on the synergy effect coefficient matrix, calculate the sum of the synergy effect coefficients of all links in each sub-link. A sub-link is a local link in the whole link consisting of multiple interrelated key links.

[0142] Determine the sign of the sum of synergy effect coefficients. If the sum is positive, it indicates that the synergy of the links in this sub-link has a positive impact on the overall link gain. If the sum is negative, it indicates a negative impact.

[0143] The calculation rules for the sub-link quality index are set: when the sum of the synergy effect coefficients is positive, the sub-link quality index is positively correlated with the sum; when the sum is negative, the sub-link quality index is negatively correlated with the absolute value of the sum.

[0144] Obtain the quality index of each sub-link of the software system and store it in the sub-link quality database.

[0145] Specifically, this step first filters cells with an element value of 1 from the stored process coordination matrix (representing a coordination relationship), extracts the corresponding row and column process names, and forms a list of "process pairs with coordination relationships". For example, if the element value of (requirements analysis, system design) in the matrix is ​​1, then this combination is a related process pair. Process pairs are categorized by "direction of influence," distinguishing between unidirectional relationships (e.g., X→Y) and bidirectional relationships (e.g., X↔Y, such as bidirectional feedback between development and testing), and the relationship type is recorded (e.g., document dependency, code dependency). Secondly, duplicate records are removed (e.g., if (X,Y) and (Y,X) are unidirectional, the original direction is retained; if bidirectional, the records are merged) to ensure that each process pair is unique. The process pairs are then checked to ensure they match the previously marked "related process pairs" (combinations with chain reactions). If inconsistencies are found, the process of constructing the process coordination matrix needs to be traced back to correct any incorrect relationships.

[0146] The acquisition and calculation of the synergy effect coefficient first requires extracting data on the synergy performance of similar software systems from the historical records of the enterprise's IT system. This includes data such as "the correlation between the defect rate in the requirements analysis stage and the defect rate in the system design stage" and "the impact of development stage delays on the testing stage cycle," quantifying these as historical impact values ​​between 0 and 1 (positive values ​​for positive impacts and negative values ​​for negative impacts). Next, 5-8 cross-domain experts (business, development, testing, and operations) score the synergy effect of each stage pair using a Likert scale (-5 to +5, where -5 indicates a very strong negative impact and +5 indicates a very strong positive impact). After removing extreme values, the average score is taken and then normalized to the range of -1 to 1 (formula: normalized value = average expert score / 5). Finally, a simulation environment is built (e.g., simulating the entire link through a business process engine), the quality of a certain link is manually adjusted (e.g., reducing the completeness of the requirements analysis document to 70%), the quality changes of related links are observed (e.g., the deviation rate of the scheme in the system design link increases to 20%), and the impact ratio is calculated (e.g., the change in deviation rate / the amount of quality adjustment) as the simulation test value (range -1 to 1).

[0147] The weighted calculation of the synergy effect coefficient first sets the weights for historical data, expert experience, and simulation tests (e.g., 0.4, 0.3, and 0.3 respectively, summing to 1), and calculates the coefficient value using the following formula: Synergy Effect Coefficient = 0.4 × Historical Impact Value + 0.3 × Expert Normalized Value + 0.3 × Simulation Test Value. For example, if the historical impact value of the process (requirements analysis → system design) is 0.6 (positive), the expert normalized value is 0.7, and the simulation test value is 0.5, then the coefficient = 0.4 × 0.6 + 0.3 × 0.7 + 0.3 × 0.5 = 0.54 (positive synergy, moderate strength).

[0148] The synergy effect coefficient matrix is ​​constructed by first creating an N×N matrix (N being the number of key links) with key links as rows and columns, and the matrix elements correspond one-to-one with the link synergy matrix. For link pairs with synergistic relationships, the calculated synergy effect coefficients are entered; for link pairs without synergistic relationships (cells with an element value of 0), the coefficient value is uniformly set to 0. The direction of influence of the coefficients is marked (e.g., "+0.54 (X→Y)" indicates that X has a positive synergy with Y, "-0.32 (Y→X)" indicates that Y has a negative synergy with X). All the above matrices need to be verified and corrected, checking the symmetry of the matrix: whether the coefficients of bidirectional link pairs (X↔Y) are reasonable (e.g., X to Y = +0.6, Y to X = +0.5, which conforms to positive feedback logic); whether the coefficients of unidirectional link pairs in the non-linked direction are 0. The expert team reviews the reasonableness of the coefficients, and recalculates and corrects coefficients that deviate significantly from reality (e.g., logically should be positive but calculated as negative).

[0149] The rules for defining sub-links are based on the correlation relationship of the link collaboration matrix, dividing the entire link into multiple local sub-links: by business scenario (e.g., "requirements analysis → system design → development coding" is a "functional implementation sub-link", "testing and verification → deployment and implementation → operation and maintenance" is a "quality assurance sub-link"); by correlation strength: links that are continuously correlated and whose absolute value of the synergy effect coefficient is ≥0.3 are combined into sub-links (e.g., X→Y→Z, and XY coefficient 0.4, YZ coefficient 0.5, then the three constitute a sub-link).

[0150] The sum of the synergy coefficients of all links in each sub-link is obtained by summing the synergy coefficients of all links in each sub-link (e.g., sub-link X→Y→Z contains two links (X,Y) and (Y,Z)).

[0151]

[0152] Where n is the number of links contained in the sub-link. For example, if the sub-link (requirements → design → development) contains a (requirements, design) coefficient of 0.54 and a (design, development) coefficient of 0.6, then the sum = 0.54 + 0.6 = 1.14 (positive sum).

[0153] The determination and storage of sub-link quality indices require defining the calculation rules for the quality indices. First, an index mapping relationship is established: when the sum of sub-link coefficients is positive, the quality index = sum × 10 (positive amplification, facilitating grading), such as a sum of 1.14 corresponding to an index of 11.4; when the sum is negative, the quality index = 10 - (|sum| × 10) (negative attenuation), such as a sum of -0.3 corresponding to an index of 10 - 3 = 7. The index range is limited to 0-10 (below 0 is counted as 0, above 10 as 10) for unified evaluation. The names, constituent links, sum of coefficients, and quality indices of each sub-link are compiled into a "Sub-link Quality Evaluation Table" and stored in the sub-link quality database. The database stores sub-links categorized by type (e.g., functional implementation, quality assurance), and supports queries by link, index range, and other conditions, providing data support for full-link evaluation.

[0154] Furthermore, based on the link coordination matrix and the software system sub-link quality index, a full-link evaluation of the software system is conducted, specifically including:

[0155] Obtain the collaborative relationships and correlation directions between all key links from the link collaboration matrix, and clarify the connection methods of each link in the entire chain;

[0156] Retrieve the quality index of each sub-link from the sub-link quality database;

[0157] The structure of the entire link is determined based on the link coordination matrix, and the various sub-links are combined into a complete full-link model according to their coordination relationships.

[0158] A weight is assigned to the quality index of each sub-link. The weight is determined according to the importance of the sub-link in the whole link. The higher the importance, the greater the weight. The total weight is 1.

[0159] The preliminary quality index of the entire link is calculated by weighted summation. The preliminary quality index is equal to the sum of the products of the quality indices of each sub-link and their corresponding weights.

[0160] The negative collaboration relationships existing in the collaboration matrix of the analysis links are analyzed, and the deduction index of negative collaboration on the quality of the entire link is calculated. The deduction index is determined based on the absolute value of the negative collaboration effect coefficient and the scope of influence.

[0161] Subtracting the deduction index from the preliminary quality index yields the final evaluation index for the entire software system chain.

[0162] Based on the final evaluation index, the quality of the entire software system is classified into levels, including excellent, good, qualified, and unqualified, and a full-link evaluation report is generated.

[0163] Specifically, this step first extracts all non-zero elements (indicating collaborative relationships) from the link collaboration matrix, and sorts out the upstream and downstream connections of each key link, including: 1. Clarifying the direction of the connection: using the "X→Y", "Y→X", or "X↔Y" annotations next to the matrix elements to determine the unidirectional impact (e.g., requirements analysis → system design) or bidirectional feedback (e.g., development coding ↔ testing verification); 2. Statistically calculating the strength of the connection: combining the collaboration effect coefficient matrix, recording the absolute value of the coefficient for each connection (e.g., the coefficient for "requirements analysis → system design" is +0.54, indicating moderate strength). This forms the "Full-Link Collaboration Relationship List," which includes fields such as "link pair, direction of connection, collaboration type (positive / negative), and strength level." This step also requires visualizing the connection methods, using flowchart tools (such as Visio and Lucidchart) to draw a full-link connection diagram: nodes represent key links, with node size according to the importance of the link (e.g., nodes related to core business are larger); arrows represent the direction of association, with the thickness of the arrow lines corresponding to the intensity of collaboration (the larger the absolute value of the coefficient, the thicker the line); different colors are used to mark the type of collaboration (blue represents positive collaboration, and red represents negative collaboration), intuitively presenting the connection logic of the entire link (such as the main link of "requirements → design → development → testing → deployment → operation and maintenance" and the branch associations between each link).

[0164] The retrieval of sub-link quality indices and the construction of the full-link model first require the accurate retrieval of sub-link quality indices. This involves retrieving the corresponding quality index from the sub-link quality database by "sub-link ID," verifying the key components and collaborative relationships within each sub-link, and ensuring consistency with the correlation matrix (e.g., a "functional implementation sub-link" includes requirements analysis, system design, and development coding; its quality index must match the evaluation results of this combination). This results in a "Sub-link Quality Index Table," containing "sub-link name, included components, quality index, and calculation basis (sum of coefficients)," which serves as the foundation for subsequent weighted calculations.

[0165] The construction of the full-link model first requires integrating the sub-links into a complete model based on the correlation relationship of the link collaboration matrix: 1. Main link integration: Connect the core business-related sub-links (such as "requirements → design → development → testing → deployment") sequentially to form the backbone of the full link; 2. Branch correlation integration: Connect the auxiliary sub-links (such as "operation and maintenance → iterative upgrade") to the main link through collaboration relationships (such as the correlation between deployment and operation and maintenance) to ensure that the model covers all key links; Adopt a modular modeling method, with each sub-link as an independent module, and the modules are connected through correlation interfaces (such as the delivery relationship of "testing → deployment"), which facilitates subsequent weight adjustment and model reuse.

[0166] The setting of sub-link weights and the calculation of the preliminary quality index require the quantitative determination of weights. The Analytic Hierarchy Process (AHP) is used to evaluate the importance of sub-links: 1. Establish a judgment matrix: Invite business, IT, and management experts to compare the importance of each sub-link pairwise (e.g., the importance of "functional implementation sub-link" is 2:1 compared to "quality assurance sub-link"); 2. Calculate weight values: Through matrix eigenvalue decomposition, obtain the weight of each sub-link (e.g., functional implementation sub-link 0.4, quality assurance sub-link 0.3, operation and maintenance support sub-link 0.2, iterative optimization sub-link 0.1), and verify consistency (CR value < 0.1) to ensure reasonable weight allocation; the final sum of weights is forced to 1, and if there is a calculation error, it is finely adjusted proportionally.

[0167] The formula for calculating the weighted average of the preliminary quality index is as follows:

[0168]

[0169] For example, if the quality indices of the three sub-links are 8.5, 7.2, and 9.0, and their weights are 0.4, 0.3, and 0.3, then the initial quality index = 8.5×0.4 + 7.2×0.3 + 9.0×0.3 = 3.4 + 2.16 + 2.7 = 8.26.

[0170] The calculation of the negative collaboration deduction index first requires the identification of negative collaboration relationships. All negative collaboration relationships (collaboration effect coefficient < 0) are screened out from the link collaboration matrix, and their "link pair, coefficient value, and scope of influence" are recorded. The scope of influence is determined according to the business process segment involved (e.g., the negative collaboration of "development coding → testing verification" affects "functional test pass rate", which belongs to the core business scope and is recorded as "high"). A "negative collaboration list" is formed, which is divided into two categories: "core business" and "non-core business" according to the scope of influence.

[0171] The formula for calculating the deduction index is:

[0172]

[0173] The influence scope weight is set according to the importance of the business (0.6 for core business and 0.4 for non-core business). For example, for two negative synergistic relationships with coefficients of -0.3 (core business, influence scope weight 0.6) and -0.2 (non-core business, 0.4), the deduction index = 0.3×0.6 + 0.2×0.4 = 0.18 + 0.08 = 0.26.

[0174] The final evaluation index is determined by the formula "Final Evaluation Index = Preliminary Quality Index - Deduction Index". For example, if the preliminary index is 8.26, the deduction index of 0.26 is subtracted, and the final index is 8.0.

[0175] The quality level classification criteria include setting level thresholds (out of 10): Excellent: ≥9.0 points (smooth end-to-end collaboration with minimal negative impact); Good: 7.0-8.9 points (good performance of core sub-links with manageable negative impact); Satisfactory: 5.0-6.9 points (basically meets business needs with some room for optimization); Unsatisfactory: <5.0 points (serious collaboration defects exist, affecting normal business operation).

[0176] The generated end-to-end assessment report includes the following core contents: Assessment Overview: Assessment objectives, scope, and a list of key links; End-to-End Model Diagram: Marking the combination methods and collaborative relationships of sub-links; Index Calculation Details: Quality index, weight, and deduction items for each sub-link; Level Conclusion and Improvement Suggestions: Proposing optimization solutions for negative collaboration links (such as "strengthening two-way review between development and testing to reduce the negative collaboration coefficient"); The report is stored in PDF format and simultaneously generates a visual dashboard (such as a key indicator radar chart and a level distribution pie chart) for easy reference in enterprise decision-making.

[0177] Furthermore, obtaining enterprise software system construction requirements and initially outlining the key stages of the software system's entire lifecycle also includes the following processing steps:

[0178] Standardize the acquired enterprise software system construction requirements information, and convert requirements information in different formats and expressions into a unified format;

[0179] Natural language processing technology is used to perform semantic analysis on the standardized demand information to extract key entities, attributes and relationships from the demand information.

[0180] Establish a network of connections for demand information, and connect the extracted key entities, attributes and relationships through network nodes and edges;

[0181] Redundancy analysis is performed on the network of demand information associations to identify and remove duplicate or redundant information in the network, thereby simplifying the demand information.

[0182] Perform a completeness check on the processed requirement information to check for any missing information. If any information is missing, return to the information acquisition stage to acquire it again.

[0183] The verified requirement information is version-marked, and the time, source, and personnel who processed the requirement information are recorded.

[0184] Based on the importance and frequency of change of the demand information, the demand information is classified and stored. The demand information with high importance and low change frequency is stored in the core database, and the rest is stored in the extended database.

[0185] The requirement information database is updated and maintained regularly. Based on changes in business operations and new requirements, the original requirement information is supplemented, modified, or deleted.

[0186] Specifically, the acquired enterprise software system construction requirements information is first standardized using format conversion tools (such as document parsers and data cleaning scripts) to convert information in different formats, such as Word documents, Excel spreadsheets, and transcripts of interview recordings, into structured JSON or XML formats, while standardizing terminology (e.g., standardizing "user volume" and "number of visitors" as "user count"). Then, natural language processing techniques (such as BERT-based semantic models) are used to segment and identify entities in the standardized text, extracting key entities (e.g., "order system" and "payment interface"), entity attributes (e.g., "response time ≤ 2 seconds"), and entity relationships (e.g., "order system depends on payment interface"). Next, a network of requirements information is established using a graph database (e.g., Neo4j), with nodes representing entities and edges representing attributes or relationships (e.g., "order system - includes - product module"). Finally, network topology analysis tools are used to identify redundant nodes (e.g., duplicate "user information" entities) and edges (e.g., duplicate "dependency" relationships), and redundant information is removed. Next, a completeness check is performed against the core requirements list (business functions, performance, etc.). If necessary information such as "security requirements" is missing, the process is returned to the research phase for supplementation. Verified information is version-marked according to the "acquisition time + source + processing personnel" rule (e.g., V1.0_20250801_Business Department Zhang San). Then, based on importance (e.g., "business objectives" are high importance) and change frequency (e.g., "compliance requirements" change every six months), high-importance, low-change-frequency information is stored in the core database (e.g., Oracle), while the rest are stored in an extended database (e.g., MongoDB). Finally, a quarterly update mechanism is triggered to supplement, modify, or archive / delete existing information in the database based on business adjustments (e.g., the addition of "cross-border payment" requirements) and new information.

[0187] This step, through standardization, semantic analysis, and the construction of relational networks, standardizes and structures the requirement information, eliminating format differences and ambiguities, and ensuring information consistency and reusability. Simultaneously, redundancy analysis and integrity verification streamline information and fill in gaps, improving requirement quality and providing precise data support for subsequent key stages in formulating and evaluating objectives. Version tagging, categorized storage, and regular update mechanisms ensure the traceability, storage efficiency, and timeliness of requirement information, enabling requirement management to dynamically adapt to changes in enterprise business and laying a reliable information foundation for end-to-end evaluation.

[0188] Furthermore, a full-link enterprise software system evaluation device is proposed to implement the evaluation method described above, characterized in that it includes:

[0189] The module for obtaining requirements information and defining key steps is used to obtain enterprise software system construction requirements information and initially define the key steps of the entire software system lifecycle.

[0190] The evaluation objectives and scope definition module is used to define the core evaluation objectives for each key stage of the software system's entire lifecycle, and simultaneously define the evaluation scope.

[0191] The Chain Reaction Link Identification and Matrix Construction Module is used to identify key links that will cause chain reactions between links based on the core evaluation objectives and evaluation scope of each key link, and to construct a link synergy matrix.

[0192] The end-to-end evaluation execution module is used to determine the synergy effect coefficient matrix based on the link synergy matrix, and simultaneously determine whether the link synergy has a positive impact on the end-to-end gain based on the synergy effect coefficient matrix, thereby determining the sub-link quality index of the software system; and to perform end-to-end evaluation of the software system based on the link synergy matrix and the sub-link quality index of the software system.

[0193] Furthermore, the module for demand information acquisition and key process definition includes:

[0194] The requirement information collection unit is used to comprehensively collect the requirement information for the construction of the software system through internal enterprise surveys and other methods. It covers various basic information related to the enterprise's business and provides raw data support for subsequent stages.

[0195] The requirement information processing unit is used to sort and filter the collected requirement information, extract the core content closely related to the construction of the software system, and ensure the effectiveness and relevance of the information.

[0196] The preliminary identification unit for key links is used to initially screen and propose key links based on the organized core requirements information and the general rules of the software system's entire life cycle, forming a list of key links and defining the basic scope for subsequent evaluation work.

[0197] Furthermore, the assessment objectives and scope definition module includes:

[0198] The process objective analysis unit is used to analyze and clarify the core evaluation objectives for each initially proposed key process, taking into account the overall requirements of the software system and the characteristics of each process, to ensure that the evaluation objectives match the functions of the process.

[0199] The assessment scope delineation unit is used to simultaneously define the assessment scope of each key link based on the core assessment objectives of each key link, clarify the specific content and boundaries involved in the assessment work, and avoid omissions or exceeding the scope of the assessment.

[0200] The Objectives and Scope Documentation Generation Unit is used to organize the core assessment objectives and corresponding assessment scope of each key stage into a standardized document, providing clear guidance for subsequent assessment stages.

[0201] The advantages of this invention are as follows: by covering the key links of the entire life cycle of the software system, defining the core links based on the requirements information, clarifying the evaluation goals and scope of each link, constructing a link collaboration matrix and a collaboration effect coefficient matrix to quantitatively analyze the correlation and influence between links, and combining the sub-link quality index and the full-link evaluation index to achieve comprehensive quantitative evaluation, while ensuring data reliability through standardized processing of requirements information, version management and other mechanisms, this invention solves the problems of neglecting the chain reaction of links, lacking quantitative analysis and having an ambiguous scope in existing evaluations, and realizes a comprehensive, accurate and dynamic evaluation of the entire link of the software system, providing a scientific basis and operable solutions for system optimization.

[0202] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A full-link based enterprise software system evaluation method, characterized in that, The method comprises the following steps: acquiring enterprise software system construction requirement information, and preliminarily drafting key links of the whole life cycle of the software system; defining core evaluation targets of the key links of the whole life cycle of the software system, and synchronously defining evaluation ranges, wherein the evaluation ranges include business process fragments, data ranges, participants, time spans and related system components involved in the links; based on the core evaluation targets and the evaluation ranges of the key links, determining key links that will produce inter-link chain reactions, and constructing a link coordination matrix; based on the link coordination matrix, determining a coordination effect coefficient matrix, and synchronously judging whether the gain of link coordination to the whole link is positive influence according to the coordination effect coefficient matrix, so as to determine a software system sub-link quality index; performing whole link evaluation on the software system according to the link coordination matrix and the software system sub-link quality index; wherein the step of determining the key links that will produce inter-link chain reactions based on the core evaluation targets and the evaluation ranges of the key links, and constructing the link coordination matrix, specifically comprises the following steps: acquiring the core evaluation targets and the evaluation ranges of the key links from an evaluation document database; analyzing output results of each key link, and determining the type, form and role of the output results of each link; analyzing input requirements of each key link, and determining input contents required by each link from other links; judging whether there is a direct correlation between the links according to the output results and the input requirements of the links, if the output of one link is the input of another link, then the two links have a direct correlation; further analyzing the degree of influence on another link when the quality of one link changes, so as to determine whether a chain reaction will occur; marking the key links that have a chain reaction as a correlation link pair, and recording the correlation between the two links in each correlation link pair and the influence direction; constructing the link coordination matrix, wherein the rows and columns of the matrix are the key links, and the elements in the matrix represent whether there is a coordination relationship between the key link in the corresponding row and the key link in the corresponding column, if there is a coordination relationship, the element value is 1, otherwise it is 0, and the correlation and the influence direction are marked beside the element; the step of determining the coordination effect coefficient matrix based on the link coordination matrix, and synchronously judging whether the gain of link coordination to the whole link is positive influence according to the coordination effect coefficient matrix, so as to determine the software system sub-link quality index, specifically comprises the following steps: extracting all link pairs with a coordination relationship from the link coordination matrix; acquiring a coordination effect coefficient corresponding to each link pair with a coordination relationship, wherein the coordination effect coefficient is used to measure the strength and influence direction of the coordination between the two links, a positive coefficient represents positive coordination, a negative coefficient represents negative coordination, and the greater the absolute value of the coefficient, the stronger the coordination; calculating the coordination effect coefficient value of each link pair according to historical data of the links, expert experience and simulation test results, wherein the historical data includes performance data of link coordination in similar software systems in the past, and the simulation test results are data obtained by testing the link coordination effect through a simulation environment. The synergy effect coefficient matrix is constructed, the rows and columns of the matrix are the key links, and the elements in the matrix are the synergy effect coefficient values of the corresponding link pairs. For the link pairs without synergy, the coefficient value is 0; According to the synergy effect coefficient matrix, the sum of the synergy effect coefficients of all link pairs in each sub-link is calculated. The sub-link is a local link composed of multiple interrelated key links in the whole link; Determine the positivity of the sum of the synergy effect coefficients. If the sum is positive, it indicates that the link synergy in the sub-link has a positive impact on the whole link. If the sum is negative, it indicates a negative impact; Set the calculation rule of the sub-link quality index. When the sum of the synergy effect coefficients is positive, the sub-link quality index is positively correlated with the sum. When the sum is negative, the sub-link quality index is negatively correlated with the absolute value of the sum; Obtain the quality index of each sub-link of the software system and store it in the sub-link quality database.

2. The full-link based enterprise software system evaluation method according to claim 1, characterized in that, Obtain the enterprise software system construction requirement information and preliminarily determine the key links of the software system full life cycle, including: Obtain the basic requirement information of the software system construction through internal investigation of the enterprise. The basic requirement information includes business objectives, business processes, data size, user quantity, and existing system status. Store these information in the requirement information database; Classify and filter the basic requirement information in the requirement information database, and filter out the core requirement information directly related to the software system construction. The core requirement information includes business function requirements, performance requirements, security requirements, scalability requirements, and compliance requirements; According to the core requirement information, obtain the key links of the same type of software system full life cycle in the industry, and preliminarily list the key link candidate list. The links in the candidate list cover requirement analysis, system design, development and coding, testing and verification, deployment and implementation, operation and maintenance, iteration and upgrade, and retirement and elimination; Perform relevance analysis on each link in the key link candidate list. Analyze the correlation degree of each link to each requirement in the core requirement information, calculate the correlation degree value of each link to the core requirement, and the correlation degree value ranges from 0 to 1. The higher the correlation degree value, the closer the correlation between the link and the core requirement; Set the correlation degree threshold. Keep the links with correlation degree values greater than or equal to the threshold in the candidate list, and remove the links with correlation degree values less than the threshold. Obtain the preliminary shortlist of key links; Adjust the shortlist of key links, add the necessary links that are missed, and delete redundant or unreasonable links. Form the preliminary determined key link list of the software system full life cycle, and store the preliminary determined key link list in the key link database.

3. The full-link based enterprise software system evaluation method according to claim 1, wherein, Define the core evaluation objectives of each key link of the software system full life cycle, and define the evaluation scope simultaneously, including: Retrieve the preliminary determined key link list of the software system full life cycle from the key link database; Obtain the function points of each key link and classify the function points according to different dimensions to obtain the selected evaluation function point set; The ratio of the number of function points in each candidate evaluation function point set in the core requirement information to the total number of function points is taken as an evaluation index, and the candidate evaluation function point set with the largest evaluation index is taken as a core evaluation target; According to the core evaluation target and the evaluation index, the evaluation range of each key link is defined; The evaluation range of each key link is confirmed, and the boundaries of the link and other links are clarified to avoid overlapping or missing of the evaluation range; The core evaluation target, evaluation index and evaluation range of each key link are sorted into an evaluation target and range specification, and stored in an evaluation document database.

4. The full-link based enterprise software system evaluation method according to claim 1, characterized in that, According to the link coordination matrix and the software system sub-link quality index, the software system is evaluated in full link, specifically including: The coordination relationship and association direction between all key links are obtained from the link coordination matrix, and the connection mode of each link in the full link is clarified; The quality index of each sub-link is called from the sub-link quality database; According to the link coordination matrix, the structure of the full link is determined, and each sub-link is combined into a complete full link model according to the coordination relationship; The weight of each sub-link quality index is set; The preliminary quality index of the full link is calculated by weighted summation, which is equal to the sum of the product of each sub-link quality index and the corresponding weight; The negative coordination relationship in the link coordination matrix is analyzed, and the deduction index of the negative coordination on the quality of the full link is calculated, which is determined according to the absolute value of the negative coordination effect coefficient and the influence range; The final evaluation index of the software system full link is obtained by subtracting the deduction index from the preliminary quality index; According to the final evaluation index, the quality of the software system full link is graded, including excellent, good, qualified and unqualified, and a full link evaluation report is generated.

5. The method of claim 1, wherein the enterprise software system based on the full link is evaluated, characterized by, The following processing steps are included in the preliminary drafting of the key links of the software system full life cycle based on the obtained enterprise software system construction requirement information: The obtained enterprise software system construction requirement information is standardized, and the requirement information in different formats and different expressions is converted into a unified format; The standardized requirement information is analyzed by natural language processing technology, and the key entities, attributes and relationships in the requirement information are extracted; An associated network of requirement information is established, and the extracted key entities, attributes and relationships are connected through network nodes and edges; The redundancy of the requirement information associated network is analyzed, and the repeated or redundant information in the network is identified and removed to simplify the requirement information; The processed requirement information is checked for completeness to check if there is a lack of necessary information. If there is a lack, return to the information acquisition stage to reacquire; The verified requirement information is marked with a version, and the acquisition time, source and processing personnel of the requirement information are recorded; According to the importance and change frequency of the requirement information, the requirement information is classified and stored. The requirement information with high importance and low change frequency is stored in the core database, and the rest is stored in the extended database; The requirement information database is updated and maintained regularly, and the original requirement information is supplemented, modified or deleted according to the changes of enterprise business and new requirement information.

6. An all-link based enterprise software system evaluation apparatus for implementing the evaluation method of any one of claims 1-5, characterized by, ​ The demand information acquisition and key link drafting module is configured to acquire enterprise software system construction demand information and preliminarily draft key links of the software system full life cycle. The evaluation target and range defining module is configured to define core evaluation targets of each key link of the software system full life cycle and simultaneously define evaluation ranges. The chain reaction link identification and matrix construction module is configured to determine key links that will produce inter-link chain reactions based on the core evaluation targets and evaluation ranges of each key link and construct a link synergy matrix. The full-link evaluation execution module is configured to determine a synergy effect coefficient matrix based on the link synergy matrix, simultaneously determine whether the gain of link synergy on the full link is a positive effect based on the synergy effect coefficient matrix, and thus determine a software system sub-link quality index, and perform full-link evaluation on the software system based on the link synergy matrix and the software system sub-link quality index.

7. An apparatus for evaluating enterprise software systems based on full link according to claim 6, characterized in that, The demand information acquisition and key link drafting module includes: The demand information acquisition unit is configured to comprehensively collect demand information for software system construction through enterprise internal research, covering various types of basic information related to enterprise business, and providing original data support for subsequent links. The demand information sorting unit is configured to sort and filter the collected demand information, extract core content closely related to software system construction, and ensure the effectiveness and pertinence of the information. The key link preliminary determination unit is configured to preliminarily screen and draft key links based on the sorted core demand information, in combination with general rules of the software system full life cycle, form a key link list, and define a basic range for subsequent evaluation work.

8. An apparatus for evaluating enterprise software systems based on full link according to claim 6, wherein, The evaluation target and range defining module includes: The link target analysis unit is configured to analyze and determine core evaluation targets for each key link preliminarily drafted in combination with the overall demand of the software system and the characteristics of each link, and ensure that the evaluation targets match the link functions. The evaluation range defining unit is configured to simultaneously define the evaluation range of each link based on the core evaluation targets of each key link, clearly define the specific content and boundaries involved in the evaluation work, and avoid omissions or out-of-range situations in the evaluation. The target and range document generation unit is configured to sort the core evaluation targets and corresponding evaluation ranges of each key link to form a standardized document and provide clear guidance for subsequent evaluation links.

Images