JP2022143770A - System development method - Google Patents

Abstract

To provide a system development method for reducing development man-hours.SOLUTION: A system development method includes a step of creating a design document in which design information is described, and a step of reading the design information from the design document by a framework. The design information includes at least one among a piece of screen item definition information that defines a screen item by setting any design item from among multiple design items, document item definition information that defines a document item by setting any design item from among the multiple design items, list data information that defines a list displayed as input candidates of the screen items, screen item transfer information that defines editing processing when displaying the screen items, document item transfer information that defines the editing processing when displaying the document items action specification information that defines actions of the screen items for each occurrence timing of the event and object control information that defines display forms of the screen items as the actions.SELECTED DRAWING: Figure 1

Description

The present disclosure relates to a system development method for software applications and the like.

Generally, in the development of a system such as a software application, a program is designed after the system is designed, and coding is performed based on a design document that is a product of the program design process. Conventionally, in system development, in order to efficiently design and code a program, there has been known a method of automatically generating the source of portions that can be automatically generated based on the information described in the design document. Patent Literature 1 discloses software development in which such an automatically generated source is shared among a plurality of developers, and the automatically generated source is provided as a sample source when implementing a source having similar functions to the automatically generated source. A support system is disclosed.

JP 2011-053755 A

However, the development support system of Patent Document 1 does not reduce the necessary production volume of the source code itself. Also, it is necessary to perform a unit test of the automatically generated source and the manually generated source, and an integration test to verify the operation when the automatically generated source and the manually generated source are combined. Furthermore, according to changes in the design documents, automatic generation of sources and correction of manually generated sources are required, and these tests must be performed again. In addition, if a part of the auto-generated source is manually modified, if the source is automatically generated again according to the change in the design document, it will be necessary to perform this manual modification again. Re-implementation requires various considerations.

The present disclosure has been made to solve the problems described above, and aims to provide a system development method that reduces development man-hours.

A system development method according to the present disclosure includes a step of creating a design document in which design information is described, and a step of reading the design information from the design document by the framework. By setting arbitrary design items, screen item definition information that defines screen items, by setting arbitrary design items among multiple design items, form item definition information that defines form items, screen List data information that defines the list displayed as input candidates for items, screen item transfer information that defines editing processing when displaying screen items, form item transfer information that defines editing processing when displaying form items, Alternatively, at least one of action specification information defining actions of screen items and object control information defining display forms of screen items as actions is included for each occurrence timing of an event.

According to the system development method of the present disclosure, the framework reads the design information from the design document, so that the system can be implemented without coding, and development man-hours can be reduced.

1 is a diagram for explaining a system development method according to Embodiment 1; FIG. FIG. 4 is a diagram showing a screen item definition sheet 21 of a design document according to Embodiment 1; FIG. 3 is a diagram showing a design document list data sheet 22 according to the first embodiment; FIG. 4 is a diagram showing an action specification sheet 23 of a design document according to Embodiment 1; FIG. 4 is a diagram showing an object control sheet 24 of a design document according to Embodiment 1; FIG. FIG. 10 is a diagram showing a screen item transfer sheet 25 of the design document 2 according to Embodiment 1; FIG. 3 is a diagram showing a form item definition sheet 31 of a design document according to Embodiment 1; FIG. 3 shows a form item transfer sheet 32 of a design document according to Embodiment 1. FIG. FIG. 4 is a schematic diagram showing a part of a screen 40 displayed in a system to be developed according to Embodiment 1; FIG. 4 is a schematic diagram showing a part of a screen 40 displayed in a system to be developed according to Embodiment 1; FIG. 4 is a schematic diagram showing a part of a screen 40 displayed in a system to be developed according to Embodiment 1; FIG. 4 is a schematic diagram showing a part of a screen 40 displayed in a system to be developed according to Embodiment 1; 5 is a diagram showing a form 50 output by the development target system according to the first embodiment; FIG. 4 is a flowchart showing a system development method according to Embodiment 1;

Embodiment 1.
FIG. 1 is a diagram for explaining the system development method according to the first embodiment. This system development method implements the functions of the system to be developed without coding by using the framework 1 that analyzes the design information contained in the design document 2 while following the so-called waterfall type development. be. As shown in FIG. 1, the framework 1 reads design information from a design document 2 described in a predetermined format, generates a screen 40 and a form 50, and displays them on a display 13 of a computer 10 such as a PC or a server. to display. Note that the framework 1 may output the form 50 to a printer and print it on paper. The framework 1 has been developed prior to the system to be developed, and can be used for a plurality of different systems to be developed. The system to be developed is, for example, a system for managing employee insurance labor.

The framework 1 and the design document 2 are stored in a storage device 11 such as a ROM (Read Only Memory) provided in a computer 10, a PROM (Programmable ROM) such as a flash memory, or a HDD (Hard Disk Drive). Also, the framework 1 is executed as a program by a processing device 12 such as a CPU (Central Processing Unit) included in the computer 10 . In the following, the description of the parts common to the conventional waterfall type development will be omitted as appropriate, and the description will focus on the features of this system development method.

The design information and design method of the screen 40 and the form 50 of the system to be developed will be described. First, the case of the screen 40 will be described. Screen item definitions, list data, action specifications, object control, check rules, and screen item transfer are designed for the screen 40 . For the design document 2, for example, spreadsheet software is used. Each of the above designs is compiled so as to correspond to one sheet of spreadsheet software. In the following description, each sheet is named with a design type, such as screen item definition sheet 21 . Also, information defined in each sheet is named with a design type, such as screen item definition information. In other words, the design information is a generic term for information defined in each sheet, that is, information defined in the design document 2 as a whole. Each sheet has a design item written as a heading in the top row, and has a format in which specific values are designed for the design item for each screen item.

FIG. 2 shows the screen item definition sheet 21 of the design document 2 according to the first embodiment. As shown in FIG. 2, the screen item definition sheet 21 contains, as screen item definition information, arbitrary design items among a plurality of design items from "input/output" to "description" for each screen item. The settings are listed for As a result, each screen item arranged on the initial screen is defined. Here, the initial screen is the screen 40 that is not controlled by any action specification information described later. Also, in the screen item definition sheet 21, it is possible to group a plurality of screen items, define non-display items, and the like. In this way, screen item specifications are not limited to a predetermined layout and can be freely defined.

"'List data' <<item transfer>>" in the screen item definition sheet 21 is a design item that refers to another sheet. "'List data' <<item transfer>>" is described when controlling a corresponding screen item by list data information or screen item transfer information. As indicated by P1, the list data sheet 22 is referred to when enclosed in quotation marks. P1 corresponds to P4 in the list data sheet 22, which will be described later. If the item is surrounded by "<>>" as indicated by P2, refer to the screen item transfer sheet 25, which will be described later. P2 corresponds to P11 of the screen item transfer sheet 25 .

FIG. 3 is a diagram showing the list data sheet 22 of the design document 2 according to the first embodiment. As shown in FIG. 3, the list data sheet 22 describes a list of input candidates for screen items as list data information. P3 lists "Blank", "2: Name Change Notification", "3: Qualification Loss Notification/Classification Change Notification", and "4: Moving Out Notification" as a list of input candidates for the combo box "Form type". In addition, P4 and P5 are designed so that the display of input candidates can be divided in the combo box "display of loss cause/insured person classification change". Conditions for dividing the display of input candidates are designed in an action specification sheet 23, which will be described later.

FIG. 4 is a diagram showing the action specification sheet 23 of the design document 2 according to the first embodiment. As shown in FIG. 4, on the action specification sheet 23, as action specification information, design items such as "processing content", "object control", or "'list data' <<item transfer>>" are described for each event occurrence timing. ing. An event means behavior such as changing a screen item to an "item" of a specific "value" ("Change") or clicking a screen item ("Click"). "Processing content", "object control" or "'list data' <<item transfer>>" corresponds to an action.

If the framework 1 is to perform non-coding processing, enter "-" in "processing content" and enter "object control" or "'list data' <<item transfer>>". "Object control" refers to the control content of the object control sheet 24 that matches the combination of "name" and "control details". P6 describes "form type" and "name change report" as a combination of "name" and "control details" of "object control" when "form type" is changed to "2: name change report". . P6 corresponds to P10 of the object control sheet 24, which will be described later.

As in the screen item definition sheet 21, "'list data' <<item transfer>>" in the action specification sheet 23 is a design item that refers to another sheet. "'List data' <<item transfer>>" is described when controlling a corresponding screen item by list data information or screen item transfer information. As indicated by P7 and P8, the list data sheet 22 is referred to when enclosed in quotation marks. On P7, "'Cause of Loss/Change of Insured Person's Classification (Change of Name)'" is entered as "'List Data'" when the 'Form Type' is changed to '2: Name Change Report'. In addition, on page 8, when you change the "Form type" to "3: Notification of loss of eligibility/change of classification", "'List data'" will be "'Indication of cause of loss/change of insured person's classification (Notification of loss of eligibility/change of classification )” is described. P7 and P8 correspond to P4 and P5 of the list data sheet 22; Also, when the item is surrounded by "<>>" as shown in P9, the screen item transfer sheet 25 is referred to. On page 9, "<<Employment Security Office>>" is described as "<<Item transfer>>" when "Form type" is changed to "3: Notification of disqualification/report of classification change".

FIG. 5 is a diagram showing the object control sheet 24 of the design document 2 according to the first embodiment. As shown in FIG. 5, in the object control sheet, the display form of each screen item is described for each combination of "name" and "control details" of "object control" of the action specification sheet 23 as object control information. be done. As the display mode, active or inactive when the screen item is in the display state, and a non-display state are set. It is also possible to set the display format to be non-convertible. No conversion means that the display form immediately before the corresponding object control is applied is not changed. P10 describes the display format of the screen items when the "name" is "form type" and the "control details" is "name change notification" in "object control" of the action specification sheet 23. . In this case, for example, "date of separation from employment, date of transfer, etc." becomes inactive, while "name of insured person", "indication of change in cause of loss/insured person category" and "name after change" become active. ing.

FIG. 6 is a diagram showing the screen item transfer sheet 25 of the design document 2 according to the first embodiment. As shown in FIG. 6, in the screen item transfer sheet 25, a table 25a at the top describes a design relating to database (hereinafter referred to as DB) mapping. In addition, this DB is a database in which information related to business processing in the development target is registered. Table 25b at the bottom describes editing processing performed when information is transferred from a transfer source screen item, DB, or file to a transfer destination screen item, DB, or file. That is, the screen item transfer sheet 25 describes information for mutual transfer of screen items, DB items, and file items (XML file, EXCEL file). The screen item transfer sheet 25 describes screen item transfer information when the transfer destination is a screen item among these combinations. As the screen item transfer information, P11 shows "-" for each predetermined number of digits for "employer's employment insurance number" and "related No." as the input contents of the screen item "employment insurance business number". , and edit processing with symbols such as ":". P12 shows editing processing for extracting the second character from the left of the "employment security office code" as the input contents of the screen item "employment security office".

Next, the case of the form 50 will be described. The design information of the form 50 includes the form item definition and the form item transfer. The description method as the design document 2 is the same as that of the screen 40 . Further, each sheet is named with a design type, such as a form item definition sheet 31, and the information defined in each sheet is named with a design type, such as form item definition information. It is the same as the case of the screen 40 in that it is referred to as .

FIG. 7 is a diagram showing the form item definition sheet 31 of the design document 2 according to the first embodiment. As shown in FIG. 7, the form item definition sheet 31 describes settings for arbitrary design items among a plurality of design items for each form item as form item definition information. As a result, each form item is defined. Also, in the form item definition sheet 31, a plurality of form items can be grouped. In this way, the specification of the form item is not limited to a predetermined layout and can be freely defined.

FIG. 8 shows the form item transfer sheet 32 of the design document 2 according to the first embodiment. As shown in FIG. 8, in the form item transfer sheet 32, the design relating to DB mapping is described in the upper table 32a. In addition, the table 32b at the bottom describes the editing process performed when transferring from the transfer source screen item, DB, or file to the transfer destination form item, DB, or file. That is, the form item transfer sheet 32 describes information for mutual transfer of screen items, form items, DB items, and file items (XML file, EXCEL file). The form item transfer sheet 32 describes the form item transfer information when the transfer destination is the form item among these combinations. As the form item transfer information, on page 13, there is a blank between the "insured person's name (surname)" and the "insured person's name (given name)" as the display contents of the form item "insured person's name". Editing processes marked with (□) are shown.

Here, functions of the framework 1 will be described. The framework 1 outputs a screen 40 and a form 50 by analyzing design information extracted from the design document 2 . The method itself by which the framework 1 extracts and analyzes design information is not particularly limited. As described above, each sheet of design document 2 is described in a predetermined format. Therefore, the framework 1 operates by referring to design information described according to the format of each sheet. Here, the display contents of the screen 40 and the form 50 based on the design information will be explained. First, the case of screen 40 will be described. In the following description, the framework 1 outputs the screen 40 based on the design document 2 shown in FIGS. 2 to 6 as an example.

FIG. 9 is a schematic diagram showing a part of the screen 40 displayed in the development target system according to the first embodiment. The screen 40 shown in FIG. 9 is obtained by the framework 1 acquiring the screen item definition information described in the screen item definition sheet 21 shown in FIG. indicate.

FIG. 10 is a schematic diagram showing part of the screen 40 displayed in the system to be developed according to the first embodiment. FIG. 10 shows an enlarged state in which list data is displayed in the screen item "form type" on the initial screen. Using the "form type" in FIG. 10 as an example, implementation of list data on the initial screen will be described.

First, the framework 1 reads the screen item definition sheet 21 of FIG. 2 and acquires "form type" (P1) as "'list data' <<item transfer>>" of the "form type". Next, the framework 1 refers to the list data sheet 22 in FIG. 3, since "list data" is set in the "form type". Then, the framework 1 applies the "blank", "2: Notification of change of name", "3: Notification of loss of eligibility/class change notification", and "4: Notification of moving out" described in "Document type" (P3) of the list data sheet 22. , and these list data are displayed as input candidates for "form type". In this manner, the framework 1 processes screen item definition information and list data information, thereby improving the degree of freedom in layout on the initial screen.

FIG. 11 is a schematic diagram showing part of the screen 40 displayed in the development target system according to the first embodiment. FIG. 11 shows an enlarged view of the initial screen in which the result of screen item transfer is displayed in the screen item "employment insurance company number". Using the "employment insurance company number" in FIG. 11 as an example, implementation of screen item transfer on the initial screen will be described.

First, the framework 1 reads the screen item definition sheet 21 of FIG. get. Next, the framework 1 refers to the screen item transfer sheet 25 in FIG. Then, as shown in FIG. 11, the framework 1, as described in the "employment insurance company number" (P11) of the screen item transfer sheet 25, for the information acquired from the transfer source table, Edit processing is performed to add symbols such as "-" and ":" to each predetermined number of digits, and the result is displayed as the input content of the "employment insurance company number". In this way, the framework 1 processes the screen item definition information and the screen item transfer information, so that various types of display contents can be displayed on the initial screen, so the layout flexibility on the initial screen is improved. is doing.

FIG. 12 is a schematic diagram showing part of the screen 40 displayed in the development target system according to the first embodiment. FIG. 12 shows an enlarged state in which object control is performed on screen items. Using FIG. 12 as an example, implementation of object control when an event occurs will be described.

First, the framework 1 reads the action specification sheet 23 of FIG. , the "form type" and "name change notification" (P6) are obtained. Next, the framework 1 refers to the object control sheet 24 of FIG. 5 because the "process content" of the "form type" is "-" and "object control" is described. Then, as shown in FIG. 12, the framework 1, as described in the "form type" and "name change notification" (P10) of the object control sheet 24, "date of separation from work, date of transfer, etc." is deactivated, and "insured person name", "indication of loss cause/insured person classification change", and "name after change" are activated.

Although an example screen is not shown, implementation of list data when an event occurs will also be described. First, the framework 1 reads the action specification sheet 23 of FIG.・Insured person classification change display (name change)” (P7) Next, in framework 1, the “process content” of the “form type” is “-” and the “list data” is entered. Therefore, reference is made to list data sheet 22 in FIG. Framework 1 is based on the "blank", "1: change due to marriage", and "2: divorce Acquire list data of "Change due to change" and "9: Others", and display these list data as input candidates for "Display of loss cause/insured person classification change".

Similarly, first, the framework 1 reads the action specification sheet 23 in FIG. >>”, acquires “‘Cause of Loss/Indication of Change in Insured Person Classification (Notification of Disqualification/Notice of Classification Change)” (P8). , and "list data" is described, the list data sheet 22 in FIG. 3 is referred to. Framework 1 is based on the “Blank” and “1: Reasons other than separation from employment” described in the “Cause of Loss/Change of Insured Person Classification (Notification of Loss of Qualification/Notice of Classification Change)” (P5) of List Data Sheet 22. ”, “2: Job separation/insured person classification change other than 3 and 6”, “3: Job separation due to business reasons”, and “6: Retirement age of 65, etc.” It is displayed as an input candidate for "display of loss cause/insured person classification change".

In this way, the framework 1 can sort the display of input candidates in the combo box "display cause of loss/insured person classification change" according to the input contents of another screen item "form type".

Although an example of a screen is not shown, implementation of screen item transfer when an event occurs will also be described. First, the framework 1 reads the action specification sheet 23 of FIG. get. Next, in the framework 1, the "process content" is "-" and the "employment insurance company number" is set to <<item transfer>>, so the screen item transfer sheet 25 in FIG. 6 is referred to. Then, as described in "Employment Security Office" (P12) of the screen item transfer sheet 25, the framework 1 extracts the second character from the left of the information acquired from the transfer source table. Edit processing is performed and displayed as the input content of "Employment Security Office".

Next, the case of the form 50 will be explained. FIG. 13 is a diagram showing a form 50 output by the development target system according to the first embodiment. FIG. 13 shows a form 50 called "notification of loss of eligibility for employment insurance". As shown in FIG. 13, the framework 1 acquires the form item definition information described in the form item definition sheet 31 of FIG. 7, and displays each form item on the form 50 based on the acquired form item definition information. do.

Also, the framework 1 reads the form item transfer sheet 32 of FIG. As shown in P14 of FIG. 13, as described in "Name of insured person" (P13) of the report item transfer sheet 32, "Name of insured person (last name)" obtained from the transfer source table is Editing processing is performed to put a blank (□) between it and the “name of the insured person”.

14 is a flowchart showing a system development method according to Embodiment 1. FIG. In the conventional development method, for example, when implementing object control, the steps of program design and program development/testing were required. Also, it is necessary to conduct an integration test with other programs and systems. On the other hand, in this system development method, as shown in FIG. (S2). As a result, the framework 1 is driven and the system under development operates. By performing a system test corresponding to the system basic design (S3), the quality of the system to be developed can be ensured. As described above, according to this system development method, since the source corresponding to the design contents is not produced, program design, program development/test, and integration test can be omitted.

As described above, according to the system development method of Embodiment 1, the framework 1 reads the design information from the design document 2, so that the system can be implemented without coding, and the development man-hours can be reduced. can. In addition, it is possible to reduce the number of test man-hours while maintaining quality. Furthermore, changes in design information can be immediately reflected in the system, improving productivity in system development.

The above is a description of the embodiments of the present disclosure, but the present disclosure is not limited to the configurations of the above embodiments, and various modifications and combinations are possible within the scope of the technical idea. . For example, the framework 1 does not have to be configured to read the design information directly from the design document 2 . In this case, for example, the design information may be registered in the design information DB, and the framework 1 may read the design information from the design information DB. For registration in the design information DB, for example, a dedicated definition tool is used. The definition tool extracts design information from the design document 2 written in a predetermined format and registers it in the design information DB.

Further, in Embodiment 1, the framework 1 may analyze and omit part of the design information targeted for non-coding control. The framework 1 may analyze at least one of screen item definition, form item definition, list data, screen item transfer, form item transfer, or action specification and object control as design information. Even if any design information is analyzed, a part of the system can be implemented without coding, and a reduction in development man-hours can be realized.

In addition to the description on the design document 2, various tools may be used as design aids. For example, in designing screen item definitions, a dedicated screen visual editor may be used. The screen visual editor is a WYSIWYG editor that can design the screen layout while confirming the actual screen image in requirements definition and system basic design. A dedicated editor may also be used for the form 50 as well.

However, the analysis target of the framework 1 does not have to be limited to the design information included in the design document 2 . For example, information such as the display position of screen items may be read into the framework 1 from a file other than the design document 2 . Further, for example, for processing other than "-" in the action specification sheet 23, a skeleton source code may be created with the processing content as a comment. A necessary portion of the skeleton source code is coded by the developer and read into the framework 1 .

1 framework, 2 design document, 10 computer, 11 storage device, 12 processing device, 13 display, 21 screen item definition sheet, 22 list data sheet, 23 action specification sheet, 24 object control sheet, 25 screen item transfer sheet, 25a Table, 25b Table, 31 Form Item Definition Sheet, 32 Form Item Transfer Sheet, 32a Table, 32b Table, 40 Screen, 50 Form.

A system development method according to the present disclosure includes a step of storing a design document in which design information is described in a memory , a step of reading the design information from the design document stored in the memory by the framework, and a step of reading the design information from the design document stored in the memory . and a step of generating a screen or a form of the system to be developed for testing based on the design information, and the design information defines the screen items by setting arbitrary design items among the plurality of design items. screen item definition information, form item definition information that defines form items by setting arbitrary design items among multiple design items, list data information that defines lists displayed as input candidates for screen items, Screen item transfer information that defines editing processing when displaying screen items, form item transfer information that defines editing processing when displaying form items, or actions that define screen item actions for each event occurrence timing At least one of specification information and object control information defining the display form of screen items is included as an action.

Claims (6)

A process of creating a design document containing design information;
a framework reading the design information from the design document;
The design information is
screen item definition information for defining a screen item by setting any of the design items among a plurality of design items;
Form item definition information for defining a form item by setting an arbitrary design item among a plurality of design items;
list data information that defines a list displayed as input candidates for the screen item;
screen item transfer information that defines editing processing when displaying the screen item;
Form item transfer information that defines the editing process when displaying the form item, or action specification information that defines the action of the screen item for each event occurrence timing, and the display format of the screen item as the action defining object control information. The design information is
The system development method according to claim 1, further comprising the action specification information and the list data information as the action defined by the action specification information. The design information is
2. The system development method according to claim 1, further comprising the action specification information and the screen item transfer information as the action defined by the action specification information. The design information is
including the screen item definition information and the list data information,
2. The system development method according to claim 1, wherein the layout of the initial screen is freely designed based on the screen item definition information and the list data information. The design information is
including the screen item definition information and the screen item transfer information,
2. The system development method according to claim 1, wherein the layout of the initial screen is freely designed based on the screen item definition information and the screen item transfer information. further comprising a step of registering the design information from the design document in a design information DB;
6. The system development method according to claim 1, wherein said framework reads said design information via said design information DB.

Images