Software development support apparatus, method thereof, and program

Abstract

To provide a software development support device for sequentially setting design specifications of a downstream process corresponding to a model element (indicating a concrete procedure or the like) of software from design specifications (indicating a rough function or the like that the software has) of a high abstraction degree of an upstream process of software development.SOLUTION: The information processing apparatus includes an accumulation unit having an area for accumulating each piece of information of a work type set according to an input deliverable, a prompt creation unit for converting information converted from an external system in each of an upstream process, an intermediate process, and a downstream process into prompt information and giving the prompt information to the external system again, and an accumulation unit having an area for accumulating information of a generated deliverable including an output deliverable and a program code returned from the external system according to a procedure as a software deliverable.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a software development support device, a method, and a program. [Background technology]

[0002] Conventionally, specification management systems (including specification management devices, methods, and programs) have been developed to manage software design documents. These specification management systems are configured to separately manage model elements that represent design content and document elements that are output.

[0003] This specification management system maintains consistency between model elements and document elements, preventing inconsistencies and missing correspondences between specifications and reducing overall development costs. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 5366351 Summary of the Invention [Problem to be solved by the invention]

[0005] In the above-mentioned specification management system, the designer creates the model elements themselves, which requires a large number of man-hours and lead time for content confirmation, etc. Furthermore, the focus of the above-mentioned specification management system is on the creation and management of design documents, and the creation of program code is not included.

[0006] Meanwhile, a recent technological trend has seen the emergence of coding support tools that use generative AI. However, these coding support tools are limited to generating individual pieces of code, and do not support the generation of complete program code or overall deliverables that take into account the software development lifecycle.

[0007] SOPPRA Digital Transformation's CodeAGI (Services | SOPPRA Digital transformation Inc. (soppradx.com)) is another technology for generating programs from design documents. This application makes it possible to generate a program once a design document is specified. CodeAGI predetermines the analysis targets, such as tables, functions, screens, and common specifications, and does not target program generation from abstract specifications. Note that "specifications" are also called "design specifications" or "design information," but in this specification these are treated as the same thing.

[0008] Therefore, the object of this embodiment is to provide a software development support device, method, and program that can generate a complete set of program code from downstream process specifications that correspond to software model elements (indicating specific procedures, etc.) by sequentially generating downstream process specifications that correspond to software model elements (indicating specific procedures, etc.) from highly abstract specifications (indicating the general functions of the software, etc.) defined in the upstream process of software development.

[0009] Another object of the present invention is to provide a software development support device, method, and program that can flexibly accommodate design modifications and partial changes in response to future changes in the software usage environment. [Means for solving the problem]

[0010] According to one embodiment, A software development process is divided into a stepwise procedure that transitions from an upstream process through an intermediate process to a downstream process, and in the stepwise procedure, means for accumulating procedure information indicating at least an input deliverable to be provided to an external system, an output deliverable to be received from the external system, and a work type that is set according to the input deliverable; means for controlling a generation process to generate the next of said generated deliverables as software deliverables according to said procedure; A means for accumulating development know-how including at least design specifications, check items, and coding rules related to the design of the software; a means for accumulating design information and software code of the software as the software deliverable while referring to the development know-how; means for storing prompt templates; means for creating a prompt containing a sentence instructing the generation of the software based on at least each piece of design information of the prompt template; means for invoking a large-scale language model to generate a text artifact using the prompt as input; means for performing post-processing including inspection of the written product in a manner designated by the user; A software development support device is provided, which comprises a means for controlling the generation processing step, a means for creating the prompt, a means for generating the text product, and a means for performing post-processing, and an interface provided for the user to access these means. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is an explanatory diagram showing how program specifications are gradually detailed in a software development SW product generation support device according to this embodiment. [Figure 2] FIG. 2 is a block diagram showing an example of the basic configuration of a software development support device according to this embodiment. [Figure 3] FIG. 3 is a block diagram showing the configuration of the operation of the software development support device according to this embodiment when creating a software product. [Figure 4] FIG. 4 is a block diagram showing an example of the configuration related to the operation when a prompt template is registered in the software development support device according to this embodiment. [Figure 5] FIG. 5 is a diagram showing an example of a template for creating a prompt used in the software development support device according to this embodiment. [Figure 6]FIG. 6 is a diagram showing an example of a prompt created using the template of FIG. 5 in the software development support device according to this embodiment. [Figure 7] FIG. 7 is an explanatory diagram showing an example of a work procedure stored in the development process storage unit of FIG. 2 and FIG. 3 in the software development support device according to this embodiment. [Figure 8] FIG. 8 is an explanatory diagram showing an example of the work types stored in the work type database of FIGS. 2 and 3 in the software development support device according to this embodiment. [Figure 9] FIG. 9 is an explanatory diagram showing an example of the design meta-information DB in the software development support device according to this embodiment. [Figure 10] FIG. 10 is an explanatory diagram showing an example of the coding know-how DB in the software development support device according to this embodiment. [Figure 11] FIG. 11 is an explanatory diagram showing an example of the design know-how DB in the software development support device according to this embodiment. [Figure 12A] FIG. 12A is an explanatory diagram showing an example of the functional specifications of the deliverable storage unit 109 in the software development support device according to this embodiment. [Figure 12B] FIG. 12B is an explanatory diagram showing an example of the screen specifications of the deliverable storage unit 109 in the software development support device according to this embodiment. [Figure 12C] FIG. 12C is an explanatory diagram showing an example of screen item specifications of the deliverable storage unit 109 in the software development support device according to this embodiment. [Figure 13A] 13A is an explanatory diagram showing an example of a function list of a design (specification) template storage unit in the software development support device according to this embodiment. [Figure 13B] FIG. 13B is an explanatory diagram showing an example of a screen list of the design (specification) template storage unit 110 in the software development support device according to this embodiment. [Figure 13C] FIG. 13C is an explanatory diagram showing an example of the screen item specifications in the design (specification) template storage unit 110 in the software development support device according to this embodiment. [Figure 14] FIG. 14 is an explanatory diagram showing an example in which the screen list is detailed. [Figure 15] FIG. 15 is a flowchart for explaining an example of the operation of the software development support device according to this embodiment. [Figure 16] FIG. 16 is a flowchart for explaining another example of the operation of the software development support device according to this embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments will be described with reference to the drawings. First, the main points to be noted when designing the system of the embodiment will be summarized below.

[0013] In a typical system integration (SI) business application, the following must be met: The total size of the generated code may be tens of thousands of lines or more. -Multiple modules such as front-end, back-end, and DB need to work together. However, currently, there is a gap between highly abstract specifications and program code. Generative AI also has a limit to the amount of input and output it can handle, making it impossible to generate all of the specifications for each step of a program at once. Furthermore, it is difficult to properly store and provide information so that multiple related modules can work together.

[0014] This embodiment is constructed based on the following concept to overcome the above points to be noted. Figure 1 is an explanatory diagram showing how the specifications for generating software change from an upstream design document with a high level of abstraction to a step-by-step detailed design document. The generation AI gradually refines the design content from the highly abstract upstream design document. Information such as what to refine and in what order, what to input, what to output, and what items are required is given to the generation AI as prompts incorporating design know-how. In this case, - The AI ​​will also generate identifiers to uniquely identify specifications and program code. - Dependency relationships and tracking information for specifications and program code are also prepared as specification items, and are generated so that they can be identified by the above identifier.

[0015] In the first stage, an input specification 1001 is processed. Here, a function definition document 1011 that describes the general functions of the software is input.

[0016] In the second stage, intermediate specifications 2001 are processed to specify the items described in the function definition document 1011. Here, a screen list 2011 of the various screens used in the software is prepared. Next, a screen transition diagram 2021 is prepared, and a screen item specification 2022 for each screen transition in this screen transition diagram 2021 and a screen layout (html) 2023 for each screen are linked.

[0017] Once the design settings for screen transitions are complete, a table list 2031 is prepared. Here, data from a data item specification 2032 is linked to each table in the list. In this state, the intermediate specifications for the main flow are the subject of program code creation.

[0018] The data item specifications 2032 may include items that are linked to web services. For this reason, web service I / F (interface) specifications 2041 are provided. If the specifications are simple, they can be used to create program code as is. However, if the specifications involve classes, the class list 2051 is referenced, and the class specifications 2052 are identified before the program code is created.

[0019] In the third stage, the creation stage of the program code 3001 is set. The data in the table list 2031 in the intermediate specification 2001 is the subject of program code creation in the schema definition SQL (DDL) 3011. The data from the web service I / F specification 2041 is the subject of generation of screen (front-end) source code 3012. Furthermore, the data in the class list 2051 and class specification data are the subject of generation of JAVA (registered trademark) (back-end) source code 3013.

[0020] As mentioned above, the specifications for generating software are divided into stages, changing from an upstream design document with a high level of abstraction to a design document with increasing detail. Then, by writing the minimum necessary specifications in prompts and providing them to the generation AI in stages, the next prompts are generated one after another while limiting the input / output capacity of the generation AI. In other words, the generation AI itself creates the next prompt, and ultimately generates the program code. Generable It achieves this level.

[0021] Fig. 2 shows the basic configuration of a software development support device 5000 according to this embodiment. Fig. 3 is a block diagram showing the software development support device 5000 when a software deliverable involving program coding is generated. Since Fig. 2 and Fig. 3 show the same functional blocks, corresponding parts are assigned the same reference numerals and will be described in parallel.

[0022] Reference numeral 101 denotes an interface. This interface 101 provides a screen and a communication interface for inputting and outputting information to users and prompt template creators. The interface 101 also includes an operation unit / display device 5500 for users and the like to operate.

[0023] A developer or prompt creator can pass input information to a prompt creator 103 , a sentence creator 104 , a post-processor 105 , and a prompt template creator 106 via an interface 101 .

[0024] The form of the user interface (UI) is not limited, but possible implementation methods include a web application, a chat interface, etc. The interface 101 can also be connected to a display device 5500.

[0025] Reference numeral 102 denotes a process control unit, which is connected to the interface 101. This process control unit 102 can select the next deliverable to be created and its generation method based on the current deliverable generation status. The next deliverable to be created is determined from the information stored in a work procedure database (hereinafter, database will be abbreviated as DB) in the development process storage unit 107 and the work type DB (these databases are shown in Figures 7 and 8). The procedure in the work procedure DB is determined based on the work type information stored in the work type DB. The work procedure DB stores the order in which deliverables are created and the types of creation work. The process control unit 102 may also be called a generation processing step control means.

[0026] A prompt creation unit 103 is provided. When advance preparations are made for a dialogue with an AI, the developer selects and uses a prompt template with appropriate content according to the type of work in the prompt creation unit 103. Note that a plurality of types of prompt templates are registered in advance in a prompt template DB in a prompt template storage unit 111.

[0027] The developer fills in each item of the selected prompt template. At this time, the developer fills in the items with reference to the following: the contents of the design meta information DB, coding know-how DB, and design know-how DB stored in the development know-how storage unit 108, and the contents of the design information DB and program code DB stored in the software product storage unit 109. The means for creating this prompt (i.e., prompt creation unit 103) creates a prompt containing a sentence instructing the generation of a program based on each piece of design information such as the development know-how, software product, and prompt template.

[0028] Reference numeral 104 denotes a sentence generation unit. This sentence generation unit 104 calls and uses a large-scale language model 201. The sentence generation unit 104 inputs the prompts created by the prompt creation unit 103 into the large-scale language model 201 to generate sentences in a language that is compatible with AI or that is acceptable to AI. These generated sentences are stored as deliverables in various databases prepared in advance.

[0029] Since there are cases where errors are mixed into the generated results (text deliverables), the generated results can be checked by the designer (developer) via the interface 101, the errors can be pointed out, and the product can be generated again. In this case, a means for carrying out post-processing including checking the text deliverables is activated in a manner specified by the user (designer / developer).

[0030] For example, if the generated result is design information, it is checked whether the design items specified in the prompt are covered by the design information. If the generated result is program code, it is checked by actually running it. The above method of checking the generated result is merely an example and is not limited to this method.

[0031] As an example of a confirmation method, if the generated result is design information, the design information and the design items specified in the prompt may be output to the display device 5500 so that the user can visually check them. Also, a separate verification system or chat system may be used to confirm whether the acquired design information has a high correlation (co-occurrence relationship) with the characters or sentences in the prompt.

[0032] Furthermore, if the generated result is program code, the data to be processed may be prepared in advance in a separately prepared test data processing device, and the post-processing means may operate to run the program code on this data processing device.

[0033] Reference numeral 105 denotes a post-processing unit, which performs post-processing of the generated results in accordance with the post-processing types (see FIG. 8) stored in the work type DB included in the development process storage unit 107. In other words, if the work is generating a list or refining a list, the post-processing unit 105 performs processing to transcribe the generated results into the corresponding specification template. If the work is generating code, the post-processing unit 105 performs processing to write the generated results to a file. These generated results are stored in the design information DB, program code DB, etc. of the software artifact storage unit 109. Furthermore, post-processing may be performed using data stored in the design template DB. In other words, a comparison check may be performed to see if the generated results match the instructions in the design template.

[0034] Reference numeral 106 denotes a prompt template creation unit, where a prompt template creator creates prompt templates (see FIG. 4). Prompt templates are prepared in advance at an initial stage, but can also be added during operation of the device, and can also be added or modified later as needed. Such addition and modification history data can be stored in the prompt template storage unit 111 or the design know-how DB, categorized into cautions, prohibited items, recommended items, etc. Then, when a user uses a similar prompt template, the modification history data can be popped up on the display device as reference information.

[0035] Next, the usage patterns of the various databases (DBs) will be described. These databases (DBs) are accessed by the process control unit 102, prompt creation unit 103, sentence generation unit 104, post-processing unit 105, prompt template creation unit 106, etc.

[0036] Reference numeral 107 denotes a development process storage unit. The development process storage unit 107 has a work procedure DB that defines the order in which deliverables are created, and a work type DB that defines the types of work involved in creating the deliverables (see the work procedure DB in FIG. 7 and the work type in FIG. 8).

[0037] As described above, examples of the types of work include list generation, list detailing, code generation, etc. The type of work determines the control logic of the generation process of the object to be generated and the logic of post-processing after the object to be generated is generated.

[0038] For example, when generating a list (the object to be generated), the control logic is to generate it all at once, and then analyze the generated results and transcribe them into a specification template as post-processing. On the other hand, when refining a list, the control logic may be to control repeated processing (i.e., repeating the generation process) based on a list of specification information (explained in Figures 15 and 16).

[0039] For example, an example of a generation process for detailing a screen list (control for repeating the generation process) will be described. Figure 14 (a) shows an example of a screen list table. The first line divides the screen ID, name, type, description, and related specifications. The second line and onwards describe the actual screen information. In this example, it is assumed that V-001 exists as the screen described in the second line. The screen ID is V-001, the name is "login screen", the type is "input form", and the description is "enter user ID and password to perform user authentication". It also shows that "FUNC-001" exists as a related specification.

[0040] Furthermore, the third line contains a description of screen V-002. For this screen, the screen ID is V-002, the name is "Login screen", the type is "Input form", and the description is "Register new members as users". It indicates that there is a related specification "FUNC-002".

[0041] The generation process for detailing the screen list generates screen item specifications, which correspond to the details of the screens, for the number of pieces of information on the actual screens described in the screen list. V-001-1, V-001-2, and V-001-3 in Figure 14(b) are generated in a lump from V-001 (login screen) in Figure 14(a), and then V-002-1, V-002-2, and V-002-3 in Figure 14(c) are generated in a lump from V-002 (user registration screen). This generation process is repeated as many times as the number of lists of design information input. Therefore, if there are N lists, N batch generation operations are performed.

[0042] Figure 14 (b) below shows an example of the specifications for various items provided on the above screen V-001. In this example, there are three items ID=V-001-1, ID=V-001-2, and ID=V-001-3, and the names of the items are "User ID," "Password," and "Login." There are further constraints, which state that the User ID is a text box, the password is encrypted in a text box, and that Login is prepared using a button. In addition, the IO categories are all I (input), and the related specification is V-001.

[0043] (c) of Figure 14 shows an example of the specifications of various items provided on the above screen V-002. This example also shows an example with three items ID=V-002-1, ID=V-002-2, and ID=V-002-3. The names of the items are "User ID," "Last Name," and "First Name." The constraints are also specified: User ID must be a text box, Last Name must be a text box, full-width characters only, and First Name must also be a text box, full-width characters only. Furthermore, the number of digits to be displayed for each item is also specified. It is also described that the related specification is V-002.

[0044] Reference numeral 108 denotes a development know-how storage unit. The development know-how storage unit 108 includes a design meta information DB, a design know-how DB, and a coding know-how DB (description examples of these will be shown later). Here, development know-how for software development is registered.

[0045] For example, in the design meta-information DB, design items to be designed in software are organized by units such as function specifications, screen specifications, and table specifications, and are managed using structural information called a metamodel (see Figure 9 (Structural Information of Design Documents)). In the coding know-how DB, notes on writing file names, encoding specification specifications, prohibited actions, etc. are described (see Figure 10 (Coding Guide)). In addition, the design know-how DB describes how to write screen item specifications, how to handle input and output data in function definition documents, and check items for design specifications (see Figure 11).

[0046] In other words, the design know-how includes meta-information for creating software (design document names and design items (metamodel), design procedures (input / output, document relationships)), points to pay attention to during design, coding guides, etc.

[0047] Reference numeral 109 denotes a software artifact storage unit. Information defined as a designed document is registered in the design information DB of the software artifact storage unit 109. The design information is defined based on design items (metamodels) registered in the design know-how DB. An ID (identification data) is assigned to the specification information to uniquely identify the specification, and trace information is also defined for the specifications that served as input to define the specification. In addition, the program code DB registers program code generated by a large-scale language model.

[0048] Reference numeral 110 denotes a design template storage unit. In the design template DB of the design template storage unit 110, models of software design documents are registered as design templates. When specific information is written here, it is called a design template storage unit (see FIG. 13).

[0049] Reference numeral 111 denotes a prompt template storage unit. Prompt templates that indicate instructions for creating design information and prompt templates that indicate the creation of program code are registered in the prompt template DB of the prompt template storage unit 111. The prompt templates can contain information such as prerequisites, explanations of design work and items, explanations of related design information, output examples, output formats, notes on output, and input specification information. Note that the items in these templates are merely examples and can be customized.

[0050] 201 is a large-scale language model (which may also be called a generative AI or external server). The large-scale language model 201 is a language model having millions to billions of parameters that has been pre-trained using large-scale data. Alternatively, a small-scale automatic program generator can be used.

[0051] The sentence generation unit 104 invokes the large-scale language model 202 and executes the task (obtains a deliverable in response to a prompt). In this embodiment, only the use of a large-scale language model is assumed, and no specific model is specified.

[0052] Figure 3 is a block diagram that focuses on the flow of data when the software development support device 5000 of this embodiment described above automatically acquires a generated software deliverable, and the same blocks as those in Figure 2 are assigned the same reference numerals. Therefore, each block is explained in Figure 2. Figure 2 is written with the understanding that various databases are constructed for the software development support device 5000 of this embodiment.

[0053] 4 shows a prompt template that has been created in advance and is registered in the prompt template DB of the prompt template storage unit 111. A prompt template creator creates a prompt template by controlling the prompt template creation unit 103 via the interface 101. The created prompt template is stored in the prompt template storage unit 111.

[0054] Fig. 5 shows an example of a prompt template 300, and Fig. 6 shows an example of a prompt created using the prompt template 300. The format of the prompt template 300 is as shown in Fig. 5. This format is displayed, for example, as a work screen for a device. The area on the left side of the screen is an area for writing a system prompt, and the area on the right side of the screen is an area for writing a user prompt.

[0055] In the display area 302 on the left side, a fixed guide is displayed saying, "You are an excellent software engineer." The display area 303 is an area for explaining design work and design items.

[0056] There is an area where the user should write, "You are currently creating {{}}." In this area, the user should write the "Software Deliverable Name." Also, An area is reserved for the user to write, asking them to design based on the input {{}}. In this area, the user writes the "name of the input software artifact." A fixed guide will appear saying, "The items to be defined are as follows." In this area, An area for the user to write is reserved, such as {{}}. In this area, the user can write the "design items to be defined."

[0057] Furthermore, in the display area 304, A fixed guide will be displayed saying "Please refer to the following if necessary." An area for the user to write is reserved, such as {{}}. In this area, the user can write "design information / program code to be referenced as (Option)".

[0058] Next, a display area 305 is an area for specifying an output format so that the generated results can be handled as structured data, and an output example may be shown. For example, the following instructions are given: The guide will say "Please output in JSON format." In the display area 306, A fixed guide will be displayed saying "Please proceed with caution." A fixed guide is displayed saying, "Please enter all IDs of the specifications that became input information." Then, the user can write know-how and notes about the design content as (optional) within {{}}. Here, the user can enter common points to be careful about, design know-how that requires individual instructions for each task, and coding know-how.

[0059] The user prompt template on the right is explained below. This area 310 asks you to design {{}} based on the input {{}}. In the first space, you are asked to enter the "name of the software deliverable to be used as input," and in the second space, you are asked to enter the "name of the software deliverable."

[0060] FIG. 6 shows an example of the {{}} box that the user is requested to fill in, as shown in FIG. 5, after the user has filled in each requested item.

[0061] 7 and 8 show examples of tables of data stored in the work procedure DB and work type DB of the development process storage unit 107. FIG.

[0062] In the work procedure DB, steps 1 to 5 are listed in the columns as the order of work. The rows of the procedures are classified into input deliverables, generated deliverables, work types, and specification classes. Figure 8 shows the table of the work type DB for work types.

[0063] In step 1, the function definition document is treated as the input deliverable, the generated deliverable is a screen list, and the task is to generate the list. The specification class is the screen specification.

[0064] In step 2, the input deliverable is a screen list (the deliverable when step 1 is executed), and the generated deliverable is a screen item specification. The work involves refining the list generated in step 1. The specification class is the screen item specification.

[0065] In step 3, the input deliverable is a screen list (the deliverable when step 1 is executed), the generated deliverable is a table list, the operation type is list generation, and the specification class is table specification.

[0066] In the next step, step 4, the input deliverable is a table list (the deliverable when step 3 is executed), and the output deliverable is a table item specification. The work type at this time is list refinement, and the specification class is table item specification.

[0067] In the next step, step 5, the input deliverables are the table list (the deliverables when step 3 is executed) and the table item specifications (the deliverables when step 4 is executed), and the generated deliverables are the schema definition SQL (DDL).

[0068] In the work type DB, the first line defines the "work name," "generation process content," "control type," and "post-processing type." For the work name, "list generation," "list detailing," and "code generation" are set, while the "generation process content" includes "generate specification list information," "repeat generation process for input specification information list," and "generate source code." For the "control type," "batch generation," "repeated generation," and "batch generation" are written. For the "post-processing type," "transcribe to design template" and "write to file" are specified.

[0069] 9 shows an example of the data structure of the design meta information DB. The meta information includes function specifications 901, screen specifications 902, screen items 903, table specifications 904, and table items 905. Each item is assigned an ID attribute, name, etc. for identification. In this way, multiple specifications that connect upstream to downstream are prepared in stages. The information shown here is an example, and does not need to be limited to this. Note that although the diagram shows each specification and each item of information as if there is only one, there may be multiple pieces of specification information and each item of information.

[0070] Figure 10 shows an example of a coding know-how DB, which describes precautions to take when writing file names, precautions regarding encoding, and prohibitions on wildcard imports.

[0071] 11 shows notes on design know-how and notes on design information, which may be added when the system is used.

[0072] For example, it states that the input and output data in the function definition document (Figure 7) should be candidates for entities, and that screen item specifications (Figure 7) should be created for each screen defined in the screen list.

[0073] 12A, 12B, and 12C are examples of tables in the design information DB stored in the software artifact storage unit 109. The design information includes functional specifications (FIG. 12A), screen specifications (FIG. 12B), and screen item specifications (FIG. 12C), each of which is managed in a table.

[0074] The functional specifications in Figure 12A have columns for describing "ID," "Name," "Description," "Function Details," "Input," "Processing," "Output," and related specifications. In this example, "FUNC-001" is written as the ID, its name is "Login," and its description is "This is a function that allows users to log in to the system." Furthermore, the function details column describes "Enter a user ID and password to perform user authentication," with "user ID and password" written as the input, and "authenticate the entered user ID and password, and if successful, display the top screen, or if unsuccessful, redirect to the login screen." The "top screen" is also written as the output. Other functional specifications are written in a similar arrangement.

[0075] As an example, Figure 12B shows the screen specifications for the screen used in the above "FUNC-001" (described in the related specifications). The screen specifications include the ID, name, type, description, input, and related specifications. In this example, the ID is "V-001," the name is "login screen," the type is "input form," and the description is "enter user ID and password to perform user authentication," and "FUNC-001" is described as the related specifications (i.e., it is described that it is related to the specifications in Figure 12A).

[0076] FIG. 12C shows the screen item specifications for the screen with the above screen ID (=V-001). The screen item specifications include the ID, name, constraints, description, IO (input / output) category, number of display digits, and related specifications. In this table, three types of IDs are shown as an example: "V-001-1, V-001-2, V-001-3," and each ID corresponds to the name "user ID, password, login." Furthermore, the constraints for each name are described as "text box, text box that must be encrypted, button," all IO categories are specified as "I (input)," all display digits are set to "---- (none in particular)," and all related specifications indicate that they relate to "V-001."

[0077] Fig. 13A shows an example of a function list (design template corresponding to a function specification class) included in the specification template DB of the design template storage unit 110. Fig. 13B and Fig. 13C show examples of a screen list and a screen item specification, both of which are also included in the design template DB.

[0078] The template showing the function list has a field for entering the project name and a field for entering the system name. It also has a field for the "ID" of the document name, a field for the "Name" of the function definition document, and a field for the "Description" of the function definition document, a field for "Function Details," a field for "Input," a field for "Processing," a field for "Output," and a field for "Related Specifications." As shown in Figure 12A, an explanation corresponding to each document is entered in each field.

[0079] FIG. 13B is a screen list (design template corresponding to a screen specification class), and FIG. 13C is a screen item specification (specification template corresponding to a screen item class).

[0080] 13B, the screen list (design template corresponding to the screen specification class) has a field for entering a project name and a field for entering a system name. Furthermore, "screen list" is written as the document name.

[0081] Next, there are fields for entering "ID," "Name," "Type," "Description," and "Related Specifications" in the screen list. The input format for these fields is specified based on the items in the metamodel stored in the design meta information database.

[0082] 13C is a screen item specification (a design template corresponding to a screen item class), which has a field for entering a project name and a field for entering a system name. Furthermore, "screen item specification" is written as the document name.

[0083] This template has fields for entering "ID," "Name," "Constraints," "IO (Input / Output) Classification," "Number of Display Digits," and "Related Specifications" (corresponding to FIG. 12C).

[0084] FIG. 15 is a flowchart showing an example of the operation when software deliverables are generated in a batch in the software development support device according to this embodiment. When this system is started (ON), the current status (the order of the processing procedures described below) is confirmed. This status is displayed on the display device 5500 (step S1). Next, the user instructs the creation of a software deliverable via the interface 101 (step S2).

[0085] The process control unit 102 acquires the next procedure from the work procedure DB (e.g., FIG. 7) in the development process storage unit 107 (step S3). It checks whether the acquired procedure is the last procedure (step S4). If the acquired procedure is the last procedure, it ends the process (step S5). However, if the acquired procedure is not the last procedure, it acquires the work type of the next procedure (step S6).

[0086] Next, a prompt template is obtained from the prompt template DB (step S7). Then, specification information to be input to the prompt template is obtained (step S8). This specification information is information in the development know-how storage unit 108. The specification information corresponds to the input deliverables (function definition document, screen list, table list, table item specification, etc.) in the work procedure DB (FIG. 7). Furthermore, design know-how (note information in FIG. 11) is obtained (step S9). Then, the specification information and design know-how are incorporated into the template to create a prompt (step S10).

[0087] Next, the generation AI generates a software product (step S11). The user then checks whether the generated result is satisfactory (step S12). If the user is not satisfied with the generated result, he or she modifies the prompt (step S13), and the generation AI generates a software product again based on the modified prompt (step S11).

[0088] In other words, as the sentence generation unit 104 interacts with the large-scale language model 201, generated deliverables corresponding to the work procedures, such as the "screen list" and "table list" shown in Figures 7 and 8, are constructed in sequence from a database of abstract concepts to a database of concrete concepts.

[0089] Then, post-processing is performed to determine the generation of a software product for one procedure (step S14), where the product is transcribed into a specification template, written to a file, and so on.

[0090] Furthermore, the deliverable is stored in the software deliverable storage unit 109 as a software deliverable (step S15), and the process returns to step S1. In step S1, the status of system operation can be known from the procedure information of the process control unit 102. The status information is sent to the display device 5500, and the progress of the software deliverable creation can be confirmed. The display device 5500 can display various forms, such as the order of the work procedures, the time from the start of the work to the present, and the progress rate of the process. Furthermore, the meta information DB shown in FIG. 9 can be used to display blocks of function specifications, screen specifications, screen item specifications, table specifications, and table item specifications, and visualize color changes, bar length changes, etc., according to the software deliverable creation status of each block (according to the number of prompts used).

[0091] In the flowchart of Fig. 15, the processes from step S8 to step S13 correspond to the case where the task names in the task type are "Generate list" and "Generate code" in Fig. 8. In this case, the control type is "Bulk generation" and the contents of the generation process are "Generate list information of specifications" and "Generate source code."

[0092] Figure 16 is a flowchart for performing list detailing processing. This example is an example of a flowchart that includes paths for repeating similar processing, although the processing content is different. A specific example of "detailing" at this time is shown in Figure 14.

[0093] Steps S1 to S7 are the same as those in Fig. 15. That is, when this system is started (ON), the current status is confirmed. This status is displayed on the display device 5500 (step S1). Next, the user instructs the creation of a software deliverable (step S2).

[0094] The process control unit 102 acquires the next procedure from the work procedure DB in the development process storage unit 107 (step S3). It checks whether the acquired procedure is the last procedure (step S4). If the acquired procedure is the last procedure, it ends the process (step S5). However, if the acquired procedure is not the last procedure, it acquires the work type of the next procedure (step S6). It acquires a prompt template from the prompt template DB (step S7).

[0095] Next, input to the prompt template (input artifact, i.e., list) is obtained. This input is specification information and also a list (see, for example, FIG. 14(a)) (step S20).

[0096] Furthermore, design know-how (note information in FIG. 11) which is the note shown in FIG. 11 is acquired (step S21). One piece of specification information is acquired from the specification information (list), and the specification information and design know-how are incorporated into the prompt template to create a prompt (steps S22 and S23).

[0097] The generated prompt is sent to the large-scale language model 201 via the sentence generator 104. The large-scale language model 201 returns the generated output (text) to the sentence generator 104 (step S24).

[0098] Next, the user checks whether the generated results are satisfactory (step S25). If the user is not satisfied with the generated results, he or she modifies the prompts (step S26), and the generation AI generates a software deliverable again based on the modified prompts (step S24).

[0099] As described above, the design information of the abstract concept is converted into the specification information of the concrete concept in sequence.

[0100] If the generated software deliverable is satisfactory (Y in step S25), it is determined whether processing has been performed for all design information (step S27). If processing has not been performed for all design information, the process returns to step S22, and processing is performed for the design information with the next list rank. If processing has been performed for all design information (Y in step S27), post-processing is performed (step S14).

[0101] In the post-processing, a post-processing step is performed to determine the generation of a software product for one procedure (step S14). Here, the product is transcribed into a specification template, written to a file, and so on.

[0102] Furthermore, the result is stored as a software result in the software result storage unit 109 (step S15), and the process returns to step S1. In step S1, the status of the system operation can be known from the procedure information of the process control unit 102. The status information is sent to the display device 5500, and the progress of the software result creation can be confirmed.

[0103] In the operation of the above-described system, data (information) of prompts used in each procedure is stored in a progress data storage unit connected to the interface 10.

[0104] By visualizing the data in the progress data storage unit during system checks or maintenance, users can reconfirm what prompts were used to generate the program code they designed. If the progress data is modified, especially if the prompts are modified, a specific identifier may be added for checking the progress data so that the modifications can be confirmed. This measure also makes it possible to view the characteristics of the large-scale language model and program generation system being used. Knowing the characteristics of the large-scale language model and program generation system being used by users can also be useful in future program design. Furthermore, if the need for design changes arises, the data in the storage unit can be effectively utilized to make small changes.

[0105] As described above, this embodiment is characterized by the following elements, each of which is given a reference numeral corresponding to the drawing.

[0106] A) The software development process is divided into steps 1 to N, which transition from the upstream process to the intermediate process and then to the downstream process. In the first procedure division, at least a first input deliverable to be provided to an external system, a first generated deliverable received from the external system in response to the first input deliverable, and information of a first work type describing how to handle the first generated deliverable are accumulated; In the second procedure section, at least information on a second input deliverable to be provided to an external system, a second output deliverable received from the external system in response to the second input deliverable, and a second work type describing how to handle the second output deliverable are accumulated, and the second input deliverable defines the use of the first output deliverable, and the second output deliverable defines an item specification indicating details of the first output deliverable; In the third procedure division, at least a third input deliverable to be provided to an external system, a third generated deliverable received from the external system in response to the third input deliverable, and information of a third work type describing how to handle the third generated deliverable are accumulated, and the third input deliverable is defined as the use of the first generated deliverable or the second input deliverable, and the third generated deliverable is defined as a table list different from the first generated deliverable, In the fourth procedure category, a storage means 107 stores information on at least a fourth input deliverable to be given to an external system, a fourth generated deliverable received from the external system in response to the fourth input deliverable, and a fourth work type describing how to handle the fourth generated deliverable, the fourth input deliverable defining the use of the third generated deliverable, and the third generated deliverable defining a table item specification detailing the third generated deliverable; The software development support device comprises a process control means 102 that executes operations related to each input product, output product, and work type in accordance with each procedure of the storage means. A2) A software development support device in which the first, second, third, and fourth input deliverables are used as data to be written in a prompt in a prompt creation unit 103.

[0107] B1) A software development process is divided into stages, transitioning from an upstream process to a downstream process via an intermediate process, and each stage includes a first storage means 107 having an area for storing at least an input deliverable to be provided to an external system, a generated deliverable received from the external system in response to the input deliverable, and information on a work type set according to the input deliverable; and a second storage means 108 having an area for storing information on development know-how including at least design specifications, check items, and coding rules related to the design of the software. The system further includes a prompt creation means 103 for creating prompts to be given to the external system in each of the upstream process, the intermediate process, and the downstream process, the prompts including information on the input deliverables and information on the development know-how. and a third storage means 109 having an area for storing information on the generated product, including the output product and program code, as a software product, which information is returned by providing the prompt to the external system according to the procedure.

[0108] B2) In addition, the embodiment has a processing control unit 102 that reads the information of the procedures set by the first storage means 107 and identifies the input deliverables to be given to the external system set in each procedure, as in 1) above.

[0109] B3) Also, in the embodiment described in 1), the embodiment has an operating means 5500 that modifies the prompt used to obtain the software deliverable based on the check result of the software deliverable before the software deliverable is stored in the third storage means 109.

[0110] B4) Furthermore, in the embodiment, in 1) above, a display means 5500 is provided which monitors the progress of the processing set in the plurality of procedures set by the first storage means 107 and displays the progress of the processing.

[0111] B5) Furthermore, this embodiment not only has features as the software development support method and program described in 1) to 5) above, but also as a service data providing device as a deliverable product. The program code may also be encrypted and provided to external users.

[0112] In the above explanation, we have described the use of a large-scale language model 201 to construct a design document from a higher-level concept to a lower-level concept, and then to create a design document that can be specified (contacted) to specific program code in stages. In this case, the name of the large-scale language model 201 is not limited to the name used in this specification. For example, a system that creates and supports a hierarchical design document that can specify specific program code from a program design overview may be called a program design document creation device or support system. This system receives a design document as an input product and returns an output product. Another significant feature of this system is that it employs a mechanism that allows this output product to be used as an input product for the next stage. This method allows the program design document creation device to be provided with input products that have high affinity.

[0113] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as set forth in the claims. Furthermore, the scope of the present invention also includes cases in which each component of the claims is expressed separately, as a combination of multiple components, or as a combination of these components. Furthermore, multiple embodiments may be combined, and examples composed of such combinations are also within the scope of the invention.

[0114] In addition, to clarify the description, the drawings may show the width, thickness, shape, etc. of each part more schematically than in the actual embodiment. Furthermore, the device of the present invention is applied even when the claims are expressed as control logic, as a program including instructions for causing a computer to execute, or as a computer-readable recording medium containing the instructions. Furthermore, the names and terms used are not limited, and other expressions that have substantially the same content and intent are also included in the present invention. [Explanation of symbols]

[0115] 101...Interface, 102...Processing control unit, 103...Prompt creation unit, 104...Text creation unit, 105...Post-processing unit, 106...Prompt template creation unit, 107...Development process memory unit, 108...Development know-how memory unit, 109...Software artifact storage unit, 110...Design (specification) template memory unit, 111...Prompt template memory unit, 5000...Software development support device, 5500...Operation unit / display unit.

Claims

1. The software development process is divided into stages, transitioning from an upstream process to a downstream process via an intermediate process, and each stage includes a first storage means having an area for storing at least an input deliverable to be provided to an external system, a generated deliverable received from the external system in response to the input deliverable, and information on a work type set according to the input deliverable; a second storage means having an area for storing information on development know-how including at least design specifications, check items, and coding rules related to the design of the software; a prompt creation means for creating a prompt to be given to the external system in each of the upstream process, the intermediate process, and the downstream process, the prompt including information on the input deliverable and information on the development know-how; a third storage means having an area for storing, as a software product, information on the generated product including the output product and program code, which is returned by providing the prompt to the external system according to the procedure; A software development support device comprising:

2. 2. The software development support device according to claim 1, further comprising a processing control unit that reads the procedure information set in said first storage means and identifies the input deliverable to be given to said external system set in each procedure.

3. 2. The software development support apparatus according to claim 1, further comprising an operating means for modifying the prompt used to obtain the software product based on a check result of the software product before the software product is stored in the third storage means.

4. 2. The software development support device according to claim 1, further comprising display means for monitoring the progress of the processes set in the plurality of procedures set in said first storage means and displaying the progress of the processes.

5. A software development support method in which a control means controls a storage means and a generation and creation means to automatically generate software, comprising: The software development process is divided into stages, transitioning from an upstream process to a downstream process via an intermediate process, and in each stage, an area is acquired for storing information on at least an input deliverable to be provided to an external system, a generated deliverable received from the external system in response to the input deliverable, and a work type set according to the input deliverable; Acquire an area to store development know-how information including at least design specifications, check items, and coding rules related to the design of the software; creating a prompt to be given to the external system in each of the upstream process, the intermediate process, and the downstream process, the prompt including information on the input deliverable and information on the development know-how; and obtaining an area for storing information about the generated product, including the output product and program code, as a software product, which information is returned by providing the prompt to the external system according to the procedure.

6. 6. The software development support method according to claim 5, wherein said control means reads information about said procedures and identifies said input deliverables to be given to said external system set in each procedure.

7. 6. The software development support method according to claim 5, further comprising the step of modifying the prompt used to obtain the software deliverable based on a check result of the software deliverable before the software deliverable is stored.

8. 2. The software development support method according to claim 1, further comprising the step of monitoring the progress of the processes set in the plurality of procedures, and displaying the progress of the processes on a display means.

9. A computer program executed by an apparatus that automatically generates software development through interaction with an external system, The software development process is divided into stages of steps that transition from an upstream process to a downstream process via an intermediate process, and in each stage of the steps, a first storage means is operated, the first storage means having an area for storing at least an input deliverable to be provided to an external system, a generated deliverable received from the external system in response to the input deliverable, and information on a work type set according to the input deliverable; activating a second storage means having an area for storing information on development know-how including at least design specifications, check items, and coding rules related to the design of the software; operating a prompt creation means for creating a prompt to be given to the external system in each of the upstream process, the intermediate process, and the downstream process, the prompt including information on the input deliverable and information on the development know-how; operating a third storage means having an area for storing, as a software product, information on the generated product including the output product and program code, which is returned by providing the prompt to the external system according to the procedure; Software development support program.

10. 10. The software development support program according to claim 9, further comprising: a processing control unit that reads the procedure information set in the first storage means and identifies the input deliverable to be provided to the external system set in each procedure.

Images