WO2021095136A1 - Software development support device, software development support method, and program - Google Patents

Abstract

A software development support device that comprises: an analysis unit that, for each of a plurality of portions of a software to be developed, analyzes the composition of a character string in information about the specifications of the relevant portion; and a commissionee classification unit that, on the basis of analysis results from the analysis unit, classifies the commissionee for the development of each portion as either inside or outside an organization that is developing the software. The software development support device thereby makes it possible to use crowdsourcing, even for software that includes highly confidential functions.

Description

Software development support device, software development support method and program

The present invention relates to a software development support device, a software development support method, and a program.

Conventionally, software development by crowdsourcing has been carried out. In crowdsourcing, when a software development consignor recruits a consignee via the Internet, the person who wishes to consign the software development is entrusted with the development work.

Specifically, the consignor divides the software development work into multiple parts so that the development work can be carried out by multiple people. For example, division by data definition and division by method definition are performed (Non-Patent Document 1). The trustee confirms the functional specifications of each divided part, selects which part is in charge, and implements the part. The consignor collects the parts implemented by the consignor and conducts integration testing to ensure that the software works correctly.

However, in software development by crowdsourcing, it is difficult to use crowdsourcing for software that includes highly confidential functions because information about the software to be developed is disclosed to the outside of the consignor.

The present invention has been made in view of the above points, and an object of the present invention is to enable the use of crowdsourcing even for software including highly confidential functions.

Therefore, in order to solve the above problems, the software development support device includes an analysis unit that analyzes the composition of the character string in the information related to the specifications of each of a plurality of parts constituting the software to be developed, and an analysis by the analysis unit. Based on the result, it has a contractor classification unit that classifies the contractors for the development of each part into the organization of the software developer or outside the organization.

It is possible to use crowdsourcing even with software that includes highly confidential functions.

It is a figure which shows the system configuration example in 1st Embodiment. It is a figure which shows the hardware configuration example of the development support server 10 in 1st Embodiment. It is a figure which shows the functional structure example of the development support server 10 in 1st Embodiment. It is a figure which shows the configuration example of the task information storage unit 121. It is a figure which shows the structural example of the keyword storage part 122. It is a flowchart for demonstrating an example of the processing procedure executed by development support server 10 in 1st Embodiment. It is a figure which shows an example of the count result of the co-occurrence number of a named entity. It is a figure which shows an example of the analysis result of the coverage rate and co-occurrence frequency for each task. It is a figure which shows an example of the classification result of the consignee of each task. It is a figure which shows the functional structure example of the development support server 10 in the 2nd Embodiment. It is a flowchart for demonstrating an example of the processing procedure executed by development support server 10 in 2nd Embodiment. It is a figure which shows the configuration example of the mounting record storage unit 124. It is a figure which shows the structural example of the review destination limited storage part 125.

Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing an example of a system configuration according to the first embodiment. In FIG. 1, the development support server 10 is connected to a plurality of work terminals 20 belonging to the inner environment via a network N1 such as an intranet within an organization such as a company that develops a certain software. The inner environment refers to the network environment inside the organization. The development support server 10 is also connected to a plurality of work terminals 20 belonging to the cloud environment, which is a network environment outside the organization, via a network N2 such as the Internet. The above-mentioned organization is hereinafter referred to as "organization X".

The development support server 10 is one or more computers that manage software development work and the like. The development support server 10 crowdsources the software development work developed by the organization X to the workers existing in the cloud environment. However, the development support server 10 allocates the work to the workers in the inner environment for the highly confidential part of the development work or the software to be developed. That is, in the present embodiment, not only crowdsourcing is performed for software development, but also outsourcing to an inner worker (hereinafter referred to as "inner sourcing") is performed. By doing so, the risk of leakage of confidential information can be reduced.

The work terminal 20 in the inner environment is a terminal such as a PC used by a worker belonging to the organization X (hereinafter referred to as "inner worker") for software development work.

The work terminal 20 in the cloud environment is a terminal such as a PC (Personal Computer) used by workers outside the organization X to which the organization X does not belong (hereinafter referred to as "cloud worker") for software development work.

FIG. 2 is a diagram showing a hardware configuration example of the development support server 10 according to the first embodiment. The development support server 10 of FIG. 2 has a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, and the like, which are connected to each other by a bus B, respectively.

The program that realizes the processing on the development support server 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive device 100, the program is installed in the auxiliary storage device 102 from the recording medium 101 via the drive device 100. However, the program does not necessarily have to be installed from the recording medium 101, and may be downloaded from another computer via the network. The auxiliary storage device 102 stores the installed program and also stores necessary files, data, and the like.

The memory device 103 reads and stores the program from the auxiliary storage device 102 when the program is instructed to start. The CPU 104 executes the function related to the development support server 10 according to the program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network.

FIG. 3 is a diagram showing a functional configuration example of the development support server 10 in the first embodiment. In FIG. 3, the development support server 10 has an analysis unit 11, a contractor classification unit 12, and a development management unit 13. Each of these parts is realized by a process of causing the CPU 104 to execute one or more programs installed on the development support server 10. The development support server 10 also uses the task information storage unit 121, the keyword storage unit 122, and the classification result storage unit 123. Each of these storage units can be realized by using, for example, an auxiliary storage device 102, a storage device that can be connected to the development support server 10 via a network, or the like.

The analysis unit 11 divides the specifications (functional specifications) of the plurality of functions of the software created in the design work related to the software to be developed so that the development work related to the specifications can be shared by a plurality of workers. For each unit (hereinafter referred to as "task"), the composition of the character string in the information related to the specifications of the relevant part is analyzed. In the present embodiment, the co-occurrence status of a preset character string group (keyword group stored in the keyword storage unit 122) is analyzed as the configuration. The specification may be divided by using, for example, the technique described in Non-Patent Document 1.

The outsourcer classification unit 12 classifies the outsourcer of the development work of each task into an inner worker (inner environment) or a cloud worker (cloud environment) based on the analysis result by the analysis unit 11.

The development management unit 13 performs the same processing as that performed in publicly known crowdsourcing for each task, such as distribution to workers and management of progress status (status).

The task information storage unit 121 stores the classification results of the software to be developed into tasks of each specification. FIG. 4 is a diagram showing a configuration example of the task information storage unit 121. As shown in FIG. 4, the task information storage unit 121 stores "specification number", "specification name", and information on one or more tasks belonging to the specification (hereinafter, referred to as "task information") for each specification. Information to be included (hereinafter referred to as "specification information") is stored. The task information includes a "task number", a "task name", a "description", and the like.

"Specification number", an identification number assigned to each specification (that is, each function). The "specification name" is a name given to each specification (that is, each function). The "task number" is a task identification number within one specification to which the task belongs. In the present embodiment, the execution order of the processing of the part (a part of the function) corresponding to each task in the specification is used as the task number. The "task name" is a name given to the task. The "description" is a description (character string) relating to the function or the functional specification of the part corresponding to the task.

In FIG. 4, for convenience, only information related to one specification (“insurance charge calculation”) is shown, but “specification number”, “specification name”, and task information are task information for each of the plurality of specifications. It is stored in the storage unit 121. The number of tasks belonging to each specification (ie, the number of divisions in each specification) does not have to be the same.

The keyword storage unit 122 stores a keyword sentence (character string group) for evaluating the high degree of confidentiality of each task definition information stored in the task information storage unit 121.

FIG. 5 is a diagram showing a configuration example of the keyword storage unit 122. As shown in FIG. 5, in the keyword storage unit 122, one or more named entity is associated with each appearing word and stored (that is, a keyword group consisting of a set of the appearing word and one or more named entity). The set of is remembered).

The appearing word is a keyword that is a condition that the confidentiality of each task definition information is relatively high, and is a character string that is first searched for in the evaluation of confidentiality. In other words, the confidentiality of the task definition information that does not include the occurrence word is evaluated to be relatively low. Named entity recognition is a keyword that relatively raises the evaluation of the confidentiality of the task definition information when it co-occurs with the appearing word in the task definition information.

In the example of FIG. 5, "vehicle type", "age", "grade", and "contract years" are associated with the appearance word "insurance fee" as unique expressions. This is because, in the software to be developed, "vehicle type", "age", "grade" and "contract years" are factors of "insurance fee". That is, when a document containing "insurance fee" and "vehicle type", "age", "grade" and "contract years" is published outside Organization X, "vehicle type", "age", "grade" and There is a risk of leakage of confidential information that "years of contract" is a factor of "insurance charges". Therefore, "vehicle type", "age", "grade", and "years of contract" are associated with the appearance word "insurance fee" as unique expressions.

Although only one appearing word is shown in FIG. 5, one or more named entities are defined in advance for each of the plurality of appearing words.

The processing procedure executed by the development support server 10 will be described below. FIG. 6 is a flowchart for explaining an example of the processing procedure executed by the development support server 10 in the first embodiment.

In the processing procedure shown in FIG. 6, the analysis unit 11 executes the loop processing L1 for each occurrence word stored in the keyword storage unit 122 (FIG. 5). Hereinafter, the appearance word that is the processing target in the loop processing L1 is referred to as a “target appearance word”. The loop process L1 includes a loop process L2 in which steps S101 to S107 are executed for each specification in which the specification information is stored in the task information storage unit 121 (FIG. 4). Hereinafter, the specifications to be processed in the loop processing L2 are referred to as "target specifications".

In step S101, the analysis unit 11 determines whether or not the "specification name" of the target specification includes the target appearance word. When the "specification name" includes the target occurrence word (Yes in S101), the analysis unit 11 describes the "specification name", the "task name" and the "description" of the task for each of the tasks belonging to the target specification. The number of occurrences (that is, the number of co-occurrence) of each named entity (hereinafter, referred to as "object named entity") corresponding to the target named word in the combined (combined) character string group is counted (S102).

For example, when the specification whose "specification name" is "insurance charge calculation" in FIG. 4 is the target specification and the target word is "insurance charge" in FIG. 5, the "specification name" is "insurance". "Charge calculation" includes the target word. Therefore, in this case, in step S102, the number of co-occurrence of each of "vehicle type", "age", "grade" and "contract years" in the "specification name", "task name" and "description" of the target specification is It is counted for 5 tasks belonging to the target specification.

FIG. 7 is a diagram showing an example of the count result of the number of co-occurrence of the named entity. FIG. 7 shows the count result of the number of co-occurrence of the occurrence word “insurance fee” and each named entity corresponding to the appearance word for the specification in which the “specification number” is “01”. Since FIG. 7 is the execution result of step S102, the total of the number of appearances in the “specification name”, the number of appearances in the “task name”, and the number of appearances in the “description” is shown for each named entity. There is.

On the other hand, when the "specification name" of the target specification does not include the target occurrence word (No in S101), the analysis unit 11 executes the loop process L3 including steps S103 to S105 for each task belonging to the target specification. Hereinafter, the task to be processed in the loop processing L3 is referred to as a “target task”.

In step S103, the analysis unit 11 determines whether or not the target occurrence word is included in the "task name" or "description" of the target task (both or either of them) (S103). When the target occurrence word is included in the "task name" or "description" of the target task (Yes in S103), the analysis unit 11 uses the "specification name" of the target specification, the "task name" of the target task, and the target task. The number of appearances (that is, the number of co-occurrences) of each object-specific expression in the character string group including the "description" is counted (S104). On the other hand, when the target occurrence word is not included in either the "task name" or the "description" (No in S103), the analysis unit 11 has 0 co-occurrence of each named entity for the target task. (S105).

When the loop process L3 is completed, the count result of the number of co-occurrence of each named entity for the target occurrence word is generated for each task belonging to the target specification in the same format as in FIG.

For example, in the specification information shown in FIG. 4, it is assumed that the character string (target appearance word) of "insurance fee" is not included in the "specification name". In this case, the tasks having task numbers 2, 3, 4, and 5 include "insurance fee" in the "task name" or "description". Therefore, for each of these tasks, the number of appearances of each named entity in the "specification name", "task name", and "description" is counted. On the other hand, the "task name" and "description" of the task whose task number is 1 do not include the "insurance fee". Therefore, the count result of the number of co-occurrence of each named entity for the task is 0.

Following step S102 or loop processing L3, the analysis unit 11 calculates the coverage rate and co-occurrence frequency for each task belonging to the target specification based on the count result of the number of co-occurrence of each named entity. S107). The coverage rate and the frequency of appearance are calculated based on the following formulas.
Coverage rate = (number of named entity with co-occurrence of 1 or more ÷ total number of named entity) × 100 (%) ・ ・ ・ (1)
Occurrence frequency = Σ Co-occurrence number of each object named entity ... (2)
FIG. 8 is a diagram showing an example of the analysis results of the coverage rate and the co-occurrence frequency for each task. In FIG. 8, the total number of object named entities = 4. On the other hand, in task 1, the named entity with a co-occurrence number of 1 or more is one of the "vehicle types". Therefore, the coverage rate of task 1 = (1/4) × 100 = 25 (%). Further, in task 1, the number of co-occurrence of "vehicle type" is 4, and the number of co-occurrence of other named entity-specific expressions is 0. Therefore, the co-occurrence frequency of task 1 = 4.

On the other hand, in task 3, there are four named entity-specific expressions whose co-occurrence number is 1 or more. Therefore, the coverage rate of task 3 = (4/4) × 100 = 100 (%). Further, in task 3, the number of co-occurrence of each named entity is 1. Therefore, the co-occurrence frequency of task 3 = 4. For other tasks, since the number of co-occurrence of each named entity is 0, the coverage rate is 0 (%) and the co-occurrence frequency is 0.

Note that the coverage rate may be calculated as a weighted average using weights for each named entity. By doing so, it is possible to consider the difference in the degree of confidentiality (importance to confidentiality) for each named entity.

In addition, in the above, an example is shown in which the number of appearances (co-occurrence) of named entity is counted from the "specification name", but when the "specification name" is hidden from the contractor, the "specification" is shown. The "name" may be excluded from the count target of the number of occurrences (co-occurrence) of the named entity.

When the loop processing L2 is completed for all the specification information and the loop processing L1 is completed for all the appearing words, the consignee classification unit 12 classifies the consignees of each task belonging to each specification (S108). Specifically, the outsourcer classification unit 12 determines the outsourcer of each task of each specification by comparing the coverage rate calculated for each occurrence word with a preset threshold value for each task of each specification. judge. That is, the outsourcer classification unit 12 classifies the outsourcer of the task whose coverage rate is equal to or higher than the threshold value for any one or more of the appearing words into the inner worker (inner environment), and the coverage rate is less than the threshold value for all the appearing words. A task is outsourced to a cloud worker (cloud environment). The coverage rate is used because it is considered that confidential information is more likely to be leaked when the appearing words co-occur with more named entities.

For example, FIG. 9 is a diagram showing an example of the classification result of the contractor of each task. FIG. 9 shows the classification result of the contractor of each task when the analysis result such as the coverage rate of each named entity is as shown in FIG. 8 when the appearing word is only “insurance fee”. In FIG. 9, the threshold value for the coverage rate is set to 50%. In this case, the outsourcer of task 3 is classified as an inner worker, and the outsourcer of tasks other than task 3 is classified as a cloud worker. Also referring to FIG. 4, for task 3, "insurance fee", "vehicle type", "age", "grade" and "contract years" co-occur, and task 3 is outsourced to a cloud worker. If this is the case, it is presumed that the risk that the insurance premium calculation method will be estimated outside the organization X will increase, but according to the first embodiment, it is necessary to avoid such a situation. Can be done. If a plurality of appearing words are defined, the contractor may be classified as an inner worker for tasks other than task 3.

The contractor classification unit 12 stores the classification result as shown in FIG. 9 in the classification result storage unit 123.

In the above, the example of classifying the consignees using only the coverage rate is shown, but the consignees may be further classified using the co-occurrence frequency.

The classification result by the contractor classification unit 12 is input to the development management unit 13. In the inner environment, the development management unit 13 publishes a task list screen (Web page) including a list of tasks for which the contractor is classified as an inner worker, and in the cloud environment, the contractor is classified as a cloud worker. By publishing the task list screen (Web page) including the task list, we are recruiting entrustees for each task. Here, the disclosure of the task list screen means that the task list screen can be accessed via the network. As a result, the tasks that the cloud worker can take charge of are limited to the tasks for which the contractor is classified as a cloud worker. Each worker in the cloud environment and the inner environment accepts (takes over) the task that he / she wants to be in charge of development from the list of tasks displayed on the task list screen displayed on each work terminal 20. .. That is, the subcontractor classification unit 12 does not identify the worker for each task. The recruitment of trustees by the development management department 13 may be carried out in the same manner as known crowdsourcing and the like. Exclusive control for avoiding duplicate development by a plurality of workers may also be performed using a known technique.

As described above, according to the first embodiment, the contractors of each task are classified according to the high degree of confidentiality of each task. Specifically, highly confidential task consignees (which may leak confidential information) are classified as inner workers, and non-confidential task consignees are classified as cloud workers. As a result, it is possible to use crowdsourcing even for software that includes highly confidential functions.

Next, the second embodiment will be described. The second embodiment will be described which is different from the first embodiment. The points not particularly mentioned in the second embodiment may be the same as those in the first embodiment.

In software development, the work process (work phase) of each task is classified into a mounting process (mounting work) and a review process (review work) in chronological order. The mounting process is a work process in which functions related to tasks are implemented (programming, etc.). The review process is a work process in which the deliverables (program source code, etc.) in the mounting process are reviewed. In general, it is desirable that the worker (implementer) in charge of the mounting process and the worker (reviewer) in charge of the review process are different for the same task. Furthermore, the reviewer should be a worker who has abundant skills and experience in software development.

Therefore, in the second embodiment, the development management unit 13 manages the progress (start and end, etc.) of each task for each work process, and the task (work terminal 20 of the worker entrusted with the task) for which the implementation process has been completed. For tasks that have been notified that the mounting process has been completed), we will recruit workers for the review process again. For example, the status may be displayed for each task on the work list screen. The status includes "not implemented", "implementing", "implementing completed", "reviewing", "reviewing completed", and the like. "Unimplemented" means that the task has not been entrusted. "Implementing" means that the task has been entrusted by one of the workers and is being implemented. "Implementation completed" means that the task implementation process has been completed and reviewers are being recruited. “Under review” means that the reviewer has taken over the task and is reviewing the deliverables of the mounting process. "Review completed" means a state in which the review process is completed, that is, a state in which the deliverable in the mounting process is completed and all the work processes related to the task are completed.

In the first embodiment, it is the contractor of the mounting process that is classified for each task. Here, if the outsourcer of the implementation process is classified as a cloud worker in the first embodiment, the outsourcer of the task review process is automatically limited to the cloud worker (that is, the recruitment of the implementation process). If only the status is simply updated on the task list screen at the time), there is a possibility that the review process will be carried out by a worker who does not have the appropriate skills or experience as a reviewer. As a result, there is a risk of deterioration in the quality of the task and, by extension, the software containing the task.

In the second embodiment, an example of solving such a problem will be described.

FIG. 10 is a diagram showing a functional configuration example of the development support server 10 in the second embodiment. In FIG. 10, the same parts as those in FIG. 3 are designated by the same reference numerals, and the description thereof will be omitted.

In FIG. 10, the development support server 10 further has a review destination classification unit 14. The review destination classification unit 14 is realized by a process of causing the CPU 104 to execute one or more programs installed on the development support server 10. The development support server 10 further uses the implementation record storage unit 124 and the review destination restriction storage unit 125. Each of these storage units can be realized by using, for example, an auxiliary storage device 102, a storage device that can be connected to the development support server 10 via a network, or the like.

FIG. 11 is a flowchart for explaining an example of the processing procedure executed by the development support server 10 in the second embodiment.

When the review destination classification unit 14 detects that the implementation of any task whose status is "implementing" (hereinafter referred to as "target task") has been completed (Yes in S201), the review destination classification unit 14 implements the target task. Determines whether or not the contractor is a cloud worker (S202).

For example, when the implementation process of any task is completed, the work terminal 20 of the contractor of the implementation process transmits a completion notification including the deliverable of the implementation process of the task to the development management unit 13 of the development support server 10. .. The completion notification further includes a specification number and a task number of the task. The development management unit 13 updates the status of the task to "implementation completed" and transfers the completion notification to the review destination classification unit 14. At this time, the identification information of the worker corresponding to the work terminal 20 of the transmission source of the completion notification (hereinafter referred to as "worker ID") and the information indicating whether or not the worker is a cloud worker are reviewed. The preclassification unit 14 is notified. The review destination classification unit 14 can detect the completion of the implementation of the target task based on the completion notification, and can determine whether or not the contractor of the target task is a cloud worker.

When the contractor of the implementation process of the target task is an inner worker (No in S202), the review destination classification unit 14 does not execute after step S203. In this case, the contractor of the review process of the target task remains the inner worker.

On the other hand, when the contractor of the implementation process of the target task is an inner worker (No in S202), the review destination classification unit 14 determines the reliability of the worker who has been entrusted with the target task (hereinafter referred to as “target worker”). The rank is acquired from the mounting record storage unit 124 (S203).

FIG. 12 is a diagram showing a configuration example of the mounting record storage unit 124. As shown in FIG. 12, the mounting record storage unit 124 stores a worker ID, mounting record information, reliability rank, and the like for each cloud worker.

The mounting record information is information showing the past record of the mounting process, and includes items such as the number of implementations, the number of reviews passed, and the review passing rate. The number of implementations is the number of tasks for which the worker (cloud worker) related to the worker ID has performed the implementation process.

The number of reviews passed is the number of tasks that have passed the review process among the tasks related to the number of implementations. Passing through the review process means that it is confirmed in the review process that there is no problem with the deliverables (source code, etc.) of the mounting process, and the task status becomes "review completed". A task in which a problem is found in the deliverable in the review process may be returned to the mounting process. In this case, the remand destination is the worker who performed the implementation process of the task. The worker corrects the deliverable in order to solve the problem pointed out, and ends the development process of the task again. However, the implementation of the development process when it is returned is not counted in the number of mountings. Alternatively, the worker can give up solving the problem pointed out and return the status of the task to "not implemented". In this case, for the worker, 1 is added to the number of implementations, but 1 is not added to the number of passing reviews.

The review pass rate is the ratio of the number of reviews passed to the number of implementations. That is, the review passing rate is the probability that the review will pass.

The reliability rank is a classification of the reliability of the worker regarding the mounting process. In the present embodiment, the reliability rank is divided into three stages of A, B, and C.

A is a category that satisfies the condition that the number of implementations is 30 or more and the review passing rate is 80% or more. B is a category that satisfies the condition that the number of implementations is 15 or more and the review passing rate is 50% or more. C is a category that is neither A nor B. Therefore, the relationship of high reliability is A> B> C. That is, FIG. 12 shows an example in which the reliability of cloud workers is ranked based on the number of tasks performed in crowdsourcing so far and the results regarding the accuracy of implementation work (= review passing rate of implemented tasks). Is shown. The number of reliability ranks and the conditions for each reliability rank are only examples.

The implementation record information and reliability rank of a certain worker (cloud worker) are, for example, when the status of the task for which the worker was in charge of the mounting process returns to "not implemented" or "review completed". When it is updated, the development management unit 13 updates it. When the status of a certain task returns to "not implemented", the development management unit 13 adds 1 to the number of implementations of the worker in the implementation process of the task and updates the review passing rate. The development management unit 13 also determines the reliability rank of the worker, and updates the reliability rank as necessary. on the other hand. When the status of a task is updated to "review completed", the development management unit 13 adds 1 to each of the number of implementations and the number of reviews passed by the worker in the implementation process of the task, and updates the review pass rate. To do. The development management unit 13 also determines the reliability rank of the worker, and updates the reliability rank as necessary.

Subsequently, the review destination classification unit 14 classifies the contractors of the review process of the target task based on the reliability rank (hereinafter, referred to as “target reliability rank”) acquired in step S203 (S204). Such classification is performed with reference to the review destination restricted storage unit 125.

FIG. 13 is a diagram showing a configuration example of the review destination restriction storage unit 125. As shown in FIG. 13, the review destination restriction storage unit 125 stores the restriction of the review destination in association with the reliability rank. The restriction of the review destination means the restriction regarding the contractor of the review process.

According to the example of FIG. 13, when the target reliability rank is A, there is no restriction on the review destination, so the review destination classification unit 14 determines the contractor of the review process of the target task as a cloud worker. That is, following the development process, the review process is also outsourced to the cloud worker. When the target reliability rank is B, the review destination classification unit 14 classifies the contractor of the review process of the target task into a cloud worker having a reliability rank of B or higher. When the target reliability is C, the review destination classification unit 14 classifies the contractor of the review process of the target task as an inner worker.

The classification result by the review destination classification unit 14 is notified to the development management department 13. The development management unit 13 changes the disclosure destination of the target task based on the classification result.

In the above, an example has been described in which only the tasks whose mounting process consignees are classified as cloud workers are subject to processing in steps S203 and subsequent steps, but also for tasks whose mounting process consignees are classified as inner workers. Step S203 and subsequent steps may be executed. This is because even an inner worker may have workers with little skill or experience. In this case, the criteria for classifying the reliability rank for the inner worker and the content of the restriction corresponding to the reliability rank in the review destination restriction storage unit 125 may be different from those for the cloud worker.

As described above, according to the second embodiment, even when the implementation process is outsourced to cloud workers with various skills and experience, there is a possibility that the risk of quality deterioration may increase. In the meantime, the tasks assigned to the crowdsourcing side can be dynamically distributed to inner sourcing or a reliable cloud worker. As a result, the risk of quality deterioration of software development using crowdsourcing can be suppressed.

Note that the second embodiment can be applied even when the task consignees are classified by a method different from that of the first embodiment. For example, when the contractor of the development process of each task is manually classified as an inner worker or a cloud worker, the second embodiment may be applied.

In each of the above embodiments, the development support server 10 is an example of a software development support device.

Although the embodiments of the present invention have been described in detail above, the present invention is not limited to such specific embodiments, and various modifications are made within the scope of the gist of the present invention described in the claims.・ Can be changed.

10 Development support server 11 Analysis unit 12 Outsourced classification unit 13 Development management department 14 Review destination classification unit 20 Work terminal 100 Drive device 101 Recording medium 102 Auxiliary storage device 103 Memory device 104 CPU
105 Interface device 121 Task information storage unit 122 Keyword storage unit 123 Classification result storage unit 124 Implementation record storage unit 125 Review destination restriction storage unit B bus

Claims (7)

1. For each of the multiple parts that make up the software to be developed, an analysis unit that analyzes the composition of the character string in the information related to the specifications of that part, and an analysis unit.
   Based on the analysis results by the analysis unit, the contractor classification unit that classifies the contractors for the development of each part into or outside the organization of the software developer.
   A software development support device characterized by having.
2. The analysis unit analyzes the co-occurrence status of the preset character string group in the information regarding the specifications of the part.
   The software development support device according to claim 1.
3. For each part where the contractor is classified outside the organization, the contractor of the review work for the mounting work of the part is based on the actual information on the past mounting work of the worker who was in charge of the mounting work of the part. Review destination classification unit, which classifies
   The software development support device according to claim 1 or 2, wherein the software development support device is characterized by having.
4. For each of the multiple parts that make up the software to be developed, an analysis procedure that analyzes the composition of the character string in the information related to the specifications of that part, and the analysis procedure.
   Based on the analysis result in the analysis procedure, the contractor classification procedure for classifying the development contractor of each part into the organization of the software developer or outside the organization, and the contractor classification procedure.
   A software development support method characterized by a computer executing.
5. The analysis procedure analyzes the co-occurrence status of a preset character string group in the information regarding the specifications of the part.
   The software development support method according to claim 4, wherein the software development support method is characterized.
6. For each part where the contractor is classified outside the organization, the contractor of the review work for the mounting work of the part is based on the actual information on the past mounting work of the worker who was in charge of the mounting work of the part. Review destination classification procedure, which classifies
   The software development support method according to claim 4 or 5, wherein the software is executed by a computer.
7. A program characterized by operating a computer as the software development support device according to any one of claims 1 to 3.

Images