Software function scale measurement method and device, electronic equipment, storage medium and product

Abstract

The invention provides a software function scale measurement method and device, electronic equipment, a storage medium and a product. The method comprises the following steps: acquiring a demand document of a software project; analyzing the demand document by using a target large language model to obtain a plurality of function point counting items, the target large language model being a large language model finely adjusted by knowledge in the field of software function scale measurement; performing transaction type identification on each function point counting item by using a target large language model to obtain a transaction type corresponding to the function point counting item; and generating a software function scale measurement result of the software project based on the transaction type.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, and in particular to a method, apparatus, electronic device, storage medium, and product for measuring software functional scale. Background Technology

[0002] In the stages of software project initiation, bidding, cost accounting, and schedule control, the results of software function scale measurement determine the rationality of project workload assessment, cost quotation, and resource allocation.

[0003] Traditional methods for measuring software feature size rely heavily on manual measurement. Staff must manually identify feature descriptions from requirements documents, break down feature point counts, determine transaction types, and ultimately count the number of feature points, based on international software feature size measurement standards. This traditional approach is highly dependent on the professional skills of staff, requiring a thorough understanding of the measurement standard rules. Since manual judgment is easily influenced by subjective experience, measurement results may differ among different personnel. Furthermore, manually parsing and calculating from lengthy and inconsistently formatted requirements documents is time-consuming and difficult to adapt to the rapid iteration pace of software development, resulting in low accuracy and efficiency in software feature size measurement. Summary of the Invention

[0004] This disclosure provides a method, apparatus, electronic device, storage medium, and product for measuring software functional scale, in order to solve problems in related technologies.

[0005] A first aspect of this disclosure provides a method for measuring software functional scale, the method comprising: Obtain the requirements document for the software project; The target large language model is used to parse the requirements document to obtain multiple function point counts. The target large language model is a large language model that has been fine-tuned with domain knowledge of software function scale measurement. The target large language model is used to identify the transaction type for each function point count item, and the transaction type corresponding to the function point count item is obtained. Based on the transaction type, generate software feature size measurement results for the software project.

[0006] In one embodiment, before obtaining the requirements document for a software project, the method provided in this disclosure includes: Acquire multi-scenario data related to software functionality and scale metrics; Based on the target question-answer pair template, a general large language model is used to generate question-answer pairs from multi-scenario data in order to construct a scenario-specific question-answer pair dataset.

[0007] In one embodiment, after generating question-answer pairs from multi-scenario data using a general large language model based on a target question-answer pair template to construct a scenario-specific question-answer pair dataset, the method provided in this disclosure includes: The question-answer pair dataset is used as training data for a general large language model, which is then fine-tuned to obtain the target large language model.

[0008] In one embodiment, the requirements document is parsed using a target large language model to obtain multiple function point count items, including: The chapter titles and body content of the requirements document are parsed to obtain the first document data; Construct the first prompt information, and use the first prompt information to guide the target large language model to analyze the structure of the first document data to obtain the second document data; Construct a second prompt message and use the second prompt message to guide the target large language model to extract the functional description text from the second document data; Construct a third prompt message and use it to guide the target large language model to generate function point count items that conform to the expression rules based on the function description text.

[0009] In one embodiment, a target large language model is used to identify the transaction type for each function point count item to obtain the transaction type corresponding to the function point count item, including: Build categorized prompts that include transaction type definitions; The target large language model is guided by classification prompts to identify the transaction type for each function point count item, and the transaction type corresponding to the function point count item is obtained. The transaction type includes internal logic file, external interface file, external input, external output and external query.

[0010] In one embodiment, based on the transaction type, a software feature size metric for the software project is generated, including: The total number of function points is determined based on the transaction type of each function point count item, according to the software function size measurement standard rules. Based on the target adjustment factor and target pricing model, determine the workload and cost quotation corresponding to the total number of function points; Based on the transaction type, total number of function points, workload, and cost quote, generate software function scale measurement results for the software project.

[0011] A second aspect of this disclosure provides a software function size measurement device, the device comprising: The acquisition unit is used to acquire the requirements document for a software project. The parsing unit is used to parse the requirements document using the target large language model to obtain multiple function point counts. The target large language model is a large language model that has been fine-tuned with domain knowledge of software function scale measurement. The identification unit is used to identify the transaction type of each function point count item using the target large language model, and obtain the transaction type corresponding to the function point count item. The generation unit is used to generate software feature size metrics for software projects based on transaction type.

[0012] A third aspect of this disclosure provides an electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods described in the first aspect of this disclosure.

[0013] A fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods described in the first aspect of this disclosure.

[0014] A fifth aspect of this disclosure provides a computer program product including a computer program that, when executed by a processor, implements the methods described in the first aspect of this disclosure.

[0015] In summary, this disclosure proposes a method for measuring software functional scale. The method includes: obtaining the requirements document of the software project; parsing the requirements document using a target large language model to obtain multiple functional point count items, wherein the target large language model is a large language model fine-tuned with knowledge of the software functional scale measurement domain; identifying the transaction type of each functional point count item using the target large language model to obtain the transaction type corresponding to the functional point count item; and generating the software functional scale measurement result of the software project based on the transaction type.

[0016] According to the solution provided in this disclosure, the target large language model, finely tuned with knowledge of the software function size measurement domain, automatically completes the parsing of requirements documents, extraction of function point counts, and identification of transaction types. This eliminates the reliance on the experience of professionals in traditional manual measurement, effectively avoids the bias of subjective human judgment, improves the accuracy of function point statistics and transaction type determination, and shortens the conversion cycle from requirements documents to measurement results, reduces labor costs, and improves the accuracy and efficiency of software function size measurement.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0019] Figure 1 A flowchart illustrating a software functional scale measurement method provided in an embodiment of this disclosure; Figure 2 A flowchart illustrating a software functional scale measurement method provided in an embodiment of this disclosure; Figure 3 A flowchart illustrating a method for generating a question-answer pair dataset provided in an embodiment of this disclosure; Figure 4 A flowchart illustrating a method for fine-tuning a general-purpose large language model provided in this embodiment of the disclosure; Figure 5 A flowchart illustrating a method for extracting function point count items provided in an embodiment of this disclosure; Figure 6 A flowchart illustrating a method for classifying function point transaction types according to an embodiment of this disclosure; Figure 7 A flowchart illustrating a software functional scale measurement method provided as an application example of this disclosure; Figure 8 A schematic diagram of the structure of a software function size measurement device provided in an embodiment of this disclosure; Figure 9 This is a schematic diagram of the hardware composition structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0020] Embodiments of this disclosure are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0021] To facilitate a better understanding of the technical solutions described in the embodiments of this disclosure by those skilled in the art, the technical terms in the embodiments of this disclosure are explained as follows before introducing the embodiments of this disclosure.

[0022] The Netherlands Software Measurement Association (NESMA) is a globally influential and authoritative professional organization in the field of Function Point Analysis (FPA).

[0023] With the evolution of the times, the software industry has become a massive sector, and its technology and market have entered a highly mature stage. However, due to the complexity of requirements in software development projects, the richness of development environments and systems, the diversity of development languages ​​and tools, and the uncertainty of deployment and testing, the measurement, evaluation, and management of workload and costs in the software industry have become extremely difficult. After a long period of exploration and practice, some methods for measuring software costs have emerged.

[0024] Currently, the most mature and mainstream software cost measurement method in the industry is generally based on Function Point Analysis (FPA). FPA is a language-independent method that effectively measures software size. The Dutch Software Measurement Association (NESMA) further developed and refined FPA theory, launching NESMA FPA and publishing the related international function point standard ISO / IEC 24570:2018: NESMA Functional Size Measurement Method. The NESMA method is an easy-to-learn, practical, fast, and economical method for measuring software size and cost, helping teams comprehensively assess the size, workload, and cost of software projects in the early stages of a project. The general process of the NESMA method is as follows: First, the function point count items for the project need to be extracted from the requirements document. Then, the transaction type for each item is determined. There are five transaction types: External Interface File (EIF), Internal Logical File (ILF), External Query (EQ), External Input (EI), and External Output (EO). The function point complexity of each function point is estimated based on the transaction type, and the total function points are calculated. Finally, the workload or cost of the software is estimated and measured based on the function points using various adjustment factors.

[0025] There are two main methods for measuring the aforementioned NESMA feature points: manual measurement and intelligent measurement. Manual measurement relies heavily on the professional skills and experience of assessors. Based on the requirements document, they manually extract the feature point counts for the software development, evaluate the transaction type of each feature point count, and further calibrate the size estimate using various adjustment factors to provide a basis for cost measurement. This process is time-consuming and labor-intensive, and cannot eliminate the uncertainty of the evaluation results caused by human factors. Intelligent measurement, on the other hand, often employs Natural Language Processing (NLP) methods. It leverages artificial intelligence to automatically generate feature point counts and intelligently evaluate transaction types, then calculates the final cost measurement result according to a specific formula. This effectively reduces human interference and achieves better and faster accurate software size and cost measurement. The core of intelligent measurement lies in using artificial intelligence (AI) algorithms to determine the transaction type. The estimation of complexity and the calculation of adjustment factors often have fixed calculation methods that only require logical operations and usually do not require additional AI capabilities.

[0026] Currently, there are two main methods for automating the generation of function point counts. The first method requires clients to write requirement documents based on specific templates and develop corresponding parsing systems or interfaces to automatically generate function point counts based on specific input items. This method heavily relies on each organization's business specifications and template requirements. The content of the function point counts is often extracted based on specific rules; for example, directly parsing subheadings from the function descriptions in the requirement document as counts. This makes the method lack in accuracy, innovation, and scalability. The second method is based on keyword matching using a pre-set industry corpus, identifying function point counts in the requirement document sentence by sentence. This method heavily relies on a very large amount of high-quality, authoritative industry data. Acquiring, processing, and de-identifying this data is a very challenging task. Many organizations lack the channels, manpower, and resources to create a comprehensive and compliant corpus, making this method difficult to reproduce.

[0027] Currently, most intelligent measurement of function point size is based on a combination of AI and NLP methods. Early teams used shallow backpropagation (BP) neural networks to estimate software workload size. While this method wasn't specifically designed for NESMA metrics, and shallow networks have significant performance improvement potential, its approach of training relevant NLP models with manually labeled data to achieve size classification provides good guidance for intelligent measurement of NESMA function point size. In the practice of NESMA methods, some teams have used least squares regression to fit function point coefficients based on historical data. While this method makes the estimated software workload more accurate, it doesn't automatically identify transaction types; it only automatically adjusts the adjustment factors in the estimation stage after identifying the transaction type. Because the adjustment factors involved are strongly correlated with the unit's business specifications and historical data, this method exhibits a lack of universality.

[0028] With the development of deep learning technology, deep learning-based sequence labeling named entity recognition methods (such as Bidirectional Long Short-Term Memory Network-Conditional Random Field, or BiLSTM-CRF for short) have become an effective method for solving NESMA (Neural Function Point) intelligent measurement. Furthermore, as pre-trained models represented by BERT have matured, using BERT and its derivative pre-trained models as text feature encoders for entity label classification prediction has become a high-performance method, due to the strong text representation and understanding capabilities of BERT and other pre-trained models. However, when implementing sequence labeling tasks using this method, prediction is performed token by token (a unit of text, typically a character in Chinese). When creating the dataset, character-by-character labeling is required, still necessitating significant additional manpower for processing historical data. Simultaneously, this method often requires customized training of different models for different stages of the measurement task, resulting in high development costs, difficult parameter tuning, and limited scalability as performance cannot be further improved by changing the model size or increasing training data.

[0029] In the past two years, with the sweeping development of Large Language Models (LLMs) technology, AI's ability to solve NLP tasks has reached a new level. Some teams have used software application documentation to train large models to solve functionalities. This proposal uses large model technology to further empower each measurement step, solving the aforementioned problems to the greatest extent while significantly improving the accuracy of intelligent measurement of NESMA software costs.

[0030] The following is a brief introduction to one approach for measuring software functional scale in related technologies: The solution proposes preprocessing the software's application documentation to obtain question-and-answer pair data as training data. This data includes document paragraphs and their corresponding function point details. The document paragraphs and their corresponding function point details are then input into a large language model for training, with vertical domain fine-tuning and the introduction of specific prompts to obtain the trained large language model. The software's application documentation is then segmented into text strings, which are batch-processed and input in parallel into the trained large language model to obtain function point outputs. Finally, the software cost is assessed based on these function point outputs.

[0031] The above solution has the following drawbacks: Training a large model using only document paragraphs from different types of software applications and their corresponding detailed functional specifications suffers from data sparsity and insufficient knowledge, which negatively impacts the model's understanding performance and task completion. The trained model can only effectively handle the task of generating functional points from paragraph text, exhibiting weak generalization and a waste of model parameters.

[0032] In the question-and-answer pair generation stage, the application document is divided into paragraphs according to the application area boundaries, and the document paragraphs are manually annotated, which requires a lot of manual labor.

[0033] The gradient descent optimization algorithm used during training performs poorly when dealing with high-dimensional, sparse, or imbalanced data, and has a slow convergence speed.

[0034] The fine-tuning process involves froze parameters by integrating the prompts into the historical dialogues of the untrained large language model. Essentially, it is context learning and prompt engineering, without injecting new knowledge into the large model.

[0035] In practical applications, paragraphs are segmented based on the characters representing the semantic termination of punctuation marks. This step requires defining relevant standards for the writing style and format of the application document; otherwise, inaccurate paragraph extraction issues such as premature or delayed segmentation may occur, failing to completely break the strict limitations of the data template format.

[0036] To address the shortcomings of related technologies, this disclosure utilizes a target large language model finely tuned with knowledge from the software function size measurement domain to automatically complete requirement document parsing, function point count extraction, and transaction type identification. This eliminates the reliance on professional experience in traditional manual measurement, effectively avoids biases from subjective human judgment, improves the accuracy of function point statistics and transaction type determination, and shortens the conversion cycle from requirement documents to measurement results, reducing labor costs and improving the accuracy and efficiency of software function size measurement.

[0037] The present disclosure will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0038] The software functional scale measurement method provided in this disclosure can be applied to scenarios involving scale, cost and value assessment in the software life cycle, such as early-stage project cost estimation and bidding. The execution subject of the method can be a server, cloud computing platform or edge computing device.

[0039] like Figure 1 As shown, Figure 1 This is a flowchart illustrating a software function size measurement method provided in an embodiment of this disclosure. The software function size measurement method provided in this embodiment includes the following steps: Step 101: Obtain the software project requirements document; In one embodiment, a requirements document refers to a text file generated during the software project development phase that describes the business functions, operation processes, and data interaction rules that the software should implement. This includes, but is not limited to, requirements specifications and functional design documents. The format of the requirements document includes, but is not limited to, Microsoft Word documents, PDF files, web page text, or structured data files.

[0040] In one embodiment, the requirements document stored on a local server or terminal device can be directly imported via local file reading.

[0041] In one embodiment, the software project requirements document can also be obtained from a software project management platform or a document collaboration system via a network interface.

[0042] Step 102: Use the target large language model to parse the requirements document and obtain multiple function point count items. The target large language model is a large language model that has been fine-tuned with domain knowledge of software function scale measurement. In one embodiment, the target large language model refers to an artificial intelligence language model that, for the task of measuring software function scale, fine-tunes parameters by injecting domain knowledge and possesses the ability to parse requirement documents, extract function points, and identify transaction types. The domain knowledge for software function scale measurement refers to a set of professional knowledge, including international / domestic standards and specifications for software function scale measurement, function point classification rules, transaction type determination criteria, and scale and cost conversion logic.

[0043] In one embodiment, the knowledge of the software function size measurement domain can be the knowledge system of the NESMA software function size measurement standard.

[0044] In one embodiment, the function point count refers to the smallest functional unit with independent business significance extracted from the requirements document.

[0045] In one embodiment, based on the parsing method of prompt engineering, prompt information containing function point extraction rules and expression paradigms can be constructed. The full text of the requirement document is input into the target large language model, and the model directly outputs a list of function point count items.

[0046] In one embodiment, the parsing method of structured preprocessing of the requirements document can also be used. First, the requirements document is converted into structured data of chapter titles and body content by an open-source document parsing tool. Then, the structured data is input into the target large language model in segments, and the function point count items are extracted segment by segment.

[0047] Step 103: Use the target large language model to identify the transaction type for each function point count item, and obtain the transaction type corresponding to the function point count item; In one embodiment, transaction type refers to the category divided according to the business attributes and data interaction characteristics of the function points, which usually includes five transaction types: internal logic file, external interface file, external input, external output, and external query.

[0048] In one embodiment, based on a rule-based identification method, the definition and judgment criteria of transaction types can be embedded in the prompt information. Function point counts are then input into the target large language model one by one to obtain the transaction types corresponding to the function point counts. Here, the definition of the transaction type refers to the definitions of the aforementioned five transaction types.

[0049] In one embodiment, the recognition method can also be based on example learning, by adding a function point count item and a corresponding transaction type comparison example to the prompt information. The target large language model learns the classification logic through example learning to obtain the transaction type corresponding to the function point count item.

[0050] In one embodiment, a multi-model collaborative identification method can also be used to cross-validate the identification results of the target large language model with the judgment results of the rule engine, and to manually review inconsistent classification results to ensure the accuracy of transaction type identification.

[0051] Step 104: Based on the transaction type, generate software function scale measurement results for the software project.

[0052] In one embodiment, the software function scale measurement result refers to a quantitative report formed by integrating information such as function point count items and transaction types.

[0053] In one embodiment, based on the international standard for software function size measurement, the total number of function points is determined according to the weighting coefficients of different transaction types, and the total number of function points is converted into workload and cost quotations, thereby generating the software function size measurement results of the software project.

[0054] In one embodiment, a machine learning model can also be built using measurement data from historical projects of similar scale and industry. The total number of function points can be input into the model to obtain personalized workload and cost quotes, thereby generating software function scale measurement results for the software project.

[0055] By employing a large language model finely tuned with domain knowledge to automate and intelligently parse and classify software requirement documents, subjective biases caused by human intervention can be reduced.

[0056] In one embodiment, before obtaining the requirements document for a software project, the software feature size measurement method includes: Acquire multi-scenario data related to software functionality and scale metrics; In one embodiment, the multi-scenario data associated with software function scale measurement refers to various professional data sets related to the software function scale measurement task and covering different application scenarios. These data sets are used to provide diverse domain knowledge inputs for the general-purpose large language model, ensuring the comprehensiveness of model learning. The general-purpose large language model refers to an artificial intelligence model that has basic natural language understanding and generation capabilities but has not yet been optimized for any specific vertical domain task.

[0057] In one embodiment, the multi-scenario data associated with software function scale measurement includes various sources such as international / national standards manuals published by authoritative organizations, official technical articles, professional training materials, and requirement specifications, function point evaluation reports, and final cost measurement results of historical software projects.

[0058] In one embodiment, a web crawler or an application programming interface (API) can be written to automatically crawl or manually download relevant standard documents, technical reports, white papers, and research papers from international / national standards organization websites, well-known industry alliance resource libraries, and academic paper databases, thereby obtaining multi-scenario data related to software functional scale metrics.

[0059] In one embodiment, the system can also connect to the enterprise's internal document management system, project management system, and configuration management database. After obtaining authorization and performing privacy desensitization, it can export the software requirements specification, function point count table, workload assessment report, and final project completion data of historical projects, thereby obtaining multi-scenario data associated with software function scale measurement.

[0060] In one embodiment, interviews with software function scale measurement experts can be conducted to record the judgment logic, common problems and solutions of typical measurement scenarios, forming structured expert knowledge data, thereby obtaining multi-scenario data related to software function scale measurement.

[0061] Based on the target question-answer pair template, a general large language model is used to generate question-answer pairs from multi-scenario data in order to construct a scenario-specific question-answer pair dataset.

[0062] In one embodiment, the target question-answer pair template refers to a predefined question-answer structure framework that includes a fixed format and content orientation, used to constrain the generation logic of the general large language model and ensure that the output question-answer pairs meet the task requirements of the software functional scale measurement.

[0063] In one embodiment, a question-answer pair dataset refers to a collection of data consisting of question-answer pairs, where the questions are designed around the task of measuring software functional scale, and the answers correspond to professional solutions. A scenario-based question-answer pair dataset refers to a dataset formed by classifying and organizing question-answer pairs according to different task scenarios of software functional scale measurement (such as standard interpretation, function point extraction, and transaction type identification), which enables the model to achieve scenario-based accurate learning.

[0064] In one embodiment, the target question-answer pair template, such as the question: How to identify the function point corresponding to [function description]? The answer: [professional answer], is input together with a single multi-scenario data (such as a function description text) into a general large language model to directly generate a single question-answer pair. After batch processing, the data is classified by scenario, and then scenario-specific question-answer pair datasets are constructed based on the question-answer pair data.

[0065] In one embodiment, the general large language model first extracts the core task points from multi-scenario data, then combines the target question-answer pair template to send an instruction to the model to generate corresponding question-answer pairs, generating multiple question-answer pairs, and finally constructs a scenario-specific question-answer pair dataset based on the question-answer pair data.

[0066] Furthermore, based on the target question-answer pair template, a general-purpose large language model is used to generate question-answer pairs from multi-scenario data. Domain experts pre-design a structured prompt word template, which defines the task instructions for generating question-answer pairs, the scenario labels of the input data (such as official documents, training materials, requirement documents, submission feature point scale tables, and evaluation results), and the expected JavaScript Object Notation (JSON) output format. Subsequently, cleaned and scenario-annotated multi-scenario data fragments, along with the template and a small number of manually created high-quality question-answer pair examples, are input into a pre-trained general-purpose large language model. Guided by the template and examples, this general-purpose large model, through its few-shot learning capabilities, performs semantic understanding and content reconstruction on the input data materials, automatically generating standardized and content-related question-answer pairs in batches, thereby constructing a large-scale, scenario-specific domain question-answer pair dataset.

[0067] By utilizing a general-purpose large language model to automatically generate question-answer pairs, the burden of manually annotating massive amounts of specialized data is reduced, and the efficiency of dataset construction is improved. Simultaneously, the integration of raw data from multiple sources and scenarios ensures the breadth and depth of knowledge coverage in the generated dataset.

[0068] In one embodiment, after generating question-answer pairs from multi-scenario data using a general large language model based on the target question-answer pair template to construct a scenario-specific question-answer pair dataset, the software functional scale measurement method further includes: The question-answer pair dataset is used as training data for a general large language model, which is then fine-tuned to obtain the target large language model.

[0069] In one embodiment, fine-tuning refers to a training process that updates the model's parameters within a small range using a task-related dataset, such as the software function size measurement task in this application, for a specific task. The core purpose is to inject domain expertise while preserving the model's basic capabilities.

[0070] In one embodiment, low-rank matrices, such as matrix A with dimensions m×r and matrix B with dimensions r×n, are embedded in the Transformer layer of the general large language model. Only the parameters of these two low-rank matrices are trained, while the original parameters are kept frozen. After training, the low-rank matrices are fused with the original parameters to obtain the target large language model.

[0071] In one embodiment, an adapter module is inserted between the Transformer layers of a general large language model, and only the parameters of the adapter module are trained to achieve lightweight domain adaptation.

[0072] By employing lightweight fine-tuning methods such as low-rank adaptation and adapters, the amount of parameter updates is reduced compared to full parameter fine-tuning, thereby reducing the computing resources and time costs required for training. Training can be completed on ordinary servers.

[0073] After obtaining the question-answering pair dataset, efficient parameter fine-tuning is required to transform the general-purpose large language model into a target large language model specifically for software feature size measurement. During fine-tuning, the weight matrices of all original layers of the selected general-purpose large language model are kept unchanged; gradients are not calculated or updated for these parameters, thus preserving the massive general knowledge and language understanding capabilities acquired during pre-training. A low-rank adaptation technique is employed, injecting a set of trainable low-rank decomposition matrices into certain fully connected layers of the original model, such as the query, key, and value projection matrices in the self-attention module or the bypass of the feedforward network layer. During training, questions from the aforementioned question-answering pair dataset are used as model input, and answers as training targets. The forward and backward propagation algorithms are used to update only the parameters of these newly injected low-rank matrices, while the original model parameters remain frozen. In this way, the model can learn and absorb professional knowledge and task patterns in the software feature size measurement domain with a minimal number of parameters, ultimately resulting in a target large language model that possesses both powerful general-purpose capabilities and expertise in domain-specific tasks.

[0074] By using question-answer pair datasets as training data for a general-purpose large language model and fine-tuning the model, the general-purpose large language model can be efficiently and quickly adapted to specific professional fields with extremely low computational resources and storage overhead.

[0075] In one embodiment, the requirements document is parsed using a target large language model to obtain multiple function point count items, including: The chapter titles and body content of the requirements document are parsed to obtain the first document data; In one embodiment, the first document data refers to the data formed after preliminary structured parsing of the requirement document, reflecting the relationship between chapter titles and corresponding text.

[0076] In one embodiment, source tools such as Python's python-docx or PyPDF2 library can be used to read the required documents in Word or PDF formats, and the titles and body text can be separated by recognizing the built-in title styles of the document to generate the first document data in JSON format.

[0077] In one embodiment, for documents without built-in styles, such as TXT documents, a mapping relationship between titles and body text can be established based on manually preset tags, such as identifying titles and splitting content, to obtain the first document data.

[0078] In one embodiment, for image-type documents such as scanned PDFs, the images can first be converted into editable text using Optical Character Recognition (OCR) technology, and then the chapter titles and main text content can be extracted to obtain the first document data.

[0079] Construct the first prompt information, and use the first prompt information to guide the target large language model to analyze the structure of the first document data to obtain the second document data; In one embodiment, the second document data refers to the structured document data after analysis and optimization by the target large language model. The second document data has corrected problems such as chaotic title hierarchy and incorrect body text attribution in the first document data, and has a clearer content association logic.

[0080] In one embodiment, the first prompt information includes rules such as analyzing the rationality of the title hierarchy, correcting mismatches between the body text and the title, and outputting standardized JSON format. The first document data is completely input into the target large language model to obtain the second document data.

[0081] In one embodiment, a comparison example of the erroneous structure and the corrected structure can be added to the first prompt message. The model learns the example logic to complete the structural optimization of the first document data, and then obtains the second document data.

[0082] Construct a second prompt message and use the second prompt message to guide the target large language model to extract the functional description text from the second document data; In one embodiment, the functional description text refers to the core text extracted from the requirements document that describes the business functions, operating procedures, and constraints that the software should implement.

[0083] In one embodiment, the features of the function description text are clearly defined in the second prompt information, such as including action words such as adding, modifying, and querying, and involving business operation processes. The target large language model extracts the function description text from the main text based on the second prompt information.

[0084] In one embodiment, the second prompt information guides the target large language model to first determine whether the chapter title belongs to the function-related category, and then extract the main text content of the corresponding chapter in a targeted manner, thereby improving the extraction efficiency of the function description text.

[0085] In one embodiment, the second prompt information may list non-functional text types, such as development background, risk description, etc. The target large language model first removes such content and then extracts the functional description text.

[0086] Construct a third prompt message and use it to guide the target large language model to generate function point count items that conform to the expression rules based on the function description text.

[0087] In one embodiment, the first prompt, the second prompt, and the third prompt are all instruction texts designed to guide the target large language model to complete a specific task. They contain key information such as task objectives, execution rules, and output formats. The specific content of the first prompt, the second prompt, and the third prompt is different.

[0088] In one embodiment, the third prompt message refers to the instruction text constructed to guide the target large language model to generate function point count items, which clearly specifies the expression rules that the output must follow, and summarizes and transforms the free function description into a standardized phrase that conforms to the function point method standard.

[0089] In one embodiment, the representation rule refers to the standardized specification of the language expression of function point count items in the field of software function scale measurement.

[0090] In one embodiment, the third prompt message explicitly states the rules, such as using noun phrases for logical files, using verb-object structures for basic processes, and the target large language model splitting the functional description text into count items according to the rules.

[0091] In one embodiment, the output format of the count items can be specified in the third prompt information, such as function point count items: [count item 1]; [count item 2], and the target large language model generates function point count items according to the output format requirements.

[0092] In one embodiment, an example of a function description text and a corresponding function point count item can also be added to the third prompt information. The target large language model can refer to the example to complete the conversion from the function description text to the function point count item.

[0093] The process of parsing the requirements document using a target large language model to obtain the functional point counts is refined through multi-round prompting interactions. Specifically, the chapter titles and body content of the requirements document are parsed to obtain the first document data. This can be automatically completed by calling a document parsing library such as python-docx, extracting the preliminary structured representation of the title hierarchy and corresponding paragraph text. Then, a first prompt message is constructed and its guiding model is used: This first prompt message is designed based on the thinking chain technology. Its content indication model first analyzes the layout style, title logical structure, and possible industry field of the input document. Then, based on this analysis, it reasones and corrects possible title misjudgments or hierarchical misalignments in the preliminary parsing, outputting a more structurally accurate second document data. Next, a second prompt message is constructed and its guiding model is used: This second prompt message is designed based on context learning technology, embedding multiple examples of manual judgment regarding functional description chapters and non-functional description chapters. The indication model, based on the logic of the examples, binary classifies the content of each chapter in the second document data, only filtering and extracting the text paragraphs identified as functional descriptions, forming a pure set of functional description text. Finally, a third prompt message is constructed and used to guide the model: this third prompt message explicitly defines the expression rules for function point count items, instructing the model to decompose or summarize the function description text obtained in the previous step into one or more independent function point count items, and ensuring that each count item conforms to the rules before outputting.

[0094] By sequentially applying prompting engineering techniques such as thought chains and contextual learning, the model is guided to perform step-by-step reasoning and precise filtering, thus solving the dependence of traditional methods on document templates and improving robustness to diverse document formats.

[0095] In one embodiment, a target large language model is used to identify the transaction type for each function point count item to obtain the transaction type corresponding to the function point count item, including: Build categorized prompts that include transaction type definitions; The target large language model is guided by classification prompts to identify the transaction type for each function point count item, and the transaction type corresponding to the function point count item is obtained. The transaction type includes internal logic file, external interface file, external input, external output and external query.

[0096] In one embodiment, the classification prompt information refers to instruction text specifically designed for transaction type identification tasks. Its core includes the standard definition of the transaction type, the judgment criteria, and the output format requirements. This is used to precisely constrain the recognition logic of the target large language model, ensuring that the classification results conform to the software functional scale measurement specifications. The transaction type definition refers to the standardized description of the essential attributes, business characteristics, and data interaction patterns of various transaction types. It is the core basis for the target large language model to determine the attribution of functional point count items.

[0097] In one embodiment, the classification prompt information can first list the complete definitions of five transaction types, and then supplement the judgment rule of "first determine whether the function point is a data set or a business operation, and then match the specific type".

[0098] In one embodiment, after defining the transaction type, a function point count item can be added—a typical example of the corresponding type, such as a customer information table—an internal logic file, or a query order status—an external query. This example enhances the target large language model's understanding of the definition.

[0099] In one embodiment, an internal logic file refers to a structured data set within the software system used to store and maintain business data. It is operated only by the system's own functional modules and serves as the core data carrier for software functionality. An external interface file refers to a structured data set that the software system relies on when interacting with other independent external systems. It is maintained by the external system, and the system only reads or writes data through the interface. External input refers to the type of function where external users or systems send data or instructions to the software to trigger the execution of the software's internal business logic. Its core function is to receive external information and drive the system response. External output refers to the type of function where the software provides data or feedback information to external users or systems based on the results of internal business logic processing. Its core function is to output the effective information processed by the system. External query refers to the type of function where external users or systems initiate data query requests to the software, and the software only retrieves and returns existing data without changing the internal data state of the system.

[0100] In one embodiment, the classification prompts and all function point counts can be integrated into a single input to guide the target large language model to complete batch recognition and output a list of transaction types, which is suitable for scenarios with a large number of function points.

[0101] In one embodiment, classification prompts can be entered first, and then the function point count items can be entered into the model one by one. After each item is identified, the result is manually confirmed, and any questionable results are corrected by supplementary prompts. This method is suitable for scenarios with high precision requirements.

[0102] Specifically, constructing classification hints that include transaction type definitions involves creating a structured natural language instruction that explicitly defines several core transaction types involved in software functional scale measurement: internal logic files, external interface files, external inputs, external outputs, and external queries. This hint formalizes the classification task as a generation task; the instruction model directly outputs the type abbreviation (such as ILF, EI, etc.) corresponding to the given function point count item. Guiding the target large language model using the classification hints involves inputting the function point count item to be classified, its corresponding functional module context information, and the constructed classification hints into the target large language model. Based on the judgment criteria and feature knowledge about various transaction types learned during the fine-tuning phase, the model analyzes the functional semantics of the input count items and directly generates corresponding transaction type labels, thereby completing automated classification.

[0103] In one embodiment, based on the transaction type, a software feature size metric for the software project is generated, including: The total number of function points is determined based on the transaction type of each function point count item, according to the software function size measurement standard rules. In one embodiment, the software function size measurement standard rule refers to the internationally or domestically accepted software function size quantification specification, which includes the function point calculation method for various transaction types, complexity classification standards, etc., and is the authoritative basis for function point quantity statistics.

[0104] In one embodiment, the total number of function points refers to the core quantitative indicator of software function scale obtained by summarizing the number of function points corresponding to each transaction type.

[0105] In one embodiment, the total number of function points can be obtained by counting the number of internal logic files / external interface files by data element type and external inputs / outputs / queries by processing logic complexity, according to the ISO / IEC 24570 standard.

[0106] In one embodiment, the function point count items can be first classified into simple, medium, and complex categories, such as the number of data elements determining the complexity of the logic file, and then the total number of function points can be obtained by combining the function point coefficients of the corresponding levels in the standard.

[0107] Based on the target adjustment factor and target pricing model, determine the workload and cost quotation corresponding to the total number of function points; In one embodiment, the target adjustment factor refers to the correction parameter set in combination with the actual scenario of the software project, which is used to balance the standard calculation results with the specificity of the project, including dimensions such as project complexity, technical difficulty, and team proficiency.

[0108] In one embodiment, the target pricing model refers to a quantitative calculation model that converts the number of function points into workload and cost, and its core includes key parameters such as function point unit price and man-day efficiency.

[0109] In one embodiment, a target pricing model can be constructed based on the company's historical project data, and the cost quote is the product of the total number of function points, the unit price of the company's function points, and the technical difficulty adjustment factor.

[0110] In one embodiment, the target pricing model can be selected based on the company's business requirements.

[0111] For example, different companies select appropriate target pricing models based on their business requirements to calculate the final number of function points according to the NESMA function point transaction type. Furthermore, different adjustment factors are used to convert the number of function points into corresponding workload and cost quotes to obtain the final measurement results. The calculation methods involved in this step are specified by the NESMA standard, and relevant parameters are scientifically adjusted and iterated according to the business needs of different units.

[0112] Based on the transaction type, total number of function points, workload, and cost quote, generate software function scale measurement results for the software project.

[0113] In one embodiment, the software function scale measurement result refers to a structured report formed by integrating function point statistics, workload and cost information.

[0114] In one embodiment, a Word or Excel report can be generated based on a fixed structure of transaction type statistics details table - total function point summary - workload calculation process - cost quotation details.

[0115] In one embodiment, data visualization tools, such as Power BI, can also be used to transform data into pie charts of transaction type percentages and line charts of the relationship between feature points and costs, generating a visual report on the scale of software features that includes charts and text descriptions.

[0116] The process of generating the final software feature size metric based on the identified transaction types follows standard metric rules for calculation and summarization. Specifically, according to the software feature size metric standard rules, the total number of feature points is determined based on the transaction type of each feature point count item. First, based on the identified transaction type (ILF, EIF, EI, EO, EQ) for each feature point count item, the unadjusted feature point weight for that count item is determined by referring to the complexity judgment matrix defined in the standard (this matrix typically depends on the number of data element types or reference file types). Then, the weights of all count items are summed to obtain the total number of unadjusted feature points. Next, the total number of unadjusted feature points is calibrated by applying the high-impact technical complexity adjustment factor or business complexity adjustment factor defined in the standard, combined with specific project characteristics (such as system complexity, performance requirements, etc.), to obtain the final adjusted total number of feature points. Subsequently, the adjusted total number of feature points is input into a pricing model calibrated based on historical data, such as using a linear regression model to establish the conversion relationship between feature points and man-month workload, or an industry benchmark unit price, while considering project-specific adjustment factors (such as team experience, development environment, etc.), to calculate the estimated workload and corresponding cost quote. Finally, the software function scale measurement result of the software project is generated by formatting all the key data obtained in the previous steps, including the count of each function point and its transaction type, the total number of function points, the estimated workload and cost quotation, according to the preset report template (such as Excel spreadsheet or structured JSON), to form a complete measurement report document.

[0117] In one embodiment, such as Figure 2 As shown, Figure 2 This is a flowchart illustrating a software function scale measurement method provided in an embodiment of the present disclosure, including intelligently generating scenario-specific question-answer pair datasets, fine-tuning a general large language model using LoRA, adaptively extracting NESMA function point count items, identifying NESMA function point transaction types, and obtaining cost measurement results.

[0118] Specifically, such as Figure 3 As shown, Figure 3 This is a flowchart illustrating a method for generating a question-and-answer pair dataset according to an embodiment of the present disclosure. The intelligent generation of scenario-specific question-and-answer pair datasets can be divided into the following steps: collection of professional data and manual quality control, data cleaning and preprocessing, and generation of question-and-answer pairs empowered by a general large model.

[0119] To improve the performance of the large-scale model in specific scenarios of NESMA software cost measurement, the amount of data collected does not need to be excessive, but the coverage of professional knowledge should be as comprehensive as possible, including different types of relevant scenarios. This proposal needs to consider the following different scenarios during implementation: professional knowledge of the NESMA international standard for software cost measurement, chapter titles and content related to function descriptions in requirements documents, NESMA function point counts corresponding to the function description text, and the actions and function point transaction types corresponding to the function point counts. To ensure the large-scale model understands the general knowledge and measurement logic of the NESMA international standard as much as possible, authoritative content of the NESMA software cost measurement specification needs to be collected as part of the data, including but not limited to relevant standard manuals and translations, articles on official websites, related papers and patents, and training materials from domestic and international professional institutions and associations. To better adapt the large-scale model to the specific application problems to be solved by this proposal and achieve intelligent measurement, it is necessary to collect historical submission materials and evaluation results of software cost measurement business, including but not limited to software project requirements documents from different industries, corresponding function point count statistics tables, and project size measurement results. Due to the diverse sources of the collected data, a secondary quality control process is required by NESMA software cost measurement experts. This process filters out high-quality and authoritative materials, removing content that could potentially lead to misunderstandings in the model. Security and privacy controls are also in place, including anonymizing necessary software project data. After data collection, the data undergoes parsing, cleaning, and preprocessing. This includes filtering out duplicate and noisy data, correcting formatting errors, extracting standard question-and-answer pairs, and annotating data from different sources such as official documents, training materials, requirement documents, feature point scale tables for review, and evaluation results.

[0120] In the process of extracting question-answer pairs, data augmentation is achieved using a general-purpose large-scale model to alleviate the problems of insufficient data quantity and quality, while minimizing manual labor. First, it is necessary to select a pre-trained generative large-scale language model with appropriate parameters that can well support the Chinese context, based on the complexity of business needs, development environment, and hardware / software conditions. Generative large-scale language models are a type of model based on deep learning technology, typically based on the Transformer architecture, which learns the statistical patterns and semantic information of language through pre-training on large-scale text corpora. The method provided in this proposal has a certain degree of scalability in model selection, does not restrict the choice of large-scale models, and can be flexibly selected according to needs.

[0121] The process involves manually constructing different paradigms for various scenarios using prompt engineering, and extracting authoritative, high-quality, and representative question-and-answer pairs from the processed data. Then, a general-purpose large model is used to perform few-shot learning on these examples, generating question-and-answer pairs based on the provided data to further augment the data. This approach leverages a general-purpose large model, eliminating the need for manual extraction of question-and-answer pairs from each collected scenario; instead, manual review of the generated question-and-answer pairs is sufficient. This reduces manual intervention, improves efficiency, and ensures the quality of the question-and-answer pairs. The following describes the process of using a large model to empower question-and-answer pair extraction in this proposal, along with an example.

[0122] (1) Define standard paradigms manually based on different scenarios and applications: The following materials are from the [Scene Tag] scene. Based on the provided examples, generate at least one question-and-answer pair in JSON format. Materials: [Materials], Examples: [Example 1][Example 2][Example 3].

[0123] (2) Examples of manual extraction of some professional samples: Material: Application \nComposed of one or more components, modules, or subsystems, supporting the automation of processes and the cohesive aggregation of data for business objectives. \nExamples: Accounts Payable, Accounts Receivable, Payroll, Purchasing, Shop Floor Production, Assembly Line Control, Air Search Radar, Target Tracking, Weapon Launch, Flight Scheduling, and Passenger Reservation. Question and Answer Pairs: {"qa_pairs":[{"question":"What is the definition of an application in the NESMA international standard?","answer":"Composed of one or more components, modules, or subsystems, supporting the automation of processes and the cohesive aggregation of data for business objectives."},{"question":"Does air search radar fall under the category of applications in NESMA?","answer":"Air search radar consists of multiple subsystems that support automated search for airborne targets and the cohesive aggregation of radar signal data, and is therefore a NESMA application."}]}.

[0124] (3) Build a prompt generator to generate prompts based on data materials and case studies, following the established paradigm: The following material is derived from the [NESMA Software Cost Measurement Standard Official Documentation] scenario. Based on the provided examples, generate at least one question-and-answer pair in JSON format. Material: [Application Boundary\nThe conceptual interface between an application and its users and / or other applications.\nNote: The application boundary is defined once the scope of the analysis is determined.] Example: [Material: Application\nComposed of one or more components, modules, or subsystems that support the automation of processes and the cohesive aggregation of data for business objectives.\nExamples: Accounts Payable, Accounts Receivable, Payroll, Purchasing, Shop Floor Production, Assembly Line Control, Air Search Radar, Target Tracking, Weapon Launch, Flight Scheduling, and Passenger Booking.] Question and Answer Pairs: {"qa_pairs":[{"question":"What is the definition of an application in the NESMA international standard?","answer":"Composed of one or more components, modules, or subsystems that support the automation of business objectives and the cohesive aggregation of data."},{"question":"Does air search radar fall under the category of applications in NESMA?","answer":"Air search radar consists of multiple subsystems that support automated search for airborne targets and the cohesive aggregation of radar signal data, and therefore falls under the category of NESMA applications."}]}].

[0125] (4) Automatically generate question-answer pairs in JSON format based on large models: {"qa_pairs":[{"question":"What is the definition of the application boundary in the NESMA software cost metric?","answer":"The application boundary is the conceptual interface between an application and its users and / or other applications. The application boundary is defined once the scope of the analysis is determined."},{"question":"Why is it necessary to define the application boundary in the NESMA standard?","answer":"In the NESMA standard, defining the application boundary is to clarify the scope of the analysis and ensure that all relevant interfaces and interactions are considered during the software cost metric process, thereby improving the accuracy and consistency of the metric."}]}.

[0126] like Figure 4 As shown, Figure 4This is a flowchart illustrating a method for fine-tuning a general-purpose large language model provided in this disclosure, including: selecting an appropriate large language model. The generative large model used is typically built based on the decoder part of the Transformer architecture. It converts the input data (questions in a question-answer pair) into token indices before inputting them into the model. This process involves core structures such as Position Encoding (PE), Masked Self-Attention, Feed-Forward Network (FFN), Residual Connection, and Layer Normalization.

[0127] Positional encoding incorporates positional information into the input embedding data (obtained from token indices through an embedding layer), enabling the model to recognize the order of words within the sequence. Sine functions of different frequencies are used as positional codes, and the mathematical expression for positional encoding is as follows:

[0128]

[0129] in, For location index, It is a dimensional index. It is the dimension of the input embedding.

[0130] The attention mechanism is a core part of the Transformer architecture. It calculates the attention weights between tokens in the input sequence and uses these weights to perform a weighted sum of values ​​to obtain the attention result, thereby achieving contextual understanding. The mathematical expression of the attention mechanism is as follows:

[0131]

[0132] Where Q, K, and V correspond to the query, key, and value of the input sequence, respectively, dk is the dimension of the key, and the Softmax function is the normalized exponential function.

[0133] The attention mechanism in the decoder upon which large models are based typically employs a masked multi-head self-attention layer. Self-attention means that each element in the sequence performs attention calculations on all other elements in its sequence, and its query, key, and value are all derived from the same feature vector. It is obtained by linear transformation of different trainable weight matrices, that is: The mask is used to obscure future tokens to ensure that each position only sees previously generated tokens. The mask is implemented by setting the corresponding attention weights to negative infinity, so that after... Afterwards, the attention result at the corresponding position will become 0, achieving the masking effect. Multi-head processing involves processing the input sequence through multiple different heads for attention calculation. Each head can learn different attention patterns. The calculation process can be divided into two steps: separate head calculation and concatenation with linear transformation. Separate head calculation will... , , Mapped to respectively Each subspace performs independent attention calculations, where Let be the number of heads. Then, the outputs of all heads are concatenated and subjected to a linear transformation to obtain the final output, as shown in the following mathematical expression:

[0134]

[0135] in, Corresponding to the multiple attention points after splicing, These correspond to the first attention head and the h-th attention head, respectively.

[0136] Position-aware feedforward neural networks typically consist of two fully connected layers following the attention layer. The word vector at each position is transformed independently through the same feedforward network, as shown in the following mathematical expression.

[0137]

[0138] ReLU is a commonly used activation function that introduces non-linearity to help learn complex patterns. W1 and W2 are weight matrices, and b1 and b2 are biases.

[0139] Residual connections sum the input and output of each layer, preserving the original input information while making the model easier to train and mitigating the vanishing gradient problem in deep networks. Layer normalization normalizes the output of each layer to stabilize and accelerate the training process; the mathematical expression is as follows:

[0140] Where γ and β are trainable scaling and translation parameters. It is a small value to prevent the denominator from being zero.

[0141] Using the aforementioned question-and-answer pair data, the pre-trained large model was fine-tuned using LoRA. The core idea of ​​LoRA is to decompose the weight matrix into the product of two low-rank matrices through low-rank decomposition. This process freezes the weights of the pre-trained model and injects the trainable low-rank decomposition matrix into each layer of the Transformer architecture, greatly reducing the number of trainable parameters of the large model on downstream tasks, reducing hardware and software requirements, and injecting professional knowledge while retaining the massive knowledge of the general large model.

[0142] During LoRA fine-tuning, the original pre-trained weight matrix of the large model is represented as follows: The parameters of the fine-tuned incremental matrix are expressed as follows: First, Decomposed into two low-rank (rank is ) matrix and In subsequent fine-tuning, only update and The parameters, thus maintaining constant.

[0143]

[0144] In practice, a coefficient can be multiplied to determine the proportion of the LoRA low-rank adaptive weight matrix obtained from fine-tuning on downstream tasks in the final model parameters. It is an adjustable hyperparameter. For rank.

[0145]

[0146] The fine-tuning process consists of two steps: forward propagation and backward propagation. During forward propagation, the input vector passes through the original weight matrix and the increment matrix to obtain the output vector.

[0147]

[0148] During backpropagation, the loss function is applied to the low-rank matrix. and The parameters are updated using gradients, and the gradient calculation is as follows, where the loss function is... .

[0149]

[0150]

[0151] Furthermore, in the fine-tuning process, the loss function and weight update optimizer need to be selected according to the specific fine-tuning task. This proposal chooses the cross-entropy loss function and the AdamW optimizer. By setting appropriate hyperparameters such as the learning rate and the number of training iterations, the weights of the low-rank decomposition matrix are iteratively updated.

[0152] The cross-entropy loss function is used to calculate the difference between the probability distribution of the generated text (output) and the probability distribution of the real text (answers in the question-answer pair). The calculation process is as follows. The number of labels in the target sequence. It is the token index of the real value. The model is given input The token is generated at that time. The probability of.

[0153]

[0154] AdamW is a common optimization algorithm, a variant of the adaptive learning rate optimization algorithm Adam. It improves model training performance and generalization ability by more effectively handling weight decay. Its steps for updating model weight parameters are as follows: First, it calculates the first moment estimate (momentum) and second moment estimate (mean squared gradient). For first-order moment estimation, For second-order moment estimation, For gradient, It is the first-order moment attenuation coefficient (close to 1). This is the second-order moment decay coefficient (close to 1). Then, deviation corrections are applied to the first and second moments, and finally, weight decay is introduced for the current weight parameters. Update, among which For learning rate, It is a small value (to prevent numerical stability constants with a denominator of 0). This is the weight decay coefficient.

[0155]

[0156]

[0157]

[0158]

[0159]

[0160] After the above steps, the fine-tuning training of the large model can be completed, resulting in a fine-tuned large model with expertise in NESMA software cost metrics.

[0161] like Figure 5 As shown, Figure 5 This is a flowchart illustrating a method for extracting function point counts according to an embodiment of this disclosure. Utilizing a fine-tuned large model, based on prompt engineering, context learning (ICL), and thought chain theory (CoT), it achieves adaptive extraction of NESMA function point counts. "Adaptive" means that the industry domain, template format, and writing style of the input software project requirements document are not restricted in any way, and the designed downstream application can adaptively complete the extraction of function point counts. This step can be divided into three sub-steps: requirements document parsing, function description extraction, and function module generation and corresponding function point count extraction.

[0162] The requirements document parsing module comprises two parts: text parsing and secondary correction. Text parsing utilizes open-source components to parse the headings and body text of Word documents into structured data. While this step can initially identify the headings, some omissions and inaccuracies may occur because the heading formatting in some requirements documents does not strictly adhere to Word's embedded heading levels. Since this proposal included chapter headings and content related to functional descriptions from software project requirements documents across various industries during the dataset preparation phase, this issue can be further addressed using the finely tuned large model.

[0163] The parsed structured requirements document is input into a large model. Based on CoT (Coding Theory), appropriate prompts are designed to allow the large model to first understand and analyze the template format and writing style of the input requirements document. Then, based on the results of the understanding and analysis, the title and body structure are further revised to obtain accurate structured requirements document data. CoT technology allows the model to explicitly generate a series of intermediate reasoning steps before generating the final answer, thereby enabling the model to perform better in complex reasoning tasks.

[0164] During the functional description extraction phase, appropriate prompts are designed. Based on CoT and contextual learning techniques, the large model first understands and analyzes the industry domain to which the software project belongs, and then further categorizes the titles of each chapter as functional description chapters. If the categorization result is yes, then the functional description of the main text content of that chapter is extracted; otherwise, it is skipped.

[0165] Contextual learning is a typical emergent capability unique to large-scale models. Specifically, it involves providing the large model with natural language instructions and multiple task examples in prompts, generating the expected output without explicit training or gradient updates. Several manually provided task examples are listed below. Since fine-tuning the large model already involves some NESMA expertise, the implementation only requires specifying the output format in the prompts and directly adding the question-answer pairs from the task examples to the user's interaction history list with the large model, or directly to the prompts. The large model can then complete the relevant classification and extraction tasks through contextual learning.

[0166] For example, User: Is [1.1 Software Development Background] a section describing a function? Model answer: [No].

[0167] User: Please extract a functional description for the following update: [In this system update, new employee information is added to employee management. Prerequisites are set: only employees of this company can edit the information. Click "Create Employee Information," and fields marked with an asterisk are required. After completion, click "Submit" to return to the main page. Select the employee information you wish to view to modify, query, or delete it. Please provide a flowchart or functional interface diagram.]

[0168] Model answer: To add employee information in employee management, set the prerequisite: only employees under this company can edit. Click "Create Employee Information". Items marked with an asterisk are required. After filling in the information, click "Submit" to return to the main page. Select the employee information you want to view to modify, query, or delete it.

[0169] Finally, the model's output needs to be parsed and post-processed to remove noise, extract the final descriptive text, and merge it into a functional description list according to the chapter order.

[0170] By extracting functional descriptions, this approach enables adaptive and accurate extraction of functional descriptions from requirements documents, eliminating irrelevant text. Leveraging the deep understanding of long texts by a large model, this method overcomes the strict limitations of existing requirements document template formats and offers excellent scalability.

[0171] After extracting the functional descriptions from all chapters of the requirements document, we further designed the downstream application for extracting NESMA function point counts. We then categorized each description in the obtained functional description list into one or more functional modules and further extracted function point counts for each functional module.

[0172] Function point counts should be in sentences, conforming to a standard sentence structure. For example, it should be a noun representing "NESMA logic file" or a verb-object structure representing "NESMA basic process". The sentence structure is defined in the system commands through prompts, and the function description is used as the user command input. The large model utilizes NESMA standard-related expertise injected during fine-tuning, along with knowledge of NESMA function point counts corresponding to the function description text, to extract the function point counts. Here is an example: User: Function Description: [Add employee information in employee management. Prerequisites: Employees must be under this company to edit. Click "Create Employee Information." Fields marked with an asterisk are required. After completion, click "Submit" to return to the main page. Select the employee information to view for modification, query, or deletion.] Large Model: Function Module: Employee Information Management. NESMA Function Point Counts: Company Employee List, Add Employee Information, Delete Employee Information, Modify Employee Information, Query Employee Information.

[0173] Similarly, the model output is further parsed and post-processed to remove noise and obtain JSON-formatted structured data of the functional module-functional point count item list.

[0174] like Figure 6 As shown, Figure 6 This is a flowchart illustrating a method for classifying function point transaction types according to an embodiment of this disclosure. The extracted function point count items are identified according to their corresponding NESMA function point transaction types. There are five transaction types: Internal Logic File (ILF), External Interface File (EIF), External Query File (EQ), External Input File (EI), and External Output File (EO). Because the large model is fine-tuned by injecting knowledge related to the actions and function point transaction types corresponding to the function point count items—that is, the classification task is specifically prompted and fine-tuned, transforming the classification task into a generation task—the model can be directly guided to generate classification results by designing appropriate prompts. Finally, the classification results are parsed and added to structured data. The following is a classification example: User: Please classify the following function point count items into transaction types, including ILF, EIF, EQ, EI, and EO. Directly generate the classification results; do not generate unnecessary content. Function point count item: [Company Employee List]. Its functional module is: [Employee Information Management], and the large model is: ILF.

[0175] Obtain cost measurement results. This process requires selecting an appropriate pricing model based on business requirements to calculate the final number of function points corresponding to each functional module's NESMA function point transaction type. Further, using different adjustment factors, the number of function points is converted into corresponding workload and cost quotes to obtain the final measurement results. The calculation methods involved in this step are specified by the NESMA standard, and relevant parameters are scientifically adjusted and iterated according to the business needs of different units. A calculation module can be directly implemented based on relevant rules without introducing additional AI capabilities. Therefore, this step is only to ensure the completeness of the measurement process and is not the focus of this proposal; it will not be elaborated upon further.

[0176] Finally, the final number of feature points, workload, and cost of the project are added to the structured data. The generated structured data is then formatted into an Excel spreadsheet, which serves as the final NESMA software cost measurement report.

[0177] This application implements an end-to-end intelligent software cost measurement system that directly generates NESMA software cost measurement reports based on software development requirements documents, including: requirements document parsing, NESMA intelligent measurement based on a large model, and generation of measurement reports.

[0178] By introducing a large language model adapted to specific domain knowledge, the traditional software measurement process, which relies on human experience for interpretation and classification, is transformed into a model-driven intelligent analysis and decision-making process. Specifically, the process begins by obtaining the software project's requirements document as input. A target large language model, pre-tuned with domain knowledge for software function scale measurement, performs deep semantic understanding and structured parsing of this document. Through this fine-tuning process, the target large language model has internalized the functional point composition logic and identification rules of relevant measurement standards, enabling it to automatically extract function point counts representing software functional units from unstructured natural language descriptions. The same target large language model is then invoked, and based on its existing domain knowledge, each identified function point count is analyzed and judged, categorized into a predefined function point transaction type system, thus completing transaction type identification. Finally, based on the measurement rules corresponding to the identified transaction types, calculations and integration are performed to generate a comprehensive software function scale measurement result that includes function point size, workload, or cost estimates.

[0179] In summary, the solution provided in this public disclosure is as follows: By using a target large language model fine-tuned with domain knowledge of software function size measurement, the system automatically completes requirement document parsing, function point count extraction, and transaction type identification. This eliminates the reliance on professional experience in traditional manual measurement, effectively avoids biases in subjective human judgment, improves the accuracy of function point statistics and transaction type determination, and shortens the conversion cycle from requirement documents to measurement results, reducing labor costs and improving the accuracy and efficiency of software function size measurement.

[0180] The following application example further illustrates the software functionality size measurement method provided in this disclosure: like Figure 7 As shown, Figure 7 This is a flowchart illustrating a software function size measurement method provided as an application example of this disclosure. The software function size measurement method provided in this application example includes the following steps: Step 701: Obtain multi-scenario data associated with software function scale measurement; Step 702: Based on the target question-answer pair template, use a general large language model to generate question-answer pairs for multi-scenario data to construct a scenario-specific question-answer pair dataset; Step 703: Use the question-answer pair dataset as training data for the general large language model, fine-tune the general large language model, and obtain the target large language model; Step 704: Obtain the software project requirements document; Step 705: Parse the chapter titles and body content of the requirements document to obtain the first document data; Step 706: Construct the first prompt information and use the first prompt information to guide the target large language model to analyze the structure of the first document data to obtain the second document data; Step 707: Construct a second prompt message and use the second prompt message to guide the target large language model to extract the functional description text from the second document data; Step 708: Construct the third prompt information and use the third prompt information to guide the target large language model to generate function point count items that conform to the expression rules based on the function description text; Step 709: Construct categorized prompt information that includes transaction type definitions; Step 710: Use classification prompts to guide the target large language model to identify the transaction type for each function point count item, and obtain the transaction type corresponding to the function point count item. The transaction type includes internal logic file, external interface file, external input, external output and external query. Step 711: Determine the total number of function points based on the transaction type of each function point count item according to the software function scale measurement standard rules. Step 712: Determine the workload and cost quotation corresponding to the total number of function points based on the target adjustment factor and target pricing model; Step 713: Generate software function scale measurement results for the software project based on transaction type, total number of function points, workload, and cost quote.

[0181] To implement the software function size measurement method provided in this disclosure, this disclosure also provides a software function size measurement device, such as... Figure 8 As shown. Figure 8 This is a schematic diagram of a software function size measurement device provided in an embodiment of the present disclosure. The software function size measurement device 800 includes: Unit 801 is used to retrieve the requirements document for the software project. The parsing unit 802 is used to parse the requirements document using the target large language model to obtain multiple function point count items. The target large language model is a large language model fine-tuned by domain knowledge of software function scale measurement. The identification unit 803 is used to identify the transaction type of each function point count item using the target large language model, and obtain the transaction type corresponding to the function point count item. Generation unit 804 is used to generate software feature size measurement results for software projects based on transaction type.

[0182] In one embodiment, the software function scale measurement device 800 further includes a dataset construction unit, which is used for: Acquire multi-scenario data related to software functionality and scale metrics; Based on the target question-answer pair template, a general large language model is used to generate question-answer pairs from multi-scenario data in order to construct a scenario-specific question-answer pair dataset.

[0183] In one embodiment, the software function size measurement device 800 further includes a fine-tuning unit, which is used for: The question-answer pair dataset is used as training data for a general large language model, which is then fine-tuned to obtain the target large language model.

[0184] In one embodiment, the parsing unit 802 is specifically used for: The chapter titles and body content of the requirements document are parsed to obtain the first document data; Construct the first prompt information, and use the first prompt information to guide the target large language model to analyze the structure of the first document data to obtain the second document data; Construct a second prompt message and use the second prompt message to guide the target large language model to extract the functional description text from the second document data; Construct a third prompt message and use it to guide the target large language model to generate function point count items that conform to the expression rules based on the function description text.

[0185] In one embodiment, the identification unit 803 is specifically used for: Build categorized prompts that include transaction type definitions; The target large language model is guided by classification prompts to identify the transaction type for each function point count item, and the transaction type corresponding to the function point count item is obtained. The transaction type includes internal logic file, external interface file, external input, external output and external query.

[0186] In one embodiment, the generation unit 804 is specifically used for: The total number of function points is determined based on the transaction type of each function point count item, according to the software function size measurement standard rules. Based on the target adjustment factor and target pricing model, determine the workload and cost quotation corresponding to the total number of function points; Based on the transaction type, total number of function points, workload, and cost quote, generate software function scale measurement results for the software project.

[0187] It should be noted that the software function size measurement device provided in the above embodiments is only illustrated by the division of the above-described program modules when performing software function size measurement. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the software function size measurement device can be divided into different program modules to complete all or part of the processing described above. In addition, the software function size measurement device provided in the above embodiments and the software function size measurement method provided in this disclosure belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0188] Figure 9 This is a schematic diagram of the hardware composition structure of the electronic device provided in the embodiments of this disclosure, such as... Figure 9 As shown, the electronic device 900 includes at least one processor 902; and a memory 901 communicatively connected to the at least one processor 902; wherein the memory 901 stores instructions executable by the at least one processor 902, the instructions being executed by the at least one processor 902 to implement the steps of the software functional scale measurement method of the present disclosure embodiments.

[0189] Optionally, the electronic device may specifically be a software function size measurement device according to the embodiments of this application, and the electronic device may implement the corresponding processes implemented by the software function size measurement device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0190] It is understood that the electronic device also includes a communication interface 903. The various components in the electronic device are coupled together via a bus system 904. It is understood that the bus system 904 is used to implement communication between these components. In addition to a data bus, the bus system 904 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 9 The general labeled all buses as Bus System 904.

[0191] It is understood that memory 901 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 901 described in the embodiments of the present invention is intended to include, but is not limited to, these and any other suitable types of memory.

[0192] The methods disclosed in the above embodiments can be applied to or implemented by processor 902. Processor 902 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 902 or by instructions in software form. Processor 902 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 902 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, specifically memory 901. Processor 902 reads information from memory 901 and, in conjunction with its hardware, completes the steps of the aforementioned methods.

[0193] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), FPGAs, general-purpose processors, controllers, MCUs, microprocessors, or other electronic components to perform the aforementioned method.

[0194] This disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the steps of the software function size measurement method of the present invention.

[0195] Optionally, the computer-readable storage medium can be applied to the software function size measurement device in the embodiments of this application, and the computer instructions cause the computer to execute the corresponding processes implemented by the software function size measurement device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0196] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the software function size measurement method provided in this embodiment of the invention.

[0197] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0198] The units described above 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 network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0199] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0200] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0201] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, 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 methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0202] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for measuring software functional scale, characterized in that, include: Obtain the requirements document for the software project; The requirement document is parsed using a target large language model to obtain multiple function point counts. The target large language model is a large language model fine-tuned with domain knowledge of software function scale measurement. The target large language model is used to identify the transaction type for each of the function point count items to obtain the transaction type corresponding to the function point count item; Based on the transaction type, generate a software functionality scale measurement result for the software project.

2. The method according to claim 1, characterized in that, The method described before obtaining the software project requirements document includes: Acquire multi-scenario data related to software functionality and scale metrics; Based on the target question-answer pair template, a general large language model is used to generate question-answer pairs from the multi-scenario data to construct a scenario-specific question-answer pair dataset.

3. The method according to claim 2, characterized in that, After generating question-answer pairs from the multi-scenario data using a general large language model based on the target question-answer pair template to construct a scenario-specific question-answer pair dataset, the method further includes: The question-answer pair dataset is used as the training data for the general large language model, and the general large language model is fine-tuned to obtain the target large language model.

4. The method according to claim 1, characterized in that, The process of parsing the requirement document using the target large language model yields multiple function point counts, including: The chapter titles and body content of the required document are parsed to obtain the first document data; Construct a first prompt message, and use the first prompt message to guide the target large language model to analyze the structure of the first document data to obtain the second document data; Construct a second prompt message, and use the second prompt message to guide the target large language model to extract the functional description text from the second document data; Construct a third prompt message, and use the third prompt message to guide the target large language model to generate a function point count item that conforms to the expression rules based on the function description text.

5. The method according to claim 1, characterized in that, The step of using the target large language model to identify the transaction type for each function point count item, and obtaining the transaction type corresponding to the function point count item, includes: Build categorized prompts that include transaction type definitions; The classification prompts are used to guide the target large language model to identify the transaction type for each function point count item, thereby obtaining the transaction type corresponding to the function point count item. The transaction type includes internal logic file, external interface file, external input, external output, and external query.

6. The method according to claim 1, characterized in that, The step of generating software function scale measurement results for the software project based on the transaction type includes: The total number of function points is determined based on the transaction type of each function point count item, according to the software function size measurement standard rules. Based on the target adjustment factor and the target pricing model, determine the workload and cost quotation corresponding to the total number of function points; Based on the transaction type, the total number of function points, the workload, and the cost quote, generate a software function scale measurement result for the software project.

7. A software function scale measurement device, characterized in that, include: The acquisition unit is used to acquire the requirements document for a software project. The parsing unit is used to parse the requirement document using the target large language model to obtain multiple function point count items. The target large language model is a large language model fine-tuned by domain knowledge of software function scale measurement. The identification unit is used to identify the transaction type of each function point count item using the target large language model, and obtain the transaction type corresponding to the function point count item. The generation unit is used to generate a software functionality scale measurement result for the software project based on the transaction type.

8. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

Images