From Labor Intensive to Knowledge Intensive—Realizing True Shift to Upper Phases of Development with TERASOLUNA Simulator

3.1 Data variations

Data variations generated by TERASOLUNA Simulator are input values for business logic. Data variations need to be information that enables verification of the design of business logic. For example, to verify a data validation check process, we need variations of data that cause errors and that end the process without errors. We also need data variations that can check the thresholds of the design conditions. Data variations are used to verify the validity of the design by checking the process results.

TERASOLUNA Suite can automatically generate data variations from design information by extracting the checking, branching, computing, and editing processes from design information that is provided in logical form. However, there are many challenges in automatic generation of data variations; these are described later.

3.2 Simulation

Simulation is a process that enables us to visualize the expected execution results after feeding the above data variations into business logic. The word simulate, which forms part of the tool’s name, usually means pseudo execution. However, this tool applies data variations to actual program source codes (business logic) instead of performing pseudo execution. The reason for this is that there is always some doubt that the results of pseudo execution may be different from the execution results with actual program source codes. Note that it is generally difficult to run an actual program because program source codes are not ready in the design phase. However, it is possible to run a process using actual program source codes with TERASOLUNA Suite because TERASOLUNA Suite generates program source codes that can create expected results based on the design. In the future, TERASOLUNA Simulator will be able to simulate screen transitions once the research and development (R&D) is completed, which will require a few more years.

3.3 Reports

A report represents a comprehensible form of information of system input and its corresponding output. It is essential to have a report form that can be easily understood by human operators. This is because the purpose of a design review is to verify the accuracy of the design, and the verification decision depends solely on the reviewer. Therefore, a report needs to be in a form that is comprehensible to the reviewer, who will make a decision based on the report.

4.1 Effects in design process

• The time to prepare data variations and simulate process executions is reduced.
• The quality of reviews is improved because reviews can be performed by checking execution results.
• Man-hours for rework are reduced because possible errors expected during execution can be identified in the design phase.
• Extra work for reviewing reports is needed.

4.2 Effects in testing process

• Man-hours required in the testing phase are expected to be reduced because data variations are checked on reports and do not need to be re-checked in the testing phase.

4.3 Summary

A summary of the overall effects indicates that although the man-hours needed for reviewing reports in the design phase increase, the time required to prepare data variations and to simulate processes decreases. Thus, the total man-hours will not change. However, the testing work in the testing phase is expected to be drastically reduced, and therefore, the time needed for process integration support and functions integration testing is also expected to be drastically reduced.

5.1 Challenge 1: Generation of data variations

Data variations are generated based on design information; consequently, if the design information is not correctly analyzed, the expected data variations cannot be generated. Typical challenges in this area are listed in Table 1. In this case, program components are used for convenience because it is difficult to define necessary patterns if we use design information for a natural language. The underlined components represent difficult components. Loop, DB (database), and, unexpectedly, cast descriptions are difficult. In addition, although it is not included in the table, it is also difficult to output appropriate boundary value data from design information.

Table 1. Challenges in generating data variations.

One solution is to combine independent methods. Current approaches to dealing with this challenge mostly target program source codes. Therefore, one of the important factors that makes our approach more feasible is that the target areas can be limited because our approach is based on TERASOLUNA Suite.

5.2 Challenge 2: Report forms

Reports need to be in a form that can be easily understood by reviewers and customers. Although the levels of understanding vary from person to person, the general goals are to create reports in which (1) the volume of information is not unnecessarily large and is limited to a size that contains necessary information only, and (2) the relationship between data variations is described in a meaningful context in order for people to identify design errors and shortcomings. Specific examples of (2) include clear descriptions for checking the purpose of each input data variation and correct sorting of a report sequence and categories for checking a report sequence.

In addition, TERASOLUNA Simulator is expected to be used in two scenarios: the reviewers’ review process and customers’ verification process. Therefore, the actual reports that are required will differ depending on each scenario. Reviewers require a report form that enables them to thoroughly check all data variations. In contrast, customers need an easily comprehensible report form that enables them to quickly review important points.

5.3 Challenge 3: Volume and quality of data variations

Another challenge is that there is no clear definition of data variations required to verify system quality (Fig. 3). TERASOLUNA Simulator is a tool for verifying a system concept visualized in a reviewer’s or customer’s mind with the design prepared for that concept. However, there is no clear answer that explains how many data variations are required for verification. In our case, it is difficult to review many data variations. Thus, balancing volume and quality requirements is a difficult issue.

Fig. 3. Data variations required to establish quality.

Moreover, one type of variation that cannot be generated by TERASOLUNA Simulator for quality verification is a variation for a process that is not defined in the design information due to initial design shortcomings. Variations that are not defined in the design information need to be identified during the review process.

5.4 Challenge 4: Very long processing time

Our approach is expected to take a very long time to completely execute all processes. Thus, reducing the processing time is an important issue. There are three possibilities to achieve this: (1) speeding up the process by improving the logic; (2) speeding up the process by using high-performance computing; and (3) making a tool that requires intervention of human knowledge instead of pursuing a fully automated tool. Approach (3) is expected to be the key for solving realistic problems.