Enterprise software system evaluation method and device based on full link
By acquiring enterprise software system construction requirements, identifying key stages throughout the entire lifecycle, constructing a stage collaboration matrix, and quantitatively analyzing synergistic effects, this approach solves the problem of insufficient accuracy in end-to-end evaluation in existing technologies, and achieves quantitative evaluation of end-to-end quality and guidance for system optimization.
Patent Information
- Application Number
- CN202511080509.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-04
- Publication Date
- 2025-11-14
- Estimated Expiration
- 2045-08-04
AI Technical Summary
Existing enterprise software system evaluation methods based on the entire value chain often focus on a single link, ignoring the chain reaction between links and lacking quantitative synergy analysis. This results in insufficient evaluation accuracy and vague scope definition, making it difficult to reflect the true quality of the entire value chain and limiting its guiding value.
By acquiring enterprise software system construction requirements, we initially identify key stages throughout the entire lifecycle, define core evaluation objectives, construct a stage collaboration matrix, determine a collaboration effect coefficient matrix, quantify the positive/negative impact between stages, calculate sub-link quality indices, and finally generate a full-link evaluation index.
It achieved a precise match between the assessment scope and the actual needs of enterprises, quantified the synergistic effects between links, clarified the quality of the entire chain, provided direct guidance for system optimization, and improved the stability and operating efficiency of the software system.
Smart Images

Figure CN120950358A_ABST
Abstract
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 output of each key stage to determine the type, form, and function of each output.
[0029] Analyze the input requirements of each key step and clarify the input content that each step needs to obtain from other steps;
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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:
[0035] Extract all pairs of links that have a collaborative relationship from the link collaboration matrix;
[0036] Obtain the synergy coefficient for each pair of links with a synergistic relationship;
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] Obtain the quality index of each sub-link of the software system and store it in the sub-link quality database.
[0043] 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:
[0044] 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;
[0045] Retrieve the quality index of each sub-link from the sub-link quality database;
[0046] 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.
[0047] Assign weights to the quality index of each sub-link;
[0048] 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.
[0049] 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.
[0050] Subtracting the deduction index from the preliminary quality index yields the final evaluation index for the entire software system chain.
[0051] 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.
[0052] 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:
[0053] Standardize the acquired enterprise software system construction requirements information, and convert requirements information in different formats and expressions into a unified format;
[0054] 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.
[0055] Establish a network of connections for demand information, and connect the extracted key entities, attributes and relationships through network nodes and edges;
[0056] 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.
[0057] 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.
[0058] The verified requirement information is version-marked, and the time, source, and personnel who processed the requirement information are recorded.
[0059] 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.
[0060] 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.
[0061] Furthermore, a full-link enterprise software system evaluation device is proposed to implement the evaluation method described above, characterized in that it includes:
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] Furthermore, the module for demand information acquisition and key process definition includes:
[0067] 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.
[0068] 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.
[0069] 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.
[0070] Furthermore, the assessment objectives and scope definition module includes:
[0071] 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.
[0072] 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.
[0073] 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.
[0074] Compared with the prior art, the beneficial effects of the present invention are:
[0075] 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
[0076] Figure 1 This is a flowchart of an enterprise software system evaluation method based on the entire value chain proposed in this invention;
[0077] Figure 2 This is a flowchart illustrating the construction of the link coordination matrix in this invention;
[0078] Figure 3 This is a flowchart illustrating the process of obtaining the sub-link quality index of the software system in this invention.
[0079] 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
[0080] 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.
[0081] Reference Figure 1 - Figure 4 As shown, an enterprise software system evaluation method based on the entire value chain includes:
[0082] Obtain information on the enterprise's software system construction requirements and initially draft the key stages of the software system's entire lifecycle;
[0083] Define the core evaluation objectives for each key stage of the software system's entire lifecycle, and simultaneously define the evaluation scope;
[0084] 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.
[0085] 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.
[0086] 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.
[0087] 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:
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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;
[0093] 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.
[0094] Specifically, obtaining basic requirements for software system construction through internal enterprise research requires designing standardized questionnaires and conducting interviews with enterprise management, business department 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 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" "supporting 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., "supporting a 50% annual increase in user volume"); compliance requirements: extracting industry regulations or corporate policies (e.g., "complying 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".
[0095] The correlation value between each link and the core requirement is calculated using the "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%).
[0096] 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);
[0097] Step 3: Calculate the weighted sum according to the weights, using the following formula:
[0098]
[0099] For example, if the "testing and verification phase" has a support level of 0.9 for performance requirements, 0.8 for security requirements, and 0.6 for other dimensions, 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.
[0100] The determination of the relevance threshold needs to be based on the "core requirement coverage": 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.
[0101] Next, remove links with relevance values below the threshold (e.g., "retirement" links with a relevance 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 key connecting links are missing (e.g., "deployment and implementation" is not included, leading to a disconnect between development and operation), they still need to be added even if the relevance 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").
[0102] 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:
[0103] Retrieve a preliminary list of key lifecycle stages of the software system from the key stage database;
[0104] 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.
[0105] 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.
[0106] 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.
[0107] 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;
[0108] 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.
[0109] 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."
[0110] 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".
[0111] 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).
[0112] 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 encryption storage" belongs to both "security requirements" and "order management business".
[0113] 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".
[0114] 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:
[0115]
[0116] For example, the "performance requirement feature set" contains 5 feature points, of which "concurrency testing and response time monitoring" directly match the core requirement of "supporting 100,000 users online at the same time". Therefore, the evaluation index = 2 / 5 = 40%.
[0117] 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").
[0118] 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".
[0119] The boundary confirmation mechanism uses the "link interface mapping method" to clearly define the boundaries with other links:
[0120] 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 and completed" 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).
[0121] The generation and storage of the assessment objectives and scope statement includes:
[0122] 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).
[0123] 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 (such as developers can view the manual for the "development and coding stage", while testers can only view the manual for the "testing and verification stage"); link the key stage database with the evaluation document database, and enable cross-database queries through stage IDs (such as automatically retrieving the corresponding manual when querying the "deployment and implementation stage") to ensure data consistency.
[0124] 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:
[0125] Obtain the core assessment objectives and scope for each key stage from the assessment document database;
[0126] Analyze the output of each key stage to determine the type, form, and function of each output.
[0127] Analyze the input requirements of each key step and clarify the input content that each step needs to obtain from other steps;
[0128] 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.
[0129] 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.
[0130] 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.
[0131] 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.
[0132] 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). The core assessment objectives (e.g., "compliance rate of security requirement functional points") and assessment scope (e.g., business process segments, data range, 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."
[0133] The process involves reverse engineering to derive the input content required from other stages: 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 conjunction with the output deliverables list.
[0134] 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").
[0135] The identification and identification of chain reactions and the marking 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 through an "impact factor": the impact factor is defined as (the probability that substandard quality of X leads to substandard quality of Y) × (the weight of the impact of substandard quality of Y on its core evaluation objective); the probability is calculated using historical data, such as "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), and link pairs with an impact factor ≥ the threshold are judged to have a chain reaction. For links that have a chain reaction, mark them as "related link pairs" and record: the type of relationship (such as "document dependency", "code dependency", "data dependency"); the direction of influence (X→Y means X affects Y, Y→X means bidirectional influence, such as "there is bidirectional feedback between development and testing"); and the key point of influence (such as "the ambiguity of X's documentation will lead to the design deviation of Y").
[0136] The steps for constructing the process coordination matrix include:
[0137] 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 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".
[0138] 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:
[0139] Extract all pairs of links that have a collaborative relationship from the link collaboration matrix;
[0140] Obtain the synergy effect coefficient for each pair of links that have 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.
[0141] 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.
[0142] 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.
[0143] 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.
[0144] 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.
[0145] 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.
[0146] Obtain the quality index of each sub-link of the software system and store it in the sub-link quality database.
[0147] Specifically, this step first filters cells with a 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 in the matrix (requirements analysis, system design) is 1, then this combination is a related process pair. Process pairs are then categorized by "direction of influence," distinguishing between unidirectional relationships (e.g., X→Y) and bidirectional relationships (e.g., ...). (e.g., two-way feedback between development and testing), and record the type of relationship (e.g., document dependency, code dependency). Secondly, remove duplicate records (e.g., if (X,Y) and (Y,X) are unidirectionally related, retain the original direction; if bidirectionally related, merge the records) to ensure each link is unique. Verify that the link pairs match the previously marked "related link pairs" (combinations with chain reactions). If inconsistencies exist, backtrack the construction process of the link collaboration matrix and correct erroneous associations.
[0148] 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 phase and the defect rate in the system design phase, and the impact of development delays on the testing cycle. This data is quantified as a historical impact value between 0 and 1 (positive values for positive impacts, negative values for negative impacts). Next, 5-8 cross-domain experts (business, development, testing, and operations) score the synergy effect of each pair of phases 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 amount of deviation rate change / the amount of quality adjustment) as the simulation test value (range -1 to 1).
[0149] 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).
[0150] 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, where each element corresponds one-to-one with the link synergy matrix. For link pairs with synergistic relationships, the calculated synergy effect coefficient is 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 coefficient is indicated (e.g., "+0.54(X→Y)" indicates positive synergy between X and Y, "-0.32(Y→X)" indicates negative synergy between Y and X). All the above matrices need to be validated and corrected to check their symmetry: bidirectional link pairs... The coefficients are checked for reasonableness (e.g., X = +0.6 for Y, Y = +0.5 for X, which conforms to positive feedback logic); the coefficients for non-related directions in unidirectional links are checked for 0. The reasonableness of the coefficients is reviewed by the expert team, and coefficients that deviate significantly from reality (e.g., logically they should be positive but are calculated as negative) are recalculated and corrected by retrieving data.
[0151] The sub-link definition rules are based on the correlation relationship of the link collaboration matrix, dividing the entire link into multiple local sub-links: divided 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"); divided 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).
[0152] 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)).
[0153]
[0154] 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).
[0155] 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 for easy 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 is categorized by sub-link type (e.g., functional implementation type, quality assurance type) and supports queries by link, index range, and other conditions, providing data support for full-link evaluation.
[0156] 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:
[0157] 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;
[0158] Retrieve the quality index of each sub-link from the sub-link quality database;
[0159] 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.
[0160] 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.
[0161] 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.
[0162] 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.
[0163] Subtracting the deduction index from the preliminary quality index yields the final evaluation index for the entire software system chain.
[0164] 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.
[0165] Specifically, this step first extracts all non-zero elements (indicating collaborative relationships) from the link coordination matrix, and sorts out the upstream and downstream connections of each key link, including: 1. Clarifying the direction of connection: through the "X→Y" or "Y→X" labels next to the matrix elements. Determine the unidirectional impact between stages (e.g., requirements analysis → system design) or the bidirectional feedback (e.g., ... 2. Statistical Analysis of Association Strength: Combining the synergy effect coefficient matrix, record the absolute value of the coefficient for each association (e.g., the coefficient for "Requirements Analysis → System Design" is +0.54, indicating moderate strength). Create a "Full-Link Synergy Relationship List," including fields for "Pair of Links, Direction of Association, Type of Association (Positive / Negative), and Strength Level." This step also requires visualizing the connection methods using flowchart tools (e.g., Visio, Lucidchart) to draw a full-link connection diagram: nodes represent key links, with node size according to link importance (e.g., larger nodes for core business-related links); arrows represent the direction of association, with arrow line thickness corresponding to the synergy strength (the larger the absolute value of the coefficient, the thicker the line); different colors are used to label the synergy type (blue for positive synergy, red for negative synergy), visually presenting the connection logic of the entire link (e.g., the main link of "Requirements → Design → Development → Testing → Deployment → Operation and Maintenance" and the branch associations between each link).
[0166] 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). A "Sub-link Quality Index Table" is then created, containing "sub-link name, included components, quality index, and calculation basis (sum of coefficients)," serving as the foundation for subsequent weighted calculations.
[0167] 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 coordination 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 the coordination relationship (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 the correlation interface (such as the delivery relationship of "testing → deployment"), which facilitates subsequent weight adjustment and model reuse.
[0168] 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.
[0169] The formula for calculating the weighted average of the preliminary quality index is as follows:
[0170]
[0171] 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.
[0172] 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.
[0173] The formula for calculating the deduction index is:
[0174]
[0175] 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.
[0176] 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 and the deduction index is 0.26, the final index is 8.0.
[0177] The quality level classification criteria include setting level thresholds (out of 10): Excellent: ≥9.0 points (smooth collaboration across the entire link, minimal negative impact); Good: 7.0-8.9 points (good performance of core sub-links, controllable 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).
[0178] 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 a visual dashboard (such as a key indicator radar chart and a level distribution pie chart) is generated simultaneously for enterprise decision-making reference.
[0179] 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:
[0180] Standardize the acquired enterprise software system construction requirements information, and convert requirements information in different formats and expressions into a unified format;
[0181] 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.
[0182] Establish a network of connections for demand information, and connect the extracted key entities, attributes and relationships through network nodes and edges;
[0183] 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.
[0184] 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.
[0185] The verified requirement information is version-marked, and the time, source, and personnel who processed the requirement information are recorded.
[0186] 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.
[0187] 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.
[0188] 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), and 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.
[0189] 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.
[0190] Furthermore, a full-link enterprise software system evaluation device is proposed to implement the evaluation method described above, characterized in that it includes:
[0191] 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.
[0192] 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.
[0193] 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.
[0194] 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.
[0195] Furthermore, the module for demand information acquisition and key process definition includes:
[0196] 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.
[0197] 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.
[0198] 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.
[0199] Furthermore, the assessment objectives and scope definition module includes:
[0200] 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.
[0201] 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.
[0202] 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.
[0203] 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.
[0204] 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 method for evaluating enterprise software systems based on the entire value chain, characterized in that, include: Obtain information on the enterprise's software system construction requirements and initially draft the key stages of the software system's entire lifecycle; Define the core evaluation objectives for each key stage of the software system's entire lifecycle, and simultaneously define the evaluation scope; 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. 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. 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.
2. The enterprise software system evaluation method based on the entire value chain according to claim 1, characterized in that, Obtain enterprise software system development requirements and initially define the key stages of the software system's entire lifecycle, including: 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. 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. 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. 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. 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; 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.
3. A method for evaluating enterprise software systems based on the entire value chain according to claim 1, characterized in that, Define the core evaluation objectives for each key stage of the software system's entire lifecycle, and simultaneously define the evaluation scope, specifically including: Retrieve a preliminary list of key lifecycle stages of the software system from the key stage database; 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. 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. 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. 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; 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.
4. A method for evaluating enterprise software systems based on the entire value chain according to claim 1, characterized in that, Based on the core assessment objectives and scope of each key link, the key links that will cause chain reactions between links are identified, and a link synergy matrix is constructed, specifically including: Obtain the core assessment objectives and scope for each key stage from the assessment document database; Analyze the output of each key stage to determine the type, form, and function of each output. Analyze the input requirements of each key step and clarify the input content that each step needs to obtain from other steps; 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. 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. 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. 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.
5. A method for evaluating enterprise software systems based on the entire value chain according to claim 1, characterized in that, 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 overall link gain, thereby determining the sub-link quality index of the software system, specifically including: Extract all pairs of links that have a collaborative relationship from the link collaboration matrix; Obtain the synergy coefficient for each pair of links with a synergistic relationship; 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. 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. 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. 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. 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. Obtain the quality index of each sub-link of the software system and store it in the sub-link quality database.
6. A method for evaluating enterprise software systems based on the entire value chain according to claim 1, characterized in that, 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, specifically including: 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; Retrieve the quality index of each sub-link from the sub-link quality database; 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. Assign weights to the quality index of each sub-link; 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. 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. Subtracting the deduction index from the preliminary quality index yields the final evaluation index for the entire software system chain. 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.
7. A method for evaluating enterprise software systems based on the entire value chain according to claim 1, characterized in that, 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: Standardize the acquired enterprise software system construction requirements information, and convert requirements information in different formats and expressions into a unified format; 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. Establish a network of connections for demand information, and connect the extracted key entities, attributes and relationships through network nodes and edges; 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. 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. The verified requirement information is version-marked, and the time, source, and personnel who processed the requirement information are recorded. 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. 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.
8. A full-link enterprise software system evaluation device, used to implement the evaluation method as described in any one of claims 1-7, characterized in that, include: 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. 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. 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. 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.
9. A full-link enterprise software system evaluation device according to claim 8, characterized in that, The module for obtaining requirements information and defining key steps includes: 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. 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. 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.
10. A full-link enterprise software system evaluation device according to claim 8, characterized in that, The assessment objectives and scope definition module includes: 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. 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. 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.
Citation Information
Patent Citations
Method for evaluating performance efficiency of information system
CN115509877A
Enterprise software system construction method and device based on micro service
CN119597363A
Comprehensive quantification method for cooperative benefit evaluation between enterprises
CN120218760A
A system for implementing a method of matrix-digital transformation of a variable data set for generating a situational-strategic product program
RU2020139765A