An adaptation retrofit cost evaluation method, system, device and medium

Abstract

This application relates to a method, system, equipment, and medium for assessing adaptation and modification costs. The method identifies objects to be adapted through demand analysis and generates an object set. Based on adaptation point counting rules, the unadjusted scale is quantified, and after adjustment using demand change factors, the adapted scale is obtained. Subsequently, basic workload is calculated using productivity benchmark data, and the non-adapted construction workload is summarized to form the total basic workload. Then, the corrected workload is obtained through dynamic correction using preset adjustment factors. Finally, based on the corrected workload, labor costs, and allocation rules, the system calculates and summarizes various costs to arrive at the total cost. This process realizes a shift from subjective experience-based judgment to standardized assessment driven by rules and data, improving the objectivity, accuracy, and adaptability to project dynamics in cost assessment, and providing a reliable basis for budget control and resource allocation.

Description

Technical Field

[0001] This invention belongs to the field of information technology and software engineering, and in particular relates to a method, system, equipment and medium for assessing adaptation and transformation costs. Background Technology

[0002] Against the backdrop of the rapid development of the information technology application innovation (IT innovation) industry, the adaptation and transformation of various application software to domestic basic software and hardware environments has become a key project that is widely implemented. However, such transformation projects usually involve complex architecture migration, code compatibility handling, and system reconstruction, and their cost assessment has long faced severe challenges.

[0003] Currently, the industry generally relies on the subjective experience of project experts or technicians to make rough estimates of workload and costs. This model leads to a lack of unified standards for evaluation results, with huge differences between different projects or different evaluation parties, poor comparability, and difficulty in supporting accurate budget preparation and bidding decisions.

[0004] Meanwhile, traditional assessment approaches often focus on explicit code modifications or simple manpower hours, failing to fully incorporate and quantify implicit but crucial adaptation activities such as heterogeneous platform compatibility testing, security feature hardening, data migration, and in-depth optimization to adapt to the unique attributes of domestic technology stacks. This results in significant omissions in cost estimations, making it easy for budget overruns to occur during actual project execution.

[0005] A more prominent problem is that the domestic IT innovation technology ecosystem itself is in a process of rapid iteration and evolution, with new domestic chips, operating system versions, databases and middleware constantly emerging. However, the existing static evaluation model cannot respond to this change in a timely manner. Its built-in parameters and coefficients are lagging behind, resulting in evaluation conclusions that are out of touch with the technological reality and cannot effectively guide the ongoing adaptation project.

[0006] Therefore, the industry urgently needs a standardized and quantifiable cost assessment method that can overcome subjective arbitrariness, comprehensively cover and adapt to work dimensions, and dynamically adapt to changes in the technology ecosystem, in order to improve the scientific nature of project management and the efficiency of the use of fiscal funds, and ensure the smooth progress and sustainable development of the information technology innovation substitution project. Summary of the Invention

[0007] Therefore, it is necessary to provide a method, system, equipment, and medium for assessing the transformation costs in response to the above-mentioned technical problems.

[0008] Firstly, this application provides a method for assessing the cost of adaptation and modification, including:

[0009] S1. Conduct requirements analysis on the application software to be modified and the target information technology innovation environment, identify all objects that need to be adapted for code-level compatibility modification, and generate a set of objects to be adapted.

[0010] S2. Based on the set of objects to be adapted, the adaptation points are counted according to the preset adaptation point counting rules to obtain the adaptation point counting results, and the total scale of unadjusted adaptation points is calculated based on the adaptation point counting results.

[0011] S3. Based on the total unadjusted adaptation point size, calculate the size adjustment by combining the preset demand change factor, and generate the adjusted adaptation size.

[0012] S4. Obtain the productivity baseline data for the adaptive construction class, and calculate the basic workload of the adaptive construction class based on the adjusted adaptation scale and productivity baseline data; obtain the workload of the non-adaptive construction class, add the basic workload of the adaptive construction class to the workload of the non-adaptive construction class, and generate the total basic workload.

[0013] S5. Based on the total basic workload, dynamically adjust the workload using preset adjustment factors to generate the corrected workload;

[0014] S6. Based on the corrected workload, the preset labor cost rate, and the preset cost allocation rules, calculate the direct labor cost, direct non-labor cost, indirect labor cost, and indirect non-labor cost respectively; summarize the direct labor cost, direct non-labor cost, indirect labor cost, and indirect non-labor cost to obtain the total cost of the adaptation and transformation project.

[0015] Secondly, this application also provides an adaptive modification cost assessment system for implementing the method described in the first aspect, the system comprising:

[0016] The requirements analysis and object identification module is used to perform requirements analysis on the application software to be modified and the target information technology innovation environment, identify all objects that need to be adapted and require code-level compatibility modification, and generate a set of objects to be adapted.

[0017] The adaptation point quantization calculation module is used to count adaptation points based on the set of objects to be adapted, according to the preset adaptation point counting rules, to obtain the adaptation point counting results, and to calculate the total scale of unadjusted adaptation points based on the adaptation point counting results.

[0018] The scale dynamic optimization module is used to calculate the scale adjustment based on the total scale of the unadjusted adaptation points and in combination with the preset demand change factors, and generate the adjusted adaptation scale.

[0019] The workload basic calculation module is used to obtain the productivity benchmark data of the adaptive construction class, calculate the basic workload of the adaptive construction class based on the adjusted adaptation scale and productivity benchmark data, obtain the workload of the non-adaptive construction class, add the basic workload of the adaptive construction class to the workload of the non-adaptive construction class, and generate the total basic workload.

[0020] The workload dynamic correction module is used to dynamically adjust the total basic workload based on preset adjustment factors to generate the corrected workload.

[0021] The cost comprehensive accounting module is used to calculate direct labor costs, direct non-labor costs, indirect labor costs, and indirect non-labor costs based on the corrected workload, preset labor cost rates, and preset cost allocation rules; and to summarize the direct labor costs, direct non-labor costs, indirect labor costs, and indirect non-labor costs to obtain the total cost of the adaptation and transformation project.

[0022] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement an adaptation cost assessment method as described in the first aspect.

[0023] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements an adaptation cost assessment method as described in the first aspect.

[0024] The aforementioned method, system, equipment, and medium for assessing adaptation and transformation costs firstly analyze the requirements of the application software to be transformed and the target information technology innovation environment, identifying and generating a set of objects to be adapted. Then, based on a preset adaptation point counting rule, this set is quantitatively counted to obtain the total scale of unadjusted adaptation points. Subsequently, a requirement change factor is introduced to adjust this scale, generating a more accurate adjusted adaptation scale. Next, by acquiring productivity benchmark data and combining it with the workload of non-adaptive construction classes, the total basic workload is calculated, and dynamically corrected using a preset adjustment factor to generate the corrected workload. Finally, based on this corrected workload and combined with preset labor cost rates and cost allocation rules, the various sub-costs are systematically calculated and summarized to obtain the total project cost. This achieves a shift in the assessment of information technology innovation software adaptation and transformation costs from relying on subjective experience to assessment based on structured rules and data-driven approaches, effectively improving the objectivity of the assessment process, the accuracy of the results, and the adaptability to dynamic changes in the project, thus providing reliable technical support for project budget control and resource optimization. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1A flowchart illustrating an adaptation and modification cost assessment method provided by the present invention;

[0027] Figure 2 This is a schematic diagram of the structure of an adaptation and modification cost assessment system provided by the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0029] refer to Figure 1 The document presents a flowchart illustrating an adaptation and modification cost assessment method provided in this application, which includes the following steps:

[0030] S1. Conduct requirements analysis on the application software to be modified and the target information technology innovation environment, identify all objects that need to be adapted for code-level compatibility modification, and generate a set of objects to be adapted.

[0031] Specifically, when conducting requirements analysis for the application software to be modified and the target domestic IT innovation environment, a systematic survey should be carried out from multiple dimensions to ensure that all potential code-level compatibility modification needs are covered. For the application software to be modified, the focus should be on analyzing its architecture design (including the front-end development framework used in the presentation layer, the service orchestration mechanism in the business logic layer, and the object-relational mapping tool used in the data access layer), code repository structure (complete code branches can be exported through version control tools to filter out code files involving external dependency calls, such as middleware client interface classes and database connection configuration modules), and development language characteristics (including the version of the development language and whether it depends on specific third-party libraries or plugins). For the target domestic IT innovation environment, it is necessary to clarify the CPU architecture type at the hardware level, as well as the operating system type, database system type, middleware type, and browser type at the software level, to ensure a comprehensive understanding of the technical differences between the original system and the target environment.

[0032] When identifying objects requiring code-level compatibility modifications, each one is checked individually based on the aforementioned technical differences. For example, if the database driver used by the original system is incompatible with the target domestically developed database, the corresponding database connection utility class needs to be included in the adaptation scope; if the non-domestically developed middleware interface protocol relied upon by the original system does not match the target middleware, the business code modules involving these interface calls need to be listed as objects to be adapted. Finally, all identified objects to be adapted are organized into a structured set of objects to be adapted. This set must clearly record the name of each object to be adapted, its code path, associated external dependent components, and the type of compatibility issues, providing a clear basis for subsequent counting work.

[0033] S2. Based on the set of objects to be adapted, the adaptation points are counted according to the preset adaptation point counting rules to obtain the adaptation point counting results, and the total scale of unadjusted adaptation points is calculated based on the adaptation point counting results.

[0034] Specifically, before counting adaptation points based on the set of objects to be adapted, adaptation point counting rules need to be formulated in advance. These rules should combine practical experience in adaptation and transformation within the industry with implementation data from similar projects within the enterprise, clearly defining the counting standards and assignment logic for different types of objects to be adapted, ensuring the objectivity and consistency of the counting process. During the counting process, each object in the set of objects to be adapted must first be classified to determine its counting category (e.g., middleware configuration-related objects, database interaction-related objects, browser page-related objects, etc.). Then, according to the preset rules, a corresponding industry statistical mean is assigned to each counting category. This mean needs to be determined through statistical calculations based on the actual transformation workload of a large number of similar adaptation projects, and is used to quantify the transformation complexity of different categories of objects to be adapted.

[0035] After counting and assigning values ​​to individual objects to be adapted, the total number of unadjusted adaptation points is calculated using the following formula: US represents the total size of the unadjusted adaptation points, which reflects the overall size of the set of objects to be adapted; n represents the total number of count categories of the objects to be adapted, that is, the number of different count categories that can be divided into for all objects to be adapted. Represents the number of count items of the i-th category, that is, the number of objects in the set of objects to be adapted that belong to the i-th count category; This represents the industry statistical mean corresponding to the i-th type of count item, used to quantify the transformation scale weight of a single individual in the i-th type of target object. During the calculation process, a programming script can be used to read the structured data of the target object set, automatically perform classification, counting, and summation operations, avoiding human calculation errors, and generate a detailed count report, recording the number of each type of count item, the corresponding industry statistical mean, and the calculation process, ensuring the results are traceable.

[0036] S3. Based on the total size of the unadjusted adaptation points, calculate the size adjustment by combining the preset demand change factor, and generate the adjusted adaptation size.

[0037] Specifically, before adjusting the scale based on the total scale of the adaptation points, a pre-defined requirement change factor needs to be determined. This factor is used to quantify the impact of requirement stability on the scale of adaptation modifications. The value of the requirement change factor is determined through a requirement review meeting, with the participation of product management personnel, development personnel, and testing personnel. A risk matrix assessment method is used, combining the judgment of requirement clarity during the requirement research phase, the probability of requirement changes during the project cycle, and the degree of impact of changes on the modification work, to determine a reasonable factor value: if the requirement is fully clear and there are no change plans during the project cycle, the factor value should be close to 1; if the requirement is uncertain and changes may significantly increase the scope of modification, the factor value should be greater than 1.

[0038] After determining the demand change factor, the adjusted fit size is calculated using the formula: Where S represents the adjusted adaptation scale, reflecting the actual renovation scale after considering the risk of demand changes; US represents the total scale of the unadjusted adaptation points, i.e., the result calculated in step S2; CF represents the demand change factor, i.e., the coefficient determined through demand review that quantifies the risk of demand changes. The adjusted adaptation scale can more accurately match the actual needs of the project, avoid underestimation of subsequent workload due to demand changes, and provide a more realistic scale basis for subsequent workload calculations.

[0039] S4. Obtain the productivity baseline data for the adaptive construction class, and calculate the basic workload of the adaptive construction class based on the adjusted adaptation scale and productivity baseline data; obtain the workload of the non-adaptive construction class, add the basic workload of the adaptive construction class to the workload of the non-adaptive construction class, and generate the total basic workload.

[0040] Specifically, when obtaining productivity benchmark data for adaptation and build tasks, it can be extracted from industry-published benchmark databases (such as software cost benchmark reports compiled by industry associations) or the company's internal project experience database. This data represents the average working time per unit adaptation point and is used to quantify the efficiency level of adaptation and build tasks. When calculating the basic workload of adaptation and build tasks based on the adjusted adaptation scale and productivity benchmark data, a multiplicative logic is used, that is, the basic workload of adaptation and build tasks is equal to the product of the adjusted adaptation scale and the productivity benchmark data. This workload only covers tasks related to code-level compatibility modifications.

[0041] Non-adaptive build workload covers other necessary work in adaptation and transformation projects besides code-level compatibility modifications (such as historical data migration, installation and configuration of the domestic IT infrastructure environment, etc.). The appropriate method for obtaining this workload can be selected based on the actual situation of the project: if there are similar historical projects, the analogy method can be used, referring to the workload of similar non-adaptive build work in historical projects; if the project is in the early stage of requirements and the details are not yet clear, the proportional method can be used, estimating according to a certain proportion of the basic workload of adaptation build; if the work tasks have been clearly broken down, the actual estimation method can be used, calculating one by one according to the difficulty and time consumption of each specific task.

[0042] The total basic workload is obtained by adding the workload of the adaptable build classes to the workload of the non-adaptable build classes, using the following formula: UE represents the total basic workload, which is the total basic work time required for the adaptation and transformation project; This represents the basic workload of adapting and building, which is the result calculated based on the adjusted adapting scale and productivity benchmark data. This represents the workload of non-adaptive construction tasks, i.e., the results obtained through analogy, proportionality, or factual estimation methods. During the calculation process, ensure that all workloads are calculated in consistent units (e.g., in "person-hours") to avoid calculation errors caused by unit differences.

[0043] S5. Based on the total basic workload, dynamically adjust the workload using preset adjustment factors to generate the corrected workload.

[0044] Specifically, before making dynamic adjustments based on the total basic workload, adjustment factors need to be preset. These factors are used to quantify the impact of non-scale factors on the workload (such as project urgency, technical difficulty, etc., excluding specific factors that are only dependent claims). The value of each adjustment factor needs to be based on the internal assignment standard established by the enterprise. This standard is determined by analyzing the impact of different influencing factors on the actual workload in similar historical projects. For example, when the project needs to be completed within a short period of time, the project urgency factor is greater than 1; when the technology stack involved in the transformation is relatively uncommon, the technical difficulty factor is greater than 1.

[0045] The total basic workload is dynamically adjusted using a preset adjustment factor to generate the corrected workload. The formula is as follows: , where AE represents the corrected workload, that is, the final workload after considering the influence of non-scale factors; UE represents the total basic workload, that is, the result calculated in step S4; k represents the number of preset adjustment factors, that is, the number of non-scale influencing factors participating in dynamic adjustment; This represents the j-th adjustment factor, which is a coefficient that quantifies the influence of the j-th non-scale factor. During the adjustment process, the basis for selecting each adjustment factor must be recorded (such as documents determining the project's urgency or assessment reports of technical difficulty) to ensure the transparency and reproducibility of the adjustment logic.

[0046] S6. Based on the corrected workload, the preset labor cost rate, and the preset cost allocation rules, calculate the direct labor cost, direct non-labor cost, indirect labor cost, and indirect non-labor cost respectively; summarize the direct labor cost, direct non-labor cost, indirect labor cost, and indirect non-labor cost to obtain the total cost of the adaptation and transformation project.

[0047] Specifically, when calculating direct labor costs, based on the corrected workload, the preset labor cost rate, and the hourly rate conversion standard, the formula is as follows: Where DHC represents direct labor cost, which is the cost of personnel directly involved in the adaptation and modification work; AE represents the corrected workload, which is the result calculated in step S5; T represents the number of standard working days per month, and H represents the standard working hours per day, which are used to convert the workload from "person-hours" to "person-months"; R represents the preset labor cost rate, which is the personnel cost per "person-month", and this rate can be determined by combining the market conditions and personnel skill levels in the project location.

[0048] Direct non-human costs are calculated item by item based on the actual non-human expenditures incurred in the project. This includes non-personnel costs directly used in the project during the adaptation and modification process (such as domestic adaptation testing and certification fees, license fees for adaptation testing tools, and temporary rental fees for hardware equipment). The calculation is based on quotations and payment vouchers provided by service providers to ensure that each cost has a clear source.

[0049] Indirect labor costs and indirect non-labor costs need to be calculated according to the preset cost allocation rules, and the corresponding formula is: IHC represents indirect human resource costs, which are the costs of personnel who indirectly serve the project (such as project management personnel and quality assurance personnel). The ratio of indirect labor costs to direct labor costs is determined based on the company's internal cost allocation system. INC represents indirect non-human costs, which are non-personnel costs indirectly used for projects (such as the allocated portion of office space rental fees and utility fees). DNC represents direct non-human costs, which is the result calculated above. This represents the proportion of indirect non-human costs allocated, that is, the proportion of indirect non-human costs to the sum of direct human costs and direct non-human costs, which is also determined according to the enterprise's cost allocation system.

[0050] The total cost of the adaptation and renovation project is obtained by summing up direct labor costs, direct non-labor costs, indirect labor costs, and indirect non-labor costs. The formula is as follows: Here, SADC represents the total cost of the adaptation and transformation project, which is the sum of all costs involved throughout the project's entire lifecycle; DHC represents direct labor costs, DNC represents direct non-labor costs, IHC represents indirect labor costs, and INC represents indirect non-labor costs, all of which are the results calculated separately above. During the aggregation process, the numerical precision of each cost item needs to be standardized (e.g., retaining two decimal places), and a detailed cost report should be generated to record the calculation logic and basis for each cost item, ensuring that the total cost is auditable and verifiable.

[0051] The aforementioned method for assessing adaptation and transformation costs begins by analyzing the requirements of the application software to be modified and the target information technology environment, identifying and generating a set of objects to be adapted. This set is then quantified and counted based on a pre-defined adaptation point counting rule to obtain the total unadjusted adaptation point scale. Subsequently, a requirement change factor is introduced to adjust this scale, generating a more accurate adjusted adaptation scale. Next, by acquiring productivity benchmark data and combining it with the workload of non-adaptive construction tasks, the total basic workload is calculated, and dynamically corrected using a pre-defined adjustment factor to generate the corrected workload. Finally, based on this corrected workload and pre-defined labor cost rates and cost allocation rules, the various sub-costs are systematically calculated and summarized to obtain the total project cost. This method shifts the assessment of information technology software adaptation and transformation costs from relying on subjective experience to a structured rule-based and data-driven approach, effectively improving the objectivity of the assessment process, the accuracy of the results, and the adaptability to dynamic changes in the project, thus providing reliable technical support for project budget control and resource optimization.

[0052] In one optional embodiment, based on the set of objects to be adapted, adaptation points are counted according to a preset adaptation point counting rule to obtain the adaptation point count result, and the total scale of unadjusted adaptation points is calculated based on the adaptation point count result, including:

[0053] S21. For each configuration file in the middleware adaptation set of objects to be adapted, treat the configuration file as a configuration class counter item, and assign the first industry statistical average value to each configuration class counter item to obtain the adaptation point value corresponding to each configuration class counter item.

[0054] Specifically, this step involves counting the configuration files in the set of objects to be adapted that belong to middleware adaptation. First, the scope of configuration files in the middleware adaptation scenario is clarified. These configuration files are the parameter configuration carriers that the middleware depends on at runtime, including but not limited to the middleware service port configuration file (such as server.xml of application server middleware), connection pool parameter configuration file (such as db.properties), log strategy configuration file (such as log4j.xml), etc. All configuration files related to middleware runtime parameters need to be filtered out from the set of objects to be adapted, excluding non-middleware configuration files (such as the application's own business configuration file).

[0055] After identifying the middleware configuration files to be adapted, each independent configuration file is defined as a configuration class counter item, meaning each configuration file corresponds to an independent counting unit, ensuring consistent counting granularity. Subsequently, each configuration class counter item is assigned a first industry statistical mean. This mean is a quantitative result obtained through statistical analysis (such as arithmetic mean after removing extreme values ​​and quantile calculation) of actual data on the "workload of a single configuration file modification" collected from a large number of similar middleware adaptation projects, reflecting the average complexity of adapting and modifying a single middleware configuration file. Finally, the adaptation point value corresponding to each configuration class counter item is "1 (single counter item) × first industry statistical mean," which directly quantifies the scale of adaptation and modification for a single middleware configuration file.

[0056] S22. For each application interface in the middleware adaptation set that belongs to the set of objects to be adapted, the application interface is treated as an interface class count item, and a second industry statistical mean is assigned to each interface class count item to obtain the adaptation point value corresponding to each interface class count item.

[0057] Specifically, this step focuses on application programming interfaces (APIs) within the middleware adaptation set of objects to be adapted. APIs in middleware adaptation scenarios are the interface carriers through which the application software to be modified interacts with the middleware for data exchange and function calls. These include, but are not limited to, APIs provided by the middleware (such as message sending APIs for message middleware, key-value operation APIs for caching middleware), protocol interfaces (such as HTTP-based REST interfaces, TCP-based custom protocol interfaces), and Web service interfaces (such as SOAP interfaces). All APIs involving middleware interaction must be identified from the set of objects to be adapted, excluding interfaces between modules within the application.

[0058] Each independent application programming interface (API) is defined as an API class counter, meaning a single API corresponds to an independent counting unit, ensuring the distinction between API class counters and configuration class counters. A second industry statistical mean is assigned to each API class counter. This mean is also derived from historical data statistics of middleware API adaptation projects within the industry, and is stratified statistically based on factors such as API protocol type, data transmission volume, and interaction complexity (e.g., the mean values ​​for simple REST APIs and complex custom protocol APIs need to be calculated separately) to accurately reflect the difficulty of modifying different types of middleware APIs. The adaptation point value corresponding to each API class counter is "1 (single counter) × second industry statistical mean", quantifying the scale of middleware API adaptation.

[0059] S23. For each data manipulation language or data query language statement in the set of objects to be adapted that belongs to database adaptation, treat the data manipulation language or data query language statement as a DML / DQL class count item, and assign a third industry statistical mean to each DML / DQL class count item to obtain the adaptation point value corresponding to each DML / DQL class count item.

[0060] Specifically, this step counts the Data Manipulation Language (DML) or Data Query Language (DQL) statements within the target application set that fall under database adaptation. First, the scope of DML and DQL statements is clarified: DML statements are used to modify database data, including INSERT, UPDATE, and DELETE; DQL statements are used to query database data, primarily SELECT statements (including single-table queries, multi-table joins, and subqueries). All DML / DQL statements interacting with the original database must be extracted from the application's code, excluding statements that do not involve database operations (such as variable assignment statements within the application).

[0061] Each independent DML or DQL statement is defined as a DML / DQL class counter item, meaning a single statement corresponds to one counter unit. If a statement contains multiple subqueries (such as nested SELECT statements), it is still counted as a "single statement" as a counter item, ensuring the uniqueness of the counter unit. A third-party industry statistical mean is assigned to each DML / DQL class counter item. This mean is obtained by statistically analyzing the "workload for modifying a single DML / DQL statement" in similar database adaptation projects. Factors such as statement complexity (e.g., the mean difference between a simple single-table SELECT statement and a multi-table join UPDATE statement), and the degree of syntactic difference between the original database and the target domestic database are considered to match the modification difficulty of different statements. The adaptation point value corresponding to each DML / DQL class counter item is "1 (single counter item) × third-party industry statistical mean," thus quantifying the scale of database statement adaptation.

[0062] S24. For each Data Definition Language Structure object in the set of objects to be adapted that belongs to database adaptation, treat the Data Definition Language Structure object as a DDL class counter item, and assign the fourth industry statistical mean to each DDL class counter item to obtain the adaptation point value corresponding to each DDL class counter item.

[0063] Specifically, this step processes the Data Definition Language (DDL) structure objects in the database adaptation set. DDL structure objects are objects used to define database structures, including but not limited to database tables, views, stored procedures, functions, and triggers. All DDL structure objects related to the application software to be modified need to be exported from the original database, excluding system-level DDL objects (such as system tables and system functions) that come with the database system.

[0064] Each independent DDL structure object is defined as a DDL class count item, meaning a single table, view, or stored procedure corresponds to a separate count unit. Even if multiple DDL structure objects have dependencies (e.g., a view depends on a table), they are still counted as independent objects as separate count items. A fourth industry statistical mean is assigned to each DDL class count item. This mean is based on historical data from database DDL object adaptation projects within the industry, combined with factors such as the type of DDL structure object (e.g., the mean difference between simple tables and complex stored procedures) and logical complexity (e.g., the number of lines of code in a stored procedure and the level of conditional judgments) to reflect the difficulty of modifying different DDL structure objects. The adaptation point value corresponding to each DDL class count item is "1 (single count item) × fourth industry statistical mean", quantifying the scale of database structure object adaptation.

[0065] S25. For each page in the browser adaptation set that involves compatibility adjustments, treat the page as a page class counter item, and assign the fifth industry statistical mean to each page class counter item to obtain the adaptation point value corresponding to each page class counter item.

[0066] Specifically, this step targets pages that require browser adaptation and involve compatibility adjustments. Pages in browser adaptation scenarios are the front-end interactive carriers of the application software to be modified, including but not limited to HTML pages on the web and composite pages containing front-end scripts (JS) and style sheets (CSS). All pages that have functional abnormalities, style errors, or interactive failures in the target domestic browser (such as a domestic security browser) need to be screened out, and pages that are already fully compatible in the target browser and do not require adjustment are excluded.

[0067] Each page requiring compatibility adjustments is defined as a page category counter, meaning a single page corresponds to one counting unit. If a page contains multiple subpages (such as pop-up pages or iframe embedded pages), it needs to be counted separately according to the "independent functional page" standard (e.g., an independent pop-up page is counted as a separate counter). A fifth industry statistical mean is assigned to each page category counter. This mean is obtained by statistically analyzing the "workload for compatibility adjustments on a single page" in similar browser adaptation projects. Factors such as page complexity (e.g., the difference in mean between simple static pages and complex pages with numerous dynamic interactions) and the types of compatibility issues involved (e.g., CSS style compatibility, JS script compatibility, and national cryptographic plugin integration compatibility) need to be considered to match the difficulty of modifying different pages. The adaptation point value corresponding to each page category counter is "1 (single counter) × fifth industry statistical mean," thus quantifying the scale of browser page adaptation.

[0068] S26. For each plugin to be adapted that belongs to the plugin adaptation set, treat the plugin to be adapted as a plugin class count item, and assign the sixth industry statistical mean to each plugin class count item to obtain the adaptation point value corresponding to each plugin class count item.

[0069] Specifically, this step addresses plugins that need adaptation within the plugin adaptation category. Plugins in the plugin adaptation scenario are external functional plugins that the application software to be modified depends on, including but not limited to IE ActiveX plugins (such as file upload plugins and printing plugins) and third-party functional plugins (such as PDF preview plugins and chart display plugins) that the original system depends on. All plugins that cannot run properly or have compatibility issues in the target domestic IT environment (such as domestic operating systems and domestic browsers) must be screened out, and plugins that can be compatible without modification must be excluded.

[0070] Each plugin requiring adaptation is defined as a plugin category counter, meaning a single plugin corresponds to one counter unit. If a plugin contains multiple functional modules (e.g., a comprehensive office plugin includes document editing and email sending modules), it is still counted as a "single plugin" counter. Each plugin category counter is assigned a sixth industry statistical mean. This mean is based on historical data from plugin adaptation projects within the industry, combined with factors such as plugin functional complexity (e.g., the difference in mean values ​​between simple tool plugins and complex business plugins) and replacement difficulty (e.g., whether there are mature domestic plugin alternatives, or whether custom development of alternative functions is required), to reflect the difficulty of modifying different plugins. The adaptation point value corresponding to each plugin category counter is "1 (single counter) × sixth industry statistical mean," quantifying the scale of plugin adaptation.

[0071] S27. Sum the fit point values ​​corresponding to all count items obtained in steps S21 to S26 to generate the total unadjusted fit point size; where the total unadjusted fit point size... Through formula calculate, Indicates the first The number of items in each category. Indicates the relationship with the first The industry statistical mean corresponding to the category count item, the first The class count item is one of the following: configuration class count item, interface class count item, DML / DQL class count item, DDL class count item, page class count item, and plugin class count item.

[0072] Specifically, this step involves summarizing all the adaptation point values ​​obtained from steps S21 to S26 to generate the total scale of unadjusted adaptation points. First, the adaptation point values ​​for configuration (S21), interface (S22), DML / DQL (S23), DDL (S24), page (S25), and plugin (S26) are collected to ensure that no adaptation point values ​​are omitted or duplicated (e.g., the same object to be adapted is not counted repeatedly across categories).

[0073] The total size of the unadjusted fit points is then obtained through summation, and its calculation formula is as follows: Where US represents the total size of unadjusted adaptation points, which is a quantitative result of the overall adaptation and transformation scale of the set of objects to be adapted, reflecting the total transformation amount of all objects to be adapted; n represents the total number of categories of the count item, here These correspond to six categories of counters: configuration class counters, interface class counters, DML / DQL class counters, DDL class counters, page class counters, and plugin class counters. This represents the number of items in the i-th category, i.e., the total number of items in each category in steps S21 to S26 (such as the total number of middleware configuration files in S21, the total number of DML / DQL statements in S23). This represents the industry statistical mean corresponding to the i-th type of count item, where type 1 (configuration type) corresponds to the statistical mean of the first industry, type 2 (interface type) corresponds to the statistical mean of the second industry, type 3 (DML / DQL type) corresponds to the statistical mean of the third industry, type 4 (DDL type) corresponds to the statistical mean of the fourth industry, type 5 (page type) corresponds to the statistical mean of the fifth industry, and type 6 (plugin type) corresponds to the statistical mean of the sixth industry. This formula can systematically integrate the modification scale of various objects to be adapted, obtaining a unified total scale of unadjusted adaptation points, providing basic data for subsequent scale adjustments and workload calculations.

[0074] In one optional embodiment, the corrected workload is generated by dynamically adjusting the total basic workload using a preset adjustment factor, including:

[0075] S31. Determine the value of the application domain adjustment factor based on the business attributes of the application software to be modified.

[0076] Specifically, the business attributes of the application software to be modified refer to the industry sectors and core business scenarios served by the software, such as government office sectors (e.g., document circulation systems), financial transaction sectors (e.g., core bank payment systems), medical diagnosis and treatment sectors (e.g., electronic medical record systems), and industrial control sectors (e.g., production line monitoring systems). Software in different sectors has different business compliance requirements, data sensitivity, and system stability requirements, and the complexity and workload of adaptation and modification also vary.

[0077] When determining business attributes, the core service scenarios and industry affiliation of the software are clarified by analyzing project requirements documents, software function specifications, and industry regulatory standards. For example, if the software needs to meet the guidelines for information technology risk management in the financial industry, it is classified as belonging to the financial sector; if it needs to meet the requirements for government information system integration services, it is classified as belonging to the government sector. Subsequently, the application domain adjustment factor value is determined based on general patterns of industry adaptation and transformation: for domains with complex business logic and high compliance requirements (such as finance and healthcare), the factor value needs to be greater than 1 due to the need for additional security compliance verification and data encryption adaptation; for domains with simple business logic and conventional compliance requirements (such as general enterprise office systems), the factor value is close to 1. The determination of factor values ​​should refer to historical experience data from similar adaptation projects in the industry to ensure that they match the complexity of the domain transformation and avoid errors in workload estimation due to omissions of domain characteristics.

[0078] S32. Determine the value of the integrity level adjustment factor based on the integrity level assessed by the application software to be modified according to the preset standard.

[0079] Specifically, the pre-defined standard refers to the system integrity evaluation specifications commonly used in the software industry. This standard typically classifies software integrity into different levels (e.g., Level A, Level B, Level C, Level D) based on dimensions such as the completeness of the software requirements specification, the detail of the design documents, the coverage of code comments, the coverage of test cases, and the completeness of the operation and maintenance manual. Different levels correspond to the degree to which existing software documentation supports adaptation and modification. The higher the integrity level, the less additional documentation or logic refactoring is required during the modification process, resulting in smaller workload deviations; conversely, lower levels require additional work such as requirements completion, documentation review, and reverse logic derivation, leading to larger workload deviations.

[0080] When assessing the completeness level, each indicator is checked against the preset standard. For example, check whether the requirements document covers all business function inputs and outputs, and exception handling rules; check whether the design document clearly defines the system architecture layers and inter-module interfaces; check whether the test cases cover core business processes and boundary scenarios. After determining the corresponding completeness level based on the verification results, adjust the factor values ​​to match the completeness level: Level A (complete data, no supplementary work) factor value close to 1; Level B (basically complete data, only minor supplementation required) factor value slightly higher than 1; Level C (partially missing data, requiring significant supplementation) factor value further increases; Level D (severely missing data, requiring extensive refactoring) factor value is the highest. The factor value must match the additional workload corresponding to the completeness level. For example, Level D software requires reverse engineering of the core logic, with additional workload accounting for 20% of the basic workload; therefore, the factor value can be set to 1.2 to ensure that the impact of supplementary workload is quantified through factor analysis.

[0081] S33. Determine the value of the development language adjustment factor based on the main development language type of the application software to be modified.

[0082] Specifically, the main development language type of the application software to be modified refers to the programming language used by the core functional modules and core business logic of the software (such as Java, C++, Python, .NET, Go, etc.). Different development languages ​​have different levels of maturity in adaptation, toolchain support, and syntax compatibility in the domestic IT innovation environment, which directly affects the efficiency and workload of adaptation and modification. For example, Java is highly efficient to modify due to the abundance of adaptation tools (such as domestic JDK and middleware) and high syntax compatibility in the domestic IT innovation ecosystem; C++ is less efficient to modify because it needs to adapt to the compilation environment of domestic CPU architectures (such as ARM64 and LoongArch) and some low-level library functions have compatibility issues; and less common programming languages ​​(such as COBOL) are extremely difficult to modify due to the scarcity of toolchains in the domestic IT innovation environment, requiring additional resources for tool development or code refactoring.

[0083] When determining the primary development language type, the software codebase, development logs, and technical architecture documents are analyzed to identify the programming language with the highest proportion (e.g., core module code accounting for over 60%) or the greatest impact on adaptation. For example, if the software front-end uses Vue.js and the back-end uses Java, and the back-end is the core business layer, then Java is determined as the primary development language. Subsequently, a factor value is determined based on the maturity of the language's adaptation to the domestic IT innovation ecosystem: languages ​​with abundant adaptation tools and high compatibility (such as Java and Python) have a factor value close to 1; languages ​​requiring additional adaptation of compilation environments or library functions (such as C++) have a factor value greater than 1; and less common languages ​​or languages ​​without domestic IT innovation tool support have a factor value significantly greater than 1. The determination of the factor value must refer to the current state of language support in the domestic IT innovation technology ecosystem (such as the compatibility list of languages ​​for domestic operating systems and compilers) to ensure it matches the actual transformation difficulty and avoids underestimating the workload due to language characteristics.

[0084] S34. Determine the team size adjustment factor based on the planned number of personnel to be deployed for the adaptation and transformation project.

[0085] Specifically, the planned number of personnel refers to the total number of core personnel planned to participate in the adaptation and transformation work during the project initiation phase. This includes developers, testers, technical consultants, and other personnel directly involved in the transformation implementation, but excludes indirect support personnel such as administrative support and project management. The impact of team size on workload is mainly reflected in communication and collaboration costs and task execution efficiency: Small teams (e.g., less than 10 people) have clear division of labor, short communication links, and smooth task connection, resulting in a small deviation between the actual workload and the basic workload; Large teams (e.g., more than 30 people) have more detailed division of labor and frequent cross-module collaboration, requiring additional time for requirements synchronization, progress coordination, code merging, etc., resulting in an actual workload higher than the basic workload; Medium-sized teams (e.g., 10-30 people) have collaboration costs and efficiency between the two, with a moderate degree of workload deviation.

[0086] When determining the planned personnel allocation, it is necessary to clarify the planned number of personnel for each position based on the project resource planning document and team building plan (e.g., 6 developers, 3 testers, 1 technical consultant, totaling 10 people). Then, the factor value should be determined based on the correlation between team size and collaboration efficiency: small teams have lower collaboration costs, so the factor value is close to 1; medium-sized teams require less coordination work, so the factor value is slightly higher than 1; large teams have higher collaboration costs, so the factor value is greater than 1. The determination of the factor value should refer to team size efficiency models in software project management (such as Brooks' Law) to ensure it matches the actual collaboration costs. For example, if the collaboration cost of a 30-person team accounts for 15% of the basic workload, then the factor value can be set to 1.15, quantifying the impact of collaboration costs on workload through factor analysis.

[0087] S35. Based on the total basic workload, and considering the values ​​of the application domain adjustment factor, integrity level adjustment factor, programming language adjustment factor, and team size adjustment factor, calculate the corrected workload; where, the corrected workload... Through formula calculate, This indicates the total amount of basic work. Indicates the adjustment factor for the application area. Indicates the integrity level adjustment factor. Indicates the language adjustment factor for development. This indicates the team size adjustment factor.

[0088] Specifically, first, confirm the validity of each adjustment factor value. The application domain adjustment factor (A) must be consistent with the industry attributes of the software to be modified, the integrity level adjustment factor (IL) must be consistent with the preset standard evaluation results, the development language adjustment factor (L) must match the main development language type, and the team size adjustment factor (T) must correspond to the planned number of personnel, ensuring that all four types of factors can accurately reflect the actual influencing factors of the project.

[0089] The corrected workload is then calculated using the following formula: Here, AE represents the corrected workload, which is the final workload after comprehensively considering various non-scale influencing factors and is the core basis for subsequent cost calculation; UE represents the total basic workload, which is the sum of the "adaptive construction basic workload and non-adaptive construction workload" in the aforementioned steps, and is the basic benchmark for workload adjustment; A represents the application domain adjustment factor, which is the coefficient determined in step S31 that quantifies the impact of industry attributes on workload; IL represents the integrity level adjustment factor, which is the coefficient determined in step S32 that quantifies the impact of software data integrity on workload; L represents the development language adjustment factor, which is the coefficient determined in step S33 that quantifies the impact of programming language adaptation difficulty on workload; and T represents the team size adjustment factor, which is the coefficient determined in step S34 that quantifies the impact of team collaboration costs on workload.

[0090] The formula employs multiplication logic because the four adjustment factors independently affect workload from different dimensions, and their effects are cumulative. For example, software in the financial field (A>1) simultaneously achieves Level D integrity (IL>1), thus requiring additional workload for both domain compliance and data supplementation. Multiplication quantifies the cumulative effect of these two types of impacts. During the calculation, it is crucial to ensure that all factor values ​​are in uniform units (dimensionless coefficients) to avoid errors due to unit differences. The final corrected workload must retain the same precision as the total basic workload (e.g., one decimal place) to provide an accurate basis for subsequent cost calculations.

[0091] In one optional embodiment, this adaptation and modification cost assessment method further includes the following steps:

[0092] S31. Collect actual workload data, actual adjustment factor values, and final actual cost data of multiple completed historical adaptation and transformation projects to build a historical project database.

[0093] Specifically, this step requires collecting key data from multiple completed historical adaptation and modification projects to build a historical project database. "Completed projects" here refers to adaptation and modification projects that have passed acceptance and have complete completion documentation. Projects that are incomplete, have incomplete data records, or were terminated due to abnormalities must be excluded to ensure the validity and representativeness of the data. The collected data dimensions should revolve around the core objective of "optimization of development language tuning factors," specifically including three types of core data:

[0094] The first category is actual workload data, which needs to be broken down to the actual person-hours invested in each stage of the project. This includes the actual person-hours for adaptation and build-related work (such as code-level modification and adaptation testing), the actual person-hours for non-adaptation and build-related work (such as data migration and environment deployment), and the additional person-hours due to development language compatibility issues (such as the time spent solving compilation compatibility issues of specific languages ​​and replacing language-specific dependency libraries). The data must come from the project time management system records, the daily / weekly reports of developers, and the workload statistics section of the project completion report to ensure consistency with the actual execution.

[0095] The second category is the actual values ​​of adjustment factors used. It is necessary to record the actual values ​​of the development language adjustment factors used during project implementation (including the initial default values ​​and the values ​​adjusted due to changes in language adaptation difficulty during implementation), as well as the actual values ​​of other adjustment factors used at the same time (application area, integrity level, team size). It is also necessary to note the basis for the selection of adjustment factor values ​​(such as industry data referenced at the time and project technical review conclusions) so as to facilitate subsequent analysis of the interaction between development language factors and other factors.

[0096] The third category is the final actual cost data, including direct labor costs (costs calculated based on actual workload and labor rates), direct non-labor costs (such as the cost of tools purchased for language adaptation and technical consulting fees), and indirect costs. The data must come from the project's financial settlement report and expense reimbursement vouchers to ensure the correlation between cost data and workload data, and to provide a cost dimension reference for verifying the effect of factor optimization.

[0097] After data collection, a historical project database is constructed according to a standardized structure. Database fields can be designed as follows: project unique identifier ID, project business domain, main development language type of the software to be modified (e.g., Java, C++, Python), software integrity level, planned team size, actual usage values ​​of various adjustment factors, actual workload at each stage, final actual cost, project completion time, and records of key issues encountered during the development language adaptation process (e.g., whether unforeseen language compatibility issues occurred). The database can be stored using a relational database (e.g., MySQL, DM8), supporting data filtering and related queries by development language type, business domain, and other dimensions, providing structured data support for subsequent regression analysis.

[0098] S32. Based on the historical project database, the default value of the development language adjustment factor is fitted and corrected through regression analysis to obtain the optimized value of the development language adjustment factor.

[0099] Specifically, the core logic of regression analysis is to establish a mathematical model of "development language type - actual workload deviation" to identify the quantitative relationship between development language type and workload estimation deviation, and then correct the original default factor values ​​so that the corrected factors can more accurately reflect the actual impact of the adaptation difficulty of different development languages ​​on workload.

[0100] In practice, regression analysis should be conducted according to the following steps:

[0101] The first step is data preprocessing. This involves selecting complete project samples from the historical project database (e.g., the sample size must cover at least 5 programming languages, with at least 10 valid projects per language to ensure statistical significance), and defining key variables: the independent variable is "programming language type" (which requires encoding conversion, such as encoding Java as 1, C++ as 2, Python as 3, .NET as 4, etc.), and control variables that may affect workload deviation (e.g., software size, integrity level, to avoid bias caused by single-variable analysis); the dependent variable is "workload estimation deviation rate," calculated as "(actual total project workload - corrected workload calculated based on the original default programming language adjustment factor) / corrected workload calculated based on the original default factor × 100%". A positive deviation rate indicates that the original default factor underestimated the workload, while a negative rate indicates an overestimation of the workload.

[0102] The second step is to select a regression model. Based on the data characteristics, choose an appropriate regression analysis method: if there is a linear relationship between the type of development language and the workload deviation rate, a multiple linear regression model can be used (with the development language encoding and control variables as independent variables, and the deviation rate as the dependent variable); if there is a non-linear relationship (such as a significant change in the deviation rate of a certain type of language after its scale exceeds a certain threshold), a stepwise regression or multinomial regression model can be used. During model construction, analysis of variance (ANOVA) is needed to test the explanatory power of the independent variables on the dependent variable. (Coefficient of determination) verifies model fit (usually) A p-value greater than 0.6 indicates that the model can explain the changes in the deviation rate well, and variables without statistical significance (such as control variables with a p-value greater than 0.05) are excluded.

[0103] The third step is factor value correction calculation. Based on the output of the regression model, the optimized development language adjustment factor values ​​are calculated. For example, if the model finds that the average workload deviation rate for Java projects is -5% (meaning the original default factor of 1.0 overestimated the workload by 5%), then the optimized Java development language adjustment factor value = original default value × (1 + average deviation rate) = 1.0 × (1 - 0.05) = 0.95; and the average workload deviation rate for C++ projects is +8% (meaning the original default factor of 1.1 underestimated the workload by 8%), then the optimized C++ factor value = 1.1 × (1 + 0.08) = 1.188. The corrected values ​​need to be validated for reasonableness by combining industry common sense and project experience, such as avoiding factor values ​​of 0 or negative numbers, and ensuring that the correction results reflect the actual difficulty of development language adaptation.

[0104] S33. Replace the original value of the development language adjustment factor used for subsequent dynamic adjustment calculations of the project with the optimized development language adjustment factor value.

[0105] Specifically, this step requires replacing the original values ​​used for dynamic adjustments in subsequent project calculations with the optimized development language adjustment factor values. This standardizes the updating and application of the factors, ensuring the optimization effect continues to impact subsequent project evaluations. The implementation follows a process of "standardized update - end-to-end synchronization - verification and iteration."

[0106] The first step is standardization updates. The optimized development language adjustment factor values ​​will be incorporated into the company's internal adaptation and modification cost assessment adjustment factor specifications. This will clearly define the optimized value for each development language type, the effective date, the corresponding historical data batch number, and the regression analysis report number. It will also include notes on the applicable scope of the values ​​(e.g., whether they only apply to specific business areas or projects of a specific software scale). The specification updates must be confirmed through a technical review meeting. Review members will include cost assessment experts, development technical leads, and project management leaders to ensure the accuracy and feasibility of the values.

[0107] Secondly, end-to-end synchronization is crucial, ensuring that the optimized values ​​are synchronized to all cost assessment-related tools, systems, and documents. If the company uses automated cost assessment tools (such as Excel templates or customized assessment systems), the assignment logic and drop-down options for the language factors in the tool need to be updated. If a manual assessment process is used, the updated factor comparison table needs to be distributed to the assessors, and specialized training should be organized to explain the background of the numerical optimization, the basis for regression analysis, and application precautions (e.g., after adjusting the values ​​for a certain language, the compatibility between the language version and the compatible tool needs to be carefully checked during the assessment). Simultaneously, the optimized factor values ​​should be synchronized to the project initiation review material template and cost estimation report template to ensure that the assessment output documents reflect the optimized factor values.

[0108] Finally, verification and iteration are performed. The optimized values ​​are set for a specific verification period (e.g., 3 months, 5 project cycles). During the verification period, projects using the new values ​​are tracked, and actual and estimated workload data are collected. The new workload deviation rate is calculated, and it is verified whether the optimized values ​​have reduced the deviation rate (e.g., from ±15% to within ±8%). If verification reveals that the values ​​for some programming languages ​​still have deviations, the latest project data needs to be added from the historical project database, and the regression analysis process in step S32 is repeated for secondary correction. This forms a closed loop of "data collection - analysis and correction - application verification - secondary optimization," ensuring that the programming language adjustment factors can be continuously optimized with technological iterations (e.g., the emergence of new programming languages, upgrades to the domestic IT innovation language toolchain) and the accumulation of project experience, always maintaining adaptability to real-world scenarios.

[0109] The aforementioned method for assessing adaptation and transformation costs begins by analyzing the requirements of the application software to be modified and the target information technology environment, identifying and generating a set of objects to be adapted. This set is then quantified and counted based on a pre-defined adaptation point counting rule to obtain the total unadjusted adaptation point scale. Subsequently, a requirement change factor is introduced to adjust this scale, generating a more accurate adjusted adaptation scale. Next, by acquiring productivity benchmark data and combining it with the workload of non-adaptive construction tasks, the total basic workload is calculated, and dynamically corrected using a pre-defined adjustment factor to generate the corrected workload. Finally, based on this corrected workload and pre-defined labor cost rates and cost allocation rules, the various sub-costs are systematically calculated and summarized to obtain the total project cost. This method shifts the assessment of information technology software adaptation and transformation costs from relying on subjective experience to a structured rule-based and data-driven approach, effectively improving the objectivity of the assessment process, the accuracy of the results, and the adaptability to dynamic changes in the project, thus providing reliable technical support for project budget control and resource optimization.

[0110] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0111] Based on the same inventive concept, this application also provides a system for implementing the adaptation and modification cost assessment method described above. The solution provided by this system is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more adaptation and modification cost assessment system embodiments provided below can be found in the limitations of the adaptation and modification cost assessment method described above, and will not be repeated here.

[0112] In one exemplary embodiment, such as Figure 2 As shown, an adaptive modification cost assessment system 20 is provided to implement the methods in the above-described method embodiments. The system includes:

[0113] The requirements analysis and object identification module 21 is used to perform requirements analysis on the application software to be modified and the target information technology innovation environment, identify all objects that need to be adapted for code-level compatibility modification, and generate a set of objects to be adapted.

[0114] The adaptation point quantization calculation module 22 is used to count adaptation points based on the set of objects to be adapted, according to the preset adaptation point counting rules, to obtain the adaptation point counting results, and to calculate the total scale of unadjusted adaptation points based on the adaptation point counting results.

[0115] The scale dynamic optimization module 23 is used to perform scale adjustment calculations based on the total scale of the unadjusted adaptation points and in combination with preset demand change factors, and generate the adjusted adaptation scale.

[0116] The workload basic calculation module 24 is used to obtain the productivity benchmark data of the adaptive construction class, calculate the basic workload of the adaptive construction class based on the adjusted adaptation scale and productivity benchmark data, obtain the workload of the non-adaptive construction class, add the basic workload of the adaptive construction class to the workload of the non-adaptive construction class, and generate the total basic workload.

[0117] The workload dynamic correction module 25 is used to dynamically adjust the total basic workload using a preset adjustment factor to generate the corrected workload.

[0118] The cost comprehensive accounting module 26 is used to calculate direct labor costs, direct non-labor costs, indirect labor costs, and indirect non-labor costs based on the corrected workload, preset labor cost rates, and preset cost allocation rules; and to summarize the direct labor costs, direct non-labor costs, indirect labor costs, and indirect non-labor costs to obtain the total cost of the adaptation and transformation project.

[0119] Embodiments of this application also provide a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the aforementioned method embodiments.

[0120] Embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0121] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0122] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A method for assessing the cost of adaptation and modification, characterized in that, The method includes: S1. Conduct requirements analysis on the application software to be modified and the target information technology innovation environment, identify all objects that need to be adapted for code-level compatibility modification, and generate a set of objects to be adapted. S2. Based on the set of objects to be adapted, the adaptation points are counted according to the preset adaptation point counting rules to obtain the adaptation point counting results, and the total scale of unadjusted adaptation points is calculated based on the adaptation point counting results. S3. Based on the total scale of the unadjusted adaptation points, and combined with the preset demand change factor, the scale adjustment calculation is performed to generate the adjusted adaptation scale. S4. Obtain the productivity benchmark data for the adaptive construction class, and calculate the basic workload of the adaptive construction class based on the adjusted adaptation scale and the productivity benchmark data; obtain the workload of the non-adaptive construction class, and add the basic workload of the adaptive construction class to the workload of the non-adaptive construction class to generate the total basic workload. S5. Based on the total basic workload, dynamically adjust it using a preset adjustment factor to generate the corrected workload; S6. Based on the corrected workload, the preset labor cost rate, and the preset cost allocation rules, calculate the direct labor cost, direct non-labor cost, indirect labor cost, and indirect non-labor cost respectively; summarize the direct labor cost, the direct non-labor cost, the indirect labor cost, and the indirect non-labor cost to obtain the total cost of the adaptation and transformation project.

2. The method according to claim 1, characterized in that, The step of counting adaptation points based on the set of objects to be adapted, according to a preset adaptation point counting rule, to obtain the adaptation point counting result, and calculating the total scale of unadjusted adaptation points based on the adaptation point counting result, includes: S21. For each configuration file belonging to the middleware adaptation set in the object set to be adapted, the configuration file is taken as a configuration class count item, and a first industry statistical average is assigned to each configuration class count item to obtain the adaptation point value corresponding to each configuration class count item. S22. For each application interface belonging to the middleware adaptation set in the object set to be adapted, the application interface is taken as an interface class count item, and a second industry statistical mean is assigned to each interface class count item to obtain the adaptation point value corresponding to each interface class count item. S23. For each data operation language or data query language statement belonging to database adaptation in the set of objects to be adapted, the data operation language or data query language statement is taken as a DML / DQL class count item, and a third industry statistical mean is assigned to each DML / DQL class count item to obtain the adaptation point value corresponding to each DML / DQL class count item. S24. For each Data Definition Language Structure Object in the set of objects to be adapted that belongs to database adaptation, the Data Definition Language Structure Object is taken as a DDL class count item, and a fourth industry statistical mean is assigned to each DDL class count item to obtain the adaptation point value corresponding to each DDL class count item. S25. For each page in the set of objects to be adapted that belongs to browser adaptation and involves compatibility adjustment, the page is taken as a page class count item, and a fifth industry statistical mean is assigned to each page class count item to obtain the adaptation point value corresponding to each page class count item. S26. For each plugin to be adapted that belongs to the plugin adaptation set, the plugin to be adapted is taken as a plugin class count item, and a sixth industry statistical mean is assigned to each plugin class count item to obtain the adaptation point value corresponding to each plugin class count item. S27. Summing the fit point values ​​corresponding to all count items obtained in steps S21 to S26 to generate the total unadjusted fit point size; wherein, the total unadjusted fit point size Through formula calculate, Indicates the first The number of items in each category. Indicates the relationship with the first The industry statistical mean corresponding to the category count item, the first The class count item is one of the following: configuration class count item, interface class count item, DML / DQL class count item, DDL class count item, page class count item, and plugin class count item.

3. The method according to claim 1 or 2, characterized in that, The process of dynamically adjusting the total basic workload using a preset adjustment factor to generate the corrected workload includes: S31. Determine the value of the application domain adjustment factor based on the business attributes of the application software to be modified; S32. Determine the value of the integrity level adjustment factor based on the integrity level assessed by the application software to be modified according to the preset standard. S33. Determine the value of the development language adjustment factor based on the main development language type of the application software to be modified; S34. Determine the value of the team size adjustment factor based on the planned number of personnel to be deployed for the adaptation and transformation project; S35. Based on the total basic workload, and in conjunction with the values ​​of the application domain adjustment factor, the integrity level adjustment factor, the development language adjustment factor, and the team size adjustment factor, calculate the corrected workload; wherein, the corrected workload... Through formula calculate, This represents the total amount of basic work. This represents the adjustment factor for the application area. This represents the integrity level adjustment factor. This represents the language adjustment factor. This represents the team size adjustment factor.

4. The method according to claim 3, characterized in that, The method further includes: S31. Collect actual workload data, actual adjustment factor values ​​used, and final actual cost data of multiple completed historical adaptation and transformation projects to build a historical project database. S32. Based on the historical project database, the default value of the development language adjustment factor is fitted and corrected through regression analysis to obtain the optimized development language adjustment factor value. S33. Replace the original value of the development language adjustment factor used for subsequent dynamic adjustment calculations of the project with the optimized development language adjustment factor value.

5. An adaptation and modification cost assessment system for implementing the method according to any one of claims 1 to 4, characterized in that, The system includes: The requirements analysis and object identification module is used to perform requirements analysis on the application software to be modified and the target information technology innovation environment, identify all objects that need to be adapted and require code-level compatibility modification, and generate a set of objects to be adapted. The adaptation point quantization calculation module is used to count adaptation points based on the set of objects to be adapted, according to a preset adaptation point counting rule, to obtain the adaptation point counting result, and to calculate the total scale of unadjusted adaptation points based on the adaptation point counting result. The scale dynamic optimization module is used to perform scale adjustment calculations based on the total scale of the unadjusted adaptation points and in combination with preset demand change factors, and generate the adjusted adaptation scale. The workload basic calculation module is used to obtain the productivity benchmark data of the adaptive construction class, calculate the basic workload of the adaptive construction class based on the adjusted adaptation scale and the productivity benchmark data; obtain the workload of the non-adaptive construction class, add the basic workload of the adaptive construction class to the workload of the non-adaptive construction class, and generate the total basic workload. The workload dynamic correction module is used to dynamically adjust the total basic workload based on the preset adjustment factor to generate the corrected workload. The cost comprehensive accounting module is used to calculate direct labor costs, direct non-labor costs, indirect labor costs, and indirect non-labor costs based on the corrected workload, preset labor cost rates, and preset cost allocation rules; and to summarize the direct labor costs, direct non-labor costs, indirect labor costs, and indirect non-labor costs to obtain the total cost of the adaptation and transformation project.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 4.

Images