Development workload evaluation method, device and system and storage medium

Abstract

The invention is suitable for the technical field of computers, and provides a development workload evaluation method, device and system and a storage medium, and the method comprises the steps: obtaining user demand information corresponding to to-be-developed software; obtaining business scene content related to the user demand information, and generating development demand information corresponding to the to-be-developed software according to the business scene content and the user demand information and a preset standardized demand template; determining a preliminary development scheme of the to-be-developed software according to the development demand information; and according to the preliminary development scheme, evaluating the development workload of the to-be-developed software. According to the embodiment, the user demand information is automatically converted into the standardized development demand information generated according to the standardized demand template, then the preliminary development scheme can be generated according to the development demand information, then the workload is evaluated according to the preliminary development scheme, the evaluation process of the development workload does not need to be manually carried out offline, and the efficiency is high.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a method, apparatus, system and storage medium for evaluating development workload. Background Technology

[0002] Before a project is developed, a technical design is usually required, and the development workload is assessed based on the technical design. During the project development process, the development work is carried out according to the assessment results.

[0003] Development workload assessment involves manpower, resource allocation, and coordination, making the process complex. Therefore, in related technologies, offline manual assessment is often used. For example, the project team first develops a preliminary development plan, then conducts an internal preliminary assessment of requirements and workload. The architecture support department matches this assessment with the project team's needs, and then discusses and modifies the preliminary workload assessment based on the matching results, arriving at the final development workload assessment result. However, offline manual assessment of development workload is inefficient. Summary of the Invention

[0004] This application provides a method, apparatus, system, and storage medium for evaluating development workload, which can solve the problem of low efficiency in evaluating development workload.

[0005] In a first aspect, embodiments of this application provide a method for evaluating development workload, including: Obtain user requirements information for the software to be developed; Obtain business scenario content related to the user's needs information, and generate development requirements information corresponding to the software to be developed according to the business scenario content and the user's needs information and a preset standardized requirements template. Based on the development requirements information, a preliminary development plan for the software to be developed is determined; Based on the preliminary development plan, assess the development workload of the software to be developed.

[0006] In one possible implementation of the first aspect, generating development requirement information corresponding to the software to be developed according to a preset standardized requirement template based on the business scenario content and the user requirement information includes: Analyze the business scenario content and user demand information from at least one of the following dimensions: business scenario dimension, functional goal dimension, data flow dimension, and business rule dimension, to obtain explicit and implicit demands. According to the preset standardized requirement template, the explicit requirements and the hidden requirements are converted into development requirement information corresponding to the software to be developed.

[0007] In one possible implementation of the first aspect, the step of converting the explicit requirements and the implicit requirements into development requirement information corresponding to the software to be developed according to a preset standardized requirement template includes: The explicit and implicit requirements are divided into multiple requirement points; Generate the operation steps, expected results, and business-related modules corresponding to each requirement point; Based on the operation steps, the expected results, and the business-related modules, the development requirements information corresponding to the software to be developed is generated.

[0008] In one possible implementation of the first aspect, determining the preliminary development plan for the software to be developed based on the development requirements information includes: Obtain the basic software corresponding to the software to be developed; Obtain the comparison results of the differences between the functional requirements corresponding to the development requirements information and the basic functions of the basic software; If the comparison results include differentiated requirements, then a preliminary development plan for the software to be developed is determined based on the differentiated requirements.

[0009] In one possible implementation of the first aspect, obtaining the comparison results of the differences between the functional requirements corresponding to the development requirement information and the basic functions of the basic software includes: The basic functions of the basic software are compared sequentially with the functional requirements corresponding to the development requirements information. If the basic function fulfills the functional requirement, then it is determined that the functional requirement is covered by the basic function. If the basic function implements part of the functional requirement, then it is determined that the functional requirement is partially covered by the basic function, and the unimplemented part is determined to be a differentiated requirement. If the basic functions cannot fulfill the functional requirements, the functional requirements are determined to be differentiated requirements. The difference comparison results are determined based on the functional requirements covered or partially covered by the basic functions, and / or the differentiated requirements.

[0010] In one possible implementation of the first aspect, assessing the development workload of the software to be developed based on the preliminary development plan includes: The initial development plan is broken down into multiple user stories, and the entities that implement each user story are identified; For each entity in the user story, the baseline total work of the entity is evaluated from at least one development impact dimension, based on the entity type of the entity. The development workload of the software to be developed is determined based on the development difficulty of each entity and the baseline total workload.

[0011] In one possible implementation of the first aspect, determining the development workload of the software to be developed based on the development difficulty of each entity and the baseline workload includes: The weighting coefficients of the entity are determined based on the development type of the entity and the data model required to implement the entity. The coefficients of the introduced variables of the entity are determined based on the completeness of the introduced data of the entity; The development workload of the entity is determined based on the baseline total workload, the weighting coefficient, and the introduced variable coefficient. The development workload of the user story is determined based on the development workload of the entity. The development workload of the software to be developed is determined based on the development workload of each user story.

[0012] In one possible implementation of the first aspect, the development impact dimensions include functional complexity, technical implementation difficulty, data interaction volume, and testing and verification costs. The step of assessing the baseline total workload of the entity from at least one development impact dimension based on the entity type includes: Based on the entity type, determine the first baseline workload corresponding to the functional complexity, the second baseline workload corresponding to the technical implementation difficulty, the third baseline workload corresponding to the data interaction volume, and the fourth baseline workload corresponding to the test and verification cost. The total baseline workload of the entity is determined based on the first baseline workload, the second baseline workload, the third baseline workload, and the fourth baseline workload.

[0013] In one possible implementation of the first aspect, the method is applied to a computer device equipped with a development workload assessment model. The development workload assessment model includes a requirements generation module, a development scheme generation module, and a workload estimation module. The requirements generation module generates development requirements information corresponding to the software to be developed based on the business scenario content and the user requirement information, according to a preset standardized requirements template. The development scheme generation module determines a preliminary development scheme for the software to be developed based on the development requirements information. The workload estimation module assesses the development workload of the software to be developed based on the preliminary development scheme.

[0014] Secondly, embodiments of this application provide a development workload evaluation apparatus, including: The acquisition unit is used to acquire user requirement information corresponding to the software to be developed. The requirement generation unit is used to obtain business scenario content related to the user requirement information, and generate development requirement information corresponding to the software to be developed according to the business scenario content and the user requirement information and a preset standardized requirement template. The development scheme generation unit is used to determine a preliminary development scheme for the software to be developed based on the development requirements information. The workload assessment unit is used to assess the development workload of the software to be developed based on the preliminary development plan.

[0015] Thirdly, embodiments of this application provide a development workload assessment system, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any one of the first aspects above.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium, comprising: the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method as described in any one of the first aspects above.

[0017] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to perform the method described in any one of the first aspects above.

[0018] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.

[0019] The beneficial effects of this application embodiment compared with the prior art are as follows: By obtaining user requirement information corresponding to the software to be developed, obtaining business scenario content related to the user requirement information, and then generating development requirement information corresponding to the software to be developed according to the business scenario content and user requirement information and a preset standardized requirement template, a preliminary development plan for the software to be developed can be generated based on the development requirement information and a preset development architecture. The system can then assess the development workload based on the preliminary development plan. This application embodiment can automatically convert user requirement information into standardized development requirement information generated according to the standardized requirement template. The system can then generate a preliminary development plan based on the standardized development requirement information. After obtaining the preliminary development plan, the workload assessment is performed based on the preliminary development plan. The workload assessment process does not require offline manual processing, which is highly efficient. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the development workload assessment system architecture provided in one embodiment of this application; Figure 2 This is a flowchart illustrating a method for evaluating development workload provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a method for evaluating development workload provided in another embodiment of this application; Figure 4 This is a flowchart illustrating a method for evaluating development workload provided in another embodiment of this application; Figure 5 This is an interactive flowchart of a development workload assessment method provided in one embodiment of this application; Figure 6 This is a schematic diagram of the structure of the development workload evaluation device provided in the embodiments of this application. Detailed Implementation

[0022] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0023] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0024] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0026] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

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

[0028] During the pre-sales Proof of Concept (POC) and project implementation and delivery, after clarifying the client's requirements, the project team conducts technical design and assesses the development workload based on the technical design. Development work proceeds according to the assessment results. The development workload assessment involves manpower, resource allocation, and coordination, making the process complex. For example, if the project team first holds internal meetings to discuss and initially assess the requirements and workload, and then provides the preliminary assessment results to the architecture support department, which then matches these results with the project team's requirements, and finally determines the final development workload through meetings with the project team, this offline, manual assessment method is extremely inefficient.

[0029] Based on this, this application provides a method for evaluating development workload, shifting from offline to online assessment. However, due to the complexity of the development workload evaluation process, online assessment presents certain difficulties. For example, before development begins, there is no development plan, making it impossible to accurately obtain the evaluation object and dimensions. The evaluation granularity is coarse, resulting in inaccurate results, which can affect the subsequent project development. In this application, however, by analyzing user needs and combining them with relevant business scenarios, user needs are converted into detailed development requirement information. Then, an accurate development plan is generated based on this information, and the development workload is evaluated according to the plan. Therefore, the evaluation results are highly accurate and efficient.

[0030] The following describes the development workload assessment method provided in the embodiments of this application through various application examples.

[0031] For example, the development workload evaluation method provided in this application embodiment can be applied to terminal devices such as mobile phones, tablets, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), and computers. This application embodiment does not impose any restrictions on the specific type of terminal device.

[0032] For example, Figure 1 This is a schematic diagram of the development workload assessment system architecture provided in the embodiments of this application, such as... Figure 1 As shown, the development workload assessment system architecture includes a presentation layer, a core service layer, and a basic service layer. The presentation layer is the interface layer, which includes an operation workbench, an assessment list, and a log list. The operation workbench is used for users to input user requirements information. The assessment list is used to display the assessment results, that is, the list of development workloads obtained after the system assesses the user requirements information. The log list is used to display the process information of the system's assessment of user requirements information (including assessment steps, etc.).

[0033] The core service layer is the core processor layer of the development workload assessment system and is an intelligent decision-making technology unit. For example, the core service layer includes: a requirements generation unit, a function matching unit, a development plan generation unit, and a workload assessment unit.

[0034] In one alternative embodiment, the basic service layer includes data storage for storing data generated during the development workload assessment process by the development workload assessment system.

[0035] In another optional embodiment, the basic service layer includes AI services and data storage. The AI ​​services include an AI teleprompter, an AI knowledge base, and an AI task flow. The core service layer and the basic service layer work together to invoke the AI. For example, the AI ​​model is invoked through the requirement generation unit to generate development requirement information; the AI ​​model is invoked through the function matching unit to compare the functional requirements of the development requirement information with the basic functions of the basic software; the AI ​​model is invoked through the development plan generation unit to generate preliminary development plans corresponding to the differentiated requirements; and the AI ​​model is invoked through the workload assessment unit to assess the development workload based on the preliminary development plan.

[0036] Figure 2 A schematic flowchart illustrating a development workload assessment method according to an embodiment of this application is shown. This is an example and not a limitation; the method can be applied to the aforementioned development workload assessment system. Figure 2 As shown, the methods for evaluating development workload include: S201, Obtain user requirement information corresponding to the software to be developed; The development workload assessment system provides a user interface, also known as an operation platform, where users can input their requirements. For example, user requirements may include at least one of the following: target business scenario, functional objectives, and problem requests. It should be noted that the target business scenario refers to the business usage scenario of the software to be developed, the functional objectives refer to the functions the software to be developed will implement, and the problem requests refer to the problems the software to be developed needs to solve.

[0037] In some embodiments, user requirement information also includes development constraint information. For example, development constraint information includes development specification constraints, external dependency or integration constraints, data permission constraints, and business permission constraints. Development specification constraints refer to the user's choice to use or restrict the use of a certain development specification. External dependency or integration constraints refer to the user's choice to access a third-party interface or integrate a module into the software to be developed. Data permission and business permission constraints refer to limitations on data and business operations.

[0038] S202, Obtain business scenario content related to user needs information, and generate development requirement information corresponding to the software to be developed according to the business scenario content and user needs information and the preset standardized requirement template. When users submit requirements, they typically only express conceptual needs, such as conveying the overall requirement in a single sentence or paragraph. Therefore, based on user requirements, computer equipment cannot automatically generate a preliminary development plan. Consequently, a preliminary development plan needs to be manually defined, and then a workload assessment needs to be conducted based on that plan.

[0039] The workload assessment system in this embodiment can enrich and expand the user's requirements information after obtaining it, and automatically convert it into detailed development requirements information, so that the development requirements information meets the requirements for automatic generation of preliminary development plan without the need for manual setting of preliminary development plan.

[0040] For example, business scenario content related to user needs information refers to business scenario content in existing software that is similar to or close to the user needs information. For example, suppose the user needs to develop a system (software) that "automatically stops device payments and synchronizes them to the financial system after an employee leaves the company." Business scenario content related to user needs information includes business scenario content obtained through channels such as HR Cloud industry knowledge, HR Cloud community knowledge, or personal community knowledge areas.

[0041] In an optional embodiment, the development workload assessment system can retrieve business scenario content related to user needs through a third-party interface.

[0042] In an optional embodiment, the development workload assessment system can also construct AI prompts based on user needs information to guide the AI ​​engine in obtaining business scenario content related to user needs. Data acquired through AI is more comprehensive, allowing for the acquisition of more complete and richer business scenario content.

[0043] After obtaining business scenario content related to user needs, the development requirements information for the software to be developed is generated according to the business scenario content and user needs information, following a pre-set standardized requirements template.

[0044] In this embodiment, the standardized requirement template is pre-set, specifying the required information. Based on this information, a comprehensive and detailed preliminary development plan can be generated. For example, the standardized requirement template refers to a detailed requirement specification, which includes a requirement number, requirement name, original user requirement information, requirement points, corresponding operation steps, expected results, and associated business modules. The development workload assessment system analyzes the user requirement information and related business scenario content according to the requirements of the standardized requirement template, fills the analysis results into the corresponding positions of the standardized requirement modules, and generates the development requirement information for the software to be developed.

[0045] To obtain more comprehensive and detailed development requirements information and ensure the accuracy of subsequent workload assessment, one possible implementation involves analyzing business scenario content and user needs from at least one of the following dimensions: business scenario, functional goal, data flow, and business rules. This process uncovers explicit and implicit requirements. Then, following a pre-defined standardized requirement template, these explicit and implicit requirements are converted into development requirements for the software to be developed. Explicit requirements refer to direct user input, determined based on user needs. Implicit requirements refer to other technologies not explicitly stated by the user that are necessary to achieve user objectives, system stability, and system closure. This embodiment analyzes business scenario content and user needs information from the dimensions of business scenario, functional goal, data flow, and business rules. This detailed analysis, mining, and expansion of user needs information across these dimensions yields more complete and comprehensive actual requirements, facilitating the automatic generation of preliminary development plans and ensuring their greater completeness.

[0046] As an example, the standardized requirement template details the operational steps, expected results, and related business modules for each requirement point. Therefore, the development requirement information generated according to the standardized requirement template includes the operational steps, expected results, and related business modules for each requirement point. Optionally, according to the preset standardized requirement template, explicit and implicit requirements are converted into development requirement information corresponding to the software to be developed, including: A1: Divide explicit and implicit needs into multiple demand points.

[0047] Optionally, the minimum functional point can be used as a requirement point to divide explicit and implicit requirements into multiple requirement points.

[0048] A2: Generate the operation steps, expected results, and business-related modules for each requirement point; By analyzing each requirement, we can determine the corresponding operational steps, the expected results, and the business-related modules for that requirement.

[0049] A3: Based on the operation steps, expected results, and business-related modules, generate the development requirements information corresponding to the software to be developed.

[0050] S203, Based on the development requirements information, determine the preliminary development plan for the software to be developed; In this step, based on the development specifications selected by the user, or based on the established development specifications, and combined with the specific development strategies required for the software to be developed, the development requirements information is analyzed to generate a preliminary development plan for the software to be developed.

[0051] In one possible implementation, an AI model-based development scheme generation module generates a preliminary development scheme for the software to be developed. For example, the AI ​​model analyzes development requirements based on the selected development platform and the prompts set for the development scheme, and then generates a preliminary development scheme for the software according to the prompts.

[0052] Suppose a user needs to develop a system (software) that automatically stops device payments and synchronizes them to the financial system after an employee leaves. This requirement falls under the HR Cloud business scenario. If the user chooses a development platform whose development specification is "primarily low-code, supplemented by high-code," then based on HR Cloud's specific development strategies, a preliminary development plan will be generated by learning from pre-built basic data, documents, interfaces, and other feasible scenarios, based on low-code as the primary approach and high-code as a supplement.

[0053] S204. Based on the preliminary development plan, assess the development workload of the software to be developed.

[0054] In one alternative embodiment, the workload required to develop each requirement or each function can be determined based on the preliminary development plan, and then the development workload of the software to be developed can be determined based on the sum of the workloads of all requirement points or all function points.

[0055] In another alternative embodiment, when evaluating the preliminary development plan, the development workload is comprehensively assessed by combining information such as development difficulty and cost, thereby improving the accuracy of the development workload assessment.

[0056] For example, based on the preliminary development plan, assessing the development workload of the software to be developed includes: B1: Break down the initial development plan into multiple user stories and determine the entities that implement each user story; B2: For each entity in the user story, assess the baseline total work of the entity from at least one development impact dimension, based on the entity type of the entity; Optionally, the dimensions of development impact include functional complexity, technical implementation difficulty, data interaction volume, and testing and verification costs.

[0057] B3: Determine the development workload of the software to be developed based on the development difficulty of each entity and the baseline total workload.

[0058] It is understandable that the development difficulty of an entity can be determined based on at least one of the entity's development type, data model, and the introduction of data completeness, and then the baseline workload can be determined based on the entity's development difficulty and the baseline workload.

[0059] As an optional implementation, development type, data model, and data integrity are converted into specific parameter values. These values ​​are then substituted into preset formulas to calculate development difficulty. The preset formulas reflect the relationship between development type, data model, data integrity, and development difficulty. The baseline workload is adjusted based on the development difficulty to improve the accuracy of workload assessment.

[0060] As an optional implementation, a mapping table between development difficulty and weighting values ​​is pre-set. After determining the development difficulty, the corresponding target weighting value is retrieved from the mapping table. The baseline workload is then weighted based on the target weighting value to obtain the baseline workload for each entity, thereby determining the development workload of the software to be developed.

[0061] As another optional implementation method, the development difficulty is reflected by dimensions such as development type, data model and the completeness of introduced data. The development difficulty reflected by each dimension is determined to determine multiple weighting coefficients. Then, based on the baseline total workload, the baseline total workload is corrected by multiple weighting coefficients. The specific implementation process can be referred to in the following embodiment.

[0062] As an example, after assessing the development workload of the software to be developed based on the preliminary development plan, the development workload is converted into document form based on a preset Word format mapping library to generate a development plan document.

[0063] In one possible implementation, based on a preset Word format mapping library, the development workload is converted into a document format to generate a development solution document. This includes: breaking down the development workload into a structured form to obtain the structured data corresponding to the development workload; mapping the structured data to a preset document template according to the preset Word mapping library to obtain the target document; and outputting the target document for users to download.

[0064] Understandably, the process of breaking down the development workload into structures includes: parsing titles / sections: for example, identifying levels based on semantic keywords to determine titles / sections, such as keywords like "Overview of Requirements" as titles or sections; parsing tables: extracting the header, row data, and column numbers of Markdown tables to obtain structured table data; and parsing the body text: converting it to Word style based on paragraph splitting and formatting marks.

[0065] Understandably, after obtaining the structured data corresponding to the development workload, based on a preset Word format mapping library, the title, body text, and tables are rendered according to chapter hierarchy in a preset document template. The rendered document template serves as the target document data. This step achieves precise data-format mapping for structured data.

[0066] In this embodiment, by acquiring user requirement information corresponding to the software to be developed, and obtaining business scenario content related to the user requirement information, the system generates development requirement information for the software to be developed according to a preset standardized requirement template based on the business scenario content and user requirement information. Then, based on the development requirement information and a preset development architecture, a preliminary development plan for the software to be developed can be generated. The system can then assess the development workload based on this preliminary development plan. This embodiment can automatically convert user requirement information into standardized development requirement information generated according to a standardized requirement template. The system can then generate a preliminary development plan based on this standardized development requirement information. After obtaining the preliminary development plan, a workload assessment is performed based on it. This workload assessment process does not require manual offline processing, resulting in high efficiency.

[0067] Figure 3 A schematic flowchart illustrating a development workload assessment method according to another embodiment of this application is shown. This is an example and not a limitation; the method can be applied to the aforementioned development workload assessment system. This embodiment is another implementation of step S203 in the foregoing embodiments. Figure 3 As shown, it includes: S301, Obtain the basic software corresponding to the software to be developed; Optionally, the basic software corresponding to the software to be developed refers to the foundation upon which the software to be developed is built. That is, if the software to be developed is based on version A software, then version A software is the basic software corresponding to the software to be developed. The development workload assessment system can be applied to scenarios with entirely new software to be developed (i.e., without basic software), or it can be applied to scenarios with software to be developed based on basic software (as in this embodiment).

[0068] For example, the base software can be selected by the user; that is, when the user inputs user requirement information, the user selects the base software of the software to be developed.

[0069] Alternatively, the base software can be automatically adapted to the base software of the software to be developed based on user needs information. For example, the type of software to be developed can be determined based on user needs information, and the latest version of the software with the smallest functional difference from the software to be developed can be used as the base software.

[0070] S302, Obtain the comparison results of the differences between the functional requirements corresponding to the development requirements information and the basic functions of the basic software; If the software to be developed is developed on top of the basic software, then when assessing the development workload of the software to be developed, the assessment should focus on the workload of customized development outside the basic software. In other words, this embodiment is a workload assessment for customized development.

[0071] As an example, the corresponding functional requirements can be determined based on the development requirements information. It can be determined which functional requirements can be implemented by the basic software and which cannot. The functional requirements that cannot be implemented by the basic software are identified as differentiated requirements, which are also requirements that need to be customized.

[0072] As an example, a three-tiered judgment rule of "configuration implementation," "partially satisfied," and "completely missing" is predefined to determine the difference between the functional requirements corresponding to the development requirements information and the basic functions of the basic software. For example, obtaining the difference comparison results between the functional requirements corresponding to the development requirements information and the basic functions of the basic software includes: The basic functions of the foundational software are compared sequentially with the corresponding functional requirements in the development requirements information to determine whether the basic functions can fulfill the required functionality. Optionally, it is determined whether the required functionality can be achieved through configuration of the basic functions. If it can be achieved through configuration, the basic functions fulfill the required functionality; if it cannot be achieved through configuration, the basic functions cannot fulfill the required functionality. For example, functional requirements such as showing / hiding form fields, adjusting process nodes, and filtering report conditions can be achieved.

[0073] If the basic functionality fulfills the functional requirement, then it is determined that the functional requirement is covered by the basic functionality, the functional requirement is marked as covered, and the configuration path of the functional requirement is determined.

[0074] If the basic functionality cannot fulfill the functional requirement, further assessment is needed to determine whether the basic functionality can fulfill a portion of the functional requirement, i.e., whether the basic functionality partially satisfies the functional requirement. If the basic functionality fulfills a portion of the functional requirement, it is determined that the functional requirement is partially covered by the basic functionality, clearly identifying the fulfilled and unfulfilled portions, and determining the unfulfilled portion as a differentiated requirement. For example, regarding the requirement of "cross-departmental salary allocation," the basic functionality supports allocation to 2 departments, but the user requirement supports allocation to 5 departments, indicating that the basic functionality fulfills a portion of the functional requirement.

[0075] If the basic functions cannot fulfill the functional requirements, the functional requirements are identified as differentiated requirements; based on these differentiated requirements, the results of the difference comparison are determined. In other words, the basic software completely lacks functional requirements.

[0076] That is, by comparing each basic function of the basic software, we check each functional requirement in the development requirements information one by one to see if it is covered by the basic functions, if it is partially covered, and if it is not covered, and finally we get the differentiated requirements (the requirements that the basic software cannot meet).

[0077] As an example, the difference comparison results include the difference requirements. That is, after the above three-level judgment, the final difference requirements are determined, and then the difference comparison results are output based on the difference requirements.

[0078] As another example, the difference comparison results are presented in the form of a difference requirement comparison table, which includes requirement number, requirement point, basic software comparison results, basic software function description (such as version, module, operation path, etc.) and difference requirement description (for the unimplemented parts and uncovered functional requirements in the partial coverage).

[0079] S303, if the difference comparison results include difference requirements, then the difference requirements determine the preliminary development plan for the software to be developed.

[0080] In an optional embodiment, a preliminary development plan is generated based on differentiated requirements, primarily using low-code and secondarily using high-code. In this optional embodiment, the design dimensions of the preliminary development plan include technology selection, data model design, business logic implementation, interface design (involving integration), and front-end interaction design.

[0081] For example, regarding technology selection, the core technology components to be used must be clearly defined, such as using "BOS Form Designer" to create basic data entities for basic data storage, document entities for approval purposes, or dynamic forms for non-routine operations. Regarding data model design, the data entities to be added / modified must be specified, including entity names, core fields, and field types. Regarding business logic implementation, pseudocode or steps must be used to describe the core logic, such as triggering service rules after an employee's resignation is approved: 1. Obtain the employee's social security account from XXX; 2. Call the third-party social security suspension interface; 3. Write the synchronization result to XXXX, etc. Regarding interface design, if integration is involved, the interface type must be clearly defined, such as REST API, request parameters, response parameters, etc. Regarding front-end interaction design, the presentation format of the front-end page must be described, such as adding a "Social Security Synchronization" button in the "Resignation Management" module, popping up a synchronization confirmation dialog box, and displaying the synchronization result.

[0082] A preliminary development plan is generated from the dimensions of technology selection, data model design, business logic implementation, interface design, and front-end interaction design. This preliminary development plan is complete and detailed, which facilitates the subsequent workload estimation based on the preliminary development plan.

[0083] Understandably, the final output preliminary development plan is presented as a set of preliminary development plans corresponding to the differentiated requirements. Based on the requirement number corresponding to each differentiated requirement, a corresponding initial design plan is generated one by one. Each initial design plan includes a technical design overview, core design points, development considerations, etc. All the initial design plans corresponding to the differentiated requirements constitute the preliminary development plan for the software to be developed.

[0084] This embodiment automatically generates customized development plans for functional requirements not found in the basic software, providing an assessment basis for subsequent development workload evaluation, and the detailed customized development plans can improve the accuracy of development workload evaluation.

[0085] Figure 4 A schematic flowchart illustrating a development workload assessment method according to another embodiment of this application is shown. This is an example and not a limitation; the method can be applied to the aforementioned development workload assessment system. This embodiment is another implementation of step S204 in the foregoing embodiments. Figure 4 As shown, it includes: S401, break down the initial development plan into multiple user stories and determine the entities that implement each user story; A User Story (US) is a small-scale feature that is associated with business value. In other words, the initial development plan is broken down into multiple User Stories based on the small-scale features that have business value, and the workload is assessed based on the entities that implement each User Story.

[0086] Optionally, the initial development plan can be broken down into multiple user stories (US) according to the INVEST principle. Each US is an independent, negotiable, valuable, estimable, and testable small unit.

[0087] It should be noted that a user story may be implemented by one entity, or it may be implemented by multiple entities and the interaction relationships between them.

[0088] S402, For each entity in a user story, assess the baseline total work of the entity from at least one development impact dimension, based on the entity type. Entity types include basic data, documents, dynamic forms, reports, layouts, multi-entity queries, and integration interfaces. In this embodiment, different baseline workloads are set based on different entity types, and the baseline workloads of entities are divided according to different development impact dimensions. The total baseline workload of an entity is calculated from multiple development impact dimensions, resulting in a more accurate estimate of the total baseline workload.

[0089] Optionally, development impact dimensions include functional complexity, technical implementation difficulty, data interaction volume, and testing and verification costs. Based on the entity type, the baseline total effort for the entity is assessed from at least one development impact dimension, including: Based on the entity type, determine the first baseline workload in terms of functional complexity, the second baseline workload in terms of technical implementation difficulty, the third baseline workload in terms of data interaction volume, and the fourth baseline workload in terms of testing and verification cost. The total baseline workload of the entity is determined based on the first baseline workload, the second baseline workload, the third baseline workload, and the fourth baseline workload.

[0090] For example, if the entity type is basic data, then the first baseline workload is determined to be 1 person-day based on functional complexity, the second baseline workload is determined to be 1 person-day based on technical implementation difficulty, the third baseline workload is determined to be 0.5 person-days when the data interaction volume is single data interaction, the third baseline workload is determined to be 1 person-day when the data interaction volume is batch data interaction, and the fourth baseline workload is determined to be 0.5 person-days based on testing and verification costs. Therefore, the total baseline workload for this entity is 1 + 1 + 0.5 (or 1) + 0.5 = 3 (or 3.5) person-days.

[0091] For example, if the entity type is a dynamic form, then the first baseline workload is determined to be 2 person-days based on functional complexity, the second baseline workload is determined to be 2 person-days based on technical implementation difficulty, the third baseline workload is determined to be 2 person-days if the data interaction volume is single data interaction, and the third baseline workload is determined to be 3 person-days if the data interaction volume is batch data interaction. The fourth baseline workload is determined to be 1.5 person-days based on testing and verification costs. Therefore, the total baseline workload for this entity is 2 + 2 + 2 (or 3) + 1.5 = 7.5 (or 8.5) person-days.

[0092] It should be noted that the baseline workload is generated based on historical development data. For example, for the same entity type, the required baseline development workload is analyzed under the influence of different development impact dimensions to determine the baseline development workload corresponding to each development impact dimension.

[0093] Alternatively, the baseline workload can be pre-defined by the developers. For example, a pre-defined correspondence between entity type, development impact dimension, and baseline workload can be established, with each entity type including at least one development impact dimension. During the estimation of development workload, after determining the entity type, the system retrieves all development impact dimensions under the entity type and the corresponding baseline workload to obtain the total baseline workload for the entity.

[0094] S403, determine the weighting coefficient of the entity based on the entity's development type and the data model required to implement the entity; It should be noted that the baseline workload is a pre-set basic workload or an estimate based on historical development data. However, for specific development projects, many other factors can influence the development workload. For example, the type of customized development and the data model required for development will affect the workload.

[0095] In an optional embodiment, a first weighting value is determined based on the development type of the entity, a second weighting value is determined based on the data model required by the entity, and the weighting coefficient of the entity is determined based on the first weighting value and the second weighting value.

[0096] Customized development includes at least one of the following types: extension, inheritance, and complete self-implementation. Each type has a different level of difficulty. For example, extension is relatively easy, with a first weighted value of 50%; inheritance is more difficult, with a first weighted value of 80%; while complete self-implementation is extremely difficult, with a first weighted value of 100%. Therefore, different development types require different levels of adjustment to the baseline workload.

[0097] A data model includes at least one of fields and logical branches. The number of fields and logical branches directly affects the development workload. For example, 1-5 fields are relatively simple, requiring less development work, assuming a corresponding second weighting value of 100%; 6-10 fields represent medium difficulty, requiring more development work, assuming a corresponding second weighting value of 150%; and more than 10 fields represent high difficulty, requiring even more development work, assuming a corresponding second weighting value of 200%. Therefore, different data models for different entities require different levels of adjustment to the baseline workload. Similarly, logical branches, combined with fields, determine the second weighting value.

[0098] For example, if the development type is inheritance, the first weighting value is determined to be 80%, and if the field is medium difficulty, the second weighting value is 150%, and the weighting coefficient of the entity is 80%*150%.

[0099] S404, Determine the coefficients of the introduced variables of the entity based on the completeness of the introduced data; It is understandable that "data completeness" refers to the completeness of data imported from third parties in the initial development plan. If the imported data is complete, importing data through third-party interfaces has no impact on development and does not require additional development time. If the imported data is incomplete, it will impact development and require additional development time, with lower data completeness corresponding to more development time. Therefore, different import variable coefficients are set based on different data completeness levels. During workload estimation, these coefficients are determined based on the required data completeness for each entity (i.e., the imported data completeness), and the baseline workload is then adjusted accordingly.

[0100] For example, if the third-party interface documentation is complete, the corresponding coefficient of the introduced variable is 1 (or 100%), and if the third-party interface documentation is incomplete, the corresponding coefficient of the introduced variable is 1.2 (or 120%).

[0101] S405, determine the development workload of the entity based on the baseline total workload, weighting coefficients, and introduced variable coefficients; For example, the development workload of an entity = baseline total workload * weighting coefficient * coefficient of introduced variables.

[0102] For example, suppose the entity type is a report. Based on the report, the baseline total workload (functional complexity = 1.5 person-days, technical implementation difficulty = 1 person-day, batch data interaction volume = 1.5 person-days, testing and verification cost = 1 person-day) is determined to be 5 person-days. The determined development dimension is extension, the fields are of medium difficulty (6-10 fields), and the logical branches are of medium difficulty. Therefore, the corresponding weighting coefficients are 50%, 150%, and 150%. Third-party documentation needs to be imported, but it is incomplete; therefore, the coefficient for the imported variable is 120%. Thus, the development workload for this entity = 5 * 50% * 150% * 150% * 120% = 6.75 person-days. Therefore, the final calculated development workload for the entity is 6.75 person-days, not 5 person-days.

[0103] S406, Determine the development workload of user stories based on the development workload of entities; A user story is implemented by at least one entity, and the development effort of a user story is determined by the sum of the development efforts of all entities that implement the user story.

[0104] S407 determines the development workload of the software to be developed based on the development workload of each user story.

[0105] The software to be developed consists of multiple user stories, and the development workload of the software to be developed is equal to the sum of the development workloads of each user story.

[0106] This embodiment breaks through the single-dimensional evaluation mode and constructs a multi-factor weighted calculation, which subdivides the baseline workload into multiple development impact dimensions. The baseline total workload of the entity is determined through different development impact dimensions. Based on the baseline total workload, the development type of the entity, the data model of the entity, and the influence of the introduced variable coefficients on the development workload are also combined to adaptively adjust the baseline total workload, improve the accuracy of workload estimation, and reduce the workload assessment deviation to more than 30%.

[0107] Figure 5An interactive flowchart of a development workload assessment method provided in another embodiment of this application is shown. This is an example and not a limitation; the method can be applied to the aforementioned development workload assessment system. This embodiment is another embodiment based on the foregoing embodiments. In this embodiment, the development workload assessment is implemented based on an AI model. Optionally, the development workload assessment method of this embodiment is applied to a computer device deployed with a development workload assessment model, and the computer device is equipped with a development workload assessment system. The development workload assessment model includes a requirements generation module, a development plan generation module, and a workload estimation module. The requirements generation module is used to generate development requirements information corresponding to the software to be developed according to a preset standardized requirements template based on business scenario content and user needs information; the development plan generation module is used to determine a preliminary development plan for the software to be developed based on the development requirements information; and the workload assessment module is used to assess the development workload of the software to be developed based on the preliminary development plan.

[0108] Correspondingly, the development work evaluation system includes an acquisition unit, a requirement generation unit, a development plan generation unit, and a workload evaluation unit.

[0109] like Figure 5 As shown, the acquisition unit based on the development workload assessment system acquires user requirement information input by the user, and then sends the user requirement information to the requirement generation unit.

[0110] The requirement generation unit determines the corresponding prompts for requirement deduction based on user requirement information. Based on the user requirement information and prompts, it invokes the AI ​​model to convert the user requirement information into development requirement information. Specifically, the AI ​​model, based on the user requirement information and prompts, deduces the user requirement information within the requirement generation module, generates development requirement information according to a standardized requirement template, and outputs it to the requirement generation unit. Furthermore, the AI ​​model's requirement generation module is configured with a three-tier information collection mechanism. This three-tier information includes user-inputted functional requirement information (such as target business scenarios, functional objectives, and problem requests), user-inputted development constraint information (such as development specifications), and the user-selected basic software. If the AI ​​model does not obtain the three-tier information, it outputs a prompt requesting the user to supplement the three-tier information, and then generates development requirement information based on the complete three-tier information. The AI ​​model reduces the misjudgment rate of requirements from the source. It should be noted that the specific process of the requirement generation module generating development requirement information is the same as in the aforementioned embodiment.

[0111] The requirements generation unit outputs AI development requirements information (i.e., deduction results) for users to modify and confirm.

[0112] The system sends the user-modified and confirmed development requirements information to the development solution generation unit. Based on this information, the development solution generation unit invokes the AI ​​model to convert the requirements into a preliminary development solution. Specifically, after receiving the development requirements information, the AI ​​model generates technical solutions in a hierarchical manner within the development solution generation module. This can be done by generating mature solutions, customized development solutions, and development platform technical documentation, etc. The customized development solution is used as the preliminary development solution, which is then returned to the development solution generation unit. It should be noted that the specific process of generating the preliminary development solution in the development solution generation module is the same as in the aforementioned embodiment.

[0113] In one optional embodiment, before the development plan generation unit generates a preliminary development plan, the system sends the user-modified and confirmed development requirements information to the function matching unit (i.e., the development work evaluation system also includes a function matching unit). The function matching unit determines matching prompts based on the development requirements information, calls the AI ​​module, and matches the functional requirements of the development requirements information with the functions of the basic software. The AI ​​module determines differentiated requirements based on the prompts, development requirements information, and basic software, uses these differentiated requirements as development requirements information, and sends them to the development plan generation unit, which then generates a preliminary development plan.

[0114] The development plan generation unit outputs a preliminary development plan for users or developers to modify and confirm, and then transmits the modified and confirmed preliminary development plan to the workload assessment unit.

[0115] The workload assessment unit, based on the preliminary development plan, invokes the AI ​​model to convert the preliminary development plan into a development workload. Specifically, after receiving the preliminary development plan, the AI ​​model estimates the corresponding development workload within the workload assessment module. It should be noted that the specific process by which the workload assessment module estimates the development workload corresponding to the preliminary development plan is the same as in the aforementioned embodiment.

[0116] It's important to note that the AI ​​model is an intelligent agent created by training from multiple perspectives, including role definition, AI thought process construction, and knowledge source limitations, to meet specific needs. For example, by constructing role-specific prompts, the AI ​​model is confined to performing tasks within a defined role. Furthermore, constructing AI thought processes, such as completing a development workload assessment, requires sequential steps including: collecting and confirming preliminary information (preliminary information refers to user requirements), transforming and extrapolating requirements, comparing requirements with the basic software to output differentiated requirements (a step required for customized development), generating a preliminary development plan based on the differentiated requirements, and assessing the development workload based on the preliminary development plan.

[0117] In this embodiment, multiple project requirement analysis cases and development workload assessment cases are integrated, covering various development entity types, as relevant business scenario content, for the AI ​​model to analyze development requirements. This allows the AI ​​model to perform analysis based on more comprehensive and accurate knowledge content, thereby improving the accuracy of the AI ​​model's analysis results.

[0118] In some embodiments, the system also periodically extracts target documents from the document library, generates online knowledge, uploads community knowledge, and continuously updates online or community knowledge, enabling the system to obtain richer business scenario content when evaluating the software to be developed.

[0119] In some embodiments, the system continuously guides and trains the AI ​​model, making its inference results increasingly accurate. For example, the system periodically extracts target documents from a document library and inputs them into the AI ​​model, allowing the AI ​​model to continuously learn from completed projects, iteratively updating its knowledge. This enables the AI ​​model to more accurately analyze development requirements, generate more detailed preliminary development plans, and thus more accurately assess development workload.

[0120] This embodiment combines an AI model to automatically convert user demand information into development demand information, and then generates a preliminary development plan based on the development demand information. Based on the preliminary development plan, the development workload is evaluated, replacing manual offline evaluation and improving evaluation efficiency.

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

[0122] Corresponding to the development workload assessment method in the above embodiment, Figure 6 A structural block diagram of the development workload evaluation device provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0123] Reference Figure 6 The evaluation device 60 includes: Acquisition unit 601 is used to acquire user requirement information corresponding to the software to be developed; The requirement generation unit 602 is used to obtain business scenario content related to user requirement information, and generate development requirement information corresponding to the software to be developed according to the business scenario content and user requirement information and a preset standardized requirement template. The development scheme generation unit 603 is used to determine the preliminary development scheme of the software to be developed based on the development requirements information. Workload assessment unit 604 is used to assess the development workload of the software to be developed based on the preliminary development plan.

[0124] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0125] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0126] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the above-described method embodiments.

[0127] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the above-described method embodiments.

[0128] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0129] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0130] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for evaluating development workload, characterized in that, The method includes: Obtain user requirements information for the software to be developed; Obtain business scenario content related to the user's needs information, and generate development requirements information corresponding to the software to be developed according to the business scenario content and the user's needs information and a preset standardized requirements template. Based on the development requirements information, a preliminary development plan for the software to be developed is determined; Based on the preliminary development plan, assess the development workload of the software to be developed.

2. The method according to claim 1, characterized in that, The step of generating development requirement information for the software to be developed according to the business scenario content and the user requirement information, and following a preset standardized requirement template, includes: Analyze the business scenario content and user demand information from at least one of the following dimensions: business scenario dimension, functional goal dimension, data flow dimension, and business rule dimension, to obtain explicit and implicit demands. According to the preset standardized requirement template, the explicit requirements and the hidden requirements are converted into development requirement information corresponding to the software to be developed.

3. The method according to claim 1, characterized in that, The step of determining a preliminary development plan for the software to be developed based on the development requirements information includes: Obtain the basic software corresponding to the software to be developed; Obtain the comparison results of the differences between the functional requirements corresponding to the development requirements information and the basic functions of the basic software; If the comparison results include differentiated requirements, then a preliminary development plan for the software to be developed is determined based on the differentiated requirements.

4. The method according to claim 3, characterized in that, The comparison results of the differences between the functional requirements corresponding to the development requirements information and the basic functions of the basic software include: The basic functions of the basic software are compared sequentially with the functional requirements corresponding to the development requirements information. If the basic function fulfills the functional requirement, then it is determined that the functional requirement is covered by the basic function. If the basic function implements part of the functional requirement, then it is determined that the functional requirement is partially covered by the basic function, and the unimplemented part is determined to be a differentiated requirement. If the basic functions cannot fulfill the functional requirements, the functional requirements are determined to be differentiated requirements. The difference comparison results are determined based on the functional requirements covered or partially covered by the basic functions, and / or the differentiated requirements.

5. The method according to any one of claims 1 to 4, characterized in that, The step of assessing the development workload of the software to be developed based on the preliminary development plan includes: The initial development plan is broken down into multiple user stories, and the entities that implement each user story are identified; For each entity in the user story, the baseline total work of the entity is evaluated from at least one development impact dimension, based on the entity type of the entity. The weighting coefficients of the entity are determined based on the development type of the entity and the data model required to implement the entity. The coefficients of the introduced variables of the entity are determined based on the completeness of the introduced data of the entity; The development workload of the entity is determined based on the baseline total workload, the weighting coefficient, and the introduced variable coefficient. The development workload of the user story is determined based on the development workload of the entity. The development workload of the software to be developed is determined based on the development workload of each user story.

6. The method according to claim 5, characterized in that, The development impact dimensions include functional complexity, technical implementation difficulty, data interaction volume, and testing and verification costs. The assessment of the baseline total workload of the entity from at least one development impact dimension, based on the entity type, includes: Based on the entity type, determine the first baseline workload corresponding to the functional complexity, the second baseline workload corresponding to the technical implementation difficulty, the third baseline workload corresponding to the data interaction volume, and the fourth baseline workload corresponding to the test and verification cost. The total baseline workload of the entity is determined based on the first baseline workload, the second baseline workload, the third baseline workload, and the fourth baseline workload.

7. A device for evaluating development workload, characterized in that, include: The acquisition unit is used to acquire user requirement information corresponding to the software to be developed. The requirement generation unit is used to obtain business scenario content related to the user requirement information, and generate development requirement information corresponding to the software to be developed according to the business scenario content and the user requirement information and a preset standardized requirement template. The development scheme generation unit is used to determine a preliminary development scheme for the software to be developed based on the development requirements information. The workload assessment unit is used to assess the development workload of the software to be developed based on the preliminary development plan.

8. A system for evaluating development workload, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the method as claimed in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

10. A computer program product containing instructions, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 6.

Images