Developing software project plans based on developer sensitivity ratings detected from monitoring developer error patterns

Abstract

A selection of one or more files for a project plan for a software build is identified. A historical assessment of one or more developers available during a build timeline for the project plan is accessed, the historical assessment comprising an assessment value calculated from one or more previously evaluated sensitivity ratings from one or more previously edited files by the one or more developers of one or more previous software builds. An optimized selection of the one or more developers is assigned to each selection of one or more files based on the historical assessment. The optimized selection of the one or more developers for each selection of one or more files in the project plan for the software build is output.

Description

BACKGROUND1. Technical Field[0001]The embodiment of the invention relates generally to data processing and particularly to developing software project plans based on developer sensitivity ratings detected from monitoring developer error patterns.2. Description of the Related Art[0002]When teams of developers work together on a software project to develop a software project, the developers access software build files for the software project, edit the software build files, and commit the edited files to a software build. Each developer may access software build files from a source control system that manages a repository for the software build, tracks the developer changes to the files in the software build, and manages commitment of the edited files to the software build.[0003]When developers edit files and commit the files to the software build, developers often include defects in the edited files that will cause the software build to fail when executed, also referred to as breakin...

AI Technical Summary

Benefits of technology

[0007]In view of the foregoing, one or more embodiments of the present invention provide for developing software project plans based on developer sensitivity ratings, detected from monitoring developer error patterns, to optimize the selection of files for a software project plan and the assignment of developers to the files, to reduce build breaks and minimize the anticipated time required for building a software project. One or more embodiments of the present invention provide for generating a sensitivity rating indicating the sensitivity of each file in a project build to cause breaks in the software build, in real-time, during the development of a software build and collecting sensitivity ratings for multiple developers for one or more project builds, over time, in order to monitor for developer error patterns by one or more developers over one or more project build. One or more embodiments of the present invention provide for developing software project plans with a selection of developers automatically selected based on the error patterns detected for each developer and the sensitivity of the files in a software project plan to breaks, based on previously detected sensitivity ratings, such that in developing a software project plan, scheduling of developers may be optimized to assign developers to specific files based on the sensitivity of the file and the error pattern of the developer.

[0008]In one or more embodiments, a method is directed to, identifying, by a computer system, a selection of one or more files for a project plan for a software build. The method is directed to accessing, by the computer system, a historical assessment of one or more developers available during a build timeline for the project plan, the historical assessment comprising an assessment value calculated from one or more previously evaluated sensitivity ratings from one or more previously edited files by the one or more developers of one or more previous software builds. The method is directed to assigning, by the computer system, an optimized selection of the one or more developers to each of the selection of one or more files based on the historical assessment. The method is directed to outputting, by the computer system, the optimized selection of the one or more developers for each of the selection of one or more files in the project plan for the software build. One advantage of accessing a historical assessment of one or more developers available during a build timeline for the project plan, the historical assessment comprising an assessment value calculated from one or more previously evaluated sensitivity ratings from one or more previously edited files by the one or more developers of one or more previous software builds, is that the historical assessment of a particular developer reflects an analysis of the developer's relative level of experience with breaks while editing one or more previous software builds, that provides the project planner with more information about the developer's experience than is provided merely by an identifier of one or more previous software builds that a developer has edited files within. In addition, one advantage of assigning an optimized selection of the one or more developers to each of the selection of one or more files based on the historical assessment is that scheduling of developers for a project plan is automated and optimized to match developers with files within a project plan based on the historical assessments to minimize the amount of project planning time spent evaluating which developers to assign to program files during project planning and optimize the matching of developers with more experience minimizing breaks while editing files in previous software builds with files in the current project plan that may be more sensitive to breaks.

Problems solved by technology

When developers edit files and commit the files to the software build, developers often include defects in the edited files that will cause the software build to fail when executed, also referred to as breaking the software build.

When large software projects are developed, with many files in the software build, along with multiple developers accessing and editing the many files, it may be difficult to keep track of which files, when changed, cause the software build to break and time may be wasted as developers, through trial and errors, submit edited files that break the software build.

A developer learning about the likelihood that edits to a file will break the software build, through trial and error and testing, requires development time and does not provide other developers with this learned understanding that edits to a file are likely to cause a build to break.

The developer's rate of gaining an understanding of the importance of the file is also limited by the developer's experience editing a particular software project build and the developer's overall experience level editing code.

Moreover, the likelihood that edits to a file to may cause breaks in a software build may be further impacted by the experience level of the developer editing the file, where a developer with less programming experience with a particular type of code function may introduce more errors into a file that cause the file to break the software build than would a developer with more programming experience with the particular type of code function.

Developers may access a GIT report prepared by the GIT function to receive a log of the metrics, which provides some information about the potential importance of a file, however, the number of lines changed in a file and the number of times a file is committed alone does not provide developers with a full understanding of the likelihood that a file may cause breaks in a particular software build because some software builds may have files that are heavily edited, but do not cause the build to break and other software build may have files where a single line edit in the file may cause the software build to break.

In addition, the GIT function metrics do not provide any information about the relative experience level of the developer editing the file, however, the relative experience level of the developer editing the file may impact the number of lines the developer edits and the number of times the files is committed with changes.

's log of additional information collected about a particular file committed to source code, collected from the contents of that source code alone, does not provide developers with a full understanding of the sensitivity of a file to cause breaks in a particular software build, where some software builds may have files that are heavily edited, but do not cause the build to break and other software build may have files where a single line edit in the file may cause the software build to break.

In addition, Jain's log of additional information about a particular file committed to source code does not provide developers with a real-time analysis and assessment of the sensitivity, of a file that causes a break to a particular software build, to cause further breaks in the software build.

In addition, US Publication 20150143335 is limited to collecting information about the contents of the source code committed, which does not provide any information about the relative experience level of the developer editing the file, which impacts the contents of the particular file committed.

Images