Release cycle optimization based on significant features values simulation

Embodiments include a system for release cycle optimization; the system includes a processor configured to perform a method. The method includes accessing, by a processor, historical data relating to a plurality of software version each having a plurality of attributes; selecting a subset of attributes from the plurality of attributes; receiving a set of data values for each of the subset of attributes from the plurality of attributes; performing one or more simulations of a software development cycle utilizing the set of data values; and obtaining a set of results from the one or more simulations comprising a plurality of predicted field defects values corresponding to each of the set of data values.

BACKGROUND

The present disclosure relates to release cycle optimization, and more specifically, to methods, systems, and computer program products for release cycle optimization based on significant features values simulation.

Software release cycle describes the life and stages of development and maturity of a software product. Planning for software release cycle focuses on how to organize development teams, assign backlog items, and plan iterations; all to ensure the highest probability of a successful software product release. Historically, teams use experience during the planning phase and base these planning decisions on knowledge and experience concerning particular tasks and development history from a particular area. From this historical planning, there is a trend to overestimate the development effort rather than underestimate the development effort.

Not all circumstances and parameters are taken into consideration based upon the above planning methodology. With the above planning methodology, the area of product or team which had previous problems with delivering a software product on time or of good quality, are analyzed and reviewed for planning purposes. With this methodology, only single parameters are evaluated and based on this single parameter, software planning decisions are made.

SUMMARY

Embodiments include a computer system for release cycle optimization, the computer system including a server having a processor, the processor configured to perform a method. The method includes accessing, by a processor, historical data relating to a plurality of software version each having a plurality of attributes; selecting a subset of attributes from the plurality of attributes; receiving a set of data values for each of the subset of attributes from the plurality of attributes; performing one or more simulations of a software development cycle utilizing the set of data values; and obtaining a set of results from the one or more simulations comprising a plurality of predicted field defects values corresponding to each of the set of data values.

Embodiments also include a computer program product for release cycle optimization, the computer program product including a non-transitory computer readable storage medium having computer readable program code embodied therewith. The computer readable program code including computer readable program code configured to perform a method. The method includes accessing, by a processor, historical data relating to a plurality of software version each having a plurality of attributes; selecting a subset of attributes from the plurality of attributes; receiving a set of data values for each of the subset of attributes from the plurality of attributes; performing one or more simulations of a software development cycle utilizing the set of data values; and obtaining a set of results from the one or more simulations comprising a plurality of predicted field defects values corresponding to each of the set of data values.

DETAILED DESCRIPTION

In accordance with exemplary embodiments of the disclosure, methods, systems and computer program products for release cycle optimization are provided. In exemplary embodiments, the method includes receiving and analyzing historical data related to a previous software product release. The method then utilizes a number of statistical analyses to determine a set of attributes that are significant in predicting a successful software product release. One or more simulation models are built using the significant attributes and a range of values for each of the significant attributes. The one or more simulations are performed and a set of values are selected based upon the number of predicted field defects from the one or more simulations.

Thus, as configured inFIG. 1, the system100includes processing capability in the form of processors101, storage capability including system memory114and mass storage104, input means such as keyboard109and mouse110, and output capability including speaker111and display115. In one embodiment, a portion of system memory114and mass storage104collectively store an operating system coordinate the functions of the various components shown inFIG. 1.

FIG. 2is a block diagram illustrating a release cycle optimization system200according to an embodiment. As shown inFIG. 2, the system200includes a software release cycle database210, an attribute determination module220, a data value set selection module230, a simulation module240, and a field defects prediction module250.

In one or more embodiments, the software release cycle database210contains historical data on previous software releases and/or previous product releases corresponding to various software development cycles. Each release contains various attributes and attributes data. In one or more embodiments, these attributes include the size of the development team, the development time, the size of the test team, the testing time period, automation test hot factors, the number of executed test cases, the number of characteristic defects found, and an iteration length. These attributes are selected based upon the historical performance data for previous software releases to indicate a desired software release performance.

Table 1 contains an exemplary embodiment of historical data on previous software releases that can be found inside the software release cycle database210. Table 1 lists a total of six attributes for five software or product releases with an output attribute for the number of field defects for each release version. Field defects represent faults and anomalies in a software product that may occur in the field, i.e. with a consumer or user of the software product.

In one or more embodiments, the attribute determination module220is configured to select a set of attributes that are deemed significant attributes. Significant attributes are attributes that allow for classification of the previous software release from Table 1 into one of a number of classes. For example, looking at Table 1, there may be two classes such as field defects number within acceptable limits and field defects number outside acceptable limits. Setting the acceptable limits of field defects at a value of fifty-five, the Table 1 results show only three releases (Release 1, Release 2, and Release 4) that would be within acceptable limits for field defect numbers.

In one or more embodiments, the attribute determination module220will determine and select significant attributes for later simulation. The determination of significant attributes can be performed utilizing machine learning algorithms, such as support vector machines (SVM) algorithm. A machine learning algorithm analyzes multiple parameters and correlations/dependencies between these multiple parameters. For example, pairs of parameters or features may show a team A and a product area B which causes a lot of field defects or failures. However, for example, team A and product area C may show results of higher quality and delivery dates that are on time or even ahead of time. Utilizing a machine learning algorithm would allow for selection of attributes that are common to a product release with low field defects.

Referring now to Table 2, there is shown an exemplary embodiment of a sample list of significant attributes: iteration length, the number of executed test cases, and size of the test team. In an embodiment, instead of selecting all six attributes from Table 1, this number is reduced to three significant attributes as shown in Table 2. In one or more embodiments, the three significant attributes are selected using a feature extraction method such as, for example, a machine learning algorithm such as support vector machines algorithm. The remaining attributes would remain unchanged.

In one or more embodiments, after selection of the significant attributes by the attribute determination module220, the data value set selection module230supplies data values for the attributes. In one or more embodiments, these data values for each of the attributes are then supplied to the simulation module240. The simulation module240will build a simulation model wherein the data values for the significant attributes are submitted in a range of values for simulation. For example, the significant attribute of test team size can range from one to six, the number of executed test cases can range from 100 to 1000, and the iteration length can range from five to twenty.

Referring now to Table 3, there is shown an exemplary embodiment of sample content simulation based on all significant attributes. The range of values that are inputted into the simulation content can be based upon resource constraints associated with the release of the software or product.

In one or more embodiments, once a simulation model is built based upon the significant attributes, the simulation module240will perform one or more simulations to identify optimal values based upon the number of field defects.

Referring now to Table 4, there are shown simulation results based upon all the significant attributes. In one or more embodiments, each simulation result and its corresponding combination of factors are being checked against a desired level of field defects. For example, a field defect value threshold can be set at thirty field defects. A simulation data set that is considered in-range would have a field defects value lower than or equal to the field defect value threshold. A simulation data set that is considered out-of-range would have a field defects value higher than the field defects value threshold. For example, the field defects threshold may be fifty which results in only four candidate simulation result combinations as shown in Table 4. The lowest value of twelve field defects results from a test team of six people, a thousand executed test cases, and an iteration length of five. However, should there be additional resource constraints, an acceptable result of forty-four field defects is obtained when the number of executed test cases is reduced from one thousand to five hundred.

In one or more embodiments, resource constraints guide the selection of attribute combinations for implementation of a software release cycle. In the above example, if the field defect threshold is fifty and the lowest costing data set results are below the threshold, then the system would select that set. After the completion of one or more simulations, the system200can display the results to any of a software engineer, hardware engineer, and a human resources individual to assess the needs described by the simulations result and the human and capital resources available to fit these needs. For example, test team sizes may be restricted based upon budgets and available personnel.

In one or more embodiments, the system200may exclude simulation results that do not fit within the resources available for use in the development of the software. For example, a company may have security constraints for certain types of software release projects. These security constraints may confine a software release project to a certain location within the company based upon the type of software being developed. The system200may develop a list of individuals to work on the project and then exclude individuals who do not work in the specified location or it may exclude a simulation result based upon this constraint. Additionally, a company may have a limit on the number of software release projects an individual can work on at one time. If the system200identifies an individual that has too many projects, it may exclude this individual from being listed as a resource in the simulation or may exclude the simulation result based upon this constraint.

In one or more embodiments, the system200may identify a need for an individual with a certain skill set to work on the software release project. For example, a specific type of software engineer with knowledge of a computer language may be necessary for development. Should this type of software engineer not be employed at the company, the system200may trigger a workflow for human resources to hire an individual with the proper skill set. The system200may also trigger training for individuals within the company to develop a skill set such as, for example, learning a new computer language. In one or more embodiments, the system200can develop a projected budget for a software release project based upon the identified resources within a company. For example, if software engineer A has the proper skill set to work on a project, his or her cost may be identified within the budget and may be compared against another software engineer within the company. Another engineer, software engineer B, may be able to work on the project for a lower cost based upon his or her salary. A simulation result may be excluded if it exceeds a budget constraint.

Referring now toFIG. 3there is shown a flow diagram illustrating a method300for release cycle optimization according to one or more embodiments. As shown in block310, the method300accesses, by a processor101, historical data, wherein the historical data relates to a plurality of software versions each having a plurality of attributes. Next, at block320, the method300selects a set of attributes from the plurality of attributes. The method300then receives a set of data values for each of the set of attributes from the plurality of attributes, as shown at block330. Next, at block340, the method300performs one or more simulations of a software development cycle utilizing the set of data values. At block350, the method300obtains a set of results from the one or more simulations comprising a plurality of predicted field defects corresponding to each of the set of data values.