Information processing program, information processing device, and information processing method

Abstract

It is possible to automatically collect information about multiple second documents, each containing information about a first document, which is a deliverable for each of multiple system development projects. [Solution] The information processing program according to the present invention causes a computer to execute a collection procedure that collects information about a plurality of second documents according to a schedule, by referring to a third document that describes a first storage location information indicating the storage location of each of the plurality of second documents corresponding to each of the plurality of system development projects, and a recording procedure that records the information about the plurality of second documents collected by the collection procedure in a development deliverable database that records information about deliverables in each of the plurality of system development projects.

Description

Technical Field

[0001] The present invention relates to an information processing program, an information processing apparatus, and an information processing method.

Background Art

[0002] Conventionally, a technique for supporting the management of documents (hereinafter, may be referred to as "development documents") generated in each development process of software development and system development processes is known. For example, design document information related to a project is associated with discussion information related to the record of project activities. And a technique for holding the number of pages of a software design document created as the project progresses based on the associated information is known.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Means for Solving the Problems

[0004] The information processing program according to the present application is a plurality of second documents in which information on a first document that is a work product in each of a plurality of system development projects is described, and a third document that describes first storage location information indicating the storage location of each of the plurality of second documents corresponding to each of the plurality of system development projects, and a collection procedure for collecting information on the plurality of second documents according to a schedule, and a recording procedure for recording information on the plurality of second documents collected by the collection procedure in a development work product database that records information on work products in each of the plurality of system development projects, and causes a computer to execute.

Brief Description of the Drawings

[0005] [Figure 1] Figure 1 is a diagram illustrating the development process of a system. [Figure 2] Figure 2 shows an example of a deliverable record document according to the present invention. [Figure 3] Figure 3 is a diagram illustrating the overview of the information processing performed by the information processing apparatus according to the embodiment. [Figure 4] Figure 4 shows an example of the configuration of an information processing system according to the embodiment. [Figure 5] Figure 5 shows an example of the configuration of an information processing device according to the embodiment. [Figure 6] Figure 6 shows an example of information stored in the development deliverables database according to this embodiment. [Figure 7] Figure 7 shows an example of information stored in the case management ledger database according to this embodiment. [Figure 8] Figure 8 shows an example of information stored in the approval record database according to this embodiment. [Figure 9] Figure 9 shows an example of a real-time visualization image (list of deliverables) according to the embodiment. [Figure 10] Figure 10 shows an example of a real-time visualization image (review record) according to the embodiment. [Figure 11] Figure 11 shows an example of a real-time visualization image (handover information) according to the embodiment. [Figure 12] Figure 12 shows an example of a real-time visualization image (development function) according to the embodiment. [Figure 13] Figure 13 shows an example of a real-time visualization image (planning / system requirements definition) according to the embodiment. [Figure 14] Figure 14 shows an example of a real-time visualization image (design) according to the embodiment. [Figure 15] Figure 15 shows an example of a hardware configuration. [Modes for carrying out the invention]

[0006] The following describes in detail, with reference to the drawings, the embodiments for implementing the information processing program, information processing device, and information processing method relating to the present application (hereinafter referred to as "embodiments"). Note that these embodiments do not limit the information processing program, information processing device, and information processing method relating to the present application. Furthermore, the same parts are denoted by the same reference numerals in each of the following embodiments, and redundant descriptions are omitted.

[0007] (Embodiment) [1. Introduction] Figure 1 is a diagram illustrating the development process of a system. Figure 1 shows an example of a system development process generally known as the waterfall model. The waterfall model of system development is divided into multiple development stages, including business requirements definition, system requirements definition, basic design, detailed design, system implementation (manufacturing), unit testing, integration testing, comprehensive testing, and user acceptance testing, and each development stage follows a specific sequence.

[0008] Furthermore, in system development, the development personnel and development managers (hereinafter sometimes referred to as "development personnel") create development documents (hereinafter sometimes referred to as "the first document"), which are deliverables corresponding to each development stage of the system development. When the development personnel complete the creation of the development documents, the development stage corresponding to the development documents is completed. In other words, the status of the creation of the development documents (hereinafter also referred to as "progress status") corresponds to the progress status of the development stage corresponding to the development documents. Note that the status of the creation of the development documents can also be rephrased as the status of the completion of the development documents.

[0009] Here, "development documentation" is a general term for the deliverables in system development. Specifically, for example, development documentation may include development plans, requirements definitions, various design documents, various specifications, coding conventions, review results, or meeting minutes created in each development stage of system development. Although the term "document" is used for explanatory purposes, as mentioned above, development documentation is a concept that encompasses various deliverables created as results of system development and is not limited to document-format files. Development documentation may be data recorded in any data format (file format) as long as it relates to the deliverables in system development.

[0010] Although not shown in Figure 1, the development process may include a development planning phase, which determines the system development plan, before the business requirements definition phase. The development document corresponding to the development planning phase is the development plan document.

[0011] In Figure 1, the system development process begins with the business requirements definition phase. In the business requirements definition phase, development stakeholders interview the client to understand the business processes they want to systemize and compile the business requirements into a business requirements definition document. In other words, the development document corresponding to the business requirements definition phase is the business requirements definition document. The business requirements are compiled from the perspective of what challenges or problems in the business led to the need for system development, and what kind of business flow they want to achieve as the final goal. The business requirements are defined from the perspective of the client and users.

[0012] Next, after the development process of business requirement definition, the development process of system requirement definition is carried out. In the development process of system requirement definition, developers summarize system requirements such as functions and performance to be installed in the system in the system requirement definition document in order to realize the content summarized in the business requirement definition document. That is, the development document, which is the deliverable corresponding to the development process of system requirement definition, is the system requirement definition document. Note that system requirements are classified into functional requirements that define the functions to be implemented and non-functional requirements that define the content to be satisfied other than functions such as performance, stability, and security level.

[0013] Next, after the development process of system requirement definition, the development process of basic design is carried out. In the development process of basic design, developers specify the functions to be implemented in the system in order to realize the content summarized in the system requirement definition document and summarize them in the basic design document. That is, the development document, which is the deliverable corresponding to the development process of basic design, is the basic design document. Note that basic design is also called external design, and developers determine the specifications of the appearance (the outside of the system) such as the screens used by the requesters and users from the perspectives of the requesters and users who actually use the system.

[0014] Next, after the development process of basic design, the development process of detailed design is carried out. In the development process of detailed design, developers perform a detailed design on how to implement the functions to be implemented in the system in order to realize the content summarized in the basic design document and summarize them in the detailed design document. That is, the development document, which is the deliverable corresponding to the development process of detailed design, is the detailed design document. Note that detailed design is also called internal design, and developers determine the internal specifications of the system from the perspective of developers.

[0015] Next, after the detailed design development process, the system implementation (manufacturing) development process is carried out. In the system implementation (manufacturing) development process, developers perform programming based on the detailed design document to create the source code that constitutes the system to be developed. For example, the development document that is the deliverable corresponding to the system implementation (manufacturing) development process may be the source code. Note that the system to be developed is created by combining a plurality of source codes. For example, the source code corresponds to the source code for a module that is a component of the program.

[0016] Next, after the system implementation (manufacturing) development process, the unit test development process is carried out. In the unit test development process, developers verify whether the program operates normally in terms of individual functions. In the unit test development process, it is tested whether the modules that are components of the program function properly. In other words, the unit test is a test conducted to confirm the quality of each module included in the system to be developed. Note that the content verified in the unit test corresponds to the content of the detailed design document. Also, the developers summarize the information regarding the verification content of the unit test in the unit test specification document. That is, the development document that is the deliverable corresponding to the unit test development process is the unit test specification document.

[0017] Next, after the unit test development process, the integration test development process is carried out. In the integration test development process, developers verify whether the functions combined operate normally. In the integration test development process, in addition to the combination of modules, tests for confirming the combination with external modules are also conducted. In other words, the integration test is a test conducted to confirm the quality of the combination of a plurality of modules included in the system to be developed. Note that the content verified in the integration test corresponds to the content of the basic design document. Also, the developers summarize the information regarding the verification content of the integration test in the integration test specification document. That is, the development document that is the deliverable corresponding to the integration test development process is the integration test specification document.

[0018] Next, following the integration testing development phase, the development process moves on to the system testing phase. In the system testing phase, development personnel verify that all functions are combined and the system operates correctly. In other words, system testing is conducted to confirm the overall quality of the system under development. The content verified in system testing corresponds to the content of the system requirements definition document. Furthermore, development personnel compile information regarding the verification content of system testing into a system testing specification document. That is, the development document that corresponds to the system testing development phase is the system testing specification document.

[0019] Next, following the development phase of integrated testing, the development phase moves on to the user acceptance testing phase. In the user acceptance testing phase, development personnel verify whether the system functions correctly in the actual operating environment used by the client or users. In other words, user acceptance testing is a test that checks the quality of the system under development in the actual operating environment used by the client or users. The content verified in user acceptance testing corresponds to the content of the business requirements definition document. Furthermore, development personnel compile information regarding the verification content of user acceptance testing into a user acceptance testing specification document. That is, the development document that corresponds to the user acceptance testing phase is the user acceptance testing specification document.

[0020] The development documents according to this embodiment may be direct deliverables in development, such as development plans, requirements specifications, various design documents (screen design documents, interface design documents, program design documents, non-functional design documents), and test specifications (specifications for various tests such as unit tests, integration tests, system tests, and acceptance tests), or they may be indirect deliverables in development, such as minutes of meetings related to development and checklists containing items to be checked during reviews. Furthermore, the development documents may be written in natural language.

[0021] Furthermore, generally, each development process in system development is managed for each system development project (hereinafter sometimes referred to as "system development project"). Here, a system development project may be the new development of a specified system, or the addition, modification, or specification change of functions in a specified system. In other words, since each development process in system development is managed for each system development project, it is desirable that information regarding development documents corresponding to each development process be easily managed for each system development project. In contrast, it has not been easy to manage information regarding development documents for each system development project in the past. For example, it has not been easy to grasp the progress of development documents, which are deliverables corresponding to each development process of system development, for each system development project in the past. Also, because it has not been easy to grasp the progress of development documents for each system development project in the past, it has not been easy to grasp the progress of each development process of system development for each system development project in the past. For example, if the progress of the system requirements definition document (e.g., completion status) is about 80%, development personnel can estimate that the progress of the system requirements definition development process is also about 80%. The progress of development documentation can be calculated as the ratio of the number of entries (items) completed by development personnel to the total number of entries (items) contained in the documentation. In contrast, traditionally, development personnel had to visually check the progress of each development document by looking at its contents one by one. Also, since the storage location of development documentation generally differs for each document, development personnel had to go through the trouble of referring to the storage location of each document. Thus, traditionally, it was not easy to manage information related to development documentation for each system development project.

[0022] In response to this, the present inventors have developed a deliverable record document (hereinafter sometimes referred to as the "second document") which describes information about development documents (first documents), which are deliverables corresponding to each development stage of system development. The deliverable record document is a document created for each system development project. An example of a deliverable record document according to the embodiment will be explained using Figure 2. Figure 2 is a diagram showing an example of a deliverable record document according to the embodiment. Specifically, the deliverable record document includes multiple sheets. Figure 2 shows the deliverable list sheet, which is one of the multiple sheets included in the deliverable record document.

[0023] The deliverable list sheet records information such as "Process," "Document Name," "Storage Location," "Approval Request Date," "Approval Completion Date," and "Status" in a coordinated manner. For example, the "Process" field stores information that identifies each of the multiple development processes in system development (e.g., the name of each development process). The "Document Name" field stores the names of the multiple development documents corresponding to each of the multiple development processes. The "Storage Location" field stores storage location information indicating the storage location of each of the multiple development documents. This storage location information may be, for example, a URL or a file path. The "Approval Request Date" field stores the date on which a request for approval of the development document was made by a development stakeholder, for example, an executive of the organization. The "Approval Completion Date" field stores the date on which the development document was approved, for example, by an executive of the organization. The "Status" field stores progress information indicating the progress status of each of the multiple development documents.

[0024] As explained in Figure 2, the deliverable record document includes a deliverable list sheet that associates and describes information that can identify each of the multiple development processes of the system development, information that can identify each of the multiple development documents corresponding to each of the multiple development processes, information indicating the storage location of each of the multiple development documents, information indicating the date on which the approval request for each of the multiple development documents was made to the development manager, information indicating the date on which the approval of each of the multiple development documents was completed by the development manager, and progress information indicating the progress status of each of the multiple development documents. For example, the deliverable record document includes information indicating the completion rate of each of the multiple development documents included in the deliverable list sheet as progress information. Here, the completion rate of the table of contents is calculated as the ratio of the number of table of contents (items) that have been completed by development personnel to the total number of table of contents (items) included in the development document. The deliverable list sheet of the deliverable record document may also include dates indicating the planned completion date and the actual completion date for each of the multiple development processes.

[0025] Thus, the second document (deliverable record document) describes, as information related to the first document (development document), the second storage location information indicating the storage location of each of the multiple first documents, which are deliverables corresponding to each of the multiple development processes of the system development project, and the first progress information indicating the progress status of each of the multiple first documents. This makes it easier to manage information related to development documents corresponding to each of the multiple development processes of the system development project for each system development project. For example, it becomes easier to grasp the progress status of development documents corresponding to each of the multiple development processes of the system development project for each system development project. In addition, it eliminates the need for development personnel to refer to the storage location of each development document.

[0026] Furthermore, the deliverable record document includes, in addition to the deliverable list sheet explained in Figure 2, a review comments sheet that describes information regarding review comments, a handover items sheet that describes information regarding handover items, a development function sheet that describes information regarding development functions, a document creation status sheet that describes information regarding the creation status of development documents, and a test information sheet that describes test information related to the testing process.

[0027] The review feedback sheet records information by associating it with items such as "Process," "Target Deliverable," "Feedback Classification," "Feedback Details," "Status," "Scheduled Completion Date," and "Completion Date." The "Process" item stores information that can identify each of the multiple development processes in system development (for example, the name of each development process). The "Target Deliverable" item stores the name of the development document that was the subject of the review feedback. The "Feedback Classification" item stores information indicating the type of feedback content of the review. The "Feedback Details" item stores the content of the review feedback. The "Status" item stores progress information indicating the progress of the response to the review feedback. The "Scheduled Completion Date" item stores the scheduled completion date for the response to the review feedback. The "Completion Date" item stores the date on which the response to the review feedback was completed.

[0028] The handover sheet records information in a coordinated manner across items such as "Process," "Impact," "Handover Items," "Status," "Scheduled Completion Date," and "Completion Date." The "Process" item stores information that identifies each of the multiple development processes in system development (for example, the name of each development process). The "Impact" item stores information indicating the degree of impact of the handover items on system development. The "Handover Items" item stores the content of the handover items. The "Status" item stores progress information indicating the progress of the response to the handover items. The "Scheduled Completion Date" item stores the scheduled completion date for the response to the handover items. The "Completion Date" item stores the date on which the response to the handover items was completed.

[0029] The development function sheet records information such as "function classification," "function ID," "function name," "new / modified," "number of unit tests," "number of integration tests," and "number of system tests" by associating them with each other. The "function classification" field stores the type of function being developed. The "function ID" field stores information that can identify the function being developed. The "function name" field stores the name of the function being developed. The "new / modified" field stores whether the function is being newly created or modified. The "number of unit tests" field stores the number of unit tests performed on the function being developed. The "number of integration tests" field stores the number of integration tests performed on the function being developed. The "number of system tests" field stores the number of system tests performed on the function being developed.

[0030] The document creation status sheet records information such as "document type," "table of contents," "content to be included," and "completion rate" by associating them with each other. The "document type" item stores information that identifies the development document (e.g., the name of the development document). The "table of contents" item stores information indicating the table of contents included in the development document. The "content to be included" item stores information indicating whether the content of the table of contents included in the development document is the content to be included. The "completion rate" item stores the completion rate of the table of contents included in the development document.

[0031] The test information sheet records information such as "test process," "effort," "number of tests," "test density," "number of bugs," and "bug density" in a manner that links them together. The "test process" item stores information that identifies the test process in system development (e.g., the name of each test process). The "effort" item stores the estimated effort provided by the development vendor for each system. For example, the "effort" item stores the estimated time required to develop that system. The "effort" item may also store the number of steps (e.g., number of lines) of the source code that makes up the system. The "number of tests" item stores the number of tests in the test process. The "test density" item stores the value obtained by dividing the number of tests by the effort. The "number of bugs" item stores the number of bugs. The "bug density" item stores the value obtained by dividing the number of bugs by the effort.

[0032] Furthermore, given the development of deliverable record documents that record information for each system development project, there is a need for a technology that automatically collects information on multiple deliverable record documents corresponding to each of multiple system development projects. Therefore, the inventors have developed a technology that automatically crawls information on multiple deliverable record documents corresponding to each of multiple system development projects.

[0033] Figure 3 will be used to illustrate the overview of the information processing performed by the information processing device according to the embodiment. Figure 3 is a diagram illustrating the overview of the information processing performed by the information processing device according to the embodiment. The information processing device executes the information processing method according to the embodiment by executing the information processing program according to the embodiment. In Figure 3, the collection of information by the information processing device according to a schedule is described as automatic crawling. In Figure 3, the information processing device collects information on each of the multiple deliverable record documents (second documents) corresponding to each of the multiple system development projects according to a schedule. Each of the multiple deliverable record documents describes information on the first document, which is a deliverable in each of the multiple system development projects. Specifically, the information processing device collects information on each of the multiple deliverable record documents according to a schedule by referring to a project management ledger database (hereinafter sometimes referred to as the "third document") which describes storage location information indicating the storage location of each of the multiple deliverable record documents. Here, the schedule may be, for example, at predetermined intervals (e.g., every 24 hours), or it may be a set of predetermined dates and times specified in advance by the user (e.g., 24:00 on December 1, 2024, 24:00 on December 2, 2024, etc.). The information processing device also records information about the collected multiple deliverable record documents in the development deliverable database. The development deliverable database records information about deliverables for each of the multiple system development projects.

[0034] As described above, the information processing device according to the embodiment collects information about a plurality of second documents according to a schedule, by referring to a third document that describes a first storage location information indicating the storage location of each of the plurality of second documents corresponding to each of the plurality of system development projects, which each of the plurality of second documents describes information about a first document that is a deliverable in each of the plurality of system development projects. The information processing device also records the collected information about the plurality of second documents in a development deliverable database that records information about deliverables in each of the plurality of system development projects. In this way, the information processing device can automatically collect information about a plurality of second documents that describe information about a first document that is a deliverable in each of the plurality of system development projects. In other words, the information processing device can automatically collect information about a plurality of deliverable record documents corresponding to each of the plurality of system development projects. In addition, the information processing device can automatically record information about a plurality of deliverable record documents in a development deliverable database.

[0035] [2. Configuration of the Information Processing System] An example configuration of the information processing system 1 according to the embodiment will be described using Figure 4. Figure 4 is a diagram showing an example configuration of the information processing system 1 according to the embodiment. As shown in Figure 4, the information processing system 1 includes a user terminal 10 and an information processing device 100. The user terminal 10 and the information processing device 100 are connected via a predetermined communication network (network N) and are able to communicate by wired or wireless means.

[0036] The user terminal 10 is an information processing device used by a user who is involved in the development of the system. For example, the user terminal 10 is an information processing device such as a desktop PC (Personal Computer) or a notebook PC. Alternatively, the user terminal 10 may be a smart device such as a smartphone or tablet. The user terminal 10 also has a screen such as an LCD display and accepts various operations from the user on the displayed content (e.g., documents or images) on the screen. Operations performed on the area of ​​the screen where the content is displayed may also be considered operations on the content.

[0037] The information processing device 100 is an information processing device that executes an information processing program according to the embodiment. The information processing device 100 collects information about multiple deliverable record documents according to a schedule by referring to a project management ledger database which describes storage location information indicating the storage location of each of multiple deliverable record documents corresponding to each of multiple system development projects. The information processing device 100 also records the collected information about the multiple deliverable record documents in a development deliverable database.

[0038] [3. Configuration of the Information Processing Device] An example of the configuration of the information processing device 100 according to the embodiment will be described using Figure 5. Figure 5 is a diagram showing an example of the configuration of the information processing device 100 according to the embodiment. The information processing device 100 has a communication unit 110, a storage unit 120, and a control unit 130.

[0039] (Storage unit 120) The storage unit 120 is implemented by, for example, semiconductor memory elements such as RAM (Random Access Memory) and flash memory, or storage devices such as hard disks and optical discs. Specifically, the storage unit 120 stores the information processing program according to the embodiment. The storage unit 120 also includes a development deliverable database 121, a project management ledger database 122, and an approval record table database 123.

[0040] The development deliverable database 121 is a database that stores information relating to each of multiple system development projects. Specifically, the development deliverable database 121 stores information relating to each of multiple deliverable record documents corresponding to each of the multiple system development projects. More specifically, the development deliverable database 121 stores information relating to deliverables in each of the multiple system development projects. Figure 6 is a diagram showing an example of the information stored in the development deliverable database 121 according to this embodiment.

[0041] As shown in Figure 6, the development deliverables database 121 stores project information, deliverable list information, review comments information, handover information, development function information, document creation status information, and test information in a mutually related manner.

[0042] For example, the development deliverables database 121 stores information such as "linking key," "update date and time," "development project number," "development project name," "system code," "system name," "planned release month," and "status" as project information, with each item associated with the others.

[0043] The "Linking Key" field stores information linking each system development project's information stored in the Development Deliverables Database 121 with the information stored in the Project Management Ledger Database 122. The "Update Date and Time" field stores the update date and time of the project information. The "Development Project Number" field stores a number that identifies the system development project. The "Development Project Name" field stores the name of the system development project. The "System Code" field stores information that can identify the system being developed. The "System Name" field stores the name of the system being developed. The "Release Month" field stores the month in which development is scheduled to be completed and the system to be released or made available (for example, a specific month such as "December 2024"). The "Status" field stores information indicating the progress of the development project. For example, the "Status" field stores information indicating what stage of development the project is currently in. For example, the "Status" field stores information that identifies each development stage, such as "Development," "Business Requirements Definition," "System Requirements Definition," "Basic Design," "Detailed Design," "System Implementation (Manufacturing)," "Unit Testing," "Integration Testing," "System Testing," "User Acceptance Testing," "Release Preparation," or "Release Completed" (for example, the name of each development stage).

[0044] Furthermore, the development deliverables database 121 stores information such as "linking key," "update date and time," "process," "document name," "storage location," "approval request date," "approval completion date," and "status" as deliverable list information, with each item associated with the others.

[0045] The "Linking Key" field stores linking information about each system development project stored in the development deliverables database 121 with information about each system development project stored in the project management ledger database 122. The "Update Date and Time" field stores the update date and time of the deliverables list information. The "Process" field stores information that can identify each of the multiple development processes in system development (for example, the name of each development process). The "Document Name" field stores the names of each of the multiple development documents corresponding to each of the multiple development processes. The "Storage Location" field stores storage location information indicating the storage location of each of the multiple development documents. The storage location information may be, for example, a URL or a file path. The "Approval Request Date" field stores the date on which a request for approval of the development document was made by a development stakeholder, for example, an executive of the organization. The "Approval Completion Date" field stores the approval date on which the development document was approved, for example, by an executive of the organization. The "Status" field stores progress information indicating the progress status of each of the multiple development documents.

[0046] Furthermore, the development deliverables database 121 stores information such as "linking key," "update date and time," "process," "target deliverable," "criteria classification," "criteria content," "status," "scheduled completion date," and "completion date" as review feedback information, linking them together.

[0047] The "Linking Key" field stores linking information about each system development project stored in the development deliverables database 121 with information about each system development project stored in the project management ledger database 122. The "Update Date and Time" field stores the update date and time of the review comments. The "Process" field stores information that can identify each of the multiple development processes in system development (for example, the name of each development process). The "Target Deliverable" field stores the name of the development document that was the subject of the review comments. The "Comment Classification" field stores information indicating the type of review comment. The "Comment Content" field stores the content of the review comments. The "Status" field stores progress information indicating the progress of the response to the review comments. The "Scheduled Completion Date" field stores the scheduled completion date for the response to the review comments. The "Completion Date" field stores the date on which the response to the review comments was completed.

[0048] Furthermore, the development deliverables database 121 stores information such as "linking key," "update date and time," "process," "impact," "handover items," "status," "scheduled completion date," and "completion date" as handover information, with each item associated with the others.

[0049] The "Linking Key" field stores linking information about each system development project stored in the development deliverables database 121 with information about each system development project stored in the project management ledger database 122. The "Update Date and Time" field stores the update date and time of the handover information. The "Process" field stores information that can identify each of the multiple development processes in system development (for example, the name of each development process). The "Impact" field stores information indicating the degree of impact on system development due to the content of the handover. The "Handover Item" field stores the content of the handover. The "Status" field stores progress information indicating the progress of the response to the handover. The "Scheduled Completion Date" field stores the scheduled completion date of the response to the handover. The "Completion Date" field stores the date on which the response to the handover was completed.

[0050] Furthermore, the development deliverables database 121 stores information such as "linking key," "update date and time," "function classification," "function ID," "function name," "new / modified," "number of unit tests," "number of integration tests," and "number of system tests" as development function information, linking them together.

[0051] The "Linking Key" field stores linking information about each system development project stored in the development deliverables database 121 with information about each system development project stored in the project management ledger database 122. The "Update Date and Time" field stores the update date and time of the development function information. The "Function Classification" field stores the type of function being developed. The "Function ID" field stores information that can identify the function being developed. The "Function Name" field stores the name of the function being developed. The "New / Modified" field stores whether the function is newly created or modified. The "Unit Test Count" field stores the number of unit tests performed on the function being developed. The "Integration Test Count" field stores the number of integration tests performed on the function being developed. The "System Test Count" field stores the number of system tests performed on the function being developed.

[0052] Furthermore, the development deliverables database 121 stores information such as "linking key," "update date and time," "document category," "table of contents," "target," and "completion rate" as document creation status information, linking them together.

[0053] The "Linking Key" field stores linking information about each system development project stored in the development deliverables database 121 with information about each system development project stored in the project management ledger database 122. The "Update Date and Time" field stores the update date and time of the document creation status information. The "Document Category" field stores information that can identify the development document (e.g., the name of the development document). The "Table of Contents" field stores information indicating the table of contents included in the development document. The "Contents to be Included" field stores information indicating whether the contents of the table of contents included in the development document are included. The "Contents to be Included" field stores the contents to be included in the table of contents included in the development document.

[0054] Furthermore, the development deliverables database 121 stores information such as "linking key," "update date and time," "test process," "effort," "number of tests," "test density," "number of bugs," and "bug density" as test information, linking them together.

[0055] The "Linking Key" field stores linking information about each system development project stored in the development deliverables database 121 with information about each system development project stored in the project management ledger database 122. The "Update Date and Time" field stores the update date and time of the test information. The "Test Process" field stores information that can identify the test process in system development (e.g., the name of each test process). The "Effort" field stores the estimated effort provided by the development vendor for each system. For example, the "Effort" field stores the estimated time required to develop the system. The "Effort" field may also store the number of steps (e.g., number of lines) of source code that makes up the system. The "Number of Tests" field stores the number of tests in the test process. The "Test Density" field stores the value obtained by dividing the number of tests by the effort. The "Number of Bugs" field stores the number of bugs. The "Bug Density" field stores the value obtained by dividing the number of bugs by the effort.

[0056] The project management ledger database 122 is a database that stores information about multiple system development projects. Figure 7 shows an example of the information stored in the project management ledger database 122 according to this embodiment.

[0057] As shown in Figure 7, the project management ledger database 122 stores information such as "linking key," "development project number," "development project name," "system code," "system name," "planned release month," "status," "planned release date," and "location of deliverable record sheet storage" in a manner that associates them with each other.

[0058] The "Linking Key" field stores linking information about each system development project stored in the development deliverables database 121 with information about each system development project stored in the project management ledger database 122. The "Development Project Number" field stores a number that identifies the system development project. The "Development Project Name" field stores the name of the system development project. The "System Code" field stores information that can identify the system being developed. The "System Name" field stores the name of the system being developed. The "Release Month" field stores the month in which development is scheduled to be completed and the system is scheduled to be released or made available (for example, a specific month such as "December 2024"). The "Release Month" field may also include the release date. The "Status" field stores information indicating the progress of the development project. For example, the "Status" field stores information indicating what stage of development the project is currently in. For example, the "Status" field stores information that identifies each development stage, such as "Development," "Business Requirements Definition," "System Requirements Definition," "Basic Design," "Detailed Design," "System Implementation (Manufacturing)," "Unit Testing," "Integration Testing," "System Testing," "User Acceptance Testing," "Release Preparation," or "Release Completed" (for example, the name of each development stage). The "Deliverable Record Storage Location" field stores storage location information indicating where the deliverable record document is stored. The storage location information may be a URL or a file path, for example.

[0059] Thus, the third document (project management ledger database 122) includes items corresponding to the second progress information that shows the progress status of each of the multiple system development projects (for example, the "Status" item), and items corresponding to the planned release date of each of the multiple system development projects (for example, the "Planned Release Month" item).

[0060] Furthermore, the project management ledger database 122 also contains information on items such as "development techniques," "standard process types," and "tailoring declarations." The "development techniques" item stores information indicating the methods and methodologies used in system development. For example, the "development techniques" item stores information on the progress of development projects and how work is carried out, such as "agile development" and "waterfall development." The "standard process types" item stores information indicating the general workflow and types of processes in system development. For example, the "standard process types" item stores information such as "AP development" (application development), "configuration changes," "bug fixes (design)," "bug fixes (programming)," and "other." The "tailoring declaration" item stores a declaration indicating that it has been formally decided to customize standard development methods and processes to suit the requirements of a specific project. The "tailoring declaration" item also stores information including special changes and adjustments for each development project.

[0061] The approval record database 123 is a database that stores information regarding the approval of development documents for each of multiple system development projects. Figure 8 shows an example of the information stored in the approval record database 123 according to this embodiment.

[0062] As shown in Figure 8, the approval record database 123 stores approval request list information and approval list information in a mutually related manner.

[0063] For example, the approval record database 123 stores information such as "development project number," "development project name," "system code," "system name," "scheduled release month," "deliverable record storage location," "approval ID," "approval request date and time," "approval requester," "approval recipient To," and "approval recipient Cc" in a manner that associates them with each other.

[0064] The "Development Project Number" field stores a number that identifies the system development project. The "Development Project Name" field stores the name of the system development project. The "System Code" field stores information that identifies the system being developed. The "System Name" field stores the name of the system being developed. The "Scheduled Release Month" field stores the month in which development is scheduled to be completed and the system to be released or made available (for example, a specific month such as "December 2024"). The "Deliverable Record Storage Location" field stores storage location information indicating the storage location of the deliverable record document corresponding to the system development project. The "Approval ID" field stores identification information that identifies the approval request. The "Approval Request Date and Time" field stores the date and time of the approval request. The "Approval Requester" field stores information that identifies the person who made the approval request (for example, the name of the person who made the approval request). The "Approval To" field stores the approver's email address. The "Approval To Cc" field stores the email addresses of users that should be included in the CC field of the approval request email.

[0065] Furthermore, the approval record database 123 stores information such as "development project number," "development project name," "system code," "system name," "scheduled release month," "deliverable record storage location," "approval ID," "approval request date and time," "approval requester," "approval recipient To," "approval recipient Cc," "approval date and time," "approver," and "approval email link" as approval list information, with the items being associated with each other.

[0066] The "Development Project Number" field stores a number that identifies the system development project. The "Development Project Name" field stores the name of the system development project. The "System Code" field stores information that identifies the system being developed. The "System Name" field stores the name of the system being developed. The "Scheduled Release Month" field stores the month in which development is scheduled to be completed and the system to be released or made available (for example, a specific month such as "December 2024"). The "Deliverable Record Storage Location" field stores storage location information indicating the storage location of the deliverable record document corresponding to the system development project. The "Approval ID" field stores identification information that identifies the approval request. The "Approval Request Date and Time" field stores the date and time of the approval request. The "Approval Requester" field stores information that identifies the person who made the approval request (for example, the name of the person who made the approval request). The "Approval To" field stores the approver's email address. The "Approval To Cc" field stores the email addresses of users that should be included in the CC field of the approval request email. The "Approval Date and Time" field stores the date and time the approval was made. The "Approver" field stores information that identifies the approver (e.g., the approver's name). The "Approval Email Link" field stores a link to the approval request email.

[0067] (Communications Department 110) The communication unit 110 is implemented using a NIC (Network Interface Card), an antenna, etc. The communication unit 110 is connected to various networks by wired or wireless means, and for example, transmits and receives information with other information processing devices other than the information processing device 100.

[0068] (Control unit 130) The control unit 130 is a controller, and is realized, for example, by executing various programs stored in the memory device inside the information processing device 100 using RAM as the working area, using a CPU (Central Processing Unit) or MPU (Micro Processing Unit), etc. Alternatively, the control unit 130 is a controller and can be realized, for example, by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array).

[0069] The control unit 130 has a reception unit 131, a collection unit 132, a recording unit 133, a generation unit 134, and a determination unit 135 as functional units, and may realize or execute the information processing operations described below. Note that the internal configuration of the control unit 130 is not limited to the configuration shown in Figure 5, and other configurations are also possible as long as they perform the information processing described later. Also, each functional unit represents the function of the control unit 130 and does not necessarily have to be physically separated.

[0070] (Reception desk 131) The reception unit 131 accepts operations to register information to the case management ledger database 122. For example, the reception unit 131 accepts operations to register case information to the case management ledger database 122. When the reception unit 131 accepts an operation to register case information, it stores the registered case information in the case management ledger database 122, associating it with a linking key. The reception unit 131 also accepts operations to update or delete information to the case management ledger database 122.

[0071] Furthermore, the reception unit 131 accepts registration operations for information corresponding to predetermined mandatory compliance items in the project management ledger database 122. For example, mandatory compliance items include items such as "development project number," "development project name," "system name," "status," "planned release month," "planned release date," "development technique," "standard process type," "tailoring declaration," "deliverable record storage location," "approval completion date," "switchover (link)," and "switchover (approval completion date)." The "approval completion date" item stores the date on which the system requirements were formally approved. The "switchover (link)" item stores a link to information regarding the procedures and plans for switching from the old system to the new system. The "switchover (approval completion date)" item stores the date on which the switch from the old system to the new system was formally approved. When the reception unit 131 accepts registration operations for information corresponding to mandatory compliance items, it stores the information entered in the registered mandatory compliance items in the project management ledger database 122, associating it with a linking key.

[0072] Furthermore, the reception unit 131 may accept registration operations for items specified by the user. When the reception unit 131 accepts registration operations for items specified by the user, it adds the items specified by the user to the items in the case management ledger database 122. In this way, the third document (case management ledger database 122) further includes items specified by the user.

[0073] (Collection Section 132) The collection unit 132 collects information about multiple second documents (deliverable record documents) according to a schedule, by referring to a third document (project management ledger database 122) which describes a first storage location information indicating the storage location of each of the multiple second documents corresponding to each of the multiple system development projects. Specifically, the collection unit 132 collects information about multiple deliverable record documents according to a schedule by referring to deliverable record table storage location information indicating the storage location of each of the multiple deliverable record documents described in the project management ledger database 122. For example, the collection unit 132 collects information about multiple deliverable record documents at predetermined intervals (e.g., every 24 hours). Furthermore, the collection unit 132 collects information on multiple deliverable record documents at multiple predetermined dates and times specified in advance by the user (for example, 24:00 on December 1, 2024, 24:00 on December 2, 2024, etc.).

[0074] For example, the collection unit 132 collects information related to multiple deliverable record documents, specifically regarding the deliverable list sheet, review comments sheet, handover items sheet, development function sheet, document creation status sheet, and test information sheet of each of the multiple deliverable record documents. More specifically, the collection unit 132 collects deliverable list information contained in each of the deliverable list sheets of each of the multiple deliverable record documents. The collection unit 132 also collects review comments contained in each of the review comments sheet of each of the multiple deliverable record documents. The collection unit 132 also collects handover items contained in each of the handover items sheet of each of the multiple deliverable record documents. The collection unit 132 also collects development function information contained in each of the development function sheet of each of the multiple deliverable record documents. The collection unit 132 also collects document creation status information contained in each of the document creation status sheet of each of the multiple deliverable record documents. Furthermore, the collection unit 132 collects test information contained in each test information sheet of the multiple deliverable record documents as information related to the multiple deliverable record documents.

[0075] (Record Section 133) The recording unit 133 records information about multiple second documents (deliverable record documents) collected by the collection unit 132 in the development deliverable database 121, which records information about deliverables in each of multiple system development projects. Specifically, the recording unit 133 stores information about multiple deliverable record documents collected by the collection unit 132 in association with information about each of the multiple system development projects. More specifically, the recording unit 133 records information about multiple deliverable record documents collected by the collection unit 132 in association with project information for each of the multiple system development projects in the development deliverable database 121. For example, the recording unit 133 records the deliverable list information, review comment information, handover information, development function information, document creation status information, and test information corresponding to each development project collected by the collection unit 132 in association with project information for each development project in the development deliverable database 121.

[0076] (Generation unit 134) The generation unit 134 generates a real-time visualization image, which is an image that visualizes information about each of the multiple second documents (deliverable record documents), based on the information recorded in the development deliverable database 121. For example, if the generation unit 134 generates a real-time visualization image, it may send the generated real-time visualization image to the user terminal 10.

[0077] Figure 9 shows an example of a real-time visualization image (list of deliverables) according to the embodiment. For example, the generation unit 134 generates a real-time visualization image 121-1 corresponding to the deliverable list sheet based on the deliverable list information recorded in the development deliverable database 121.

[0078] Figure 10 shows an example of a real-time visualization image (review record) according to the embodiment. For example, the generation unit 134 generates a real-time visualization image 121-2 corresponding to the review comment sheet based on the review comment information recorded in the development deliverable database 121.

[0079] Figure 11 shows an example of a real-time visualization image (handover information) according to the embodiment. For example, the generation unit 134 generates a real-time visualization image 121-3 corresponding to the handover information sheet based on the handover information recorded in the development deliverable database 121.

[0080] Figure 12 shows an example of a real-time visualization image (development function) according to the embodiment. For example, the generation unit 134 generates a real-time visualization image 121-4 corresponding to the development function sheet based on the development function information recorded in the development deliverable database 121.

[0081] Figure 13 shows an example of a real-time visualization image (plan / system requirements definition) according to the embodiment. For example, the generation unit 134 refers to the storage location information of each of the multiple development documents included in the list of deliverables information recorded in the development deliverables database 121, and obtains the table of contents information of each of the multiple development documents. In Figure 13, the multiple development documents are a system requirements definition document, a development plan document, and a test plan document. Subsequently, the generation unit 134 calculates the completion rate of each of the tables of contents of the multiple development documents based on the acquired table of contents information. Subsequently, the generation unit 134 generates a real-time visualization image 121-5 based on the table of contents information and the completion rate of each of the multiple development documents.

[0082] Figure 14 shows an example of a real-time visualization image (design) according to the embodiment. For example, the generation unit 134 generates a real-time visualization image 121-6 corresponding to the document creation status sheet based on the document creation status information recorded in the development deliverable database 121. Figure 14 shows a real-time visualization image 121-6 when the development document is a design document.

[0083] (Judgment unit 135) The determination unit 135 determines whether each of the multiple development processes in each of the multiple system development projects is progressing as planned, based on the planned completion date and the actual completion date of each of the multiple development processes in each of the multiple system development projects. For example, the determination unit 135 refers to the development deliverable database 121 and determines whether the actual completion date for each of the multiple development processes in each of the multiple system development projects is recorded. If the actual completion date is recorded, the determination unit 135 terminates the process. On the other hand, if the actual completion date is not recorded, the determination unit 135 determines whether the planned completion date is recorded. If the planned completion date is not recorded, the determination unit 135 terminates the process. On the other hand, if the planned completion date is recorded, the determination unit 135 determines whether the number of days until the planned completion date is within a predetermined number of days (for example, 3 days). For example, if the determination unit 135 determines that the number of days until the planned completion date is not within a predetermined number of days, it determines that the specified development process is progressing as planned. On the other hand, if the determination unit 135 determines that the number of days remaining until the scheduled completion date is within a predetermined number of days, it determines that the predetermined development process is not progressing as planned.

[0084] Furthermore, if the determination unit 135 determines that a predetermined development process is not progressing as planned, the generation unit 134 generates notification information indicating that the predetermined development process is not progressing as planned. For example, the generation unit 134 generates notification information that includes the number of days remaining until the scheduled completion date. Also, if the generation unit 134 generates notification information, it may send the generated notification information to the user terminal 10.

[0085] Furthermore, the determination unit 135 determines, for each of the multiple system development projects, whether or not information corresponding to predetermined mandatory compliance items is included in the third document. For example, the determination unit 135 refers to the project management ledger database 122 to determine whether or not information corresponding to predetermined mandatory compliance items is included.

[0086] [4. Variations] The information processing device 100 may send an approval request email in response to a predetermined operation on the deliverable record document. The deliverable record document displays checkboxes corresponding to each of several development documents. For example, the reception unit 131 receives an operation from the user to check the checkbox corresponding to a predetermined development document in the deliverable record document. When the reception unit 131 receives the operation to check the checkbox corresponding to the predetermined development document, the generation unit 134 displays an approval request button corresponding to the predetermined development document on the deliverable record document so that it can be selected. The reception unit 131 also receives a selection operation for the approval request button from the user. When the reception unit 131 receives the selection operation for the approval request button, the generation unit 134 generates an approval ID and stores the approval request information related to the approval request identified by the approval ID in the approval record table database 123. The generation unit 134 also generates an approval request email (hereinafter sometimes referred to as "approval request email") by referring to the development deliverable database 121. For example, the generation unit 134 refers to the development deliverables database 121 and generates an approval request email that includes the specified development document subject to the approval request as an attachment. The generation unit 134 also refers to the approval record database 123 and generates an approval request email that includes the approver's name, a sentence describing the content of the approval request, an approve button, and a reject button. If the generation unit 134 has generated an approval request email, it sends the approval request email to the approver's user terminal 10.

[0087] [5. Effects] As described above, the information processing device 100 according to the embodiment comprises a collection unit 132 and a recording unit 133. The collection unit 132 collects information on a plurality of second documents according to a schedule, by referring to a third document that describes a first storage location information indicating the storage location of each of the plurality of second documents corresponding to each of the plurality of system development projects, which are second documents that describe information on a first document that is a deliverable in each of the plurality of system development projects. The recording unit 133 records the information on the plurality of second documents collected by the collection unit 132 in a development deliverable database that records information on deliverables in each of the plurality of system development projects.

[0088] As a result, the information processing device 100 can automatically collect information on multiple second documents, each containing information on a first document, which is a deliverable in each of multiple system development projects. Furthermore, because the information processing device 100 can automatically collect information on multiple second documents, it can contribute to achieving Sustainable Development Goal (SDG) 9, "Build resilient infrastructure, promote inclusive and sustainable industrialization and foster innovation."

[0089] Furthermore, the second document contains, as information related to the first document, second storage location information indicating the storage location of each of the multiple first documents, which are deliverables corresponding to each of the multiple development processes of the system development project, and first progress information indicating the progress status of each of the multiple first documents.

[0090] As a result, the information processing device 100 can automatically collect second storage location information indicating the storage location of each of the multiple first documents, which are deliverables corresponding to each of the multiple development processes in each of the multiple system development projects, and first progress information indicating the progress status of each of the multiple first documents.

[0091] Furthermore, the third document includes items corresponding to the progress information of the second document, which shows the progress status of each of the multiple system development projects, and items corresponding to the planned release dates of each of the multiple system development projects.

[0092] This allows the information processing device 100 to manage the progress status of each of the multiple system development projects, as well as the planned release dates for each of the multiple system development projects.

[0093] The information processing device 100 also includes a generation unit 134. The generation unit 134 generates a real-time visualization image, which is an image that visualizes information about each of a plurality of second documents, based on the information recorded in the development deliverables database.

[0094] This enables the information processing device 100 to allow development personnel to easily and visually grasp information related to each of the multiple second documents.

[0095] The information processing device 100 also includes a determination unit 135. The determination unit 135 determines whether each of the multiple development processes in each of the multiple system development projects is progressing as planned, based on the planned completion date and the actual completion date of each of the multiple development processes. If the determination unit 135 determines that a predetermined development process is not progressing as planned, the generation unit 134 generates notification information indicating that the predetermined development process is not progressing as planned.

[0096] This allows the information processing device 100 to easily understand whether each of the development processes in each of the multiple system development projects is progressing according to schedule.

[0097] Furthermore, the determination unit 135 determines, for each of the multiple system development projects, whether or not information corresponding to predetermined mandatory compliance items is included among the items contained in the third document.

[0098] This allows the information processing device 100 to easily determine, for example, whether development personnel have included mandatory compliance items in accordance with the organization's rules.

[0099] Furthermore, the third document includes additional items specified by the user.

[0100] This allows the information processing device 100 to improve the usability of the third document.

[0101] [6. Hardware Configuration] Furthermore, the information processing device 100 according to the above-described embodiment is realized by a computer 1000 having a configuration such as that shown in Figure 15. The following explanation will use the information processing device 100 as an example. Figure 15 is a diagram showing an example of the hardware configuration. The computer 1000 is connected to an output device 1010 and an input device 1020, and has a configuration in which an arithmetic unit 1030, a primary storage device 1040, a secondary storage device 1050, an output interface 1060, an input interface 1070, and a network interface 1080 are connected by a bus 1090.

[0102] The arithmetic unit 1030 operates based on programs stored in the primary storage device 1040 and the secondary storage device 1050, as well as programs read from the input device 1020, and executes various processes. The arithmetic unit 1030 can be implemented using, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), an ASIC (Application Specific Integrated Circuit), or an FPGA (Field Programmable Gate Array).

[0103] The primary storage device 1040 is a memory device, such as RAM (Random Access Memory), that temporarily stores data used by the arithmetic unit 1030 for various calculations. The secondary storage device 1050 is a storage device where data used by the arithmetic unit 1030 for various calculations and various databases are registered, and can be implemented using ROM (Read Only Memory), HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, etc. The secondary storage device 1050 may be internal storage or external storage. The secondary storage device 1050 may also be a removable storage medium such as USB (Universal Serial Bus) memory or SD (Secure Digital) memory card. The secondary storage device 1050 may also be cloud storage (online storage), NAS (Network Attached Storage), file server, etc.

[0104] The output I / F 1060 is an interface for transmitting information to be output to output devices 1010, such as displays, projectors, and printers, and is implemented using connectors of standards such as USB (Universal Serial Bus), DVI (Digital Visual Interface), and HDMI (High Definition Multimedia Interface). The input I / F 1070 is an interface for receiving information from various input devices 1020, such as mice, keyboards, keypads, buttons, and scanners, and is implemented using, for example, USB.

[0105] Furthermore, the output interface 1060 and input interface 1070 may be wirelessly connected to the output device 1010 and input device 1020, respectively. In other words, the output device 1010 and input device 1020 may be wireless devices.

[0106] Furthermore, the output device 1010 and the input device 1020 may be integrated as a touch panel. In this case, the output I / F 1060 and the input I / F 1070 may also be integrated as an input / output I / F.

[0107] The input device 1020 may also be a device that reads information from, for example, an optical recording medium such as a CD (Compact Disc), DVD (Digital Versatile Disc), or PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory.

[0108] The network interface 1080 receives data from other devices via network N and sends it to the computing unit 1030, and also transmits data generated by the computing unit 1030 to other devices via network N.

[0109] The arithmetic unit 1030 controls the output device 1010 and the input device 1020 via the output interface 1060 and the input interface 1070. For example, the arithmetic unit 1030 loads a program from the input device 1020 or the secondary storage device 1050 onto the primary storage device 1040 and executes the loaded program.

[0110] For example, when computer 1000 functions as an information processing device 100, the arithmetic unit 1030 of computer 1000 realizes the functions of the control unit 130 by executing a program loaded onto the primary storage device 1040. Alternatively, the arithmetic unit 1030 of computer 1000 may load a program obtained from another device via the network interface 1080 onto the primary storage device 1040 and execute the loaded program. Furthermore, the arithmetic unit 1030 of computer 1000 may cooperate with other devices via the network interface 1080 and call and use program functions, data, etc., from other programs on other devices.

[0111] [7. Other] Although embodiments of the present invention have been described above, the present invention is not limited by the content of these embodiments. Furthermore, the aforementioned components include those that can be easily conceived by those skilled in the art, those that are substantially the same, and those that fall within the so-called equivalent range. Moreover, the aforementioned components can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the gist of the embodiments described above.

[0112] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, specific names, and information including various data and parameters shown in the above document and drawings can be arbitrarily changed unless otherwise specified. For example, the various information shown in each figure is not limited to the information shown.

[0113] Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0114] For example, the information processing device 100 described above may be implemented using multiple server computers, and depending on the function, it may be implemented by calling external platforms, etc., via APIs (Application Programming Interfaces) or network computing, allowing for flexible configuration changes.

[0115] Furthermore, the embodiments and modifications described above can be combined as appropriate, provided that the processing content is not inconsistent. [Explanation of Symbols]

[0116] 100 Information Processing Devices 110 Communications Department 120 Storage section 121 Development Deliverable Database 122 Project Management Ledger Database 123 Approval Record Database 130 Control Unit 131 Reception Department 132 Collection Department 133 Records Section 134 Generation part 135 Judgment section

Claims

1. A collection procedure for collecting information about a plurality of second documents according to a schedule, by referring to a third document that describes a first storage location information indicating the storage location of each of the plurality of second documents corresponding to each of the plurality of system development projects, the plurality of second documents containing information about a first document which is a deliverable in each of the plurality of system development projects, and the plurality of second documents containing information about a plurality of second documents which are deliverables in each of the plurality of system development projects, A recording procedure for recording information about the plurality of second documents collected by the collection procedure in a development deliverable database that records information about deliverables in each of the plurality of system development projects, An information processing program that causes a computer to execute something.

2. The second document describes, as information relating to the first document, second storage location information indicating the storage location of each of the multiple first documents which are deliverables corresponding to each of the multiple development processes of the system development project, and first progress information indicating the progress status of each of the multiple first documents. The information processing program according to claim 1.

3. The third document includes items corresponding to the second progress information showing the progress status of each of the multiple system development projects, and items corresponding to the planned release date of each of the multiple system development projects. The information processing program according to claim 1.

4. A generation procedure for generating a real-time visualization image, which is an image that visualizes information about each of the plurality of second documents, based on the information recorded in the aforementioned development deliverable database. The information processing program according to claim 1, which further causes a computer to execute.

5. A determination procedure for determining whether each of the multiple development processes in each of the multiple system development projects is progressing as planned, based on the planned completion date and actual completion date of each of the multiple development processes in each of the multiple system development projects, If the determination procedure determines that a predetermined development process is not proceeding as planned, a generation procedure is provided to generate notification information indicating that the predetermined development process is not proceeding as planned. The information processing program according to claim 1, which further causes a computer to execute.

6. A determination procedure for determining whether, for each of the aforementioned multiple system development projects, information corresponding to predetermined mandatory compliance items is included among the items contained in the third document, The information processing program according to claim 3, which further causes a computer to execute.

7. The third document further includes items specified by the user, The information processing program according to claim 3.

8. A collection unit collects information about a plurality of second documents, each containing information about a first document which is a deliverable in each of a plurality of system development projects, by referring to a third document which contains first storage location information indicating the storage location of each of the plurality of second documents corresponding to each of the plurality of system development projects, according to a schedule. A recording unit records information about the plurality of second documents collected by the collection unit into a development deliverable database that records information about deliverables in each of the plurality of system development projects. An information processing device equipped with the following features.

9. An information processing method implemented by a program executed by an information processing device, A collection process for collecting information about a plurality of second documents according to a schedule, by referring to a third document that describes a first storage location information indicating the storage location of each of the plurality of second documents corresponding to each of the plurality of system development projects, the plurality of second documents containing information about a first document which is a deliverable in each of the plurality of system development projects, and the plurality of second documents containing information about a plurality of second documents which are deliverables in each of the plurality of system development projects, A recording step includes recording information about the plurality of second documents collected by the collection step in a development deliverable database that records information about deliverables in each of the plurality of system development projects, Information processing methods including

Images