Quantitative management system, quantitative management method, and quantitative management program

Abstract

This disclosure enables comprehensive quantitative management and proposals for diverse needs. [Solution] A quantitative management system including a collection unit, a simulation processing unit, and a presentation processing unit outputs item expansion results, uses the quantification model to extract combinations of quantifiable targets that require quantification from the item expansion results, obtains input information for the combinations of quantifiable targets and performs calculations, and outputs quantitative information regarding the combinations of quantifiable targets.

Description

Technical Field

[0001] Conventionally, there has been a technology related to the management of system development.

[0002] For example, there is a technology related to a project support system capable of improving the efficiency of project management (see Patent Document 1). In the technology of Patent Document 1, it is disclosed to output project information together with the reliability of the correspondence relationship, and to check the consistency between the project plan information and the correspondence relationship based on the estimated reliability of the correspondence relationship.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] [[ID=Z31]] By the way, when developing systems in various industries, it may be required to develop a system after considering a wide range of requirements from business-level needs to management-level needs. However, management-level needs include market needs and external environment needs, and there are a variety of needs depending on the industry, and it was not possible to uniformly define requirements from the needs. Conventionally, it has been difficult to consider such complex needs and incorporate them into specifications and development requirements. Therefore, there has been a need for a method that can appropriately unify and quantify various needs from the management level to the business level, comprehensively manage them, support communication among related parties, and enable comprehensive improvement proposals.

[0005] An object of the present disclosure is to provide a quantitative management system, a quantitative management method, and a quantitative management program that enable comprehensive management and proposal by quantification for various needs. [Means for solving the problem]

[0006] The quantitative management system of this disclosure is a quantitative management system including a collection unit, a simulation processing unit, and a presentation processing unit. The collection unit collects variable portions relating to predetermined viewpoints and business item information. The viewpoints and business item information includes a plurality of hierarchically classified items and level items that are combined with the items at each level. The variable portions are a plurality of the items that are subject to quantification and are determined by an agreement between the ordering party and the contractor. The simulation processing unit uses a trained quantification model to perform a simulation by item expansion that generates hierarchical combinations using the items including the variable portions and the level items, and outputs the item expansion results. The presentation processing unit presents the item expansion results in a predetermined output manner, and the simulation processing unit uses the quantification model to extract combinations of quantifiable targets that require quantification from the item expansion results, obtains input information for the combinations of quantifiable targets and performs calculations, and outputs quantified information relating to the combinations of quantifiable targets. The presentation processing unit presents the quantified information in a predetermined output manner. [Effects of the Invention]

[0007] The quantitative management system, quantitative management method, and quantitative management program of this disclosure provide the effect of enabling comprehensive quantitative management and proposals for diverse needs. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is a conceptual diagram illustrating a quantitative management system based on knowledge information encompassing all aspects of the universe. [Figure 2] Figure 2 is a conceptual diagram illustrating an example of a foundation building method for clients and contractors in a quantitative management system based on knowledge information encompassing all aspects of the universe. [Figure 3] Figure 3 is a block diagram showing the functional configuration of the quantitative management system of this embodiment. [Figure 4] Figure 4 is a block diagram showing the hardware configuration of the quantitative management system. [Figure 5] Figure 5 is a flowchart showing the processing flow by the quantitative management system. [Figure 6] Figure 6 is an example of a table summarizing the planned vs. actual management of review bugs or test bugs. [Figure 7] Figure 7 shows an example of a combination of (dp(q)) and bi(α). [Figure 8] Figure 8 shows an example of a combination of bi(α) and nCi. [Figure 9] Figure 9 shows an example of the timeline of processing within a block. [Figure 10] Figure 10 shows an example of expanding an item table to the first, second, and third levels. [Figure 11] Figure 11 shows an example of how items related to software development work can be broken down. [Figure 12] Figure 12 shows an example of how to hierarchically refine combinations of tasks (requirements) using an item expansion table, with financial operations as an example. [Figure 13] Figure 13 shows an example of how to hierarchically refine the simulation items for the variable portion using an item expansion table. [Figure 14] Figure 14 shows an example of how to hierarchically refine management simulation items using an item expansion table. [Figure 15] Figure 15 is a table showing an example of an evaluation of promotion planning in on-the-job training (OJT) that sets promotion goals. [Figure 16] Figure 16 is a table showing an example of estimation errors and errors due to corrections (additions and deletions) caused by test bugs. [Modes for carrying out the invention]

[0009] An example of an embodiment of the disclosed technology will be described below with reference to the drawings. In each drawing, identical or equivalent components and parts are given the same reference numerals. Furthermore, the dimensional ratios in the drawings are exaggerated for illustrative purposes and may differ from actual ratios.

[0010] (Assumptions of this embodiment) First, the prerequisites for using the quantitative management system of this embodiment (this embodiment) will be explained. Figure 1 is a conceptual diagram illustrating a quantitative management system based on knowledge information of all things in the universe. As shown in Figure 1, the quantitative management system is used by the user (contractor, client) based on the perspective of knowledge information of all things in the universe (events, things, images, feelings).

[0011] This section explains the concept of quantitative management in this method. The aim of this new quantitative management method is to place quantitative data at the core of operations in all industries, not just software development, so that management and the field staff can work together in unison without disconnection, thereby contributing to business management. In the following example of this embodiment, software development will be used as the subject. In this embodiment, quantitative data refers to "the quantity of the product and the cost per unit quantity." The quantitative management method is to "determine quantitative data by resolving the variable parts (described later) in the higher-level processes of software development." The goal is to contribute to the management of software development by putting quantitative data at the core of all operations, including cost management based on quantitative data, declaration and performance of evaluations based on quantitative data, and management operations based on quantitative data. Furthermore, the research into finding quantitative data for non-quantitative operations will continue as a research topic and will fall under the scope of quantitative management in this method.

[0012] In addressing the variable parts, the departments responsible for promoting improvement and reform within the order placer and the order receiver play a central role. When simulating the variable parts, it is necessary to expand the scope of vision to include all aspects on Earth, from the perspectives of the visible and invisible phenomena ( "things", "objects", "images", "sensations"), and repeat the hypothesis verification. This indicates that the order placer can realize requirements and contribute to society by resolving the variable parts regarding such predetermined perspectives and item information of the business. Also, the order receiver can define the system requirements for realizing the improvement and reform requirements, and by defining the input / output data and processes, can reduce the occurrence of downward flow bugs to the lower processes. As a result, it is possible to define quantities, improve quality, and reduce costs.

[0013] Figure 2 is a conceptual diagram showing an example of the foundation construction method for the order placer and the order receiver in a quantitative management system based on all-encompassing knowledge information. By each of the state or enterprise (order placer) and the software development enterprise (order receiver) conducting hypothesis verification on the premise of all-encompassing knowledge, quantities are defined.

[0014] The state regards the business of protecting its territory, people, and sovereignty as its "main business", and acts as an organization where the Cabinet, ministries and agencies, and other organizations conduct "supporting business", assuming the role of the order placer, and the highest decision-making body is the "Diet (ruling party)". The "government agencies (ministries and agencies, local governments, etc.)" function as the order placer of the state. Supplementary information on the organization of the state is as follows. Examples of the main business and support are given in 1 - 3. Main business 1: Organization for protecting territory / Ministry of Defense, Self-Defense Forces, Japan Coast Guard Management of main business 1: Cabinet Secretariat Territorial and Sovereignty Policy Planning and Coordination Office Main business 2: Organization for protecting people / National Police Agency, Fire and Disaster Management Agency, Ministry of Health, Labour and Welfare Management of main business 2: Cabinet Office Main business 3: Organization for protecting sovereignty / Ministry of Foreign Affairs, Cabinet Secretariat Territorial and Sovereignty Policy Planning and Coordination Office Management of main business 3: Cabinet Secretariat Support 1: Support organization for the business of protecting territory / Ministry of Foreign Affairs, Geospatial Information Authority of Japan Management of support 1: Cabinet Secretariat Support 2: Support organization for the business of protecting people Local governments, medical institutions, welfare facilities Management of Support 2: Supervisory departments of each ministry and agency Support 3: Support organizations for tasks protecting sovereignty / National Diet, Judicial bodies Management of Support 3: Cabinet

[0015] Companies, as organizations with their own "core business" and "support services" such as "general affairs, accounting, information systems, legal affairs, and procurement," play the role of clients, and their highest decision-making body is the "board of directors." Software development companies, on the other hand, play the role of contractors, receiving "orders" from governments and corporations (clients) and making system "development" their "core business."

[0016] Next, we will explain the perspectives (events, things, images, and feelings) of universal knowledge information that are prerequisites for using quantitative management systems. Universal knowledge information is a perspective for understanding things in terms of holistic optimization rather than partial optimization. The categories shown below are examples of classification of universal knowledge information, but if there is knowledge that does not belong to any category, a category can be added to any perspective for consideration.

[0017] "Things" are a perspective based on concrete reality and objective facts. "Things" refer to elements that can be objectively measured and recognized, such as material existence, data, specific systems, and physical laws. Examples include the size of a conference room, the number of participants, the duration of a meeting, sales figures, product specifications, Earth's temperature data, and demographics. A key characteristic is that this type of information is easily targeted for scientific analysis and efficiency improvements, and is generally well-suited for general AI. Examples of the "things" category are shown below. [International] United Nations, borders, treaties, legal systems, customs, languages, geography, distance, time zones, intellectual property rights, technology transfer, Hague Sales Act, Vienna Sales Convention, letters of credit, forward exchange contracts, intercoms [National] Government, Cabinet, Ministry, Local government, Research institute, Research paper [Company] Products, services, sales, profits, factories, research laboratories, sales offices, head office / branch offices, retailers, processes, pollution (company and / or people), research papers [Lifestyle] Weddings and funerals, hiring, resignation, housework, life and death, school enrollment, graduation, joining and leaving a company [Housing] House construction (foundation work, exterior, interior), real estate brokerage, landscaping, planting, condominium management [Professional occupations] Lawyers, patent attorneys, accountants (Individuals often form groups or organizations such as associations to carry out their activities.) [Arts] Music, theater, Noh, Kabuki, Rakugo, Manzai, Circus, Dance, Painting, Sculpture, Ceramics, Calligraphy, Haiku (Individuals often form groups or organizations to engage in activities.) [Schools] Elementary schools, junior high schools, high schools, universities, graduate schools, public schools, private schools, vocational schools, and other types of schools [Social education] Museums, historical archives, libraries [Travel] Inns, hotels, amusement parks, theme parks [Entertainment] Movies, cafes, cabarets, horse racing, bicycle racing, boat racing [Hospital] Medical treatment, midwifery / nursing, therapeutic treatments (massage, acupuncture, moxibustion, judo therapist), dental technology, public health center, quarantine, testing, disinfection, psychiatric hospital, social insurance, social welfare, nursing care [Combined services] Post office, cooperatives (agriculture, fisheries, seafood processing, forestry, business) [Waste] Waste disposal [Maintenance] Automobile maintenance [Repair] Machinery repair (general machinery, construction and mining machinery, electrical machinery and equipment, mounting, furniture, watches, footwear, etc.) [Other business services] Shorthand, word processing, photocopying, building maintenance, security, displays, industrial equipment cleaning, sign painting, call center [Job placement, temporary staffing] [Political, economic, and cultural organizations] [Religion] [Other services] Meeting halls, slaughterhouses, [Foreign government] Foreign embassies and consulates

[0018] "Things" is a perspective based on relationships, processes, and actions. "Things" refer to interactions between "things," processes within a temporal flow, human behavior, or organizational structures. Examples include meeting procedures, decision-making processes, customer communication, supply chain flows, and human work behavior. A key characteristic is that it captures invisible connections and dynamic aspects that change over time, even when looking only at "things." The PDCA cycle is also considered and created from this "things" perspective. Examples of the "thing" category are shown below. [Languages] Japanese, English, Korean, Chinese, French, German, Spanish (languages ​​used by humans to communicate with one another) [Information] A conversion of all things in the universe into units that can be handled by a computer. [Human being] Mind (habits, customs, personality, temperament, willpower, character), body (brain, bones, muscles, tendons, blood, internal organs) (Humans are involved in all things in the universe and are active in all areas.) [Physical properties] Liquid / Solid, Shape (round, square, triangle, etc.), Weight, Odor / Smell, Hardness (properties of the substance) [Standards] ISO, CMMI, JIS, JISA, JAS, [Laws] Constitution, laws, [Intangible property rights] Patents, trademarks, copyrights, [Regulations] Systems, customs, rules [Living things] Plants and animals, fish and shellfish, forests; [Inorganic things] Minerals, gravel, electricity, gas, water, heat; [Buildings] Houses, buildings, gardens, parks

[0019] "Election" is a perspective based on meaning, concept, symbolism, and the overall picture. "Feeling" can be considered to refer to the symbolic meaning of "things" or "events," the larger concept they represent, or the overall structure or pattern. It is a perspective that connects individual parts and deciphers the meaning and patterns behind them. Examples include corporate culture, organizational vision, social norms, design concepts, trends, universal human nature, and the laws of nature. Its characteristic feature is its focus on abstract concepts that are not directly visible, and on capturing patterns and overall picture that only become apparent when multiple "things" or "events" combine. It is a crucial perspective for identifying the "axes" and "planes" of complex systems. Examples of the "elephant" category are shown below. [Meteorology] Typhoons, rain, wind, crust, ocean (handled by government ministries (Japan Meteorological Agency))

[0020] "Sensation" is a perspective based on emotions, feelings, values, and subjective experiences. It refers to subjective and difficult-to-articulate aspects of human beings, such as emotions, personal feelings, aesthetic sense, happiness, ethics, and individual values. Examples include the stress of a crowded train, job satisfaction, customer satisfaction, the feeling of beauty, anxiety, and joy. Its characteristic is that it is a perspective that cannot be fully captured by "things," "events," or "images" alone, and is related to the richness and suffering of being human, as well as the core of ethical judgment. Examples of the "feeling" category are shown below. [Senses] The five senses (sight, hearing, taste, smell, touch (temperature, pressure)), sixth sense, intuition, emotions (the knowledge and information of all things in the universe, dealt with in fields such as medicine)

[0021] The system of this embodiment manages the target of solutions by (higher-level) process, and is divided into process management and quantitative management. The processes include overall design, FuncALL (e.g., functional design specifications), coding, unit testing, block testing, block connection testing, and system testing, and process management and quantitative management are defined for each. Details of process management and quantitative management for each process will be described later after an overview of the configuration and processing flow.

[0022] Based on the above premises, the quantitative control system of this embodiment will now be described.

[0023] (Configuration of this embodiment) Figure 3 is a block diagram showing the functional configuration of the quantitative management system 100 of this embodiment. The quantitative management system 100 is connected via a network N to a user terminal 200 that can be operated by the ordering party and the receiving party. The user terminal 200 accepts various operations related to the acquisition of quantification information. There may be multiple user terminals 200, and they may be terminals operated by the ordering party and the receiving party, respectively. The configuration of each part of the quantitative management system 100 will be described later.

[0024] Figure 4 is a block diagram showing the hardware configuration of the quantitative management system 100. As shown in Figure 4, the quantitative management system 100 includes a CPU (Central Processing Unit) 11, ROM (Read Only Memory) 12, RAM (Random Access Memory) 13, storage 14, input unit 15, display unit 16, and communication interface (I / F) 17. Each component is connected to the others via a bus 19 so as to be able to communicate with each other. These hardware components can reside on a server, but are not limited to a single server; distributed servers in the cloud may be used.

[0025] The CPU 11 is a central processing unit that executes various programs and controls various components. Specifically, the CPU 11 reads a program from the ROM 12 or storage 14 and executes the program using the RAM 13 as a working area. The CPU 11 controls each of the above components and performs various calculations according to the program stored in the ROM 12 or storage 14. In this embodiment, the ROM 12 or storage 14 stores an information processing program. Note that a GPU or the like may be used instead of the CPU 11 depending on the suitability of each process, and an appropriate processing unit may be used depending on the process.

[0026] ROM12 stores various programs and data. RAM13 temporarily stores programs or data as a working area. Storage14 consists of a storage device such as an HDD (Hard Disk Drive) or SSD (Solid State Drive) and stores various programs, including the operating system, and various data.

[0027] The input unit 15 includes a pointing device such as a mouse and a keyboard, and is used for various types of input. The display unit 16 is, for example, a liquid crystal display and displays various types of information. The display unit 16 may also function as the input unit 15 by employing a touch panel system.

[0028] The communication interface 17 is an interface for communicating with other devices such as terminals. For such communication, a wired communication standard such as Ethernet (registered trademark) or FDDI, or a wireless communication standard such as 4G, 5G, or Wi-Fi (registered trademark) may be used.

[0029] (Functional Configuration) Next, the functional configuration of the quantitative management system 100 will be described. The quantitative management system 100 consists of a storage unit 102, a data collection unit 110, a simulation processing unit 112, and a presentation processing unit 114. Below, an overview of each part of the functional configuration will be given, and then the details of the processing content will be explained with examples of configurations.

[0030] The memory unit 102 stores a trained quantification model and setting data (prompts) for inputting instructions to the quantification model regarding the calculation of quantification information. The quantification model can be one in which items considered as candidates for item expansion (described later) are pre-trained for each industry, and predetermined calculation formulas necessary for calculating quantification information are pre-trained. For example, the prompts used in this embodiment can be created to instruct the quantification model to perform calculations based on the process definitions and quantitative management concepts for each process, which will be described later. In this embodiment, the example of using a generative AI model that generates quantification information by inference according to the instructions included in the prompts is explained, but it is not limited to this. Other options include programs that define processing based on training materials, APIs, or setting data. Furthermore, the quantification model itself does not need to be stored in the memory unit 102; an external quantification model may be used, and only prompts and setting data for reference may be stored in the memory unit 102. The memory unit 102 also stores the collected response data (described later) and various data required for processing in each part.

[0031] The quantification model will be trained using training data. The training data will be prepared and used by the system administrator. The training targets are pre-training of candidate items for each industry and calculation of quantification information. Based on the process definitions and quantitative management concepts for each process described later, data will be selected and used for training. Candidate items for item expansion will be pre-trained for each industry. This will allow the quantification model to acquire specific industry knowledge. The training of candidate items for item expansion will be designed to take into account the general knowledge information mentioned above. In addition, pre-training of calculation formulas related to quantification, as described later, will be performed. The system will learn the basic formulas for calculating manufacturing costs, departmental costs, outsourcing costs, and for declared evaluations and performance evaluations, using the prescribed calculation formulas necessary for calculating quantification information. The calculation formulas will be described later. Furthermore, for evaluation among the quantification information, the evaluation criteria table will be applied for training. In evaluation, the system will learn how to determine evaluation points using the evaluation criteria table based on the difference from the standard for individual production volume and unit cost. The learning materials data may be added as needed. The learning materials data may include, for example, business information and learning from predetermined perspectives, assuming the core business, support, and management operations of a company using a quantitative management system, as well as predetermined perspectives. The predetermined perspectives may include, for example, laws, licenses, patents, business knowledge, quality, estimates, process definitions, costs, hardware, software, packages, OSS, processing methods, and databases. Business knowledge refers to knowledge established from past business experience (case studies, lessons learned from failures, tips, methods, etc.).

[0032] The data collection unit 110 collects variable portions of the item information for predetermined viewpoints and tasks (hereinafter, "variable portions" refers to variable portions of the item information for predetermined viewpoints and tasks). The collection of variable portions is performed, for example, by collecting response data from clients and contractors. The item information for viewpoints and tasks includes multiple items classified hierarchically and level items that are combined with the items at each level. Examples of items and level items will be described later.

[0033] The collection unit 110 outputs a list of candidate items for the variable portion to the user terminal 200 and presents it to both the ordering party and the contractor, and prompts them to input response data indicating whether or not the candidate items correspond to the variable portion. The collection unit 110 collects the response data from both the ordering party and the contractor. Furthermore, the collection unit 110 presents the parts in the response data where the answers of the ordering party and the contractor differ, and collects the variable portion by requesting adjustments and approvals from the ordering party and the contractor. The response data collected from both the ordering party and the contractor can be stored in the storage unit 102.

[0034] Here, the variable parts refer to multiple items that are subject to quantification and are determined by an agreement between the client and the contractor. These refer to problems for which there is no definitive solution with current knowledge and technology. By resolving these variable parts in the higher-level stages of software development, the "quantitative" aspects are defined, aiming for quality improvement and cost reduction. The determination of whether or not there are variable parts must be agreed upon between the client and the contractor before the contract is signed. For the client, resolving the variable parts leads to the realization of improvement and reform requests, enabling social contribution. For the contractor, resolving the variable parts defines the system requirements, reduces the occurrence of bugs and unnecessary processes in lower-level stages, and contributes to quality improvement and cost reduction.

[0035] This section explains the method for determining whether or not there are variable parts. This method ensures that the client and the contractor agree on the presence or absence of variable parts in the order and contract. (1) The department with decision-making authority is designated as the "department where the creator with decision-making authority is located" within both the client and the contractor, which will contribute to resolving the variable parts. (2) This is an effort by the client and the contractor to determine whether or not there are variable parts and to find out the reality (truth). Before the contractor accepts the order, there may be disagreements between the contractor and / or the client regarding the determination of whether or not there are variable parts and the reality (truth), so whoever notices this will be responsible for persuading the other party. Mutual trust between the client and the contractor is necessary for cooperation. Both the client and the contractor must decide whether there are "yes (▲)" or "no (〇)" variable parts before the contract is signed. The contractor will determine whether there are "yes (▲)" or "no (〇)" variable parts in the table through an investigation (over a certain period of time). [Table 1] [Table 2]

[0036] Regarding the debate over whether the variable part can be solved or not, if the target system has a variable part and the contractor has the potential to solve it, the client and the contractor should agree in advance on a grace period for determining whether the solution is possible. Based on the contractor's investigation results, the contractor and the client can distinguish between cases where there is a variable part and cases where there isn't, regarding their respective perceptions of "yes (▲)" or "no (〇)". Regardless of whether the project can be accepted or not, the client should agree on a grace period (×× months) for determining whether the solution is solvable or not. Furthermore, if there is a variable part, the cases can be distinguished between cases where the contractor has the potential to solve it and cases where they do not. Table 2 shows the distinction between cases where the solution is solvable or not. "Solvable" means that the contractor has the potential to resolve the variable parts. The client and the contractor will agree in advance on a grace period for determining whether or not the issues can be resolved. "Unsolvable" means that the contractor has no potential to resolve the variable parts. "Resolved" means that there are no variable parts. When the contractor makes a decision on whether or not to accept the project based on the conditions for acceptance or rejection, if it is accepted, it means that the client and the contractor have agreed on the conditions for acceptance or rejection. If it is rejected, it means that the client and the contractor cannot agree on the conditions for acceptance or rejection. The conditions for acceptance or rejection refer to some or all of the following: period, input, output, fee, etc.

[0037] The simulation processing unit 112, as a first process, uses a trained quantification model to perform a simulation by item expansion, which generates hierarchical combinations using items including variable parts and level items, and outputs the item expansion results. The simulation is performed by receiving business information about the ordering party and inputting prompts containing instruction sentences regarding the business information into the quantification model.

[0038] The presentation processing unit 114 presents the item expansion results to the user terminal 200 in a predetermined output format. The output format may be a display on the user terminal 200 or a printout. The presentation processing unit also presents the quantification information output in the second process of the simulation processing unit 112 in a predetermined output format. The presentation processing unit 114 may also propose candidates for quantification based on the presented item expansion results and request input information for the candidates. The presentation processing unit 114 may also output sets of sets where the quantification information did not match, present them to the client and the contractor, and request them to reacquire the input information. The simulation processing unit 112 can reacquire the changed input information for the set from the client and the contractor and recalculate the quantification information for the set. The usage scenario for presentation varies on a case-by-case basis; it may be presented to the client and the contractor simultaneously, or it may be presented separately (asynchronously) to each, and the input information may be reacquired.

[0039] The simulation processing unit 112 performs a second process related to the output of quantification information. The simulation processing unit 112 uses a quantification model to extract combinations of quantifiable items that require quantification from the item expansion results. The quantifiable items that require quantification are combinations related to the variable part. The simulation processing unit 112 obtains input information for the combination of quantifiable items from the user terminal 200, performs calculations, and outputs quantifiable information related to the combination of quantifiable items. The simulation processing unit 112 inputs a prompt to the quantification model that includes an instruction to perform calculations using at least cost information from the input information, and outputs quantifiable information that uses cost information in the calculation based on the inference results of the quantification model.

[0040] In the second process of the simulation processing unit 112, if the quantitative information of the simulation results does not match the pre-set "expected output data (answer)", the hypothesis is repeatedly tested by changing the input information included in the prompt or by restarting the process.

[0041] The presentation processing unit 114 presents the quantified information to the user terminal 200 in a predetermined output format. The output format may be a display on the user terminal 200 or a printout or other format.

[0042] (Variations in functional configuration) In the above functional configuration, when the data collection unit 110 receives a predetermined request for a list of candidate items from the user terminal 200, it may input a prompt containing instructions related to the request into the quantification model and present a list of candidate items. The quantification model is pre-trained to output a list of candidate items for the variable portion, including items from a predetermined higher-level process of the overall design.

[0043] Furthermore, in the above functional configuration, a usage method may be envisioned in which the user terminal 200 can select and specify any range of item expansion results, and the content will be output for confirmation. After the item expansion results are output by the presentation processing unit 114, the collection unit 110 receives a prompt containing an instruction to output content for the specified combination. The simulation processing unit 112 inputs the prompt containing the content output instruction to the quantification model and outputs the content for the specified combination. The presentation processing unit 114 outputs the content for the specified combination. This allows the system to be used as a tool for presenting and confirming the item content of the simulation to stakeholders.

[0044] Furthermore, in the above functional configuration, the presentation processing unit 114 may distinguish between combinations that do not include variable parts and combinations that include variable parts in the output configuration of the item expansion results, and output combinations that include variable parts with an identification method for identification. This makes it easier for the user to understand the variable parts.

[0045] (Process flow) Next, the processing flow of the quantitative management system 100 will be explained. Figure 5 is a flowchart showing the processing flow by the quantitative management system 100. The CPU 11 functions as a part of the quantitative management system 100 to execute the following processes.

[0046] In step S100, the CPU 11 outputs a list of candidate items for the variable portion to the user terminal 200 based on the output of the quantification model, and presents it to both the ordering party and the receiving party.

[0047] In step S102, the CPU 11 receives response data indicating whether or not a candidate item corresponds to a variable portion.

[0048] In step S104, the CPU 11, as its first process, accepts input of business information regarding the ordering party and creates a prompt containing instructions related to the business information. Note that the prompt can be automatically generated in response to the input of business information by creating configuration data for automatic execution.

[0049] In step S106, the CPU 11 inputs the created prompt into the trained quantification model, and performs a simulation using item expansion to generate hierarchical combinations using items including variable parts and level items based on the output from the quantification model, and outputs the item expansion results.

[0050] In step S108, the CPU 11 presents the item expansion results to the user terminal 200 in a predetermined output format.

[0051] In step S110, the CPU 11 uses a quantification model to extract combinations of items from the item expansion results that require quantification.

[0052] In step S112, the CPU 11 obtains input information for the extracted combination of items to be quantified from the user terminal 200. Note that the input information is not limited to being obtained directly from the user terminal 200; the input information may also be stored in the storage unit 102 beforehand and referenced by the user terminal 200.

[0053] In step S114, the CPU 11 creates a prompt that includes an instruction to perform a calculation using at least the cost information from the input information.

[0054] In step S116, the created prompt is input to the quantification model, and the quantification information, which uses cost information in its calculations, is output based on the inference results of the quantification model. The quantification information here includes the identification result, which determines whether the quantification information does not match the expected output data for each combination of items to be quantified.

[0055] In step S118, the CPU 11 presents the quantification information to the user terminal 200 in a predetermined output format. If there are any mismatched pairs for each of the combinations to be quantified, information indicating the mismatch is added to the output format.

[0056] In step S120, the CPU 11 determines for each combination to be quantified whether there are any pairs where the quantified information does not match the expected output data, i.e., whether all pairs match. If there are any pairs that do not match, the process returns to step S112, accepts the input information for the pairs that did not match again, and repeats the processing. If there are no pairs that do not match and all pairs match, the process ends.

[0057] As described above, the quantitative management system 100 according to this embodiment enables comprehensive quantitative management and proposals for diverse needs.

[0058] (Process definition and quantitative control for each process) Next, we will explain the process definitions and quantitative control for each process, and then describe specific examples of simulation processing.

[0059] This section explains the process definition and quantitative management of the overall design. In the process definition of the overall design, in order to realize the customer's requests for improvement and reform of their business operations, when solving problems for which there is no certain solution with current knowledge and technology (hereinafter referred to as "variable parts"), the departments promoting improvement and reform within both the client and the contractor must take the lead in simulating the variable parts, and repeatedly verify hypotheses by broadening the perspective to include all things and phenomena on Earth ("events," "things," "symbols," "feelings"). Business operations refer to the core business and its management operations, as well as support operations and their management operations. Through the resolution of the variable parts, the client can realize the requests for improvement and reform, and ultimately contribute to society. Furthermore, the contractor can reduce the occurrence of bugs that are leaked to lower-level processes by defining the requirements of the system that realizes the requests for improvement and reform, and defining the input / output data and processing. In addition, through the resolution of the variable parts, quantitative measures can be defined, quality can be improved, and costs can be reduced.

[0060] The core business refers to operations that generate profit (national interest for a nation, profit for a company), while the support business refers to operations that support the core business. The management of the core business refers to operations that lead and promote the improvement and reform of the core business, while the management of the support business refers to operations that lead and promote the improvement and reform of the support business. The client refers to a nation or a company (international and / or domestic business organization or organized individual business organization). The contractor refers to a company that develops the system. Regarding departments, in deciding on solutions for variable parts, it is necessary to establish an improvement and reform department to which a creator belongs, with authority that transcends all relevant departments, directly under the highest decision-making body (the National Diet (ruling party) in the case of a nation, or the board of directors in the case of a company). The responsibility of this department is to review the organization, overcome the current obstacles, demonstrate creativity to open up new possibilities, and think through and implement improvements and reforms to the operations of both the client and the contractor without ever giving up. Miscellaneous issues can be identified, for example, by simulation item, for example, using the following methods. (1) Observe how users actually use the product or service, and decipher hidden needs from their actions, expressions, and words. (2) Collaborate with users to brainstorm ideas and co-create new value. (3) Predict future social and technological changes and consider what users will demand in those changes. (4) Exchange opinions with people from different backgrounds to grasp problems from multiple perspectives and generate new ideas. The selection of simulation methods and items will be handled by the improvement and reform department to which the creator belongs. The simulation will be conducted by dividing the system into blocks and using input and output data for each block. A block refers to a set of operations consisting of the core business, the management of the core business, and the support and management of the support. Input and output data refer to data such as databases, screens, reports, and telegrams. Data includes data names (including symbol names) and data types (including significant digits). Sub-processes refer to the processes from FuncALL onwards.

[0061] For quantitative management of the overall design, it is assumed that there are quantitative components for the variable parts, and that each item in the simulation is subordinate to the overall design. Additions and deletions are permitted as needed, depending on changes in the time or circumstances.

[0062] This section describes the process definition and quantitative management for FuncALL. In FuncALL's process definition, the order of blocks, the input data and processing of each block, and the output data (including input / output data names and significant digits) are defined. The main route and subroutine groups for each block and the input / output data for each program are also defined, and instruction-dependent program specifications are created for each development language. It is assumed that programmers can count the number of steps by looking at the instruction-dependent program specifications. However, the following assumptions are made: (1) The contractor is expected to make daily efforts to improve and update the instruction-dependent program specifications that have been defined. (2) The contractor is expected to recognize that the instruction-dependent program specifications that have been defined will contribute to low-code development. For processes where it is expected that ingenuity will be required in the way parentheses, loops, branches, etc. are written, proactive efforts will be made to address and resolve these issues in advance. Furthermore, the following regulations 1 and 2 are established. [Convention 1] Before calling other subroutines, store the loop count (i, j, k, etc.), and restore it when the subroutine returns. Based on the input / output data definitions for each program, test cases and test data definitions are created for testing each individual program. Based on the case distinctions and input / output data for inter-block connections created in the overall design, test cases and test data definitions are created for testing within each block (intra-block testing). [Convention 2] Block input data names (symbols) shall be replaced with our proprietary names during input. During output, the proprietary names shall be replaced with the corresponding data names before output. Based on the case distinctions and input / output data of inter-block connections created in the overall design, test cases and test data definitions for inter-block connections shall be created (inter-block connection tests). Based on the case distinctions and input / output data definitions for the entire system (including connections to other systems) created in the overall design, test cases and test data definitions for the entire system shall be created.

[0063] For quantitative management of FuncALL, the number of steps will be estimated in the instruction-dependent program specification. The standard cost and selling price per step of FuncALL will remain constant.

[0064] This section describes the coding process definition and quantitative management. In the coding process definition, source code is coded based on the instruction-corresponding program specification. If bugs are found during code review, the source code is corrected (deleted and / or added). In quantitative management of coding, the number of steps is defined as the number of instructions; for example, the number of instructions can be counted using a step counting tool. The ratio of comments to the quantity of output: The output should be expressed in a way that allows experienced programmers to correctly estimate the content of the steps, but explanations should be included in the formula at a certain percentage (e.g., 10% or 5% per 50Ks). The standard cost and selling price per coding step will be constant.

[0065] This section explains the process definition and quantitative management of unit testing. The process definition for unit testing includes (1) test data creation (setting actual values), (2) test execution, and (3) test bug fixing. (1) This section explains how to create test data (set actual values). Based on the test cases and test data definitions for the program itself created with FuncALL, set the values ​​of the input data and the corresponding output data (answers). For black-box tests of loops, set the output data to the number of loop iterations for the input data. All cases of branch tests will be performed as white-box tests. Black-box tests will not be performed. The test data values ​​will either be automatically generated using random numbers, or they will be data that is easy to calculate the answer for. [Rules] When there are multiple different data with a common part used in arithmetic operations, using the same data in the common part may result in the same calculation result, so it should not be used (binary 0 and 1 are excluded as they do not have a common part). Example 1: The range of values ​​for data with different data names used in arithmetic operations should not be shared. Example 2: The value of data with different data names used in arithmetic operations should not be set to 0 (this applies when A=B=0 in Example 1 above). (2) The test execution will be explained. Based on the test cases, unit tests will be performed using the corresponding test data. If the test results do not match the configured output data (answer), the following (3) test bug handling will be performed. All test results, including bugs, will be recorded (for the purpose of re-examining the test results later). (3) We will explain how to handle test bugs. Test bug handling includes correction (deletion and / or addition), correction of test data, etc. (the same applies hereinafter). Identify the location where the bug occurs, determine the location to correct, make the correction, and then (2) perform the test. If bugs are found in the input data or output data, correct those as well. The review will be considered a part of the test in advance, and its quantity and cost will be accounted for. A trail of evidence for corrections will be established. Evidence will be something that supports the location and content of the correction, and allows for the counting of the number of steps for correction.

[0066] This section explains the quantitative management of unit tests. (1) Regarding test data creation, the amount of test data depends on the number of instructions in the calculation formula, not on the number of test data items. This is because multiple data items do not go through the same calculation formula simultaneously. In white-box testing, the number of test data items is quantitative. In the case of loops, it is the total number of loop iterations, and in the case of branches, it is the total number of branches. In black-box testing, the number of test data items is quantitative (except for the number of test data items in white-box testing mentioned above). In the case of loops, it is one internal processing case and one loop iteration, and branches are not performed. (2) The amount of testing performed is the number of test cases. (3) The amount of test bug fixes, both for deletion and / or addition, is shown in the number of steps (absolute value) and is recorded for each iteration. The productivity of addition and / or deletion is the same as for coding. The contract declares an upper limit on the amount of bug fixes to the client, and if the amount of bugs exceeds the limit, the portion exceeding the limit will be provided free of charge.

[0067] This section explains the process definition and quantitative control of block testing. The process definition for block testing includes (1) test data creation, (2) test execution, and (3) test bug fixing. (1) This section explains how to create test data. Based on the test cases and test data definitions within the blocks created in FuncALL, set the values ​​of the input and output data and the corresponding output data (answers). (2) The test execution will be explained. Based on the test case, block tests will be performed using the corresponding test data. If the test result does not match the set output data (answer), the following (3) test bug fix will be performed. All test results, including bugs, will be recorded (for the purpose of re-examining the test results later). (3) We will explain how to handle test bugs. Corrections will be made by deleting and / or adding code. We will establish a record of the corrections. The record will be something that confirms the location and content of the corrections, and records that allow us to count the number of steps deleted and / or added.

[0068] This section explains the quantitative management of block tests. (1) For test data creation, the quantity of test data is defined as the number of test data entries. (2) The quantity of tests performed is defined as the number of test cases. (3) For test bug fixes, both deletions and / or additions are recorded as steps (absolute value). The productivity of additions and / or deletions is assumed to be the same as that of coding.

[0069] The process definition and quantitative control for block connection testing are the same as for block testing.

[0070] This section explains the process definition and quantitative management of system testing. The process definition for system testing includes (1) test data creation, (2) test execution, and (3) test bug fixing. (1) This section explains how to create test data. Based on the creation of test cases and definition of test data for the entire system (including connections to other systems) created with FuncALL, set the values ​​of the input and output data and the corresponding output data (answers). However, if data is received from the client, use that data. (2) The test execution will be explained. Based on the test cases, system tests will be performed using the corresponding test data. If the test results do not match the configured output data (answer), the following (3) test bug fix will be performed. All test results, including bugs, will be recorded (for the purpose of re-examining the test results later). (3) We will explain how to handle test bugs. Corrections will be made by deleting and / or adding. However, if data is received from the client, the overall design will be reviewed. A trail of evidence for corrections will be established. The trail will be something that confirms the location and content of the correction, and a record that can count the number of steps deleted and / or added.

[0071] This document explains the quantitative management of system testing. (1) Regarding test data creation, the quantity of test data shall be the number of test data entries. However, if data is received from the client, it shall be counted separately. (2) The quantity of tests performed shall be the number of test cases. However, if data is received from the client, it shall be counted separately. (3) The quantity of test bug fixes shall be recorded in terms of the number of steps (absolute value), both for deletion and / or addition. The productivity of addition and / or deletion shall be the same as that of coding.

[0072] (Budget and actuals management) Next, we will explain budget management. Figure 6 is an example of a table summarizing budget management for review bugs or test bugs.

[0073] This document explains the budgeting and actual management of the amount of deletions and additions based on review bugs. The scope of review includes the program specifications and source code for the main route and subroutine groups ((1) function systems, (2) loop processing groups, (3) branch (branching processing) groups, and (4) customized parts for the contractor and / or cooperating companies in the OS, cloud, package, and open software), with instructions corresponding to the development language. The location of the review bug is identified, and the corresponding part is deleted or added. The amount and cost of deletions and additions based on review bugs are budgeted and managed monthly, separately for each detected process, target product, company, and deletion / addition. The planned amount of deletions and additions based on review bugs is calculated using the following formula. (Formula) Planned amount of deletions and additions based on review bugs = Estimated amount of bugs - Actual amount of deletions and additions based on bugs at the time of review completion (Formula) Estimated bug quantity = Target product quantity per detection process (review) × Bug rate of the corresponding target product in the bug rate table

[0074] The actual amount of deletions and additions based on review bugs will be zero immediately after creation, and will refer to the actual amount up to the first time. The cost of deletions and additions based on review bugs will be the responsibility of the source of the bug. The company is the company to which the person responsible for creating the product under review belongs (the contractor or cooperating company). However, in the case of delivery, there may be multiple companies responsible for the same product, so all companies responsible for that product will be included in the aggregation.

[0075] This section explains the budget-versus-actual management of deletions and additions based on test bugs. The location of the test bug is identified, and deletions and additions are made at those locations. The quantity and cost of deletions and additions based on test bugs are managed monthly, broken down by test process, target product, company, and deletion / addition. The planned quantity of deletions and additions based on test bugs is calculated using the following formula. (Formula) Planned amount of bug removal and addition based on test bugs = Estimated amount of bugs - Actual amount of bug removal and addition based on bugs at the time of review completion immediately before testing - Actual amount of bug removal and addition based on bugs at the time of test completion

[0076] For estimated bug counts, as well as actual amounts of bugs deleted and added upon review completion, refer to the above-mentioned bug budgeting and management guidelines.

[0077] The actual amount of deletions and additions based on completed test bugs is zero before the start of testing, and after the start of testing, it refers to the amount up to that point. The cost of deletions and additions based on test bugs is the responsibility of the source of the bug. The company is the company to which the person responsible for creating the product under test belongs (the contractor or cooperating company). However, in cases such as deliveries, there may be multiple companies responsible for the same product, so all companies responsible for that product will be included in the aggregation.

[0078] Regarding the bug rate by process, (1) the bug rate immediately after the creation of the product is as shown in the bug rate table below. This assumes that no reviews are performed in any subsequent lower-level processes. (2) The bug detection rate immediately before testing, and (3) the remaining bug rate immediately before testing. [Table 3]

[0079] (Simulation of the variable part) Regarding the simulation, we will explain (1) the items of the work (including level items) and their combinations, (2) the items of the simulation (including level items) and their combinations, and (3) the simulation method.

[0080] (1) Items of work (including level items) and combinations thereof To organize the tasks to be included in the simulation, the following symbols are used to indicate the items of each task to be included. Main occupation: bi(1≦i≦n) Main job management: bai (1≦i≦n) Support: sj (1 ≤ j ≤ m) Support management: sgj (1 ≤ j ≤ m) The level of performance for each task is indicated by the following symbols. Main occupation: bi(α)(1≦i≦n,1≦α≦γ) Main job management: bai(α)(1≦i≦n,1≦α≦γ) Support: sj(β)(1≦j≦m,1≦β≦δ) Support management: sgj(β)(1≦j≦m,1≦β≦δ) Since the maximum value of each level item differs depending on the task, the maximum values ​​of each level item are shown below. Main occupation: γ=f(bi) Main job management: γ=g(bai) Support: δ = φ(sj) Support management: δ = Θ(sgj)

[0081] The simulation targets the business items × level items for each item (for convenience of explanation, the signed items will be simply referred to as levels). The formula is as follows. Table 4 below summarizes the case for the main business. The same applies to the management, support, and support management of the main business. Since there are cases where the items of each business are combined, these will also be included in the simulation. Table 5 below summarizes the items for the case of the main business. The same applies to the management, support, and support management of the main business. Note that there is no correlation between the levels bi(α) of item bi and they are treated as independent; if there is a correlation, it will be elevated to an item. [Table 4] [Table 5]

[0082] The following applies to bi1(α1) to bin(αn). bi1(α1): The level of item bi1 α1 (1≦α1≦γ(=f(bi1)) bi2(α2): The level of item bi2 is α2 (1 ≤ α2 ≤ γ (= f(bi2))). bi3(α3): The level of item bi3 is α3 (1 ≤ α3 ≤ γ (= f(bi3)) bii(αi): The level of item bii is αi (1≦αi≦γ(=f(bii))). bin(αn): The level αn of item bin (1 ≤ αn ≤ γ (= f(bin)))

[0083] (2) Simulation items (including level items) and their combinations The simulation applies the simulation items (including level items) and their combinations to the business items (including level items) and their combinations as described in (1) above.

[0084] The simulation items are indicated by the following symbols. Simulation item: dp(1≦P≦ψ) The simulation items dp are as follows. Details of each item will be described later. d1: Corporate strategy, market strategy (client and / or contractor) d2:Laws d3: Patent d4: Business Knowledge d5: Hardware and software d6: Package, open software d7: Processing method and data design d8: Software created by another company (input / output data) d9: Restoration of existing specifications d10:Quality characteristics d11: Estimate d12~d∞: For additional items

[0085] There exists a level item q (1≦q≦ω) for the simulation item dp. The symbols are as follows: Level item of the simulation item: dp(q) (1≦p≦ψ, 1≦q≦ω)

[0086] For the table showing the level items for each item dp, simply replace the symbol bi with dp and bi(α) with dp(q) in the table showing the level items for each item bi in Table 4 above. For the formula for calculating the number of combinations of level item dp(q) based on the number of combinations of item dp, simply replace the symbol bi with dp and bi(α) with dp(q) in the formula for calculating the number of combinations of level item bi(α) based on the number of combinations of item bi in Table 5 above.

[0087] (3) Simulation method [1] The combinations used in the simulation can be found in Table 5 (and the Table of Alternatives to Table 5) above for the main business. The same applies to the management, support, and support management of the main business. [2] Select valid items from the business item bi and simulation item dp and define them as block bi. Invalid items are block bi that do not have a variable part and simulation item dp that is unrelated to the variable part. [3] Simulate as a block (see "Simulation by Block" below). That is, simulate the processing of the input data and simulate the combination until you can obtain the output data (answer). [4] For all combinations selected from Table 5 (and the Table of Reinterpretations of Table 5) above, perform the process in [3].

[0088] This section explains block-based simulation. In block-based simulation, output data to various terminals and / or auxiliary storage devices is defined as the output data (answer) for block BI. Input data from various terminals and / or auxiliary storage devices for the output data is input into the block-specific block BI processing (pre-developed section, main route, and subroutine group). The simulation is repeated until the output data of the relevant processing (conditional branching, calculation formula) is output to the specified terminal and / or auxiliary storage device and matches the output data (answer) to the various terminals and / or auxiliary storage devices defined earlier. The calculation formula includes perform (calls, loops) and movement. If the calculation and output data match, the block BI simulation is terminated. However, termination is determined based on agreement with the client. Note that terminals and / or auxiliary storage devices include the company's own and / or cloud service terminals and / or auxiliary storage devices (databases, etc.).

[0089] (A) Verification of input / output data and processing for combinations of block / level and simulation item / level. Figure 7 shows examples of combinations of (dp(q)) and bi(α). The input / output data and processing (IPO) for each combination are shown in the table in Figure 7. The combinations are combinations of block-specific / level-specific bi(α) and simulation item-specific / level-specific dp(q).

[0090] (B) Verification of input / output data and processing for combinations of block / level and simulation item / level. Figure 8 shows examples of combinations of bi(α) and nCi. These are combinations of block-specific / level-specific bi(α) combinations nCi (1≦i≦n) and simulation item-specific / level-specific dp(q) combinations ψCp (1≦p≦ψ). The input / output data and processing (IPO) for these combinations are shown in the table in Figure 8.

[0091] (C) Processing of the target system within block Figure 9 shows an example of the time series of processing within a block. The processing within the block is divided into a main root program (m) and a group of subroutines (s), and the program-specific input / output data is derived from the block's input / output data. m and s are as follows. m1, m2, ...mm...mq...my: Main route program by time series s1: Branch Sub s2: Input Sub s3: Repeat sub sn: Main processing sub so: Repeated sub-processing within the main body mdbio: File Input / Output Sub

[0092] (Contents and explanation of simulation items) The following are examples of simulation items for the variable portion.

[0093] (1) Corporate Strategy, Market Strategy (Client and / or Contractor): Based on the client's requirements, confirm whether the software development contributes to improving the quality of the goods or services offered to the market and / or differentiating the contractor from competitors at a reasonable cost. Also, confirm whether the software development contributes to improving the quality of the contractor's own products or services and / or differentiating the contractor from competitors at a reasonable cost.

[0094] (2) Laws and Regulations: Confirm whether the client's requirements need to be reviewed in order to revise, amend, or comply with laws and regulations related to the client's requirements. (Items i) to ii) below are for reference only). i) Revision, amendment, and compliance with laws and regulations ii) Revision, modification, and compliance with intellectual property rights (patents, copyrights)

[0095] (3) Patents: We will confirm whether the client's requirements need to be reviewed due to patent infringement, disputes, or contractual (friendly or hostile) issues related to the client's requirements (i) to ii) below are for reference only). i) Examine the technical scope and scope of rights of competing licensed patents to avoid patent infringement and resolve patent disputes. ii) License agreement (friendly or hostile)

[0096] (4) Business Knowledge: Based on the client's requirements, input and output data necessary for new business knowledge will be added, taking into account improvements and reforms to the current business knowledge. Business knowledge refers to knowledge established from past business experience to achieve business objectives (case studies, lessons learned from failures, tips, methods, etc.). The extracted data will have its data type and number of significant digits defined as follows: i) to iii). Data type refers to the classification of data processed by the program based on its calculation, operation, and purpose of use. i) Input / output data in input / output media (screens, reports, etc.) and input / output with other systems (Internet, telegrams, etc.) ii) Data held in storage media (files, databases, etc.) based on the input / output data and processing described in i) above. ii) Data being calculated in progress within the program during processing based on the input / output data and data held on the storage medium described in i) and ii) above (see notes on handling significant digits)

[0097] (5) Hardware and software Based on the client's requirements, and incorporating improvements and reforms to existing hardware and software, limit tests will be conducted using the input / output data listed in (4) Business Knowledge above to address the temporal, physical, and usage constraints of the hardware and software, and to resolve any usage constraints. This will include understanding the differences between the production and development environments of the target system. Hardware includes servers and / or general-purpose OS (platforms), cloud, disks (HD / SSD, CD / DVD, USB, etc.), memory, networks, and terminals (PCs, ATMs, convenience store terminals, smartphones, IC cards, business terminals, IoT terminals, surveillance cameras, connected cars, network-controlled factory equipment and robots, etc.). Software includes open source, development languages, RDBMS, AI, security tools, ChatGPT, Large-Scale Language Models (LLM), development frameworks, server and network virtualization technologies, etc. For databases (RDBMS), simulations at the following levels are required based on the client's requirements. [1] Criteria for separating the functionality of databases and applications [2] Data model (normalization, indexing, data types) and SQL statement optimization [3] Performance (response time, throughput, scalability (e.g., increasing data volume)) [4] Tuning (cache, disk I / O bottleneck, connection leak, lock contention) [5] Backup (Yes (Full, Differential, Incremental), No), Recovery (Restore, Recovery, Roll Forward) [6] Cloud (multi-cloud, on-premises, hybrid)

[0098] (6) Packages and Open Software: Based on the client's requirements, the initial costs, operating costs, and maintenance costs of the proposed packages and / or open software will be estimated to reduce the user's expenses (estimated until the end of the system's lifespan, and within budget). The costs will also be estimated to increase due to adverse events resulting from the constraints and prerequisites of the above-mentioned packages and / or open software. Estimates will be made not only at the time of initial implementation but also each time revisions are made (within budget).

[0099] (7) Processing Method and Data Design: Based on the client's requirements, a new processing method and data design will be formulated, taking into account improvements and reforms to the current processing method and data design. Data design will include the time series of input and output (occurrence timing such as ms, seconds, minutes, hours, days, weeks, months, and years), format (visual, data structure, database, DWH, data lake, etc.), capacity, transmission medium (USB, internet, etc.), storage medium (flash memory, HDD, SSD, etc.), retention period (temporary storage, permanent storage, etc.), management policy (quality, security, privacy, etc.), transfer to other systems, and evacuation and recovery in the event of a disaster. Processing methods will include online processing, batch processing, centralized processing (mainframe), distributed processing (cloud), and interactive processing (immediate processing (synchronous), waiting for processing completion (asynchronous)).

[0100] (8) Software created by other companies (input / output data): Based on the client's requirements, the exchange of input / output data with software created by the client's partner company shall be confirmed and finalized. Furthermore, confirmation and finalization shall be made each time the other party's system is changed (provided it is within budget).

[0101] (9) Reconstruction of existing specifications: Based on the client's requirements, the transfer of input and output data with the existing system will be confirmed and finalized. Furthermore, confirmation and finalization will be made each time the other system is changed (provided it is within budget). Reconstruction of existing specifications will involve reconstructing the program specifications corresponding to the instructions from the source code, regardless of whether the specifications exist or not.

[0102] (10) Quality Characteristics: The quality shall meet the required quantity based on the client's requirements. The quality quantity refers to the quantity of the following quality characteristics: Product quality (especially security and performance), quality during use, and data quality. However, since many of these qualities are undefined, the quantities will be defined through future quantitative research. In order to further improve the quality of the target system, measures will be taken to extend its lifespan (service life) by implementing means to mitigate failures and strengthening equipment.

[0103] (11) Estimate: An estimate including variable parts will be prepared each time a simulation is run, and compared with the client's budget. This estimate, along with the quality characteristics, will be used to determine whether the simulation can be completed.

[0104] The above explanation uses an example that assumes simulation items for the main business; therefore, we will provide supplementary explanations regarding simulation items for management. The simulation items dp for management are as follows: d1: Process definition and quantitative control d2: Cost d3: Rating d4: Work / Daily Total d5: Resource allocation d6: Education / OJT d7: Estimate, contract d8: Procurement support, outsourcing management d9: Examination d10: Operation d11: General Affairs d12: Meeting d13: Management report d14: External common MS d15~d∞: For additional items

[0105] (1) Process definition and quantitative control: Based on the background and rationale of the constraints on the standard values ​​of quantitative measurements in the process, we will identify challenges that allow us to discover the creators (see examples below). A1) Establishment of domestic standards for system development organizations, and establishment of a unified development process definition and development environment within the country. A2) Quantification of quality characteristics A3) Method for generating all data structures required by the system. A4) Expand the data we incorporate as quickly as possible to keep up with changes in the demands for improvement and reform, and speed up the revision and abolition of those demands accordingly. ⇒ Reforms and improvements such as automating the modularization mechanism of the program structure that follows ⇒ Reforms and improvements such as automation of normalization of tracking databases and creation of index structures. A5) Automation of a mechanism to perfectly restore or create system specifications. ⇒ Reverse engineer the instruction-dependent specification document (which is useful for low-code development) from the existing source code. ⇒Standard version with specifications independent of system differences ⇒ A standard version of the code system that is independent of system differences (including significant digits, etc.) A6) Standardization of the criteria for counting the number of steps ⇒ Standardize the method for measuring the amount of system source code, as well as the units of measurement for that amount. ⇒ Standardize the measurement method and units for quantities other than the system's source code (JCL, tables, etc.) (currently this is a manual process). A7) Standardization of programming languages ​​in conjunction with the unification of program structures (targeting industrial programming only, excluding private programming) ⇒ Unifying the modular structure of the program, such as branching and looping. ⇒Match the number of system cases with the number of test cases. A8) Automating test data ⇒Automatic generation of test data according to the number of system cases ⇒Automatic generation of test results (answers) ⇒Automatic deletion of data that should not be used as test data (such as identical data in the common parts of different data used in arithmetic operations). A9) Automating the review process ⇒ A method that pre-empts some of the test cases. A10) Automation of test results ⇒ A method to obtain evidence of the same number of modifications as the test cases. A11) Method for counting the number of steps in modifications (deletions and additions) ⇒ Show the number of correction steps (absolute value) and account for each iteration. Collect and analyze the productivity of additions and deletions separately. A12) Establish evidence of the modifications. Evidence is evidence that supports the content and location of the modifications, and that allows for the counting of the number of steps deleted and added. A13) Establishment of quantities for each process and cost based on those quantities. ⇒ The basis for assuming a constant cost per unit quantity in the lower-level processes (FuncALL, CD, UT), the quantity, and the method of collecting costs based on that quantity. ⇒ Establishment of a method for collecting costs based on quantity in processes other than those mentioned above.

[0106] (2) Cost (details below): Based on the standards for costs that should not be charged to clients in the software industry, we will identify problems that creators can discover (see examples below). B1) Publicly known costs that should not be charged (costs that do not produce goods) ⇒ Cost difference based on the number of scheduled working days per month ⇒ Cost difference due to overtime work ⇒ Costs corresponding to the excess amount exceeding the agreed-upon margin of error with the client (estimate error, error due to bugs) ⇒ Paid leave, special leave, and costs incurred due to other reasons (lateness, leaving work early, leaving work early) B2) Publicly known expenses that should not be charged (expenses that do not produce a product) ⇒ Travel expenses, transportation expenses, communication expenses (telephone charges, fax charges, postage stamps, postcard costs), machine line usage fees, dispatch contract fees, purchasing expenses, inspection fees, rental fees, water and electricity costs, cleaning and common area maintenance fees, lease fees, equipment and fixture costs, repair costs, depreciation expenses, machine line usage fees, insurance premiums, meeting expenses, book printing costs, consumables costs, transportation and storage costs, taxes and public charges, training expenses, etc. B3) Establishing the quality of costs to be billed and formalizing the system. ⇒Verification of cost quality based on the contribution of various procedures and tools used in the production process to the finished product.

[0107] (3) Evaluation (details below): Based on the quantitative evaluation criteria for development personnel in the software industry, we will identify challenges that creators can discover (see examples below). C1) Quantifying the evaluation of personnel responsible for intangible management and processes (overall design including variable parts, system testing). ⇒ Prototyping, evaluation, and refinement of measurement methods for output (results, effects, etc.) whose quantity is not visible.

[0108] (4) Work hours and daily records: We will identify issues that creators can discover regarding the work hours and daily records of development personnel in the software industry (examples below). D1) Standardize the accounting method for daily totals of personnel responsible for intangible management and processes (overall design including variable parts, system testing), taking into account the dependency relationships of daily total items. ⇒ Prototyping and refining of measurement methods for output (results, effects, etc.) whose quantity is not visible. (5) Resource allocation: We will identify challenges in constructing a resource allocation method that discovers creators and places them in an environment where they can be utilized. ⇒ Establishment of domestic standards for system development organizations, and establishment of unified development process definitions and development environments within Japan. (6) Education and On-the-Job Training: We will identify challenges in building an education and on-the-job training program that discovers and nurtures creators.

[0109] (7) Estimates, contracts [Quotation] We will identify the challenges in developing a system for discovering creators and placing them in an environment where they can be utilized, and then agreeing on a quotation with the client. ⇒When accepting an order, if the contractor has the potential to resolve any variable aspects, the contractor should agree in advance with the client on a grace period before deciding that the issue cannot be resolved. ⇒Efforts to identify any variable parts will be carried out by the department on the contractor's side that has the authority to make decisions, in cooperation with the client, and the results of these efforts will be agreed upon by both the client and the contractor. ⇒If unresolved issues are found in the variable parts during the lower-level processes (FuncALL, CD, UT), the work on the variable parts of the overall design will be restarted. [Contract] We will identify the challenges in developing a system for establishing contracts with clients to discover creators and place them in an environment where they can be utilized. ⇒Even though it's a quasi-mandate contract, it's important to ensure the creator's environment is secure. For example, eliminating time constraints, physical constraints, and constraints on the development environment. ⇒In the case of the environment to which the creator belongs, a lump-sum contract should not be used.

[0110] (8) Procurement support and outsourcing management: Identify challenges in establishing a system to which the client and cooperating companies agree to discover and place creative individuals in an environment where they can be utilized. ⇒In the case of a cooperating company that employs more creators than contractors, it is important to ensure a supportive environment for the creators. For example, eliminate time constraints, physical constraints, and constraints on the development environment.

[0111] (9) Inspection: In the inspection of products based on process definition and quantitative control, the creator shall identify any issues that can be discovered (see examples below). ⇒ Examination of the simulation method for the variable portion (comprehensiveness and validity of dependency relationships) (10) Operation: In the interactions between the system operations department and other departments, identify issues that can be discovered by the creator (see examples below). ⇒ Proposing constructive solutions to resolve conflicts between related departments in system operation. (11) General Affairs: In general affairs, identify problems that can be discovered by the creator (see examples below). ⇒ Consolidation and streamlining of general administrative matters, checking the skills of the person in charge.

[0112] (12) Meetings: The goal is to identify challenges that creators can discover during meetings (see examples below). ⇒ Consolidation and streamlining of meetings, establishment of a method for predicting cost-effectiveness in advance (in principle, whether meetings can be avoided). (13) Management reports: Management reports should identify problems that can be discovered by the creator (see examples below). ⇒ Consolidation and streamlining of management reports, establishment of a method for predicting cost-effectiveness in advance. (In principle, whether management reports can be eliminated.) (14) External Common MS: In the external common MS, identify problems that creators can discover (see examples below). ⇒ Establishment of a system that surpasses external standardized management systems (using our own unique methods as an alternative to ISMS, PIMS, EMS, QMS, and CMMI)

[0113] An example of item expansion in the simulation is explained. Figure 10 shows an example of expanding the item expansion table from the first to the third order. Note that there is no correlation between the levels bi(α) of item bi and they are considered independent. If there is a correlation, it is elevated to an item and further detailed. When the item expansion table is expanded from the first to the second to the third order, ... the number of items can be expressed by the following formula. Σ(i=1~n)(α=1~θ(i))bi(α)× Σ(α=1~θ)(β=1~μ(iα))biα(β)× Σ(β=1~μ)(γ=1~λ(iαβ))biαβ(γ)×...

[0114] The expansion is complete when the data types and significant digits used by the system are determined. When performing a simulation, it is necessary to consider the dependencies between items, so combinations of table items are used.

[0115] The scope of item development includes operations (core business, core business management, support, support management) and simulation items (variable portion, management), in the combinations shown in the table below. However, management includes not only core business management and support management, but also management of core business management and support management. Furthermore, the variable portion also exists in support. Therefore, the scope shown in the table below is as follows: [1] to [4]. [Table 6] The simulations include: [1] simulation of the variable portion of the core business, [2] simulation of the management of the core business, [3] simulation of the variable portion of the support, and [4] simulation of the management of the support.

[0116] Figure 11 shows an example of item breakdown for software development tasks. Figure 12 shows an example of how to hierarchically refine combinations of tasks (requirements) using an item breakdown table, using financial operations as an example. Figure 13 shows an example of how to hierarchically refine simulation items for variable parts using an item breakdown table. Figure 14 shows an example of how to hierarchically refine simulation items for management using an item breakdown table.

[0117] As described above, the simulation processing unit 112 performs the calculations. In the simulation processing unit 112, the constraints on the prompt item expansion are set so that the scope of the hierarchical item expansion is to be n-th order hierarchically, and each of the level items combined with the n-th order expanded items is set to be each of the n+1-th order expanded items. As constraints on the prompt calculation, the calculation data is aggregated for the n+1-th order expanded combinations and calculations are performed for the n-th order expanded combinations to calculate quantitative information for the combination of quantification targets at each level. Furthermore, the first-order items of the nth order are set to be a combination of items related to the variable portion of the core business, items related to management of the core business, items related to the variable portion of support, and items related to management of support.

[0118] (Details of cost, valuation, and control) We will explain the details of cost, valuation, and control.

[0119] (Cost price) (1) Manufacturing cost: The manufacturing cost CCt for a given production quantity Vt at a given time t is determined by the following formula, using the cost per unit quantity Ct. Cct = Vt × Ct

[0120] [Standard Manufacturing Cost Cs] Standard manufacturing cost Cs is the cost required to produce a standard quantity V0, and can be calculated by multiplying it by the standard unit cost C0. Cs (yen) = CO (yen / amount) × V0 (amount)

[0121] The standard manufacturing cost Cs will be used as the cost basis for calculating the invoice amount to the ordering party. The units of V0, C0, and quantity will be based on empirical values ​​for each process. In the testing process, empirical values ​​will be used for each work item: test data creation, test execution, and test bug fixing. The purpose of defining empirical values ​​is to improve the accuracy of costs and to improve and reform the activities that form the basis of costs. For example, the quantity and cost of each process in the contractor's past software development projects can be compiled, and the standard production quantity and standard cost unit price for each process can be determined using these standard production quantities and standard cost unit prices. The quantity and cost based on that process can then be estimated.

[0122] Regarding the contract: When receiving an order for a system with variable parts in the overall design process, and for system testing, a quasi-mandate contract (contract price per hour or per month) will be concluded. System testing involves the contractor and the client (a cooperating company contracted separately by the client). Sub-processes will be under a lump-sum contract (unit price per unit quantity per process), and will remain at a fixed amount (unit price per unit quantity per process × quantity created) for any system unless the price is lowered or raised. Regarding errors in estimation and errors in corrections (additions and deletions) due to test bugs, an upper limit (δ%) will be set for estimation errors, and any sales price exceeding this limit will be free of charge. The corresponding cost will not be considered a manufacturing cost, but rather the cost of the headquarters responsible for estimation, "manufacturing department expenses". Regarding errors in corrections (additions and deletions) due to review bugs and test bugs, an upper limit (ε%) will be set for both additions and deletions, and any sales price exceeding this limit will be free of charge. The corresponding cost will not be considered a manufacturing cost, but rather a "development department expense," which is the cost of the department responsible for creating the program that was corrected based on review bugs and test bugs.

[0123] [Standard Production Volume V0] The standard production volume V0 is determined by the production volume Vt at a certain time point t, according to the following formula. The equation on the left, Vt = V0 + {±α(t)} × V0, is Vt = V0(1±α(t)). V0: Standard production volume (quantity) ±α(t): The rate of increase or decrease in quantity refers to the rate of increase or decrease in quantity based on the following items (a), (b), and (c). A) This refers to the percentage increase or decrease in quantity resulting from the following increases or decreases in (1)-(3) that should be accounted for in the manufacturing division. (1) Percentage change in quantity relative to standard production volume V0 due to monthly day difference (2) There is no increase or decrease due to differences in overtime pay rates. (3) There is no increase or decrease due to exceeding the upper limit of the estimate error. (Including the estimate error from outsourcing) B) This refers to the percentage increase or decrease in the quantity resulting from the increase or decrease in the following (1) which should be accounted for by the development department. (1) There is no increase or decrease due to exceeding the upper limit of bug tolerance. (Including bug tolerance from outsourced work) C) General administrative expenses and activities related to expenses do not generate products relative to manufacturing costs, and therefore are not included in increases or decreases in production volume.

[0124] [Standard Quantity Cost Unit Price C0] The standard quantity cost unit price C0 is determined by the cost per unit quantity Ct at a certain point in time t, using the following formula. Ct = C0 + {±β(t)} × C0 The above equation can be rewritten as Ct = C0(1 ± β(t)). C0: Standard unit cost (yen / quantity) Cs: Standard cost; manufacturing cost of standard production volume V0 ±β(t): The rate of increase or decrease in cost per unit is the rate of increase or decrease in cost based on the following items D), E), and F). D) This refers to the percentage increase or decrease in costs resulting from the following increases or decreases in (1) to (3) that should be recorded as manufacturing department expenses. (1) Percentage change of monthly daily cost ΔCm relative to standard cost Cs (2) Percentage change of the variance cost ΔCUz relative to the standard cost Cs (3) Percentage increase or decrease of the cost exceeding the upper limit of the estimation error relative to the standard cost Cs (including outsourcing estimation error costs) E) This refers to the following cost increase / decrease rates that should be recorded as development department expenses. (1) Percentage increase or decrease of the cost exceeding the upper limit of bug error relative to the standard cost Cs (including outsourced bug error costs) F) General and administrative expenses and other costs are not included in the cost of goods sold.

[0125] [Time Cost Unit Price] The time cost unit price CUt (yen / h) at a given time t is determined by the following formula, using the production time Ht (h) and the quantity cost unit price Ct relative to the production quantity Vt (quantity). CUt(yen / hour) = (Vt / Ht)(amount / hour) × Ct(yen / amount) The hourly cost unit price CUm (yen / h) at a certain end of the month m is determined by the following formula, using the production time Hm (h) and the quantity cost unit price Cm relative to the production quantity Vm (quantity). CUm (yen / hour) = (Vm / Hm) (amount / hour) × Cm (yen / amount)

[0126] [Standard Time Cost Unit Price Cus] The standard time cost unit price CUs (yen / h) at a certain end of the month m is determined by the following formula, using the standard manufacturing time H0 (h) and the standard quantity cost unit price C0 for the standard production quantity V0 (quantity). CUs(yen / hour) = (V0 / H0)(amount / hour) × C0(yen / amount) Furthermore, the standard hourly cost unit price CUs is calculated by dividing the standard monthly salary by the standard number of hours per month. See the formula below. CUs=Ks÷Hms Hms: Standard number of hours per month

[0127] [Standard Monthly Salary Ks] The standard monthly salary Ks is determined using the base salary and the number of bonus months, according to the following formula. Ks = K × {1 + (Bm ÷ 12)}, K: Basic salary = Basic wage determined based on age and years of service. Bm: Number of months of bonus (Bonus = Total of salary paid several times a year in addition to basic salary = K × Bm)

[0128] [Monthly Standard Hours Hms] The monthly standard hours Hms are determined using the standard number of days in a month and the prescribed working hours per day, according to the following formula. Hms = Dms × Ls DMS: Standard number of days per month Ls: Standard working hours per day (usually 8 hours) [Monthly Standard Days Dms] The monthly standard days Dms are calculated by dividing the annual standard number of days by the number of months, 12. Dms = Dys ÷ 12 Dys: Standard number of days per year = 240 days (Determined based on the number of scheduled working days over the past 10 years and relevant laws and regulations)

[0129] As described above, the simulation processing unit 112 performs the calculations. In the simulation processing unit 112, the units of quantity for each product are used as quantification indicators for calculating the manufacturing cost. The constraints on the cost information of the prompts include instructions to calculate at least the predetermined manufacturing cost, departmental costs for the predetermined department, and outsourcing costs using learned calculation formulas. The instructions for calculating the manufacturing cost include the calculation of standard manufacturing cost, standard production volume, standard unit cost per unit of quantity, unit cost per unit of time, standard unit cost per unit of time, standard monthly salary, standard monthly hours, and standard monthly days, using learned calculation formulas. The standard manufacturing cost is calculated using predetermined empirical values ​​for each process as the unit of quantity, and the volume increase / decrease rate used in calculating the standard production volume is calculated considering the volume increase / decrease rate associated with the increase / decrease that should be recorded by the manufacturing department and the development department, respectively.

[0130] This section explains the breakdown and main costs of each cost category. Labor costs are broken down into manufacturing costs, manufacturing department costs, and development department costs. Manufacturing department costs include (1) monthly day variance costs, (2) overtime pay rate variance costs, and (3) costs exceeding the upper limit of the estimation error.

[0131] (1) Monthly variance cost: In the case of a monthly salary system, the monthly salary amount (standard monthly salary Ks) is constant, but the number of scheduled working days (Dm) varies from month to month. Therefore, the hourly cost per unit (CUm) for that month (m) differs from the standard hourly cost per unit (CUs). Accordingly, the monthly variance cost (ΔCm) based on this is not included in the manufacturing cost, but is recorded as "manufacturing department expenses". As a result, this cost is excluded from the manufacturing cost that forms the basis of the invoice amount. The monthly daily cost variance ΔCm is calculated using the following formula. ΔCm = Ks × (ΔDm ÷ Dms) ΔDm = Dm - Dms Ks: Standard monthly salary Dm: Monthly scheduled working days DMS: Standard number of days per month ΔDm: Monthly difference in scheduled working days

[0132] (2) Overtime pay rate variance cost: The variance cost (ΔCUz) between the cost unit price (CUz) obtained by adding the overtime pay rate (Rz) to the number of overtime hours (Lz(Rz)) and the cost obtained by applying the standard time cost unit price (CUs) to the same hours is recorded as "manufacturing department expenses" rather than manufacturing costs. As a result, this cost is excluded from the manufacturing costs that form the basis of the invoice amount. The time-based overtime pay rate variance cost ΔCz is calculated using the following formula. ΔCz = Σ(CUz - CUs) × Lz(Rz) CUs: Standard time cost per unit CUk: Time-based cost per unit CUk = K ÷ Hm K: Basic salary Hm: Monthly scheduled working hours CUz: Unit price with premium wage rate added. CUz = CUk × (1 + Rz) Lz(Rz): Number of overtime hours by premium pay rate Rz: Overtime pay rate The following examples illustrate the cases z=1 to z=5. Time-based overtime pay rate variance cost ΔCz ΔC1 = (CU1 - CUs) × L1 (R1) ΔC2 = (CU2 - CUs) × L2(R2) ΔC3 = (CU3 - CUs) × L3 (R3) ΔC4 = (CU4 - CUs) × L4 (R4) ΔC5 = (CU5 - CUs) × L5 (R5) Time-based cost per unit CU1 = CUk × (1 + R1) CU2 = CUk × (1 + R2) CU3 = CUk × (1 + R3) CU4 = CUk × (1 + R4) CU5 = CUk × (1 + R5)

[0133] The daily overtime pay rate variance cost is the daily sum of the time-of-day overtime pay rate variance cost ΔCz. The monthly overtime pay rate variance cost is the monthly sum of the daily overtime pay rate variance cost.

[0134] (3) Costs exceeding the upper limit of estimation error: Costs corresponding to the amount exceeding the upper limit of estimation error agreed upon with the client at the time of contract shall be waived. An upper limit of δ% shall be set for estimation errors, and any sales price exceeding this limit shall be waived. The costs corresponding to the waived amount shall not be considered manufacturing costs, but rather the costs of the manufacturing division responsible for the estimation. For estimation errors in variable parts of overall design and system testing, and estimation errors in FuncALL and coding, costs exceeding the upper limit of δ% set at the time of contract shall be waived. δ shall be set at a certain level and shall be determined at the time of the estimation contract.

[0135] Development department costs include (1) costs for exceeding the bug error limit. Costs corresponding to the excess error limit for corrections (additions and deletions) due to review bugs and test bugs in unit tests, as agreed with the client at the time of contract, will be free of charge. For corrections (additions and deletions) due to review bugs and test bugs, an upper limit (ε%) will be set for both additions and deletions, and any sales price exceeding this limit will be free of charge. The costs corresponding to the free portion will not be considered manufacturing costs, but will be considered the costs of the development department responsible for creating the program corrected due to review bugs and test bugs. ε will be set at a certain level and will be determined at the time of the estimate contract.

[0136] Outsourcing costs include outsourced manufacturing costs, outsourced estimation error costs, and outsourced bug error costs. General and administrative expenses include the cost of holidays, lateness, early departure, and time off. Expenses include costs not included in manufacturing costs.

[0137] (evaluation) (1) Quantitative evaluation: The target processes are FuncALL, CD (coding), and UT (unit testing). Evaluation will be conducted monthly based on both declared and actual results. This is because there are monthly day variances as described in the cost section above. Quarterly and annually, the evaluation will be based on the cumulative monthly evaluation points.

[0138] [Basic Evaluation Formula] The evaluation at a given time point t is determined by the difference between the individual production quantity Vit and the standard production quantity V0, and the difference between the individual cost unit price Cit and the standard cost unit price C0, according to the evaluation criteria table. Vit - V0 = (±αi(t)) × V0 Cit - C0 = (±βi(t)) × C0 ±αi(t): The difference rate obtained by adding the increase or decrease due to individual i to ±α(t) at the [standard production quantity V0] of the cost. ±βi(t): The difference rate obtained by adding the increase or decrease in the unit cost due to individual i to the ±β(t) in the [standard unit cost C0] of the cost.

[0139] The manufacturing cost CCit of individual i at a given time t is determined by the following formula, using the individual unit cost Cit for the individual production quantity Vit. CCit=Vit×Cit=V0(1±αi(t))×C0(1±βi(t))=Cs+V0×{C0×(±βi(t))}+{V0×(±αi(t))}×C0+{V0×(±αi(t))}×{C0×(±βi(t))}

[0140] Therefore, the manufacturing cost difference ΔCCit for individual i at a certain point in time t is given by the following equation. ΔCCit = CCit - Cs [Declaration Evaluation] In the monthly declaration evaluation (assuming t=m), individual i declares their own production quantity Vdim and unit cost Cdim for the monthly manufacturing cost difference ΔCCim. Production volume based on individual i's declaration at the beginning of the month m: Vdim = V0(1 ± αdi(m)) Cost per unit based on the declaration of individual i at the same point in time m: Cdim = C0(1 ± βdi(m)) ±αdi(m): The percentage difference between the declared output of individual i and the standard output V0 at the beginning of the month (m). ±βdi(m): Difference rate from the standard unit cost C0 of the unit cost based on the declaration of individual i at point m.

[0141] The manufacturing cost CCdim for the quantity Vdim produced based on the declaration of individual i at the time of declaration (monthly point in time m) is determined by the following formula, using the unit cost Cdim based on the declaration. CCdim=Vdim×Cdim=V0(1±αdi(m))×C0(1±βdi(m))=Cs+V0×{C0×(±βdi(m))}+{V0×(±αdi(m))}×C0+{V0×(±αdi(m))}×{C0×(±βdi(m))}

[0142] Therefore, the manufacturing cost difference ΔCCdim for individual i at the time of declaration is as follows: ΔCCdim = CCdim - Cs

[0143] The evaluation score at the time of declaration is determined based on the evaluation criteria table, using the difference rate ±αdi(m) between the production volume based on individual i's declaration at the beginning of the month m and the standard production volume V0, and the difference rate ±βdi(m) between the unit cost based on individual i's declaration at the same time m and the standard unit cost C0. The value of these values ​​is determined based on whether they are <0, =0, or >0. [Table 7] The interpretations of α and β in the above evaluation criteria table at the end of the month and the end of the fiscal period are as follows: [Table 8]

[0144] For the testing process, evaluation points are calculated for each work item in accordance with the above, and these points are aggregated to determine the evaluation score for that testing process. The evaluation score for an individual's monthly declared evaluation is determined by weighting and aggregating the evaluation points for each process according to the unit cost per process. For both the FuncALL process and the testing process, evaluation points are calculated for each work item in accordance with the above, and these points are aggregated to determine the evaluation score for that process. The evaluation score for an individual's monthly declared evaluation is determined by weighting and aggregating the evaluation points for each process according to the unit cost per process.

[0145] [Performance Evaluation] Monthly performance evaluations are conducted by determining the difference rate between individual i's monthly production volume Vrim and the standard production volume V0, and the difference rate between individual i's monthly production cost unit price Crim (calculated by dividing individual i's monthly production cost Ccrim by the monthly production volume Vrim) and the standard production cost unit price C0. Based on these results, evaluation points are determined according to the evaluation criteria table.

[0146] Calculate the difference rate ±αri(m) between individual i's monthly production volume Vrim and the standard production volume V0. Monthly production volume of individual i at the end of the month: Vrim The percentage difference between individual i's monthly output at the end of the month (m) and the standard output (V0): ±αri(m) = (Vrim-V0)÷V0

[0147] The monthly production cost per unit for individual i, Crim, is calculated by dividing individual i's actual monthly manufacturing cost CCrim by the monthly production volume Vrim. Actual monthly manufacturing cost performance of individual i at the same time point m: CCrim Monthly cost per unit for individual i: Crim = CCrim ÷ Vrim

[0148] Calculate the difference rate ±βdi(m) between individual i's monthly cost unit price Crim and the standard cost unit price C0. ±βri(m) = (Crim - C0) ÷ C0

[0149] The monthly performance evaluation score is determined based on the evaluation criteria table, using the difference rate ±αri(m) between individual i's monthly actual production volume Vrim and the standard production volume V0, and the difference rate ±βri(m) between individual i's monthly cost unit price Crim and the standard cost unit price C0, respectively, depending on whether these values ​​are <0, =0, or >0.

[0150] The difference between declared and actual performance for individual i in a given month m shall not be analyzed by calculating the difference between the declared evaluation score and the actual evaluation score, but rather by analyzing and evaluating the difference in production volume and cost per unit. Individual i's evaluation score at the end of the month shall be determined based on the evaluation criteria table, by subtracting the difference rate of declared evaluation from the difference rate of actual evaluation for production volume and cost per unit, and determining whether the resulting value is <0, =0, or >0 for each.

[0151] ◇Subtract the difference rate ±αdi(m) of declared monthly production from the difference rate ±αri(m) of actual monthly production to calculate the difference rate Δαi(m) of declared monthly production. Δαi(m)=αri(m)-αdi(m) (3 ways: Δαi(m)<0, Δαi(m)=0, Δαi(m)>0) ◇Subtract the difference rate ±βdi(m) of the declared monthly cost unit price from the difference rate ±βri(m) of the actual monthly cost unit price to calculate the declared-actual difference rate Δβi(m) of the monthly cost unit price. Δβi(m)=βri(m)-βdi(m) (There are three possibilities: Δβi(m)<0, Δβi(m)=0, and Δβi(m)>0)

[0152] Performance evaluation of worker (i) at the end of the period: The annual evaluation score for individual i is determined based on the evaluation criteria table, by calculating the annual total of the deviation rate of performance evaluations and determining whether the value is <0, =0, or >0.

[0153] ◇The annual calculation of the monthly production volume deviation rate Δαi(m) from declared production volume to actual production volume will be performed. Δαi(y) = ΣΔαi(m) (3 ways: Δαi(y)<0, Δαi(y)=0, Δαi(y)>0) ◇Perform an annual calculation of the monthly volume cost unit price deviation rate Δβi(m). Δβi(y) = ΣΔβi(m) (There are three possibilities: Δβi(y)<0, Δβi(y)=0, and Δβi(y)>0)

[0154] (2) Evaluation of the overall design and the variable parts of ST Budget management will be conducted monthly, annually, and in the medium to long term, based on declarations and actual results. When a plan is declared, a hypothesis will be created and approved by the "department where the creator with decision-making authority is located," and a review period approved by the client will be set. Actual results will be categorized into estimation errors, invalid results, and reservations, and will be handled as follows. If the estimation error exceeds the limit, the cost exceeding the limit will be recorded in "Manufacturing Department Expenses" (see Cost). If it is anticipated during the work that the review period accepted by the client will be exceeded, an extension request will be discussed with the client. Invalid - If monthly results cannot be accepted, it will be considered invalid. Reserved - If there is a prospect of concrete results, it will be reserved. Individual evaluation: Evaluate the value of the results or effects.

[0155] (3) Evaluation of management: Budget management will be conducted on a monthly, annual, and medium- to long-term basis, based on declarations and actual results. When declaring plans, a theme will be set and a review deadline will be set that is approved by the "department where the creator with decision-making authority is located". Actual results will be categorized into estimation errors, invalid, and reserve, and will be handled as follows, requiring approval from the "department where the creator with decision-making authority is located".

[0156] Estimation Error: If the estimation error exceeds the limit, the cost exceeding the limit will be recorded in "Manufacturing Department Expenses" (see Cost). If it is anticipated that the accepted review period will be exceeded during the work, an extension request will be discussed. Invalid / Monthly results cannot be accepted, so it will be considered invalid. Reserved / If there is a prospect of concrete results, it will be reserved. Management items will be described later. Individual evaluation: Evaluate whether the participant contributed to the creator's discovery through the given theme.

[0157] As described above, regarding departmental costs in prompts, instructions to calculate manufacturing departmental costs may include calculations of monthly day variance costs, overtime pay rate variance costs, and costs exceeding the upper limit of estimation error using learned formulas. Instructions to calculate development departmental costs may include calculations of costs exceeding the upper limit of bug error.

[0158] Furthermore, the quantification model can be pre-trained with predetermined evaluation indicators as quantification information. The simulation processing unit 112 can input prompts to the quantification model that include instructions to perform calculations using the evaluation indicators, and perform quantitative evaluations for predetermined functional specifications, coding, and testing processes for the aforementioned items related to the business.

[0159] For the evaluation of the quantification of the simulation processing unit 112, it is possible to include a declared evaluation and a performance evaluation using a learned calculation formula. As a basic evaluation formula for evaluating the declared evaluation and the performance evaluation in the calculation formula, for the evaluation at time t, the difference from the standard production volume V0 of the individual production volume Vit and the difference from the standard unit cost C0 of the individual unit cost Cit are used to determine the evaluation points according to a predetermined evaluation criteria table.

[0160] (Management) Since there is also the content described above regarding the management items, supplementary matters will be explained. As the simulation items of management (management items), items related to setting up an environment for the next strategy towards realizing further improvement and reform by finding issues that can discover creators are exemplified.

[0161] (1) Supplementary explanations are made regarding process definition and quantitative management. In a process where standards for unit quantity and cost based on quantity are defined, based on nine combinations of planned - actual differences and planned - actual of the quantity of products, improvements and reforms are made to the standards of unit quantity and cost based on quantity and the products. In a process where only the cost standard is defined, nine differences between the declared and actual costs are analyzed, and improvements and reforms are made to the accounting method having a combination of the subordinate relationships of the declared and actual items. (2) Supplementary explanations are made regarding cost. Based on nine combinations of planned - actual differences by cost item and planned - actual of the calculation basis of the cost item, improvements and reforms are made regarding the accounting of development department costs and manufacturing department costs. (3) Supplementary explanations are made regarding evaluation. Evaluation is performed based on nine combinations in process definition and quantitative management, and target setting is performed for the evaluated person. (4) Supplementary explanations are made regarding labor and daily records. Regarding labor, pay attention to the following matters so that manufacturing department employees can perform normal labor (actively engage in work by exerting physical and mental efforts), and improvements are made based on statistical processing. - Annual number of days of paid leave, reasons for trends (outstanding days) - Annual number of days of abnormal leave (absenteeism, lateness, etc.), reasons for trends (outstanding days) - Annual number of days of other holidays (special holidays, refreshment holidays, etc.), reasons for trends (outstanding days) Regarding the daily schedule, certify the production volume and the man-hours required for production for each project, process, company, and product. For both in-house and external (in the case of subcontracting), certify the production volume and the man-hours required for production for each individual and product. The certification is based on a declaration according to each standard for the volume and the cost based on the volume. (Planned and actual) volume shall refer to "Process Definition by Process". Since the volume of the overall design is a research topic, the overall design shall be only man-hours. Each data layout of the daily schedule shall be designed so that it can identify factors such as for each purpose, ensuring the accuracy of corrections, etc., and the validity, invalidity, and reservation of evaluation results. For management and variable parts, check the dependency of input items and identify (valid, invalid, reserved) evaluation results. The following table is an example of how to represent the dependency of input items and the identification of results.

Table 9

[0162] The number of combinations of dependencies is nCr. n: total number of items, r: number of items with dependencies. The dependencies are defined for the entire company. The checks during input shall be as follows. → Is there any input error in the dependencies? → Is the total value of items with dependencies the maximum value excluding invalid parts?

[0163] (5) Supplement regarding resource allocation. Resource allocation means promoting the improvement and reform (including the discovery of creators) of resources for management and / or the core business in software development projects, and accumulating the improvement and reform as this time's portion while achieving project goals. The improvement and reform of resources shall be combined with this time's portion and the previously accumulated portion as a new this time's portion at the start of the next project. By repeating this, the improvement and reform of resources are continued. Although it targets projects, the improvement and reform of resources are also continued in the company's management and / or core business. Among them, creators discover creators.

[0164] (5-1) Regarding human resources, we define creators and intellectuals. Creator: A person who, in order to achieve the company's purpose and goals, relentlessly thinks through and implements improvements and reforms in the company's core business, support operations, and their respective management. Intellectual 1: Able to support creators and has above-average productivity compared to Intellectual 2. Intellectual 2: Productivity is standard Intellectual 3: People other than those mentioned above The skills of Intellectual 1, Intellectual 2, and Intellectual 3 are as described above, and their individual future plans (position, field of work (management, development)) are also set. For the field of knowledge, simulation items for the variable portion and simulation items for management can be referenced. (5-2) The company's operations shall be understood as its core business, support services, and the management of each. The items and levels of operations shall be defined, and the number of cases, man-hours, and volume shall be determined.

[0165] (5-3) Resource allocation refers to reviewing the allocation of resources (hereinafter referred to as "resource ij") in item i and level ij of the business details in (5-2) and promoting improvement and reform. Departments requesting resources will request resources according to resource ij. Departments providing resources will provide resources according to resource ij. The "department where the creator with decision-making authority is located" will take measures for resource allocation to promote improvement and reform based on the above. Resources refer to the following items: - Personnel (creators or intellectuals), evaluation (quantity, cost), number of people, input / output, start and end dates, man-hours and cost, work location, work style, software, hardware, and other equipment used. [Table 10] The following is an explanation of the symbols used for personnel in the table. kr; Types of personnel (k0; Creator, k1; Intellectual 1, k2; Intellectual 2, k3; Intellectual 3) n_kri; Quantity of kr (0 ≤ r ≤ 3) in department i n_krj; Quantity of kr (0 ≤ r ≤ 3) in department j Furthermore, even if k0 is transferred to any other department, kr(1≦r≦3) will never be the case. kr(1≦r≦3) may change, albeit slightly, when k0 is transferred to another department.

[0166] (6) I will add some information about education. (6-1) Education: Through the implementation of an educational system based on our fundamental principles, we will identify creative individuals and cultivate employees who will collaborate with them to drive improvement and reform. [Basic Stance] The top management adheres to altruism rather than self-interest, is composed primarily of creative employees, and strives to improve and reform the company and the industry by demonstrating leadership. (6-2) On-the-Job Training (OJT): There are two types of OJT: one with promotion goals and another with skill development goals. Figure 15 is a table showing an example of an evaluation of promotion planning in on-the-job training (OJT) that sets promotion goals. In OJT with promotion goals, performance against the training goals is evaluated upon project completion, and each individual's skills are determined. When resource allocation is planned, promotion goals are set based on each individual's declaration. Upon project completion, each individual's promotion planner (see table below) evaluates performance against the promotion goals and determines each individual's position. The period is set as the start date and the date of goal achievement (including OJT). In OJT with skill improvement as the goal, training goals are set based on each individual's declaration when resource allocation is planned. Teacher / student training goals (example) are set. For example, if the teacher is a creator (evaluator) and the training goal is knowledgeable person 1 => creator, the student is asked to solve creative problems, and it is determined whether they can become a creator. Teacher: knowledgeable person 1 (field A) / training goal: knowledgeable person 1 (field B) => knowledgeable person 1 (field A) is an example where the fields of knowledge are different.

[0167] (7) Provide additional information regarding estimates and contracts. (7-1) Estimate: The variable parts of the target system shall be identified in accordance with the following i) and ii), and based on agreement with the client. Subsequently, if any unresolved issues are found in the variable parts during lower-level processes (FuncALL, CD, UT), the work shall be restarted from the variable parts of the overall design. (i) When placing an order for a system that will receive an order or may receive an order, if there is a possibility that the order recipient can resolve the variable part, an agreed-upon grace period with the order placer shall be set in advance until a decision of irresolvability is made. (ii) Regarding the determination of the presence of variable parts and the efforts to find the substance (truth), the department with the decision-making power on the order recipient side shall conduct it together with the order placer, and the results of the efforts shall be agreed upon by the order placer and the order recipient. (7-2) Contracts: When placing an order for a system with variable parts in the overall design process and in the case of system testing (testing involving the order recipient and the order placer (cooperating companies separately contracted by the order placer)), a subcontract (contract price, hourly rate or monthly rate) shall be concluded. The lower-level processes shall be lump-sum contracts (unit price per unit quantity of each process), and as long as there is no price reduction or increase for any system, it shall be a fixed amount (unit price per unit quantity of each process × quantity produced). Figure 16 is a table showing an example of errors due to estimation errors and corrections (additions and deletions) due to test bugs. The amount exceeding the estimated upper limit shall be the cost of the manufacturing department (manufacturing department expenses), and the amount exceeding the upper limit of the correction error due to review bugs and test bugs shall be the cost of the development department (development department expenses).

[0168] (8) Supplementary remarks on procurement support and subcontract management. Based on the evaluation forms for each process (FuncALL, CD, UT) used in the in-house evaluation, set up an evaluation form for each process for each cooperating company. At the completion of the contract, evaluate the performance of each process for each cooperating company. For the overall design process and the processes from block testing to system testing, it shall be a subcontract, and set the evaluation at the start of the contract for the employees of the cooperating companies participating in the overall design process. At the completion of the contract, evaluate the performance of the employees of the cooperating companies.

[0169] (9) Supplementary remarks on inspections. Based on process definition and quantitative management, conduct inspections that cover the following. - Inspection of the declaration of the deadline until the existence of variable parts is confirmed and compliance with the declaration - Inspection of the declaration of the grace period until a decision of irresolvability is made in the case of variable parts and compliance with the declaration - Inspection of the method for setting the items and levels of simulation of variable parts - Examination of selection methods based on combinations including the dependencies of simulation items in the variable portion. - Daily reports of production volume and man-hours by process (FuncALL, CD, UT) are compared with actual production (to detect miscalculations due to collusion within teams on-site, or intentional or arbitrary miscalculations by individuals).

[0170] (10) Additional information regarding operation. Based on the communication between the system operations department and other departments, and considering the role of the system operations department, identify changes in the system (the operations department refers to the system operations department and / or the business operations department). (10-1) Role of the System Operations Department - Stable system operation (prompt response to system failures, implementation of system maintenance work, system monitoring) - System improvement (monitoring and improving system performance, analyzing system failures and formulating measures to prevent recurrence, and introducing system operation tools) - Security measures (monitoring and analysis of security logs, application of security patches, implementation of security education and training) - User support (handling inquiries regarding system usage, reporting the situation to users in the event of a system failure, and providing education and training on system usage) (10-2) Communication between the system operations department and other departments - Requests issued by the Systems Operations Department to other departments →Introduction and development of new systems, modification and addition of functions to existing systems, extension of operating hours, and response to failures. → System operation status reports, incident reports, creation of various operational documents, and implementation of education and training. - Requests made by other departments to the system operations department → Rapid identification of the cause of system failures and implementation of recovery work, investigation of the scope of impact and reporting of the situation to relevant parties, analysis of the cause of the failure and formulation of measures to prevent recurrence. →Perform routine system maintenance, version upgrades and patch applications, and make or add system settings. → Monitoring system operation status and detecting anomalies, monitoring and improving system performance, monitoring security logs and detecting threats

[0171] (11) Regarding general affairs, tasks that do not involve improvements or reforms to the company's administrative processes will be handled by employees with the skills of Knowledge Person 3. (12) Meetings shall be held regularly (daily, weekly, monthly, quarterly, semi-annually, after the financial results, etc.) or as needed. Meetings shall be held to identify areas for improvement and reform. (13) Management reports shall be used on a regular basis (daily, weekly, monthly, quarterly, semi-annually, at the end of the fiscal year, etc.) or as needed. Reports shall be used to identify improvements and reforms, or to confirm the results of improvements and reforms. (14) External common management systems (ISO, ISMS, PIMS, EMS, QMS, CMMI, etc.) should be reviewed for improvement and reform purposes.

[0172] Furthermore, the technology disclosed herein is not limited to the embodiments described above, and various modifications and applications are possible without departing from the spirit of this invention.

[0173] Furthermore, although the present specification describes an embodiment in which the program is pre-installed, it is also possible to provide the program stored on a computer-readable recording medium. [Explanation of Symbols]

[0174] 100 Quantitative Management Systems 102 Storage section 110 Collection Department 112 Simulation Processing Unit 114 Presentation Processing Unit 200 user terminals

Claims

1. A quantitative management system including an acquisition unit, a simulation processing unit, and a presentation processing unit, The aforementioned collection unit collects variable portions of information regarding predetermined perspectives and work items concerning the ordering party and the contractor. The aforementioned perspective and business item information includes multiple items classified hierarchically and level items that are combined with those items at each level, and also includes multiple items created to hierarchically detail the combination of business requirements for each industry. The aforementioned variable portion is a plurality of items subject to quantification, which are determined by an agreement between the ordering party and the contractor. The trained quantification model has, as part of its item expansion training, pre-trained combinations of item information that are candidates for item expansion for each industry, and is trained to expand each of the simulation items for the core business and the simulation items for management, and as part of its quantification information calculation training, it has pre-trained predetermined calculation formulas necessary for calculating quantification information, including manufacturing costs, departmental costs, and basic evaluation formulas for predetermined evaluations. The simulation processing unit uses the quantification model to perform a simulation by item expansion, generating hierarchical combinations of the items including the variable portion and the level items for items corresponding to the industries of the ordering party and the receiving party, and outputs the item expansion results. The item development results include multiple item development tables that hierarchically show the combinations of business requirements in the simulation items for the main business and the combinations of simulation items for management, and the item development table for the simulation items of the variable portion. The presentation processing unit presents the item expansion results to the ordering party and the receiving party in a predetermined output manner. The simulation processing unit uses the quantification model to extract combinations of quantifiable targets that require quantification from the variable portion of the item expansion result, obtains input information used to calculate the quantifiable information for the combination of quantifiable targets from the ordering party and the receiving party, calculates the quantifiable information using the input information, and outputs the quantifiable information for the combination of quantifiable targets. The presentation processing unit presents the quantified information in a predetermined output manner, and outputs the sets of quantified information that did not match, and presents them to the ordering party and the receiving party. The simulation processing unit further retrieves the modified input information for the set from at least one of the ordering party and the receiving party, recalculates the quantitative information for the set, and repeats the retrieval and recalculation until there are no more sets with discrepancies. Quantitative management system.

2. The collection unit presents a list of candidate items for the variable portion to the ordering party and the contractor, respectively, and has the ordering party and the contractor input response data indicating whether or not the candidate items correspond to the variable portion, and collects the response data. The collection unit collects the variable portion by presenting the parts in the response data where the responses of the ordering party and the receiving party differ, and by requesting adjustments and approvals from the ordering party and the receiving party to determine the variable portion. The quantitative control system according to claim 1.

3. The quantitative management system according to claim 1 or 2, wherein the collection unit proposes candidates for the items to be quantified based on the presented item expansion results and requests the input information for the candidates.

4. The quantification model uses a generative AI model that generates predetermined data through inference in accordance with instructions included in the prompt. The simulation processing unit receives the input of business information relating to the ordering party, inputs the prompt containing the instruction statement relating to the business information into the quantification model, and outputs the item expansion result based on the inference result of the quantification model. The quantitative management system according to claim 1 or 2, wherein the simulation processing unit inputs the prompt, which includes an instruction to perform calculations using at least cost information, to the quantitative model, and outputs the quantitative information using the cost information in the calculation based on the inference results of the quantitative model.

5. As a constraint on the item expansion of the prompt, the scope of the hierarchical item expansion is to expand hierarchically to the nth level. Each of the level items combined with the items in the nth-order expansion is considered to be each of the items in the (n+1)th-order expansion. The quantitative management system according to claim 4, wherein, as a constraint condition for the calculation of the prompt, the quantitative information is calculated for each layer of the combination of the target to be quantified, by aggregating the calculation data for the combinations that have been expanded by the (n+1)th order and performing calculations for the combinations that have been expanded by the nth order.

6. The quantitative management system according to claim 5, wherein the nth-order first-order item is a combination of the item of the variable portion related to the main business, the item of management related to the main business, the item of the variable portion related to support, and the item of management related to support.

7. The quantitative management system according to claim 4, wherein the constraints on the cost information of the prompt include an instruction to calculate at least a predetermined manufacturing cost, departmental costs relating to the costs of a predetermined department, and outsourcing costs using the learned calculation formula.

8. In calculating the aforementioned manufacturing costs, units of quantity or man-hours for each product are used as quantitative indicators. The instructions for calculating the aforementioned manufacturing costs include the calculation of standard manufacturing costs, standard production quantities, standard unit costs per quantity, hourly unit costs, standard hourly unit costs, standard monthly wages, standard monthly hours, and standard monthly days, using the learned formulas. The aforementioned standard manufacturing cost shall be calculated using predetermined empirical values ​​for each process as the unit of quantity. The quantitative management system according to claim 7, wherein the rate of increase or decrease in quantity used in calculating the standard production quantity is calculated taking into account the rate of increase or decrease in quantity associated with the increase or decrease to be recorded by the manufacturing department and the development department, respectively.

9. The quantitative management system according to claim 7, wherein, with respect to the departmental costs, the instruction for calculating the manufacturing departmental costs includes calculating monthly day variance costs, overtime pay rate variance costs, costs exceeding the upper limit of estimation error, and costs exceeding the upper limit of bug error, using the learned calculation formula.

10. The quantification model has predetermined evaluation indicators learned in advance as quantification information. The quantitative management system according to claim 4, wherein the simulation processing unit inputs the prompt, which includes an instruction to perform calculations using the evaluation index, to the quantitative model, and performs a quantitative evaluation of the items related to the business with respect to predetermined functional specifications, coding, and predetermined testing processes.

11. The evaluation of the quantification includes a declared evaluation and an actual evaluation using the learned calculation formula, The quantitative management system according to claim 10, wherein, as the basic evaluation formula for evaluating the declared evaluation and actual evaluation in the calculation formula, for the evaluation at time t, the evaluation score is determined by a predetermined evaluation criteria table using the difference between the individual production quantity Vit and the standard production quantity V0, and the difference between the individual cost unit price Cit and the standard cost unit price C0.

12. The quantification model is pre-trained to output a list of candidate items for the variable portion, including items from a predetermined higher-level process of the overall design. The quantitative management system according to claim 4, wherein when the collection unit receives a predetermined request for the list of candidate items, it inputs the prompt including an instruction statement relating to the request into the quantitative model and presents the list of candidate items.

13. After the item expansion result is output by the presentation processing unit, the collection unit receives the prompt which includes a content output instruction to output the content of the specified combination. The simulation processing unit inputs the prompt, which includes the instruction statement for content output, to the quantitative model and causes it to output the content of the specified combination. The quantitative management system according to claim 4, wherein the presentation processing unit outputs the contents of the specified combination.

14. The quantitative management system according to claim 1, wherein the presentation processing unit, in the output configuration of the item expansion result, distinguishes between combinations that do not include the variable portion and combinations that include the variable portion, and outputs the combinations that include the variable portion with an identification method for identification.

15. The processor, We collect information on the ordering party and the contractor, including any changes in the specified perspectives and itemized information of the work, The aforementioned perspective and business item information includes multiple items classified hierarchically and level items that are combined with those items at each level, and also includes multiple items created to hierarchically detail the combination of business requirements for each industry. The aforementioned variable portion consists of multiple items subject to quantification, which are determined by an agreement between the ordering party and the contractor. The trained quantification model has, as part of its item expansion training, pre-trained combinations of item information that are candidates for item expansion for each industry, and is trained to expand each of the simulation items for the core business and the simulation items for management, and as part of its quantification information calculation training, it has pre-trained predetermined calculation formulas necessary for calculating quantification information, including manufacturing costs, departmental costs, and basic evaluation formulas for predetermined evaluations. Using the trained quantification model, a simulation is performed using item expansion to generate hierarchical combinations of the items including the variable portion and the level items for the items corresponding to the industry of the ordering party and the ordering party, and the item expansion results are output. The item development results include multiple item development tables that hierarchically show the combinations of business requirements in the simulation items for the main business and the combinations of simulation items for management, and the item development table for the simulation items of the variable portion. The results of the item expansion are presented in a predetermined output format. Using the quantification model, the combination of quantifiable targets that require quantification is extracted from the item expansion results, input information used to calculate the quantifiable information for the combination of quantifiable targets is obtained from the ordering party and the receiving party, the quantifiable information is calculated using the input information, and the quantifiable information for the combination of quantifiable targets is output. The quantified information is presented in a predetermined output format, and sets of quantified information that do not match are output and presented to the ordering party and the receiving party. Furthermore, the system retrieves the modified input information for the set from at least one of the ordering party and the receiving party, recalculates the quantified information for the set, and repeats the retrieval and recalculation until there are no more sets with discrepancies. An information processing method in which a computer performs the processing.

16. The processor, We collect information on the ordering party and the contractor, including any changes in the specified perspectives and itemized information of the work, The aforementioned perspective and business item information includes multiple items classified hierarchically and level items that are combined with those items at each level, and also includes multiple items created to hierarchically detail the combination of business requirements for each industry. The aforementioned variable portion consists of multiple items subject to quantification, which are determined by an agreement between the ordering party and the contractor. The trained quantification model has, as part of its item expansion training, pre-trained combinations of item information that are candidates for item expansion for each industry, and is trained to expand each of the simulation items for the core business and the simulation items for management, and as part of its quantification information calculation training, it has pre-trained predetermined calculation formulas necessary for calculating quantification information, including manufacturing costs, departmental costs, and basic evaluation formulas for predetermined evaluations. Using the trained quantification model, a simulation is performed using item expansion to generate hierarchical combinations of the items including the variable portion and the level items for the items corresponding to the industry of the ordering party and the ordering party, and the item expansion results are output. The item development results include multiple item development tables that hierarchically show the combinations of business requirements in the simulation items for the main business and the combinations of simulation items for management, and the item development table for the simulation items of the variable portion. The results of the item expansion are presented in a predetermined output format. Using the quantification model, the combination of quantifiable targets that require quantification is extracted from the item expansion results, input information used to calculate the quantifiable information for the combination of quantifiable targets is obtained from the ordering party and the receiving party, the quantifiable information is calculated using the input information, and the quantifiable information for the combination of quantifiable targets is output. The quantified information is presented in a predetermined output format, and sets of quantified information that do not match are output and presented to the ordering party and the receiving party. Furthermore, the system retrieves the modified input information for the set from at least one of the ordering party and the receiving party, recalculates the quantified information for the set, and repeats the retrieval and recalculation until there are no more sets with discrepancies. An information processing program that instructs a computer to perform a task.

Images