A software asset full life cycle cost prediction method and system

Abstract

The present application relates to the technical field of software asset management and cost data processing, in particular to a software asset full life cycle cost prediction method and system. Maintenance tasks are determined according to to-be-implemented repair and asset version dependency relationship, and reuse evidence containing version application conditions is generated through construction and regression verification of repair products; common modification tasks that meet the application conditions and share delivery tasks are merged, independent adaptation tasks are retained, remaining modification scale and cost driving factors are input into a parameter estimation model, workload is predicted, and remaining maintenance cost is converted; when the version dependency relationship changes, the reuse evidence is reviewed, unexecuted tasks associated with assets that fail the review are split, adaptation tasks are supplemented, and the prediction is updated; and remaining fees and cumulative actual costs are summarized. Through the linkage of reuse evidence and task reconstruction, the maintenance scale is adjusted synchronously with the application state of repair results, and the repeated counting of common modifications and the omission of independent adaptations are reduced.

Description

Technical Field

[0001] This invention relates to the field of software asset management and cost data processing technology, specifically to a method and system for predicting the full lifecycle cost of software assets. Background Technology

[0002] Software asset lifecycle cost forecasting is used to process cost data from software development, deployment, operation and maintenance to decommissioning. For self-developed or custom software, existing implementations typically extract software scale from requirements documents, code repositories, and project time records, describing the content to be developed and modified in function points or code volume. This is then combined with cost drivers such as product complexity, personnel capabilities, and development environment, and a parametric relationship between scale and workload is established or calibrated using historical project data. During forecasting, the scale to be estimated is input into the parametric model to obtain the development or maintenance workload, which is then converted into costs according to labor rates, and supplemented with licensing, operational resources, and decommissioning / migration costs. As the project progresses, the costs already incurred and the forecast costs for the unfinished phases are aggregated to form a lifecycle cost result updated by phase or period.

[0003] For software assets whose modules are shared by multiple applications, existing maintenance cost estimates also utilize dependency analysis to determine the scope of changes. In practice, the reference relationships between applications and modules are identified based on the module list and version history. Combining compilation dependencies, interface calls, or data structure relationships, the content to be repaired is mapped to the affected software objects, and the newly added and modified code is tallied to form the maintenance scale. Module reuse can be reflected in the estimate through reuse scale or adaptation workload. The scale of affected objects and corresponding cost drivers are used to estimate the maintenance workload. After maintenance activities are completed, subsequent estimates are updated using actual man-hours and modification records. The above processing typically organizes data around software objects and the scope of changes, and the asset summary results are aggregated according to the estimation results corresponding to each software object.

[0004] The actual deployment versions and build conditions of shared modules in different assets are not necessarily the same. Whether the same remediation result can be used by multiple assets will change with version updates and verification results. When using object size and the scope of dependency impact as the basis for estimation, the fact that a module is jointly referenced does not directly determine whether its modification work can be merged, and the confirmed reuse relationship cannot be directly carried over to the changed version. If the maintenance scale still follows the original object division or existing reuse records, the scope of modifications received by the parametric model may deviate from the current maintenance task to be performed. Therefore, the problem that needs to be solved is how to keep the scale division of common modifications and independent adaptations consistent with the actual maintenance task when the applicable status of remediation results changes across assets, and how to update the remaining cost prediction synchronously with the division. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for predicting the full lifecycle cost of software assets, which can solve the problems mentioned in the background art.

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

[0007] A method for predicting the full lifecycle cost of software assets includes: determining maintenance tasks based on the repairs to be implemented and the version dependencies of the software assets, and generating reuse evidence containing version applicability conditions based on the construction and regression verification results of the repair artifacts;

[0008] Merge common modification tasks that meet the applicable conditions of the version and share the same delivery task, and retain independent adaptation tasks;

[0009] The remaining modification scale and cost drivers of the common modification task and the independent adaptation task are input into the parameter estimation model to predict the workload and calculate the remaining maintenance cost.

[0010] When the version dependency relationship changes, the evidence is reviewed and reused, the unexecuted tasks that are not linked to the asset are split and reviewed, independent adaptation tasks are added and the remaining maintenance costs are recalculated.

[0011] The remaining maintenance costs are incorporated into other remaining expenses, and then added to the cumulative actual costs to obtain the total lifecycle predicted cost.

[0012] Preferably, the generation of the reuse evidence includes: binding the repaired artifact to the pre-repair module version, and determining the target asset of the referenced module version along the version dependency relationship;

[0013] Build a repair artifact according to the deployment configuration of the target asset, and perform regression verification on the artifact related to the change interface.

[0014] The verified module version and deployment configuration are written into the applicable conditions of the version, and the verification record is associated with the target asset and the corresponding maintenance task.

[0015] Preferably, when merging the common modification tasks, a common task record is established for the common delivery tasks, and the software assets corresponding to the common modification tasks are associated with the common task record;

[0016] For common modification tasks where the delivered products are the same but the delivery tasks are different, separate task records should be maintained.

[0017] Bind the independent adaptation task to the corresponding software asset and record the public task records it references;

[0018] The common modification scale is extracted based on the unexecuted portion of the common task record, and the adaptation modification scale is extracted based on the unexecuted portion of each independent adaptation task. The extracted modification scale is then input into the parameter estimation model.

[0019] Preferably, the changed version dependencies are matched with the applicable conditions of the version, and the re-build and regression verification are re-executed for target assets that do not match.

[0020] The association between the target asset that failed verification and the public modification task is marked as invalid, and the completed part and the unexecuted part corresponding to the invalid association are separated according to the execution record;

[0021] The unexecuted portion is converted into an independent modification task, and the modifications in the re-verification record that are outside the scope of the independent modification task are listed as independent adaptation tasks.

[0022] Update the version applicability conditions for the verified target assets and retain the common modification task associations, and recalculate the remaining modification scale based on the converted and supplemented tasks.

[0023] Preferably, the changed interfaces and dependency paths involved in the regression verification are associated with the verification records;

[0024] When the module version or the deployment configuration changes, the changed interface is located along the dependency path, the regression test cases associated with the verification record are executed, and the applicable conditions of the version are updated after the verification is passed; if the verification fails, the reuse evidence of the corresponding asset is marked as invalid.

[0025] Preferably, the common modification scale and the adaptive modification scale are recorded as scale entries with task source identifiers, and associated with model input records and activity decomposition records;

[0026] When multiple software assets reference the same common task record, only one size entry corresponding to the task source identifier is retained;

[0027] The scale items are aggregated according to the estimation granularity of the parameter estimation model and then input into the parameter estimation model to obtain the workload and convert it into the remaining maintenance cost according to the labor cost rate.

[0028] For verification of independent records, the activities covered by the parameter estimation model are checked according to the task source identifier and activity decomposition record. For verification work covered by the model, the model output is used. For verification work not covered, the remaining working hours of the corresponding verification task are converted into the remaining maintenance cost after being converted according to the labor rate.

[0029] Preferably, an index is established from the version applicability conditions to the reuse evidence, and a reverse index is established from the reuse evidence to the common modification task;

[0030] When a change in the version dependency is detected, evidence of the affected reuse is obtained through the index, and the associated common modification task is located along the inverted index.

[0031] Only the remaining modification scale of the tasks involved in the failure association is re-aggregated, and the corresponding remaining maintenance cost record is replaced with the re-estimated result, while the cost records not involved in the failure association are retained.

[0032] Preferably, a verification record is established for target assets for which re-verification results have not yet been obtained, and a first task set of shared repair products and a second task set of independently adapted repair products are established respectively;

[0033] The first task set references the common modification task, while the second task set retains an independent modification scale. Both are associated with the record to be verified and the remaining maintenance cost is calculated independently.

[0034] After obtaining the re-verification result, if the verification passes, the cost record corresponding to the first task set is used; if the verification fails, the cost record corresponding to the second task set is used, and the prediction record corresponding to the other task set is cancelled.

[0035] Preferably, for the aforementioned failure association, the actual working hours and costs of the completed portion are kept bound to the original public modification task;

[0036] For the unexecuted portion, establish an independent modification task that inherits the original task source, and determine the scale of new adaptation modifications according to the current version of the target asset corresponding to the aforementioned failure association;

[0037] When replacing the remaining maintenance cost record, only the original prediction entries corresponding to the unexecuted part are cancelled, and the prediction entries corresponding to the independent modification task and the newly added adaptive modification scale are written.

[0038] The actual costs of the original public modification tasks are collected once and then combined with the remaining maintenance costs after the replacement.

[0039] A software asset lifecycle cost prediction system includes a memory and a processor. The processor runs a program in the memory and performs the following: determining maintenance tasks based on the repairs to be implemented and the version dependencies of the software assets; and generating reuse evidence containing version applicability conditions based on the construction and regression verification results of the repair artifacts.

[0040] Merge common modification tasks that meet the version application conditions and share delivery tasks, and retain independent adaptation tasks;

[0041] The remaining modification scale and cost drivers of the common modification task and the independent adaptation task are input into the parameter estimation model to predict the workload and calculate the remaining maintenance cost.

[0042] When the version dependency relationship changes, the evidence is reviewed and reused, the unexecuted tasks that do not pass the asset association review are split and reviewed, the independent adaptation tasks are added and the remaining maintenance costs are recalculated.

[0043] The remaining maintenance costs are incorporated into other remaining expenses, and then added to the cumulative actual costs to obtain the total lifecycle predicted cost.

[0044] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0045] 1. By linking the reuse evidence formed from the construction and regression validation results with the version applicability conditions, the merging of common modification tasks has a verifiable basis. Modifications that share delivery tasks and meet the applicability conditions are counted as the same operation, while the adaptation content that each asset needs to implement remains independent. After version dependencies change, the review results directly determine whether related tasks remain shared. Unexecuted tasks associated with assets that fail the review are split and corresponding adaptation content is added, so that the remaining modification scale of the input parameter model is adjusted according to the applicability status of the repair results. Evidence judgment and task reconstruction jointly change the estimation input, reducing the scale omission caused by merging tasks based solely on module reference relationships, and the situation where common modifications are included in the estimation multiple times, so that the remaining lifecycle cost is based on the set of maintenance tasks corresponding to the current version status.

[0046] 2. After establishing an index from version applicability conditions to reused evidence and a reverse index from reused evidence to common modification tasks, version changes can locate affected tasks along existing correspondences. The recalculation scope is limited to the remaining modification scale involved in the failure association; prediction records not involved in the failure association are retained, reducing duplicate estimations for unaffected tasks. When splitting tasks, the actual working hours and costs of completed portions remain bound to the original common modification tasks, and only the prediction entries for unexecuted portions are replaced, allowing historical cost records and subsequent workload reconstruction to be handled separately. Combining task source identifiers and activity decomposition records, validation activities covered by the model retain the model output, while uncovered portions are recalculated based on remaining working hours, clarifying the source boundaries of different cost items, ensuring that partial updates retain the existing correspondence of actual costs, and constraining the aggregation scope of newly added prediction items. Attached Figure Description

[0047] Figure 1 A flowchart for predicting the total lifecycle cost of software assets;

[0048] Figure 2 A graph is constructed to estimate the remaining modification scale within the set;

[0049] Figure 3 A graph for estimating the remaining maintenance costs of the set;

[0050] Figure 4A comparison chart of remaining maintenance costs for mutually exclusive delivery scenarios;

[0051] Figure 5 Flowchart for task reconstruction and predictive update after reuse failure;

[0052] Figure 6 This is a diagram showing the cost breakdown for the entire lifecycle forecast. Detailed Implementation

[0053] Please refer to Figure 1 In one embodiment, a method for predicting the full lifecycle cost of software assets includes: determining maintenance tasks based on the version dependencies of the repairs to be implemented and the software assets; generating reuse evidence containing version applicability conditions based on the construction and regression verification results of the repair artifacts; merging common modification tasks that meet the version applicability conditions and share delivery tasks, while retaining independent adaptation tasks; inputting the remaining modification scale and cost drivers of the common modification tasks and independent adaptation tasks into a parameter estimation model to predict workload and calculate remaining maintenance costs; reviewing the reuse evidence when version dependencies change, splitting unexecuted tasks that fail the asset association review, adding independent adaptation tasks, and recalculating remaining maintenance costs; and incorporating the remaining maintenance costs into other remaining expenses, plus the accumulated actual costs, to obtain the predicted full lifecycle cost.

[0054] In this embodiment, the processing object is software assets held by the enterprise that require continuous development and maintenance. Software assets can be independently deployed applications or modules used by multiple applications. Asset registration records store asset identifiers and their respective applications; deployment records store the actual running artifacts and module reference relationships; maintenance records store the content to be repaired and the delivery tasks undertaken for repair; and expense records store expenditures already incurred and estimated expenditures for activities not yet completed. Public modification tasks refer to modification operations generated by shared delivery tasks and used by multiple assets, while independent adaptation tasks refer to interface adjustments or integration operations performed separately by a specific asset to use the repair results. The two types of tasks are distinguished based on the identity of the delivery operation. Modules with the same name or repair results do not directly constitute a basis for consolidation. Lifecycle forecasting uses the sum of cumulative actual costs and remaining forecast costs. Activities completed before the forecast date are included in actual costs, while activities still to be executed after the forecast date are included in the remaining forecast range. The same execution record cannot be in both ranges simultaneously.

[0055] In this embodiment, a software asset lifecycle cost prediction system includes a memory and a processor. The processor runs a program in the memory and performs the following: determining maintenance tasks based on the version dependencies of the software assets and the repairs to be implemented; generating reuse evidence containing version applicability conditions based on the construction and regression verification results of the repair artifacts; merging common modification tasks that meet the version applicability conditions and share delivery tasks, while retaining independent adaptation tasks; inputting the remaining modification scale and cost drivers of the common modification tasks and independent adaptation tasks into a parameter estimation model to predict workload and calculate remaining maintenance costs; reviewing the reuse evidence when version dependencies change, splitting unexecuted tasks that fail the asset association review, adding independent adaptation tasks, and recalculating remaining maintenance costs; and incorporating the remaining maintenance costs into other remaining expenses, plus the accumulated actual costs, to obtain the predicted lifecycle cost.

[0056] Specifically, the memory stores an asset version table, a maintenance task table, and reuse evidence records. The processor reads a data snapshot from the same prediction point in time, generates task associations and model inputs within the work area, and then writes the results that pass the consistency check into the prediction result table. The asset version table uses asset identifiers and deployment version identifiers as search criteria. The maintenance task table records job content using task instance identifiers. The reuse evidence record associates repair artifacts and target assets with evidence identifiers. The model input record references task instances and retains the basis for scale extraction. The prediction result record references the version of the model input. These records can be stored in a relational database. The many-to-many relationship between tasks and evidence is stored through an association table. The program does not depend on a specific database product. Reading and writing are both based on the prediction version as the boundary. Published prediction versions are not overwritten by intermediate data that has not yet been submitted in subsequent calculations. The processor performs data acquisition, relationship matching, and cost calculation. The construction and verification of repair artifacts can be performed by existing construction services and return result records with object identifiers.

[0057] Furthermore, when obtaining version dependencies, the module artifacts actually used by the application are read from the deployment manifest, and the final resolved module version is determined by combining the dependency locking record. The version range allowed in the module declaration does not replace the actual deployment version. A content summary is calculated for each artifact, and the source record that can be traced back to the build input is saved. The summary is used to locate candidate identical objects. When candidate objects need to be merged, the artifact content and delivery source are compared again. Modules with the same name and version but different content are retained separately. The referenced asset is used as the starting point of the relationship, and the actual dependent module is used as the ending point of the relationship. The relationship is recorded as whether it comes from the build dependency or the runtime interface. The referenced object is searched in reverse at the module corresponding to the content to be repaired. When a circular dependency is encountered, the relationship identifier that has been visited is used to determine whether to continue expanding, so as to avoid the same relationship entering the pending set repeatedly in one traversal. The resulting impact set only indicates the scope of objects that need to be checked. Whether the modification job is shared is still determined by the delivery task and reuse evidence.

[0058] In this embodiment, the repair to be implemented comes from a registered defect handling task or version update task. The registration includes the baseline before the repair and the code object to be changed. The program locates the code object to its module and then obtains the assets that may use the repair results through version dependencies. The repair artifact can be a generated patch file or a build input package containing the modified code. Its build and regression results are used to determine whether the repair results can be used under a specific target version. When the results have not yet been obtained, the relevant relationships are reserved as pending verification and cannot be directly used as the basis for confirmed sharing. The verified record saves the build input and regression coverage of this time. The program extracts the version applicability conditions from the record and associates the maintenance tasks of the corresponding assets with the evidence. The resulting common delivery scope still includes the deployment or adaptation activities performed by the assets individually. The merging of common modifications does not make these activities automatically completed. Independent adaptation tasks continue to participate in the remaining scale and workload calculation.

[0059] Specifically, merging common modification tasks affects the reference relationships between task records, without deleting the original repair requirements. Each participating asset retains its association with the common task, and the common task retains its identity as a jointly delivered operation. Independent adaptation tasks retain their own task instances and target versions. Cost forecasting reads the operation content of the common task once and then reads the operation content of each independent adaptation task separately. The asset view displays the corresponding references and independent tasks, and the asset portfolio view is aggregated by operation record. The same common expense displayed in different asset views cannot be added together again. When version changes occur after the forecast point, the program first re-verifies the applicable conditions and then decides whether to retain or remove the sharing relationship of the corresponding asset based on the construction and regression results. Other assets that still meet the conditions continue to reference the original common task. Actual expenditures that have already occurred are saved in the execution record. Removing a reference only changes the organization of future tasks. Existing expenses cannot be deleted from history, nor can historical expenses be copied to new tasks.

[0060] In one embodiment, the parameter estimation model receives scale input according to the estimation set. The estimation set corresponds to the maintenance delivery scope with the same model activity caliber. The set can simultaneously include common modification tasks and asset-independent adaptation tasks. The set division is determined when compiling historical samples, and the same division method is used during prediction. The code scale cannot be arbitrarily split in order to obtain lower calculation results. Sets are established separately for tasks belonging to different activity calibers or different manual pricing scopes. For each set, the task instances that still need to be executed are first determined, and then duplicate references of the same job are removed according to the task instance and modification location. The modification content that different delivery jobs need to complete is retained to form a unique remaining scale entry. The code scale is calculated by excluding blank lines and comment lines, and the number of newly added and modified lines. Automatically generated code that does not require manual maintenance is not included in this scale. The same statistical rules are used for historical samples, and the calculation relationship is as follows.

[0061] ;

[0062] Where g represents the identifier of the estimation set, This represents the set of task instances within the estimation set that have undergone job identity verification and still need to be executed, where t represents the task instances within it. This indicates the remaining number of newly added and modified lines of code for this task instance. This represents the remaining modification scale in thousands of lines. The summation symbol indicates accumulation for each task instance, and dividing by 1000 indicates conversion from lines of code to thousands of lines. For example, if a common modification job has 1000 lines remaining, and asset-specific adaptation tasks have 200 and 200 lines remaining respectively, although the common job is referenced by two assets, its scale entry only enters the set once, resulting in 1400 lines, which is converted to 1.4 thousand lines. If one of the assets requires an additional 400 lines of independent modification, then that independent job is counted as its own task instance. When there are no incomplete modifications in the set, its scale is 0. Completed code is no longer included in the remaining scale. For verification activities that do not change the code but need to be executed separately, they are handled separately according to the activity overwrite record, without artificially increasing the number of lines of code to replace verification time.

[0063] Please refer to Figure 2 , Figure 2 The horizontal axis represents four task instances that still need to be executed in this prediction version, from task A to task D. The vertical axis represents the remaining modification scale of each task. Gray fill, two opposite diagonal lines, and horizontal line textures are used to identify the columns one by one. In the formula... The scope of valid tasks that still belong to this estimation set is limited. Take the number of rows for each instance after merging the modified positions and deducting the accepted content. It is the size of the set after summing these rows and converting them to thousands of rows. Figure 2Assignment C has the highest column height, at 0.9 thousand rows; Assignment A has 0.4 thousand rows, and Assignments B and D each have 0.2 thousand rows, totaling 1.7 thousand rows. The column height reflects the difference in the actual remaining work scope, not the share allocated by the number of assets. When the same common assignment is referenced by multiple assets, only one column is formed; independent adaptations of different task instances are listed separately. Therefore, the diagram follows the formula for summing by task instance boundaries.

[0064] In this embodiment, the program combines the remaining maintenance costs of each estimated set with other unoccupied lifecycle costs to form a remaining forecast. Other costs are provided by licensing agreements or confirmed implementation plans, including operational services and exit costs that are not within the scope of the maintenance model activities. The forecast results simultaneously save the cost period and source. For assets in the initial construction phase, the unfinished development costs are obtained according to existing development estimate records and are distinguished by activity attribution and maintenance estimates. After entering the operation and maintenance phase, the development expenditures already incurred are included in the cumulative actual costs. The same cost source can only correspond to either the actual record or the remaining record. License expenditures already paid cannot be included in future acquisition costs again because the license is still in use. When there is a future renewal agreement, a record is established with an independent contract period. This process enables the method to cover the cost scope of software formation, continuous maintenance, and exit from use. Maintenance task refactoring only replaces the remaining forecast associated with it, while the remaining lifecycle records retain their respective sources and periods.

[0065] In a preferred embodiment, when merging common modification tasks, a common task record is established for shared delivery tasks, and the software assets corresponding to the common modification tasks are associated with the common task record; task records are retained separately for common modification tasks with the same deliverables but different delivery tasks; independent adaptation tasks are bound to their corresponding software assets, and the common task records they reference are recorded; the scale of a common modification is extracted based on the unexecuted portion of the common task record, and the scale of adaptation modification is extracted based on the unexecuted portion of each independent adaptation task, and the extracted modification scale is input into the parameter estimation model.

[0066] Specifically, the task record sets both a task source identifier and a task instance identifier. The task source identifier points to the original repair item that generated the maintenance requirement, and the task instance identifier points to the actual planned delivery operation. When multiple assets reference the same common task, they share the task instance. When an asset needs to be modified separately, a new task instance is obtained, but it can still reference the same task source. The merge key of the common task includes the identity of the common delivery operation and the baseline before the repair. Only when both contents are consistent and the related assets meet the reuse conditions will the common modification reference of the asset point to the same record. Only tasks with the same repair requirements but implemented by different delivery operations are kept separate. For example, assets 101 and 102 agree to use the repair artifact generated by delivery task 501. The common modification record corresponds to task 501. Although asset 103 uses the same patch, its maintenance plan requires it to be completed by the independent delivery task 502. In this case, task 502 retains its own scale entry. Its task source can be the same as task 501, but its instance identity is different.

[0067] Furthermore, deduplication of modification scale is performed within a single job scope. The program obtains the difference between the baseline before repair and the code to be delivered, converts each difference into a file identifier and code position in the baseline, associates new content with the insertion position, associates modified content with the range of statements replaced, and records the source of the difference. When the same task instance generates the same difference record due to multiple asset references, only one range entry is retained. The union of partially overlapping difference ranges is used for statistics, and content located in different files or belonging to different delivery tasks is counted separately. When code reordering causes line number changes, the code line range is filled back based on the declaration position in the syntax structure and the corresponding difference of the function. All text changes caused by simple movement cannot be regarded as reimplementation. Pure deletion tasks register the maintenance objects to be deleted and the call content that must be adjusted accordingly as the modification scope, and use the same measurement caliber in the historical samples. Regression activities that still need to be implemented after deletion are processed according to their activity records, and the number of executions is not converted into fictitious code scale.

[0068] In this embodiment, the completed and unexecuted parts are divided according to the accepted deliverables. The execution record is associated with the code submission and corresponding acceptance record. After a certain modification is completed and the acceptance result is obtained, its size entry is marked as completed, and the target version at the time of completion is retained. Tasks that have invested time but have not formed acceptable deliverables still have remaining work. The invested time is included in the actual cost, but the code size cannot be directly reduced according to the proportion of invested time to the total expected time. For tasks that are being executed, the program compares the target modification range from the latest acceptable baseline, moves the accepted differences out of the remaining range, and retains the content that still needs to be modified or reworked in the new remaining range. If the version change makes the completed results unable to be directly used for the target asset, the existing actual expenditures continue to be retained. Additional work on the new target version is created as a separate task instance. The expenditures that have already been incurred cannot be restored to incurred costs, nor can the new target be considered completed on the grounds that the original task has been completed.

[0069] In a preferred embodiment, when the repair requirement has been confirmed but the complete code has not yet been formed, the maintenance scale adopts a traceable estimated scale entry. The entry records the interface or code object to be changed and the source of the estimate. The program filters completed tasks with the same modification objects and the same activity scope from the historical maintenance records, reads the actual number of new and modified lines for each task, sorts them by modification object category and takes the median value, and then summarizes them according to the number of currently confirmed modification objects to obtain the estimated scale of the scope to be delivered. Execution records formed after the prediction date are not used during the filtering. When the historical records are insufficient to provide the corresponding object category, the estimated scope confirmed by the maintenance design record and its submission source are retained. The unknown scale cannot be replaced by 0. After subsequent code submissions form comparable differences, the corresponding estimated entries are replaced with the actual difference positions, and the connection with the original estimate record is maintained through the task instance identifier. The replacement only applies to the incomplete scope. Activities that have been included in the actual expenditure are not returned to the remaining scale set.

[0070] In a preferred embodiment, the common modification scale and the adaptive modification scale are recorded as scale entries with task source identifiers, and associated with model input records and activity decomposition records. When multiple software assets reference the same common task record, only one scale entry with the corresponding task source identifier is retained. The scale entries are aggregated according to the estimation granularity of the parameter estimation model and input into the parameter estimation model to obtain the workload and convert it into the remaining maintenance cost according to the labor rate. For the verification work of independent records, the activities covered by the parameter estimation model are checked according to the task source identifier and activity decomposition record. The verification work covered by the model uses the model output, and the remaining working hours of the corresponding verification task for the uncovered verification work are converted into the remaining maintenance cost according to the labor rate.

[0071] Specifically, within the same public task record, the task source identifier is used to identify identical inputs due to repeated references. When verifying scale across independent task records, the task instance identifier is read simultaneously. Jobs that undertake the same repair task but need to be executed independently will not be deleted again due to the same source. The model input record stores the task instances and their scale entries contained in the estimation set. The activity decomposition record stores the work content covered by the sample man-hours, such as whether the coding activity has already included the corresponding regression job. Prediction and historical calibration use the same activity decomposition version. Model calibration obtains the code scale and actual man-days from the completed estimation set with the same caliber. The registration level of cost drivers such as product complexity is converted into model input. Data with missing levels is separately retained as incomplete data, and missing records are not interpreted as the lowest level. An executable parameter relationship uses the scale power function and the driver factor multiplier to describe the maintenance workload, and then converts it into cost according to the man-day rate. The calculation relationship is as follows.

[0072] ;

[0073] in, This represents the estimated remaining maintenance cost of the set, in yuan. This indicates the labor cost rate, expressed in yuan per person per day. This indicates a scale conversion factor, with units of person-days per (thousand lines). , Represents a dimensionless scale index. This represents the remaining size of the software corresponding to the estimated set, in thousands of lines of code. This represents the set of cost drivers, where d represents the identifier of each factor. This represents the dimensionless workload multiplier for the corresponding factor. This represents the remaining validator man-days not covered by the model's activity scope; the product symbol indicates that each factor multiplier is multiplied sequentially. When no factor is enabled, the product is 1. The value in parentheses is the sum of the model workload and the additional validator workload, which is then multiplied by the labor cost rate to obtain the cost. When the scale is 0, no coding maintenance workload is generated. For example, if the remaining scale is 1.4 thousand rows, the scale conversion factor is 10, the scale index is 1, the product of the factor multipliers is 1.2, the additional validator man-days is 0, and the labor cost rate is 2000 yuan per man-day, we get 16.8 man-days and 33600 yuan. When the additional validator man-days are changed to 3, the cost is 39600 yuan. These values ​​are used to illustrate the calculation process and are not considered as a fixed configuration adopted by all assets.

[0074] Please refer to Figure 3 , Figure 3 Bundle Figure 2The summarized task size is placed in estimation group A, with the horizontal axis representing the estimated set and the vertical axis representing the current remaining maintenance cost for that set. This version has only one valid set, therefore only one gray filled bar appears. This bar corresponds to 40,800 yuan, reflecting the combined result of current task members, model parameters, and activities not yet executed. During calculation... and Determine the scale power function. Adjust workload item by item; verify man-days separately. Only enters if the activity breakdown is not covered and has not yet been executed, and is ultimately charged by manual rates. Converted to A single bar chart cannot deduce any multiplier or rate, nor does it represent fees already paid. If the remaining scope of a maintenance task changes, all valid members of the set should be re-aggregated before calculating the new cost based on the same model version; old costs cannot be linearly increased or decreased based on the proportion of a single task bar.

[0075] Furthermore, the scale conversion factor and scale index can be obtained from a historical set with the same caliber. Specifically, the natural logarithm of the actual code scale and actual person-days (both greater than 0) is taken, and the logarithmic scale is used as the numerical independent variable. The driving factor level is converted into an indicator variable, and the least squares fit is solved with the logarithmic actual person-days as the dependent variable. The intercept of the fit is used as the scale conversion factor after taking the exponent, and the coefficient corresponding to the logarithmic scale is used as the scale index. The coefficient of each level indicator variable is used as the workload multiplier after taking the exponent. Each factor retains one baseline level with a multiplier of 1, and other levels are interpreted relative to this baseline. When the indicator variables are completely overlapping and cannot be uniquely solved, the level fields with the same information source are merged or the corresponding factors are temporarily not used, and the processed field mapping is saved. Non-unique solution results cannot be directly used for prediction. For implementation methods that have adopted public parameter relationships, existing model versions can be read, and the consistency of measurement caliber can be checked with local samples. The model version and activity decomposition version are saved with the prediction record.

[0076] In this embodiment, the cost conversion adopts the same man-day caliber as the model workload. When the original working hours are registered in hours, they are converted to man-days according to the working day conversion rules already adopted by the corresponding project, and the conversion source is saved. The man-month output cannot be directly multiplied by the man-day rate. When the costs of different personnel need to be priced separately, the estimation set is divided according to the pricing range. Multiple rates cannot be mixed without basis within the same set. Independent verification records are matched with the activity decomposition records through task source and verification object. Regression executions that are already included in the model's working hour range do not incur additional labor costs. For special verifications not covered by the model, the working hour plan that has not yet been executed is read, converted to the same man-day caliber, and priced separately. Executed verification activities are included in the actual costs and removed from the remaining working hour plan. When verification requires rework, a rework operation record is created. The original verification execution record remains in the "occurred" state. The same execution record cannot be used as both incurred cost and unexecuted verification cost at the same time.

[0077] Furthermore, the scale power function is non-linear when the scale exponent is not 1. If the scale of the same estimation set changes, it is necessary to read all the current incomplete entries of the set, re-aggregate them, and then execute the model calculation. For example, if a common task is still jointly referenced by assets 101 and 102, and asset 103 needs to add an independent adaptation, the program will locate the new adaptation to its set and recalculate the cost for that set. It cannot directly add the new cost after deducting the previously displayed common cost share of asset 103 from the original total cost. The common cost reference in the asset view is only used to indicate the source and does not represent an independently addable model result. Historical data and current predictions both use the estimation set as the cost aggregation unit. When a new task belongs to different activity categories, an independent set is created for it and calculated separately. The other sets retain their original inputs and results. The new set and the original set are checked through task affiliation to confirm that no incomplete task has been entered repeatedly.

[0078] In a preferred embodiment, the generation of reuse evidence includes: binding the repair artifact to the module version before repair, determining the target asset that references the module version along the version dependency relationship; building the repair artifact according to the deployment configuration of the target asset, performing regression verification of the associated change interface on the built artifact; writing the verified module version and deployment configuration into the version applicable conditions, and associating the verification record with the target asset and the corresponding maintenance task.

[0079] Specifically, the version applicability conditions are represented by verifiable records. These records include the identity of the module artifact before the fix and the deployment configuration related to the build and regression. The artifact identity is determined by the content summary and the build source. The deployment configuration includes the dependency resolution results and the interface protocol used. The asset number is used to find the verification object but cannot replace the actual version used by the verification object. The verification record also stores the summary of the fix artifact and the scope of the interfaces covered. Subsequent sharing judgments require that the object to be used falls within the scope of the already verified conditions. Temporary directory names, record write times, and other content that does not participate in the build and interface behavior are not considered as applicable conditions. When collecting configurations, the actual fields used are determined based on the build input list and test loading records. All deployment records cannot be used indiscriminately as reuse restrictions. The same fix artifact can correspond to multiple condition records. Each condition record is associated with a verified asset. The failure of a certain condition does not override the verification results that can still be used under other conditions.

[0080] In this embodiment, the baseline before the repair is read and verified. The patch to be reused or the modified build input package is applied in an independent working directory. The existing build script is executed according to the dependency version locked for the target asset, and the build input summary and build output summary are recorded. When the build script returns to a complete state and generates the expected artifact, the build artifact that can continue to be executed for regression verification is obtained. If the build cannot be completed due to missing interfaces or dependency conflicts, the specific conflicting objects and their corresponding dependency locations are recorded, and these locations are used for subsequent independent adaptation scope analysis. If the build environment is not ready, dependency files have not been obtained, or the execution process is interrupted, this record is not considered a conclusion of incompatibility with the repair artifact, but rather a state of no valid result is retained. The object identifier of the build record is used throughout the subsequent regression process. The result of a successful build cannot be combined with the test result of another test with different inputs to form the same pass evidence; result association is based on the premise of the same input snapshot.

[0081] Furthermore, regression verification locates the modified interfaces or code entry points from the code differences being fixed, then reads the correspondence between these objects and existing test cases, and supplements the test cases associated with the affected calling objects along the dependency path; each test case saves input data, expected return content, and error state constraints, loads the target deployment configuration during execution, calls the build artifacts on isolated data copies, compares the actual return value with the expected value, and records whether any unconventional error states occur; when dealing with set data whose result order is irrelevant, the records are sorted according to the interface convention before comparison; when dealing with variable fields such as time stamps, only the comparison rules explicitly registered in the test cases are applied, and unstated differences cannot be automatically ignored; when all selected test cases are completed and their respective judgment conditions are met, the test case is recorded as passed; when there is an output difference that can be repeatedly located, the test case is recorded as failed; when there are no test cases corresponding to the affected interface, the test case is retained and the verification task for that interface is supplemented; the passing of existing test cases does not replace the verification results of interfaces that have not yet been covered.

[0082] In this embodiment, the effective scope of reused evidence is limited to the baseline, configuration, and interface scope used in this verification. The evidence does not indicate that all possible inputs or all future deployment conditions have been verified. The program associates the verification status of each target asset with the corresponding maintenance task. By recording, the asset is allowed to reference the common delivery task in the current prediction scenario. If the record does not provide an interface or dependent object that needs to be independently adapted, the record to be verified retains the sharing relationship that cannot yet be determined. For example, assets 101 and 102 use the same module baseline, but asset 102 enables a different interface protocol. The program builds and executes use cases related to the protocol respectively. Only when asset 102 also obtains a pass result under its protocol conditions will its common modification task be pointed to an existing common delivery task. When the module of asset 103 belongs to an independent modification branch, even if the module displays the same version name, an independent verification association is established according to the actual artifact identity, and the pass record of asset 101 is not used.

[0083] In a preferred embodiment, the changed interface involved in regression verification is associated with the dependency path to the verification record; when the module version or deployment configuration changes, the changed interface is located along the dependency path, the regression test case associated with the verification record is executed, and the version application conditions are updated after the verification is passed, and the reuse evidence of the corresponding asset is marked as invalid when the verification fails.

[0084] Specifically, the dependency paths in the verification log store the relationship identifiers from the repair module to the affected interface and the version snapshots of the objects on the path. When the configuration changes, the recorded path containing the changed object is searched, and the corresponding interface and test case set are obtained. When multiple paths point to the same test case, only one verification execution request is created under the same target version. The execution request still saves all source paths so that the corresponding associations can be updated when the results are returned. When the changed object is not on the recorded path, but a new reference relationship to the repair module is added, the path needs to be rebuilt and the new interface needs to be verified. The old evidence cannot be directly used just because the object is not in the old path. After the re-verification is passed, an evidence version applicable to the new snapshot is established. The old evidence retains its original scope of application. Assets that have not yet been updated can still use the old evidence based on the old version conditions. Evidence versions are connected through source relationships. The global overwrite method is not used to erase the conditions that other assets still need to reference.

[0085] In a preferred embodiment, a verification record is established for target assets that have not yet obtained re-verification results. A first task set sharing repair artifacts and a second task set independently adapting repair artifacts are established. The first task set references common modification tasks, while the second task set retains independent modification scales. The two are associated with the verification record and the remaining maintenance cost is calculated independently. After obtaining the re-verification result, the cost record corresponding to the first task set is used when the verification is successful, and the cost record corresponding to the second task set is used when the verification fails. The prediction record corresponding to the other task set is canceled.

[0086] Furthermore, the two task sets correspond to mutually exclusive scenarios at the same prediction point in time. The first task set retains common modification references under the assumption that the conditions to be verified are met, and retains adaptation tasks that the target asset still needs to complete independently. The second task set removes this shared assumption and adds independent modification and adaptation tasks. Each scenario re-examines whether there are other valid references to the common tasks. If other assets still need to deliver the tasks together, the common tasks continue to be retained in both scenarios. Only when there are no valid references and the maintenance plan no longer executes the common task will the independent scenario withdraw its remaining prediction. Scenario differences are expressed through task instance sets and then calculated separately according to their respective estimation sets. It is not permissible to simply add an unspecified risk amount to the existing total cost. The two scenarios share the same incurred cost records, but each has its own remaining prediction version. The asset portfolio results are generated separately. It is not permissible to count the common tasks in the two scenarios once and then combine them into a total amount.

[0087] ;

[0088] in, This represents the estimated remaining maintenance cost of the collection in a shared repair artifact scenario. This represents the remaining maintenance cost for the same set in an independent adaptation scenario. This represents the remaining maintenance cost after the verification result is determined. All three cost symbols are in yuan. The superscript is used to distinguish the scenario status. z represents the determined result of this re-verification. 1 indicates pass and 0 indicates fail. For example, the scale of the shared scenario is 1,400 rows and the scale of the independent scenario is 1,800 rows. Using the model and labor cost rate of the previous example and setting the man-day for the separate verification to 0, we get 33,600 yuan and 43,200 yuan respectively. 33,600 yuan is used when it passes and 43,200 yuan is used when it fails. The two are not added together or averaged. When the verification is not yet completed or the execution is interrupted, the result is not marked as 0. Instead, it remains in the pending verification state and two predictions are saved. The formula is only used to select records after the result is determined. If the independent scenario involves other estimation sets, the corresponding sets are recalculated one by one and then summarized according to the same scenario identifier.

[0089] Please refer to Figure 4 ,for Figure 4 The horizontal axis shows the mutually exclusive task statuses of independent and shared delivery, with the left and right columns representing the statuses. The vertical axis represents the recalculated remaining maintenance costs for each status. The filled column represents 40,800 yuan for independent delivery, while the diagonal column represents 31,200 yuan for shared delivery, a difference of 9,600 yuan. The shared solution retains publicly referenced tasks that are still valid and includes necessary adaptations for the asset itself. The independent solution adds the necessary independent modifications according to the target version; therefore, the difference in column height comes from the task members and their remaining scope, rather than simply adding a risk amount.

[0090] In this embodiment, when the verification result is returned, the current artifact summary and configuration snapshot of the verified asset are read again and compared item by item with the snapshot saved in the execution request. Only when the two are consistent is the result allowed to update the current prediction. If the asset has released a new version during the verification process, the returned result is saved as historical evidence of the original snapshot, and the new version continues to be in a state of pending review. The required task set is regenerated based on the new version. The pass conclusion of the original version cannot be transferred to the latest version. For the same execution result returned repeatedly for the same asset, the program identifies the already processed record based on the verification execution identifier, and does not generate independent adaptation tasks repeatedly, nor does it cancel the scenario repeatedly. When there are multiple assets to be verified, each combined scenario saves the shared or independent state adopted by each asset. Only when the task-related state combination is compatible with each other is the combination fee calculated. For example, if a public task has been canceled by the scenario, other assets cannot continue to reference the canceled task record in the same scenario.

[0091] Specifically, withdrawing an unused scenario involves marking its remaining prediction record as a non-current record and removing its reference in the current prediction version. Historical scenarios and their corresponding verification requests are still retained for retrospective purposes. Actual cost records do not belong to any mutually exclusive remaining scenario, and their assigned execution job is always unique. Therefore, selecting a shared scenario or an independent scenario will not re-incur the expenditures that have already occurred. When re-verification fails, the program reads the failed interface and corresponding dependency path, compares the planned independent modification scope with the adaptation scope to be added, establishes references for modifications covered by existing tasks, adds adaptation tasks for content outside the scope, and then proceeds to scale extraction. This record organization ensures that scenario selection is based on a corresponding set of tasks and verification results. The prediction results allow users to query which task a particular remaining cost came from, which verification record was used, and which version of the model input was adopted. The query results do not require reverse inference of the cause of cost changes.

[0092] Please refer to Figure 5 In a preferred embodiment, the changed version dependencies are matched with the version applicable conditions, and the build and regression verification are re-executed for mismatched target assets; the association between the target assets that fail verification and the common modification tasks is marked as invalid, and the completed and unexecuted parts corresponding to the invalid associations are separated according to the execution records; the unexecuted parts are converted into independent modification tasks, and the modification content outside the scope of independent modification tasks in the re-verification records is listed as independent adaptation tasks; the version applicable conditions of the target assets that pass verification are updated and the association of common modification tasks is retained, and the remaining modification scale is recalculated according to the converted and supplemented tasks.

[0093] Specifically, the failure to pass the review corresponds to the association between a specific asset and a common task, not the task itself used by all assets. The program obtains the target asset version and task instance from the failure association, and then checks which valid references the original common task still have. If the original common task is still referenced by other assets or adopted forecast scenarios, its unfinished jobs retain the execution plan and scale input, only removing the references of the failed asset and generating the corresponding independent task. If the original common task no longer has valid references, but the maintenance plan still clearly requires delivery, the source of its continued execution plan is recorded. Jobs cannot be deleted solely based on the number of references. Forecasts that have not yet been executed are only revoked when the plan has been terminated. Revoked forecasts do not include job records that have been completed and incurred costs. Costs incurred continue to be collected in the original task. Independent tasks only obtain the scope of modifications that need to be completed and the inheritance relationship. The entire cost of the original common task cannot be used as the estimated cost of the new task.

[0094] Furthermore, the scope of independent modifications to the target asset is determined by re-comparing the current version with the content to be fixed. Fragments that have been completed and can still be used in the current version are no longer considered as independent rewrite content. Fragments that are not yet completed or need to be rewritten are entered into independent tasks. If the interface adjustment pointed to by the failure verification record is already included in the scope of the independent task, only the verification source association is added. If it is not included in the scope, an independent adaptation task is created and the dependency between it and the original task is marked. For example, if the public fix changes the date parsing interface and the parameter type no longer matches after the target asset version changes, the independent modification task is used to implement the fix content that can be used in the target version. The parameter conversion at the call site is an additional adaptation content. The two are extracted separately according to the code scope. The model receives the incomplete scope in the converted task set. The actual cost of the completed fragments is kept in the original record. New work caused by the change of parameter type has an independent entry. The execution state switch cannot replace the re-comparison of the modification scope.

[0095] In a preferred embodiment, an index is established from version applicability conditions to reuse evidence, and a reverse index is established from reuse evidence to common modification tasks; when a change in version dependency is detected, the affected reuse evidence is obtained through the index, and the associated common modification tasks are located along the reverse index; only the tasks involved in the failure association are re-aggregated for the remaining modification scale, and the corresponding remaining maintenance cost records are replaced with the re-estimated results, while cost records not involved in the failure association are retained.

[0096] Specifically, the conditional index uses the version objects and configuration fields involved in the matching as search terms, and the evidence identifier and target asset identifier as associated values. The reverse index uses the evidence identifier as the search term and saves the corresponding public task and asset reference relationship. The version change event carries the object identifier and content snapshot before and after the change. The program searches the conditional index based on the fields where the difference occurs, and then obtains the asset association that needs to be reviewed along the reverse index. The newly added objects in the relationship are supplemented with the scope of impact according to the current dependency relationship. After obtaining the failure association, the affected estimation set is located by the relationship between the task and the model input record. The remaining scale of these sets is re-aggregated, instead of just substituting the changed fragments into the power function and then appending them. The model input and cost results of the unaffected set remain unchanged. The unchanged task scale in the affected set still participates in the complete calculation. After the set calculation is completed, its remaining prediction record is replaced as a whole to keep the input granularity of the nonlinear model consistent with the original historical calibration granularity.

[0097] In this embodiment, evidence updates, task splits, and prediction record replacements caused by a single event are submitted within the same prediction version. The program first saves the transformed asset associations and new tasks in a temporary record area, then generates the corresponding model inputs and calculates the costs. Before submission, it checks whether the still-referenced public tasks exist, whether each task has a unique estimated attribution, and whether the completed execution records still point to the original cost source. After the checks pass, it compares the prediction version read at the start of the calculation with the currently published version. If they are the same, it submits the new associations and results at once. If they are different, it reads the latest version and recalculates the affected set. Each change event saves an event identifier. When the same event arrives repeatedly, the processing record is read directly, and the same independent task cannot be created again. If the event describes a new asset snapshot, it is treated as a subsequent change and processed separately. The service return results and asset publication events are established according to the object snapshots, directly overwriting the current evidence without relying on the message arrival order.

[0098] In a preferred embodiment, for failure associations, the actual working hours and costs of the completed portion are kept bound to the original common modification task; for the unexecuted portion, an independent modification task is established to inherit the source of the original task, and the scale of the new adaptation modification is determined according to the current version of the target asset corresponding to the failure association; when replacing the remaining maintenance cost record, only the original prediction entry corresponding to the unexecuted portion is cancelled, and the prediction entry corresponding to the independent modification task and the scale of the new adaptation modification is written; the actual cost of the original common modification task is collected once and summarized with the remaining maintenance cost after replacement.

[0099] Specifically, the scope of cancellation for original forecast entries is determined based on whether the job continues to exist. If an ineffective asset originally only referenced a common job, only the forecast references that are no longer valid for that asset are cancelled; forecasts for common jobs still needed by other assets cannot be deleted. If an ineffective asset originally had independently owned unexecuted entries, the original entries can be replaced with entries for newly created independent tasks. The replacement record saves the original task source and the new task instance, and the actual costs are still collected along the execution record. For example, if a common task has completed 300 lines and recorded the actual working hours, and the remaining 700 lines are still required to be completed by other valid referencing assets, then the common task retains the remaining inputs of the 700 lines, and the ineffective asset creates a new scope of modification according to the current version. The costs of the 300 lines that have already been completed cannot be copied to the independent task. If the ineffective asset cannot use the results formed by these 300 lines, its subsequent reimplementation belongs to a new uncompleted job, and the original execution record continues to exist as actual costs. The scale and estimated costs of the new task are calculated separately.

[0100] In this embodiment, the lifecycle aggregation is based on the currently adopted prediction scenario as the boundary. Actual costs are obtained from records with unique execution identifiers, and remaining maintenance costs are obtained from the currently valid estimation set results. Other remaining costs are obtained based on the contract period and planned activities. Records with the same cost source that appear simultaneously in the corresponding activities of the estimation set and other remaining costs retain an entry based on activity affiliation. Verification costs already aggregated in the estimation set cannot be added to other costs again. Completed license payments, development work, and maintenance executions are collectively included in the accumulated actual costs. Future operating resources and exit activities continue to be included in other remaining costs according to their respective records. When using a unified currency, the conversion date and conversion basis are saved without changing the job identity at the task level. The aggregation relationship is as follows.

[0101] ;

[0102] in, This represents the projected cost of the software asset's entire lifecycle under the current forecasting scenario. G represents the cumulative actual costs incurred up to the forecast date, and G represents the total estimated set of activities in the current scenario that are valid and do not involve duplicate activities. Using the aforementioned definition, let represent the remaining maintenance cost of one of the estimated sets. This represents the remaining stage costs that have not yet entered the estimated set cost, with each cost in yuan. The plus sign indicates merging non-overlapping cost ranges, and the summation indicates reading the current prediction results for each estimated set individually. Set results not adopted in mutually exclusive scenarios are not included in the summation. For example, if the cumulative actual cost is 90,000 yuan, the current scenario includes one estimated set with a remaining maintenance cost of 33,600 yuan, and other remaining costs of 26,400 yuan, then the total lifecycle predicted cost is 150,000 yuan. If the independent adaptation scenario is adopted and the cost of that set becomes 43,200 yuan, and all other records remain unchanged, the total lifecycle predicted cost is 159,600 yuan. The change comes from the calculation of the adopted task set and its size, and is not formed by adding duplicate common costs.

[0103] Please refer to Figure 6 , Figure 6 The entire lifecycle is summarized by cost source: the horizontal axis represents cumulative actual costs, remaining maintenance costs, and other remaining costs; the vertical axis represents monetary value; the three bars are distinguished by actual costs and diagonal lines in the opposite direction. In the current version of the diagram, The figure of 90,000 yuan represents the cost for which there is a single execution or payment record up to the prediction date; the effective estimation set under the current scenario... Total: 40,800 yuan; The figure is 26,400 yuan, corresponding to other stage costs that have not yet occurred and are not included in the maintenance estimate set. According to the formula, the three non-overlapping sources are added together. The amount is 157,200 yuan. Paid licenses and executed verifications cannot be included in the latter two categories, and unadopted shared candidate fees cannot be summed with the maintenance fees of the current independent scenario.

[0104] In a complete application process, Asset 101 and Asset 102 both use module version 7. Repair task 501 delivers repair artifact 701. Asset 101 passes verification under existing deployment conditions, while Asset 102 enters the verification pending phase due to interface configuration adjustments. The program saves both shared and independent scenarios for Asset 102 and maintains the uniqueness of the actual costs incurred by Task 501. During the verification period, some modifications to Task 501 are accepted. The system updates the common remaining scale based on the completed segments. Both scenarios read the same latest actual costs, but recalculate their respective sets of incomplete tasks. When Asset 102 passes re-verification, evidence applicable to the new configuration is established and the shared scenario is adopted. If it fails, its common task association is removed and the independent scenario is adopted. Common jobs that Asset 101 continues to use retain their original ownership. Whether a prediction is revoked depends on whether the corresponding job still needs to be executed in the current scenario. Each update saves the correspondence between asset snapshots, evidence versions, and model inputs. The calculation results can be restored according to the prediction date, and future verification records are not used for predictions at past points in time.

[0105] Furthermore, the program output includes the lifecycle forecast costs of the asset portfolio and their cost sources. When querying a single asset, it returns its independent activity costs and common activity references. When querying a portfolio, it reads the deduplicated activity set and the results of each estimate set. When a repair is fully completed, the remaining modification scale is zeroed out, and the actual execution cost is retained in the cumulative record. Unfinished special verifications continue to be predicted according to the activity coverage relationship. Verification tasks that still need to be performed cannot be closed simply because the code modification is completed. After the software is taken out of use, the confirmed exit costs are transferred to the actual costs. The remaining operational services or archiving plans are still retained as incomplete records. When all incomplete activities are closed, the prediction results only retain the actual costs incurred and their sources. The current prediction version, historical versions, and execution records stored in the system are distinguished by their respective identifiers. When the processor receives the same query again, it obtains the same task set and model input based on the same data version and outputs the cost results corresponding to that version.

Claims

1. A method for predicting the lifecycle cost of software assets, characterized in that, include: Maintenance tasks are determined based on the version dependencies of the repairs to be implemented and the software assets, and reuse evidence containing version applicability conditions is generated based on the construction and regression verification results of the repair artifacts. Merge common modification tasks that meet the applicable conditions of the version and share the same delivery task, and retain independent adaptation tasks; The remaining modification scale and cost drivers of the common modification task and the independent adaptation task are input into the parameter estimation model to predict the workload and calculate the remaining maintenance cost. When the version dependency relationship changes, the evidence is reviewed and reused, the unexecuted tasks that are not linked to the asset are split and reviewed, independent adaptation tasks are added and the remaining maintenance costs are recalculated. The remaining maintenance costs are incorporated into other remaining expenses, and then added to the cumulative actual costs to obtain the total lifecycle predicted cost.

2. The method for predicting the full lifecycle cost of software assets according to claim 1, characterized in that, The generation of the reuse evidence includes: binding the repaired artifact to the original module version, and determining the target asset of the referenced module version along the version dependency relationship; Build a repair artifact according to the deployment configuration of the target asset, and perform regression verification on the artifact related to the change interface. The verified module version and deployment configuration are written into the applicable conditions of the version, and the verification record is associated with the target asset and the corresponding maintenance task.

3. The method for predicting the full lifecycle cost of software assets according to claim 1, characterized in that, When merging the common modification tasks, a common task record is created for the common delivery tasks, and the software assets corresponding to the common modification tasks are associated with the common task record. For common modification tasks where the delivered products are the same but the delivery tasks are different, separate task records should be maintained. Bind the independent adaptation task to the corresponding software asset and record the public task records it references; The common modification scale is extracted based on the unexecuted portion of the common task record, and the adaptation modification scale is extracted based on the unexecuted portion of each independent adaptation task. The extracted modification scale is then input into the parameter estimation model.

4. The method for predicting the full lifecycle cost of software assets according to claim 1, characterized in that, Match the changed version dependencies with the applicable conditions of the version, and re-execute the build and regression verification for target assets that do not match. The association between the target asset that failed verification and the public modification task is marked as invalid, and the completed part and the unexecuted part corresponding to the invalid association are separated according to the execution record; The unexecuted portion is converted into an independent modification task, and the modifications in the re-verification record that are outside the scope of the independent modification task are listed as independent adaptation tasks. Update the version applicability conditions for the verified target assets and retain the common modification task associations, and recalculate the remaining modification scale based on the converted and supplemented tasks.

5. The method for predicting the full lifecycle cost of software assets according to claim 2, characterized in that, Associate the changed interfaces and dependency paths involved in the regression verification with the verification records; When the module version or the deployment configuration changes, the changed interface is located along the dependency path, the regression test cases associated with the verification record are executed, and the applicable conditions of the version are updated after the verification is passed; if the verification fails, the reuse evidence of the corresponding asset is marked as invalid.

6. The method for predicting the full lifecycle cost of software assets according to claim 3, characterized in that, The common modification scale and the adaptive modification scale are recorded as scale entries with task source identifiers, and associated with model input records and activity decomposition records; When multiple software assets reference the same common task record, only one size entry corresponding to the task source identifier is retained; The scale items are aggregated according to the estimation granularity of the parameter estimation model and then input into the parameter estimation model to obtain the workload and convert it into the remaining maintenance cost according to the labor cost rate. For verification of independent records, the activities covered by the parameter estimation model are checked according to the task source identifier and activity decomposition record. For verification work covered by the model, the model output is used. For verification work not covered, the remaining working hours of the corresponding verification task are converted into the remaining maintenance cost after being converted according to the labor rate.

7. The method for predicting the full lifecycle cost of software assets according to claim 4, characterized in that, Establish an index to the version's applicable conditions to the reuse evidence, and establish a reverse index to the reuse evidence to the common modification task; When a change in the version dependency is detected, evidence of the affected reuse is obtained through the index, and the associated common modification task is located along the inverted index. Only the remaining modification scale of the tasks involved in the failure association is re-aggregated, and the corresponding remaining maintenance cost record is replaced with the re-estimated result, while the cost records not involved in the failure association are retained.

8. The method for predicting the full lifecycle cost of software assets according to claim 7, characterized in that, For target assets for which re-verification results have not yet been obtained, establish a record to be verified, and establish a first task set for shared repair artifacts and a second task set for independently adapted repair artifacts. The first task set references the common modification task, while the second task set retains an independent modification scale. Both are associated with the record to be verified and the remaining maintenance cost is calculated independently. After obtaining the re-verification result, if the verification passes, the cost record corresponding to the first task set is used; if the verification fails, the cost record corresponding to the second task set is used, and the prediction record corresponding to the other task set is cancelled.

9. The method for predicting the full lifecycle cost of software assets according to claim 7, characterized in that, For the aforementioned failure association, the actual working hours and costs of the completed portion will be kept bound to the original public modification task; For the unexecuted portion, establish an independent modification task that inherits the original task source, and determine the scale of new adaptation modifications according to the current version of the target asset corresponding to the aforementioned failure association; When replacing the remaining maintenance cost record, only the original prediction entries corresponding to the unexecuted part are cancelled, and the prediction entries corresponding to the independent modification task and the newly added adaptive modification scale are written. The actual costs of the original public modification tasks are collected once and then combined with the remaining maintenance costs after the replacement.

10. A software asset lifecycle cost prediction system, characterized in that, Includes a memory and a processor, the processor running a program in the memory to perform: determining maintenance tasks based on the version dependencies of the repair to be implemented and the software assets, and generating reuse evidence containing version applicability conditions based on the construction and regression verification results of the repair artifact; Merge common modification tasks that meet the version application conditions and share delivery tasks, and retain independent adaptation tasks; The remaining modification scale and cost drivers of the common modification task and the independent adaptation task are input into the parameter estimation model to predict the workload and calculate the remaining maintenance cost. When the version dependency relationship changes, the evidence is reviewed and reused, the unexecuted tasks that do not pass the asset association review are split and reviewed, the independent adaptation tasks are added and the remaining maintenance costs are recalculated. The remaining maintenance costs are incorporated into other remaining expenses, and then added to the cumulative actual costs to obtain the total lifecycle predicted cost.

Images