Abstract: Techniques pertaining to analyzing power consumed by a processing unit in a mobile computing device caused by execution of certain modules are described herein. A power trace is generated that indicates an amount of power consumed by the processing unit over time, and the power trace is aligned with an execution log. Spikes are extracted from the power trace, and computing operations are performed over the spikes to acquire data pertaining to power consumed by the processing unit that are attributable to modules in the execution log.

Abstract: The discussion relates to software development automated analytics. One example can access a database related to a software development project. The database can include both software code and non-code metadata. The example can analyze the non-code metadata and the software code to identify parameters. It can relate the parameters to aspects of the software development project. The example can cause a graphical user interface to be presented that conveys an individual aspect.

Abstract: Generation of a dependency graph for code that includes code portions such as resources or functions or both. For some or all of the nodes, the dependency is calculated by determining that the given node, a depending node, depends on an affecting node. The dependency is recorded so as to be associated with the node. Furthermore, the dependency calculation method is recorded so as to be associated with the dependency. The code may perhaps include portions within two different domains, in which the mechanism for calculating dependencies may differ. In some cases, the dependency graph may be constructed in stages, and perhaps additional properties may be associated with the node, and metadata of the properties may also be recorded.

Abstract: An exemplary method includes receiving source code having a plurality of code segments, providing a desired level of quality for the source code, analyzing the source code to assign a complexity measure to each of the plurality of code segments and assigning a level of code coverage to each of the plurality of code segments based at least in part on the desired level of quality and the complexity measures. An exemplary system prioritizes quality improvements to source code based, in part, on a quality assessment. Such a system can improve code quality by assigning higher test coverage levels to modules with higher complexity.

Abstract: Techniques pertaining to analyzing power consumed by a processing unit in a mobile computing device caused by execution of certain modules are described herein. A power trace is generated that indicates an amount of power consumed by the processing unit over time, and the power trace is aligned with an execution log. Spikes are extracted from the power trace, and computing operations are performed over the spikes to acquire data pertaining to power consumed by the processing unit that are attributable to modules in the execution log.

Abstract: The discussion relates to software development automated analytics. One example can access a database related to a software development project. The database can include both software code and non-code metadata. The example can analyze the non-code metadata and the software code to identify parameters. It can relate the parameters to aspects of the software development project. The example can cause a graphical user interface to be presented that conveys an individual aspect.

Abstract: The present examples provide technologies for estimating code failure proneness probabilities for a code set and/or the files that make up the set. The code set being evaluated is typically comprised of binary and/or source files that embody the software for which the estimates are desired. The estimates are typically based on a set of selected code metrics, the code metrics typically selected based on corresponding failures of a previous version of the software. A historically variant metric feedback factor may also be calculated and code metric values classified relative to a baseline code set embodying the previous version of the software.

Abstract: The present examples provide technologies for estimating code failure proneness probabilities for a code set and/or the files that make up the set. The code set being evaluated is typically comprised of binary and/or source files that embody the software for which the estimates are desired. The estimates are typically based on a set of selected code metrics, the code metrics typically selected based on corresponding failures of a previous version of the software. A historically variant metric feedback factor may also be calculated and code metric values classified relative to a baseline code set embodying the previous version of the software.

Abstract: The present examples provide technologies for estimating code failure proneness probabilities for a code set and/or the files that make up the set. The code set being evaluated is typically comprised of binary and/or source files that embody the software for which the estimates are desired. The estimates are typically based on a set of selected code metrics, the code metrics typically selected based on corresponding failures of a previous version of the software. A historically variant metric feedback factor may also be calculated and code metric values classified relative to a baseline code set embodying the previous version of the software.

Abstract: A system is described herein that predicts defects in a portion of code of an application that is configured to execute on a computing device. Versions of code are analyzed to locate change bursts, which are alterations to at least one portion of code over time-related events. If a change burst is identified, defects are predicted with respect to the code based at least in part upon the identified change burst.

Abstract: Techniques described herein help determine dependencies and associations between CPEs in a computing system. These techniques track previous check-ins over a period of time in order to learn the dependencies and associations between CPEs. The previous check-ins are performed by a plurality of different computer programmers. In some embodiments, in response to receiving an indication that a CPE has either already been modified or is about to be modified by a computer programmer, the techniques provide the computer programmer with a recommendation indicating CPEs that are associated with the CPE being modified. This recommendation is based on the dependencies and associations determined from the previous check-ins performed by the plurality of different computer programmers.

Abstract: Code coupling metrics are extracted from compiled code rather than from source code or software specifications. Examples of compiled code include binary machine code and machine-independent intermediate code that is convertible into binary machine code by a just-in-time compiler. The compiled code may be compiled from source code written in an object-oriented programming language, or from source code written in a procedural programming language, or from any combination thereof. A coupling metrics system includes a reader to access compiled code and its symbol table information, and a coupling metrics extraction component to calculate coupling metrics from the compiled code and its symbol table information. The coupling metrics system may be part of an integrated development environment (IDE) system.

Abstract: An exemplary method includes receiving source code having a plurality of code segments, providing a desired level of quality for the source code, analyzing the source code to assign a complexity measure to each of the plurality of code segments and assigning a level of code coverage to each of the plurality of code segments based at least in part on the desired level of quality and the complexity measures. An exemplary system prioritizes quality improvements to source code based, in part, on a quality assessment. Such a system can improve code quality by assigning higher test coverage levels to modules with higher complexity.

Abstract: Metrics may be determined from intermediate computer code by reading and analyzing an entire application using intermediate code, including any linked portions. The metrics may include cyclomatic complexity, estimated or actual number of lines of code, depth of inheritance, type coupling, and other metrics. The metrics may be combined into a quantifiable metric for the code.

Abstract: The present examples provide technologies for estimating code failure proneness probabilities for a code set and/or the files that make up the set. The code set being evaluated is typically comprised of binary and/or source files that embody the software for which the estimates are desired. The estimates are typically based on a set of selected code metrics, the code metrics typically selected based on corresponding failures of a previous version of the software. A historically variant metric feedback factor may also be calculated and code metric values classified relative to a baseline code set embodying the previous version of the software.

Abstract: Code coupling metrics are extracted from compiled code rather than from source code or software specifications. Examples of compiled code include binary machine code and machine-independent intermediate code that is convertible into binary machine code by a just-in-time compiler. The compiled code may be compiled from source code written in an object-oriented programming language, or from source code written in a procedural programming language, or from any combination thereof. A coupling metrics system includes a reader to access compiled code and its symbol table information, and a coupling metrics extraction component to calculate coupling metrics from the compiled code and its symbol table information. The coupling metrics system may be part of an integrated development environment (IDE) system.