JP2024074124A - Information processing device and program - Google Patents

Abstract

[Problem] To provide an information processing device and a program capable of supporting verification work after a service is implemented. [Solution] The system includes a selection means for selecting one of the service nodes corresponding to the last measure from tree data in a tree structure in which the relationship between business goals and measures for achieving the goals are set in stages by nodes, a reading means for reading design information of the selected service node from a design information storage unit that stores design information associated with each of the service nodes and indicating the settings of the measures corresponding to the service nodes at the design stage, a generation means for generating test cases for verifying the state after the implementation of the measures corresponding to the selected service node based on the design information read by the reading means, and a storage control means for storing the test cases generated by the generation means in a storage unit in association with the selected service node. [Selected Figure] FIG.

Description

An embodiment of the present invention relates to an information processing device and a program.

At stores and other locations, a variety of services are provided. In these locations, the processing procedures for each element involved in the implementation of the service may be designed as a business flow using methods such as the Key Performance Indicator (KPI) tree method or Business Process Model and Notation (BPMN). For example, technology has been proposed that can automatically create a business flow so that the input/output relationships between adjacent tasks are continuous.

The above-mentioned method makes it possible to design the processing procedures for implementing a service while checking the processing procedures of each element and the relationships between elements. However, conventional methods do not take into consideration the processing that occurs after the service is actually implemented, and it is not easy to verify whether the designed service is being implemented as expected.

The problem that this invention aims to solve is to provide an information processing device and program that can support verification work after a service is implemented.

The information processing device of the embodiment includes a selection means, a read means, a generation means, and a storage control means. The selection means selects one of the service nodes corresponding to the last measure from tree data in a tree structure in which the relationship between business goals and measures for achieving the goals are set in stages by nodes. The read means reads out design information of the selected service node from a design information storage unit that stores design information associated with each of the service nodes and indicating the settings of the measures corresponding to the service nodes at the design stage. The generation means generates a test case for verifying the state after the implementation of the measure corresponding to the selected service node based on the design information read by the read means. The storage control means stores the test case generated by the generation means in the storage unit in association with the selected service node.

FIG. 1 is a diagram illustrating an example of a configuration of a task support system according to an embodiment. FIG. 2 is a diagram illustrating an example of a hardware configuration of a terminal device according to the embodiment. FIG. 3 is a diagram illustrating an example of a hardware configuration of a server device according to the embodiment. FIG. 4 is a diagram illustrating an example of a data configuration of a KPI tree DB according to the embodiment. FIG. 5 is a diagram illustrating an example of a visualized KPI tree according to the embodiment. FIG. 6 is a diagram illustrating an example of a data configuration of a business flow DB according to the embodiment. FIG. 7 is a diagram illustrating an example of a visualized business flow according to the embodiment. FIG. 8 is a diagram illustrating an example of a data configuration of a cost DB according to the embodiment. FIG. 9 is a diagram illustrating an example of a data configuration of a checklist DB according to the embodiment. FIG. 10 is a diagram illustrating an example of a data configuration of a test case DB according to the embodiment. FIG. 11 is a diagram illustrating an example of a functional configuration of a terminal device and a server device according to the embodiment. FIG. 12 is a diagram illustrating an example of a screen provided by the design support unit according to the embodiment. FIG. 13 is a diagram illustrating an example of a screen provided by the design support unit according to the embodiment. FIG. 14 is a diagram illustrating an example of a screen provided by the test case creation support unit according to the embodiment. FIG. 15 is a diagram illustrating an example of a screen provided by the test case creation support unit according to the embodiment. FIG. 16 is a diagram illustrating an example of a screen provided by the test case creation support unit according to the embodiment. FIG. 17 is a flowchart illustrating an example of a process related to the creation of a test case executed by the server device according to the embodiment.

The following describes the embodiments in detail with reference to the drawings. Note that the present invention is not limited to the embodiments described below.

FIG. 1 is a diagram showing an example of the configuration of a business support system according to an embodiment. As shown in FIG. 1, the business support system 1 has a terminal device 10 and a server device 20. The terminal device 10 and the server device 20 are connected to each other so as to be able to communicate with each other via a network N such as a LAN (Local Area network).

The terminal device 10 is a terminal device used by a user of the business support system 1. The terminal device 10 executes various processes in response to user operations. For example, the user operates the terminal device 10 to access the server device 20, thereby utilizing various functions provided by the server device 20. The terminal device 10 can be realized by a stationary terminal device such as a PC (Personal Computer), or a portable terminal device such as a notebook PC, tablet terminal, or smartphone.

The server device 20 is an example of an information processing device. The server device 20 provides various functions to the terminal device 10. For example, the server device 20 provides functions for creating and viewing KPI trees, business flows, cost information, checklists, test cases, etc., which will be described later.

In this embodiment, an example in which the server device 20 is realized by a single information processing device will be described, but this is not intended to be limiting. For example, the server device 20 may be realized by multiple information processing devices using technology such as cloud computing.

Next, the configuration of the terminal device 10 and server device 20 described above will be described.

Figure 2 is a diagram showing an example of the hardware configuration of the terminal device 10. As shown in Figure 2, the terminal device 10 has a computer configuration including a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, and a RAM (Random Access Memory) 13.

The CPU 11 is an example of a processor, and controls each part of the terminal device 10. The ROM 12 stores various programs. The RAM 13 is a workspace in which programs and various data are deployed.

The terminal device 10 also includes a display unit 14, an operation unit 15, a memory unit 16, and a communication unit 17.

The display unit 14 is composed of a display device such as an LCD (Liquid Crystal Display). The display unit 14 displays various information under the control of the CPU 11. The operation unit 15 has a keyboard, a pointing device, etc. The operation unit 15 outputs the operation content received from the user to the CPU 11. The operation unit 15 may be a touch panel provided on the display screen of the display unit 14.

The storage unit 16 is composed of a storage medium such as a hard disk drive (HDD) or flash memory, and maintains the stored contents even when the power is cut off. The storage unit 16 stores programs that the CPU 11 can execute and various setting information. For example, the storage unit 16 stores application programs such as a web browser that can utilize various functions provided by the server device 20.

The CPU 11 executes various processes by operating according to programs stored in the ROM 12 and memory unit 16 and deployed in the RAM 13.

The communication unit 17 is a communication interface that can be connected to the network N. The communication unit 17 communicates with external devices such as the server device 20 via the network N.

Figure 3 is a diagram showing an example of the hardware configuration of the server device 20. As shown in Figure 3, the server device 20 has a computer configuration including a CPU 21, a ROM 22, and a RAM 23.

The CPU 21 is an example of a processor, and controls each part of the server device 20. The ROM 22 stores various programs. The RAM 23 is a workspace in which programs and various data are deployed.

The server device 20 also includes a display unit 24, an operation unit 25, a memory unit 26, and a communication unit 27.

The display unit 24 is composed of a display device such as an LCD. The display unit 24 displays various information under the control of the CPU 21. The operation unit 25 has a keyboard, a pointing device, etc. The operation unit 25 outputs the operation content received from the user to the CPU 11. The operation unit 25 may be a touch panel provided on the display screen of the display unit 24.

The memory unit 26 is an example of a storage device. The memory unit 26 is composed of a storage medium such as a HDD or flash memory, and maintains the stored contents even when the power is cut off. The memory unit 26 stores programs that the CPU 21 can execute and various setting information. For example, the memory unit 26 stores web application programs that can provide various functions to the terminal device 10. The CPU 21 executes various processes by operating according to the programs stored in the ROM 22 or the memory unit 26 and deployed in the RAM 23.

The memory unit 26 also stores a KPI tree DB 261, a business flow DB 262, a cost DB 263, a checklist DB 264, and a test case DB 265, etc.

The KPI tree DB261 is a database for storing and managing KPI trees. Here, a KPI tree is tree data in a tree structure in which the relationship between the business goals of an organization or company (final goals, described below) and the measures for achieving those goals (intermediate goals, causes, solutions, services, etc., described below) is set in a hierarchical manner by nodes.

Figure 4 is a diagram showing an example of the data configuration of the KPI tree DB 261. As shown in Figure 4, the KPI tree DB 261 associates the KPI tree with an identifiable tree ID and stores the tree name, the KPI tree, etc.

In the tree name field, information indicating the name of the KPI tree is registered. In addition, in the KPI tree field, the actual data of the KPI tree (hereinafter also referred to as a data file) or the address indicating the storage location of the data file is registered.

The KPI tree is created using a method such as KPI (Key Performance Indicator). The KPI tree can be displayed in a visualized form, for example, as shown in Figure 5.

Figure 5 is a diagram showing an example of a visualized KPI tree. Note that Figure 5 shows a visualized KPI tree of the tree name "ABC Supermarket KPI Tree" shown in Figure 4.

As shown in FIG. 5, the KPI tree is made up of multiple nodes connected in a tree structure. Here, the final goal node A, which is the root node, is a node for setting the goal to be achieved. The final goal node A corresponds to, for example, a KGI (Key Goal Indicator). For example, if the final goal is to increase store sales, "sales" or the like is set in the final goal node A.

One or more intermediate goal nodes B are connected to the final goal node A. One or more intermediate goal nodes B can also be connected to the intermediate goal node B. In the intermediate goal node B, an intermediate goal is set to achieve the goal (final goal or intermediate goal) set in the node immediately above. The intermediate goal node B corresponds to, for example, KPIs (Key Performance Indicators).

Figure 5 shows an example in which intermediate goal node Ba, which has the intermediate goal of increasing the number of customers visiting the store set as an intermediate goal, and intermediate goal node Bb, which has the intermediate goal of increasing the average customer spending set as an intermediate goal, are placed below final goal node A. Also, an example is shown in which intermediate goal node Bc, which has the intermediate goal of increasing the number of retailers set as an intermediate goal, and intermediate goal node Bd, which has the intermediate goal of increasing the unit price of an item are placed below intermediate goal node Bb.

In addition, in the KPI tree, it is possible to place a factor node C below an intermediate goal node B, which represents a factor for achieving the intermediate goal set in this intermediate goal node B. The factor node C corresponds to, for example, a KSF (Key Success Factor).

Figure 5 shows an example in which factor nodes Ca to Cd, in which "improved quality," "product lineup," "sales floor," and "advertising" are set as factors for increasing the number of customers, are placed below intermediate goal node Ba. Also, an example is shown in which factor nodes Ce and Cf, in which "sales promotion" and "impulse buying" are set as factors for increasing sales points, are placed below intermediate goal node Bc. Also, an example is shown in which factor node Cg, in which "improved customer understanding" is set as a factor for increasing the average customer spending, is placed below intermediate goal node Bb.

In addition, in a KPI tree, it is possible to place a solution node D, which represents a solution method for realizing (solving) the intermediate objective or factor set in the node immediately above, under an intermediate goal node B or factor node C.

Figure 5 shows an example in which solution nodes Da and Db, in which "store information visualization" and "product lineup optimization" are set, are placed below factor nodes Ca to Cc. Also, an example is shown in which solution nodes Dc to De, in which "coupon issuance," "points management," and "POP creation" are set, are placed below factor node Ce. Also, an example is shown in which solution node Df, in which "CRM (Customer Relationship Management)" is set, is placed below factor node Cg.

In addition, in the KPI tree, it is possible to place a service node E, which represents a specific service for realizing the cause or solution method set in the node immediately above, under a factor node C or solution node D. Here, the service node E corresponds to the measure at the end.

Figure 5 shows an example in which a service node Ea with "Service A" set is placed under solution node Df.

Each node that makes up the KPI tree is assigned a node ID to identify it. The KPI tree is saved in, for example, JSON (JavaScript Object Notation) format. Note that the format in which the KPI tree is saved is not limited to JSON, and it may be saved in other data formats such as XML (Extensible Markup Language).

Returning to FIG. 3, the business flow DB 262 is a database for storing and managing business flows. A business flow is a data file in which each element related to the performance of a business and the execution contents executed by the element are described as a series of procedures. For example, a business flow describes, for each element related to the implementation of a service, the execution contents and procedures executed by the element.

Figure 6 is a diagram showing an example of the data configuration of the business flow DB 262. As shown in Figure 6, the business flow DB 262 associates the business flow with an identifiable flow ID and stores the target service, business flow name, business flow, etc.

In the target service field, information is registered that specifies the service that corresponds to the business that is the subject of the business flow description. Specifically, the node ID of the service node E specified as the target service, the tree ID of the KPI tree to which the service node E belongs, etc. are registered. Note that the method of specifying the target service is not limited to this.

In the business flow name field, information indicating the name of the business flow is registered. For example, the node name of the corresponding service node E can be set as the business flow name. In addition, in the business flow field, the address indicating the data file of the business flow or the storage destination of the data file is registered.

The business flow is created using techniques such as flowcharts and BPMN (Business Process Modeling Notation). The business flow can be represented in a visualized form, for example as shown in Figure 7.

Figure 7 is a diagram showing an example of a visualized business flow. Note that Figure 7 shows an example of a business flow related to service node Ea (service A) of the KPI tree shown in Figure 5.

As shown in Figure 7, in the business flow, between a start event ST and an end event EN, a series of operations (or processes) relating to the implementation of service A are described for each element that performs the operation. The business flow in Figure 7 shows an example in which the elements described are "customers" who visit a store, "surveillance cameras" and "payment system" installed in the store, and "store staff" who work at the store.

Here, the "surveillance cameras" are hardware resources, and are installed, for example, in multiple locations in a store. The "payment system" is a software resource, and is implemented by a PC (Personal Computer) such as a POS installed in the store. It is assumed that the use of a PC as an element of the hardware resources related to the implementation of the "payment system" is set in the business flow or in association with the business flow. Also, for example, a points service that gives points to "customers" according to the purchase amount as an additional service provided by the "payment system" may be included in the business flow as an independent element.

Hereinafter, the hardware resources, software resources, and additional services involved in implementing the target service are collectively referred to as "elements." The definition of an element may be included in the business flow, for example, or may be stored in association with the service node E of the target service. Furthermore, elements may include human resources such as store clerks.

In the business flow of Figure 7, the flow of a "customer" is described as first coming to the store (step Qa), selecting the product to be purchased (step Qb), and proceeding to the cash register (step Qc). The flow of a "surveillance camera" installed in the store is described as taking a picture of the "customer" heading to the cash register (step Qd) and sending the captured image data to a payment system installed in the store (step Qe). The flow of the "payment system" is described as receiving the captured image data from the "surveillance camera" (step Qf), and displaying customer information such as the attributes of the "customer" derived from the captured image data on a display device (step Qg).

The flow for the "clerk" who operates the cash register is described as checking the customer information displayed by the "payment system" (step Qh) and performing the cash register procedure for the items brought in by the "customer" (step Qi). It is also described that, in conjunction with the cash register procedure performed by the "clerk," the "payment system" executes "payment processing" (step Qj).

It is also described that the "customer" pays for the product in accordance with the "payment process" of the "payment system" (step Qk) and leaves the store (step Ql). It is also described that the "payment system" saves data showing the details of this transaction upon payment (step Qm).

When implementing a points service, for example, the payment system identifies the membership number of the "customer" shown in the photographed data by comparing the photographed data received in step Qf with the facial images of each member registered in advance. The payment system then accumulatively stores the points issued according to the purchase amount in association with the identified membership number.

The above-mentioned business flow is saved in, for example, JSON format. Note that the format in which the business flow is saved is not limited to JSON, and it may be saved in other data formats such as XML.

Returning to FIG. 3, cost DB263 is a database for storing and managing cost information indicating the estimated costs required to implement a service. Cost DB263 is an example of a design information storage unit.

Figure 8 is a diagram showing an example of the data configuration of cost DB263. As shown in Figure 8, cost DB263 stores target services, cost information, etc. in association with a cost ID for identifying each piece of cost information.

In the target service field, information is registered that specifies the service for which costs are to be calculated. Specifically, the node ID of the service node E specified as the target service, the tree ID of the KPI tree to which the service node E belongs, etc. are registered. Note that the method of specifying the target service is not limited to this. For example, the target service may be indirectly specified by registering the flow ID of a business flow that has the same service as a target service.

The cost information has items such as name, type, quantity, implementation cost, and operation cost. The name of the object for which costs are calculated is registered in the name item. For example, the names of elements related to the implementation of the target service are registered in the name item. Note that Figure 8 shows an example in which "surveillance camera," "payment system," "PC," and "point service," which were explained in the business flow of Figure 7, are registered in the name item. Hereinafter, the object for which costs are calculated will be referred to simply as "element."

In the type field, information indicating the type of element is registered. Figure 8 shows an example in which the types "surveillance camera" and "PC" are registered as hardware resources (HW). It also shows an example in which the type of "payment system" is registered as a software resource (SW). It also shows an example in which the type of "point service" is registered as the service "Service."

The quantity field contains information indicating the quantity of an element. Figure 8 shows an example in which the quantity of "surveillance cameras" is "5", the quantity of "PCs" is "1", the quantity of "payment systems" is "1", and the quantity of "point services" is "1".

The "Installation cost" field contains information indicating the estimated cost required to install an element. Figure 8 shows an example in which "30,000" yen has been registered as the cost of installing five "surveillance cameras." It also shows an example in which "300,000" yen has been registered as the cost of installing one "PC."

The operating cost item stores information indicating the estimated cost required to operate the element. Here, operation means operating costs for a specified period, such as operating costs per month. Figure 8 shows an example in which "7,000" yen has been registered as the monthly operating cost for the "payment system." It also shows an example in which "10,000" yen has been registered as the monthly operating cost for the "points service."

Note that the data configuration of cost DB263 is not limited to that of FIG. 8. For example, cost DB263 may store, in association with cost information, the user ID of the user who input (or updated) the cost information and date and time information indicating the input (or update) date.

Returning to FIG. 3, checklist DB264 is a database for storing and managing checklists for checking requirements related to the implementation of a service. Checklist DB264 is an example of a design information storage unit.

Figure 9 is a diagram showing an example of the data configuration of checklist DB264. As shown in Figure 9, checklist DB264 stores target services, check targets, checklists, etc. in association with a checklist ID for identifying the checklist.

In the target service field, information specifying the service to be checked is registered. Specifically, the node ID of the service node E specified as the target service, the tree ID of the KPI tree to which the service node E belongs, etc. are registered. Note that the method of specifying the target service is not limited to this. For example, the target service may be indirectly specified by registering the flow ID of a business flow that has the same service as a target service.

In the check target item, information indicating the check target is registered. For example, the names of elements such as hardware resources and software resources related to the implementation of the target service are registered as check targets. For example, if the service of service node Ea described in Figure 5 is the target service, elements such as "surveillance camera" and "payment system" are registered as check targets, as shown in Figure 9. Note that the check target is not limited to elements, and the entire service may be the target for checking (corresponding to "whole" in Figure 9).

Checklist items include the checklist data file or an address indicating where the data file is stored. A checklist is created, for example, for each check target, and includes one or more check items (confirmation items) according to the check target. For example, a checklist may include check items for non-functional requirements. Here, "non-functional requirements" refer to requirements other than the function of the target element, and examples include requirements such as the target's performance, availability, and security.

The above-mentioned business flow, cost information, and checklist are created in the design stage of the service set in the KPI tree. For example, the cost information is set with estimated implementation and operating costs for elements related to the implementation of the service (or business flow) planned in the design stage. Also, the checklist is set with various check items related to the implementation of the service (or business flow) planned in the design stage. Here, the cost information and checklist are examples of design information that indicate the settings in the design stage of the service corresponding to service node E.

The KPI tree, business flow, cost information, and checklist may be created in advance, or may be created via the terminal device 10, etc. with the server device 20 providing support for the creation. In the latter case, for example, the server device 20 provides the terminal device 10 with an operation screen (GUI (Graphical User Interface)) for supporting the viewing, creation, and editing of the KPI tree, business flow, cost information, and checklist.

Specifically, the server device 20 provides the terminal device 10 with a screen on which the KPI tree can be created and edited while visualizing various nodes and the relationships between the nodes. Then, when the server device 20 completes the creation or editing of the KPI tree, it stores the KPI tree in the KPI tree DB 261.

When any of the service nodes E included in the KPI tree is selected, the server device 20 provides a screen on which a business flow, cost information, and checklist can be created and edited for the service corresponding to the service node E. Then, when any of the business flow, cost information, and checklist is created, the server device 20 associates it with the node ID and tree ID of the service node E and stores it in the corresponding DB.

After implementing a service designed using a KPI tree, business tree, etc., the store implementing the service checks whether the service is operating as expected at the time of design. For example, the store implementing the service verifies whether the costs required for the introduction and operation of each element were as expected at the time of design. In addition, the store implementing the service performs verification work such as rechecking or reviewing check items depending on the situation after the service is implemented. Hereinafter, the data set used in the verification work to verify the state after the service is implemented is also referred to as a test case.

Test case DB265 is a database that stores and manages the above-mentioned test cases. Test case DB265 is an example of a storage unit.

Figure 10 is a diagram showing an example of the data configuration of test case DB265. As shown in Figure 10, test case DB265 associates a test case with an identifiable test case ID and stores the target service, test case name, creation date, creator name, test case, etc.

In the target service field, information is registered that specifies the service that is the target of the test case. Specifically, the node ID of the service node E specified as the target service, the tree ID of the KPI tree to which the service node E belongs, etc. are registered. Note that the method of specifying the target service is not limited to this.

The name of the test case is registered in the Test Case Name field. Any name can be set for the test case. For example, in the case of a test case used monthly, it is possible to include a name such as "Monthly Report."

The creation date field stores information indicating the date the test case was created. The creator name field stores information indicating the creator who created the test case.

In the test case item, the data file of the test case or the address indicating the storage destination of the data file is registered. Specifically, the test cases include a test case related to cost (hereinafter also referred to as the first test case) and a test case related to a check item (hereinafter also referred to as the second test case). Test case DB265 is capable of registering the data file or the storage destination of the data file for each of the first test case and the second test case.

Returning to FIG. 3, the communication unit 27 is a communication interface that can be connected to the network N. The communication unit 27 communicates with external devices such as the terminal device 10 via the network N.

Next, the functional configuration of the terminal device 10 and the server device 20 will be described with reference to FIG. 11. FIG. 11 is a diagram showing an example of the functional configuration of the terminal device 10 and the server device 20.

As shown in FIG. 11, the terminal device 10 has a display control unit 111 and an operation reception unit 112 as functional units.

Some or all of the functional units of the terminal device 10 may be software configurations realized by cooperation between the processor (e.g., CPU 11) of the terminal device 10 and a program stored in a memory (e.g., ROM 12, storage unit 16). Also, some or all of the functional units of the terminal device 10 may be hardware configurations realized by a dedicated circuit or the like mounted on the terminal device 10.

The display control unit 111 of the terminal device 10 controls the display unit 14 to display various screens on the display unit 14. For example, the display control unit 111 displays various operation screens on the display unit 14 based on information provided by the server device 20.

The operation reception unit 112 of the terminal device 10 receives user operations via the operation unit 15. For example, when the operation reception unit 112 receives an operation on the screen displayed on the display unit 14, it notifies the server device 20 of the content of the operation.

On the other hand, as shown in FIG. 11, the server device 20 has a GUI providing unit 211, a design support unit 212, a test case creation support unit 213, a display control unit 214, and an operation receiving unit 215 as functional units.

Some or all of the functional units of the server device 20 may be software configurations realized by cooperation between the processor (e.g., CPU 21) of the server device 20 and a program stored in a memory (e.g., ROM 22, storage unit 26). Also, some or all of the functional units of the server device 20 may be hardware configurations realized by a dedicated circuit or the like mounted on the server device 20.

The GUI providing unit 211 cooperates with other functional units to provide the terminal device 10 with information capable of displaying various operation screens (hereinafter also simply referred to as screens). Here, the GUI providing unit 211 may provide data representing the screens, or may provide various content data related to the display of the screens. Hereinafter, the provision of information related to the display of a screen by the GUI providing unit 211 to the terminal device 10 is also referred to as "providing" the screen or "displaying" the screen.

The design support unit 212 works in cooperation with the GUI provision unit 211 to provide a screen on which KPI trees, business flows, cost information, checklists, etc. can be viewed and created (edited).

For example, the design support unit 212 provides a screen on which a KPI tree to be viewed or edited can be selected based on the KPI tree DB 261. When a KPI tree is selected, the design support unit 212 reads the KPI tree from the KPI tree DB 261 and provides a screen on which the KPI tree is visualized.

In addition, when a service node E set in the KPI tree is selected, the design support unit 212 reads various information associated with the service node E from the business flow DB 262, the cost DB 263, and the checklist DB 264, and provides a screen (hereinafter also referred to as the design support screen) on which the read information can be viewed or edited.

Figures 12 and 13 are diagrams showing examples of screens provided by the design support unit 212. Note that Figures 12 and 13 show the design support screen when the service node Ea included in the KPI tree in Figure 5 is selected.

The design support screen 30 has tabs TA to TC. Tab TA is an operator for displaying the business flow related to the service of service node Ea. When tab TA is selected, the design support unit 212 reads out the business flow stored in association with the node ID and tree ID of service node Ea from the business flow DB 262, and displays the business flow in a visualized state in area 31.

Tab TB is an operator for displaying cost information related to the service of service node Ea. When tab TB is selected, the design support unit 212 reads out the cost information stored in association with the node ID and tree ID of service node Ea from the cost DB 263, and displays a screen based on the cost information in area 31 (see FIG. 12).

Specifically, the design support unit 212 displays an estimated cost screen in area 31, which includes a first display area 32 that displays the cost for each element, and a second display area 33 that displays the estimated cost for all elements.

The first display area 32 displays a list of the name, type, quantity, introduction cost, and operation cost of each element included in the cost information. The second display area 33 displays the total result of adding up the costs of each element displayed in the first display area 32. Specifically, the second display area 33 displays the total result of the costs, separated into introduction cost and operation cost.

This allows users designing a service to easily check the cost of each element and the cost required for the entire element by referring to the cost information displayed on the estimated cost screen.

Tab TC is an operator for displaying a checklist related to the service of service node Ea. When tab TC is selected, the design support unit 212 reads out the checklist stored in association with the node ID and tree ID of service node Ea from the checklist DB 264, and displays a check screen based on the checklist in area 31 (see FIG. 13).

Specifically, the design support unit 212 generates a tab for each checklist read from the checklist DB 264, and displays in the area 31 a check screen that can be switched by the tab. The screen that is displayed by the tab switching operation displays the check items included in the checklist that corresponds to the tab. In other words, the checklist can be switched by switching the tab.

In FIG. 13, tab TD corresponds to the checklist whose element is "Overall," tab TE corresponds to the checklist whose element is "Surveillance Camera," and tab TF corresponds to the checklist whose element is "Payment Service." In other words, the checklists are output in association with the corresponding elements.

In FIG. 13, the tab TD is selected, and the check items set for each of the operation-related and maintenance-related items are displayed. Each check item is associated with four options: "Not done," "Pending," "OK," and "NG," and the user can select one of the options.

This allows the user to easily check each check item related to the implementation of a service during the design stage by selecting the appropriate option while checking the contents of the check items for the element selected in tabs TD to TF.

In FIG. 13, the check items have four options, but the number and type of options are not limited to this. Also, a configuration may be adopted in which a character string can be input as an answer to the check items. In either case, it is possible to set the method of answering the check items at the checklist creation stage. The check results of the check items may be saved in the corresponding checklist, or may be saved in the form of a separate file associated with the checklist.

The design support unit 212 may also provide a screen that allows users to create and edit KPI trees, business flows, cost information, checklists, etc.

For example, the design support unit 212 provides a screen on which various nodes constituting a KPI tree and the relationships between the nodes can be created and edited. Then, when the design support unit 212 completes the creation or editing of a KPI tree, it stores the KPI tree in the KPI tree DB 261.

In addition, when a service node E is specified from the KPI tree, the design support unit 212 provides a screen on which the business flow, cost information, and checklist can be created and edited for the service corresponding to that service node E.

For example, the design support unit 212 provides a business flow creation screen on which drawing parts and the like corresponding to the BPMN notation rules are arranged. Then, when the design support unit 212 completes the creation or editing of the business flow, it associates the business flow with the node ID and tree ID of the specified service node E and stores the business flow in the business flow DB 262.

For example, the design support unit 212 provides a cost information creation screen on which the quantity, implementation cost, operating cost, etc. can be input for each element related to the implementation of the service based on the elements defined in the business flow. Then, when the design support unit 212 completes the creation of the cost information, it stores the cost information in the cost DB 263 in association with the node ID and tree ID of the specified service node E.

For example, the design support unit 212 provides a checklist creation screen that enables creation and editing of check items for each element related to the implementation of a service based on elements defined in a business flow, etc. Then, when the design support unit 212 completes the creation of a checklist, it stores the checklist in the checklist DB 264 in association with the node ID and tree ID of the specified service node E.

Returning to FIG. 11, the test case creation support unit 213 is an example of a selection means, a read means, a generation means, a storage control means, and an output means. The test case creation support unit 213 cooperates with the GUI provision unit 211 to provide a screen for supporting the viewing and creation (editing) of test cases.

For example, when the test case creation support unit 213 receives an instruction to start creating a test case, it provides a screen on which a target KPI tree can be selected based on the KPI tree DB 261. Furthermore, when a KPI tree is selected, the test case creation support unit 213 reads the KPI tree from the KPI tree DB 261 and provides a screen on which the KPI tree is visualized.

When a service node E set in the KPI tree is selected, the test case creation support unit 213 reads out the cost information and checklist associated with the service node E from the cost DB 263 and the checklist DB 264. Then, the test case creation support unit 213 provides a screen for supporting the creation and editing of a checklist (hereinafter also referred to as a creation support screen) based on the read cost information and checklist.

Figures 14 and 15 are diagrams showing examples of screens provided by the test case creation support unit 213. Note that Figures 14 and 15 show the creation support screen when service node Ea included in the KPI tree in Figure 5 is selected.

The creation support screen 40 has tabs TG and TH. Tab TG is an operator related to the creation of a cost-related test case (first test case). When tab TG is selected, the test case creation support unit 213 generates a screen in which the first test case can be edited (hereinafter also referred to as the first test case screen) based on the cost information, and displays it in area 41 (see FIG. 14).

As shown in FIG. 14, the first test case screen displays, for each element related to the implementation of the selected service (service node Ea), the name, type, quantity, initial cost (planned), operating cost (planned), initial cost (actual), and a remarks field for that element. Here, the name, type, quantity, initial cost (planned), and operating cost (planned) of each element correspond to the name, type, quantity, implementation cost, and operating cost of the element contained in the cost information read from cost DB263.

Initial cost (actual) is a newly added item, and it is possible to input an actual value, which is the estimated amount of the initial cost that is determined after the service is implemented. Here, the initial cost (actual) and remarks items are added in an empty state by default, and any numerical value can be input by the user. Specifically, the cost of hardware resources, software resources, and additional services actually required to implement the service is input in the initial cost (actual) item. The remarks column is also a newly added item. The user who creates and edits the test case can input any information in the remarks column.

The first test case screen also has an Add button 42, which is an operator for instructing the addition of a new component. When the test case creation support unit 213 accepts the operation of the Add button 42, it provides a screen on which elements such as hardware resources, software resources, and additional services can be added, and adds the element selected by the user operation and displays it in the area 41.

For example, the test case creation support unit 213 provides a screen on which an element to be added can be selected from multiple types of elements registered in advance. For the added element, information can be entered in the initial cost (actual results) and remarks fields, etc.

On the other hand, the tab TH is an operator for creating a test case (second test case) related to the checklist. When the tab TH is selected, the test case creation support unit 213 generates a screen on which the second test case can be edited (hereinafter also referred to as the second test case screen) based on the checklist, and displays it in the area 41 (see FIG. 15).

As shown in FIG. 15, the second test case screen has tabs corresponding to each element of the read checklist. In FIG. 15, there is a tab TI corresponding to "Overall," a tab TJ corresponding to "Surveillance Camera," and a tab TK corresponding to "Payment Service."

Here, when one of the tabs TI to TK is selected, the test case creation support unit 213 displays the check items included in the checklist of the element corresponding to the selected tab in an editable state. Figure 15 shows an example in which the tab TI corresponding to "Overall" has been selected, and the various check items set in the "Overall" checklist are displayed in an editable state.

Specifically, a character string representing the content of the check item is displayed in an input field 43. In this input field 43, the character string can be edited by a user operation. In addition, an empty input field 43 is also provided, and a new check item can be created by inputting any character string. Note that an empty input field 43 can be added by operating an add button 44.

This allows the user who creates or edits the test case to easily edit the check items in the checklist used during service design and add new check items depending on the situation after the service is implemented. In addition, on the second test case screen, it is also possible to edit or add categories of check items (operation-related, maintenance-related, etc.).

When the test case creation support unit 213 receives an operation on the creation support screen instructing completion of editing, it generates a test case based on the edited content. Specifically, the test case creation support unit 213 generates a first test case that reflects the edited content on the first test case screen. In addition, the test case creation support unit 213 generates a second test case that reflects the edited content on the second test case screen.

Then, the test case creation support unit 213 registers the generated first test case and second test case as a set of checklists in the test case DB 265 in association with the node ID and tree ID of the selected service node E. The test case creation support unit 213 also registers the user ID of the user who instructed the creation of the checklist and the creation date in the test case DB 265 in association with the checklist.

In this way, the test case creation support unit 213 generates test cases related to the confirmation work after the service is implemented based on the cost information and checklist created when the service was designed. This allows the system to utilize the cost information and checklist created when the service was designed for the verification work after the service is implemented.

The test case creation support unit 213 also provides a screen that displays a list of test cases registered in the test case DB 265.

For example, when one KPI tree is selected from the KPI trees registered in the KPI tree DB 261, the test case creation support unit 213 reads out the name of the test case associated with the tree ID of the selected KPI tree from the test case DB 265. Then, the test case creation support unit 213 provides a screen (hereinafter also referred to as the list screen) that displays a list of the read test cases.

Figure 16 is a diagram showing an example of a screen provided by the test case creation support unit 213. Note that Figure 16 shows a list screen when the KPI tree in Figure 5 is selected.

The list screen 50 has an area 51. The test case creation support unit 213 displays a list of test cases read from the test case DB 265 in the area 51. Figure 16 shows an example in which, for each test case read from the test case DB 265, the test case name, creation date, creator, etc. of the test case are displayed in a list.

Here, the listed test cases can be selected, and by selecting one of the test cases, an operation menu 52 is displayed that allows the user to instruct operations for that test case. The operation menu 52 has options (or operators) such as "Perform Test," "Edit," "Rename," and "Delete," for example.

"Perform Test" is an option for instructing the execution of a test using the check items included in the second test case. When "Perform Test" is selected, the test case creation support unit 213 generates a check screen from the second test case of the selected test case and provides the generated check screen. The check screen based on the second test case may be provided, for example, in a form similar to the check screen in FIG. 13, or in a different form. The check results entered in the second test case may be included in and saved in the second test case, or may be saved in a separate file associated with the second test case.

"Edit" is an option for instructing editing of the first test case and the second test case. When "Edit" is selected, the test case creation support unit 213 provides the creation support screen described in Figures 14 and 15 based on the first test case and the second test case of the selected test case. For example, "Edit" is selected when entering an initial cost (actual cost) for the first test case.

"Change name" is an option for instructing a change to the test case name. When "Change name" is selected, the test case creation support unit 213 makes the test case name of the selected test case editable.

"Delete" is an option for instructing the deletion of a test case. When "Delete" is selected, the test case creation support unit 213 deletes the selected test case from the test case DB 265.

The options in the operation menu 52 are not limited to the example in FIG. 16. For example, the operation menu 52 may include an option to instruct the user to create a copy of a test case.

The list screen 50 also has an Add button 53 for instructing the addition of a test case. When the Add button 53 is operated, for example, the test case creation support unit 213 provides a screen in which a service node E for which a test case is to be created can be selected from the selected KPI tree. Then, the test case creation support unit 213 provides the creation support screen described in FIG. 14 and FIG. 15 for the selected service node E.

Returning to FIG. 11, the display control unit 214 of the server device 20 controls the display unit 24 to display various screens on the display unit 24. For example, the display control unit 214 causes the display unit 24 to display various screens provided by the GUI providing unit 211.

The operation reception unit 215 of the server device 20 receives user operations via the operation unit 25. For example, when the operation reception unit 215 receives an operation on various operation support screens displayed on the display unit 24, it outputs the operation content to the CPU 21.

An example of the operation of the server device 20 described above will be described below. FIG. 17 is a flowchart showing an example of a process related to the creation of a test case executed by the server device 20. Note that, as a premise of this process, it is assumed that the KPI tree, business flow, cost information, and checklist created at the time of design are stored in advance in the KPI tree DB 261, business flow DB 262, cost DB 263, and checklist DB 264.

First, the test case creation support unit 213 accepts the selection of a KPI tree for which a test case is to be created from the KPI trees registered in the KPI tree DB 261 (step S11). Next, the test case creation support unit 213 visualizes and displays the selected KPI tree (step S12).

Then, the test case creation support unit 213 waits until a service node E for which a test case is to be created is selected from the KPI tree (step S13; No). Here, when a service node E is selected (step S13; Yes), the test case creation support unit 213 generates a test case creation support screen based on the setting information (cost information, checklist) of the selected service node E (step S14). Next, the test case creation support unit 213 displays the generated creation support screen (step S15).

Here, the user operating the creation support screen can edit the first test case and the second test case as described in Figures 14 and 15. For example, the user operating the creation support screen can input performance values after the service is implemented, and add check items according to the situation after the service is implemented. Then, when the user has finished the editing operation, the user instructs the generation of a test case by instructing completion of editing. Note that the editing operation is not essential, and the user may instruct completion of editing without performing the editing operation.

When the test case creation support unit 213 receives an instruction to complete editing, it determines whether an editing operation has been performed (step S16). If an editing operation has not been performed (step S16; No), the test case creation support unit 213 generates a set of test cases from the first test case and the second test case generated when the creation support screen was generated (step S17), and proceeds to step S19. On the other hand, if an editing operation has been performed (step S16; Yes), the test case creation support unit 213 generates a set of test cases, the first test case and the second test case, which reflect the editing contents (step S18), and proceeds to step S19.

Next, the test case creation support unit 213 stores the generated test case in the test case DB 265 in association with the node ID of the selected service node E and the tree ID of the KPI tree, along with the creation date, the creator's user ID, etc. (step S19).

Then, the test case creation support unit 213 reads out the test cases stored in association with the tree ID of the selected KPI tree from the test case DB 265, and displays a screen listing the test cases (step S20).

As described above, the server device 20 of this embodiment selects one of the service nodes E from the KPI tree created in advance, and reads out the cost information and test cases, which are the design information of the selected service node E, from the cost DB 263 and the checklist DB 264. The server device 20 also generates test cases based on the read cost information and test cases. The server device 20 then stores the generated test cases in the test case DB 265 in association with the selected service node E.

In this way, the server device 20 generates test cases to be used in the verification work after the service is implemented based on the cost information and test cases set in the design stage, so it is possible to generate test cases that include the estimated amount and test items in the design stage. Therefore, the user performing the verification work can verify the situation after the service is implemented while comparing it with the settings set in the design stage. Therefore, the server device 20 of this embodiment can support the verification work after the service is implemented.

Furthermore, the server device 20 generates a test case having an input field for inputting the estimated amount at the design stage and the estimated amount after the service is implemented, based on cost information including the estimated amount at the design stage of the service corresponding to the service node E. This allows the user performing the verification work to input the estimated amount after the service is implemented while checking the estimated amount set at the design stage, making it easy to verify whether the service is being implemented as expected, etc. Therefore, the server device 20 of this embodiment can support the verification work after the service is implemented.

The server device 20 also generates test cases based on the check items defined in the checklist for the service corresponding to the service node E. This allows the user performing the verification work to set check items according to the situation after the service is implemented while checking the check items set at the design stage, thereby improving the efficiency of the check work after the service is implemented. Therefore, the server device 20 of this embodiment can support the verification work after the service is implemented.

The server device 20 also provides an operation screen on which test cases can be edited, and reflects the edited content in the test cases. This allows the user performing the verification work to input verification results and customize test cases via the operation screen, making it possible to efficiently perform verification work after the service is implemented. Therefore, the server device 20 of this embodiment can support verification work after the service is implemented.

The server device 20 also reads out from the test case DB 265 the test cases stored in association with each of the service nodes E in the KPI tree, and outputs a list of the read test cases. This allows the user performing the verification work to easily check the test cases stored in association with the KPI tree.

The above-described embodiment can be modified as appropriate by changing a portion of the configuration or function of each of the above-described devices. Therefore, some modified examples of the above-described embodiment will be described below as other embodiments. Note that the following will mainly describe the differences from the above-described embodiment, and detailed descriptions of the points in common with the contents already described will be omitted. The modified examples described below may be implemented individually or in appropriate combination.

(Variation 1)
In the above-described embodiment, an example was shown in which the terminal device 10 and the server device 20 work together to display various screens provided by the server device 20 on the terminal device 10, but this is not limited to the above, and the terminal device 10 may display the screens alone.

In this case, the terminal device 10 includes, for example, the above-mentioned GUI providing unit 211 and design support unit 212.
By providing functional units such as the test case creation support unit 213, it is possible to display various screens related to the creation and editing of test cases. Note that the terminal device 10 is in a state in which it can read and write various DBs held by the server device 20.

In this case, some or all of the KPI tree DB261, the business flow DB262, the cost DB263, the checklist DB264, and the test case DB265 may be held by the terminal device 10, or may be held by another device (or cloud) accessible by the terminal device 10.

(Variation 2)
In the above embodiment, the server device 20 stores and manages the business flow in association with the service node E of the KPI tree, but the present invention is not limited to this and may be configured not to use a service node.

(Variation 3)
In the above-described embodiment, the server device 20 is configured to generate both a first test case related to cost and a second test case related to check items, but this is not limited to this, and it may also be configured to generate only one of the test cases.

The programs executed by each device in the above-described embodiments are provided in a state where they are pre-installed in a ROM, a storage unit, etc. The programs executed by each device in the above-described embodiments may be provided by being recorded in an installable or executable format on a computer-readable recording medium such as a CD-ROM, a flexible disk (FD), a CD-R, or a digital versatile disk (DVD).

Furthermore, the programs executed by each device in the above-mentioned embodiments may be stored on a computer connected to a network such as the Internet and provided by downloading via the network. Also, the programs executed by each device in the above-mentioned embodiments may be provided or distributed via a network such as the Internet.

Although an embodiment of the present invention has been described above, this embodiment is presented as an example and is not intended to limit the scope of the invention. These new embodiments and their modifications can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the gist of the invention. These embodiments and their modifications are included in the scope and gist of the invention, and are included in the scope of the invention and its equivalents described in the claims.

REFERENCE SIGNS LIST 1 Business support system 10 Terminal device 20 Server device 111 Display control unit 112 Operation reception unit 211 GUI provision unit 212 Design support unit 213 Test case creation support unit 214 Display control unit 215 Operation reception unit 261 KPI tree DB
262 Business flow DB
263 Cost DB
264 Checklist DB
265 Test Case DB

JP 2014-235470 A

Claims (6)

A selection means for selecting one of the service nodes corresponding to the measures at the end from tree data in a tree structure in which the relationship between a business goal and a measure for achieving the goal is set stepwise by nodes;
a readout means for reading out design information of the selected service node from a design information storage unit that stores design information associated with each of the service nodes and indicating settings of a policy corresponding to the service node at a design stage;
a generation means for generating a test case for verifying a state after implementation of a measure corresponding to the selected service node, based on the design information read by the reading means;
a storage control means for storing the test case generated by the generation means in a storage unit in association with the selected service node;
An information processing device comprising: The reading means reads out the design information including an estimated cost at a design stage of a solution corresponding to the service node;
the generation means generates the test case having an input field for inputting an estimated cost at the design stage of the measure corresponding to the service node and an estimated cost after implementation.
The information processing device according to claim 1 . The reading means reads out the design information including a checklist that defines check items of a measure corresponding to the service node;
The generating means generates the test case based on the check items defined in the checklist of the policy corresponding to the service node.
The information processing device according to claim 1 . The generating means provides an operation screen on which the test case can be edited, and reflects the edited content in the test case.
4. The information processing device according to claim 1. The information processing device according to claim 1, further comprising an output means for reading from the storage unit the test cases stored in association with each of the service nodes in the tree data, and outputting a list of the read test cases. The computer of the information processing device,
A selection means for selecting one of the service nodes corresponding to the measures at the end from tree data in a tree structure in which the relationship between a business goal and a measure for achieving the goal is set stepwise by nodes;
a readout means for reading out design information of the selected service node from a design information storage unit that stores design information associated with each of the service nodes and indicating settings of a policy corresponding to the service node at a design stage;
a generation means for generating a test case for verifying a state after implementation of a measure corresponding to the selected service node, based on the design information read by the reading means;
a storage control means for storing the test case generated by the generation means in a storage unit in association with the selected service node;
A program to make it function as such.

Images