Software development cost estimation method and device
By combining white-box and black-box testing, business and non-business functional units in software development are evaluated differently, which solves the problems of high difficulty, low efficiency and poor accuracy in the estimation of software development costs in existing technologies, and achieves efficient and accurate cost assessment.
Patent Information
- Application Number
- CN202511075444.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-31
- Publication Date
- 2025-11-18
AI Technical Summary
Existing methods for estimating software development costs suffer from high difficulty, low efficiency, and poor accuracy. In particular, they fail to reflect cost differences when evaluating high-value features, leading to inaccurate evaluation results.
White-box testing is used to evaluate the incremental functionalities of business functional units, while black-box testing is used to evaluate the incremental functionalities of non-business functional units. The total development cost is calculated by the total incremental functionalities, total development days, and unit price per person-day. This differentiated evaluation mechanism improves the accuracy and efficiency of the evaluation.
It achieves a dual improvement in the accuracy and efficiency of software development cost assessment, accurately assesses the cost of high-value functional modules, and simplifies the assessment process while lowering the technical threshold.
Smart Images

Figure CN120975867A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software engineering technology, and more specifically, to a method and apparatus for estimating software development costs. Background Technology
[0002] Driven by the global wave of digital and intelligent transformation, enterprises are deepening their digital transformation processes, with software systems becoming a key infrastructure supporting business innovation and process reshaping. Software development is characterized by dynamically changing requirements and complex technical architectures; the combination of these factors significantly increases the risk of uncontrolled software costs. Therefore, building an accurate and scientific software development cost forecasting system is not only an important means for enterprises to mitigate operational risks and optimize resource allocation, but also a crucial guarantee for improving the return on investment in digital transformation and ensuring the successful achievement of corporate strategic goals.
[0003] In the 1970s, Function Point Analysis (FPA) was proposed. This method established a methodological foundation for budgetary resource control in software engineering by deconstructing the relationship between user functional units and cost mapping. However, FPA involves many abstract concepts, making it difficult to understand and use. Furthermore, its operation is cumbersome; a complete function point count requires multiple steps, including boundary identification, function decomposition, and complexity determination. Therefore, using FPA for software development cost estimation is extremely difficult, resulting in low efficiency in practice. In addition, the measurement model used by FPA overemphasizes data-driven functions in actual measurement, leading to small differences between different function points. This is particularly unfavorable for estimating high-value function points, failing to reflect the cost differences between high-value and ordinary function points, and ultimately causing bias in the final software cost assessment.
[0004] There is currently no effective solution to the above problems. Summary of the Invention
[0005] This application provides a method and apparatus for estimating software development costs, which at least solves the technical problems of high difficulty, low efficiency and poor accuracy in estimating software development costs in existing methods.
[0006] According to one aspect of the embodiments of this application, a method for estimating software development costs is provided, comprising: dividing the software to be evaluated into multiple business functional units and multiple non-business functional units according to preset software development requirements; evaluating the function point increment of each business functional unit using white-box testing, and evaluating the function point increment of each non-business functional unit using black-box testing; determining the total function point increment of the software to be evaluated based on the function point increment of each business functional unit and the function point increment of each non-business functional unit, and using the product of the total function point increment, the total development days and total number of people of the software to be evaluated, and a preset per-person-day unit price as the total development cost of the software to be evaluated, wherein the per-person-day unit price is used to characterize the development cost per person per day for completing one function point increment.
[0007] Optionally, the multiple business functional units include: an external input unit and an external output unit; the multiple non-business functional units include at least one of the following: a device access functional unit, a dataset functional unit, a non-AI model functional unit, and an AI model functional unit.
[0008] Optionally, white-box testing is used to evaluate the function point increment of each business function unit, including: for each business function unit, determining the business type and business complexity of the business function unit; when the business type is an external input unit and the business complexity is not lower than a preset first threshold, determining the function point increment of the business function unit as a first value; when the business type is an external input unit and the business complexity is lower than the first threshold, determining the function point increment of the business function unit as a second value; when the business type is an external output unit and the business complexity is not lower than the first threshold, determining the function point increment of the business function unit as a third value; when the business type is an external output unit and the business complexity is lower than the first threshold, determining the function point increment of the business function unit as a fourth value; wherein, the first value is greater than the second value, and the third value is greater than the fourth value.
[0009] Optionally, black-box testing is used to evaluate the functional point increments of each of the non-business functional units, including: when the non-business functional unit is a device access functional unit, determining the access scenario type of the device access functional unit, and determining the baseline functional point increment of the device access functional unit based on the access scenario type, wherein the higher the complexity of the access scenario type, the larger the corresponding baseline functional point increment, and vice versa; determining the first number of access devices and the second number of access device model types of the device access functional unit, and combining the baseline functional point increment, determining the functional point increment of the device access functional unit according to the following formula:
[0010]
[0011] In the formula, FPI 设备接入功能单元 FPI 1 represents the function point increment of the device access function unit. 基准 This represents the increment of the baseline function point of the device access function unit. This indicates rounding down, where σ and γ are positive integers, and A represents the first quantity. 基准 B represents the base number of devices accessed by the device access function unit, and B represents the second quantity. 基准 The base number representing the number of device models and types connected to the device access function unit.
[0012] Optionally, evaluating the functional point increments of each of the non-business functional units using black-box testing further includes: when the non-business functional unit is a dataset functional unit, determining the application scenario type of the dataset functional unit, and determining the baseline functional point increment of the dataset functional unit based on the application scenario type, wherein the higher the complexity of the application scenario type, the larger the corresponding baseline functional point increment, and vice versa; and determining the functional point increment of the dataset functional unit according to the following formula based on the baseline functional point increment and the number of bytes in the dataset of the dataset functional unit:
[0013]
[0014] In the formula, FPI 数据集功能单元 FPI represents the function point increment of a dataset's functional unit. 基准 The baseline function point increment represents the data set functional unit, where C represents the number of bytes in the dataset (in the terabyte range), and τ is a positive integer.
[0015] Optionally, evaluating the functional point increments of each of the aforementioned non-business functional units using black-box testing further includes: when the non-business functional unit is a non-AI model functional unit, determining the model type of the non-AI model functional unit; when the model type is a new research type, determining the key indicators of the new research type non-AI model functional unit, and respectively determining the average value of the functional point increments and the same key indicators of other non-AI model functional units with the same model functions as the new research type non-AI model functional unit, using the average value as the benchmark functional point increments and benchmark key indicators of the new research type non-AI model functional unit, and determining the functional point increments of the new research type non-AI model functional unit according to the following formula:
[0016]
[0017] In the formula, FPI 新研模型 FPI 3 represents the function point increment of a non-AI model functional unit in a newly developed type. 基准 D represents the baseline function point increment of a non-AI model functional unit in a newly developed type of research. ′Let μ represent the key performance indicator (KPI), D represent the baseline KPI, and μ be a positive integer. When the model type is an improvement type, determine the improvement KPIs and original KPIs for the non-AI model functional units of the improvement type, and determine the historical function point increments of the non-AI model functional units before the improvement. Use these historical function point increments as the baseline function point increments for the non-AI model functional units of the improvement type. The function point increments of the non-AI model functional units of the improvement type are determined according to the following formula:
[0018]
[0019] In the formula, FPI 改进模型 FPI 4 represents the function point increment of a non-AI model functional unit representing an improvement type. 基准 E represents the baseline function point increment of a non-AI model functional unit of the improved type. ′ The improved key indicators represent the key indicators of the improved non-AI model functional units, E represents the original key indicators of the improved non-AI model functional units, and δ is a positive integer. When the model type is the extended type, the model complexity of the extended type non-AI model functional units is determined. When the model complexity is not lower than the preset third threshold, the historical function point increment of the extended type non-AI model functional units is used as the function point increment of the extended type non-AI model functional units. When the model complexity is lower than the third threshold, the function point increment of the extended type non-AI model functional units is determined based on the business complexity of the external output units of the extended type non-AI model functional units.
[0020] Optionally, evaluating the functional point increments of each of the non-business functional units using black-box testing further includes: when the non-business functional unit is an AI model functional unit, determining the model type of the AI model functional unit; when the model type is a self-developed type, determining the average value of the functional point increments of other AI model functional units with the same model function as the self-developed type AI model functional unit, using the average value as the baseline functional point increment of the self-developed type AI model functional unit, and using the product of the baseline functional point increment and a preset weight value as the functional point increment of the self-developed type AI model functional unit; when the model type is a reference type, determining the model complexity of the reference type AI model functional unit; when the model complexity is not lower than a preset third threshold, using the historical functional point increments of the reference type AI model functional unit as the functional point increment of the reference type AI model functional unit; when the model complexity is lower than the third threshold, determining the functional point increment of the reference type AI model functional unit based on the business complexity of the external output unit of the reference type AI model functional unit.
[0021] According to another aspect of the embodiments of this application, a software development cost estimation device is also provided, comprising: a splitting module, used to split the software to be evaluated into multiple business functional units and multiple non-business functional units according to preset software development requirements; a function point increment evaluation module, used to evaluate the function point increment of each business functional unit using white-box testing, and to evaluate the function point increment of each non-business functional unit using black-box testing; and a development cost estimation module, used to determine the total function point increment of the software to be evaluated based on the function point increment of each business functional unit and the function point increment of each non-business functional unit, and to use the product of the total function point increment, the total development days and total number of people of the software to be evaluated, and a preset per-person-day unit price as the total development cost of the software to be evaluated, wherein the per-person-day unit price is used to represent the development cost of each person completing one function point increment per day.
[0022] According to another aspect of the embodiments of this application, a computer program product is also provided, the computer program product comprising: a computer program, wherein the computer program, when executed by a processor, implements the above-described software development cost estimation method.
[0023] According to another aspect of the embodiments of this application, an electronic device is also provided, the electronic device including: a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described software development cost estimation method through the computer program.
[0024] In this embodiment, a dual-track mechanism of white-box and black-box evaluation is adopted to conduct differentiated incremental evaluation of functional points for business functions and non-business functions. The total development cost of the software to be evaluated is determined by comprehensively considering the total incremental functional points obtained from the evaluation, the total development dates and total number of personnel of the software to be evaluated, and the preset per-person-day price. This achieves the technical effect of improving both the accuracy and efficiency of software development cost evaluation, accurately assessing the development cost of software projects containing high-value functional modules, simplifying the evaluation process, and lowering the technical threshold. This solves the technical problems of high difficulty, low efficiency, and poor accuracy in existing methods for estimating software development costs. Attached Figure Description
[0025] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0026] Figure 1 This is a flowchart illustrating an optional software development cost estimation method according to an embodiment of this application.
[0027] Figure 2 This is a schematic diagram of an optional software development cost estimation device according to an embodiment of this application;
[0028] Figure 3 This is a schematic diagram of the structure of a computer terminal for implementing a software development cost estimation method according to an embodiment of this application. Detailed Implementation
[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0030] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application 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 this application 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 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.
[0031] To better understand the embodiments of this application, the following is a translation and explanation of some nouns or terms that appear in the description of the embodiments of this application:
[0032] Function Point Analysis (FPA) is a reliable and effective method for measuring software size. In FPA, any software system can be viewed as consisting of five elements: external input processing, external output processing, external query processing, internal logical files, and external reference files. By estimating the number of these five elements in the software system and multiplying them by appropriate weights (the weights being the function point increment for each element), the system's function point increment can be calculated.
[0033] FPI (Function Point Increment): In incremental or iterative software development, this refers to the number of new, modified, or deleted features in a single iteration (or version) compared to the previous baseline. Its core function is to quantify the net change in feature size. In software engineering cost standards, it is formally defined as the net increment of feature size during iterative delivery.
[0034] White-box testing, also known as structural testing or transparent box testing, is a testing method based on the internal structure and logic of a program.
[0035] Black-box testing is a testing method that does not consider the internal structure and implementation details of a program, but only focuses on whether the input and output meet expectations.
[0036] Example 1
[0037] According to an embodiment of this application, a method for estimating software development costs is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0038] Figure 1 This is a flowchart illustrating a software development cost estimation method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:
[0039] Step S102: According to the preset software development requirements, the software to be evaluated is divided into multiple business function units and multiple non-business function units.
[0040] Step S104: Use white-box testing to evaluate the functional point increments of each business function unit, and use black-box testing to evaluate the functional point increments of each non-business function unit.
[0041] Step S106: Determine the total function point increment of the software to be evaluated based on the function point increment of each business function unit and the function point increment of each non-business function unit. Then, multiply the total function point increment by the total development date and total number of people of the software to be evaluated and the preset per-person-day unit price as the total development cost of the software to be evaluated. The per-person-day unit price is used to represent the development cost of each person completing one function point increment per day.
[0042] Based on the scheme defined in steps S102 to S106 above, it can be understood that in this embodiment, a dual-track mechanism of white-box and black-box evaluation is adopted to conduct differentiated incremental evaluation of functional points for business functions and non-business functions. The total development cost of the software to be evaluated is determined by comprehensively considering the total incremental functional points obtained from the evaluation, the total development days and total number of personnel of the software to be evaluated, and the preset per-person-day unit price. This achieves the technical effect of improving both the accuracy and efficiency of software development cost evaluation, accurately evaluating the development cost of software projects containing high-value functional modules, while simplifying the evaluation process and lowering the technical threshold.
[0043] The following section explains each step of the software development cost estimation method in conjunction with a specific implementation process.
[0044] In the technical solution provided in step S102 above, the system classifies software development requirements, including but not limited to business objectives, user requirements, system architecture and technical requirements, according to their core business logic and data processing characteristics. These classifications are divided into business functional units that can be directly described by business logic (i.e., functional components in the software to be evaluated that are directly related to interaction with external systems and internal data processing) and non-business functional units that rely on specific technologies and are difficult to measure directly from the perspective of business logic.
[0045] Optionally, the multiple business function units include: an external input unit and an external output unit. The external input (EI) unit is the process by which the software receives external data or instructions, while the external output (EQ) unit is the result of the software providing data to the outside or performing operations.
[0046] Optionally, the multiple non-business functional units include at least one of the following: device access functional unit, dataset functional unit, non-AI model functional unit, and AI model functional unit. Specifically, the device access functional unit involves software support for the connection and communication of various hardware devices; the dataset functional unit focuses on the independent data preparation work required in the software project, including data collection, cleaning, and preprocessing; the non-AI model functional unit covers various logical models used in the software other than artificial intelligence models, such as business process simulation and digital twin models; and the AI model functional unit refers to the artificial intelligence models integrated in software development, including generative AI large models, task-oriented small models, and their reference models.
[0047] Furthermore, the system can use the white-box approach to evaluate the size of each business functional unit, following these steps:
[0048] For each business function unit, determine the business type and business complexity of the business function unit;
[0049] When the business type is an external input unit and the business complexity is not lower than the preset first threshold, the function point increment of the business function unit is determined to be the first value.
[0050] When the business type is an external input unit and the business complexity is lower than the first threshold, the function point increment of the business function unit is determined to be the second value.
[0051] When the business type is an external output unit and the business complexity is not lower than the first threshold, the function point increment of the business function unit is determined to be the third value.
[0052] When the business type is an external output unit and the business complexity is lower than the first threshold, the function point increment of the business function unit is determined to be the fourth value.
[0053] Among them, the first value is greater than the second value, and the third value is greater than the fourth value.
[0054] For example, consider the application scenario of optimizing external transaction interfaces in an e-commerce system upgrade project. When assessing software development costs, the system first conducts a detailed analysis of system requirements, identifying business functional units that interact with external systems, including external input units and external output units.
[0055] Next, the system further evaluates the business type and complexity of each business function unit. If an external input unit involves complex payment request processing, it needs to parse payment information in multiple formats, call multiple third-party services to verify payment status, handle exceptions, and ensure secure data transmission. Because this function involves multiple data sources, complex business logic, and security considerations, the system will determine its business complexity to be high (i.e., not lower than the preset first threshold) and assign a higher function point increment value (e.g., the first value is 12) to this complex external input unit. Conversely, if another external input unit is simply reading user login information, the system will determine its business complexity to be low (i.e., below the first threshold) and assign a lower function point increment value (e.g., the second value is 7) to this simple external input unit.
[0056] Similarly, for an external output unit, such as an order confirmation notification, if it involves large-scale concurrent processing, complex data structures, and simultaneous transmission across multiple channels, the system will determine its business complexity to be high (i.e., not lower than the first threshold), and assign a higher function point increment value (e.g., the third value is 15) to such a complex external input unit. Conversely, if an external output unit simply updates inventory information to the database and the data processing logic is relatively straightforward, the system will determine its business complexity to be low (i.e., below the first threshold), and assign a lower function point increment value (e.g., the fourth value is 9) to such a simple external output unit.
[0057] It should be noted that the first threshold, second threshold, first value, second value, third value, and fourth value mentioned above are all custom settings based on actual application scenarios and historical experience.
[0058] In addition, for the size evaluation of non-business functional units, the system can use a black-box approach combined with a variable weight mechanism to discuss the following scenarios:
[0059] (1) When the non-business function unit is the device access function unit, the system can evaluate the size of each non-business function unit in the following way:
[0060] First, determine the access scenario type of the device access function unit, and then determine the baseline function point increment of the device access function unit based on the access scenario type.
[0061] The types of access scenarios include, but are not limited to, community monitoring, industrial monitoring, and medical device networking. Higher complexity of the access scenario type implies broader device compatibility and stricter security requirements, thus requiring a larger increment in baseline function points. Conversely, lower complexity results in a smaller increment in baseline function points. In other words, there is a positive correlation between the complexity of the access scenario type and the increment in baseline function points. For example, when accessing a simple community camera scenario, the increment in baseline function points can be set to 40, while when accessing a complex mine sensor scenario, the increment can be set to 70.
[0062] Next, determine the first number of access devices (such as physical terminals, sensors, or other hardware components) and the second number of access device models and types for the device access function unit. Then, in conjunction with the baseline function point increment, determine the function point increment of the device access function unit according to the following formula:
[0063]
[0064] In the formula, FPI 设备接入功能单元 FPI 1 represents the function point increment of the device access function unit. 基准 This represents the increment of the baseline function point of the device access function unit. This indicates rounding down, where σ and γ are positive integers, and A represents the first quantity. 基准 B represents the base number of devices accessed by the device access function unit (e.g., 100, 1000, etc.), where B represents the second quantity. 基准 The cardinality representing the number of device models and types accessed by the device access function unit (e.g., 10, 50, etc.), and A 基准 and B 基准 They serve as a benchmark for converting device access-related parameters into function point adjustment coefficients. Their existence ensures that the evaluation method can reflect the actual scale and complexity of device access while maintaining the stability and universality of the overall evaluation framework.
[0065] The initial number of connected devices reflects the scale and implementation difficulty of the device access functional unit. Therefore, when calculating the function point increment, the system adjusts the function point increment of the device access functional unit based on the functional relationship between the number of connected devices and the baseline function point increment. Specifically, this is achieved through the log function and floor operation, adjusting the function point increment of each order of magnitude (i.e., A / A) as B increases. 基准 When the number of device models increases, the function point increment will also increase accordingly by multiples of σ (σ is a positive integer) to ensure a reasonable assessment of the additional costs brought about by the diversity of device models. Furthermore, considering that different device models also bring additional R&D and testing burdens—because customized access solutions or additional compatibility testing are required when there are various access device models—an increase in the B value will also lead to an increase in the function point increment. Therefore, the system also adjusts the function point increment of the device access function unit according to the functional relationship between the number of device models and the baseline function point increment. Specifically, this is achieved through the log function and floor function, increasing the function point increment by a multiple of B (i.e., B / B) for each order of magnitude increase. 基准 When this happens, the function point increment will also increase accordingly by multiples of γ (γ is a positive integer) to ensure a reasonable assessment of the additional costs brought about by the diversity of equipment models.
[0066] For example, if the device accesses the functional unit FPI 1 基准 =40, A is 10000, A 基准 B is 1000, B is 100, B 基准 If σ,γ = 3 and 10, then the function point increment of the device access function unit is:
[0067] (2) When the non-business functional unit is a dataset functional unit, the system can evaluate the size of each non-business functional unit in the following way:
[0068] First, determine the application scenario type of the dataset functional unit, and then determine the baseline functional point increment of the dataset functional unit based on the application scenario type.
[0069] These application scenarios include, but are not limited to, healthcare, fintech, and IoT data collection. These scenarios are assigned different complexity levels based on the varying data sensitivity, processing complexity, and compliance requirements involved. Higher complexity application scenarios mean increased difficulty in data processing and management, thus requiring a corresponding increase in the increment of baseline functionalities. Conversely, lower complexity application scenarios mean lower difficulty in data processing and management, resulting in a corresponding decrease in the increment of baseline functionalities.
[0070] Based on the baseline function point increment and the number of bytes in the dataset of the dataset functional unit, and in conjunction with the baseline function point increment, the function point increment of the dataset functional unit is determined according to the following formula:
[0071]
[0072] In the formula, FPI 数据集功能单元 FPI represents the function point increment of a dataset's functional unit. 基准 The baseline function point increment represents the functional unit of the dataset, C represents the number of bytes in the dataset, and τ is a positive integer.
[0073] The size of the dataset directly impacts the costs of data preprocessing, storage, and transmission; therefore, increasing the C value leads to a larger function point increment. By using the log function and floor function, the non-linear relationship between the dataset size and the baseline function point increment is calculated, avoiding unreasonable ratios between function point increments for small and large datasets and ensuring the accuracy of cost assessment.
[0074] For example, if the FPI of the dataset functional unit is 2 基准 If C = 100, C = 340TB, and τ = 3, then the function point increment of the dataset functional unit is: (3) When the non-business functional unit is a non-AI model functional unit, the system can evaluate the size of each non-business functional unit in the following way:
[0075] Determine the model type for non-AI model functional units. The model type includes one of the following: new development type, improved type, or reused type. New development type refers to a model or function developed from scratch; improved type refers to a development model that improves or optimizes an existing model or function; reused type refers to an existing model or function that can be directly used or slightly modified for use in new software projects.
[0076] When the model type is a new research type, first determine the key indicators of the non-AI model functional units of the new research type, and then determine the function point increment and the average value of the same key indicators of other non-AI model functional units with the same model functions as the non-AI model functional units of the new research type. Use the average value as the baseline function point increment and baseline key indicator of the non-AI model functional units of the new research type, and determine the function point increment of the non-AI model functional units of the new research type according to the following formula:
[0077]
[0078] In the formula, FPI 新研模型 FPI 3 represents the function point increment of a non-AI model functional unit in a newly developed type. 基准D represents the baseline function point increment of a non-AI model functional unit in a newly developed type of research. ′ denoted as key indicator, D represents the benchmark key indicator, and μ is a positive integer.
[0079] The key indicators for the non-AI model functional units of the aforementioned newly developed types can vary depending on the specific model type and application scenario. For example, if the non-AI model functional unit is a simulation model, its key indicators include, but are not limited to: accuracy, runtime events, data throughput, and scalability; if the non-AI model functional unit is a data twin model, its key indicators include real-time synchronization capability, accuracy, data fusion capability, and user interaction experience; if the non-AI model functional unit is a VR model, its key indicators include: rendering quality, response speed, and richness of interaction.
[0080] For example, if a newly developed non-AI model functional unit is an inventory forecasting model in a logistics supply chain optimization system to improve warehouse inventory turnover efficiency, its aim is to predict future inventory demand over a certain period by analyzing various factors such as historical sales data, market trends, seasonal changes, and supplier delivery times, using advanced statistical algorithms and machine learning techniques (excluding large AI generative models). If prediction accuracy is set as a key indicator, and D... ′ =0.95, using the average prediction accuracy of industry-wide inventory forecasting models as the benchmark key indicator, set D=0.85, FPI 3 基准 If we set μ = 2 and 100, then the function point increment of this new type of non-AI model functional unit is:
[0081] When the model type is an improvement type, determine the key improvement indicators (i.e., the new indicator values of the improved non-AI model functional units in terms of performance, efficiency, accuracy, resource consumption, scalability, etc.) and the original key indicators (i.e., the values of the non-AI model functional units before improvement on the same set of performance or characteristic indicators) for the improved non-AI model functional units. Also, determine the historical function point increments of the improved non-AI model functional units before improvement, and use these historical function point increments as the baseline function point increments for the improved non-AI model functional units. The function point increments for the improved non-AI model functional units are then determined according to the following formula:
[0082]
[0083] In the formula, FPI 改进模型 FPI 4 represents the function point increment of a non-AI model functional unit representing an improvement type. 基准 E represents the baseline function point increment of a non-AI model functional unit of the improved type. ′δ represents the improvement key indicator of the non-AI model functional unit of the improvement type, E represents the original key indicator of the non-AI model functional unit of the improvement type, and δ is a positive integer.
[0084] For example, if the improved non-AI model functional unit is a path optimization model in a smart logistics management system, its original method was based on the classic shortest path algorithm to calculate the optimal route for cargo transportation. However, the original method has limitations when facing real-time road condition changes and multi-objective optimization (such as balancing cost and time), so the model needs to be improved. Assuming the initial function point increment of this model is 400 FPI, then FPI 4 基准 =400, δ=2, after the computation time of the model is reduced from the original 10 seconds to 5 seconds during the improvement, the functional point increment of the non-AI model functional unit of this improvement type is:
[0085] It's important to note that the feature point increment cannot be negative. Therefore, the above calculation aims to demonstrate the impact of the differences in key metrics before and after the improvement on the feature point increment. In practical applications, the calculation logic may need to be adjusted, such as using E and E'. ′ The ratio is calculated to reflect the positive function point increment resulting from the performance improvement. Therefore, the above actual calculation can be adjusted as follows:
[0086] When the model type is a reused type, determine the model complexity of the non-AI model functional unit of the reused type; when the model complexity is not lower than the preset third threshold, use the historical function point increment of the non-AI model functional unit of the reused type as the function point increment of the non-AI model functional unit of the reused type; when the model complexity is lower than the third threshold, determine the function point increment of the non-AI model functional unit of the reused type based on the business complexity of the external output unit of the non-AI model functional unit of the reused type.
[0087] Regarding model complexity, the system makes a comprehensive judgment based on multiple dimensions such as the architecture, algorithm complexity, data processing capabilities, and business adaptability of the non-AI model functional units of the reuse type. The third threshold mentioned above is a threshold determined based on industry standards or internal corporate experience, used to distinguish whether the complexity of the reused model has reached the level that requires additional cost investment.
[0088] Specifically, during the evaluation process, if the model complexity is not lower than the third threshold, it indicates that the reuse of the model still requires a certain degree of customization to adapt to new business needs or technical environments. In this case, the historical function point increment of the model (i.e., the number of function points calculated when the original model was developed) can be directly used as the basis for cost assessment of model reuse without recalculating the function point increment, which effectively simplifies the cost assessment process for reuse. Conversely, if the model complexity is lower than the third threshold, it indicates that the cost of model reuse is low, and the main cost will appear in the business logic implementation of the external output units related to the model. In this case, the system can conduct an in-depth analysis of the business complexity of the external output units related to the model, such as the format complexity of the output data, the requirements for real-time performance, and the difficulty of integration with external systems. Then, based on these complexity indicators, the function point increment of the model can be adjusted to ensure the rationality of the cost assessment.
[0089] (4) When the non-business functional unit is an AI model functional unit, the system can evaluate the size of each non-business functional unit in the following way:
[0090] Determine the model type of the AI model functional unit. The model type includes one of the following: self-developed model or referenced model. A self-developed model refers to an AI model developed for the first time in the current software project, including but not limited to large generative AI models or small models for specific tasks. These models typically require design and training from scratch, involving the preparation of large amounts of data, algorithm selection and optimization, model training, and subsequent testing and fine-tuning. A referenced model refers to a situation where an existing AI model is reused or partially modified in the current software project. These models may come from the open-source community, other internal projects, or third-party vendors; they have undergone preliminary verification and practical application, possessing a certain degree of maturity and stability.
[0091] When the model type is self-developed, determine the average value of the function point increments of other AI model functional units that have the same model function as the self-developed AI model functional unit. Use the average value as the baseline function point increment of the self-developed AI model functional unit. Use the product of the baseline function point increment and the preset weight value as the function point increment of the self-developed AI model functional unit.
[0092] The incremental function points of other AI model functional units with the same model functionality mentioned above can come from the company's internal project database, industry standards, or publicly available academic research. Therefore, the system can obtain a baseline incremental function point value by calculating the average of these model incremental function points. This baseline value reflects the general R&D cost of implementing the same or similar AI functions. Next, based on technical indicators such as the training data scale, algorithm complexity, number of model parameters, and computational resource requirements of the self-developed AI model functional units, as well as business indicators such as their criticality in the business process, whether sensitive data processing is involved, and whether continuous model optimization and updates are required, a preset weight value is set to reflect the actual R&D difficulty and cost. Finally, the product of the baseline incremental function point value and the preset weight value is taken as the incremental function point value of the self-developed AI model functional unit. This ensures that the calculation result not only considers the general R&D cost of similar functional models but also integrates the complexity and additional costs of the self-developed model in a specific project, thus providing a more accurate cost estimate that reflects the characteristics of the project.
[0093] When the model type is a reference type, determine the model complexity of the AI model functional unit of the reference type; when the model complexity is not lower than the preset third threshold, use the historical function point increment of the AI model functional unit of the reference type as the function point increment of the AI model functional unit of the reference type; when the model complexity is lower than the third threshold, determine the function point increment of the AI model functional unit of the reference type based on the business complexity of the external output unit of the AI model functional unit of the reference type.
[0094] Regarding model complexity, the system also makes a comprehensive judgment based on factors such as the depth and breadth of the AI model functional units of the reference type, the advancement and uniqueness of the algorithm, the quality and diversity of the training data, the requirements of computing resources, and the model's positioning and role in the business process (such as the complexity of the model's input-output relationship and its coupling with the business process).
[0095] Specifically, during the evaluation process, if the complexity is not lower than the third threshold, it indicates that the reuse of the model still requires a certain degree of customization to adapt to new business needs or technical environments. In this case, the historical function point increment of the model (i.e., the number of function points calculated when the original model was developed) can be directly used as the basis for cost assessment of reusing the model, without the need to recalculate the function point increment. When the model complexity is lower than the third threshold, it means that the reuse cost of the model is low, and the main cost investment will be reflected in the business implementation of the external output units related to the model. At this time, the system can conduct in-depth analysis based on the business complexity of the external output units related to the model, such as the difficulty of processing output data, the degree of dependence on external systems, and the requirements for real-time performance and accuracy. Then, the function point increment of the model is adjusted based on these complexity indicators to ensure the rationality of the cost assessment.
[0096] It should be noted that the above σ, γ, τ, μ, δ are all custom settings based on actual application scenarios and historical experience.
[0097] Furthermore, the system can aggregate the function point increments of each business functional unit and each non-business functional unit to obtain the total function point increments (Total FPIs) of the software to be evaluated. Simultaneously, it determines the total development days (TDD) and total development staff (TDS) of the software to be evaluated. These two parameters reflect the total time and human resources expected to be invested during project execution. The system uses a preset daily rate per person (DRPP) as the basis for cost calculation. DRPP is determined comprehensively based on industry standards, the company's internal cost accounting system, employee skill levels, and market salary levels to ensure the accuracy and rationality of cost calculation.
[0098] Finally, the total feature point increment is combined with the total development days, total number of people, and per-person-day rate to calculate the total development cost (TDC) of the software to be evaluated.
[0099] It is important to note that, in order to better address cost fluctuations caused by changes in requirements, technical challenges, and uncertainties throughout the project lifecycle, and to ensure dynamic adaptability of cost estimation and more precise budget control, this application embodiment can also set different scale adjustment factors for the total function point increment at different software development stages.
[0100] Specifically, in the early stages of software development, such as project initiation and requirements design, project requirements are often unclear or unstable and may change, leading to additional workload and costs. Therefore, a higher size adjustment factor (such as 1.39 or 1.20) can be set to reserve a buffer for possible requirement changes and avoid insufficient subsequent cost estimation. At this time, the expression for the total development cost of the software to be evaluated can be written as:
[0101] TDC = Total FPIs × Size Adjustment Factor × TDS × TDD × DRPP
[0102] As software development progresses, project requirements and technical solutions become clearer, project maturity increases, and uncertainties decrease. Therefore, from the requirements design phase to the acceptance phase, the size adjustment factor gradually returns to 1.00, reflecting the project's transition from high risk to low risk and from high uncertainty to low uncertainty. At this point, the expression for the total development cost of the software to be evaluated can be written as:
[0103] TDC=Total FPIs×TDS×TDD×DRPP
[0104] The aforementioned software development cost estimation method introduces a dual-track evaluation mechanism for business functions and non-business functions to more accurately quantify software development costs. In particular, when evaluating non-business functions such as AI models and non-AI models, a black-box method without disassembly is implemented, which greatly reduces the technical threshold and operational complexity of the evaluation, making the cost evaluation process more efficient, reducing the time and manpower costs required for the evaluation, and improving the practicality of the evaluation.
[0105] Example 2
[0106] According to an embodiment of this application, a software development cost estimation apparatus for implementing the software development cost estimation method in Embodiment 1 is also provided, such as... Figure 2 As shown, the software development cost estimation device includes at least: a breakdown module 22, a function point incremental evaluation module 24, and a development cost estimation module 26, wherein:
[0107] The splitting module 22 is used to split the software to be evaluated into multiple business function units and multiple non-business function units according to the preset software development requirements.
[0108] Function point increment evaluation module 24 is used to evaluate the function point increment of each business function unit using white-box testing, and to evaluate the function point increment of each non-business function unit using black-box testing.
[0109] The development cost estimation module 26 determines the total function point increment of the software to be evaluated based on the function point increment of each business function unit and the function point increment of each non-business function unit. The total function point increment is multiplied by the total development date and total number of people of the software to be evaluated, and the preset per-person-day unit price as the total development cost of the software to be evaluated. The per-person-day unit price is used to represent the development cost of each person completing one function point increment per day.
[0110] The following section explains the functions of each module of the software development cost estimation device in conjunction with the specific implementation process.
[0111] Specifically, module 22, based on pre-defined software development requirements, including but not limited to business objectives, user needs, system architecture, and technical requirements, categorizes software functional units according to their core business logic and data processing characteristics. These categorization methods result in business functional units that can be directly described through business logic (i.e., functional components in the software to be evaluated that are directly related to interaction with external systems and internal data processing), and non-business functional units that rely on specific technologies and are difficult to measure directly from a business logic perspective. Among these:
[0112] The multiple business function units include: external input unit and external output unit. Among them, the external input (EI) unit is the process by which the software receives external data or instructions, while the external output (EQ) unit is the result of the software providing data to the outside world or performing operations.
[0113] The non-business functional units include at least one of the following: device access functional unit, dataset functional unit, non-AI model functional unit, and AI model functional unit. Specifically, the device access functional unit involves software support for the connection and communication of various hardware devices; the dataset functional unit focuses on the independent data preparation work required in the software project, including data collection, cleaning, and preprocessing; the non-AI model functional unit covers various logical models used in the software other than artificial intelligence models, such as business process simulation and digital twin models; and the AI model functional unit refers to the artificial intelligence models integrated in software development, including generative AI large models, task-oriented small models, and their reference models.
[0114] Furthermore, the function point increment evaluation module 24 can evaluate the size of each business function unit using the white-box method, following these steps:
[0115] For each business function unit, determine the business type and business complexity of the business function unit;
[0116] When the business type is an external input unit and the business complexity is not lower than the preset first threshold, the function point increment of the business function unit is determined to be the first value.
[0117] When the business type is an external input unit and the business complexity is lower than the first threshold, the function point increment of the business function unit is determined to be the second value.
[0118] When the business type is an external output unit and the business complexity is not lower than the first threshold, the function point increment of the business function unit is determined to be the third value.
[0119] When the business type is an external output unit and the business complexity is lower than the first threshold, the function point increment of the business function unit is determined to be the fourth value.
[0120] Among them, the first value is greater than the second value, and the third value is greater than the fourth value.
[0121] In addition, for the size evaluation of non-business functional units, the function point incremental evaluation module 24 can use a black-box method combined with a variable weight mechanism to discuss the following situations:
[0122] (1) When the non-business function unit is the device access function unit, the system can evaluate the size of each non-business function unit in the following way:
[0123] First, determine the access scenario type of the device access function unit, and then determine the baseline function point increment of the device access function unit based on the access scenario type. The higher the complexity of the access scenario type, the larger the corresponding baseline function point increment, and vice versa.
[0124] Next, determine the first number of access devices (such as physical terminals, sensors, or other hardware components) and the second number of access device models and types for the device access function unit. Then, in conjunction with the baseline function point increment, determine the function point increment of the device access function unit according to the following formula:
[0125]
[0126] In the formula, FPI 设备接入功能单元 FPI 1 represents the function point increment of the device access function unit. 基准 This represents the increment of the baseline function point of the device access function unit. This indicates rounding down, where σ and γ are positive integers, and A represents the first quantity. 基准 B represents the base number of devices accessed by the device access function unit (e.g., 100, 1000, etc.), where B represents the second quantity. 基准 The base number representing the number of device models and types connected to the device access function unit.
[0127] (2) When the non-business functional unit is a dataset functional unit, the system can evaluate the size of each non-business functional unit in the following way:
[0128] First, determine the application scenario type of the dataset functional unit, and then determine the baseline functional point increment of the dataset functional unit based on the application scenario type. The higher the complexity of the application scenario type, the larger the corresponding baseline functional point increment, and vice versa.
[0129] Based on the baseline function point increment and the number of bytes in the dataset of the dataset functional unit, and in conjunction with the baseline function point increment, the function point increment of the dataset functional unit is determined according to the following formula:
[0130]
[0131] In the formula, FPI 数据集功能单元 FPI represents the function point increment of a dataset's functional unit. 基准 The baseline function point increment represents the functional unit of the dataset, C represents the number of bytes in the dataset, and τ is a positive integer.
[0132] (3) When the non-business functional unit is a non-AI model functional unit, the system can evaluate the size of each non-business functional unit in the following way:
[0133] Determine the model type of the non-AI model functional unit.
[0134] When the model type is a new research type, first determine the key indicators of the non-AI model functional units of the new research type, and then determine the function point increment and the average value of the same key indicators of other non-AI model functional units with the same model functions as the non-AI model functional units of the new research type. Use the average value as the baseline function point increment and baseline key indicator of the non-AI model functional units of the new research type, and determine the function point increment of the non-AI model functional units of the new research type according to the following formula:
[0135]
[0136] In the formula, FPI 新研模型 FPI 3 represents the function point increment of a non-AI model functional unit in a newly developed type. 基准 D represents the baseline function point increment of a non-AI model functional unit in a newly developed type of research. ′ denoted as key indicator, D represents the benchmark key indicator, and μ is a positive integer.
[0137] When the model type is an improvement type, determine the key improvement indicators (i.e., the new indicator values of the improved non-AI model functional units in terms of performance, efficiency, accuracy, resource consumption, scalability, etc.) and the original key indicators (i.e., the values of the non-AI model functional units before improvement on the same set of performance or characteristic indicators) for the improved non-AI model functional units. Also, determine the historical function point increments of the improved non-AI model functional units before improvement, and use these historical function point increments as the baseline function point increments for the improved non-AI model functional units. The function point increments for the improved non-AI model functional units are then determined according to the following formula:
[0138]
[0139] In the formula, FPI 改进模型 FPI 4 represents the function point increment of a non-AI model functional unit representing an improvement type. 基准 E represents the baseline function point increment of a non-AI model functional unit of the improved type. ′ δ represents the improvement key indicator of the non-AI model functional unit of the improvement type, E represents the original key indicator of the non-AI model functional unit of the improvement type, and δ is a positive integer.
[0140] When the model type is a reused type, determine the model complexity of the non-AI model functional unit of the reused type; when the model complexity is not lower than the preset third threshold, use the historical function point increment of the non-AI model functional unit of the reused type as the function point increment of the non-AI model functional unit of the reused type; when the model complexity is lower than the third threshold, determine the function point increment of the non-AI model functional unit of the reused type based on the business complexity of the external output unit of the non-AI model functional unit of the reused type.
[0141] (4) When the non-business functional unit is an AI model functional unit, the system can evaluate the size of each non-business functional unit in the following way:
[0142] Determine the model type of the AI model functional unit.
[0143] When the model type is self-developed, determine the average value of the function point increments of other AI model functional units that have the same model function as the self-developed AI model functional unit. Use the average value as the baseline function point increment of the self-developed AI model functional unit. Use the product of the baseline function point increment and the preset weight value as the function point increment of the self-developed AI model functional unit.
[0144] When the model type is a reference type, determine the model complexity of the AI model functional unit of the reference type; when the model complexity is not lower than the preset third threshold, use the historical function point increment of the AI model functional unit of the reference type as the function point increment of the AI model functional unit of the reference type; when the model complexity is lower than the third threshold, determine the function point increment of the AI model functional unit of the reference type based on the business complexity of the external output unit of the AI model functional unit of the reference type.
[0145] Furthermore, the development cost estimation module 26 can first aggregate the function point increments of each business functional unit and the function point increments of each non-business functional unit to obtain the total function point increments (Total FPIs) of the software to be evaluated. At the same time, it determines the total development days (TDD) and total development staff (TDS) of the software to be evaluated, and uses the preset daily rate per person (DRPP) as the basis for cost calculation.
[0146] Finally, the total feature point increment is combined with the total development days, total number of people, and per-person-day rate to calculate the total development cost (TDC) of the software to be evaluated.
[0147] It should be noted that each module in the software development cost estimation device in this application embodiment corresponds one-to-one with each implementation step of the software development cost estimation method in embodiment 1. Since embodiment 1 has been described in detail, some details not shown in this embodiment can be referred to embodiment 1, and will not be elaborated further here.
[0148] Example 3
[0149] According to an embodiment of this application, a computer program product is also provided, which includes a computer program, wherein when the computer program is executed by a processor, it implements the software development cost estimation method in embodiment 1.
[0150] According to an embodiment of this application, a non-volatile storage medium is also provided, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the software development cost estimation method in Embodiment 1 by running the computer program.
[0151] According to an embodiment of this application, a processor is also provided for running a computer program, wherein the computer program executes the software development cost estimation method in Embodiment 1 during runtime.
[0152] According to an embodiment of this application, an electronic device is also provided, comprising: a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the software development cost estimation method of embodiment 1 through the computer program.
[0153] Specifically, the computer program executes the following steps during runtime: The software to be evaluated is divided into multiple business functional units and multiple non-business functional units according to preset software development requirements; the function point increment of each business functional unit is evaluated using white-box testing, and the function point increment of each non-business functional unit is evaluated using black-box testing; the total function point increment of the software to be evaluated is determined based on the function point increments of each business functional unit and each non-business functional unit, and the total function point increment is multiplied by the total development days and total number of people of the software to be evaluated, and the preset per-person-day unit price is used as the total development cost of the software to be evaluated, where the per-person-day unit price is used to represent the development cost per person per day for completing one function point increment.
[0154] As an alternative implementation, the aforementioned computer terminal may exist in the form of a mobile terminal, a computer terminal, or a similar computing device. Figure 3 A hardware block diagram of a computer terminal for implementing a software development cost estimation method is shown. Figure 3 As shown, the computer terminal 30 may include one or more processors 302 (shown as 302a, 302b, ..., 302n in the figure) 302 (processor 302 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 304 for storing data, and a transmission device 306 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 3 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, computer terminal 30 may also include... Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown.
[0155] It should be noted that the aforementioned one or more processors 302 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 30. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).
[0156] The memory 304 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the software development cost estimation method in this embodiment. The processor 302 executes various functional applications and data processing by running the software programs and modules stored in the memory 304, thereby implementing the above-mentioned application vulnerability detection method. The memory 304 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 304 may further include memory remotely located relative to the processor 302, and these remote memories can be connected to the computer terminal 30 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0157] The transmission device 306 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 30. In one example, the transmission device 306 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 306 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.
[0158] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 30.
[0159] The sequence numbers of the above embodiments are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0160] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0161] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.
[0162] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0163] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0164] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0165] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.
Claims
1. A method of software development cost estimation, characterized by, The method comprises the steps of: splitting the software to be evaluated into a plurality of business function units and a plurality of non-business function units according to preset software development requirements; evaluating the function point increments of each business function unit by using white-box testing and evaluating the function point increments of each non-business function unit by using black-box testing; determining the total function point increments of the software to be evaluated according to the function point increments of each business function unit and the function point increments of each non-business function unit, and taking the product of the total function point increments, the total development date and total number of the software to be evaluated, and a preset man-day unit price as the total development cost of the software to be evaluated, wherein the man-day unit price is used to represent the development cost of one function point increment completed by one person per day.
2. The method of claim 1, wherein the plurality of business function units comprise an external input unit and an external output unit; the plurality of non-business function units comprise at least one of a device access function unit, a data set function unit, a non-AI model function unit, and an AI model function unit.
3. The method of claim 2, wherein, The method of evaluating the function point increments of each business function unit by using white-box testing comprises the steps of: determining the business type and business complexity of each business function unit; in the case that the business type is the external input unit and the business complexity is not lower than a preset first threshold value, determining the function point increment of the business function unit as a first value; in the case that the business type is the external input unit and the business complexity is lower than the first threshold value, determining the function point increment of the business function unit as a second value; in the case that the business type is the external output unit and the business complexity is not lower than the first threshold value, determining the function point increment of the business function unit as a third value; in the case that the business type is the external output unit and the business complexity is lower than the first threshold value, determining the function point increment of the business function unit as a fourth value; wherein the first value is greater than the second value, and the third value is greater than the fourth value.
4. The method of claim 2, wherein, The method of evaluating the function point increments of each non-business function unit by using black-box testing comprises the steps of: in the case that the non-business function unit is the device access function unit, determining the access scenario type of the device access function unit, and determining the reference function point increment of the device access function unit according to the access scenario type, wherein the higher the complexity of the access scenario type, the greater the corresponding reference function point increment, and vice versa; determining the first number of access devices and the second number of types of access devices of the device access function unit, and combining the reference function point increment to determine the function point increment of the device access function unit according to the following formula: In the formula, FPI 设备接入功能单元 denotes a function point increment of the device access function unit, FPI 1 基准 denotes a reference function point increment of the device access function unit, denotes a floor function, σ, γ are positive integers, A denotes the first number, A 基准 denotes a base of the number of access devices of the device access function unit, B denotes the second number, B 基准 denotes a base of the number of model types of the access devices of the device access function unit.
5. The method of claim 2, wherein, The method of evaluating the function point increments of each non-business function unit by using black-box testing further comprises the steps of: In a case where the non-business function unit is the data set function unit, a type of application scenario of the data set function unit is determined, and a reference function point increment of the data set function unit is determined according to the type of application scenario, wherein the higher the complexity of the type of application scenario is, the greater the corresponding reference function point increment is, and vice versa; The function point increment of the data set function unit is determined according to the reference function point increment and a data set byte number of the data set function unit according to the following formula: where FPI 数据集功能单元 denotes the function point increment of the data set function unit, FPI 2 基准 denotes the reference function point increment of the data set function unit, C denotes the data set byte amount in the order of terabytes, and τ is a positive integer.
6. The method of claim 2, wherein, The function point increment of each non-business function unit is evaluated by using black box testing, and the method further includes: In a case where the non-business function unit is the non-AI model function unit, a type of model of the non-AI model function unit is determined; In a case where the type of model is a new research type, a key indicator of the non-AI model function unit of the new research type is determined, and a function point increment of another non-AI model function unit having a same model function as the non-AI model function unit of the new research type and an average value of a same key indicator are respectively determined, the average value is taken as a reference function point increment and a reference key indicator of the non-AI model function unit of the new research type, and a function point increment of the non-AI model function unit of the new research type is determined according to the following formula: In the formula, FPI 新研模型 denotes the function point increment of the newly researched type of non-AI model function unit, FPI 3 基准 denotes the reference function point increment of the newly researched type of non-AI model function unit, D ′ denotes the key indicator, D denotes the reference key indicator, and μ is a positive integer. In a case where the type of model is an improvement type, an improvement key indicator and an original key indicator of the non-AI model function unit of the improvement type are determined, and a historical function point increment of the non-AI model function unit of the improvement type before improvement is determined, the historical function point increment is taken as a reference function point increment of the non-AI model function unit of the improvement type, and a function point increment of the non-AI model function unit of the improvement type is determined according to the following formula: In the formula, FPI 改进模型 denotes the function point increment of the non-AI model function unit of the improvement type, FPI 4 基准 denotes the reference function point increment of the non-AI model function unit of the improvement type, E ′ denotes the improvement key indicator of the non-AI model function unit of the improvement type, E denotes the original key indicator of the non-AI model function unit of the improvement type, and δ is a positive integer; In a case where the type of model is a continuation type, a model complexity of the non-AI model function unit of the continuation type is determined, in a case where the model complexity is not lower than a preset third threshold value, a historical function point increment of the non-AI model function unit of the continuation type is taken as a function point increment of the non-AI model function unit of the continuation type, and in a case where the model complexity is lower than the third threshold value, a function point increment of the non-AI model function unit of the continuation type is determined according to a business complexity of an external output unit of the non-AI model function unit of the continuation type.
7. The method of claim 2, wherein, The function point increment of each non-business function unit is evaluated by using black box testing, and the method further includes: In a case where the non-business function unit is the AI model function unit, a type of model of the AI model function unit is determined; In a case where the type of model is a self-research type, an average value of a function point increment of another AI model function unit having a same model function as the AI model function unit of the self-research type is determined, the average value is taken as a reference function point increment of the AI model function unit of the self-research type, and a product of the reference function point increment and a preset weight value is taken as a function point increment of the AI model function unit of the self-research type. In a case where the model type is a reference type, a model complexity of an AI model function unit of the reference type is determined; in a case where the model complexity is not lower than a preset third threshold value, a history function point increment of the AI model function unit of the reference type is taken as a function point increment of the AI model function unit of the reference type; in a case where the model complexity is lower than the third threshold value, the function point increment of the AI model function unit of the reference type is determined according to a service complexity of an external output unit of the AI model function unit of the reference type.
8. A software development cost estimation apparatus characterized by comprising: The method comprises: a splitting module configured to split a software to be evaluated into a plurality of business function units and a plurality of non-business function units according to a preset software development requirement; a function point increment evaluation module configured to evaluate a function point increment of each of the business function units by using white-box testing and evaluate a function point increment of each of the non-business function units by using black-box testing; a development cost estimation module configured to determine a total function point increment of the software to be evaluated according to the function point increment of each of the business function units and the function point increment of each of the non-business function units, and take a product of the total function point increment, a total development date and a total number of the software to be evaluated, and a preset man-day unit price as a total development cost of the software to be evaluated, wherein the man-day unit price is used to represent a development cost of one function point increment completed by one person per day.
9. A computer program product, characterised in that, The computer program is executed by a processor to implement the software development cost estimation method in any one of claims 1 to 7. The computer program is executed by a processor to implement the software development cost estimation method in any one of claims 1 to 7.
10. An electronic device, comprising: The computer program is executed by a processor to implement the software development cost estimation method in any one of claims 1 to 7.