Working hour estimation method and device for system development life cycle, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a man-hour estimation method and device for a system development life cycle, electronic equipment and a storage medium. The method comprises the steps that a code warehouse and a supply chain risk assessment data source are acquired; determining a plurality of man-hour pre-estimation factors based on the code warehouse and the supply chain risk assessment data source; determining a factor weight corresponding to each man-hour pre-estimation factor according to development characteristics of a to-be-developed system product; and performing man-hour pre-estimation on the to-be-developed system product based on each man-hour pre-estimation factor and the factor weight corresponding to each man-hour pre-estimation factor. According to the technical scheme, the subjective limitation of artificial experience is effectively overcome based on the objective data analysis method, the working hours of the system development life cycle can be accurately estimated, personnel resources are reasonably mobilized according to the estimated working hours, and therefore it is guaranteed that system products can be delivered on time.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for estimating working hours during the system development lifecycle. Background Technology

[0002] The System Development Lifecycle (SDLC), as a systematic methodology for realizing software products, covers the entire process of activities including requirements analysis, system design, coding implementation, testing and verification, and operation and maintenance upgrades. Among these activities, the system development lifecycle time estimation is a core aspect of project management, and its accuracy directly affects resource allocation efficiency and delivery quality.

[0003] Traditional time estimation methods rely heavily on human experience, with senior project managers or technical leaders making estimations by analogy with historical project data. This method is overly dependent on personal experience, and the judgment standards of different people vary significantly. As a result, traditional time estimation methods often have large deviations in practical applications, leading to unreasonable allocation of personnel resources and seriously affecting the delivery schedule. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, apparatus, electronic device and storage medium for estimating working hours in the system development lifecycle, which can accurately estimate the working hours in the system development lifecycle and reasonably allocate personnel resources based on the estimated working hours, thereby ensuring that the system product can be delivered on time.

[0005] In a first aspect, embodiments of this application provide a method for estimating working hours during the system development lifecycle, the method comprising:

[0006] Obtain code repositories and supply chain risk assessment data sources; wherein, the code repository is an open-source project code library whose functions are benchmarked against the system product to be developed;

[0007] Multiple time estimation factors are determined based on the code repository and the supply chain risk assessment data source;

[0008] Based on the development characteristics of the system product to be developed, determine the factor weights corresponding to each of the time estimation factors;

[0009] The working hours of the system product to be developed are estimated based on each of the aforementioned working hour estimation factors and the factor weights corresponding to each of the aforementioned working hour estimation factors.

[0010] Optionally, as described above, the step of determining multiple time estimation factors based on the code repository and the supply chain risk assessment data source includes:

[0011] Based on the code repository, determine the code size factor and the technical debt coefficient factor;

[0012] Extract Git logs from the code repository and determine team capability calibration factors based on the Git logs;

[0013] External dependence risk factors are determined based on the aforementioned supply chain risk assessment data sources.

[0014] Optionally, as described above, determining the code size factor and technical debt coefficient factor based on the code repository includes:

[0015] The code repository is parsed using a static parsing tool to generate an abstract syntax tree;

[0016] Based on the abstract syntax tree, a code module call relationship graph is constructed, and based on the code module call relationship graph, the number of times each code module depends on external code modules is counted;

[0017] The module coupling degree value of each code module is determined based on the number of dependencies of each code module;

[0018] Count the total number of lines of code in the code repository, and the number of code smells per unit of code in the code repository;

[0019] The code size factor is determined based on the total number of lines of code and the coupling degree value of each module.

[0020] The technical debt coefficient factor is determined based on the total number of lines of code, the number of code smells, and the coupling degree value of each module.

[0021] Optionally, as described above, determining the code size factor based on the total number of lines of code and the coupling degree values ​​of each module includes:

[0022] The total coupling degree of the modules is determined based on the coupling degree values ​​of each module.

[0023] Retrieve the code complexity coefficient corresponding to the total module coupling value from the code complexity coefficient lookup table; wherein, the code complexity coefficient lookup table stores the correspondence between code complexity coefficients and the total module coupling value;

[0024] The code size factor is determined based on the total number of lines of code and the code complexity coefficient.

[0025] Optionally, as described above, determining the technical debt coefficient factor based on the total number of lines of code, the number of code smells, and the coupling degree values ​​of each module includes:

[0026] The bad smell density value is determined based on the total number of lines of code and the number of bad smells in the code.

[0027] The technical debt coefficient factor is determined by weighting the coupling degree value of each module and the bad smell density value.

[0028] Optionally, as described above, determining the team capability calibration factor based on the Git logs includes:

[0029] Parse the diff data in the Git logs and calculate the daily valid code commits based on the diff data;

[0030] Obtain the association ID associated with the CI / CD pipeline from the Git logs, and based on the association ID, obtain the time taken for each stage from code commit to production deployment from the Git logs;

[0031] The average time duration is determined based on the time spent on each item.

[0032] Obtain the preset team experience coefficient;

[0033] The team capability calibration factor is determined based on the daily effective code submissions, the average time taken, and the team experience coefficient.

[0034] Optionally, as described above, determining the external dependence risk factor based on the supply chain risk assessment data source includes:

[0035] The maturity risk values ​​of each open-source component required for the system product to be developed, as well as the delivery delay probability of the required third-party interfaces, are obtained from the supply chain risk assessment data source.

[0036] The target maturity risk value is obtained from the plurality of maturity risk values, which is the highest value.

[0037] The external dependency risk factor is determined by weighting the delivery delay probability and the target maturity risk value.

[0038] Optionally, as described above, determining the factor weights corresponding to each of the time estimation factors based on the development characteristics of the system product to be developed includes:

[0039] The factor weights of each time estimation factor corresponding to the development feature are retrieved from the factor weight lookup table; wherein, the factor weight lookup table stores the correspondence between the development feature and the factor weights of each time estimation factor.

[0040] Optionally, as described above, the step of estimating the working hours of the system product to be developed based on each of the working hour estimation factors and the factor weights corresponding to each of the working hour estimation factors includes:

[0041] The first working hour is obtained by performing a weighted calculation based on each of the working hour estimation factors and the factor weights corresponding to each of the working hour estimation factors.

[0042] The first working time is input into the working time calibration model, and the working time calibration model calibrates the first working time and outputs a second working time; wherein, the second working time is the final estimated working time of the system product to be developed.

[0043] Optionally, as described above, the method further includes:

[0044] The second working hours are divided according to the project phase working hour allocation ratio of the system product to be developed, so as to obtain the phase working hours of each project phase.

[0045] Work time curves are plotted based on the work time of each project phase.

[0046] Secondly, embodiments of this application provide a time estimation device for system development lifecycle, the device comprising:

[0047] The acquisition module is used to acquire code repositories and supply chain risk assessment data sources; wherein, the code repository is an open-source project code library whose functions are benchmarked against the system product to be developed;

[0048] The first determining module is used to determine multiple time estimation factors based on the code repository and the supply chain risk assessment data source;

[0049] The second determining module is used to determine the factor weights corresponding to each of the time estimation factors based on the development characteristics of the system product to be developed.

[0050] The time estimation module is used to estimate the time of the system product to be developed based on each of the time estimation factors and the factor weights corresponding to each of the time estimation factors.

[0051] Thirdly, embodiments of this application provide an electronic device, comprising: a processor and a memory, wherein the processor is configured to execute a program stored in the memory for estimating the working hours of a system development lifecycle, so as to implement the aforementioned method for estimating the working hours of a system development lifecycle.

[0052] Fourthly, embodiments of this application provide a storage medium storing one or more programs, which can be executed by one or more processors to implement the above-described method for estimating the working hours of the system development lifecycle.

[0053] The present application provides a method, apparatus, electronic device, and storage medium for estimating work hours during the system development lifecycle. The method includes: acquiring a code repository and a supply chain risk assessment data source; wherein the code repository is an open-source project code library functionally aligned with the system product to be developed; determining multiple work hour estimation factors based on the code repository and the supply chain risk assessment data source; determining the factor weights corresponding to each work hour estimation factor according to the development characteristics of the system product to be developed; and estimating the work hours of the system product to be developed based on each work hour estimation factor and its corresponding factor weight. This technical solution first obtains open-source projects with similar functions to the target system product from the code repository as a benchmark reference, while integrating supply chain risk assessment data as a supplementary basis; then, it identifies and quantifies key factors affecting work hours, dynamically adjusting the weight ratio of each factor according to product characteristics; and finally, it comprehensively calculates the work hour estimation result. This method based on objective data analysis effectively overcomes the subjective limitations of human experience, enabling accurate estimation of work hours during the system development lifecycle. Based on the estimated work hours, it allows for the reasonable allocation of personnel resources, thereby ensuring the timely delivery of the system product. Attached Figure Description

[0054] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0055] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 A flowchart illustrating an embodiment of a method for estimating working hours in the system development lifecycle provided in this application;

[0057] Figure 2 A flowchart illustrating an embodiment of another method for estimating the working hours of a system development lifecycle provided in this application;

[0058] Figure 3 A flowchart illustrating an embodiment of another method for estimating the working hours of a system development lifecycle provided in this application;

[0059] Figure 4 A flowchart illustrating an embodiment of another method for estimating the working hours of a system development lifecycle provided in this application;

[0060] Figure 5 A flowchart illustrating an embodiment of another method for estimating the working hours of a system development lifecycle provided in this application;

[0061] Figure 6 A flowchart illustrating an embodiment of another method for estimating the working hours of a system development lifecycle provided in this application;

[0062] Figure 7 A block diagram illustrating an embodiment of a system development lifecycle time estimation device provided in this application;

[0063] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0065] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0066] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0067] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0068] Foundational technologies in artificial intelligence generally include sensors, dedicated AI chips, cloud computing, storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0069] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0070] To facilitate understanding of the embodiments of this application, the following will provide further explanation and description with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of this application.

[0071] This application provides a method for estimating the working hours of a system development lifecycle. See [link to relevant documentation]. Figure 1 , Figure 1 A flowchart illustrating an embodiment of a method for estimating working hours in the system development lifecycle provided in this application. Figure 1 The process shown may include the following steps:

[0072] Step 101: Obtain the code repository and supply chain risk assessment data source;

[0073] Among them, the code repository is the open-source project code library that is functionally benchmarked against the system product to be developed; it can be understood that the code repository selects the technology stack and functional modules that need to be matched with the system product to be developed, and establishes a code feature library of the benchmark technology stack by collecting open-source code repositories that are functionally benchmarked against the system product to be developed.

[0074] Supply chain risk assessment data sources are datasets covering key indicators such as supplier reliability, component security, and delivery stability, used to assess and manage supply chain risks. In this embodiment, by simultaneously integrating supply chain risk assessment data to identify potential technology dependency risks, the combination of the two data sources covers both the inherent technical challenges of the development process and the uncertainties brought by the external supply chain, together forming a complete time estimation system.

[0075] Step 102: Determine multiple time estimation factors based on code repositories and supply chain risk assessment data sources;

[0076] The time estimation factor is the quantitative data corresponding to the key indicator factors that affect the time estimation. Its role is to transform various factors affecting time in the development process into calculable numerical dimensions. This definition method is in line with the methodology of establishing a scientific evaluation system through quantitative indicators in enterprise practice. Its essence is to transform the technical implementation difficulty and external risks into calculable variables.

[0077] Step 103: Determine the factor weights corresponding to each time estimation factor based on the development characteristics of the system product to be developed.

[0078] The weighting of time estimation factors is essentially about establishing a dynamic balance mechanism between development goals and resource input. By analyzing product characteristics (such as efficiency and stability), different weights are assigned to each time estimation factor, enabling time estimation to adapt to different development scenarios. This dynamic weight adjustment mechanism makes the estimated time more closely aligned with the development goals of the system product to be developed, and can significantly reduce time estimation deviation compared to a fixed weight model.

[0079] Step 104: Estimate the working hours of the system product to be developed based on each working hour estimation factor and the factor weight corresponding to each working hour estimation factor.

[0080] In this embodiment, authoritative data (code repositories and supply chain risk assessment data sources) are introduced as data support. Through structured data processing and dynamic weight adjustment, accurate estimation of working hours is achieved based on both, realizing the transformation from extensive working hour estimation to accurate estimation, and solving the problems of subjectivity and lag in traditional working hour estimation methods.

[0081] The aforementioned technical solution first obtains open-source projects with similar functions to the target system product from the code repository as a benchmark reference, while integrating supply chain risk assessment data as a supplementary basis; then, it identifies and quantifies the key factors affecting working hours, dynamically adjusting the weight ratio of each factor according to product characteristics; finally, it comprehensively calculates the estimated working hours. This method based on objective data analysis effectively overcomes the subjective limitations of human experience, enabling accurate estimation of working hours throughout the system development lifecycle. Based on the estimated working hours, it rationally allocates human resources, thereby ensuring the timely delivery of the system product.

[0082] like Figure 2 As shown, as an optional implementation, the method described above, step 102, which determines multiple time estimation factors based on the code repository and supply chain risk assessment data source, includes the following steps:

[0083] Step 201: Determine the code size factor and technical debt coefficient factor based on the code repository;

[0084] The code size factor is a quantitative data point for the key indicator factor of codebase size, which affects the estimated working hours. The technical debt coefficient factor is a quantitative data point for the key indicator factor of code debt, which affects the estimated working hours.

[0085] For the specific implementation process of step 201 above, please refer to [link / reference]. Figure 3 ,like Figure 3 As shown, as an optional implementation, the method described above, step 201 of determining the code size factor and technical debt coefficient factor based on the code repository includes the following steps:

[0086] Step 301: Use a static parsing tool to parse the code repository and generate an abstract syntax tree;

[0087] Using tools such as SonarQube, Checkstyle, and TreeSitter, static analysis techniques are used to scan the code repository and construct a tree structure, namely an abstract syntax tree, which contains information such as the type of syntax nodes (e.g., class declarations, method calls) and code location. Each node of this abstract syntax tree records the logical structure of each code module.

[0088] Step 302: Construct a code module call relationship graph based on the abstract syntax tree, and count the number of times each code module depends on external code modules based on the code module call relationship graph;

[0089] The abstract syntax tree is traversed to extract dependencies such as import statements and method calls. A directed code module call graph is constructed (node ​​= code module, edge = call relationship). The out-degree (number of times each module depends on others) of each module is counted to obtain the number of times each code module depends on external code modules. For example, if code module A calls 10 methods from code modules B and C, then code module A depends on external code modules 2 times (depending on two external code modules).

[0090] Step 303: Determine the module coupling value of each code module based on the number of dependencies of each code module;

[0091] The module coupling value of each code module is determined based on the number of dependencies of each code module and the total number of code modules. The formula for calculating the module coupling value (CBO) of each code module is: CBO = Number of dependencies / Total number of code modules. Continuing the previous example, if the total number of code modules is 10, then the CBO of code module A is 2 / 10 = 0.2.

[0092] Step 304: Count the total number of lines of code in the code repository and the number of code smells per unit of code in the code repository;

[0093] The total number of lines of code in the code repository is the same as the number of valid lines of code (excluding blank lines / comments).

[0094] In practical applications, tools such as PMD (Programming Mistake Detector) can be used to identify bad code such as duplicate code and excessively long methods in each unit of code in the code repository, thereby obtaining the number of code smells per unit of code in the code repository.

[0095] Step 305: Determine the code size factor based on the total number of lines of code and the coupling degree values ​​of each module;

[0096] The process of determining the code size factor can be achieved through steps A1 to A3:

[0097] Step A1: Determine the total coupling degree of the modules based on the coupling degree values ​​of each module;

[0098] The coupling values ​​of each module are added together to obtain the total coupling value of the modules.

[0099] Step A2: Query the code complexity coefficient corresponding to the total module coupling value from the code complexity coefficient lookup table;

[0100] The code complexity coefficient lookup table stores the correspondence between code complexity coefficients and the total module coupling degree. This lookup table may be a database table, an Excel spreadsheet, a configuration file, or other data structure; no specific limitation is made here. For ease of understanding, it is shown in Table 1.

[0101] Table 1

[0102] Total module coupling Code complexity coefficient 0-0.3 0.4 0.4-0.7 0.8 0.8-1 1.2

[0103] It should be noted that the above-described correspondence between code complexity coefficients and total module coupling is only an example. The specific correspondence between code complexity coefficients and total module coupling can be set according to actual needs, and is not limited here.

[0104] As can be seen from Table 1, the higher the coupling value, the higher the code complexity coefficient, where a higher code complexity coefficient indicates more complex code.

[0105] Step A3: Determine the code size factor based on the total number of lines of code and the code complexity coefficient.

[0106] Specifically, the code size factor is obtained by multiplying the total number of lines of code by the code complexity coefficient. The formula for calculating the code size factor is: Code size factor = Total number of lines of code × Code complexity coefficient.

[0107] Step 306: Determine the technical debt coefficient factor based on the total number of lines of code, the number of code smells, and the coupling degree of each module.

[0108] The process of determining the technology debt coefficient factor can be achieved through steps B1 to B2:

[0109] Step B1: Determine the code smell density value based on the total number of lines of code and the number of code smells;

[0110] The bad smell density value can be calculated using the following formula: Bad smell density value = (Number of bad smells in the code / Total number of lines of code) × 1000.

[0111] Step B2 involves weighting the coupling degree values ​​and bad smell density values ​​of each module to determine the technical debt coefficient factor.

[0112] The technology debt factor can be calculated using the following formula: Where n is the total number of code modules, and the values ​​of weight A and weight B can be set according to actual needs, without being limited here.

[0113] Step 202: Extract Git logs from the code repository and determine the team capability calibration factor based on the Git logs;

[0114] For the specific implementation process of step 202 above, please refer to [link / reference]. Figure 4 ,like Figure 4 As shown, as an optional implementation, the method described above, step 202, which involves extracting Git (Global Information Tracker) logs from the code repository and determining the team capability calibration factor based on the Git logs, includes the following steps:

[0115] Step 401: parse the diff data in the Git logs and calculate the number of valid code commits per day based on the diff data;

[0116] Use `git log --numstat` to get the number of lines added and deleted for each commit from the diff (difference) data, filter out invalid changes such as blank lines and comments, and get the daily effective code commits (number of lines added - number of lines deleted).

[0117] Step 402: Obtain the association ID associated with the CI / CD pipeline from the Git logs, and obtain the time taken for each stage from code commit to production deployment based on the association ID from the Git logs.

[0118] Extract the unique ID (Identifier) ​​generated by the system from the commit message for the CI (Continuous Integration) / CD (Continuous Deployment) pipeline. Based on the associated ID, obtain the time taken in the Git logs for the build phase (from commit time to build success time), the test phase (from build success to test pass time), and the deployment phase (from test pass time to production release time).

[0119] Step 403: Determine the average time duration based on the time spent on each project;

[0120] The median time for each stage is used to obtain the average time (to avoid interference from extreme values).

[0121] Step 404: Obtain the preset team experience coefficient;

[0122] Step 405: Determine the team capability calibration factor based on the daily effective code submissions, average time taken, and team experience coefficient.

[0123] The team capability calibration factor can be determined by the team's average delivery speed through the daily effective code submissions, average time taken, and team experience coefficient. Then, the team capability calibration factor is determined based on the team's average delivery speed.

[0124] The team's average delivery speed can be calculated using the following formula: Team average delivery speed = Daily effective code submissions / Average time taken × Team experience coefficient; where the team experience coefficient can be set according to actual needs and is not limited here.

[0125] The team capability calibration factor can be calculated using the following formula: Team capability calibration factor = Average team delivery speed / Industry benchmark.

[0126] In software development efficiency evaluation, the industry benchmark refers to a standardized reference value derived from large-scale industry data analysis, used to compare team delivery efficiency across different sectors. Example: Average team delivery speed of 500 lines / person-day ÷ industry benchmark of 400 yields a team capability calibration factor of 1.25.

[0127] Step 203: Determine external dependence risk factors based on supply chain risk assessment data sources.

[0128] For the specific implementation process of step 203 above, please refer to [link / reference]. Figure 5 ,like Figure 5 As shown, as an optional implementation, the method described above, step 203, which determines the external dependence risk factor based on the supply chain risk assessment data source, includes the following steps:

[0129] Step 501: Obtain the maturity risk value of each open source component required for the system product to be developed, as well as the delivery delay probability of the required third-party interfaces, from the supply chain risk assessment data source.

[0130] The maturity risk value is a numerical value used to quantitatively assess the comprehensive risk level of open-source components in terms of security, stability, and sustainability. The supply chain risk assessment data source includes the maturity risk values ​​of all current open-source components. Based on the requirements of the system product to be developed, the necessary source components are determined. Then, only the maturity risk values ​​of each open-source component corresponding to the system product to be developed are obtained from the supply chain risk assessment data source.

[0131] The delivery delay probability of the aforementioned third-party interfaces is a numerical value used to quantitatively assess the reliability of timely delivery of services relying on third-party interfaces. The supply chain risk assessment data source includes the delivery delay probabilities of all current third-party interfaces. Based on the requirements of the system product to be developed, the necessary third-party interfaces are determined. Then, only the delivery delay probabilities of the third-party interfaces required by the system product to be developed are obtained from the supply chain risk assessment data source.

[0132] Step 502: Obtain the target maturity risk value with the highest value from multiple maturity risk values;

[0133] Sort the maturity risk values ​​of all open source components and take the maximum value as the target maturity risk value (e.g., if component A has a risk value of 0.7 and component B has a risk value of 0.9, then the target maturity risk value is 0.9).

[0134] Step 503: Weight the delivery delay probability and the target maturity risk value to determine the external dependency risk factor.

[0135] The external dependency risk factor can be calculated using the following formula: (delivery delay probability × weight C) + (target maturity risk value × weight D); where the values ​​of weight C and weight D can be set according to actual needs and are not limited here.

[0136] The execution order of steps 201 to 203 can be flexibly adjusted according to actual needs, and there is no need to strictly follow the order.

[0137] Through the above steps, the code size factor is directly related to maintenance time, the technical debt factor reveals the high-time-consuming modules that need to be refactored, and the time allocation focuses on technical pain points. The team capability factor derived from Git logs calibrates development efficiency deviations in real time, avoiding underestimation of time due to misjudgment of capabilities. The external dependency risk factor can offset the impact of supply chain uncertainty. The above time prediction factors can comprehensively quantify the risks across the entire chain from code and team to supply chain. This method based on objective data analysis effectively overcomes the subjective limitations of human experience and can accurately predict the time of the system development life cycle.

[0138] In practical applications, to provide a clear visual representation of the status of each code module, a risk heatmap can be constructed based on the cyclomatic complexity and the number of modifications to each module. The number of modifications can be used to visually represent the risk level of each code module through color coding, with color gradients distinguishing risk levels: typically red represents high risk, yellow represents medium risk, and green represents low risk. The cyclomatic complexity can be obtained from the control flow graph generated by parsing the code repository using static analysis tools. Since the calculation process of cyclomatic complexity is existing technology, it will not be detailed here. In addition, the number of modifications to each code module is the monthly commit volume of the Git log for each code module.

[0139] Specifically, the factor weights corresponding to each time estimation factor can usually be implemented using a factor weight lookup table. The factor weights corresponding to each time estimation factor are determined based on the development characteristics of the system product to be developed, including: querying the factor weights of each time estimation factor corresponding to the development characteristics from the factor weight lookup table.

[0140] The factor weight lookup table stores the correspondence between development characteristics and the factor weights of each time-estimation factor. This factor weight lookup table may be a database table, an Excel spreadsheet, a configuration file, or other data structure; no specific limitation is made here. For ease of understanding, it is shown in Table 2:

[0141] Table 2

[0142]

[0143] It should be noted that the above-listed correspondence between development characteristics and the factor weights of various time estimation factors is only an example. The specific correspondence between development characteristics and the factor weights of various time estimation factors can be set according to actual needs, and is not limited here.

[0144] like Figure 6 As shown, as an optional implementation, the method described above, step 104, which estimates the working hours of the system product to be developed based on each working hour estimation factor and the factor weights corresponding to each working hour estimation factor, includes the following steps:

[0145] Step 601: Perform a weighted calculation based on each time prediction factor and the factor weight corresponding to each time prediction factor to obtain the first time.

[0146] The first working hour can be calculated using the following formula: Code size factor × Factor weight of code size factor + Factor weight of technical debt coefficient factor × Factor weight of technical debt coefficient factor + Factor weight of team capability calibration factor × Factor weight of team capability calibration factor + Factor weight of external dependency risk factor × Factor weight of external dependency risk factor.

[0147] Step 602: Input the first working hour into the working hour calibration model, and the working hour calibration model calibrates the first working hour and outputs the second working hour.

[0148] To obtain more accurate working hours, the first working hour can be calibrated to correct the deviation. Specifically, the first working hour is calibrated using a working hour calibration model to obtain a calibrated second working hour, which is the final estimated working hour of the system product to be developed.

[0149] The time calibration model is obtained by training a machine learning model (such as XGBoost) using the historical first working hour and the label corresponding to the first working hour. The label is the actual working hour.

[0150] In practical applications, the second working hours can be divided according to the working hour allocation ratio of the project stage of the system product to be developed (for example, the working hour allocation ratio of the core coding stage is 60%, the working hour allocation ratio of the system integration stage is 25%, the working hour allocation ratio of the risk buffer stage is 15%, etc.) to obtain the working hours of each project stage; and a working hour curve can be drawn based on the working hours of each project stage.

[0151] By dividing work hours into project phases and plotting work hour curves, the peak values ​​of the curves can be used to identify critical points in resource demand, allowing for advance deployment of manpower to avoid bottlenecks, as well as phased cost accounting, in order to successfully deliver the system product.

[0152] See Figure 7 This is a block diagram illustrating an embodiment of a system development lifecycle time estimation device provided in this application. Figure 7 As shown, the device includes:

[0153] Module 701 is used to acquire code repositories and supply chain risk assessment data sources; the code repository is an open-source project code library whose functions are benchmarked against the system product to be developed.

[0154] The first determination module 702 is used to determine multiple time estimation factors based on the code repository and supply chain risk assessment data source;

[0155] The second determining module 703 is used to determine the factor weights corresponding to each time estimation factor based on the development characteristics of the system product to be developed.

[0156] The time estimation module 704 is used to estimate the time of the system product to be developed based on each time estimation factor and the factor weight corresponding to each time estimation factor.

[0157] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0158] As an optional implementation, the first determining module 702 includes:

[0159] The third determination module is used to determine the code size factor and technical debt coefficient factor based on the code repository;

[0160] The fourth module is used to extract Git logs from the code repository and determine the team's capability calibration factor based on the Git logs.

[0161] The fifth determination module is used to determine external dependence risk factors based on supply chain risk assessment data sources.

[0162] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0163] As an optional implementation, the third determining module described above is further configured to:

[0164] Static parsing tools are used to parse the code repository and generate an abstract syntax tree;

[0165] A code module call relationship graph is constructed based on the abstract syntax tree, and the number of times each code module depends on external code modules is counted based on the code module call relationship graph;

[0166] The module coupling value of each code module is determined based on the number of dependencies of each code module;

[0167] Count the total number of lines of code in the code repository, and the number of code smells per unit of code in the code repository;

[0168] The code size factor is determined based on the total number of lines of code and the coupling degree of each module.

[0169] The technical debt coefficient factor is determined based on the total number of lines of code, the number of code smells, and the coupling degree of each module.

[0170] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0171] As an optional implementation, the third determining module described above is further configured to:

[0172] The total coupling degree of the modules is determined based on the coupling degree values ​​of each module.

[0173] Retrieve the code complexity coefficient corresponding to the total module coupling value from the code complexity coefficient lookup table; the code complexity coefficient lookup table stores the correspondence between code complexity coefficients and the total module coupling value;

[0174] The code size factor is determined based on the total number of lines of code and the code complexity coefficient.

[0175] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0176] As an optional implementation, the third determining module described above is further configured to:

[0177] Determine the bad smell density value based on the total number of lines of code and the number of bad smells in the code;

[0178] The technical debt coefficient factor is determined by weighting the coupling degree value and the bad smell density value of each module.

[0179] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0180] As an optional implementation, the fourth determining module described above is further configured to:

[0181] Parse the diff data in the Git logs and calculate the number of valid code commits per day based on the diff data;

[0182] Retrieve the association ID associated with the CI / CD pipeline from the Git logs, and based on the association ID, retrieve the time taken for each stage from code commit to production deployment from the Git logs.

[0183] The average duration is determined based on the time spent on each project.

[0184] Obtain the preset team experience coefficient;

[0185] The team capability calibration factor is determined based on the daily effective code submissions, average time taken, and team experience coefficient.

[0186] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0187] As an optional implementation, the fifth determining module described above is further configured to:

[0188] Obtain the maturity risk values ​​of each open-source component required for the system product to be developed, as well as the probability of delivery delay for the required third-party interfaces, from the supply chain risk assessment data source.

[0189] The target maturity risk value is the highest among multiple maturity risk values.

[0190] The external dependency risk factor is determined by weighting the delivery delay probability and the target maturity risk value.

[0191] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0192] As an optional implementation, the second determining module 703 described above is further configured to:

[0193] Retrieve the factor weights of each time-estimation factor corresponding to the development feature from the factor weight lookup table; the factor weight lookup table stores the correspondence between the development feature and the factor weights of each time-estimation factor.

[0194] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0195] As an optional implementation, the above-mentioned time estimation module 704 is further used for:

[0196] The first working hour is obtained by weighting the various working hour prediction factors and their corresponding factor weights.

[0197] The first working hour is input into the working hour calibration model, which calibrates the first working hour and outputs the second working hour; the second working hour is the final estimated working hour of the system product to be developed.

[0198] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.

[0199] As an optional implementation, the above-described apparatus further includes:

[0200] The time allocation module is used to allocate the second time according to the time allocation ratio of the project stage of the system product to be developed, so as to obtain the time of each project stage.

[0201] The curve plotting module is used to plot time curves based on the phase time of each project stage.

[0202] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 The illustrated electronic device 1200 includes at least one processor 1201, a memory 1202, at least one network interface 1204, and other user interfaces 1203. The various components in the electronic device 1200 are coupled together via a bus system 1205. It is understood that the bus system 1205 is used to implement communication between these components. In addition to a data bus, the bus system 1205 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 8 The general labeled all buses as Bus System 1205.

[0203] The user interface 1203 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0204] It is understood that the memory 1202 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 1202 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0205] In some implementations, memory 1202 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 12021 and application program 12022.

[0206] The operating system 12021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 12022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this application embodiment can be included in the application program 12022.

[0207] In this embodiment of the application, the processor 1201 executes the method steps provided by each method embodiment by calling the program or instructions stored in the memory 1202, specifically the program or instructions stored in the application program 12022.

[0208] The methods disclosed in the embodiments of this application can be applied to or implemented by the processor 1201. The processor 1201 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in the processor 1201. The processor 1201 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 1202. Processor 1201 reads the information in memory 1202 and completes the steps of the above method in conjunction with its hardware.

[0209] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0210] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0211] The electronic device provided in this embodiment may be as follows: Figure 8 The electronic device shown can perform the following: Figure 1-6 All steps of the time estimation method in the system development lifecycle, thereby achieving Figure 1-6 For details on the technical effectiveness of the time estimation method for the system development lifecycle shown, please refer to [link / reference needed]. Figure 1-6 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0212] This application also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0213] When one or more programs in the storage medium can be executed by one or more processors, the above-mentioned method for estimating the time required for the system development lifecycle can be implemented.

[0214] The processor is used to execute a program stored in memory that estimates the time required for the system development lifecycle, in order to implement the steps of the method for estimating the time required for the system development lifecycle.

[0215] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0216] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0217] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for estimating working hours in the system development lifecycle, characterized in that, The method includes: Obtain code repositories and supply chain risk assessment data sources; wherein, the code repository is an open-source project code library whose functions are benchmarked against the system product to be developed; Multiple time estimation factors are determined based on the code repository and the supply chain risk assessment data source; Based on the development characteristics of the system product to be developed, determine the factor weights corresponding to each of the time estimation factors; The working hours of the system product to be developed are estimated based on each of the aforementioned working hour estimation factors and the factor weights corresponding to each of the aforementioned working hour estimation factors.

2. The method according to claim 1, characterized in that, The determination of multiple time estimation factors based on the code repository and the supply chain risk assessment data source includes: Based on the code repository, determine the code size factor and the technical debt coefficient factor; Extract Git logs from the code repository and determine team capability calibration factors based on the Git logs; External dependence risk factors are determined based on the aforementioned supply chain risk assessment data sources.

3. The method according to claim 2, characterized in that, The determination of the code size factor and technical debt coefficient factor based on the code repository includes: The code repository is parsed using a static parsing tool to generate an abstract syntax tree; Based on the abstract syntax tree, a code module call relationship graph is constructed, and based on the code module call relationship graph, the number of times each code module depends on external code modules is counted; The module coupling degree value of each code module is determined based on the number of dependencies of each code module; Count the total number of lines of code in the code repository, and the number of code smells per unit of code in the code repository; The code size factor is determined based on the total number of lines of code and the coupling degree value of each module. The technical debt coefficient factor is determined based on the total number of lines of code, the number of code smells, and the coupling degree value of each module.

4. The method according to claim 3, characterized in that, The process of determining the code size factor based on the total number of lines of code and the coupling degree value of each module includes: The total coupling degree of the modules is determined based on the coupling degree values ​​of each module. Retrieve the code complexity coefficient corresponding to the total module coupling value from the code complexity coefficient lookup table; wherein, the code complexity coefficient lookup table stores the correspondence between code complexity coefficients and the total module coupling value; The code size factor is determined based on the total number of lines of code and the code complexity coefficient.

5. The method according to claim 3, characterized in that, The process of determining the technical debt coefficient factor based on the total number of lines of code, the number of code smells, and the coupling degree values ​​of each module includes: The bad smell density value is determined based on the total number of lines of code and the number of bad smells in the code. The technical debt coefficient factor is determined by weighting the coupling degree value of each module and the bad smell density value.

6. The method according to claim 2, characterized in that, The determination of team capability calibration factors based on the Git logs includes: Parse the diff data in the Git logs and calculate the daily valid code commits based on the diff data; Obtain the association ID associated with the CI / CD pipeline from the Git logs, and based on the association ID, obtain the time taken for each stage from code commit to production deployment from the Git logs; The average time duration is determined based on the time spent on each item. Obtain the preset team experience coefficient; The team capability calibration factor is determined based on the daily effective code submissions, the average time taken, and the team experience coefficient.

7. The method according to claim 2, characterized in that, The determination of external dependence risk factors based on the supply chain risk assessment data source includes: The maturity risk values ​​of each open-source component required for the system product to be developed, as well as the delivery delay probability of the required third-party interfaces, are obtained from the supply chain risk assessment data source. The target maturity risk value is obtained from the plurality of maturity risk values, which is the highest value. The external dependency risk factor is determined by weighting the delivery delay probability and the target maturity risk value.

8. The method according to claim 1, characterized in that, The step of determining the factor weights corresponding to each of the time estimation factors based on the development characteristics of the system product to be developed includes: The factor weights of each time estimation factor corresponding to the development feature are retrieved from the factor weight lookup table; wherein, the factor weight lookup table stores the correspondence between the development feature and the factor weights of each time estimation factor.

9. The method according to claim 1, characterized in that, The step of estimating the working hours of the system product under development based on each of the aforementioned working hour estimation factors and the factor weights corresponding to each of the aforementioned working hour estimation factors includes: The first working hour is obtained by performing a weighted calculation based on each of the working hour estimation factors and the factor weights corresponding to each of the working hour estimation factors. The first working time is input into the working time calibration model, and the working time calibration model calibrates the first working time and outputs a second working time; wherein, the second working time is the final estimated working time of the system product to be developed.

10. The method according to claim 9, characterized in that, The method further includes: The second working hours are divided according to the project phase working hour allocation ratio of the system product to be developed, so as to obtain the phase working hours of each project phase. Work time curves are plotted based on the work time of each project phase.

11. A time estimation device for system development lifecycle, characterized in that, The device includes: The acquisition module is used to acquire code repositories and supply chain risk assessment data sources; wherein, the code repository is an open-source project code library whose functions are benchmarked against the system product to be developed; The first determining module is used to determine multiple time estimation factors based on the code repository and the supply chain risk assessment data source; The second determining module is used to determine the factor weights corresponding to each of the time estimation factors based on the development characteristics of the system product to be developed. The time estimation module is used to estimate the time of the system product to be developed based on each of the time estimation factors and the factor weights corresponding to each of the time estimation factors.

12. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a program stored in the memory for estimating the time required for the system development lifecycle, to implement the method for estimating the time required for the system development lifecycle as described in any one of claims 1 to 10.

13. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the time estimation method for the system development life cycle according to any one of claims 1 to 10.

Images