Software build system, software development assisting system, and software development assisting program

Abstract

To keep the time and cost for building software low.SOLUTION: A software build system comprises: a delivery date acquisition unit 35 that acquires a delivery date defined for software; an association unit 41 that associates the software with a virtual server provided from a service that supplies virtual servers; and a performance determination unit 37 that determines performance of the virtual server on the basis of information on the software.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a software build system, a software development support method, and a software development support program, and more particularly to a software build system that builds software using a virtual server, a software development support method that supports building software using a virtual server, and a software development support program that causes a computer to execute the software development support method. [Background technology]

[0002] When developing software, the source files and editing history of the software are stored in a repository to manage the versions, which makes the software development more efficient. A technology is known that adjusts the order in which multiple pieces of software are built by using the information stored in the repository. For example, Japanese Patent Application Laid-Open No. 2017-215762 describes a software build system that requests a group of compile servers to build software based on source code committed by a designer, build priorities registered in a development theme management system, and countermeasure priorities registered in a fault management system.

[0003] However, in the software build system described in JP 2017-215762 A, high-priority software is built before low-priority software. This causes a problem of delaying the build of low-priority software. For this reason, it is desirable to improve the performance of the build server and shorten the time spent building software.

[0004] In order to shorten the time spent building software, it is necessary to use a high-performance build server, but build servers are expensive. In recent years, a service that generates virtual servers on the cloud has become known. Using this service, it is possible to generate a virtual server for each software build, but in order to use the virtual server as a build server, it is necessary to set up a build environment on the virtual server, which can be a cumbersome task. To address this issue, there is a service that provides a separate virtual server that is a copy of a virtual server with a build environment set up. By using this service, the task of setting up a build environment is no longer necessary.

[0005] On the other hand, the cost of receiving the service varies depending on the performance of the virtual server. The higher the performance of the virtual server, the higher the cost. The cost of the virtual server copied from the virtual server is determined by the performance of the virtual server in which the build environment was set up first. However, since the performance required of the virtual server varies depending on various factors such as the software development stage and delivery date, it is difficult to determine the performance of the virtual server to be generated initially. If one tries to keep costs down, the performance of the virtual server will be lowered, which may result in longer time spent on building and inefficient development. Conversely, if the performance of the virtual server is increased, efficient development will be possible, but costs will increase. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2017-215762 A Summary of the Invention [Problem to be solved by the invention]

[0007] The present invention has been made to solve the above-mentioned problems, and one of the objects of the present invention is to provide a software build system that reduces the time and costs required to build software.

[0008] Another object of the present invention is to provide a software development support method which reduces the time and cost required to build software.

[0009] It is still another object of the present invention to provide a software development support program which reduces the time and costs required to build software. [Means for solving the problem]

[0010] According to one aspect of the present invention, a software build system includes a delivery date acquisition means for acquiring a delivery date set for the software, an association means for associating the software with a virtual server provided by a service that supplies the virtual server, and a performance determination means for determining the performance of the virtual server based on information about the software.

[0011] According to another aspect of the present invention, a software development support method includes a delivery date acquisition step of acquiring a delivery date set for the software, an association step of associating the software with a virtual server provided by a service that supplies the virtual server, and a performance determination step of determining the performance of the virtual server based on information about the software.

[0012] According to yet another aspect of the present invention, a software development support program causes a computer to execute a delivery date acquisition step of acquiring a delivery date set for the software, an association step of associating the software with a virtual server provided by a service that supplies the virtual servers, and a performance determination step of determining the performance of the virtual server based on information about the software. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 is a diagram showing an example of an overall outline of a software build system according to an embodiment of the present invention. [Diagram 2] 2 is a block diagram showing an example of a hardware configuration of a build environment management server. FIG. [Diagram 3] FIG. 1 is a first sequence diagram showing a procedure for building software in the software build system. [Figure 4] FIG. 2 is a second sequence diagram showing the procedure of building software in the software build system. [Diagram 5] 2 is a block diagram showing an example of functions of a CPU included in the build environment management server. FIG. [Figure 6] FIG. 13 illustrates an example of an administrator build instruction screen. [Figure 7] FIG. 13 is a diagram showing an example of a playback instruction screen. [Figure 8] FIG. 13 is a diagram showing an example of a developer build instruction screen. [Figure 9] FIG. 13 illustrates an example of a version management table. [Figure 10] FIG. 13 illustrates an example of a build history table. [Figure 11] FIG. 13 illustrates an example of a performance level table. [Figure 12] 1 is a graph showing an example of a relationship between a performance level and a delivery date. [Figure 13] 13 is a flowchart showing an example of the flow of a virtual server generation process. [Figure 14] 13 is a flowchart showing an example of the flow of a virtual server reproduction process. [Figure 15] 13 is a flowchart showing an example of the flow of a performance determination process. [Figure 16] 13 is a flowchart showing an example of the flow of an increase rate determination process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] A software build system according to an embodiment of the present invention will be described below with reference to the drawings. In the following description, the same components are given the same reference numerals. Their names and functions are also the same. Therefore, detailed description thereof will not be repeated.

[0015] 1 is a diagram showing an example of an overall overview of a software build system according to the present embodiment. The software build system 1 includes a build environment management server 100, a service providing server 200, a version management server 201, a delivery date management server 202, an administrator PC 300, and developer PCs 300A to 300C.

[0016] The build environment management server 100, the service providing server 200, the version management server 201, the delivery date management server 202, the manager PC 300, and the developer PCs 300A to 300C are connected to a network 5 and can communicate with each other. The network 5 is the Internet. Note that the network 5 is not limited to the Internet, and may be a wide area network (WAN), a public switched telephone network (PSTN), a local area network, or the like. The build environment management server 100, the service providing server 200, the version management server 201, the delivery date management server 202, the manager PC 300, and the developer PCs 300A to 300C may be connected to the network 5 by wire or wireless.

[0017] The build environment management server 100, the version management server 201, and the delivery date management server 202 are general computers, and their configurations are well known, so the description will not be repeated here.

[0018] The service providing server 200 is a computer managed by a business that provides a service of supplying virtual servers. A user can use the services provided by the service providing server 200 by registering with the business.

[0019] The version management server 201 executes a version management program that manages software versions, and realizes a version management system. The version management server 201 has a function for managing the change history of source code. The version management server 201 has a repository, and stores source code, object programs, change history, and related documents for each version of software.

[0020] The delivery date management server 202 manages the delivery date of the software. The delivery date management server 202 determines the delivery date for each piece of software. The delivery date of the software is a date agreed upon between the sales representative of the software and the customer, and is registered by the sales representative in the delivery date management server 202 in association with the software. A first type of delivery date and a second type of delivery date are determined for this delivery date. The first type of delivery date is a delivery date that cannot be extended. The second type of delivery date is a delivery date that can be extended. The first type of delivery date and the second type of delivery date are, for example, delivery dates agreed upon between the sales representative and the customer, and are registered by the sales representative in the delivery date management server 202 in association with the software. Either the first type of delivery date or the second type of delivery date, or both, are set for one piece of software.

[0021] Administrator PC 300 and developer PCs 300A-300C are each a typical personal computer. Here, an example is shown in which there are three developer PCs 300A-300C, but there is no restriction on the number. There may be one or more developer PCs 300A.

[0022] In this embodiment, an example will be described in which an administrator and three developers A to C belong to a team developing software. The administrator operates administrator PC 300, and developers A to C operate developer PCs 300A to 300C, respectively.

[0023] Fig. 2 is a block diagram showing an example of a hardware configuration of a build environment management server. Referring to Fig. 2, the build environment management server 100 is a computer that performs calculation processing, and includes a central processing unit (CPU) 101 for controlling the entire build environment management server 100, a ROM (Read Only Memory) 102 for storing programs to be executed by the CPU 101, a RAM (Random Access Memory) 103 used as a working area for the CPU 101, an HDD 104 for storing data in a non-volatile manner, a communication unit 105 for connecting the CPU 101 to a network, a display unit 106 for displaying information, an operation unit 107 for accepting input of user operations, and an external storage device 108.

[0024] The communication unit 105 is an interface for connecting the PC 200A to the network 5. Therefore, the CPU 101 can communicate with the service providing server 200, the version management server 201, the delivery date management server 202, the manager PC 300, and the developer PCs 300A to 300C, which are connected to the network 5, via the communication unit 105.

[0025] CPU 101 downloads a program from a computer connected to network 5 and stores the program in HDD 104. When a computer connected to network 5 writes a program to HDD 104, the program is stored in HDD 104. CPU 101 loads the program stored in HDD 104 into RAM 103 and executes it. Note that instead of HDD 104, a semiconductor memory such as an EPROM (Erasable Programmable ROM) capable of storing data in a non-volatile manner may be used.

[0026] A CD-ROM (Compact Disk Read Only Memory) 109 is attached to the external storage device 108. In this embodiment, an example will be described in which the CPU 101 executes a program stored in the ROM 102 or the HDD 104. The CPU 101 may control the external storage device 108 to read a program to be executed by the CPU 101 from the CD-ROM 109, and store the read program in the RAM 103 for execution.

[0027] The recording medium for storing the programs executed by CPU 101 is not limited to CD-ROM 109, but may be a flexible disk, a cassette tape, an optical disk (MO (Magnetic Optical Disc) / MD (Mini Disc) / DVD (Digital Versatile Disc)), an IC card, an optical card, a mask ROM, an EPROM (Erasable Programmable ROM), or other semiconductor memory. The programs referred to here include not only programs that can be directly executed by CPU 101, but also source programs, compressed programs, encrypted programs, and the like.

[0028] Fig. 3 is a first sequence diagram showing the procedure for building software in the software build system. Fig. 3 shows the processes executed and the information transmitted and received by the administrator PC 300, the build environment management server 100, the service providing server 200, and the version management server 201. Fig. 3 shows the passage of time from top to bottom. Also, an example will be described in which a source program generated by any of the developer PCs 300A to 300C is stored in the repository of the version management server 201.

[0029] Referring to FIG. 3, an administrator operates administrator PC 300 to instruct build environment management server 100 to generate a virtual server. The generation instruction includes performance information that defines the performance of the virtual server. The performance information includes, but is not limited to, at least CPU performance, memory performance, storage performance, and network performance. CPU performance includes the number of CPU cores and / or processing speed. Memory performance includes the main memory size and transfer speed. Storage performance includes the non-volatile memory size and hardware type. Network performance indicates communication capabilities and includes the speed at which data is transmitted and received.

[0030] In response to receiving a generation instruction from the administrator, the build environment managing server 100 requests the service providing server 200 to generate a virtual server. This generation request includes performance information specified in the generation instruction. In response to receiving the generation request, the service providing server 200 generates a virtual server with the performance specified by the performance information included in the generation request. As a result, a virtual server is formed in the service providing server 200.

[0031] An administrator operates the administrator PC 300 to instruct the build environment management server 100 to set up a build environment. The instruction to set up the build environment includes tool information that identifies the tools used by the virtual server as the build environment. The tool information is, but is not limited to, information that identifies a toolchain. The toolchain includes a compiler, a linker, and a debugger.

[0032] The build environment management server 100 sets up a build environment in a virtual server formed in the service providing server 200 in response to a build environment setting instruction from an administrator. This setting instruction includes tool information. The virtual server formed in the service providing server 200 sets a toolchain specified by the tool information in accordance with the setting instruction received from the build environment management server 100.

[0033] The administrator operates the administrator PC 300 to instruct the build environment management server 100 to build software. The build instruction here is called a developer build instruction. The developer build instruction includes build conditions. The build conditions include information that identifies the software to be built, the version of that software, and information that identifies the repository in which the source files that make up that software are stored. A source file is data in which source code is written.

[0034] In response to the administrator's build instruction, the build environment management server 100 transmits a command to instruct the virtual server formed in the service providing server 200 to execute a full build. This command includes build conditions. In response to receiving the command, the virtual server formed in the service providing server 200 executes a full build according to the build conditions included in the command. Specifically, the virtual server obtains a source file defined in the build conditions from a repository defined in the build conditions. In this case, since the source file is stored in a repository owned by the version management server 201, the virtual server formed in the service providing server 200 obtains the source file from the version management server 201. Then, the virtual server formed in the service providing server 200 performs a full build using the source file.

[0035] When a full build using source files is completed, the virtual server formed in the service providing server 200 transmits build history data to the version management server 201. The build history data includes object files, build time, number of bugs, and, if an error occurs, error information related to the error.

[0036] When the version management server 201 receives build performance data from a virtual server formed in the service providing server 200, the version management server 201 stores the build performance data in a repository. This updates the build history related to the software. The version management server 201 also saves object files in the repository.

[0037] On the other hand, the service providing server 200 saves the virtual machine image and powers off the virtual server after the virtual server executes a full build and transmits build result information to the version management server 201. The virtual machine image is an image of a virtual server in which a build environment is set, and is a startup template that brings together information required to start up a virtual server in which a build environment is set.

[0038] The build environment management server 100 acquires a machine image name for identifying the virtual machine image from the service providing server 200, and stores the acquired machine image name in the HDD 104. The build environment management server 100 then associates the software that is the target of the build with the virtual machine image. Association data that associates the software name, version, and machine image name for identifying the software is stored in the HDD 104.

[0039] The service providing server 200 counts the usage time from when the virtual server is generated until the power is turned off, calculates a billing amount from the usage time and a unit price per unit time determined according to the performance of the virtual server, and charges the build environment management server 100. The build environment management server 100 accesses the service providing server 200 using an ID issued by the service providing server 200. The service providing server 200 charges for the ID that has been accessed. This ID may be managed by the build environment management server 100, or may be managed by the administrator operating the administrator PC 300.

[0040] Fig. 4 is a second sequence diagram showing the procedure for building software in the software build system. Fig. 4 shows the processes executed and the information transmitted and received by developer PC 300A, build environment management server 100, service providing server 200, version management server 201, and delivery date management server 202. Fig. 4 shows the passage of time from top to bottom. Also, an example will be described in which source files constituting software generated by one of developer PCs 300A to 300C, developer PC 300A in this case, are stored in the repository of version management server 201.

[0041] Referring to FIG. 4, developer A operates developer PC 300A to instruct build environment management server 100 to regenerate a virtual server. The regeneration instruction includes a machine image name. As shown in FIG. 3, build environment management server 100 associates a software name, a version of the software, and a machine image name of a virtual machine image of a virtual server generated to build the software of that version. Therefore, developer PC 300A obtains a table that associates a source file name, a version, and a machine image name from build environment management server 100, and displays the table. This allows developer A to specify a machine image name corresponding to a virtual server for building a version of software developed by developer A. Developer A can also specify a version of software developed by developer A from the version history of the software managed by version management server 201. Developer A inputs a machine image name determined by referring to the table into developer PC 300A, and developer PC 300A transmits a regeneration instruction of the virtual server to build environment management server 100.

[0042] In response to a playback instruction from developer A, the build environment management server 100 requests the service providing server 200 to play back a virtual server. This virtual server playback request includes a machine image name included in the playback instruction. In response to receiving the virtual server playback request, the service providing server 200 generates a virtual server in which a build environment is set, using a virtual machine image specified by the machine image name. As described with reference to FIG. 3, this virtual server has performance determined by an administrator, and a build environment set by the administrator is set. The build environment management server 100 acquires a virtual server name for identifying the virtual server played back by the service providing server 200 from the service providing server 200, and transmits the name to the developer PC 300A. This enables developer A to identify the virtual server created in the service providing server 200.

[0043] The build environment management server 100 obtains the delivery date of the software. The service providing server 200 obtains the delivery date of the software from the delivery date management server 202. Then, the build environment management server 100 obtains the build history. The build environment management server 100 obtains the build history related to the software from the version management server 201.

[0044] The build environment management server 100 determines the performance of the virtual server. The build environment management server 100 determines the performance of the virtual server based on the delivery date and build history of the software. Then, the build environment management server 100 transmits to the build environment management server 100 an instruction to change the performance of the virtual server created in the build environment management server 100. This performance change instruction is transmitted using a command line interface (CLI). The service providing server 200 that receives the performance change instruction changes the performance of the previously created virtual server to the performance specified in the performance change instruction.

[0045] Developer A operates developer PC 300A to instruct the build environment management server 100 to build software. The build instruction here is called a developer build instruction. The developer build instruction includes the virtual server name.

[0046] In response to receiving a developer build instruction from the developer PC 300A, the build environment management server 100 identifies the software to be built. In this embodiment, since the virtual server name includes the software name and version, the source file to be built is identified from the software name and version associated with the virtual server name. Note that the developer may specify the software.

[0047] The build environment management server 100 transmits a command to the virtual server formed in the service providing server 200 to instruct the execution of a build of the software. The command includes build conditions. In response to receiving the command, the virtual server formed in the service providing server 200 executes a build of the software according to the build conditions included in the command. Specifically, the virtual server acquires source files constituting the software defined by the build conditions from a repository defined by the build conditions. Here, since the source files are stored in the repository owned by the version management server 201, the virtual server formed in the service providing server 200 acquires the source files from the version management server 201. Then, the virtual server formed in the service providing server 200 executes a build using the source files. The build conditions include whether a full build or a differential build is performed. If a full build is defined in the build conditions, the virtual server executes a full build using the source files, and if a differential build is defined in the build conditions, the virtual server executes a differential build using the source files.

[0048] When the virtual server formed in the service providing server 200 completes the build of the software, it transmits build history data to the version management server 201. The build history data includes the object file, the build time, the number of bugs, and, if an error occurs, error information related to the error.

[0049] When the version management server 201 receives build performance data from a virtual server formed in the service providing server 200, the version management server 201 stores the build performance data in a repository. This updates the build history related to the source code. The version management server 201 also saves object files in the repository.

[0050] On the other hand, after the virtual server executes a build of the software and transmits the build result data to the version management server 201, the service providing server 200 turns off the power of the virtual server.

[0051] The service providing server 200 counts the usage time from when the virtual server is generated to when the power is turned off, calculates the billing amount based on the usage time and the unit price per unit time determined according to the performance of the virtual server, and charges the build environment management server 100.

[0052] Fig. 5 is a block diagram showing an example of functions of a CPU included in the build environment management server. The functions shown in Fig. 5 are realized by the CPU 101 included in the build environment management server 100 as the CPU 101 executes a software development support program. A continuous integration tool is also installed in the build environment management server 100. The continuous integration tool is a tool for automatically executing a build of software. An example of a continuous integration tool is Jenkins. For this reason, the build environment management server 100 cooperates with a virtual server formed as a build server in the service providing server 200 to execute a process of building a source file.

[0053] Referring to FIG. 5, the CPU 101 provided in the build environment management server 100 includes an administrator instruction receiving unit 11, a build environment generation unit 13, an administrator build instruction unit 15, a developer instruction receiving unit 21, a virtual server reproduction unit 23, a developer build instruction unit 25, and an association unit 41.

[0054] The administrator instruction receiving unit 11 controls the communication unit 105 to communicate with the administrator PC 300. The administrator instruction receiving unit 11 receives from the administrator PC 300 an instruction that is input to the administrator PC 300 by the administrator.

[0055] The administrator instruction receiving unit 11 transmits a performance input screen for inputting the performance of the virtual server to the administrator PC 300, and receives performance information indicating the performance input by the administrator according to the performance input screen from the administrator PC 300. The administrator instruction receiving unit 11 outputs the performance information to the build environment generating unit 13.

[0056] The administrator instruction receiving unit 11 transmits an environment setting screen for specifying a build environment to be set in the virtual server, and receives build environment information input by the administrator according to the environment setting screen from the administrator PC 300. The build environment information is information that is set in the virtual server in order to execute the process of building software. The build environment information includes, for example, tool information and information specifying the version management server 201.

[0057] The build environment generation unit 13 communicates with the service providing server 200 and uses the services provided by the service providing server 200. The build environment generation unit 13 includes a virtual server generation request unit 17 and a build environment setting unit 19. In response to performance information input from the administrator instruction receiving unit 11, the virtual server generation request unit 17 requests the service providing server 200 to generate a virtual server. For example, the build environment generation unit 13 uses a CLI to transmit a command to generate a virtual server. The service providing server 200 that receives the command generates a virtual server having performance specified by the performance information included in the command, and makes it available to the build environment management server 100.

[0058] In response to the build environment information being input from the administrator instruction receiving unit 11, the build environment generating unit 13 sets a build environment in a virtual server formed in the service providing server 200. For example, the build environment generating unit 13 operates the virtual server formed in the service providing server 200, and sets a build environment specified by the build environment information in the virtual server.

[0059] The administrator instruction receiving unit 11 transmits an administrator build instruction screen to the administrator PC 300 and receives an administrator build instruction from the administrator PC 300 .

[0060] FIG. 6 is a diagram showing an example of an administrator build instruction screen. Referring to FIG. 6, the administrator build instruction screen includes an area for inputting the file name of a source file, an area for inputting the version of the source file, an area for inputting repository information, and an execution instruction button on which a character string of "full build" is displayed. When the execution instruction button is instructed with the source file name, the version of the source file, and the repository information respectively input, the administrator PC 300 transmits an administrator build instruction to the build environment management server 100. The administrator build instruction includes the source file name, the version of the source file, and repository information that identifies the repository in which the source file is stored. Here, a case where the software is composed of one source file is shown as an example. Therefore, the source file name in FIG. 6 is information that identifies the software.

[0061] Returning to FIG. 5, in response to receiving an administrator build instruction from the administrator PC 300, the administrator instruction receiving unit 11 outputs the administrator build instruction to the administrator build instruction unit 15. In response to receiving the administrator build instruction, the administrator build instruction unit 15 instructs the virtual server formed in the service providing server 200 to build. Specifically, the administrator build instruction unit 15 obtains a source file identified by the source file name and version included in the administrator build instruction from a repository identified by the repository information, and inputs an instruction to the virtual server to perform a full build. As a result, the source file is built by the virtual server formed in the service providing server 200, and the build performance data is stored in the repository. When the build by the virtual server is completed, the administrator build instruction unit 15 outputs a completion instruction to the associating unit 41. The completion instruction includes the source file name.

[0062] In response to the input of the completion instruction, the associating unit 41 instructs the service providing server 200 to save the virtual machine image to the virtual server and to turn off the power of the virtual server. After saving the virtual machine image of the virtual server, the service providing server 200 replies with a machine image name for identifying the virtual machine image. The associating unit 41 associates the virtual machine image with the software. Specifically, the associating unit 41 outputs association data that associates the machine image name with the file name of the source file and the version of the source file to the virtual server reproduction unit 23.

[0063] The developer instruction receiving unit 21 controls the communication unit 105 to communicate with the developer PC 300A. The developer instruction receiving unit 21 receives instructions from the administrator PC 300 that the developer A inputs to the developer PC 300A. The developer instruction receiving unit 21 transmits a playback instruction screen to the developer PC 300A, and receives a playback instruction from the developer PC 300A.

[0064] Fig. 7 is a diagram showing an example of a playback instruction screen. Referring to Fig. 7, the playback instruction screen includes an area for inputting a machine image name, an area for inputting a case number, and an execution instruction button on which a character string for "generation" is displayed. When the execution instruction button is pressed with the machine image name and case number input, the administrator PC 300 transmits a playback instruction to the build environment management server 100. The playback instruction includes the machine image name and the case number.

[0065] Returning to FIG. 5, in response to receiving a playback instruction from the administrator PC 300, the manager instruction receiving unit 11 outputs the received playback instruction to the virtual server playback unit .

[0066] In response to an input of a playback instruction, the virtual server playback unit 23 generates a virtual server in the service providing server 200. The virtual server playback unit 23 includes a virtual server playback request unit 31, a build history acquisition unit 33, a delivery date acquisition unit 35, a performance determination unit 37, and a performance change request unit 39.

[0067] In response to the input of the playback instruction, the virtual server playback request unit 31 requests the service providing server 200 to play back the virtual server. Specifically, the virtual server playback request unit 31 inputs a command to play back the virtual server, including the machine image name and the case number included in the playback instruction, to the virtual server. As a result, the service providing server 200 generates a virtual server based on the virtual machine image specified by the machine image name. The service providing server 200 replies with a virtual server name for identifying the generated virtual server. At this time, the service providing server 200 adds the case number to the virtual server name. There are cases where the same virtual server is generated for the number of cases. The virtual server playback request unit 31 transmits the virtual server name to the developer PC 300A. Therefore, the developer A can recognize the name of the virtual server generated by the service providing server 200.

[0068] In response to input of a playback instruction, the build history acquisition unit 33 acquires build history information from the version management server 201. The build history acquisition unit 33 receives association data from the associating unit 41. The association data associates a machine image name, a source file name, and a source file version. The build history acquisition unit 33 identifies the source file name and version associated with the machine image name included in the playback instruction by the association data. The build history acquisition unit 33 acquires build history data corresponding to the source file name and version from the version management server 201. The build history acquisition unit 33 outputs the build history data to the performance determination unit 37.

[0069] The delivery date acquisition unit 35 identifies the source file name and version associated with the machine image name included in the playback instruction by the association data. The delivery date acquisition unit 35 acquires the delivery date corresponding to the source file name and version from the delivery date management server 202. The delivery date acquisition unit 35 outputs the delivery date to the performance determination unit 37.

[0070] The performance determination unit 37 determines the performance of the virtual server. The performance determination unit 37 determines the performance level of the virtual server based on the delivery date and build record data. The performance level and the process of determining the performance level by the performance determination unit 37 will be described in detail later. The performance determination unit 37 outputs the determined performance level to the performance change request unit 39.

[0071] The performance change request unit 39 transmits to the service providing server 200 a command instructing the service providing server 200 to change the performance of the virtual server to the performance determined by the performance level input from the performance determining unit 37. In response to receiving the command, the service providing server 200 changes the performance of the virtual server.

[0072] The developer instruction receiving unit 21 transmits a developer build instruction screen to the developer PC 300A, and receives a developer build instruction from the developer PC 300A.

[0073] Fig. 8 is a diagram showing an example of a developer build instruction screen. Referring to Fig. 8, the developer build instruction screen includes an area for inputting a virtual server name, a differential build execution instruction button on which a character string for a differential build is displayed, and a full build execution instruction button on which a character string for a full build is displayed.

[0074] When either the differential build execution instruction button or the full build execution instruction button is pressed with the virtual server name entered, developer PC 300A transmits a developer build instruction to build environment management server 100. The administrator build instruction includes the virtual server name and the build type. The build type indicates either a differential build or a full build.

[0075] Returning to FIG. 5, in response to receiving a developer build instruction from the developer PC 300A, the developer instruction receiving unit 21 outputs the developer build instruction to the developer build instruction unit 25. In response to the input of the developer build instruction, the developer build instruction unit 25 instructs the virtual server formed in the service providing server 200 to perform either a differential build or a full build. The source file name and version corresponding to the virtual server are input from the virtual server replay unit 23 to the developer build instruction unit 25. The developer build instruction unit 25 acquires a source file specified by the source file name and version from a repository specified by the repository information, and inputs an instruction to build the source file to the virtual server. As a result, the source file is built by the virtual server formed in the service providing server 200, and the build performance data is stored in the repository. When the build by the virtual server is completed, the developer build instruction unit 25 instructs the service providing server 200 to turn off the power of the virtual server.

[0076] <Generate build history table> Build history acquisition unit 33 generates a version management table based on the version management information acquired from version management server 201 and delivery date information acquired from delivery date management server 202. Furthermore, build history acquisition unit 33 generates a build history table based on the version management table and build performance data acquired from version management server 201.

[0077] Fig. 9 is a diagram showing an example of a version management table. Referring to Fig. 9, the version management table includes a plurality of version management records. A version management record is generated for each case number. The version management record includes a case number field, a software name field, a version field, a case content field, a development scale field, a person in charge field, a delivery date field, and a must-delivery date field.

[0078] The software name field is set with information for identifying the software to be developed. The version field is set with the version of the software identified by the software name set in the software name field. The software to be developed is identified by the combination of the software name and version. The case content field is set with the content of the software development by the developer for the software to be developed. For example, if a portion of the software is to be added, the case content indicates the part to be added, and if the software is to be modified, the part to be modified and the content of the modification.

[0079] The case number field is set with information that is attached to the set of software name, version, and case details. The development scale field is set with the development scale of the software identified by the case number. The development scale includes the size of the source file or the number of source files. Here, the development scale is defined as large, medium, or small. For example, the development scale is determined by classifying the planned number of lines of the program into three categories using a threshold value.

[0080] The person in charge field contains information identifying the developer in charge of the development work of the software identified in the case number field.

[0081] In the delivery date field, a second type of delivery date for the software identified by the case number is set. The second type of delivery date is set to an extendable date. In the mandatory delivery date field, a first type of delivery date for the software identified by the case number is set. The first type of delivery date set in the mandatory delivery date field is set to an irreextendable date. The second type of delivery date may or may not be set.

[0082] According to the version management table shown in Figure 9, the number of developers in charge of developing software named Product A and version Ver2 is two, and the number of developers in charge of developing software named Product B and version Ver1 is one.

[0083] Fig. 10 is a diagram showing an example of a build history table. Referring to Fig. 10, the build history table includes build history records corresponding to build performance data generated by the version control server 201 for execution of a build of software.

[0084] The build history record includes an item for the case number, an item for the machine image name, an item for the virtual server, and an item for the build record. The item for the case number is set with the information set in the item for the case number in the version management table shown in Fig. 9. Therefore, a build history record is generated for a build of the software of the version set in the item for the software name and the item for the version in Fig. 9.

[0085] The machine image name field is set with a machine image name for identifying the machine image of the virtual server for which a build environment created by the administrator is set. The virtual server field includes a name field and a performance level field. The name field is set with the name of the virtual server regenerated from the machine image by the service providing server 200. The performance level field is set with the performance level of the virtual server.

[0086] The build performance items include a bug density item and a build time history item. The bug density item is set to the level of density of bugs found as a result of a build executed by a virtual server. Here, there are three bug density levels: high, medium, and low. The bug density is determined by classifying the bug density into three levels using a threshold value.

[0087] The build time history item is set to the time from when the virtual server starts to when the build ends. The time set in the build time history item may be the time required for the previous build, or, if the build is repeated multiple times, the cumulative time may be set.

[0088] <Determining performance level> The performance determination unit 37 stores a performance level table in the HDD 104. The performance level table is a table that defines the relationship between the performance level of a virtual server and the performance and fee of the virtual server. Here, the relationship is defined such that the higher the performance level, the higher the performance of the virtual server and the higher the fee.

[0089] Fig. 11 is a diagram showing an example of a performance level table. Referring to Fig. 11, the performance level table includes performance level records corresponding to a plurality of performance levels. The performance level record includes an instance name field, a performance level field, a virtual server performance field, and a fee field.

[0090] The instance name item is set with the name of the virtual server determined by the service providing server 200. The performance level item is set with one of a number of predetermined performance levels. Here, an example is described in which 100 performance levels are determined from 1 to 100. In the figure, eight examples of performance levels are shown, namely, Lv1, 4, 8, 15, 25, 30, 75, and 100, and performance level records for the other performance levels are omitted. Lv100 indicates the highest performance level, and Lv1 indicates the lowest performance level.

[0091] The virtual server items include a CPU performance item, a memory performance item, a storage performance item, and a network performance item. In the CPU performance item, a value indicating the CPU performance of the virtual server is set. In this embodiment, the CPU performance is the number of CPU cores. Note that the CPU performance may be represented by the processing speed. In the memory performance item, the main memory size is set. In the storage performance item, the non-volatile memory size is set. Note that the storage performance may be represented by the type of non-volatile memory. In the network performance item, the communication speed is set.

[0092] The fee item is set with the fee requested by the business entity managing the service providing server 200 when the service providing server 200 supplies a virtual server having the performance value set in the virtual server performance item. The fee is a price per unit time.

[0093] The performance determination unit 37 determines the performance level based on the delivery date of the software to be built. The performance determination unit 37 determines a higher performance level as the period between the current date and the delivery date is shorter.

[0094] Furthermore, when build performance data exists for the software to be built, the performance determination unit 37 refers to the build history table stored in HDD 104 and determines the performance level based on the build performance data in addition to the delivery date. The build performance data includes build history time and bug density. The longer the build time, the higher the performance determination unit 37 determines the performance level. The higher the bug density, the higher the performance determination unit 37 determines the performance level. Furthermore, the more developers are in charge of developing the software to be built, the higher the performance determination unit 37 determines the performance level.

[0095] Fig. 12 is a graph showing an example of the relationship between performance level and delivery date. Referring to Fig. 12, the horizontal axis shows the time until the delivery date, and the vertical axis shows the performance level. Fig. 12 shows a straight line that shows the relationship between the delivery date and performance level when the development scale is small, there is one developer, and the bug density is low, and a straight line that shows the relationship between the delivery date and performance level when the development scale is large, there are three developers, and the bug density is high. For both straight lines, the shorter the time until the delivery date, the higher the performance level.

[0096] The line showing the performance level for different development scales, number of developers, and bug densities lies in the range between the two lines.

[0097] The slope of the graph indicates the rate of increase. The rate of increase indicates the difference in performance increase per unit time. The difference in performance is the difference between the performance level at the start of the unit time and the performance level at the end of the unit time. The rate of increase increases as the development scale, number of developers, and bug density increase. The rate of increase W may be determined using the following formula (1), which uses development scale X, number of developers Y, and bug density Z.

[0098] W = aX + bY + cZ … (1) Here, a, b, and c are predetermined constants.

[0099] If there is no build history for the software to be built, the performance determination unit 37 determines the performance level based on the time until delivery, using a predetermined value as the difference in performance increase per unit time.

[0100] Fig. 13 is a flowchart showing an example of the flow of a virtual server generation process. The virtual server generation process is a process executed by CPU 101 included in build environment management server 100 as CPU 101 executes a software development support program. With reference to Fig. 13, CPU 101 included in build environment management server 100 determines whether or not administrator login has been detected (step S01). The process remains in a standby state until administrator login is detected (NO in step S01), and if administrator login is detected (YES in step S01), the process proceeds to step S02.

[0101] In step S02, the performance information is accepted, and the process proceeds to step S03. CPU 101 transmits a performance input screen to administrator PC 300, and receives performance information indicating the performance that the administrator inputs to administrator PC 300 according to the performance input screen from administrator PC 300. The performance information includes the number of CPU cores, the size of the main memory, communication capabilities, and the size of the non-volatile memory.

[0102] In step S03, a request is made to the service providing server 200 to generate a virtual server, and the process proceeds to step S04. For example, the CPU 101 uses a CLI to transmit a command to generate a virtual server to the service providing server 200. The service providing server 200 that receives the command generates a virtual server with the performance included in the command.

[0103] In step S04, the build environment is accepted, and the process proceeds to step S05. CPU 101 transmits an environment setting screen to administrator PC 300, and receives build environment information from administrator PC 300 indicating the build environment that the administrator inputs to administrator PC 300 in accordance with the environment setting screen. The build environment information includes, for example, information specifying a compiler, a library, a linker, a debugger, and version control server 201.

[0104] In step S05, a build environment is set in the virtual server formed in the service providing server 200, and the process proceeds to step S06. The CPU 101, for example, operates the virtual server formed in the service providing server 200, and sets the build environment specified by the build environment information in the virtual server.

[0105] In step S06, it is determined whether or not a source file has been specified. The process waits until a source file has been specified (NO in step S06), and if a source file has been specified (YES in step S06), the process proceeds to step S07. CPU 101 transmits the administrator build instruction screen shown in FIG. 6 to administrator PC 300, and receives an administrator build instruction from administrator PC 300. The administrator build instruction includes the file name of the source file, the version of the source file, and repository information.

[0106] In step S07, a full build is instructed to the virtual server in which the build environment formed in service providing server 200 is set, and the process proceeds to step S08. CPU 101 acquires the source file identified by the source file name and version from the repository identified by the repository information, and inputs an instruction to build to the virtual server. As a result, the source file is built by the virtual server formed in service providing server 200, and build performance data is stored in the repository.

[0107] In step S08, a request is made to generate a virtual machine image, and the process proceeds to step S09. CPU 101 transmits a command to the service providing server 200 to save the virtual machine image of the virtual server. When the service providing server 200 has completed saving the virtual machine image, it replies with a machine image name for identifying the virtual machine image. In step S09, the virtual server is turned off, and the process proceeds to step S10. An instruction to do so is transmitted, and CPU 101 transmits a command to the service providing server 200 to turn off the power of the virtual server.

[0108] In step S10, the virtual server and the software are associated with each other, and the process ends. CPU 101 generates association data that associates the machine image name of the virtual machine image with the file name and the version of the source file, and stores the association data in HDD 104.

[0109] Fig. 14 is a flowchart showing an example of the flow of a virtual server replay process. The virtual server replay process is a process executed by CPU 101 included in build environment management server 100 as CPU 101 executes a software development support program. With reference to Fig. 14, CPU 101 included in build environment management server 100 judges whether or not a developer login has been detected. CPU 101 waits until it detects the login of any one of developers A to C (NO in step S11), and if it detects the login of any one of developers A to C (YES in step S11), the process proceeds to step S12. Below, an example will be described in which the login of developer A has been detected.

[0110] In step S12, CPU 101 causes developer PC 300A to display a playback instruction screen, and proceeds to step S 13. CPU 101 transmits the playback instruction screen shown in Fig. 7 to developer PC 300A, and causes developer PC 300A to display the playback instruction screen.

[0111] In step S13, it is determined whether a regeneration instruction has been accepted. The process waits until the regeneration instruction is accepted (NO in step S13), and when the regeneration instruction is accepted (YES in step S13), the process proceeds to step S14. The regeneration instruction includes the machine image name and the case number.

[0112] In step S14, the service providing server 200 is requested to regenerate the virtual server, and the process proceeds to step S15. The CPU 101 transmits a command to regenerate the virtual server to the service providing server 200. The regeneration command includes the machine image name and the case number included in the regeneration instruction accepted in step S12. As a result, the service providing server 200 generates a virtual server based on the virtual machine image specified by the machine image name.

[0113] In step S15, a source file to be built is identified, and the process proceeds to step S16. CPU 101 acquires build history information from version management server 201, and identifies the source file based on the association data. The association data associates a machine image name, a file name of the source file, and a version of the source file. CPU 101 identifies, as the source file to be built, the source file identified by the source file name and version associated by the association data with the machine image name included in the playback instruction accepted in step S13.

[0114] In step S16, the deadline for the source file is acquired, and the process proceeds to step S 17. CPU 101 acquires the deadline for the source file from deadline management server 202.

[0115] In step S17, the build history data is acquired, and the process proceeds to step S 18. CPU 101 acquires from version management server 201 the build history data indicating the build history of the source file.

[0116] In step S18, a performance determination process is executed, and the process proceeds to step S19. The performance determination process will be described in detail later, but is a process for determining the performance of a virtual server in which a build environment formed in the service providing server 200 is set.

[0117] In step S19, a request to change the performance of the virtual server is made, and the process proceeds to step S20. CPU 101 transmits a command to service providing server 200 to instruct the change of the performance of the virtual server to the performance determined in step S18. In response to receiving the command, service providing server 200 changes the performance of the virtual server.

[0118] In step S20, it is determined whether a build instruction has been accepted. CPU 101 accepts a build instruction by transmitting the developer build instruction screen shown in Fig. 8 to developer PC 300A and receiving the build instruction from developer PC 300A. The process waits until the build instruction is accepted (NO in step S20), and if the build instruction is accepted (YES in step S20), the process proceeds to step S21. The build instruction includes a virtual server name and a build type. The build type indicates either a differential build or a full build.

[0119] In step S21, a build is instructed to the virtual server formed in the service providing server 200. The CPU 101 instructs the virtual server formed in the service providing server 200 to perform a full build or a differential build of the source file identified in step S15. As a result, the source file is built by the virtual server formed in the service providing server 200, and the build performance data is stored in the repository.

[0120] In the next step S22, the power supply of the virtual server is turned off, and the process ends. The CPU 101 transmits a command to the service providing server 200 to turn off the power supply of the virtual server.

[0121] Fig. 15 is a flowchart showing an example of the flow of the performance determination process. The performance determination process is a process executed in step S18 of the virtual server regeneration process. With reference to Fig. 15, CPU 101 included in build environment management server 100 acquires the due date of the development case and the current date and time (step S31), and advances the process to step S32. CPU 101 calculates the period until the due date.

[0122] In step S32, it is determined whether the time until the due date is equal to or less than a threshold value TH. If the time until the due date is equal to or less than the threshold value TH, the process proceeds to step S33, but if not, the process proceeds to step S35.

[0123] In step S33, an increase rate determination process is executed, and the process proceeds to step S34. In step S34, the increase rate is set to a value determined by default, and the process proceeds to step S35. The increase rate determined by default is determined based on at least one of the development scale, bug density, build history time, and the number of developers.

[0124] In step S35, the performance level is determined, and the process returns to the virtual server regeneration process. If the process proceeds from step S33, the performance level is determined based on the increase rate determined in step S33, and if the process proceeds from step S34, the performance level is determined based on the increase rate set by default. The increase rate indicates the slope of the graph shown in FIG.

[0125] Fig. 16 is a flow chart showing an example of the flow of the increase rate determination process. The increase rate determination process is a process executed in step S33 of the performance determination process. Referring to Fig. 16, the CPU 101 included in the build environment management server 100 judges whether the delivery date is a required delivery date or not (step S41). If the delivery date determined to be equal to or less than the threshold value Th1 in step S32 of the performance determination process is a required delivery date, the process proceeds to step S42, but if not, step S42 is skipped and the process proceeds to step S43. In step S42, the CPU 101 increases the increase rate and proceeds to step S43. The CPU 101 determines the increase rate to be a value larger than the increase rate set by default.

[0126] In step S43, it is determined whether the development scale is equal to or greater than a threshold value Th2. If the development scale is equal to or greater than the threshold value Th2, the process proceeds to step S44, but if not, step S44 is skipped and the process proceeds to step S45. In step S44, CPU 101 increases the rate of increase, and the process proceeds to step S45. The rate of increase is determined to be a value greater than the rate of increase determined before step S43 was executed.

[0127] In step S45, it is determined whether the bug density is equal to or greater than a threshold value Th3. If the bug density is equal to or greater than the threshold value Th3, the process proceeds to step S46. If not, step S46 is skipped and the process proceeds to step S47. In step S46, CPU 101 increases the rate of increase, and the process proceeds to step S47. The rate of increase is determined to be a value greater than the rate of increase determined before step S46 is executed.

[0128] In step S47, it is determined whether the build history time is equal to or greater than a threshold value Th4. If the build history time is equal to or greater than the threshold value Th4, the process proceeds to step S48. If not, step S48 is skipped and the process proceeds to step S49. In step S48, CPU 101 increases the increase rate, and the process proceeds to step S49. The increase rate is determined to be a value greater than the increase rate determined before step S48 was executed.

[0129] In step S49, it is determined whether the number of developers is equal to or greater than a threshold Th5. If the number of developers is equal to or greater than the threshold Th5, the process proceeds to step S50. If not, step S50 is skipped and the process returns to the performance determination process. In step S50, the CPU 101 increases the rate of increase and returns the process to the performance determination process. The rate of increase is determined to be a value greater than the rate of increase determined before step S50 was executed.

[0130] As described above, the software build system 1 in this embodiment includes the build environment management server 100 and the service providing server 200 that provides a service of supplying a virtual server. The build environment management server 100 acquires a delivery date set for the software from the delivery date management server 202, associates the virtual server and the software provided by the service providing server 200, determines the performance of the virtual server based on information about the software, and requests the service providing server 200 to change the performance of the virtual server to the determined performance. Therefore, the time to build the software on the virtual server is adjusted based on information about the software. Also, when the price for receiving the provision of the virtual server from the service providing server 200 varies depending on the performance of the virtual server, the price for receiving the provision of the virtual server can be made as low as possible. Therefore, the time to build the software and the cost for the build can be suppressed.

[0131] Furthermore, the build environment management server 100 determines the virtual server performance to be higher as the time until the software delivery date becomes shorter. Therefore, as the time until the delivery date becomes shorter, the time to build the software can be shortened, and more time can be spent on development.

[0132] Furthermore, when the delivery date of the software includes a first type of delivery date that cannot be changed and a second type of delivery date that can be changed, the build environment management server 100 makes the difference in performance increased per unit time larger when the first type of delivery date is set than when the second type of delivery date is set for the software. When the first type of delivery date is set, the cost is higher than when the second type of delivery date is set, but the build is shorter because the difference in performance increased per unit time of the virtual server is higher. This makes it possible to secure more time for the development of the software. On the other hand, when the second type of delivery date is set, the cost can be lower than when the first type of delivery date is set.

[0133] Furthermore, the build environment management server 100 increases the difference in performance increased per unit time as the number or size of source files constituting the software increases. In general, the larger the number or size of source files, the greater the load on the virtual server, and the longer the build time will be if the performance of the virtual server remains the same. Furthermore, the number or size of source files increases as the development of software progresses. The build environment management server 100 increases the difference in performance increased per unit time when the number or size of source files is large compared to when the number or size of source files is small, and therefore it is possible to prevent the time required to build software in which the number or size of source files increases as development progresses from increasing.

[0134] Furthermore, the build environment management server 100 increases the difference in performance that is increased per unit time the higher the density of bugs in the software. In general, when the bug density of software is high, the number of builds is increased more than when the bug density is low. For this reason, the build environment management server 100 increases the difference in performance that is increased per unit time when the bug density of software is high compared to when the bug density is low, thereby shortening the build time and ensuring time for work on fixing bugs in the software.

[0135] Furthermore, the version management server 201 stores the history of software builds by the virtual server, and the build environment management server 100 increases the difference in performance increased per unit time the longer it takes to build the software. Therefore, the build environment management server 100 increases the difference in performance increased per unit time when the software has been built for a long time compared to when it has been built for a short time, thereby preventing the build time from becoming too long and ensuring time for software development.

[0136] Furthermore, when software is developed by multiple developers, the build environment management server 100 increases the difference in performance that is increased per unit time the greater the number of developers. In general, when there are a large number of developers developing software, the number of builds increases compared to when there are a small number of developers. For this reason, the build environment management server 100 increases the difference in performance that is increased per unit time when there are a large number of developers developing software compared to when there are a small number of developers, thereby shortening the build time and ensuring time for software development.

[0137] The build environment management server 100 also defines a plurality of performance levels with different degrees of performance for the virtual server, selects one from the plurality of performance levels, and transmits a request to the service providing server 200 to change the performance of the virtual server to the performance determined at the selected performance level. This makes it possible to change the performance of the virtual server created in the service providing server 200.

[0138] <Summary of the embodiment> (Item 1) a delivery date acquisition means for acquiring a delivery date set for the software; an association means for associating the virtual server provided by a service that supplies the virtual server with the software; and a performance determination means for determining the performance of the virtual server based on information about the software.

[0139] According to this aspect, the virtual server and the software are associated with each other, and the performance of the virtual server is determined based on information about the software, so that the time to build the software is adjusted. Also, when the price for receiving the provision of the virtual server varies depending on the performance of the virtual server, the price for receiving the provision of the virtual server can be made as low as possible. As a result, it is possible to provide a software build system that suppresses the time and cost for building the software.

[0140] (Item 2) The software build system according to item 1, wherein the performance determining means increases the performance of the virtual server as the time until the delivery date of the software becomes shorter.

[0141] According to this perspective, the shorter the time until the software is delivered, the higher the performance of the virtual server will be, and as the time until delivery shortens, the time required to build the software can be shortened, thereby securing more time for development.

[0142] (Item 3) The delivery date of the software includes a first type of delivery date that cannot be changed and a second type of delivery date that can be changed; 3. The software build system according to claim 2, wherein the difference in performance that the performance determination means increases per unit period is greater when the first type of delivery date is defined for the software than when the second type of delivery date is defined for the software.

[0143] According to this aspect, when the first type of delivery date is set, the cost is higher than when the second type of delivery date is set, but the build time is shorter because the difference in performance increase per unit time of the virtual server is higher. Therefore, more time can be secured for software development. On the other hand, when the second type of delivery date is set, the cost can be lower than when the first type of delivery date is set.

[0144] (Item 4) A software build system according to item 2 or 3, wherein the difference in performance increased per unit time by the performance determining means is greater as the number or size of source files constituting the software is greater.

[0145] According to this aspect, the difference in performance increase per unit period is greater the greater the number or size of source files. The greater the number or size of source files, the greater the load on the virtual server, and the longer the build time will be if the virtual server performance remains the same. As software development progresses, the number or size of source files increases. When the number or size of source files is large, the difference in performance increase per unit period is greater compared to when the number or size of source files is small, so it is possible to prevent the time to build software whose number or size of source files increases as development progresses from increasing.

[0146] (Item 5) The software build system according to any one of Items 2 to 4, wherein the difference in performance increased by the performance determining means per unit time is larger as the density of bugs in the software is higher.

[0147] According to this aspect, the difference in performance improvement per unit time is greater the higher the density of bugs in the software. When the bug density of the software is high, the number of builds is greater than when the bug density is low. Therefore, when the bug density of the software is high, the difference in performance improvement per unit time is greater than when the bug density is low, so the build time is shorter and it is possible to secure time for work on improving the software bugs.

[0148] (Item 6) Further comprising a history storage means for storing a history of the software being built by the virtual server, 6. The software build system according to any one of items 2 to 5, wherein the difference in performance that the performance determining means increases per unit time is larger as the time taken to build the software is longer.

[0149] According to this aspect, the difference in performance increase per unit time is greater the longer it takes to build the software. Therefore, when the time taken to build the software is long, the difference in performance increase per unit time is greater than when the time taken to build the software is short. This makes it possible to prevent the build time from becoming too long and secure time to develop the software.

[0150] (Item 7) A software build system according to any one of Items 2 to 6, wherein, when the software is developed by multiple developers, the difference in performance that the performance determination means increases per unit period is greater the greater the number of the multiple developers.

[0151] According to this aspect, the more developers there are developing software, the greater the difference in performance that can be increased per unit time. When there are a large number of developers developing software, the number of builds increases compared to when there are a small number of developers. Therefore, when there are a large number of developers developing software, the difference in performance that can be increased per unit time is greater than when there are a small number of developers, so the build time is shorter and more time can be secured for software development.

[0152] (Item 8) A software build system described in any one of Items 1 to 7, wherein the performance determination means determines one of a plurality of performance levels which differ in the degree of performance of the virtual server, and requests the service to change the performance of the virtual server to the performance determined by the determined performance level.

[0153] According to this aspect, one of a plurality of performance levels having different degrees of performance of the virtual server is determined, and a request is made to the service to change the performance of the virtual server to the performance determined by the determined performance level. Thus, the performance of the virtual server can be changed.

[0154] (Item 9) a delivery date acquisition step for acquiring a delivery date set for the software; an associating step of associating the software with a virtual server provided by a service that provides the virtual server; A performance determination step of determining the performance of the virtual server based on information relating to the software.

[0155] According to this aspect, it is possible to provide a software development support method that reduces the time and cost required to build software.

[0156] (Item 10) a delivery date acquisition step for acquiring a delivery date set for the software; an associating step of associating the software with a virtual server provided by a service that provides the virtual server; A performance determination step of determining the performance of the virtual server based on information about the software.

[0157] According to this aspect, it is possible to provide a software development support program that reduces the time and cost required to build software.

[0158] The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present invention is defined by the claims, not the above description, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0159] 1 image forming support system, 3 LAN, 5 Internet, 100 mobile terminal, 200A to 200C PC, 400 first server, 401 second server, 402 third server, 101 CPU, 102 ROM, 103 RAM, 104 HDD, 105 communication unit, 106 display unit, 107 operation unit, 108 external storage device, 109 CD-ROM, 201 detection unit, 203 print instruction acquisition unit, 205 image data acquisition unit, 207 RIP, 209 output unit, 211 setting unit, 213 status update unit, 215 device determination unit, 221 account acquisition unit, 223 device type acquisition unit, 225 instruction acquisition request unit, 301 to 306 printing device.

Claims

1. A delivery date acquisition means for acquiring a delivery date set in the software; an association means for associating the virtual server provided by a service that supplies the virtual server with the software; and a performance determination means for determining the performance of the virtual server based on information about the software.

2. 2. The software build system according to claim 1, wherein said performance determining means increases the performance of said virtual server as the time until the delivery date of said software becomes shorter.

3. The delivery date of the software includes a first type of delivery date that cannot be changed and a second type of delivery date that can be changed; 3. The software build system according to claim 2, wherein the difference in performance increased per unit period by said performance determining means is greater when said first type of delivery date is defined for said software than when said second type of delivery date is defined for said software.

4. 4. The software build system according to claim 2, wherein the difference in performance increased by said performance determining means per unit time is greater as the number or size of source files constituting said software is greater.

5. 4. The software build system according to claim 2, wherein the difference in performance increased by said performance determining means per unit time is larger as the density of bugs contained in said software is higher.

6. A history storage unit stores a history of the software being built by the virtual server, 4. The software build system according to claim 2, wherein the difference in performance that said performance determining means increases per unit time increases as the time taken for said software to be built increases.

7. 4. The software build system according to claim 2, wherein, when the software is developed by a plurality of developers, the difference in performance that the performance determining means increases per unit time increases as the number of the plurality of developers increases.

8. The software build system according to any one of claims 1 to 3, wherein the performance determination means determines one of a plurality of performance levels having different degrees of performance of the virtual server, and requests the service to change the performance of the virtual server to the performance determined by the determined performance level.

9. A delivery date acquisition step of acquiring a delivery date set in the software; an associating step of associating the software with a virtual server provided by a service that provides the virtual server; a performance determination step of determining performance of the virtual server based on information about the software.

10. a delivery date acquisition step of acquiring a delivery date set in the software; an associating step of associating the software with a virtual server provided by a service that provides the virtual server; A performance determination step of determining the performance of the virtual server based on information about the software.

Images