JP2013097450A - Development support system, development support method and development support program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a development support system, a development support method and a development support program for supporting the management of system development on the basis of a management slip created on a development object system.SOLUTION: A control part 21 of a test process management server 20 executes the input processing of a defective management slip (generation), the registration processing of a response system, and the input processing of the defective management slip (response). Also, the control part 21 executes the input processing of a specification change management slip (generation), the registration processing of the response system and the input processing of the specification change management slip (response). Moreover, the control part 21 executes the input processing of a test journal and the calculation processing of progress information. Then, in the case of creating a written report, the control part 21 specifies a registration system, and creates and outputs the written report by using the defective management slip and the test journal.

Description

  The present invention relates to a development support system, a development support method, and a development support program for supporting management of system development based on a management form created for a development target system.

  Various management forms are used in the development management of business systems used in a company. In the development of such a system, various tests are performed. Various reports may be prepared to manage the progress of such tests. In view of this, an automatic test result report creation apparatus that automatically creates a software test result report and changes a test plan based on the test result has been studied (for example, see Patent Document 1). In the technique described in this document, the test execution results of the test execution means are analyzed, aggregated and accumulated. Then, the test results are analyzed and aggregated, converted into a data format that can be used by general software such as word processing software, and output.

  In addition, a software quality management system that creates a scheduled input sheet, a report output sheet, and a result sheet has been studied (for example, see Patent Document 2). In the technique described in this document, an input scheduled value and a target value / target allowable range determined from quality management items recorded in the past are described in an input sheet, and these are transferred to a report output sheet. The input actual value is described on the actual result sheet, and the total value of the actual value totaled for each process unit is described on the report output sheet. Then, the planned value and the total value are compared to determine whether the difference is within the allowable range, and the determination result is described in the report output sheet.

  Further, in software development, a software development support apparatus that can be easily edited by a user according to the purpose of correction is also being studied (see, for example, Patent Document 3). In the software development support device described in this document, in the software development support, the edited file that is the modified software code is compared with the original file, and the edited file corresponds to the corrected part and the corrected part. Data corresponding to the correction corresponding to the correction corresponding part of the original file to be generated is generated. Then, for the correction input by the user, the correction purpose automatically extracted from the report is presented, and the correction content is managed according to the correction purpose.

JP-A-6-89202 (first page, FIG. 1) JP 2007-279965 A (first page, FIG. 1) JP 2009-53778 A (first page, FIG. 1)

  When developing a large-scale system, there are cases where software is separately developed at a plurality of bases or departments, and these are integrated and managed to construct a system for realizing a desired business. In this case, during the test period, it is necessary to summarize the progress of the test and share information about the implementation status with the parties concerned.

  Therefore, meetings for information sharing are held at each development base and department. When such a conference is held, if the scale of system development is large, the effort and cost for preparing the conference and for participation of the administrator increase.

  In particular, a report for each development is created by each development staff member participating in system development based on a test diary, a defect management slip in a test, a specification change management slip, and the like. However, the number of test diaries, defect management forms, and specification change management forms is enormous, and it may be difficult to confirm the contents individually. In addition, for the above-mentioned meeting, it took time and effort to recreate the materials that compiled these management slips.

  Furthermore, it is necessary to collect the overall feeling of the test implementation status and report it to relevant parties in a timely manner. In addition, matters that affect other systems, such as defects that have occurred and specification changes, need to be expanded to relevant parties.

  The present invention has been made to solve the above-described problems, and its purpose is to provide a development support system and a development support method for supporting management of system development based on a management form created for a development target system. And providing a development support program.

  In order to solve the above problems, the invention described in claim 1 is related to user information and system master information storage means for storing identification information of a development target system; Group information storage means for storing system identification information related to the system, management form storage means for storing management forms created by users and recorded with system identification information in management of system development, and client terminal And a control unit connected to the control unit, the control unit acquires user information from a client terminal, and from the system master information storage unit and group information storage unit to the user information Means for acquiring the identification information of the associated system; and the acquired identification information of the system from the management slip storage means. There means for extracting the recorded management form, to create a report including the evaluation results of the aggregate management form in which the extracted, and summarized in that a section for output to the client terminal.

  The invention according to claim 2 further comprises term storage means for storing keywords used in development in the development support system according to claim 1, wherein the control means includes the term storage means in the management slip. The gist of the present invention is to extract a keyword recorded in the above and create a report in which the appearance status of the keyword is recorded.

  The invention according to claim 3 is the development support system according to claim 1 or 2, wherein information on progress is recorded in the management slip, and the control means is recorded in the management slip. The gist is to calculate a progress rate based on the progress and create a report including the progress rate.

  According to a fourth aspect of the present invention, in the development support system according to any one of the first to third aspects, the management slip includes identification information of a cause system in which an event has occurred, and an influence of the event. The identification information of the corresponding system that needs to be dealt with is recorded, and the control means identifies the identification information of the development target system associated with the user information, and the management record recorded in the management slip storage means In the combination of the identification information of the cause system of the vote and the identification information of the corresponding system, the management slip in which the identification information of the development target system is recorded as one of the identification information is specified, and the identification information of the other system is If it is not recorded in the group information storage means, the user is proposed to register the identification information of the other system in the group information storage means. Furthermore the subject matter that a Cormorant means.

  The invention according to claim 5 specifies the related system associated with the development target system when the identification information of the development target system is acquired in the development support system according to any one of claims 1 to 4. Then, regarding the related system, the failure occurrence situation is specified using the management slip, and when it is determined that the number of failure occurrences is greater than a reference number in the failure occurrence situation, a warning is issued regarding the development target system. Is the gist.

  The invention described in claim 6 is the development support system according to any one of claims 1 to 5, wherein the management slip records version information of a program used in the development target system, When the control means acquires the release approval information of the program of the development target system, the control means further includes means for acquiring a management slip of the development target system, specifying the latest version in the management slip, and registering it as a releasable version This is the gist.

  According to the seventh aspect of the present invention, system master information storage means for storing identification information of a development target system in association with user information, and system identification information related to the development target system in association with user information. Group information storage means for storing, management form storage means for storing a management form created by a user and recorded with system identification information in system development management, and control means connected to the client terminal A method for supporting system development using the development support system, wherein the control means obtains user information from a client terminal, and the use is obtained from the system master information storage means and group information storage means. Acquiring the system identification information associated with the user information and from the management slip storage means And a step of creating a report including an evaluation result obtained by collecting the extracted management slips and outputting the report to the client terminal. To do.

  The invention according to claim 8 is a system master information storage means for storing identification information of a development target system in association with user information, and system identification information related to the development target system in association with user information. Group information storage means for storing, management form storage means for storing a management form created by a user and recorded with system identification information in system development management, and control means connected to the client terminal A program for supporting system development using the developed development support system, wherein the control means acquires user information from a client terminal, and the use is obtained from the system master information storage means and group information storage means. Acquiring the system identification information associated with the person information from the management form storage means. Means for extracting the manifest the identification information of the system is recorded, creates a report including the evaluation results of the aggregate management form in which the extracted and summarized in that to function as means for outputting to the client terminal.

(Function)
According to the invention described in claim 1, 7 or 8, the control means acquires user information from the client terminal, and the system information associated with the user information is obtained from the system master information storage means and the group information storage means. Get identification information. Next, a management slip in which the acquired system identification information is recorded is extracted from the management slip storage means. Then, a report including an evaluation result obtained by collecting the extracted management slips is created and output to the client terminal. Thereby, the development status of the system related to the development target system can be grasped collectively. In addition, by registering an existing system related to the development target system in the group information storage means, it is possible to include the status of the existing system in the report.

  According to the second aspect of the present invention, the control means extracts a keyword recorded in the term storage means in the management slip and creates a report in which the appearance status of the keyword is recorded. In large-scale system development, the number of management votes becomes enormous. Therefore, the system development status can be provided by including the appearance status (for example, the appearance frequency) of common keywords in the report.

  According to the third aspect of the invention, the control means calculates the progress rate based on the progress status recorded in the management slip, and creates a report including the progress rate. This makes it possible to provide information about system development delay through the progress rate.

  According to the invention described in claim 4, the control means specifies the identification information of the development target system associated with the user information. Next, in the combination of the identification information of the cause system of the management slip recorded in the management slip storage means and the identification information of the corresponding system, the management slip in which the identification information of the development target system is recorded as either one of the identification information Identify. If the identification information of the other system is not recorded in the group information storage means, the user is proposed to register the identification information of the other system in the group information storage means. As a result, it is possible to identify related systems using the information recorded in the management slip, and to promote centralized management of the management slips related to these systems. Here, the events include defects and specification changes as will be described later.

  According to the invention described in claim 5, when the control means acquires the identification information of the development target system, the related system associated with the development target system is specified, and the related system is defective using the management slip. Identify the situation. In the case of a system with many failures, attention is given to the development target system. As a result, when the system related to the development target system includes a system in which a defect is likely to occur, the development staff can be alerted.

  According to the sixth aspect of the present invention, when the control unit acquires the approval information of the management target system, the control unit acquires the management slip of the management target system. Then, the latest version is identified in the management slip and certified as a releasable version. Thereby, it is possible to grasp the system development status using the management slip and perform an accurate system release.

  According to the present invention, it is possible to provide a development support system, a development support method, and a development support program for supporting management of system development based on a management form created for a development target system.

The system schematic of embodiment of this invention. Explanatory drawing of each information recorded on the management information storage part of this embodiment. It is explanatory drawing of the information used by this embodiment, (a) is department master information, (b) is system master information, (c) is case information, (d) is related system information, (e) is group registration Information, (f) is user master information, (g) is test number schedule information, (h) is test diary information, (i) is an explanatory diagram of test number record information. It is explanatory drawing of the information used in this embodiment, (a) is defect management slip (occurrence) information, (b) is defect management slip (correspondence) information, (c) is defect correspondence content information, (d) is Specification change management slip (policy) information, (e) is a specification change management slip (correspondence) information, and (f) is an explanatory diagram of specification change correspondence content information. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment.

  Hereinafter, an embodiment embodying the present invention will be described with reference to FIGS. In this embodiment, in system development that is performed in cooperation with multiple departments, management of correction development (defect handling and specification changes) during the test period of system development projects using management slips created in each department A development support system, a development support method, and a development support program that are used for execution will be described. In the present embodiment, a defect management sheet for managing events (defect occurrence and specification change) affecting system development, a test change log for recording daily test statuses, and the like are used as management sheets. Then, in order to construct a target business processing system, it is assumed that a plurality of system developments and tests are performed in parallel, and development management of these systems is integrated.

In the present embodiment, a test process management server 20 is used as shown in FIG. The test process management server 20 is connected to the client terminal 10 via a network.
The client terminal 10 is a computer terminal used by persons involved in system development (developer in charge of each system development, manager in each department, and in charge of promotion of system development as a whole). The client terminal 10 includes a display unit configured from a display (not shown) and the like, and an input unit configured from a keyboard, a pointing device, and the like. The developer in charge uses this client terminal 10 to create a test diary, a defect management slip, and a specification change management slip and upload them to the test process management server 20. The manager uses this client terminal 10 to manage the development status of his / her department, obtain information on the development status of other departments, and examine the influence on the development of his / her department. The person in charge of promotion uses the client terminal 10 to compile test diaries, defect management forms, and specification change management forms for each development department, and create a report.

  The test process management server 20 is a server computer for supporting quality management during a test period in system development. The test process management server 20 includes a control unit 21, a management information storage unit 22, a term dictionary storage unit 23, a relevance evaluation storage unit 24, a design information storage unit 25, and a library storage unit 26.

  Here, the control unit 21 includes a control unit including a CPU, a RAM, a ROM (not shown), and the like, and processes (defect management stage, specification change management stage, diary management stage, group registration stage) described later. Relevance evaluation stage, correction development support stage, report output stage, library management stage, etc.). As shown in FIG. 1, the control unit 21 uses an access control unit 210, a diary management unit 211, a defect management unit 212, a specification change management unit 213, a group management unit 214, and a relevance evaluation unit 215 by a development support program. , Correction development support means 216, report output means 217, and library management means 218.

The access control unit 210 identifies a user in response to an access from the client terminal 10 and executes a process of taking over the process to each unit described later.
The diary management unit 211 executes a process of acquiring the test diary created by the person in charge of development and recording it in the management information storage unit 22. Furthermore, the diary management unit 211 executes processing for evaluating the progress of the test.

The defect management unit 212 executes a process of acquiring a defect management form created by the person in charge of development and recording it in the management information storage unit 22.
The specification change management unit 213 executes a process of acquiring the specification change management form created by the person in charge of development and recording it in the management information storage unit 22.

The group management unit 214 executes a process of grouping a plurality of systems in order to provide information to related parties (developer and manager) of the related system.
The relevance evaluation unit 215 executes a process of searching for a related system using a keyword. This relevance evaluation means 215 retains data relating to the number of reference words in order to identify common keywords used in a related system.

  The correction development support means 216 executes a process of calling attention when a system with a high frequency of defects is involved in correction development (defect handling or specification change). The modified development support means 216 holds data relating to the reference number for the occurrence of defects in order to evaluate the frequency of occurrence of defects.

The report output unit 217 creates a report including an evaluation result obtained by collecting the management forms, and executes a process of creating a report to be provided to each department.
The library management unit 218 executes processing for managing the release of the development target system according to the development progress.

  The management information storage unit 22 functions as a system master information storage unit, a group information storage unit, and a management form storage unit, and records various data for supporting the evaluation of each development during the system development test period. In the present embodiment, as shown in FIG. 2, department master information D01 to specification change correspondence content information D32 are recorded. The contents of each information will be described with reference to FIGS.

  In the department master information D01, master data for managing each department related to system development is recorded. This department master information D01 is recorded when a department related to system development is determined and registered. As shown in FIG. 3A, the department master information D01 includes data relating to a department code and a department name.

Data relating to an identifier for identifying each department is recorded in the department code data area.
Data related to the name of the department is recorded in the department name data area.

In the system master information D02, master data in which identification information of the development target system is recorded is recorded. This system master information D02 is recorded when the development target system is determined and registered. As shown in FIG. 3B, the system master information D02 includes data related to a department code, a system code, and a system name.
In the department code data area, data relating to an identifier for identifying a department (user information) in charge of development of this system is recorded.
Data related to an identifier (identification information) for specifying each development target system is recorded in the system code data area. An existing system related to the development target system may be registered.
Data relating to the name of the system is recorded in the system name data area.

  In the case information D03, master data about a case related to system development is recorded. This item information D03 is recorded when a system development item is determined and registered. As shown in FIG. 3C, the case information D03 includes data on the case name, the case number, and the supervising department code.

Data relating to the name of each case is recorded in the case name data area.
In the case number data area, data relating to an identifier for identifying this case is recorded.
In the supervising department code data area, data relating to an identifier for identifying the department that supervises the matter is recorded.

  In the related system information D04, data for specifying a system related to the development target system is recorded. The related system information D04 is recorded when a related system is registered in each case. As shown in FIG. 3D, the related system information D04 includes a case name, a case number, a system code, a department code, and data related to the development scale.

Data relating to the name of each case is recorded in the case name data area.
In the case number data area, data relating to an identifier for identifying this case is recorded.

  In the system code data area, data relating to an identifier for specifying a system to be developed in this case is recorded. Here, the systems recorded in the related system information D04 to which the same item number is assigned are mutually related.

In the department code data area, data relating to an identifier for identifying a department related to the system development is recorded.
In the development scale data area, data relating to the quantity (number of steps, number of programs, etc.) for specifying the scale of system development is recorded.

  In the group registration information D05, system identification information related to the development target system is recorded, and data for specifying a related system for which a report is desired to be browsed in each department is recorded. This group registration information D05 is recorded when a request to view a report is acquired. As shown in FIG. 3E, the group registration information D05 includes data related to a group ID, a group name, a department code, and a registration system code.

In the group ID data area, data relating to an identifier for specifying each group is recorded.
In the group name data area, data relating to an identifier for specifying the name of each group is recorded.

In the department code data area, data relating to an identifier for identifying a department that wishes to browse this report is recorded.
In the registered system code data area, data relating to an identifier for identifying a target system for which a report is desired to be browsed in this department is recorded. An existing system related to the development target system can be registered in this data area.

  In the user master information D06, master data about each person in charge of development, manager, and person in charge of promotion work is recorded. This user master information D06 is recorded when each person in charge of system development, a manager, and a person in charge of promotion office are determined and registered. As shown in FIG. 3F, the user master information D06 is configured to include data relating to a user ID, password, name, department code, system code, and authority flag.

In the user ID data area, data relating to an identifier for identifying each person in charge or manager is recorded.
In the password data area, data related to a password for performing user authentication of each person in charge or administrator is recorded.

Data relating to the name of the user is recorded in the name data area.
In the department code data area, data relating to an identifier for identifying the department to which the user belongs is recorded.

In the system code data area, data relating to an identifier for specifying the system that the user is in charge of is recorded.
In the authority flag data area, data relating to an identifier for specifying the authority of the responsible system is recorded in this system development.

  In the test number schedule information D10, data related to a test execution schedule in system development is recorded. The test number schedule information D10 is recorded when a schedule of tests to be performed in system development is registered. As shown in FIG. 3G, the test number schedule information D10 includes data related to a system code, a process, a department code, an execution schedule date, an execution schedule count, and an execution schedule count (cumulative total).

In the system code data area, data relating to an identifier for specifying the development target system is recorded.
In the process data area, data relating to an identifier for specifying a process to be tested in the system development is recorded. Through this process, the progress of development can be specified.

In the department code data area, data relating to an identifier for specifying the department to be tested is recorded.
In the scheduled execution date data area, data related to the scheduled date of the test is recorded.

In the scheduled execution number data area, data relating to the number of tests executed on the scheduled execution date is recorded.
In the scheduled execution number (cumulative) data area, data relating to the cumulative number of tests performed up to this scheduled date is recorded.

  In the test diary information D11, data related to the test diary created by the developer is recorded. This test diary information D11 is recorded when a test diary is registered. As shown in FIG. 3 (h), the test diary information D11 includes data relating to a system code, a process, a department code, an execution date, a drafter, test contents, a delay occurrence situation, and a problem occurrence situation. .

In the system code data area, data relating to an identifier for specifying a system to be a target of the test diary is recorded.
In the process data area, data relating to an identifier for specifying a process to be tested is recorded.

In the department code data area, data relating to an identifier for identifying the department to which the developer in charge of creating the test diary belongs is recorded.
In the execution date data area, data related to the date on which the test in the test diary is executed is recorded.

In the drafter data area, data relating to an identifier (user ID) for identifying the person in charge of development who created the test diary is recorded.
In the test content data area, data related to the test content in system development is recorded.

In the delay occurrence status data area, the presence / absence of a delay in the test progress status and data regarding the delay contents are recorded.
In the problem occurrence status data area, whether or not a problem has occurred in the test that is the subject of the test diary and data relating to the contents of the problem are recorded.

  In the test number record information D12, data related to the results of tests performed in system development is recorded. This test number record information D12 is recorded when a test diary is registered in system development. As shown in FIG. 3 (i), the test number record information D12 includes data related to a system code, a process, a department code, an execution date, an execution number, an execution number (cumulative), and a progress rate.

In the system code data area, data relating to an identifier for specifying the development target system is recorded.
In the process data area, data relating to an identifier for specifying a process to be tested in the system development is recorded.

In the department code data area, data relating to an identifier for identifying the department that has performed the test is recorded.
In the execution date data area, data relating to the date on which the test was executed is recorded.
In the execution number data area, data related to the number of tests executed on the execution date is recorded.

In the execution number (cumulative) data area, data relating to the total number of tests performed up to this execution date is recorded.
In the progress rate data area, data relating to the progress rate obtained by dividing the number of test executions (cumulative) by the planned number of test executions (cumulative) of the test number schedule information D10 is recorded.

  In the defect management slip (occurrence) D20, data relating to a management slip regarding a defect generated in the test is recorded. This defect management slip (occurrence) D20 is recorded when a defect occurring in the test is found. As shown in FIG. 4A, the defect management slip (occurrence) D20 is configured to include defect management number, subject, process, system code, creation date, department code, and data related to the defect outline.

Data relating to an identifier for identifying each defect is recorded in the defect management number data area.
In the subject data area, data relating to the name representing the content of the defect is recorded.
In the process data area, data relating to an identifier for specifying a process in which a defect has occurred is recorded.

In the system code data area, data relating to an identifier for identifying a system (cause system) in which a failure has occurred is recorded.
In the creation date data area, data relating to the date of creation of the defect management slip is recorded.

In the department code data area, data relating to an identifier for identifying the department that has found this defect is recorded.
In the defect summary data area, data relating to the content of the defect that has occurred is recorded.

In the defect management slip (correspondence) D21, data relating to the management slip regarding the correspondence to the failure that occurred in the test is recorded. This defect management slip (correspondence) D21 is generated and recorded when registration of a system that should cope with a defect is performed. As shown in FIG. 4B, the defect management slip (correspondence) D21 is configured to include defect management number, branch number, system code, creation date, department code, cause, and data related to correspondence.
In the defect management number data area, data relating to an identifier for identifying a defect that has occurred in the test is recorded.
In the branch number data area, data relating to an identifier for specifying a correspondence to a defect is recorded. In the present embodiment, since a plurality of correspondences may be required for one defect, branch numbers are used to identify individual correspondences.

In the system code data area, data relating to an identifier for specifying a system (corresponding system) to be dealt with with respect to the generated defect is recorded.
In the creation date data area, data relating to the date of creation of the defect management slip is recorded.

In the department code data area, data relating to an identifier for identifying the department that has dealt with the defect is recorded.
In the cause data area, data relating to the cause of the failure that has occurred is recorded.
In the response data area, data related to the response (program change, similarity review, and formulation of recurrence prevention measures) performed on the defect is recorded.

  In the defect handling content information D22, data relating to programs and documents created in dealing with defects is recorded. This failure handling content information D22 is recorded when a program or document for handling a failure is registered. As shown in FIG. 4C, the defect handling content information D22 is configured to include data relating to a defect management number, a branch number, a system code, a corresponding file, a version, a corresponding category, and a corresponding date.

In the defect management number data area, data relating to an identifier for identifying a defect that has occurred in the test is recorded.
In the branch number data area, data relating to an identifier for individually specifying the correspondence to the defect is recorded.

In the system code data area, data relating to an identifier for specifying a system that has dealt with a failure is recorded.
In the corresponding file data area, data (program identifier) for identifying a program used for defect handling and data (document identifier) for identifying a document relating to defect handling are recorded.

In the version data area, data related to the version of a program or document created by handling a defect is recorded.
In the correspondence classification data area, data relating to an identifier for specifying the type of failure correspondence is recorded.
In the response date data area, data related to the date of failure handling is recorded.

  In the specification change management slip (policy) D30, data related to the management slip regarding the policy of the specification change scheduled system is recorded. This specification change management slip (policy) D30 is recorded when a specification change policy in system development is determined and registered. As shown in FIG. 4D, the specification change management form (policy) D30 includes data on specification change management number, subject, process, system code, creation date, department code, change contents, and influence contents. Is done.

In the specification change management number data area, data relating to an identifier for specifying each specification change is recorded.
In the subject data area, data relating to the name representing the contents of the specification change is recorded.
In the process data area, data relating to an identifier for specifying a process for which the specification is changed is recorded.

In the system code data area, data relating to an identifier for specifying a system (cause system) whose specification is to be changed is recorded.
In the creation date data area, data relating to the date of creation of the specification change management slip is recorded.

In the department code data area, data relating to an identifier for identifying a department whose specification is to be changed is recorded.
In the change content data area, data relating to specification change content is recorded.
In the influence content data area, data relating to the content of the influence that is expected to occur due to the specification change is recorded.

  In the specification change management slip (correspondence) D31, data related to the management slip regarding the response to the specification change of the development target system is recorded. This specification change management slip (correspondence) D31 is generated and recorded when registration of a system that should respond to a specification change is performed. As shown in FIG. 4E, the specification change management form (correspondence) D31 is configured to include data on specification change management numbers, branch numbers, system codes, creation dates, department codes, and points to be noted.

In the specification change management number data area, data relating to an identifier for specifying a specification change in system development is recorded.
In the branch number data area, data relating to an identifier for specifying the individual correspondence included in the specification change is recorded. In the present embodiment, since a plurality of correspondences may be required for one specification change, branch numbers are used to identify individual correspondences.

In the system code data area, data relating to an identifier for specifying a system (corresponding system) that should respond to the specification change is recorded.
In the creation date data area, data relating to the date of creation of the specification change management slip is recorded.

In the department code data area, data relating to an identifier for identifying the department that has responded to the specification change is recorded.
In the consideration data area, data relating to matters to be noted in this correspondence is recorded.

  In the specification change correspondence content information D32, data relating to a program or document created in response to the specification change is recorded. This specification change correspondence content information D32 is recorded when a program or document regarding the correspondence to the specification change is registered. As shown in FIG. 4F, the specification change correspondence content information D32 includes data on specification change management numbers, branch numbers, system codes, corresponding files, and versions.

In the specification change management number data area, data relating to an identifier for specifying a specification change in system development is recorded.
In the branch number data area, data relating to an identifier for individually specifying the correspondence to the specification change is recorded.

In the system code data area, data relating to an identifier for specifying a system whose specification has been changed is recorded.
In the corresponding file data area, data (program identifier) for specifying a program used for the specification change and data (document identifier) for specifying a document related to the specification change are recorded.
In the version data area, data related to the version of the program or document created by the specification change is recorded.

  The term dictionary storage unit 23 functions as term storage means. The term dictionary storage unit 23 stores keywords that may be included in the management slip. More specifically, phrases (keywords) used for explaining the contents (causes, responses, etc.) are recorded in the defect management form and the specification change management form.

  In the relevance evaluation storage unit 24, evaluation result data for evaluating relevance of each system is recorded. As the evaluation result data, data relating to a keyword (common keyword) that is commonly used when a failure occurs in the combination of the system code of the cause system and the system code of the corresponding system is recorded.

  The design information storage unit 25 records design information of each system. The design information includes information output from each system and interface information about the system to which this information is input. Based on this interface information, it is possible to specify the system code of the interrelated system.

  The library storage unit 26 includes a latest version storage unit and a releasable version storage unit. The latest version storage unit records the latest versions of programs and documents created in system development. The releasable version storage unit stores a version of a program or document that has been tested and can be used in a production environment.

  A processing procedure for supporting test evaluation in system development using the system configured as described above will be described with reference to FIGS. Here, the outline, the relevance evaluation process, the correction development support process, the report output process, and the library management process will be described in this order.

(Overview)
First, the outline of the processing will be described with reference to FIG. Here, the defect management process, the specification change management process, the test diary management process, and the group registration process will be described in this order.

[Defect management processing]
When a defect is found in the test, the control unit 21 of the test process management server 20 executes a defect management slip (occurrence) input process (step S1-1). Specifically, the developer in charge accesses the test process management server 20 using the client terminal 10. In this case, the access control unit 210 of the control unit 21 of the test process management server 20 outputs a user authentication screen on the display of the client terminal 10 and acquires the user ID and password of the person in charge of development. When this user ID and password are registered in the user master information D06, a menu screen is output on the display of the client terminal 10. On this menu screen, select “Defect management slip (occurrence) input”.

  In this case, the access control unit 210 of the control unit 21 takes over the process to the defect management unit 212. Then, the defect management unit 212 outputs a defect management slip input screen on the display of the client terminal 10. This defect management slip input screen includes an occurrence column and a correspondence column. The developer in charge in the occurrence column of the defect management slip input screen finds defect contents (subject, process, system code, creation date, department code, defect summary, etc.) found in the system test registered in the user master information D06. ). When completion input is performed in the occurrence column, the defect management means 212 of the control unit 21 assigns a defect management number, generates a defect management slip (occurrence) D20, and registers it in the management information storage unit 22.

  Next, the control unit 21 of the test process management server 20 executes a corresponding system registration process (step S1-2). Specifically, the defect management unit 212 of the control unit 21 acquires the related system information D04 in which the system code of the cause system is recorded in the management information storage unit 22. Then, the defect management unit 212 acquires the system code recorded in the related system information D04 to which the same case number is assigned. The defect management unit 212 outputs a list display including the interface information recorded in the design information storage unit 25 to the display of the client terminal 10 in association with these system codes. In this case, the developer in charge selects only systems that need to be dealt with by deleting unnecessary system codes from the list display or adding necessary system codes. When completion input is performed in the list display, the defect management means 212 of the control unit 21 assigns branch numbers to the defect management numbers corresponding to the selected system codes. Then, the defect management means 212 generates a defect management slip (correspondence) D21 for each corresponding system and registers it in the management information storage unit 22. Further, here, a correction development support process described later is executed.

  Next, the control unit 21 of the test process management server 20 executes a defect management slip (correspondence) input process (step S1-3). Specifically, the person in charge of developing the corresponding system accesses the test process management server 20 using the client terminal 10. In this case, the access control unit 210 of the control unit 21 of the test process management server 20 outputs a user authentication screen on the display of the client terminal 10 and acquires the user ID and password of the person in charge of development. When this user ID and password are registered in the user master information D06, a menu screen is output on the display of the client terminal 10. On this menu screen, select “Defect management slip (corresponding) input”.

  In this case, the access control unit 210 of the control unit 21 takes over the process to the defect management unit 212. Then, the defect management unit 212 outputs a defect management slip input screen on the display of the client terminal 10. This defect management slip input screen includes an occurrence column and a correspondence column. In this defect management slip input screen, the developer in charge enters the corresponding contents of the defect (creation date, department code, cause, countermeasure) in the corresponding column of the system registered in the user master information D06 (corresponding system that he is in charge of) Etc.). Here, if there is a correspondence file (program or document) created for dealing with a defect, it is attached to the correspondence column.

  When completion input is performed in the correspondence column, the defect management means 212 of the control unit 21 records the content input in the correspondence column in the defect management slip (correspondence) D21. Further, when a correspondence file is attached, the defect management means 212 generates defect correspondence content information D22 and registers it in the management information storage unit 22. Further, the defect management unit 212 updates the corresponding file recorded in the latest version storage unit of the library storage unit 26. In this case, the system code and version are associated with the corresponding file.

[Specification change management processing]
When the specification is changed, the control unit 21 of the test process management server 20 executes a specification change management slip (policy) input process (step S1-4). Specifically, the developer in charge accesses the test process management server 20 using the client terminal 10. In this case, the access control unit 210 of the control unit 21 of the test process management server 20 outputs a user authentication screen on the display of the client terminal 10 and acquires the user ID and password of the person in charge of development. When this user ID and password are registered in the user master information D06, a menu screen is output on the display of the client terminal 10. On this menu screen, select “Specification Change Management Form (Policy) Input”.

  In this case, the access control unit 210 of the control unit 21 takes over the process to the specification change management unit 213. Then, the specification change management unit 213 outputs a specification change management slip input screen on the display of the client terminal 10. This specification change management slip input screen includes a policy column and a correspondence column. In the policy column of the specification change management slip input screen, the developer in charge changes the specifications of the system registered in the user master information D06 (subject, process, system code, creation date, department code, change details, impact details) Etc.). When a completion input is made in the policy column, the specification change management means 213 of the control unit 21 assigns a specification change management number, generates a specification change management slip (policy) D30, and registers it in the management information storage unit 22 To do.

  Next, the control unit 21 of the test process management server 20 executes a corresponding system registration process (step S1-5). Specifically, the specification change management unit 213 of the control unit 21 acquires the related system information D04 in which the system code of the cause system is recorded in the management information storage unit 22. Then, the specification change management unit 213 acquires the system code recorded in the related system information D04 to which the same case number is assigned. Then, the specification change management unit 213 outputs a list display including the interface information recorded in the design information storage unit 25 on the display of the client terminal 10 in association with these system codes. In this case, the developer in charge selects only systems that need to be dealt with by deleting unnecessary system codes from the list display or adding necessary system codes. When completion input is performed in the list display, the specification change management means 213 of the control unit 21 assigns a branch number to the specification change management number for each selected system code. Then, the specification change management means 213 generates a specification change management slip (correspondence) D31 for each corresponding system and registers it in the management information storage unit 22. In this case as well, correction development support processing described later is executed.

  Next, the control unit 21 of the test process management server 20 executes input processing of a specification change management slip (correspondence) (step S1-6). Specifically, the person in charge of developing the corresponding system accesses the test process management server 20 using the client terminal 10. In this case, the access control unit 210 of the control unit 21 of the test process management server 20 outputs a user authentication screen on the display of the client terminal 10 and acquires the user ID and password of the person in charge of development. When this user ID and password are registered in the user master information D06, a menu screen is output on the display of the client terminal 10. On this menu screen, select “Specification change management slip (corresponding) input”.

  In this case, the access control unit 210 of the control unit 21 takes over the process to the specification change management unit 213. Then, the specification change management unit 213 outputs a specification change management slip input screen on the display of the client terminal 10. This specification change management slip input screen includes a policy column and a correspondence column. In this specification change management form input screen, the developer in charge enters the response contents (creation date, department code, notes) in the corresponding column of the system (corresponding system he / she is responsible for) registered in the user master information D06. Item). Here, if there is a correspondence file (program or document) created for dealing with the specification change, it is attached to the correspondence column.

  When completion input is performed in the correspondence column, the specification change management unit 213 of the control unit 21 records the contents input in the correspondence column in the specification change management slip (correspondence) D31. Furthermore, when the corresponding file is attached, the specification change management means 213 generates specification change correspondence content information D32 and registers it in the management information storage unit 22. Further, the specification change management unit 213 updates the corresponding file recorded in the latest version storage unit of the library storage unit 26. In this case, the system code and version are associated with the corresponding file.

[Test diary management process]
When registering the test diary, the control unit 21 of the test process management server 20 executes test diary input processing (step S1-7). Specifically, the developer in charge accesses the test process management server 20 using the client terminal 10. In this case, the access control unit 210 of the control unit 21 of the test process management server 20 outputs a user authentication screen on the display of the client terminal 10 and acquires the user ID and password of the person in charge of development. When this user ID and password are registered in the user master information D06, a menu screen is output on the display of the client terminal 10. On this menu screen, select “Test Diary Input”.

  In this case, the access control unit 210 of the control unit 21 takes over the process to the diary management unit 211. The diary management unit 211 outputs a diary input screen for the system code registered in the user master information D06 on the display of the client terminal 10. The developer in charge inputs the test contents (system code, process, department code, execution date, number of executions, etc.) on this diary input screen.

  When update input is performed on the diary input screen, the diary management means 211 of the control unit 21 causes the defect management slip (occurrence) D20 in which the system code, process, and department code input on the diary input screen are recorded, specification change A management slip (policy) D30 is extracted from the management information storage unit 22. Further, the diary management means 211 includes a specification change management slip corresponding to the specification change management number of the failure management slip (corresponding) D21 corresponding to the failure management number of the failure management slip (occurrence) D20 and the specification change management slip (policy) D30. (Action) D31 is extracted from the management information storage unit 22. Then, the diary management means 211 outputs the contents of each management slip in the reference field of the diary input screen.

  Further, the control unit 21 of the test process management server 20 executes progress information calculation processing (step S1-8). Specifically, the diary management unit 211 of the control unit 21 extracts from the management information storage unit 22 the test number schedule information D10 in which the system code, the process, and the department code input on the diary input screen are recorded. Next, the diary management unit 211 specifies the test number schedule information D10 in which the input implementation date is recorded in the planned execution date data area. Then, the diary management unit 211 acquires the scheduled number of implementations and the scheduled number of implementations (cumulative total) recorded in the test number schedule information D10.

  Further, the diary management unit 211 extracts the test number record information D12 in which the system code, the process, and the department code input on the diary input screen are recorded from the management information storage unit 22. Next, the diary management unit 211 specifies the test number record information D12 having the latest date recorded in the execution date data area. Then, the diary management unit 211 acquires the number of executions and the number of executions (cumulative total) recorded in the test number record information D12.

  Next, the diary management means 211 adds the number of executions entered on the diary input screen to the number of implementations and the number of implementations (cumulative total) recorded in the acquired test number record information D12 to obtain the current implementation. Calculate the number of cases and the number of implementations (cumulative). Next, the diary management unit 211 calculates the progress rate by dividing the current number of implementations (cumulative) by the number of scheduled implementations (cumulative). Then, the diary management unit 211 displays the scheduled number of implementations, the number of scheduled implementations (cumulative), the number of implementations (cumulative), and the progress rate on the diary input screen.

  In this case, the person in charge of development refers to the reference field, progress rate, etc. displayed on the display of the client terminal 10 and inputs the test content, delay occurrence status, problem occurrence status, etc. on the diary input screen.

  When the completion input is performed on the diary input screen, the diary management unit 211 of the control unit 21 generates test diary information D11 and test number record information D12 in which information set on the diary input screen is recorded. Then, the diary management unit 211 registers the test diary information D11 and the test number record information D12 in the management information storage unit 22.

[Group registration process]
When performing group registration of related systems, the control unit 21 of the test process management server 20 executes group registration request processing (step S1-9). Specifically, the developer in charge accesses the test process management server 20 using the client terminal 10. In this case, the access control unit 210 of the control unit 21 of the test process management server 20 outputs a user authentication screen on the display of the client terminal 10 and acquires the user ID and password of the person in charge of development. When this user ID and password are registered in the user master information D06, a menu screen is output on the display of the client terminal 10. On this menu screen, select “Group Registration”.

  In this case, the access control unit 210 of the control unit 21 takes over the process to the group management unit 214. And the group management means 214 acquires a system code from the system master information D02 in which the department code of the user master information D06 is recorded.

  Next, the group management means 214 sends from the management information storage unit 22 a failure management slip (occurrence) D20, a failure management slip (corresponding) D21, a specification change management slip (policy) D30, and a specification in which this system code is recorded. A change management slip (correspondence) D31 is extracted. In this case, a related system having an influence on occurrence of a defect or specification change is specified by a combination of the system code of the cause system and the corresponding system.

  Next, the control part 21 of the test process management server 20 performs a comparison process with a registration system (step S1-10). Specifically, the group management unit 214 of the control unit 21 acquires the department code recorded in the user master information D06. Then, the group management unit 214 extracts the group registration information D05 in which the department code is recorded from the management information storage unit 22. Next, the group management unit 214 compares the registered system code recorded in the group registration information D05 with the system code of the related system specified above.

  Next, the control part 21 of the test process management server 20 performs a grouping proposal process (step S1-11). Specifically, the group management unit 214 of the control unit 21 performs grouping on the client terminal 10 when the system code of the identified related system is not recorded in the group registration information D05. Output a suggested message. This message includes the system code that was not recorded in the group registration information D05 in the comparison result of step S1-10.

  And the control part 21 of the test process management server 20 performs a group update process (step S1-12). Specifically, when the group management unit 214 of the control unit 21 obtains a registration instruction including a system code from the client terminal 10, it additionally registers this system code in the registration system code data area of the group registration information D05. To do.

(Relevance evaluation processing)
Next, the relevance evaluation process will be described with reference to FIG. Here, a related system is predicted using the defect management slip.

  First, the control unit 21 of the test process management server 20 executes a related system specifying process (step S2-1). Specifically, the relevance evaluation means 215 of the control unit 21 obtains system codes of systems that are related to each other and that are input / output based on interface information recorded in the design information storage unit 25. Identify.

  Next, the control unit 21 of the test process management server 20 executes an associated system update process (step S2-2). Specifically, the relevance evaluation unit 215 of the control unit 21 acquires evaluation result data in which the identified system code is recorded from the relevance evaluation storage unit 24. Next, the relevance evaluation unit 215 newly generates and records evaluation result data when the evaluation result data in which both system codes are recorded is not registered.

  Next, the control unit 21 of the test process management server 20 executes a determination process as to whether or not the defect occurrence frequency is high (step S2-3). Specifically, the relevance evaluation unit 215 of the control unit 21 extracts the defect management slip (occurrence) D20 in which the creation date within the evaluation target period is recorded. Then, the relevance evaluation means 215 calculates the number of defective occurrences using the extracted defect management slip (occurrence) D20 and compares it with the occurrence frequency reference number. When the number of occurrences of defects is greater than the occurrence frequency reference number, it is determined that the occurrence frequency of defects is high.

When it is determined that the defect occurrence frequency is low (in the case of “NO” in step S2-3), the control unit 21 of the test process management server 20 ends the relevance evaluation process.
On the other hand, when it is determined that the defect occurrence frequency is high (in the case of “YES” in step S2-3), the control unit 21 of the test process management server 20 executes a common keyword extraction process (step S2-4). Specifically, the relevance evaluation means 215 of the control unit 21 uses the keywords recorded in the term dictionary storage unit 23 to describe the failure summary of the failure management slip (occurrence) D20 during a period when the failure occurrence frequency is high. Count the number of words recorded in the data area. Then, the relevance evaluation means 215 specifies words / phrases having a larger number of words than the number of reference words / phrases as common keywords.

  Next, the control unit 21 of the test process management server 20 executes a defect management slip search process including a common keyword (step S2-5). Specifically, the relevance evaluation unit 215 of the control unit 21 extracts a defect management slip (occurrence) D20 in which the identified common keyword is recorded in the defect overview data area. In this case, the defect management slip (occurrence) D20 in a period other than the period in which the defect occurrence frequency is high is also used.

  Next, the control unit 21 of the test process management server 20 executes relevance evaluation update processing using the defect management slip (step S2-6). Specifically, the relevance evaluation unit 215 of the control unit 21 specifies a system in which a system code is recorded in the extracted defect management slip (occurrence) D20 as a related system. The relevance evaluation unit 215 records the common keyword in the evaluation result data in which both system codes are recorded.

(Modification development support processing)
Next, the correction development support process will be described with reference to FIG. In this process, attention is given to correction development (defect handling or specification change) using the defect management slip. This process is performed when the client terminal 10 executes the corresponding system registration process (steps S1-2 and S1-5).

  First, the control unit 21 of the test process management server 20 executes a modification development target specifying process (step S3-1). Specifically, the correction development support means 216 of the control unit 21 extracts the defect management form (occurrence) D20 and the specification change management form (policy) D30 of the correction development target system in the management information storage unit 22, and the system code Is identified.

  Next, the control unit 21 of the test process management server 20 executes a related system specifying process (step S3-2). Specifically, the correction development support means 216 of the control unit 21 specifies related system information D04 in which this system code is recorded. Then, the correction development support unit 216 specifies the related system by acquiring the system code recorded in the related system information D04 to which the same item number is assigned.

Then, in the related systems, the processing target system is sequentially specified, and the following processing is repeated.
Here, the control unit 21 of the test process management server 20 executes a defect occurrence status acquisition process (step S3-3). Specifically, the correction development support means 216 of the control unit 21 extracts the defect management slip (occurrence) D20 in which the system code of the processing target system is recorded from the management information storage unit 22. Here, a defect management slip (occurrence) D20 for a predetermined period is extracted.

  Next, the control unit 21 of the test process management server 20 executes a determination process as to whether or not the defect occurrence frequency is high (step S3-4). Specifically, the correction development support means 216 of the control unit 21 counts the total number of extracted defect management slips (occurrence) D20. When the total number is equal to or greater than the reference number, it is determined that the defect occurrence frequency is high.

  When it is determined that the defect occurrence frequency is high (in the case of “YES” in step S3-4), the control unit 21 of the test process management server 20 executes an alerting process (step S3-5). Specifically, the correction development support means 216 of the control unit 21 outputs a message indicating that the defect occurrence frequency is high on the display of the client terminal 10 of the person in charge of development. On the other hand, if it is determined that the failure occurrence frequency is low (in the case of “NO” in step S3-4), the control unit 21 of the test process management server 20 ends the process for this related system.

(Report output processing)
Next, the report output process will be described with reference to FIG.
When creating a report, the control unit 21 of the test process management server 20 executes a report creation request acquisition process (step S4-1). Specifically, the user accesses the test process management server 20 using the client terminal 10. In this case, the access control means 210 of the control unit 21 of the test process management server 20 outputs a user authentication screen on the display of the client terminal 10 and acquires the user ID and password of this user. When this user ID and password are registered in the user master information D06, a menu screen is output on the display of the client terminal 10. On this menu screen, select “Create Report”. In this case, the access control unit 210 of the control unit 21 takes over the processing to the report output unit 217.

  Next, the control unit 21 of the test process management server 20 executes a report target system specifying process (step S4-2). The report output means 217 of the control unit 21 acquires the department code recorded in the user master information D06 of the user, and extracts the system master information D02 in which the department code is recorded from the management information storage unit 22. . Then, the report output means 217 acquires the system code (the system code of the own system) recorded in the system code data area of the extracted system master information D02. Further, the report output means 217 extracts the group registration information D05 in which the department code is recorded from the management information storage unit 22. Then, the report output means 217 acquires a system code (system code of another system) recorded in the registered system code data area of the extracted group registration information D05. And it identifies as a report object system using the system code acquired from the registration system code data area of system master information D02 and group registration information D05.

First, the following processing is executed for the defect management form and the specification change management form.
Here, the control unit 21 of the test process management server 20 executes a process for calculating the number of corresponding cases (step S4-3). Specifically, the report output means 217 of the control unit 21 specifies the defect management slip (occurrence) D20 in which the system code of the own system is recorded, and calculates the number of occurrences of defects in the own system. Further, the report output means 217 specifies the specification change management slip (policy) D30 in which the system code of the own system is recorded, and changes the specification of the own system based on the number of the specification change management slip (policy) D30. Calculate the number of cases. Next, the report output unit 217 specifies the failure management slip (correspondence) D21 in which the system code of the own system is recorded, and calculates the number of failures corresponding to the own system due to the failure. Further, the report output means 217 specifies the specification change management slip (correspondence) D31 in which the system code of the own system is recorded, and calculates the number of cases corresponding to the specification change of the own system due to the specification change.

  Next, the report output means 217 calculates the number of cases corresponding to the own system in accordance with the defect or specification change that has occurred in the own system. Furthermore, the number of cases corresponding to the other system is calculated in accordance with a defect or a specification change that has occurred in the own system. Furthermore, the number of cases handled by the own system is calculated in accordance with a defect occurring in another system or a specification change.

  Next, the control unit 21 of the test process management server 20 executes keyword extraction processing included in the defect management form and the specification change management form (step S4-4). Specifically, the report output means 217 of the control unit 21 displays the failure summary data area of the failure management slip (occurrence) D20 in which the system code of the report target system is recorded, and the cause of the failure management slip (correspondence) D21. The keywords included in the data area and the corresponding data area are extracted in association with the process. Further, the report output means 217 takes note of the change content data area, the influence content data area of the specification change management form (policy) D30 in which the system code of the report target system is recorded, and the specification change management form (correspondence) D31. The keywords included in the item data area are extracted in association with the process.

  Next, the control unit 21 of the test process management server 20 executes a keyword distribution calculation process (step S4-5). Specifically, the report output means 217 of the control unit 21 calculates the total number of each keyword that appears for each system development process, and creates a keyword distribution.

Next, the following processing is executed for the test diary.
Here, the control unit 21 of the test process management server 20 executes a keyword extraction process included in the test diary (step S4-6). Specifically, the report output means 217 of the control unit 21 extracts keywords recorded in the test contents, delay occurrence status, and problem occurrence status of the test diary information D11.

  Next, the control unit 21 of the test process management server 20 executes a keyword distribution calculation process (step S4-7). Specifically, the report output means 217 of the control unit 21 calculates the total number of each keyword that appears for each system development process, and creates a keyword distribution.

  Next, the control unit 21 of the test process management server 20 executes progress rate evaluation processing (step S4-8). Specifically, the report output means 217 of the control unit 21 acquires the progress rate of the test in this process from the test number record information D12. Next, the report output means 217 associates the extracted keyword distribution with the progress rate.

  Next, the control unit 21 of the test process management server 20 executes a progress comparison process of the report target system (step S4-9). Specifically, the report output means 217 of the control unit 21 generates a comparison table comparing the acquired progress rates of the respective registration systems.

  Next, the control unit 21 of the test process management server 20 executes a report providing process (step S4-10). Specifically, the report output means 217 of the control unit 21 creates a report and outputs it to the display of the client terminal 10. This report includes the number of failures in the system, the number of responses due to failures in other systems, the keyword distribution included in the failure management slip and test diary for each registered system, keyword evaluation results, progress rate evaluation results, progress rate Include a comparison table.

(Library management processing)
Next, library management processing will be described with reference to FIG.
First, the control unit 21 of the test process management server 20 executes an approval process (step S5-1). Specifically, when a new program is released, the administrator accesses the test process management server 20 using the client terminal 10. Then, the client terminal 10 is used to identify the program and input the approval. In this case, the client terminal 10 transmits a program release instruction to the test process management server 20. This release instruction includes data (program identifier) for specifying the program to be released. In this case, the library management unit 218 of the control unit 21 of the test process management server 20 acquires a release instruction.

  Next, the control unit 21 of the test process management server 20 executes version information acquisition processing (step S5-2). Specifically, the library management unit 218 of the control unit 21 acquires the version information of the program recorded in the library for the program identifier to be released.

  Next, the control unit 21 of the test process management server 20 executes a process for extracting the corresponding data (step S5-3). Specifically, the library management unit 218 of the control unit 21 extracts from the management information storage unit 22 a defect management slip (corresponding) D21 and a specification change management slip (corresponding) D31 in which a program identifier to be released is recorded. . Next, the library management means 218 specifies failure correspondence content information D22 corresponding to the failure management number of the failure management slip (correspondence) D21 and specification change correspondence content information corresponding to the specification change management number of the specification change management slip (correspondence) D31. The version information recorded in D32 is acquired.

  Next, the control unit 21 of the test process management server 20 executes a determination process as to whether or not the version information matches (step S5-4). Specifically, the library management means 218 of the control unit 21 compares the version information of the program recorded in the library with the version information acquired from the defect handling content information D22 and the specification change handling content information D32.

  If the two pieces of version information match (in the case of “YES” in step S5-4), the control unit 21 of the test process management server 20 executes a registration process as a releasable version (step S5-5). Specifically, the library management means 218 of the control unit 21 transfers the latest version to the releasable version storage unit. The program registered in the releasable version storage unit is transferred to the production system area and used in the production system.

  On the other hand, when the two pieces of version information do not match (in the case of “NO” in step S5-4), the control unit 21 of the test process management server 20 executes a warning process (step S5-6). Specifically, the library management unit 218 of the control unit 21 outputs a message indicating that the versions do not match to the administrator's client terminal 10.

According to this embodiment, the following effects can be obtained.
(1) In the present embodiment, the control unit 21 of the test process management server 20 executes a defect management slip (occurrence) input process (step S1-1) and a corresponding system registration process (step S1-2). Then, the control unit 21 executes a defect management slip (correspondence) input process (step S1-3). As a result, it is possible to centrally manage defect information and response status that have occurred in tests in system development.

  (2) In the present embodiment, the control unit 21 of the test process management server 20 executes specification change management slip (policy) input processing (step S1-4) and corresponding system registration processing (step S1-5). . And the control part 21 performs the input process of a specification change management slip (correspondence) (step S1-6). As a result, it is possible to centrally manage specification changes and response statuses that occur in system development.

  (3) In the present embodiment, the control unit 21 of the test process management server 20 executes test diary input processing (step S1-7). Further, the control unit 21 extracts a defect management slip (occurrence) D20, a defect management slip (correspondence) D21, a specification change management slip (policy) D30, and a specification change management slip (correspondence) D31 from the management information storage portion 22, Output the contents of each management slip in the reference field of the diary input screen. Further, the control unit 21 executes progress information calculation processing (step S1-8). This makes it possible to efficiently grasp the progress status by centrally managing test diaries in system development. Further, the developer can create a test diary with reference to the defect management form, specification change management form, and progress.

  (4) In this embodiment, the control part 21 of the test process management server 20 performs a group registration request process (step S1-9). Here, it is possible to identify a related system that has an influence on the occurrence of a defect or a specification change by combining the cause system and the system code of the corresponding system recorded in the defect management form or the specification change management form.

  Further, the control unit 21 of the test process management server 20 executes a comparison process (step S1-10) with the registration system and a grouping proposal process (step S1-11). As a result, by registering related systems, it is possible to grasp the status of other systems that may affect the own system.

  (5) In this embodiment, when it is determined that the defect occurrence frequency is high in the relevance evaluation process (in the case of “YES” in step S2-3), the control unit 21 of the test process management server 20 uses the common keyword. An extraction process is executed (step S2-4). Next, the control unit 21 executes a defect management vote search process (step S2-5) including a common keyword, and a relevance evaluation update process (step S2-6) using the defect management vote. Accordingly, it is possible to specify a related system using the keywords recorded in the defect management form and the specification change management form. Then, by using this relevance evaluation result, it is possible to identify a system that is preferably checked together at the time of system check or the like.

  (6) In the present embodiment, in the correction development support process, the control unit 21 of the test process management server 20 performs the correction development target specifying process (step S3-1) and the related system specifying process (step S3-2). Run. Next, the control unit 21 executes a defect occurrence status acquisition process (step S3-3). Then, when it is determined that the defect occurrence frequency is high (in the case of “YES” in Step S3-4), the control unit 21 of the test process management server 20 executes an alerting process (Step S3-5). As a result, it is possible to call attention to correction development related to a system having a high defect occurrence frequency.

  (7) In the present embodiment, in the report output process, the control unit 21 of the test process management server 20 executes a process for calculating the number of corresponding cases (step S4-3). As a result, it is possible to identify a system that has a large influence according to a defect or a specification change.

  Further, the control unit 21 executes a keyword extraction process (step S4-6) included in the test diary, a keyword distribution calculation process (step S4-7), and a progress rate evaluation process (step S4-8). Thereby, the suitability of the progress situation can be evaluated by the keyword.

  Further, the control unit 21 executes a progress comparison process of the report target system (step S4-9). Thereby, it is possible to grasp a system in which the progress of progress is not complete.

  (8) In this embodiment, in the library management process, the control unit 21 of the test process management server 20 performs an approval process (step S5-1), a corresponding data extraction process (step S5-2), and a version matching process. (Step S5-3) is executed. When the versions match (in the case of “YES” in step S5-4), the control unit 21 of the test process management server 20 executes a certification process as a releasable version (step S5-5). As a result, the correct version can be identified and the program can be released using the defect management form and the specification change management form.

In addition, you may change each said embodiment as follows.
In the above embodiment, the control unit 21 of the test process management server 20 executes a progress comparison process for the report target system (step S4-9). Instead of this, the control unit 21 of the test process management server 20 may execute a comparison process of the status of the previous report. In this case, the output report is recorded for each user. When a new report is created, the comparison result is output in comparison with the previous report. As a result, it is possible to grasp changes since the previous report was created.

  In the above embodiment, the control unit 21 of the test process management server 20 executes progress rate evaluation processing (step S4-8). Specifically, the report output means 217 of the control unit 21 acquires the progress rate of the test in this process from the test number record information D12. Next, the report output means 217 associates the extracted keyword distribution with the progress rate. Here, the number of responses to defects and specification changes may be associated with the progress rate. If the number of responses is large, the progress of the test may be delayed, so the cause of this delay can be grasped.

  In the above embodiment, the control unit 21 of the test process management server 20 executes the grouping proposal process (step S1-11). In this case, a related system having an influence on occurrence of a defect or specification change is specified by a combination of the system code of the cause system and the corresponding system. Then, when the system code of the identified related system is not recorded in the group registration information D05, the group management unit 214 of the control unit 21 prompts the client terminal 10 to propose grouping. Is output. In addition to this, it is also possible to output a message using the evaluation result data recorded in the relevance evaluation storage unit 24. In this case, the common keyword recorded in the relevance evaluation storage unit 24 is included in the grouping proposal message for related systems that are not recorded in the group registration information D05. Thereby, it is possible to determine whether group registration is necessary with reference to the common keyword.

  In the above embodiment, when it is determined that the defect occurrence frequency is high (in the case of “YES” in step S2-3), the control unit 21 of the test process management server 20 executes the common keyword extraction process (step S2). -4). Then, the control unit 21 of the test process management server 20 executes a defect management vote search process (step S2-5) including the common keyword, and a relevance evaluation update process (step S2-6) using the defect management vote. To do. Here, the occurrence of a situation different from the normal state in system development may be detected using a keyword. In this case, the test process management server 20 is provided with an appearance pattern storage unit as standard information storage means. In the appearance pattern storage unit, keywords (standard patterns) used in test diaries, defect management forms, and specification change management forms created by the person in charge of development are recorded. In the standard pattern, commonly used keywords and appearance frequencies are recorded in each process of system development.

  In the report output process, the control unit 21 of the test process management server 20 executes a keyword evaluation process. Specifically, the report output means 217 of the control unit 21 acquires the standard pattern from the appearance pattern storage unit. Next, the report output means 217 compares the standard pattern with the keyword distribution in the current system development. Then, the report output unit 217 determines that a standard defect has occurred or a specification has been changed for a keyword whose distribution matches the standard pattern. On the other hand, a keyword having a distribution different from the standard pattern is specified as a keyword to be noted, and the keyword to be noted is included in the report. In general, defects and specification changes that occur depending on processes in the initial stage and the final stage are different. Therefore, the development status can be evaluated based on the appearance status of the keywords recorded in the defect management form and the specification change management form for each process.

  In the above embodiment, the relevance evaluation process is executed using a defect management slip. Here, the relevance evaluation process may be performed using the specification change management slip.

  DESCRIPTION OF SYMBOLS 10 ... Client terminal, 20 ... Test process management server, 21 ... Control part, 210 ... Access control means, 211 ... Diary management means, 212 ... Defect management means, 213 ... Specification change management means, 214 ... Group management means, 215 ... Relevance evaluation means, 216 ... correction development support means, 217 ... report output means, 218 ... library management means, 22 ... management information storage section, 23 ... term dictionary storage section, 24 ... relevance evaluation storage section, 25 ... design Information storage unit, 26... Library storage unit.

Claims (8)

System master information storage means for storing identification information of a development target system in association with user information;
Group information storage means for storing system identification information related to the development target system in association with user information;
In management of system development, a management slip storage means for storing a management slip created by a user and recording system identification information;
A development support system comprising control means connected to a client terminal,
The control means is
Means for acquiring user information from the client terminal, and acquiring system identification information associated with the user information from the system master information storage means and group information storage means;
Means for extracting a management slip in which the acquired system identification information is recorded from the management slip storage means;
A development support system comprising means for creating a report including an evaluation result obtained by collecting the extracted management slips and outputting the report to the client terminal. A term storage means for storing keywords used in development;
2. The development support system according to claim 1, wherein the control means extracts a keyword recorded in the term storage means in the management slip and creates a report in which the appearance status of the keyword is recorded. . Information on the progress is recorded in the management slip,
The development support system according to claim 1, wherein the control unit calculates a progress rate based on a progress situation recorded in the management slip, and creates a report including the progress rate. . In the management slip, identification information of a cause system in which an event has occurred and identification information of a corresponding system that needs to be dealt with according to the influence of the event are recorded,
The control means is
Identify the identification information of the development target system associated with the user information,
A management slip in which the identification information of the development target system is recorded as either one of the identification information in the combination of the identification information of the cause system of the management slip and the identification information of the corresponding system recorded in the management slip storage means. Identify,
Means for proposing registration of the identification information of the other system to the group information storage means to the user if the identification information of the other system is not recorded in the group information storage means; The development support system according to claim 1, further comprising: When the identification information of the development target system is acquired, the related system associated with the development target system is specified,
For the related system, identify the defect occurrence status using the management slip,
The development support system according to any one of claims 1 to 4, wherein when the number of occurrences of defects is determined to be greater than a reference number in the state of occurrence of defects, a warning is issued regarding the development target system. . In the management slip, version information of a program used in the development target system is recorded,
The control means is
When the release approval information of the program of the development target system is acquired, the management slip of the development target system is acquired,
6. The development support system according to claim 1, further comprising means for specifying the latest version in the management form and registering it as a releasable version. System master information storage means for storing identification information of a development target system in association with user information;
Group information storage means for storing system identification information related to the development target system in association with user information;
In management of system development, a management slip storage means for storing a management slip created by a user and recording system identification information;
A method for supporting system development using a development support system comprising a control means connected to a client terminal,
The control means is
Obtaining user information from a client terminal, obtaining system identification information associated with the user information from the system master information storage means and group information storage means;
Extracting the management slip in which the identification information of the acquired system is recorded from the management slip storage means;
A development support method comprising: generating a report including an evaluation result obtained by collecting the extracted management slips and outputting the report to the client terminal. System master information storage means for storing identification information of a development target system in association with user information;
Group information storage means for storing system identification information related to the development target system in association with user information;
In management of system development, a management slip storage means for storing a management slip created by a user and recording system identification information;
A program for supporting system development using a development support system including a control means connected to a client terminal,
The control means;
Means for obtaining user information from a client terminal, and obtaining system identification information associated with the user information from the system master information storage means and group information storage means;
Means for extracting a management slip in which the acquired system identification information is recorded from the management slip storage means;
A development support program that functions as means for creating a report including an evaluation result obtained by collecting the extracted management slips and outputting the report to the client terminal.

Images