Method for identifying critical parts in software code

A method for identifying critical parts in software code comprised in a number of software code files. The method comprises fetching at least two revisions of the software code, wherein the at least two revisions includes a first revision and a second revision, and the second revision being a latter revision. The method further comprises comparing the second revision to the first revision in order to identify at least a first and a second segment of software code in the second revision that have been changed, fetching at least a first and second timestamp correlated with the change of the at least first and second segment of software code respectively, and determining a time difference between the change of the at least first and second segment of software code based on the at least first and second timestamp. If the time difference is within a predetermined range, the method includes assigning a temporal coupling between the at least first and second segment of software code. If the temporal coupling has been assigned, the method also includes identifying the first and/or second segment of software code as critical parts.

CROSS-REFERENCE TO RELATED APPLICATIONS

This applications is national phase application of International Application No. PCT/SE2017/050770 field Jul. 10, 2017. Application No. PCT/SE2017/050770 claims priority to European Patent Application No. 16183741.4 filed Aug. 11, 2016. The entireties of the aforementioned applications are incorporated herein by reference.

TECHNICAL FIELD

The inventive concept generally relates to the field of software programming, and more particularly to the field of software code management and risk assessment of software code.

BACKGROUND

Companies in the software industry spend a large part of their budget on maintaining and improving existing software code. Large software code files are usually the product of a shared development effort. It is not an unusual occurrence to find 30-40 developers having made contributions to a single software code file. Further, such large software code files could consist of thousands of lines of code, and may in some cases be seen as a system by themselves. As a result, software code is often difficult to maintain, and no single developer has a holistic picture of the evolution of the software code.

There is therefore a need for improved software code management, facilitating software maintenance and software code comprehension.

SUMMARY OF THE INVENTION

It is an object of the present inventive concept to mitigate, alleviate or eliminate one or more of the above-identified deficiencies in the art and disadvantages singly or in combination.

According to a first aspect of the inventive concept, these and other objects are achieved in full, or at least in part, by a method for identifying critical parts in software code comprised in a number of software code files, the method comprising: fetching at least two revisions of the software code, wherein the at least two revisions comprises a first revision and a second revision, the second revision being a latter revision; comparing said second revision to said first revision in order to identify at least a first and a second segment of software code in said second revision that have been changed; fetching at least a first and second timestamp correlated with said change of said at least first and second segment of software code respectively; determining a time difference between said change of said at least first and second segment of software code based on said at least first and second timestamp; if said time difference is within a predetermined range, assigning a temporal coupling between said at least first and second segment of software code; and if said temporal coupling has been assigned, identifying said first and/or second segment of software code as critical parts.

The software code may be comprised in at least two software code files.

The method may further comprise the step of providing a suggestion on how to re-arrange the software code such that the critical parts appear closer to each other.

The method may further comprise the step of re-arranging the software code according to the suggestion.

The method may further comprise the step of providing a suggestion on how to split one or several of the number of software code files and/or combine at least two software code files such that the critical parts appear closer to each other.

The method may further comprise the step of splitting and/or combining the one or several of the number of software code files according to the suggestion.

The method may further comprise the step of identifying a number of developers involved in the change of the at least first and second segment of software code, and wherein the step of assigning a ticket identifier coupling between the at least first and second segment of software code further comprises a prerequisite that the same developer has been involved in the change of the at least first and second segment of software code.

The method may further comprise the step of identifying a number of ticket identifiers referenced in the change of the at least first and second segment of software code, and wherein the step of assigning a temporal coupling between the at least first and second segment of software code further comprises the prerequisite that the change of the at least first and second segment of software code have been made with reference to the same ticket identifier.

According to a second aspect of the inventive concept, these and other objects are achieved in full, or at least in part, by a method for suggesting a developer suitable for updating software code comprised in a number of software code files, the method comprising: identifying a number of critical parts in the software code according the first aspect; identifying a number of developers that have been involved in developing the number of critical parts; and providing names of the number of developers.

According to a third aspect of the inventive concept, these and other objects are achieved in full, or at least in part, by a computer program comprising computer program code adapted to perform the steps according to the first aspect when the computer program is run on a computer.

The computer program may be embodied on a computer readable medium.

Other objectives, features and advantages of the present inventive concept will appear from the following detailed disclosure, from the attached claims as well as from the drawings.

DETAILED DESCRIPTION

The present inventive concept may enable the identification of potential risks in large codebases. Generally, the identification may be made possible by analysis of the historic contributions by developers involved in the development of a software code. More particularly, the identification may be made possible by analyzing the pattern of how individual functions evolve over time, within a single software code file and/or across multiple software code files.

It will be understood that the present inventive concept may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the present disclosure.

These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions means which implement the function specified in the present disclosure.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable data processing apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable data processing apparatus provide processes for implementing the functions specified in the present disclosure.

In the context of the present inventive concept, the following terminology will be used:

Segment of software code—A function or method comprising software code.

Change of segment of software code—An addition of software code to the segment of software code, and/or a deletion of software code comprised in the segment of software code, and/or a re-arrangement of software code comprised in the segment of software code.

Temporal coupling—A coupling between at least two segments of software code based on analysis of software code changes with respect to time and/or developer involvement and/or ticket identifier references.

Below reference is made to a first and second segment of software code. However, as is readily appreciated by the person skilled in the art, any number of segments of software code is possible within the scope of the present inventive concept.

With reference toFIG. 1, a first revision102and a second revision104of a software code file106is illustrated. The first revision102may comprise a number of segments of software code108. Here, between the two revisions102,104, a first and second segment of software code110and112respectively has been changed. The two changed segments of software code110,112, may be identified by comparing the second revision104to the first revision102. It is to be understood that the two revisions102,104are not necessarily subsequent revisions. In contrast, a number of revisions may have been performed between the two revisions102,104.

Now referring toFIG. 2, examples of information, events, and timestamps related to a development of a software code file206are illustrated. Below, references will be made to changes of segments of software code files. It is to be understood that these changes may be identified according to the disclosure made in conjunction withFIG. 1.

The software code file208may comprise a number of segments of software code208. The following may be seen as an example of how a software code file may change over time. A working copy of a first revision202may be checked out by a developer for revising the software code file206. The checkout214may be associated with a timestamp tAcorrelated with the time at which the checkout214occurred. A change of a first segment of software code210may be made. The change of the first segment of software code210may be committed. A first commit216may be associated with a timestamp tBcorrelated with the time at which the first commit216occurred. In conjunction with the first commit216, a second revision204may be created. The change of the first segment of software code210may be associated with the timestamp tB. In other words, the timestamp tBmay be correlated with the change of the first segment of software code210.

A change of a second segment of software code212may be made. The change of the second segment of software code212may be committed. A second commit218may be associated with a timestamp tCcorrelated with the time at which the second commit218occurred. In conjunction with the second commit248, a third revision246may be created. The change of the second segment of software code212may be associated with the timestamp tC. In other words, the timestamp tCmay be correlated with the change of the second segment of software code212.

A time difference ΔtBCbetween the changes of the first and second segment of software code210,212may be determined based on the timestamps tB, tC, correlated with the changes of the first and second segment of software code210,212respectively. If the time difference ΔtBCis within a predetermined range, a temporal coupling between the first and second segment of software code210,212may be assigned. The predetermined range may be defined in a unit of time, such as a number of minutes. One example of such a predetermined range is 0 hours to 24 hours. If the temporal coupling between the first and second segment of software code210,212has been assigned, at least one of the first and second segment of software code210,212may be identified as a critical part. The identification of at least one of the first and second segment of software code210,212as critical parts may be further based on the frequency of assigned temporal couplings between the two segments of software code210,212. In other words, if a temporal coupling between the first and second segment of software code210,212is assigned multiple times during a predetermined period of time, at least one of the first and second segment of software code210,212may be identified as a critical part. The predetermined period of time may be defined in a unit of time, such as a number of minutes, hours, and days, or by the time between any two revisions of software code comprised in a number of software code files.

A change of a third segment of software code254may be made. The change of the third segment of software code254may be committed. A third commit252may be associated with a timestamp tDcorrelated with the time at which the third commit252occurred. In conjunction with the third commit252, a fourth revision250may be created. The change of the third segment of software code254may be associated with the timestamp tD. In other words, the timestamp tDmay be correlated with the change of the third segment of software code254.

A time difference ΔtBDbetween the changes of the first and third segment of software code210,254may be determined based on the timestamps tB, tD, correlated with the changes of the first and third segment of software code210,254respectively. If the time difference ΔtBDis within a predetermined range, a temporal coupling between the first and third segment of software code210,254may be assigned. The predetermined range may be defined in a unit of time, such as a number of minutes. If the temporal coupling between the first and third segment of software code210,254has been assigned, at least one of the first and third segment of software code210,254may be identified as a critical part. The identification of at least one of the first and third segment of software code210,254as critical parts may be further based on the frequency of assigned temporal couplings between the two segments of software code210,254. In other words, if a temporal coupling between the first and third segment of software code210,254is assigned multiple times during a predetermined period of time, at least one of the first and third segment of software code210,254may be identified as a critical part. The predetermined period of time may be defined in a unit of time, such as a number of minutes, hours, and days, or by the time between any two revisions of software code comprised in a number of software code files.

Now referring toFIG. 3, similar to the disclosure made in conjunction withFIG. 2, a change of a first segment of software code310may be associated with a timestamp tAcorrelated with the time at which the change occurred. A change of a second segment of software code312may be associated with a timestamp tBcorrelated with the time at which the change occurred. The two changes may be made while referencing the same ticket identifier318. The fact that the two changes were made while referencing the same ticket identifier318may indicate that a temporal coupling between the first and second segment of software code310,312, exists. In other words, the assignment of a temporal coupling between the first and second segment of software code310,312, may be based solely on, or in combination with a time difference and predetermined range as described in conjunction withFIG. 2 or 8, the existence of a common ticket identifier318referenced for the changes of the first and second segment of software code310,312. In other words, a number of ticket identifiers referenced in the change of the first and second segment of software code310,312may be identified. The assignment of a temporal coupling between the first and second segment of software code310,312may comprise a prerequisite that the change of the first and second segment of software code310,312has been made with reference to at least one and the same ticket identifier.

It may also be possible to identify a number of developers involved in the changes of the first and second segment of software code310,312. The assignment of a temporal coupling between the first and second segment of software code310,312may be based solely on, or in combination with a time difference and predetermined range as described in conjunction withFIG. 2 or 8and/or a ticket identifier as described in the section above, the existence of a common developer involved in the change of the first and second segment of software code310,312. In other words, a number of developers involved in the change of the first and second segment of software data310,312may be identified. The assignment of a temporal coupling between the first and second segment of software code310,312may comprise a prerequisite that at least one and the same developer has been involved in the change of the first and second segment of software code310,312. An identification of a common developer involved in the change of the first and second segment of software code310,312may be defined as a developer coupling between the first and second segment of software code310,312. The predetermined range as described in conjunction withFIGS. 2 and 8may be adjusted if a developer coupling between the first and second segment of software code310,312is not assigned. Similarly, the predetermined range may be adjusted if a developer coupling between the first and second segment of software code310,312is assigned. For example, if a developer coupling is assigned, the predetermined range may be increased.

Below, reference will be made to critical parts. It should be understood that there may exist subgroups of critical parts. In other words, depending on the temporal coupling, and/or developer coupling, a critical part may belong to a number of specific subgroups. In the disclosures made in conjunction withFIGS. 4-6, the critical parts420,520, and620, belong to a common subgroup of critical parts respectively.

Now referring toFIG. 4, a software code file406may comprise a number of critical parts420arranged among a number of segments of software code. The critical parts420may have been identified by any combination of the methods disclosed in conjunction withFIGS. 2, 3, and 8. The software code comprised in the software code file406may be re-arranged such that the critical parts420appear closer together in the software code. This may be accomplished by moving either of the critical parts420. Hereby, the readability and comprehension of the software code file406may be increased.

Now referring toFIG. 5, a first software code file522may comprise a number of critical parts520arranged among a number of segments of software code. The critical parts520may have been identified any combination of the methods disclosed in conjunction withFIGS. 2, 3, and 8. The software code file522may be split such that the critical parts520appear closer to each other in the software code. This may be accomplished by arranging the critical parts520in a second software code file524and arranging the remaining software code in a third software code file526. As is readily understood by the person skilled in the art, any number of software code files may be created in order to provide for that critical parts comprised in the software code file522appear closer to each other.

Now referring toFIG. 6, a first and second software code file628,630may comprise a number of critical parts620arranged among a number of segments of software code. The critical parts620may have been identified by any combination of the methods disclosed in conjunction withFIGS. 2, 3, and 8. The first and second software code file628,630may be combined such that the critical parts620appear closer to each other. This may be accomplished by arranging the software code comprised in both the first and second software code file628,630in a third software code file632. As is readily understood by the person skilled in the art, any number of software code files may be combined in order to provide for that critical parts comprised in the number of software code files appear closer to each other. Similarly, as is readily understood by the person skilled in the art, any number of software code files may be created as a result of the combination. For example, three software code files comprising critical parts belonging to a first and a second subgroup of critical parts may be combined to create a first and a second software code file comprising critical parts belonging to a first and a second subgroup of critical parts respectively.

Now referring toFIG. 7, a method for identifying critical parts in software code comprised in a number of software code files is illustrated in a block diagram. The method comprises a step of fetching734at least two revisions of the software code, wherein the at least two revisions comprises a first revision and a second revision, the second revision being a latter revision. The method further comprises comparing736the second revision to the first revision in order to identify at least a first and a second segment of software code in the second revision that have been changed. The method further comprises fetching738at least a first and second timestamp correlated with the change of the at least first and second segment of software code respectively. The method further comprises determining740a time difference between the change of the at least first and second segment of software code based on the at least first and second timestamp. The method further comprises, if the time difference is within a predetermined range, identifying742a temporal coupling between the at least first and second segment of software code. The method further comprises, if the temporal coupling has been assigned, identifying744the first and/or second segment of software code as critical parts.

Below will follow an alternative method of associating timestamps with changes of segments of software code. In contrast to the disclosure made in conjunction withFIG. 2, several timestamps may be associated with several changes of segments of software code between two subsequent revisions of a software code file.

Now referring toFIG. 8, alternative examples of information, events, and timestamps related to a development of a software code file806are illustrated. The software code file806may comprise a number of segments of software code808. The following may be seen as an example of how a software code file may change over time. A working copy of a first revision802may be checked out by a developer for revising the software code file806. The checkout814may be associated with a timestamp tAcorrelated with the time at which the checkout814occurred. A change of a first segment of software code810may be made. The change of the first segment of software code810may be associated with a timestamp t1correlated with the time at which the change occurred. A change of a second segment of software code812may be made. The change of the second segment of software code812may be associated with a timestamp t2correlated with the time at which the change occurred. At some point in time, the developer may commit his changes to the software code. The commit816may be associated with a timestamp tBcorrelated with the time at which the commit816occurred. After the commit816is made, a second revision804may be created. The changes may be identified according to the disclosure made in conjunction withFIG. 1. A time difference Δt between the changes of the first and second segment of software code810,812may be determined based on the timestamps t1, t2, correlated with the changes of the first and second segment of software code810,812respectively. If the time difference Δt is within a predetermined range, a temporal coupling between the first and second segment of software code810,812may be assigned. The predetermined range may be defined in a unit of time, such as a number of minutes. If the temporal coupling between the first and second segment of software code810,812has been assigned, at least one of the first and second segment of software code810,812may be identified as a critical part. The identification of at least one of the first and second segment of software code810,812as critical parts may be further based on the frequency of assigned temporal couplings between the two segments of software code810,812. In other words, if a temporal coupling between the first and second segment of software code810,812is assigned multiple times during a predetermined period of time, at least one of the first and second segment of software code810,812may be identified as a critical part. The predetermined period of time may be defined in a unit of time, such as a number of minutes, hours, and days, or by the time between any two revisions of software code comprised in a number of software code files.

The inventive concept may further enable a suggestion of a developer suitable for updating software code. The suggestion may be made by identifying a number of critical parts in the software code according to the disclosures made in conjunction withFIGS. 1-8. A number of developers that have been involved in developing the number of critical parts may be identified. The names of the number of developers may then be provided. Hereby, developers that are likely to be familiar with the critical parts of the software code may be suggested.

Utilizing Ticket Identifiers to Identify Critical Parts

The following sections disclose a method for identifying critical parts in software code. In general, the method is based on the realization that if at least one and the same ticket identifier is referenced in the change of a first and second segment of software code, a ticket identifier coupling between the two segments of software code may be assigned, and at least one of the two segments of software code may be identified as a critical part. One example of such a method may be described as:

CLAUSES

1. A method for identifying critical parts in software code comprised in a number of software code files, said method comprising:fetching at least two revisions of said software code, wherein said at least two revisions comprises a first revision and a second revision, said second revision being a latter revision;comparing said second revision to said first revision in order to identify at least a first and a second segment of software code in said second revision that have been changed;fetching at least a first and a second ticket identifier associated with said change of said at least first and second segment of software code respectively;determining if said first and second ticket identifier are the same; if said first and second ticket identifier are the same, assigning a ticket identifier coupling between said at least first and second segment of software code; andif said ticket identifier coupling has been assigned, identifying said first and/or second segment of software code as critical parts.2. The method according to clause 1, wherein the software code is comprised in at least two software code files.3. The method according to clause 1 or 2, further comprising the step of providing a suggestion on how to re-arrange the software code such that the critical parts appear closer to each other in said software code.4. The method according to clause 3, further comprising the step of re-arranging said software code according to the suggestion.5. The method according to any one of the preceding clauses, further comprising the step of providing a suggestion on how to split one or several of the number of software code files and/or combine at least two software code files such that the critical parts appear closer to each other.6. The method according to clause 5, further comprising the step of splitting and/or combining said one or several of said number of software code files according to the suggestion.7. The method according to any one of the preceding clauses, further comprising the step of identifying a number of developers involved in the change of the at least first and second segment of software code, and wherein the step of assigning a ticket identifier coupling between the at least first and second segment of software code further comprises the prerequisite that the same developer has been involved in the change of the at least first and second segment of software code.8. The method according to any one of the preceding clauses, further comprising the steps of: fetching at least a first and second timestamp correlated with the change of the at least first and second segment of software code respectively; determining a time difference between the change of the at least first and second segment of software code based on the at least first and second timestamp; if the time difference is within a predetermined range, assigning a temporal coupling between the at least first and second segment of software code; and wherein the step of assigning a ticket identifier coupling between the at least first and second segment of software code further comprises a prerequisite that said temporal coupling has been assigned.9. A method for suggesting a developer suitable for updating software code comprised in a number of software code files, the method comprising:identifying a number of critical parts in the software code according to any one of clauses 1 to 8;identifying a number of developers that have been involved in developing the number of critical parts; andproviding names of the number of developers.10. A computer program comprising computer program code adapted to perform the steps of any one of clauses 1 to 8 when the computer program is run on a computer.11. The computer program according to clause 10 embodied on a computer readable medium.
Identifying Parts in Software Code for Review

The following sections disclose a method for identifying parts in software code for review in order to improve the software code. This method may be performed as an automated step in a software code review process in order to get a list of parts of the software code that are critical for the functionality of the software code. In general, the method is based on the realization that a segment of software code subject to frequent changes may be more likely to contain errors compared to a segment of software code which is rarely changed. Further, a complexity analysis of the segments of software code may be combined with a change frequency analysis. For example, a complex segment of software code which is frequently changed is more likely to contain errors, compared to a less complex segment of software code which is frequently changed. One example of such a method may be described as:

CLAUSES

1. A method for identifying parts in software code for review, said method comprising:providing a change frequency log comprising a number of segments of software code comprised in said software code;determining a change frequency of said number of segments of software code;updating said change frequency log to reflect said change frequency of said number of segments of software code;assigning each of said number of segments of software code in said change frequency log a review score based on said change frequency; andidentifying segments of software code in said change frequency log having a review score exceeding a predetermined threshold as parts for review.2. The method according to clause 1, wherein said software code is comprised in a plurality of software code files, and wherein said method further comprises a step of determining a change frequency of said number of plurality of software code files.3. The method according to clause 1 or 2, further comprising determining a complexity value for each of said number of segments of software code, and wherein said review score is based on a combination of said complexity value and said change frequency.4. The method according to any one of the preceding clauses, wherein the step of determining a change frequency of said number of segments of software code comprisesfetching a number of revisions of said software code;identifying a number of segments of software code comprised in any of said number of revisions;comparing pairs of subsequent revisions in said number of revisions in order to identify a number of segments of software code that have been changed; anddetermining a number of change occurrences for each of said number of segments of software code that have been changed.5. The method according to clause 2, further comprising identifying critical software code files based on a file change frequency and/or a file complexity value, and for said critical software code files, identifying parts for review according to any one of clauses 2 to 4.

As is evident from the clauses above, in one example of the method, a change frequency may first be determined on a file-level, and subsequently on a sub-file level. In other words, a plurality of software code files may first be analyzed in order to find the software code file which is most frequently changed. The software code file which is most frequently changed may then be analyzed in order to determine the change frequency of individual segments of software code comprised in the software code file. The method may further comprise analyzing and identifying a file complexity value for each software code file. Hereby, an efficient method for identifying software code parts for review is achieved.

LIST OF REFERENCE SIGNS

102First revision104Second revision106Software code file108Segment of software code110First segment of software code112Second segment of software code202First revision204Second revision206Software code file208Segment of software code210First segment of software code212Second segment of software code214Checkout216First commit246Third revision248Second commit250Fourth revision252Third commit254Third segment of software code310First segment of software code312Second segment of software code318Ticket identifier406Software code file420Critical part520Critical part522First software code file525Second software code file526Third software code file620Critical part628First software code file630Second software code file632Third software code file734Step of fetching revisions736Step of comparing revisions738Step of fetching timestamps740Step of determining time difference742Step of identifying temporal coupling744Step of identifying critical part802First revision804Second revision806Software code file808Segment of software code810First segment of software code812Second segment of software code816Commit