Software development workload determination method, management system and storage medium

Abstract

The invention relates to the technical field of computers, in particular to a software development workload determination method, a management system for implementing the method, a computer readable storage medium and a computer program product. The method comprises the following steps: quantifying a non-function demand according to a customization rule to determine a function point number corresponding to the non-function demand; calculating a first software development workload corresponding to the function demand and the quantized non-function demand by using a software workload estimation model based on a function point analysis method; obtaining a second software development workload which is determined based on an empirical method and corresponds to the functional demand and the quantized non-functional demand; verifying the first software development workload according to the second software development workload; and if the verification is passed, outputting the first software development workload.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and more specifically to a method for determining software development workload, a management system for implementing the method, a computer-readable storage medium, and a computer program product. Background Art

[0002] Software development workload assessment is an estimate of the manpower, time, resources, etc. required for a software development project, and is an important guarantee for project success. Correctly assessing software development workload can avoid project delays and waste of resources, and help companies maintain their advantages in a highly competitive market.

[0003] The current software development workload method has significant shortcomings, mainly including the lack of transparency in the evaluation process and the strong subjectivity of the evaluation results. Although traditional methods such as function points and lines of code cover functional and interface requirements, they are powerless when faced with complex projects such as architecture optimization and system upgrades, and the early evaluation plan is immature. In addition, the evaluation system based on expert experience is highly subjective and has inconsistent standards, making it difficult to ensure the objectivity and rationality of the evaluation results.

[0004] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present application, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0005] In order to solve or at least alleviate one or more of the above problems, the embodiments of the present application provide a method for determining software development workload, a management system for implementing the method, a computer-readable storage medium and a computer program product, which improve the comprehensiveness and accuracy of the workload assessment scheme by quantifying non-functional requirements and introducing a double verification mechanism, thereby providing more reliable data support for project management.

[0006] According to a first aspect of the present application, a method for determining software development workload is provided, the method comprising the following steps: quantifying non-functional requirements according to customized rules to determine the number of function points corresponding to the non-functional requirements; calculating a first software development workload corresponding to the functional requirements and the quantified non-functional requirements using a software workload estimation model based on a function point analysis method; obtaining a second software development workload corresponding to the functional requirements and the quantified non-functional requirements determined based on an empirical method; verifying the first software development workload according to the second software development workload; and outputting the first software development workload if the verification passes.

[0007] As an alternative or supplement to the above scheme, the method for determining the software development workload according to an embodiment of the present application also includes: obtaining functional requirements and non-functional requirements in a project requirement document and / or a business requirement document; determining whether the non-functional requirements include a non-quantifiable part that cannot be quantified according to the customized rules; if the non-quantifiable part is included, obtaining a third software development workload corresponding to the non-quantifiable part determined based on an empirical method.

[0008] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, determining whether the non-functional requirement includes a non-quantified part that cannot be quantified according to the customized rule includes: obtaining the total non-functional requirement development workload determined based on an empirical method; if the ratio of the total non-functional requirement development workload to the first software development workload exceeds a preset ratio threshold, determining that the non-functional requirement includes the non-quantified part; if the ratio of the total non-functional requirement development workload to the first software development workload does not exceed the preset ratio threshold, determining that the non-functional requirement does not include the non-quantified part.

[0009] As an alternative or supplement to the above solution, the method for determining software development workload according to an embodiment of the present application further includes: determining the sum of the third software development workload and the first software development workload as the final workload.

[0010] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, obtaining a third software development workload corresponding to the non-quantitative part determined based on an empirical method includes: using a work breakdown structure to decompose the non-quantitative part into work packages, wherein the smallest work package decomposed does not exceed 10 man-days.

[0011] As an alternative or supplement to the above scheme, the software development workload determination method according to an embodiment of the present application also includes: quantifying some functional requirements according to the customized rules to determine the function points corresponding to the some functions, and the applicable scenarios of the customized rules include one or more of the following: login, batch processing and scheduled tasks, public function modification, artificial intelligence models, error business processing, public function modification, data migration, data collection, data governance, multi-dimensional reports, home page or cockpit large-screen display.

[0012] As an alternative or supplement to the above solution, in a method for determining software development workload according to an embodiment of the present application, the customized rule includes: recording the login process as an external input.

[0013] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, the customized rules include: if each task in the batch processing and scheduled tasks can run independently, each task is counted separately as a transaction function; if the batch processing and scheduled tasks are intended to complete a business function, they are combined and counted as one transaction function.

[0014] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, the customized rules include: for common function modifications that affect multiple business functions, all affected business functions are counted as transaction function modifications respectively; if the cumulative count exceeds the preset function points, the excess is calculated at 50%.

[0015] As an alternative or supplement to the above solution, in a method for determining software development workload according to an embodiment of the present application, the customized rules include: splitting the error business processing of the same entry into multiple basic processes according to the type of error cause.

[0016] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, the customization rules include: counting each independent model as an internal logical file; counting model feature extraction, model training, model verification, and model parameter setting as external inputs respectively; counting model viewing as an external query; and counting model application and model interpretation as external outputs respectively.

[0017] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, the customized rules include: when data migration or import is performed through a development program, script or job, the migration conversion processing related to each logical file is counted as an external input; data migration performed through tools or configuration operations does not count function points.

[0018] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, the customization rules include: counting the business system configuration parameters for the first data collection as an internal logical file; and counting the configuration of the collection parameters as an external input.

[0019] As an alternative or supplement to the above solution, in a method for determining software development workload according to an embodiment of the present application, the customization rule includes: counting changes in business functions caused by changes in business rules that are not maintainable by users according to modifications to basic processes.

[0020] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, the customized rules include: for string search or replacement, function points are not counted; for complex data processing tasks that require the development of programs or scripts to execute, the data processing of each logical file is counted as an external input.

[0021] As an alternative or supplement to the above solution, in a method for determining software development workload according to an embodiment of the present application, the customized rule includes: determining the sum of the statistical dimensions of the multi-dimensional report as the number of basic processes.

[0022] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, the customization rules include: splitting the main blocks of the home page or the cockpit large screen; counting the blocks that do not involve data linkage as a basic process; if there is data linkage between blocks, they are combined and counted as one basic process.

[0023] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, a software workload estimation model based on a function point analysis method is used to calculate the first software development workload corresponding to the functional requirements and the quantified non-functional requirements, including: determining the total number of function points corresponding to the functional requirements and the quantified non-functional requirements; determining the first software development workload based on the product of the total number of function points, the system classification productivity, the software factor adjustment factor, and the development factor adjustment factor.

[0024] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, the software factor adjustment factor is at least partially determined by the weighted sum of the following items: system deployment architecture adjustment factor, performance adjustment factor, business continuity level adjustment factor, and operating environment adjustment factor.

[0025] As an alternative or supplement to the above solution, in a method for determining software development workload according to an embodiment of the present application, the development factor adjustment factor is at least partially determined by the product of a development language adjustment factor and a team experience adjustment factor.

[0026] As an alternative or supplement to the above scheme, in a method for determining software development workload according to an embodiment of the present application, verifying the first software development workload based on the second software development workload includes: if the difference between the second software development workload and the first software development workload does not exceed a preset range, the verification is passed.

[0027] According to a second aspect of the present application, a management system is provided, comprising: a memory; a processor; and a computer program stored in the memory and executable on the processor, wherein the execution of the computer program results in the following operations: quantifying non-functional requirements according to customized rules to determine the number of function points corresponding to the non-functional requirements; calculating a first software development workload corresponding to the functional requirements and the quantified non-functional requirements using a software workload estimation model based on a function point analysis method; obtaining a second software development workload corresponding to the functional requirements and the quantified non-functional requirements determined based on an empirical method; verifying the first software development workload according to the second software development workload; and outputting the first software development workload if the verification passes.

[0028] According to a third aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes instructions, and the instructions, when run, execute any one of the methods for determining software development workload according to the first aspect of the present application.

[0029] According to a fourth aspect of the present application, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements any one of the methods for determining software development workload described in the first aspect of the present application.

[0030] The software development workload determination scheme according to one or more embodiments of the present application realizes the quantitative conversion of non-functional requirements to software scale by integrating customized rules and function point analysis methods. Specifically, the scheme not only covers the workload estimation of traditional functional requirements, but also can quantify non-functional requirements into software scale according to customized rules, and calculate the software development workload according to the software workload estimation model based on the function point analysis method with reference to functional requirements, thereby realizing a more comprehensive and accurate software development workload evaluation. In addition, the scheme introduces a second software development workload determined based on the empirical method as a verification method, and cross-validates the model output results by comparing the difference between the first and second software development workloads. This mechanism not only improves the reliability and credibility of the estimation results, but also helps to identify and correct potential deviations or errors in the estimation process, providing more solid data support for the planning and execution of software development projects. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The above and / or other aspects and advantages of the present application will become clearer and easier to understand through the following description of various aspects in conjunction with the accompanying drawings, in which the same or similar units are represented by the same reference numerals. In the accompanying drawings:

[0032] Figure 1 A schematic flow chart of a method 10 for determining software development workload according to one or more embodiments of the present application;

[0033] Figure 2 A schematic flowchart of a method 20 for determining software development workload according to one or more embodiments of the present application; and

[0034] Figure 3 is a schematic block diagram of a management system 30 according to one or more embodiments of the present application. DETAILED DESCRIPTION

[0035] The description of the following specific embodiments is merely exemplary in nature and is not intended to limit the disclosed technology or the application and use of the disclosed technology. In addition, it is not intended to be bound by any express or implied theory presented in the aforementioned technical field, background technology or the following specific embodiments.

[0036] In the following detailed description of the embodiments, many specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it is apparent to one of ordinary skill in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features are not described in detail to avoid unnecessarily complicating the description.

[0037] Terms such as "comprising" and "including" indicate that in addition to the units and steps directly and clearly stated in the specification, the technical solution of the present application does not exclude the situation of having other units and steps that are not directly or clearly stated. Terms such as "first" and "second" do not indicate the order of units in terms of time, space, size, etc., but are only used to distinguish between units.

[0038] Function Point Analysis (FPA) is a scale measurement technique widely used in the field of software development. It aims to measure the scale of a software system by quantifying its functions, and thus support the estimation of software development workload, duration, and cost. Specifically, the FPA method divides the functions of a software system into measurable units (i.e., function points), and uses this as a basis to evaluate the scale and complexity of the software.

[0039] The "functional requirements" in this article refer to the specific functional or behavioral requirements that the software system must meet. These requirements are directly related to the core business processes and user operations of the software system, such as user login, data storage, information retrieval, etc. The "non-functional requirements" in this article refer to the requirements of the software system in terms of performance, security, availability, etc. Although these requirements do not directly affect the implementation of the function, they will have a significant impact on the overall performance of the system and user experience.

[0040] In traditional software development workload assessment methods, non-functional requirements are often ignored or difficult to quantify, resulting in incomplete workload estimation. In addition, as mentioned above, although traditional methods cover functional and interface requirements, they are powerless when faced with complex projects such as architecture optimization and system upgrades, and the preliminary assessment plan is immature. In addition, the assessment system based on expert experience is highly subjective and has inconsistent standards, making it difficult to ensure the objectivity and rationality of the assessment results. In this regard, the present application proposes a software development workload determination scheme, which improves the comprehensiveness and accuracy of the workload assessment scheme by quantifying non-functional requirements and introducing a double verification mechanism, thereby providing more reliable data support for project management. In the following, various exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings.

[0041] Referring to the accompanying drawings, Figure 1 It is a schematic flow chart of a method 10 for determining software development workload according to one or more embodiments of the present application.

[0042] like Figure 1 As shown, in step S110, the non-functional requirements are quantified according to the customized rules to determine the function points corresponding to the non-functional requirements.

[0043] Software development workload assessment is a complex and multi-dimensional process, involving multiple key links such as demand analysis, task decomposition, historical data reference, team capability assessment, and risk assessment. Accurate workload assessment can not only help to make reasonable resource allocation, but also effectively control the progress and cost of the project. Among them, demand analysis is the first step in software development workload assessment. Demand analysis can clarify the functional requirements, non-functional requirements and other constraints of the project. Optionally, before executing step S110, the project requirements and / or business requirements entered by the staff can be obtained first, and the functional requirements and non-functional requirements can be identified through demand analysis. That is, the software development workload can be evaluated based on the two dimensions of project requirements and business requirements.

[0044] As an effective tool for measuring the scale of software functional requirements, the FPA method has a direct application scope limited to the quantification of functional requirements. In other words, the FPA method has obvious limitations in the measurement of non-functional requirements. Traditionally, non-functional requirements rely on expert experience for estimation, but this method is subjective and uncertain. To this end, according to one or more embodiments of the present application, rules for customizing the function point method are proposed for some typical non-functional requirement scenarios (e.g., batch processing and scheduled tasks, artificial intelligence (AI) models, architecture optimization, etc.) so as to convert these non-functional requirements into function points for estimation. It can be understood that such customized rules not only unify the quantitative estimation standards for non-functional requirement scenarios, but also enable the FPA method to be used as the main method to comprehensively estimate the software development workload, thereby making up for the shortcomings of the empirical method estimation and improving the accuracy and objectivity of the estimation.

[0045] In addition, in view of the limitations of the FPA method in evaluating functional complexity, especially when the fast FPA method is used in the early stage of the project, transaction functions are often uniformly regarded as medium complexity to estimate function points. This simplified processing makes it difficult to accurately match the development workload required for high-complexity business functions. For example, for high-aggregation business processing scenarios (for example, error business processing), its basic process processing logic is intricate, and different logical processing branches need to be designed according to a variety of error cause codes. This highly customized requirement cannot directly reflect its software development workload through standard function points. Therefore, for such complex functional requirement scenarios, it is necessary to customize special function point rules to ensure that the estimation results can be closer to the complexity and scale of the actual development work. In view of the above reasons, one or more embodiments of the present application also customize rules for some complex functional requirement scenarios (for example, error business processing, home page or cockpit large screen display, etc.).

[0046] Exemplarily, the applicable scenarios of customized rules (for example, non-functional requirement scenarios and partial functional requirement scenarios) include but are not limited to: login, batch processing and scheduled tasks, public function modification, artificial intelligence model, error business processing, public function modification, data migration, data collection, data governance, multi-dimensional reports, home page or cockpit large screen display. The rules customized for the above scenarios will be introduced one by one below.

[0047] Custom rule 1: Record the login process as an external input (EI).

[0048] Regardless of the login method (e.g., account and password login, third-party login, etc.), as long as these methods are integrated into the same login interface, they are considered a basic process for function point calculation. Auxiliary elements involved in the login process, such as graphic verification, SMS verification, etc., are considered necessary steps in the basic process and do not increase the function point count.

[0049] Custom rule 2: If each task in a batch or scheduled task can run independently, each task is counted as a transaction function (for example, EI, external output (EO), external inquiry (EQ)); if the batch or scheduled task is intended to complete a business function, they are counted together as one transaction function.

[0050] Batch processing and scheduled tasks belong to non-functional requirement scenarios according to the rules of the standard FPA method, but in actual system development, these tasks often bear important business processing responsibilities and realize specific business value. In this regard, batch processing and scheduled tasks should be regarded as transaction functions for function point calculation under certain conditions. These conditions include but are not limited to: atomic operations in business, the ability to generate clear business value, the ability of the system to enter a stable state after execution, and task self-containment.

[0051] It should be noted that when counting by the FPA method, it is not possible to simply base it on the number of batch scripts written by developers. Instead, the number of transaction functions should be determined from a business perspective based on the definition of basic processes. This means that a basic process should be regarded as a single, indivisible operation in the business, which must achieve specific business value after completion and put the system into a stable state. For example, common batch functions such as end of day, daily clearing, daily settlement, and daily cutting can usually be identified as independent basic processes because they meet the definition of basic processes.

[0052] The following is a specific application example of custom rule 2. Assume that there are three end-of-day batch processing tasks, numbered 1, 2, and 3. If any of these tasks can be rerun independently after failure, and their execution does not depend on the success of other tasks, then they should each be counted as independent transaction functions. However, if these three batch processing tasks are executed sequentially and together complete a broader business function (such as data aggregation and report generation), and the failure of one of the tasks will prevent the execution of subsequent tasks, then they should be combined and regarded as a basic process for function point calculation. For example, in the batch processing process of generating daily reports every day, there may be multiple subtasks, such as obtaining business data A and B, processing and generating indicators C and D based on these data, and finally synthesizing these indicators into daily reports. Because these subtasks are logically closely connected and interdependent, they should be regarded as a whole - the basic process of "regularly generating daily reports", whose type is EI.

[0053] Custom rule 3: For common function modifications that affect multiple business functions, all affected business functions are counted as transaction function modifications; if the cumulative count exceeds the preset function points, the excess is calculated at 50%.

[0054] For the modification of common functions (for example, adding watermarks, embedding points, operation logs, verification, etc.), such changes often affect multiple transaction functions and have a wide impact on the system. When making scale estimates, each affected business function needs to be counted according to the modification of the transaction function. Even if certain adjustments are made to take high reuse into account, due to the large number of transaction functions involved and the high similarity of the modification content of each function, this method may lead to a significant deviation between the total scale of function point counts and the actual required workload. In this regard, in order to be closer to the actual work situation and improve the accuracy of the estimate, the high reuse modification of each transaction function affected by the modification of the common function can be counted according to the normal rules to ensure the accuracy of the basic scale. Then, when the cumulative adjusted scale reaches the preset function point number (for example, 40 function points), a more flexible coefficient method is used to calculate the part exceeding this threshold, that is, a coefficient of 50% of this part of the additional workload is given to reflect its relatively low incremental work intensity. It is understandable that Custom Rule 3 aims to balance the accuracy of the estimate with the efficiency in actual operation, ensuring that while covering a wide range of impacts, the estimated costs can also be reasonably controlled, providing a more scientific and reasonable basis for project management.

[0055] Custom rule 4: Split the error business processing of the same entry into multiple basic processes according to the error cause type.

[0056] For the error business processing flow under the same entry, in view of the complexity of its basic processing logic, differentiated logical processing branches are designed according to different error cause codes. In this regard, the error business can be subdivided into multiple independent basic processing processes according to the major categories of error cause codes, and the degree of reuse between these basic processes can be flexibly adjusted according to the needs of actual operations.

[0057] Customization rule 5: Count each independent model as an internal logic file (ILF); count model feature extraction, model training, model verification, and model parameter setting as an EI respectively; count model review as an EQ; and count model application and model interpretation as an EO respectively.

[0058] For AI models such as machine learning (ML), each independent model is counted as an ILF. Model parameters are not counted as ILFs. Business data used by the model is considered to be already in the system unless otherwise specified in the requirements, and the external interface file (ELF) is not counted. Model feature extraction is counted as EI, including related data annotation, cleaning, feature recognition, etc. If feature extraction is not described in the requirements document, it is not counted. Model training is counted as EI, which means using algorithms to process the training data set to generate a model. Model verification is counted as EI, which means using test data sets to verify and calibrate the model. Model parameter setting is counted as EI, which means that users can manually adjust model parameters. If the requirements do not describe the software with model parameter configuration function, it is not counted. Model viewing is counted as EQ, which means querying and displaying model information (including related parameters and features). If it is not described in the requirements, it is not counted. Model application is counted as EO, which means applying the model to process business data and present the results. The model explanation count is EO, which means applying the model to analyze and explain the processing results. If there is no description in the requirements, it will not be counted.

[0059] Customization rule 6: When data is migrated or imported through development programs, scripts, or jobs, each logical file-related migration conversion process is counted as one EI; data migration performed through tools or configuration operations is not counted as a function point.

[0060] When the data migration or import process is implemented by developing a dedicated program, script, or job, the migration conversion process involved in each logical file can be counted as an independent elementary process (EI). On the contrary, if the data migration is completed entirely by relying on ready-made tools and their configuration operations without writing additional programs or scripts, such migration will not be counted in the function point category. It is particularly important to note that during the counting process, the calculation transaction function should not be simply split according to the number of database tables or the specific steps of the data migration conversion process. This practice may lead to duplicate counting, thereby exaggerating the actual scale of the project. Instead, a comprehensive assessment should be made based on the integrity and complexity of the migration logic.

[0061] Customization rule 7: The business system configuration parameters for the first data collection are counted as ILF; the configuration of the collection parameters is counted as EI.

[0062] When the data distribution service platform performs batch data collection tasks for business systems, the platform will tailor collection configuration parameters for each business system data to be collected. This process utilizes the platform's automatic data collection function, and achieves efficient data integration (including public domain analysis) based on these configuration parameters, significantly reducing direct intervention at the code level. Based on the above characteristics, the following counting rules are formulated:

[0063] When a business system is included in the scope of batch data collection for the first time, its corresponding collection configuration parameters are counted as an independent ILF; at the same time, the initial setting and adjustment of these configuration parameters are counted as an elementary process (EI) to reflect the complexity of the configuration work. It should be noted that the data collection operation directly performed by the data collection function that the system already has is not counted as an additional logical file; for business systems that have participated in batch data collection, if their collection configuration needs to be updated or adjusted in the subsequent process, the logical files of their collection configuration parameters are no longer counted repeatedly. At this time, the change or optimization of the collection parameter configuration is counted as a transaction function (EI), and the specific degree of reuse and modification type are determined according to established rules.

[0064] Customization Rule 8: Changes in business functionality caused by changes in business rules that are not maintainable by users are counted as modifications to the basic process.

[0065] For business rule changes that users cannot directly maintain through the system interface, these rules are considered part of the coded data and do not directly correspond to the modification of the logic file. When these deep-level business rules change, they will affect the implementation of business functions that rely on them. In this scenario, developers need to intervene to implement rule updates by adjusting the database table structure, updating configuration files, or hard-coding directly in the program code. At the same time, in order to maintain the consistency and accuracy of the business logic, necessary modifications must be made to the relevant business function codes involving these business rules. The rules for this scenario customization are as follows: Any modification of the business function code caused by changes in business rules is considered a modification of the basic process (EI), and function points are counted accordingly.

[0066] Customization rule 9: For string search or replacement, function points are not counted; for complex data processing tasks that require the development of programs or scripts to execute, the data processing of each logical file is counted as an external input.

[0067] For example, if it is necessary to develop a program or script to perform more complex processing, such as processing business data according to new regulatory rules, cleaning up useless or invalid data, etc., the data processing of each logical file will be counted as 1 EI, and the degree of reuse and modification type will be determined according to normal rules.

[0068] Custom rule 10: Determine the sum of the statistical dimensions of the multidimensional report as the number of basic processes.

[0069] Multidimensional reports and their data drilling functions often rely on professional tools to implement. Since directly treating each report as an independent EO will lead to excessive calculation of the quantity, an optimization strategy can be adopted in actual operation: by summing (not multiplying) the supported statistical dimensions, the total amount of basic processing units (usually EOs) can be reasonably determined. Taking the specific needs of a certain business data as an example, if annual reports, quarterly reports, and monthly reports are required (there are differences between each report), and these reports need to support statistical analysis by multiple dimensions of institutions, industries, enterprise types, and business types, then when calculating the number of EOs, the addition principle should be adopted, that is, 3 (annual reports, quarterly reports, monthly reports) plus 4 (institutions, industries, enterprise types, business types) equals 7 EOs, rather than using the multiplication principle, which results in 3 times 4 equaling 12 EOs. This processing method is more efficient and meets actual needs.

[0070] Customization rule 11: Split the main blocks of the home page or cockpit screen; count the blocks that do not involve data linkage as one basic process; if there is data linkage between blocks, merge them and count them as one basic process.

[0071] The home page or cockpit screen often involves multiple blocks displayed in parallel, and each block carries different information or statistical indicators. According to the principle of function point division, although the whole can be regarded as a comprehensive basic process, since the basic process is very complex, it is considered to formulate specific rules to refine the counting. Accordingly, the home page or cockpit screen can be split and counted according to its main blocks: if there is no data linkage between blocks, each independent block is regarded as a separate basic process; conversely, if there is data interaction or linkage between blocks, these blocks should be counted together as one basic process. In addition, for functions that can be manually triggered by users in the large screen, such as drilling down to view details, the conventional function point counting method can be used for statistics.

[0072] In step S120, a first software development workload corresponding to the functional requirements and the quantified non-functional requirements is calculated using a software workload estimation model based on the FPA method.

[0073] Exemplarily, after the quantifiable parts of the functional requirements and non-functional requirements are decomposed (i.e., decomposed into corresponding EI, EO, EQ, ILF, EIF), the unadjusted function points UFP of each function point type are calculated according to the complexity weight. In one example, the UFP is calculated as follows:

[0074] UFP k =β k *T k

[0075] The value range of k is 1 to 5, corresponding to different function point types (i.e., EI, EO, EQ, ILF, EIF); UFP k represents the unadjusted function point number of the kth function point type; T k is the number of function points of the function point type corresponding to k; β k is the weight coefficient of the function point type corresponding to k.

[0076] Next, the first software development effort may be determined based on the UFP, the system classification productivity rate (PDR), the software factor adjustment factor (SWF), and the development factor adjustment factor (RDF).

[0077] Among them, PDR is the function point time consumption rate of the system, and the unit is man-hours / function point. Based on the data analysis of historical projects and requirements, the systems can be classified to determine the PDR value of each type of system, and the PDR value of each type of system can be optimized by continuously accumulating project data in the future.

[0078] SWF may be determined at least in part by the weighted sum of the following: system deployment architecture adjustment factor, performance adjustment factor, business continuity level adjustment factor, and operating environment adjustment factor. For example, the values ​​of each adjustment factor may be determined with reference to Table 1 shown below:

[0079]

[0080] Table 1

[0081] The RDF may be determined at least in part by the product of the development language adjustment factor and the team experience adjustment factor. For example, the values ​​of each adjustment factor may be determined with reference to Table 2 shown below:

[0082]

[0083] Table 2

[0084] Exemplarily, after determining UFP, PDR, SWF, and RDF, the first software development effort AE may be determined based on the following formula:

[0085] AE=S*PDR*SWF*RDF / MM

[0086]

[0087] Among them, S is the software scale estimated by FPA method; MM is the man-month conversion factor; CF is the scale change adjustment factor; DR .... k is the reuse degree adjustment coefficient of the function point type corresponding to k; MT k is the modification type adjustment coefficient of the function point type corresponding to k.

[0088] In step S130, a second software development workload corresponding to the functional requirements and the quantified non-functional requirements determined based on the empirical method is obtained. For example, the staff can perform a preliminary analysis of the project requirements document or the business requirements document offline according to the operating instructions of the software scale estimation application guide, and estimate the second software development workload based on experience.

[0089] In step S140, the first software development workload is verified according to the second software development workload. Exemplarily, the result generated by the software workload estimation model based on the FPA method can be verified using the estimation result determined by the developer using the empirical method. In a possible implementation of the present application, if the difference between the second software development workload and the first software development workload does not exceed the preset range, the verification is passed; if the difference between the second software development workload and the first software development workload exceeds the preset range, the verification is not passed.

[0090] In step S150, if the verification is passed, the first software development workload is output. For example, if the verification is not passed, the developer is required to analyze and explain the reasons, and further determine the workload through review.

[0091] It should be noted that, for software functional requirements, the software development workload based on functional requirements can be estimated based on the software workload estimation model of the FPA method (refer to step S120), and the estimation result (i.e., the first software development workload) includes the workload of common software non-functional requirements (e.g., quality, performance, etc.). That is, the development workload of some common software non-functional requirements is not estimated separately, and has been reflected in the software workload estimation model through the system productivity, software factor adjustment factor, etc. In addition, as mentioned above, the rules of the function point method are customized for some typical non-functional requirement scenarios (e.g., batch processing and scheduled tasks, AI models, etc.) so as to convert these non-functional requirements into function points for estimation. However, the non-functional requirements may also include parts that cannot be converted into software scale through customized rules (referred to as "non-quantitative parts" in this article). For the non-quantitative part, the empirical method can be used for estimation as a supplement to the software workload estimation model based on the FPA method.

[0092] Specifically, in a possible implementation of the present application, the total non-functional requirement development workload determined based on the empirical method is first obtained (for example, input by the developer); if the ratio of the total non-functional requirement development workload to the first software development workload exceeds a preset ratio threshold, that is, when the development workload of the non-functional requirements exceeds the reasonable ratio of the development workload of the non-functional requirements usually included in the first software development workload, it is determined that the non-functional requirements include a non-quantitative part, that is, the empirical method can be used to estimate the excess part as a supplement to the output result of the software workload estimation model based on the FPA method; if the ratio of the total non-functional requirement development workload to the first software development workload does not exceed the preset ratio threshold, it is determined that the non-functional requirements do not include a non-quantitative part, that is, there is no need to supplement the first software development workload.

[0093] In a possible implementation of the present application, after determining that the non-functional requirements include a non-quantified part, the software workload NFSE of the non-quantified part may be calculated based on the following formula:

[0094] NFSE=max(0,NFTE-AE*NFRR)

[0095] Among them, NFTE is the total workload of non-functional requirement development determined based on the empirical method, and NFRR is the reasonable proportion of the non-functional requirement workload in the first software development workload.

[0096] In another possible implementation of the present application, the third software development workload NFSE corresponding to the non-quantified part determined based on the empirical method can be directly obtained. Optionally, the non-quantified part can be decomposed into work packages using a work breakdown structure (WBS), wherein the minimum work package decomposed does not exceed 10 man-days.

[0097] It can be understood that, if there is a non-quantified part, the sum of the third software development workload NFSE and the first software development workload AE is determined as the final workload.

[0098] Continue to refer to Figure 2 , Figure 2 It is a schematic flow chart of a method 20 for determining software development workload according to one or more embodiments of the present application.

[0099] In step S201, functional requirements and non-functional requirements in a project requirement document and / or a business requirement document are obtained. In step S203, it is determined whether the non-functional requirements include a non-quantifiable part that cannot be quantified according to a customized rule. If the non-quantifiable part is included, a third software development workload NFSE corresponding to the non-quantifiable part determined based on an empirical method is obtained. In step S205, part of the non-functional requirements and / or part of the functional requirements are quantified according to the customized rule to determine the corresponding function points. In step S207, a first software development workload AE corresponding to the quantified requirements is calculated using a software workload estimation model based on a function point analysis method. In step S209, a second software development workload corresponding to the functional requirements and the quantified non-functional requirements determined based on an empirical method is obtained. In step S211, it is determined whether the difference between the second software development workload and the first software development workload exceeds a preset range. In step S213, if it does not exceed the preset range, the sum of NFSE and AE is determined as the final workload and output.

[0100] The execution of the above steps S201-S213 can be specifically referred to Figure 1 The description of the steps in is not repeated here.

[0101] The above-mentioned software development workload determination methods 10 and 20 realize the quantitative conversion of non-functional requirements into software scale by integrating customized rules and function point analysis methods. Specifically, the software development workload determination methods 10 and 20 not only cover the workload estimation of traditional functional requirements, but also can quantify non-functional requirements into software scale according to customized rules, and calculate the software development workload according to the software workload estimation model based on the function point analysis method with reference to the functional requirements, thereby realizing a more comprehensive and accurate software development workload evaluation. In addition, the software development workload determination methods 10 and 20 introduce the second software development workload determined based on the empirical method as a verification method, and cross-validate the model output results by comparing the difference between the first and second software development workloads. This mechanism not only improves the reliability and credibility of the estimation results, but also helps to identify and correct potential deviations or errors in the estimation process, providing more solid data support for the planning and execution of software development projects.

[0102] Figure 3 3 is a schematic block diagram of a management system 30 according to one or more embodiments of the present application. The management system 30 includes a memory 310, a processor 320, and a computer program 230 stored in the memory 310 and executable on the processor 320. The execution of the computer program 230 enables the following Figure 1 The software development workload determination method 10 or 20 shown is executed. Exemplarily, the management system 20 may be a project management system, a business requirement management system, or a comprehensive management system, suitable for evaluating software development workload in two dimensions: project and business requirement.

[0103] In addition, the present application can also be implemented as a computer-readable storage medium, in which a program for causing a computer to execute the following steps is stored. Figure 1 or Figure 2 Here, as the computer-readable storage medium, various computer-readable storage media such as disks (e.g., magnetic disks, optical disks, etc.), cards (e.g., memory cards, optical cards, etc.), semiconductor memories (e.g., ROMs, nonvolatile memories, etc.), and tapes (e.g., magnetic tapes, cassette tapes, etc.) can be used.

[0104] The present disclosure may also be implemented as a computer program product, which includes a computer program. When the computer program is executed by a processor, the following Figure 1 or Figure 2 The steps in the method are shown in the procedure.

[0105] In the applicable situation, hardware, software or a combination of hardware and software can be used to realize the various embodiments provided by the application. Moreover, in the applicable situation, without departing from the scope of the application, the various hardware components and / or software components set forth herein can be combined into a composite component comprising software, hardware and / or both. In the applicable situation, without departing from the scope of the application, the various hardware components and / or software components set forth herein can be divided into subcomponents comprising software, hardware or both. In addition, in the applicable situation, it is contemplated that the software component can be implemented as a hardware component, and vice versa.

[0106] Software according to the present application (such as program code and / or data) may be stored on one or more computer-readable storage media. It is also contemplated that the software identified herein may be implemented using one or more general or special-purpose computers and / or computer systems, networked and / or otherwise. Where applicable, the order of the various steps described herein may be changed, combined into composite steps, and / or divided into sub-steps to provide the features described herein.

[0107] The embodiments and examples set forth herein are provided to best illustrate embodiments according to the present application and its specific applications, and thereby enable those skilled in the art to implement and use the present application. However, those skilled in the art will appreciate that the above description and examples are provided only for ease of illustration and example. The description set forth is not intended to cover all aspects of the present application or to limit the present application to the precise form disclosed.

Claims

1. A method for determining software development workload, characterized in that: The method comprises the following steps: quantifying the non-functional requirements according to the customized rules to determine the number of function points corresponding to the non-functional requirements; Calculating the first software development workload corresponding to the functional requirements and the quantified non-functional requirements by using a software workload estimation model based on a function point analysis method; Obtaining a second software development workload determined based on an empirical method and corresponding to the functional requirements and the quantified non-functional requirements; verifying the first software development workload according to the second software development workload; and If the verification is successful, the first software development workload is output.

2. The method for determining software development workload according to claim 1, characterized in that: The method further comprises: Obtain functional and non-functional requirements from project requirements and / or business requirements; determining whether the non-functional requirement includes a non-quantifiable portion that cannot be quantified according to the customization rule; If the non-quantitative part is included, a third software development workload corresponding to the non-quantitative part determined based on an empirical method is obtained.

3. The method for determining software development workload according to claim 2, characterized in that: Determining whether the non-functional requirement includes a non-quantifiable portion that cannot be quantified according to the customization rule includes: Obtain the total workload of non-functional requirements development determined based on empirical methods; If the ratio of the total workload of the non-functional requirement development to the workload of the first software development exceeds a preset ratio threshold, determining that the non-functional requirement includes the non-quantified part; If the ratio of the total development workload of the non-functional requirements to the first software development workload does not exceed the preset ratio threshold, it is determined that the non-functional requirements do not include the non-quantified part.

4. The method for determining software development workload according to claim 2, characterized in that: The method further comprises: The sum of the third software development workload and the first software development workload is determined as the final workload.

5. The method for determining software development workload according to claim 2, characterized in that: Obtaining a third software development workload corresponding to the non-quantified part determined based on an empirical method includes: The non-quantitative part is decomposed into work packages using the work breakdown structure, wherein the smallest work package decomposed does not exceed 10 man-days.

6. The method for determining software development workload according to claim 1, characterized in that: The method also includes: quantifying some functional requirements according to the customized rules to determine the function points corresponding to the some functions, and the applicable scenarios of the customized rules include one or more of the following: login, batch processing and scheduled tasks, public function modification, artificial intelligence model, error business processing, public function modification, data migration, data collection, data governance, multi-dimensional reports, home page or cockpit large screen display.

7. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: Consider the login process as an external input.

8. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: If each task in a batch or scheduled task can run independently, each task will be counted as a separate transaction function; If the batch processing and scheduled tasks are intended to complete a business function, they are counted as one transaction function.

9. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: For common function modifications that affect multiple business functions, all affected business functions are counted as transaction function modifications; If the scale after cumulative counting exceeds the preset function points, the excess will be calculated at 50%.

10. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: According to the type of error cause, the error business processing of the same entrance is divided into multiple basic processes.

11. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: Count each separate model as an internal logical file; Model feature extraction, model training, model validation, and model parameter setting are each counted as an external input; Count model views as one external query; Model application and model interpretation are counted as one external output each.

12. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: When migrating or importing data through development programs, scripts, or jobs, count each logical file-related migration conversion process as an external input; Data migration performed through tools or configuration operations does not count towards function points.

13. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: The business system configuration parameters for the first data collection are counted as internal logic files; The configuration of the imputation parameters is counted as external input.

14. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: Changes in business functionality caused by changes in business rules that are not maintainable by users are counted as modifications to the underlying process.

15. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: Searching or replacing a string does not count function points; For complex data processing tasks that require the development of programs or scripts to perform, count the data processing of each logical file as one external input.

16. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: The sum of the statistical dimensions of a multidimensional report is determined as the number of basic processes.

17. The method for determining software development workload according to claim 1 or 6, characterized in that: The custom rules include: Split the main blocks of the homepage or cockpit screen; Counting blocks that do not involve data linkage as a basic process; If there is data linkage between blocks, the merge is counted as one basic process.

18. The method for determining software development workload according to claim 1 or 6, characterized in that: Using the software workload estimation model based on the function point analysis method, calculating the first software development workload corresponding to the functional requirements and the quantified non-functional requirements includes: Determine the total number of function points corresponding to the functional requirements and the quantified non-functional requirements; The first software development workload is determined based on the product of the total number of function points, the system classification productivity, the software factor adjustment factor, and the development factor adjustment factor.

19. The method for determining software development workload according to claim 18, characterized in that: The software factor adjustment factor is at least partially determined by a weighted sum of the following items: a system deployment architecture adjustment factor, a performance adjustment factor, a business continuity level adjustment factor, and an operating environment adjustment factor.

20. The method for determining software development workload according to claim 18, characterized in that: The development factor adjustment factor is determined at least in part by a product of a development language adjustment factor and a team experience adjustment factor.

21. The method for determining software development workload according to claim 1, characterized in that: Verifying the first software development workload according to the second software development workload includes: If the difference between the second software development workload and the first software development workload does not exceed a preset range, the verification passes.

22. A management system, characterized in that: The management system is used for project management and / or business demand management, and the management system includes: Memory; processor; as well as A computer program stored on the memory and executable on the processor, the execution of which results in the following operations: quantifying the non-functional requirements according to the customized rules to determine the number of function points corresponding to the non-functional requirements; Calculating the first software development workload corresponding to the functional requirements and the quantified non-functional requirements by using a software workload estimation model based on a function point analysis method; Obtaining a second software development workload determined based on an empirical method and corresponding to the functional requirements and the quantified non-functional requirements; verifying the first software development workload according to the second software development workload; as well as If the verification is successful, the first software development workload is output.

23. The management system according to claim 22, characterized in that: The execution of the computer program also results in the following operations: Obtain functional and non-functional requirements from project requirements and / or business requirements; determining whether the non-functional requirement includes a non-quantifiable portion that cannot be quantified according to the customization rule; If the non-quantitative part is included, obtaining a third software development workload corresponding to the non-quantitative part determined based on an empirical method; The sum of the third software development workload and the first software development workload is determined as the final workload.

24. The management system according to claim 23, characterized in that: Determining whether the non-functional requirement includes a non-quantifiable portion that cannot be quantified according to the customization rule includes: Obtain the total workload of non-functional requirements development determined based on empirical methods; If the ratio of the total workload of the non-functional requirement development to the workload of the first software development exceeds a preset ratio threshold, determining that the non-functional requirement includes the non-quantified part; If the ratio of the total development workload of the non-functional requirements to the first software development workload does not exceed the preset ratio threshold, it is determined that the non-functional requirements do not include the non-quantified part.

25. The management system according to claim 22, characterized in that: Using the software workload estimation model based on the function point analysis method, calculating the first software development workload corresponding to the functional requirements and the quantified non-functional requirements includes: Determine the total number of function points corresponding to the functional requirements and the quantified non-functional requirements; The first software development workload is determined based on the product of the total number of function points, the system classification productivity, the software factor adjustment factor, and the development factor adjustment factor.

26. The management system according to claim 25, characterized in that: The software factor adjustment factor is at least partially determined by a weighted sum of the following: a system deployment architecture adjustment factor, a performance adjustment factor, a business continuity level adjustment factor, an operating environment adjustment factor; and / or The development factor adjustment factor is determined at least in part by a product of a development language adjustment factor and a team experience adjustment factor.

27. The management system according to claim 22, characterized in that: Verifying the first software development workload according to the second software development workload includes: If the difference between the second software development workload and the first software development workload does not exceed a preset range, the verification passes.

28. The management system according to claim 22, characterized in that: The execution of the computer program further results in the following operations: quantifying the partial functional requirements according to the customization rules to determine the function points corresponding to the partial functions; and The applicable scenarios of the customized rules include one or more of the following: login, batch processing and scheduled tasks, public function modification, artificial intelligence models, error business processing, public function modification, data migration, data collection, data governance, multi-dimensional reports, home page or cockpit large-screen display.

29. The management system according to claim 22 or 28, characterized in that: The custom rules include one or more of the following: Record the login process as an external input; According to the error cause type, the error business processing of the same entrance is divided into multiple basic processes; When migrating or importing data through development programs, scripts, or jobs, count each logical file-related migration conversion process as an external input; Changes in business functionality caused by changes in business rules that are not maintainable by users are counted as modifications to basic processes; The sum of the statistical dimensions of a multidimensional report is determined as the number of basic processes.

30. The management system according to claim 22 or 28, characterized in that: The custom rules include: If each task in a batch or scheduled task can run independently, each task will be counted as a separate transaction function; If the batch processing and scheduled tasks are intended to complete a business function, they are counted as one transaction function.

31. The management system according to claim 22 or 28, characterized in that: The custom rules include: For common function modifications that affect multiple business functions, all affected business functions are counted as transaction function modifications; If the scale after cumulative counting exceeds the preset function points, the excess will be calculated at 50%.

32. The management system according to claim 22 or 28, characterized in that: The custom rules include: Count each separate model as an internal logical file; Model feature extraction, model training, model validation, and model parameter setting are each counted as an external input; Count model views as one external query; Model application and model interpretation are counted as one external output each.

33. The management system according to claim 22 or 28, characterized in that: The custom rules include: The business system configuration parameters for the first data collection are counted as internal logic files; The configuration of the imputation parameters is counted as external input.

34. The management system according to claim 22 or 28, characterized in that: The custom rules include: Searching or replacing a string does not count function points; For complex data processing tasks that require the development of programs or scripts to perform, count the data processing of each logical file as one external input.

35. The management system according to claim 22 or 28, characterized in that: The custom rules include: Split the main blocks of the homepage or cockpit screen; Counting blocks that do not involve data linkage as a basic process; If there is data linkage between blocks, the merge is counted as one basic process.

36. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes instructions, which, when executed, execute the method for determining software development workload according to any one of claims 1-21.

37. A computer program product, characterized in that It comprises a computer program, which, when executed by a processor, implements the method for determining the software development workload according to any one of claims 1-21.

Images