ES2923100T3 - Clasificación de partes de código de software - Google Patents
Clasificación de partes de código de software Download PDFInfo
- Publication number
- ES2923100T3 ES2923100T3 ES18778845T ES18778845T ES2923100T3 ES 2923100 T3 ES2923100 T3 ES 2923100T3 ES 18778845 T ES18778845 T ES 18778845T ES 18778845 T ES18778845 T ES 18778845T ES 2923100 T3 ES2923100 T3 ES 2923100T3
- Authority
- ES
- Spain
- Prior art keywords
- software code
- metric
- code
- metrics
- pieces
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/77—Software metrics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/75—Structural analysis for program understanding
Abstract
Se describe un método para clasificar una pluralidad de partes de un código de software para identificar una o más partes candidatas del código de software para alteración. El código de software está asociado con un registro histórico de cambios que indica alteraciones previas de las partes del código de software. El método comprende (para cada una de la pluralidad de partes del código de software) determinar una pluralidad de métricas constituyentes de la parte del código de software analizando el registro del historial de cambios y determinando el código de software una métrica de alteración reciente para la parte del software código en función de las indicaciones de tiempo del registro del historial de cambios, y escalar una o más de las métricas constituyentes en función de la métrica de alteración reciente. La pluralidad de métricas constituyentes comprende: una métrica de complejidad de código de la parte derivada en base al código de software, y una métrica de frecuencia de cambio de la parte determinada en base a las indicaciones de tiempo del registro de historial de cambios. El método también comprende clasificar la pluralidad de partes del código de software en función de sus respectivas métricas constituyentes y generar una señal indicativa de una o más partes candidatas del código de software en función de la clasificación. También se describen los correspondientes arreglos, nodos de control y productos de programas informáticos. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Clasificación de partes de código de software
Campo técnico
La presente divulgación se refiere en general al campo del desarrollo y mantenimiento de código de software. Más particularmente, se refiere a la identificación de partes de código de software como partes candidatas para su alteración y/o a la reducción de la utilización de hardware para el desarrollo de código de software.
Antecedentes
En el desarrollo y/o mantenimiento del código de software, puede ser engorroso priorizar entre diferentes partes del código de software, por ejemplo, para determinar en qué partes del código de software se deberían centrar la corrección de errores, las mejoras o acciones similares. Habitualmente, una priorización subóptima conduce a uno o más de los siguientes problemas: un código de software menos compacto, más iteraciones del desarrollo de software (y, por lo tanto, más versiones del código, un número más alto de confirmaciones y/o más compilaciones del código de software), etc. Habitualmente, estos problemas son particularmente pronunciados cuando el código de software comprende una gran cantidad de partes y/o líneas de código.
Existen algunos enfoques que intentan resolver el problema de la priorización. Algunos ejemplos de tales enfoques incluyen métodos para la revisión de código, el análisis de código y el análisis de métricas de complejidad. De acuerdo con tales enfoques, es posible determinar si un fragmento de código es, o no, complicado.
Algunos enfoques para el análisis de código aplican un aprendizaje automático para identificar problemas de calidad y otras cuestiones relacionadas con el software. Un ejemplo de un enfoque de este tipo se divulga en Y. Suresh, L. Kumar y S. K. RathStatistical, "Machine Learning Methods for Software Fault Prediction Using CK Metric Suite: A Comparative Analysis", ISRN Software Engineering, Volumen 2014, ID de Artículo 251083, https://www.hindawi.com/journals/isrn/2014/251083/. Habitualmente, los enfoques de aprendizaje automático para el problema anterior (por ejemplo, el uso de entrenamiento supervisado y la construcción de modelos) son problemáticos, debido a que estos pueden no generalizarse a bases de código de software que no sean las usadas para su entrenamiento.
Se divulga técnica anterior relevante adicional en A. Tornhill, "Code Maat", https://web.archive.org/web/20170223131925/https://github.com/adamtornhill/code-maat, que presenta una herramienta de línea de comandos usada para extraer y analizar datos a partir de un sistema de control de versiones y en S. Stevanetic, U. Zdun, "Software Metrics for Measuring the Understandability of Architectural Structures", Actas de la 19a Conferencia Internacional sobre Evaluación y Valoración en Ingeniería de Software, abril de 2015, Artículo n.° 21, que presenta un estudio de correlación sistemático que recopila diferentes métricas de software a partir de trabajo relacionado (por ejemplo, tamaño, acoplamiento, complejidad).
Por lo tanto, existe la necesidad de enfoques alternativos para priorizar entre diferentes partes del código de software.
Sumario
Se debería hacer hincapié en que se interpreta que la expresión "comprende/comprendiendo/que comprende", cuando se usa en la presente memoria descriptiva, especifica la presencia de características, elementos integrantes, etapas o componentes expuestos, pero no excluye la presencia o adición de una o más características, elementos integrantes, etapas, componentes o grupos de los mismos. Como se usan en el presente documento, se pretende que las formas singulares "un", "una" y "el/la" incluyan asimismo las formas plurales, a menos que el contexto indique claramente lo contrario.
Un objeto de algunas realizaciones es resolver o mitigar, aliviar o eliminar al menos algunas de las desventajas anteriores, u otras desventajas.
De acuerdo con un primer aspecto, esto se logra mediante un método para clasificar una pluralidad de partes de un código de software para la identificación de una o más partes candidatas del código de software para su alteración como se define en la reivindicación 1.
En algunas realizaciones, la pluralidad de métricas constituyentes comprende además una o más de - una métrica de importancia arquitectónica de la parte del código de software determinada basándose en el registro de historial de cambios, y una métrica de fragmentación de desarrolladores de la parte del código de software determinada basándose en identidades de desarrollador del registro de historial de cambios asociadas con indicaciones respectivas de alteraciones previas del código de software.
En algunas realizaciones, el método comprende además normalizar cada una de las métricas constituyentes antes de
la etapa de clasificar la pluralidad de partes del código de software.
De acuerdo con algunas realizaciones, determinar una o más de las métricas constituyentes comprende excluir, de la determinación, alteraciones previas asociadas con una indicación de tiempo fuera de una ventana de tiempo del registro de historial de cambios.
El método puede, de acuerdo con algunas realizaciones, comprender además determinar una métrica de tendencia de complejidad de código para cada una de la pluralidad de partes del código de software, y ajustar a escala una o más de las métricas constituyentes basándose en la métrica de tendencia de complejidad de código antes de la etapa de clasificar la pluralidad de partes del código de software.
En algunas realizaciones, el método puede comprender además (antes de la etapa de clasificación) agrupar las partes del código de software en una pluralidad de grupos basándose en las métricas constituyentes respectivas de cada una de las partes del código de software y, para cada uno de los grupos, determinar una métrica de grupo basándose en las métricas constituyentes respectivas de cada una de las partes del código de software del grupo. Entonces, clasificar la pluralidad de partes del código de software basándose en sus métricas constituyentes respectivas puede comprender clasificar la pluralidad de grupos basándose en su métrica de grupo respectiva.
De acuerdo con algunas realizaciones, el método puede comprender además (para cada una de la pluralidad de partes del código de software) determinar una métrica combinada basándose en la pluralidad de métricas constituyentes. Entonces, clasificar la pluralidad de partes del código de software basándose en sus métricas constituyentes respectivas puede comprender clasificar la pluralidad de partes del código de software basándose en sus métricas combinadas respectivas.
En algunas realizaciones, la señal indicativa de las una o más partes candidatas está configurada para provocar el control de la utilización de hardware asociada con el código de software de alteración.
Un segundo aspecto, que no está cubierto por la invención reivindicada y que se presenta solo con fines ilustrativos, es un método de control de utilización de hardware que comprende realizar el método para clasificar una pluralidad de partes de un código de software de acuerdo con el primer aspecto y controlar la utilización de hardware asociada con alteración del código de software basándose en la señal indicativa de las una o más partes candidatas.
Un tercer aspecto, que no está cubierto por la invención reivindicada y que se presenta solo con fines ilustrativos, es un producto de programa informático que comprende un medio legible por ordenador no transitorio, que tiene en el mismo un programa informático que comprende instrucciones de programa. El programa informático se puede cargar en una unidad de procesamiento de datos y está configurado para provocar la ejecución del método de acuerdo con el primer o el segundo aspecto cuando el programa informático es ejecutado por la unidad de procesamiento de datos.
Un cuarto aspecto es un producto de programa informático como se define en la reivindicación 7.
Un quinto aspecto es un aparato para la clasificación de una pluralidad de partes de un código de software para la identificación de una o más partes candidatas del código de software para su alteración como se define en la reivindicación 9.
Un sexto aspecto, que no está cubierto por la invención reivindicada y que se presenta solo con fines ilustrativos, es un aparato para el control de utilización de hardware que comprende la disposición para clasificar una pluralidad de partes de un código de software de acuerdo con el quinto aspecto, en donde la circuitería de control está configurada además para provocar el control de la utilización de hardware asociada con la alteración del código de software basándose en la señal indicativa de las una o más partes candidatas.
Un séptimo aspecto, que no está cubierto por la invención reivindicada y que se presenta solo con fines ilustrativos, es un nodo de control que comprende la disposición de acuerdo con el quinto aspecto o el aparato de acuerdo con el sexto aspecto.
En algunas realizaciones, cualquiera de los aspectos anteriores puede tener adicionalmente características idénticas o correspondientes a cualquiera de las diversas características según se ha explicado anteriormente para cualquiera de los otros aspectos.
Una ventaja de algunas realizaciones es que se proporcionan enfoques para priorizar entre diferentes partes del código de software.
Breve descripción de los dibujos
Objetos, características y ventajas adicionales aparecerán a partir de la siguiente Descripción detallada de realizaciones, haciéndose referencia a los dibujos adjuntos. Los dibujos no están necesariamente a escala, sino que se hace hincapié en ilustrar las realizaciones de ejemplo.
La figura 1 es un diagrama de flujo que ilustra etapas de método de ejemplo de acuerdo con algunas realizaciones; la figura 2 es un diagrama de flujo que ilustra etapas de método de ejemplo de acuerdo con algunas realizaciones; la figura 3 es una representación gráfica esquemática que ilustra métricas de complejidad de código de ejemplo de acuerdo con algunas realizaciones;
la figura 4 es un diagrama de bloques esquemático que ilustra una disposición de ejemplo de acuerdo con algunas realizaciones; y
la figura 5 es un dibujo esquemático que ilustra un medio legible por ordenador de ejemplo de acuerdo con algunas realizaciones.
Descripción detallada
Como ya se ha mencionado anteriormente, se debería hacer hincapié en que se interpreta que la expresión "comprende/comprendiendo/que comprende", cuando se usa en la presente memoria descriptiva, especifica la presencia de características, elementos integrantes, etapas o componentes expuestos, pero no excluye la presencia o adición de una o más características, elementos integrantes, etapas, componentes o grupos de los mismos. Como se usan en el presente documento, se pretende que las formas singulares "un", "una" y "el/la" incluyan asimismo las formas plurales, a menos que el contexto indique claramente lo contrario.
Las realizaciones de la presente divulgación se describirán y se ejemplificarán a continuación en el presente documento más plenamente con referencia a los dibujos adjuntos. Sin embargo, las soluciones divulgadas en el presente documento se pueden materializar de muchas formas diferentes y no se deberían interpretar como limitadas a las realizaciones expuestas en el presente documento.
En lo sucesivo, se describirán realizaciones en las que se proporcionan enfoques para priorizar entre diferentes partes del código de software.
Como se ha mencionado anteriormente, es posible determinar si un fragmento de código es, o no, complicado mediante la aplicación de métodos para la revisión de código, el análisis de código y/o el análisis de métricas de complejidad. Sin embargo, todos estos enfoques se centran en el estado actual del código de software, y no en el historial de desarrollo y/o de mantenimiento del código de software. Por ejemplo, también puede ser relevante para la priorización cuándo se alteró una parte del código de software.
Además, sería beneficioso si los enfoques de priorización fueran de autoentrenamiento, de tal modo que se pudieran aplicar a cualquier código de software sin los problemas habitualmente experimentados para la priorización de aprendizaje automático en relación con el código de software; que no es posible una generalización a bases de código de software que no sean la usada para el entrenamiento.
Además, es muy posible que una parte de código de software esté libre de errores y que, sin embargo, sea costosa de mantener. Sería beneficioso si un enfoque de priorización pudiera identificar también tales partes de código de software.
En "Your Code as a Crime Scene", de Adam Tornhill (Pragmatic Programmers, ISBN-13: 978-16800500387), se usan métricas de complejidad en combinación con un cálculo del número de revisiones de cada archivo. La métrica resultante se puede usar para identificar partes de código de software denominadas "puntos críticos", lo que puede ser beneficioso para la detección de diversos problemas técnicos.
Sin embargo, este enfoque puede no ser óptimo para la priorización de partes de software en el contexto del mantenimiento. Algunas razones para esto incluyen que un punto crítico identificado puede no constituir un problema en absoluto, debido a que una complejidad alta y muchas revisiones no indican necesariamente un problema grave. Por ejemplo, un punto crítico puede identificar una actividad que está limitada a uno (o unos pocos) desarrolladores (en algunas realizaciones, esto se aborda mediante la aplicación de una métrica de fragmentación de desarrolladores). Otro ejemplo es cuando un punto crítico identifica una parte que no es muy significativa en relación con otras partes del código de software (en algunas realizaciones, esto se aborda mediante la aplicación de una métrica de importancia arquitectónica). Otro ejemplo más es cuando un punto crítico identifica una parte que históricamente ha constituido un problema, pero que ha dejado de hacerlo (en algunas realizaciones, esto se aborda mediante la aplicación de una métrica de actualidad de alteración y/o una métrica de tendencia de complejidad).
La figura 1 ilustra un método 100 de ejemplo de acuerdo con algunas realizaciones. El método es para clasificar una pluralidad de partes de un código de software para la identificación de una o más partes candidatas del código de software para su alteración. El código de software está asociado con un registro de historial de cambios (por ejemplo, un sistema de control de versiones) indicativo de alteraciones previas de las partes del código de software, estando, cada indicación de una alteración previa de una parte del código de software, asociada en el registro de historial de cambios con una indicación de tiempo. El código de software y el registro de historial de cambios están comprendidos en una circuitería de almacenamiento.
Cuando se usa en el presente documento, la expresión partes de un código de software incluye cualquier partición adecuada del código de software. Por ejemplo, una parte de un código de software se puede referir a un archivo, un grupo de archivos, una función, un procedimiento, etc.
Que una parte sea una parte candidata para su alteración puede, por ejemplo, interpretarse como una parte a priorizar para su desarrollo, mejora y/o mantenimiento. La parte candidata para su alteración pueden ser candidatas de refactorización. Habitualmente, la parte candidata para su alteración pueden ser partes del código de software que, en algún sentido, son costosas de mantener (por ejemplo, involucrando a muchos desarrolladores diferentes, afectando a muchas otras partes del código de software y/u ocupando una gran cantidad de tiempo de mantenimiento).
Por lo tanto, una alteración se puede interpretar como cualquier modificación o revisión adecuada (por ejemplo, una adición, un borrado, una reorganización, etc.).
El método comienza analizando el registro de historial de cambios y el código de software en la circuitería de almacenamiento como se ilustra mediante la etapa 105, para adquirir la información necesaria para determinar las métricas como se describirá en lo sucesivo.
En la etapa 110, se determina una pluralidad de métricas constituyentes para cada parte de la pluralidad de partes del código de software. Al menos, la pluralidad de métricas constituyentes comprende una métrica de complejidad de código y una métrica de frecuencia de cambios.
La métrica de complejidad de código se obtiene basándose en el código de software por medio de cualquier algoritmo conocido o futuro adecuado para el análisis de complejidad. Por ejemplo, la métrica de complejidad puede ser indicativa de un tamaño (por ejemplo, un número de caracteres o un número de líneas de código) de la parte correspondiente.
La métrica de frecuencia de cambios se determina basándose en las indicaciones de tiempo del registro de historial de cambios. Las indicaciones de tiempo se usan para calcular cuántas alteraciones (por ejemplo, cuántas confirmaciones) ha experimentado la parte por unidad de tiempo. Un cálculo de este tipo se basa en el número de alteraciones en una ventana de tiempo que excluye las alteraciones que son más antiguas que un tiempo de rastreo máximo.
La pluralidad de métricas constituyentes determinadas en la etapa 110 puede comprender adicionalmente una o más de una métrica de importancia arquitectónica y una métrica de fragmentación de desarrolladores.
La métrica de importancia arquitectónica se determina basándose en el registro de historial de cambios. Esta métrica es para describir cuánto impacto tiene una parte sobre otras partes del código de software (por ejemplo, cuántas asociaciones, acoplamientos, etc., hay entre la parte y otras partes). Por ejemplo, la métrica de importancia arquitectónica se puede determinar determinando el número de veces que la parte ha experimentado una alteración junto con otras partes y/o determinando el número de partes que experimentan una(s) alteración(es) conjuntamente. Habitualmente, una determinación de este tipo se basa en las alteraciones en una ventana de tiempo que excluye las alteraciones que son más antiguas que un tiempo de rastreo máximo.
La métrica de fragmentación de desarrolladores se determina basándose en identidades de desarrollador del registro de historial de cambios asociadas con indicaciones respectivas de alteraciones previas del código de software. Habitualmente, esta métrica es para describir cuántos desarrolladores (o grupos organizativos de desarrolladores) diferentes están implicados en las alteraciones de la parte. Por ejemplo, esta métrica se puede determinar calculando cuántas identidades de desarrollador diferentes están asociadas con alteraciones de la parte. Habitualmente, un cálculo de este tipo se basa en las alteraciones en una ventana de tiempo que excluye las alteraciones que son más antiguas que un tiempo de rastreo máximo. Como alternativa o adicionalmente, la métrica de fragmentación de desarrolladores puede ser para describir cómo se distribuyen las alteraciones de una parte entre la organización de desarrolladores.
En la etapa 120, se determina una métrica de actualidad de alteración para cada parte del código de software basándose en las indicaciones de tiempo del registro de historial de cambios. Las indicaciones de tiempo se usan para determinar cuánto tiempo hace que tuvo lugar la alteración más reciente de la parte. Como alternativa o adicionalmente, la métrica de actualidad de alteración se puede determinar a través del cálculo de cuántas alteraciones ha experimentado la parte por unidad de tiempo en una ventana de tiempo que excluye las alteraciones que son más antiguas que un tiempo de rastreo de actualidad (que es más reciente que el tiempo de rastreo máximo).
Por lo tanto, en general, determinar una o más de las métricas constituyentes puede, de acuerdo con algunas realizaciones como se ha ejemplificado previamente, comprender excluir alteraciones previas asociadas con una indicación de tiempo fuera de una ventana de tiempo del registro de historial de cambios. La ventana de tiempo puede ser una ventana deslizante. Como alternativa o adicionalmente, se pueden aplicar diferentes pesos en la determinación de una o más de las métricas constituyentes, en donde los pesos dependen de cómo de reciente sea la alteración previa, es decir, un tipo de filtrado.
La métrica de actualidad de alteración se usa en la etapa 150 para ajustar a escala una o más de las métricas constituyentes.
En algunas realizaciones, una o más (por ejemplo, cada una) de las métricas constituyentes se pueden normalizar como se ilustra mediante la etapa opcional 140. Habitualmente, tal normalización se realiza antes del ajuste a escala mediante la métrica de actualidad de alteración en la etapa 150. La normalización puede comprender ajustar a escala las métricas a un valor entre 0 y 1, lo que habitualmente se logra dividiendo todos los valores de métrica para el mismo tipo de métrica por el valor más grande posible para ese tipo de métrica o por el valor más grande entre los valores de métrica que se van a normalizar.
Como se ilustra mediante la etapa opcional 130, se puede determinar una métrica de tendencia de complejidad de código para cada una de la pluralidad de partes. La tendencia de complejidad de código se puede usar para ajustar a escala adicionalmente una o más de las métricas constituyentes como se ilustra mediante la etapa opcional 160.
Por ejemplo, la métrica de complejidad de código de la parte determinada en la etapa 110 y en una o más ejecuciones anteriores del método 100 se puede usar para determinar si (y cuánto) está disminuyendo la complejidad a lo largo del tiempo para la parte. Esto se ejemplificará adicionalmente en relación con la figura 3.
A la métrica de tendencia de complejidad de código se le puede dar un valor alto si la complejidad no está disminuyendo, un valor medio si la complejidad está disminuyendo lentamente y un valor bajo si la complejidad está disminuyendo rápidamente (siendo los valores continuos o estando cuantificados). En una realización típica, a la métrica de tendencia de complejidad de código se le da el valor 0 si la métrica de complejidad de código ha disminuido más de un valor umbral durante un período de tiempo especificado, y el valor 1 en caso contrario. El valor umbral se puede dar como un valor absoluto o relativo.
En la etapa 190, las partes del código de software se clasifican basándose en sus métricas constituyentes respectivas. La clasificación en este contexto pretende denotar una priorización relativa entre las partes. Por lo tanto, la clasificación puede comprender ordenar las partes unas en relación con otras; ordenar cada parte en relación con otras partes. Se debería señalar que dos o más partes se pueden clasificar por igual de acuerdo con algunas realizaciones, denotando de ese modo que las mismas se priorizan por igual.
Además, la clasificación se puede realizar entre grupos de partes en lugar de entre partes individuales. Esto se puede lograr, por ejemplo, agrupando (o reuniendo) en primer lugar la pluralidad de partes en grupos como se ilustra mediante la etapa opcional 180. El agrupamiento puede, por ejemplo, realizarse basándose en una o más de las métricas constituyentes respectivas, de tal modo que partes que tienen valores de métrica similares se agrupan en el mismo grupo. El agrupamiento se puede implementar usando cualquier algoritmo de agrupamiento conocido o futuro adecuado. Cuando la clasificación se realiza entre grupos, la clasificación se puede basar en una métrica de grupo determinada en lugar de en las métricas constituyentes de las partes individuales del grupo.
Si un rango alto se interpreta como altamente priorizado, lo siguiente puede habitualmente ser de aplicación para cada una de las métricas constituyentes:
- un valor de métrica de complejidad relativamente alto da una contribución de rango relativamente alta,
- una métrica de frecuencia de cambios relativamente alta da una contribución de rango relativamente alta, - una métrica de importancia arquitectónica relativamente alta da una contribución de rango relativamente alta, y - una métrica de fragmentación de desarrolladores relativamente alta da una contribución de rango relativamente alta.
En la etapa 195, se genera una señal indicativa de las una o más partes candidatas del código de software basándose en la clasificación. Por ejemplo, la señal se puede introducir en una interfaz de usuario para comunicar (parte de) la clasificación a un usuario, por ejemplo, un usuario asociado con la organización de los desarrolladores. Al usuario se le puede proporcionar, por ejemplo, una lista de las partes más priorizadas del código de software (por ejemplo, determinadas como un número predeterminado de las partes con la clasificación más alta o como todas las partes para las que algún valor de métrica supera un umbral de priorización). Como alternativa o adicionalmente, la señal se puede introducir en una circuitería de almacenamiento (por ejemplo, una memoria) para el almacenamiento de (parte de) la clasificación.
En algunas realizaciones, las métricas constituyentes se combinan, como se ilustra mediante la etapa opcional 170, en una métrica combinada antes de la clasificación de la etapa 190 y, si es aplicable, antes del agrupamiento de la etapa 180. La métrica combinada puede, por ejemplo, ser un valor escalar (por ejemplo, un promedio, posiblemente ponderado, de los valores de métrica constituyente, o una suma de los valores de métrica constituyente) o un vector que comprende los valores de métrica constituyente.
En las realizaciones en las que se determina una métrica combinada, el ajuste a escala de la etapa 150 y/o el ajuste a escala de la etapa 160 se pueden aplicar posiblemente a la métrica combinada en lugar de a las métricas
constituyentes.
La interacción entre las diversas etapas del método 100 de ejemplo se puede ejemplificar como sigue. La métrica de frecuencia de cambios y la métrica de actualidad de alteración se determinan basándose en las indicaciones de tiempo del registro de historial de cambios, y la señal indicativa de las una o más partes candidatas del código de software para su alteración se basa en la clasificación de las métricas constituyentes, al menos una de las cuales se ajusta a escala mediante la métrica de actualidad de alteración.
Un efecto de ejemplo de la aplicación del método 100 de ejemplo, mediante el cual se indica una clasificación de partes candidatas para su alteración, es que el desarrollo de software se puede realizar de forma más eficiente, por ejemplo, dando como resultado un código de software más compacto, menos iteraciones del desarrollo de software (y, por lo tanto, menos versiones, menos confirmaciones y/o menos compilaciones del código de software), etc.
Este efecto puede, a su vez, conducir al efecto de una utilización de hardware disminuida. Por ejemplo, un código de software más compacto necesita menos recursos de memoria para almacenar el mismo; cuando hay menos versiones y/o menos confirmaciones del código de software, se necesitan menos recursos de memoria (circuitería de almacenamiento) para almacenar las versiones y/o el contenido del registro de historial de cambios; menos compilaciones del código de software necesitan menos capacidad de procesamiento y menos confirmaciones entrañan que se hagan menos operaciones de escritura en el hardware (circuitería de almacenamiento) que almacena el código de software y/o el contenido del registro de historial de cambios; etc.
Una forma de lograr o potenciar uno o más de los efectos anteriores es dejar que la señal indicativa de las una o más partes candidatas se configure para provocar el control de la utilización de hardware asociada con el código de software de alteración. De hecho, un método de control de utilización de hardware puede comprender ejecutar el método 100 de ejemplo y controlar la utilización de hardware asociada con la alteración del código de software basándose en la señal indicativa de las una o más partes candidatas.
El control de la utilización de hardware basándose en la señal indicativa de las una o más partes candidatas puede adoptar cualquier forma adecuada. Los ejemplos incluyen pero no se limitan a los que se presentan en lo sucesivo.
Las partes de software se pueden seleccionar para su alteración basándose en (por ejemplo, de acuerdo con) la indicación de la señal. Por ejemplo, si la señal indica una o más partes de software (habitualmente de las mejor clasificadas), estas partes de software se pueden seleccionar para su alteración. La selección puede ser realizada por medios técnicos (por ejemplo, una circuitería de selección; que puede, o no, estar comprendida en una circuitería de control descrita más adelante en el presente documento) o por uno o más usuarios (por ejemplo, desarrolladores de software) basándose en una indicación de interfaz de usuario generada a partir de la indicación de la señal.
Debido a que la selección se basa en la clasificación, la alteración del código de software habitualmente diferirá - en términos de qué partes de software se alteran y/o cuándo se alteran partes de software - en comparación con escenarios en los que se aplican otras clasificaciones. Por lo tanto, se puede mejorar la eficiencia de la alteración del código de software.
Tales mejoras pueden lograrse en términos de una reducción del tamaño global del código de software - reduciendo de ese modo el espacio de almacenamiento requerido. Como alternativa o adicionalmente, tales mejoras se pueden lograr en términos de una reducción del número de alteraciones del código - reduciendo de ese modo el tamaño global del registro de historial de cambios (debido a que hay menos confirmaciones) y, por lo tanto, reduciendo el espacio de almacenamiento requerido, y/o la utilización de la capacidad de procesador (debido a que hay menos compilaciones).
La figura 2 ilustra un método 200 de ejemplo de acuerdo con algunas realizaciones. El método 200 se puede ver como un caso especial del método 100 ilustrado en la figura 1. En la siguiente descripción, el algoritmo de acuerdo con algunas realizaciones (y, en particular, el enfoque ilustrado en la figura 2) se denominará Priorización de Candidatos de Refactorización (PRC). Además, parte se ejemplificará mediante un archivo y los términos archivo y parte se usarán de forma intercambiable sin pretenderse que sean limitantes.
En la etapa 210, se determinan métricas evolutivas para las diferentes partes en evaluación y, en la etapa 220, se determinan métricas de complejidad de código para las diferentes partes en evaluación (compárese con las etapas 110 y 120 de la figura 1).
Habitualmente, la determinación de la etapa 220 puede implicar la aplicación de una medida de complejidad adecuada de la industria del software, por ejemplo, la Complejidad Ciclomática de McCabe o una medida de Líneas de Código. La determinación de la etapa 220 se puede realizar iterando a través de todos los archivos (u otros tipos de partes) en el código de software (también denominado código base) y calcular la métrica de complejidad de código para cada uno de los mismos.
Las métricas evolutivas determinadas en la etapa 210 pueden, por ejemplo, corresponder a una o más de la métrica de frecuencia de cambios, la métrica de importancia arquitectónica, la métrica de fragmentación de desarrolladores y
la métrica de actualidad de alteración como se ha descrito anteriormente.
Habitualmente, la determinación de la etapa 210 se puede realizar extrayendo el historial de control de versiones (compárese con el análisis del registro de historial de cambios de la etapa 105 de la figura 1). Se puede extraer información asociada con cada alteración (confirmación) previa de interés. Como se ha indicado anteriormente, tal información habitualmente puede incluir indicaciones del programador que realizó la alteración (un tipo de identificación de desarrollador), los archivos (un tipo o una parte) que se alteraron en la revisión y el tiempo (por ejemplo, una fecha) en el que tuvo lugar la alteración (un tipo de indicación de tiempo).
La métrica de frecuencia de cambios se puede ejemplificar mediante una medida de la tasa de cambio de código; una medida de con qué frecuencia se modifica un archivo de código fuente (una parte del código de software).
La métrica de fragmentación de desarrolladores se puede ejemplificar como una medida de cuántos desarrolladores diferentes han contribuido a un archivo de código fuente (una parte del código de software) y cómo de fragmentadas están sus contribuciones. Para determinar cómo de fragmentadas están las contribuciones, se puede calcular cualquier medida de fragmentación adecuada, por ejemplo, una basándose en la divulgación de M. d'Ambros, M. Lanza y H. Gall, "Fractal Fingers: Visualizing Development Effort for CVS Entities", 3rd IEEE International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT) 2005.
La métrica de importancia arquitectónica se puede ejemplificar como una medida de cómo de importante es el archivo (una parte del código de software) desde una perspectiva arquitectónica; por ejemplo, en términos del número de veces que se ha cambiado cualquier otro archivo junto con este archivo. El razonamiento subyacente a esta métrica es que aquellas partes que se alteran a menudo junto con otras partes deberían ser, habitualmente, fundamentales para el sistema de software.
La métrica de actualidad de alteración se puede ejemplificar mediante una cantidad de modificaciones recientes y/o una indicación del tiempo desde que tuvo lugar el último cambio significativo. En aplicaciones típicas, el tiempo se puede medir con una resolución de meses. Un cambio significativo puede, por ejemplo, definirse como una alteración cuando se añade o se modifica más de una única línea de código.
Habitualmente, al menos algunas de las métricas determinadas en las etapas 210 y 220 se normalizan (compárese con la etapa 140 de la figura 1), por ejemplo, a un valor entre 0 y 1, en donde 1 puede denotar la puntuación más alta (el código más complejo, el código con el mayor número de cambios, etc.). Por ejemplo, se pueden normalizar todas las métricas, excepto las métricas de actualidad de alteración, o se pueden normalizar todas las métricas. Si se normalizan las métricas de actualidad de alteración, un ejemplo es dejar que el valor 1 corresponda a la duración de tiempo más corta entre las partes desde que se hizo el cambio más reciente para esa parte y que el valor 0,01 corresponda al período de tiempo más largo entre las partes desde que se hizo el cambio más reciente para esa parte.
En la etapa 230, las métricas (posiblemente normalizadas) determinadas en las etapas 210 y 220 se ponderan (se ajustan a escala) basándose en las métricas de actualidad de alteración (compárese con la etapa 150 de la figura 1). En un ejemplo típico en el que se normalizan las métricas de actualidad de alteración, la etapa 230 puede comprender multiplicar las métricas de actualidad de alteración por cada una de las otras métricas de cada archivo.
En la etapa 240, las métricas para cada parte se combinan en un vector de características para cada parte (compárese con la etapa 170 de la figura 1). Por ejemplo, el vector puede contener valores normalizados de métrica de complejidad de código, métrica de frecuencia de cambios, métrica de fragmentación de desarrolladores y métrica de importancia arquitectónica.
Un algoritmo de agrupamiento se ejecuta en la etapa 250 (compárese con la etapa 180 de la figura 1) para agrupar partes por similitud de sus vectores de características. Por ejemplo, en esta etapa se puede usar un algoritmo de aprendizaje automático no supervisado para el agrupamiento, tal como un agrupamiento de k medias.
En la etapa 260, las agrupaciones (grupos) se seleccionan basándose en sus vectores de características (compárese con la etapa 190 de la figura 1). Por ejemplo, se pueden seleccionar agrupaciones con valores de métrica relativamente altos para cada uno de los elementos del vector de características. Esta selección se puede realizar según sea adecuado dependiendo de la importancia de las diferentes métricas. En algunas realizaciones, las agrupaciones se seleccionan de tal modo que alcancen la puntuación más alta en la mayoría de las dimensiones del vector en comparación con las otras agrupaciones.
Se puede ver que la(s) agrupación(es) seleccionadas denotan la(s) parte(s) más priorizada(s) del código de software (el/los archivo(s) de código fuente más priorizado(s)). La clasificación también se puede mantener entre agrupaciones seleccionadas, de tal modo que se puede ver que una (o algunas) de las agrupaciones seleccionadas denotan la(s) parte(s) priorizada(s) en primer lugar, se puede ver que una (o algunas) de las agrupaciones seleccionadas denotan la(s) parte(s) priorizada(s) en segundo lugar, y así sucesivamente. En la etapa 270, se genera una lista de partes candidatas para su alteración (compárese con las etapas 190 y 195 de la figura 1) basándose en la selección de la etapa 260.
La figura 3 ilustra esquemáticamente un ejemplo para tres partes diferentes de código de software de cómo se desarrollan a lo largo del tiempo las métricas de complejidad de código 301, 302, 303 correspondientes. A partir de esta información, se puede determinar una métrica de tendencia de complejidad de código (compárese con la etapa 130 de la figura 1). Por ejemplo, la métrica de tendencia de complejidad de código para la parte correspondiente a la complejidad de código 301 se puede determinar a través de la relación calculada dividiendo la diferencia (con signo) 304 en valores de métrica de complejidad de código por la duración de una ventana de tiempo 305, y de forma similar para 302 y 303. En algunas realizaciones, la métrica de tendencia de complejidad de código se puede establecer a 0 si la relación es menor que un valor umbral. Si la relación no es menor que el valor umbral, la métrica de tendencia de complejidad de código se puede establecer a 1, por ejemplo.
La figura 4 ilustra esquemáticamente una disposición de ejemplo de acuerdo con algunas realizaciones. La disposición de ejemplo puede, por ejemplo, estar comprendida en un nodo de control 400 y/o se puede configurar para provocar la ejecución de una o más de las etapas de método explicadas en relación con cualquiera de las figuras 1 y 2.
Por lo tanto, la disposición es para la clasificación de una pluralidad de partes de un código de software para la identificación de una o más partes candidatas del código de software para su alteración, en donde el código de software está asociado con un registro de historial de cambios indicativo de alteraciones previas de las partes del código de software y, en el presente caso, cada indicación de una alteración previa de una parte del código de software está asociada en el registro de historial de cambios con una indicación de tiempo.
El código de software y el registro de historial de cambios están comprendidos en una circuitería de almacenamiento a la que puede acceder la disposición, ilustrada en la figura 4 como las bases de datos 401,402, 403, 404. Se debería señalar que se puede usar cualquier circuitería de almacenamiento adecuada (bases de datos, circuitería de memoria, registros, etc.) con el fin de almacenar el código de software y el registro de historial de cambios. La circuitería de almacenamiento puede comprender más de una unidad de almacenamiento físico (posiblemente en diferentes dispositivos y/o en diferentes ubicaciones geográficas) o una única unidad de almacenamiento físico, y el código de software y el registro de historial de cambios pueden estar comprendidos en las mismas o diferentes unidades de almacenamiento. En la figura 4, el código de software se almacena de forma distribuida en las bases de datos 402, 403, 404 y el registro de historial de cambios se almacena en la base de datos 401.
La disposición comprende una circuitería de control (CNTR, por ejemplo, un controlador) 410 asociada con la circuitería de almacenamiento (es decir, la circuitería de control puede acceder a la circuitería de almacenamiento).
La circuitería de control 410 está configurada para provocar (para cada una de la pluralidad de partes del código de software) la determinación de una pluralidad de métricas constituyentes (que comprenden una métrica de complejidad de código y una métrica de frecuencia de cambios) de la parte del código de software mediante el análisis del registro de historial de cambios y el código de software, la determinación de una métrica de actualidad de alteración para la parte del código de software basándose en las indicaciones de tiempo del registro de historial de cambios, y el ajuste a escala de una o más de las métricas constituyentes basándose en la métrica de actualidad de alteración. Por ejemplo, las determinaciones se pueden realizar mediante una circuitería de determinación (por ejemplo, un determinador - DET) 411 y el ajuste a escala se puede realizar mediante una circuitería de ajuste a escala (por ejemplo, una unidad de ajuste a escala - SC) 412. La circuitería de determinación y/o la circuitería de ajuste a escala pueden estar comprendidas en la circuitería de control 410 como se ilustra en la figura 4, o la circuitería de determinación y/o la circuitería de ajuste a escala pueden estar asociadas de otro modo con la circuitería de control 410.
La circuitería de control 410 también está configurada para provocar la clasificación de la pluralidad de partes del código de software basándose en sus métricas constituyentes respectivas y la generación de una señal indicativa de las una o más partes candidatas del código de software basándose en la clasificación. Por ejemplo, la clasificación se puede realizar mediante una circuitería de clasificación (por ejemplo, un clasificador - RANK) 413 y la generación se puede realizar mediante una circuitería de generación de señales (por ejemplo, un generador de señales - SG) 420. La circuitería de clasificación puede estar comprendida en la circuitería de control 410 como se ilustra en la figura 4, o esta puede estar asociada de otro modo con la circuitería de control 410. De forma similar, la circuitería de generación de señales puede estar comprendida en la circuitería de control 410, o puede estar asociada de otro modo con la circuitería de control 410 como se ilustra en la figura 4. Como se ha ejemplificado anteriormente, la señal generada se puede usar como entrada a una interfaz de usuario (Ul) 430.
Por lo tanto, de acuerdo con algunas realizaciones, se proporciona un mecanismo para priorizar automáticamente los candidatos de refactorización en una base de código. Los candidatos de refactorización se pueden definir como partes de código fuente que son costosas de mantener.
Como se ha mencionado anteriormente, existen algunos otros enfoques que intentan resolver el problema de cómo priorizar entre partes de un código de software. Una limitación de los métodos basándose solo en la complejidad de código es que un fragmento de código no es necesariamente un problema únicamente debido a que es complejo. Desde la perspectiva del mantenimiento, este es un problema solo si necesita mucho trabajo y las métricas de complejidad de código no reflejan tales circunstancias.
En cambio, una PRC de acuerdo con algunas realizaciones proporciona una lista priorizada de archivos de código fuente que son los más costosos de mantener; por ejemplo, presentando riesgo de defectos y/o cuellos de botella en la productividad del equipo. Habitualmente, esta lista se puede determinar basándose en suposiciones de que es probable que partes del código de software sean un problema de mantenimiento si las mismas:
- tienen una complejidad alta,
- se modifican a menudo,
- son modificadas por muchos programadores diferentes,
- son significativas desde una perspectiva arquitectónica, y
- se ha trabajado en las mismas recientemente.
Una ventaja de la PRC de acuerdo con algunas realizaciones es que el algoritmo de aprendizaje automático no supervisado de la PRC no requiere entrenamiento y, por lo tanto, se generaliza a todas las bases de código. En lugar de dar un resultado absoluto, la PRC ofrece una priorización relativa dentro de una base de código ("En esta base de código, estos archivos son los más importantes a los que hay que atender").
Mediante la aplicación de métricas de tendencia de complejidad de código de acuerdo con algunas realizaciones como se ha ejemplificado anteriormente, es posible excluir archivos refactorizados recientemente de la lista priorizada. Si no se usan métricas de tendencia de complejidad de código, puede suceder que la PRC a veces entregue candidatos de refactorización como priorizados, incluso si los mismos se han refactorizado recientemente y ya no suponen un problema de mantenimiento. Este puede ser el caso si un archivo ha sido un problema históricamente y, por lo tanto, obtiene una puntuación alta en la mayoría de las métricas evolutivas. La aplicación de métricas de tendencia de complejidad de código se puede ver como la aplicación de un filtro que descarta - de la consideración como candidatos de refactorización - archivos que muestran una fuerte disminución en la complejidad de código.
Las realizaciones descritas y sus equivalentes se pueden materializar en software o hardware o una combinación de los mismos. Las realizaciones se pueden realizar mediante circuitería de propósito general. Los ejemplos de circuitería de propósito general incluyen procesadores de señales digitales (DSP), unidades de procesamiento central (CPU), unidades de coprocesador, matrices de puertas programables en campo (FPGA) y otro hardware programable. La circuitería de propósito general puede, por ejemplo, estar asociada con comprendida en un aparato tal como un nodo de control, tal como un nodo servidor.
Las realizaciones pueden aparecer dentro de un aparato electrónico que comprende disposiciones, circuitería y/o lógica de acuerdo con cualquiera de las realizaciones descritas en el presente documento. Como alternativa o adicionalmente, un aparato electrónico se puede configurar para realizar métodos de acuerdo con cualquiera de las realizaciones descritas en el presente documento.
De acuerdo con algunas realizaciones, un producto de programa informático comprende un medio legible por ordenador tal como, por ejemplo, una memoria de bus serie universal (USB), una tarjeta enchufable, una unidad integrada o una memoria de solo lectura (ROM). La figura 5 ilustra un medio legible por ordenador de ejemplo en forma de un disco compacto (CD)-ROM 500. El medio legible por ordenador tiene almacenado en el mismo un programa informático que comprende instrucciones de programa. El programa informático se puede cargar en un procesador de datos (PROC) 520, que puede, por ejemplo, estar comprendido en un aparato electrónico 510. Cuando se carga en la unidad de procesamiento de datos, el programa informático se puede almacenar en una memoria (MEM) 530 asociada con o comprendida en la unidad de procesamiento de datos. De acuerdo con algunas realizaciones, el programa informático puede, cuando se carga en y es ejecutado por la unidad de procesamiento de datos, provocar la ejecución de etapas de método de acuerdo con, por ejemplo, cualquiera de los métodos ilustrados en las figuras 1 a 2 o descritos de otro modo en el presente documento.
En el presente documento se ha hecho referencia a diversas realizaciones. Sin embargo, un experto en la materia reconocería numerosas variaciones a las realizaciones descritas que seguirían cayendo dentro del alcance de las reivindicaciones. Por ejemplo, las realizaciones de método descritas en el presente documento divulgan métodos de ejemplo a través de etapas que se realizan en un cierto orden. Sin embargo, se reconoce que estas secuencias de sucesos pueden tener lugar en otro orden sin apartarse del alcance de las reivindicaciones. Además, algunas etapas de método se pueden realizar en paralelo incluso si se han descrito como realizadas en secuencia.
De la misma forma, se debería señalar que, en la Descripción de realizaciones, no se pretende en modo alguno que la partición de bloques funcionales en unidades particulares sea limitante. Por el contrario, estas particiones son meramente ejemplos. Los bloques funcionales descritos en el presente documento como una unidad se pueden dividir en dos o más unidades. Además, los bloques funcionales descritos en el presente documento como implementados como dos o más unidades se pueden fusionar en menos unidades (por ejemplo, una única unidad).
Por lo tanto, se debería entender que los detalles de las realizaciones descritas son meramente ejemplos presentados con fines ilustrativos, y que se pretende que todas las variaciones que caigan dentro del alcance de las reivindicaciones se engloben en las mismas.
Claims (10)
1. Un método (100, 200) para clasificar una pluralidad de partes de un código de software para la identificación de una o más partes candidatas del código de software para su alteración,
en donde el código de software está asociado con un registro de historial de cambios indicativo de alteraciones previas de las partes del código de software, estando, cada indicación de una alteración previa de una parte del código de software, asociada en el registro de historial de cambios con una indicación de tiempo, y
en donde el código de software y el registro de historial de cambios están comprendidos en una circuitería de almacenamiento, comprendiendo el método:
para cada una de la pluralidad de partes del código de software, determinar (110, 210, 220) una pluralidad de métricas constituyentes de la parte del código de software analizando el registro de historial de cambios y el código de software, comprendiendo la pluralidad de métricas constituyentes:
- una métrica de complejidad de código de la parte del código de software derivada basándose en el código de software; y
- una métrica de frecuencia de cambios de la parte del código de software determinada usando las indicaciones de tiempo del registro de historial de cambios para calcular cuántas alteraciones ha experimentado la parte por unidad de tiempo, en donde el cálculo se basa en un número de alteraciones en una primera ventana de tiempo que excluye las alteraciones que son más antiguas que un tiempo de rastreo máximo;
para cada una de la pluralidad de partes del código de software, determinar (120, 210) una métrica de actualidad de alteración para la parte del código de software usando las indicaciones de tiempo del registro de historial de cambios para determinar cuánto tiempo hace que tuvo lugar la alteración más reciente de la parte y/o para calcular cuántas alteraciones ha experimentado la parte por unidad de tiempo en una segunda ventana de tiempo que excluye las alteraciones que son más antiguas que un tiempo de rastreo de actualidad que es más reciente que el tiempo de rastreo máximo;
para cada una de la pluralidad de partes del código de software, ajustar a escala (150, 230) una o más de las métricas constituyentes basándose en la métrica de actualidad de alteración;
clasificar (190, 260) la pluralidad de partes del código de software basándose en sus métricas constituyentes respectivas; y
generar (195, 270) una señal indicativa de las una o más partes candidatas del código de software basándose en la clasificación.
2. El método de la reivindicación 1, en donde la pluralidad de métricas constituyentes comprende además una o más de:
- una métrica de importancia arquitectónica de la parte del código de software determinada basándose en el registro de historial de cambios; y
- una métrica de fragmentación de desarrolladores de la parte del código de software determinada basándose en identidades de desarrollador del registro de historial de cambios asociadas con indicaciones respectivas de alteraciones previas del código de software.
3. El método de cualquiera de las reivindicaciones 1 a 2, que comprende además normalizar (140) cada una de las métricas constituyentes antes de la etapa de clasificar la pluralidad de partes del código de software.
4. El método de cualquiera de las reivindicaciones 1 a 3, que comprende además:
determinar (130) una métrica de tendencia de complejidad de código para cada una de la pluralidad de partes del código de software; y
ajustar a escala (160) una o más de las métricas constituyentes basándose en la métrica de tendencia de complejidad de código antes de la etapa de clasificar la pluralidad de partes del código de software.
5. El método de cualquiera de las reivindicaciones 1 a 4, que comprende además, antes de la etapa de clasificación:
agrupar (180, 250) las partes del código de software en una pluralidad de grupos basándose en las métricas constituyentes respectivas de cada una de las partes del código de software; y
para cada uno de los grupos, determinar una métrica de grupo basándose en las métricas constituyentes respectivas de cada una de las partes del código de software del grupo,
en donde clasificar la pluralidad de partes del código de software basándose en sus métricas constituyentes respectivas comprende clasificar la pluralidad de grupos basándose en su métrica de grupo respectiva.
6. El método de cualquiera de las reivindicaciones 1 a 5, que comprende además, para cada una de la pluralidad de partes del código de software, determinar (170, 240) una métrica combinada basándose en la pluralidad de métricas
constituyentes, y en donde clasificar la pluralidad de partes del código de software basándose en sus métricas constituyentes respectivas comprende clasificar la pluralidad de partes del código de software basándose en sus métricas combinadas respectivas.
7. Un producto de programa informático que comprende un programa informático que se puede cargar en una unidad de procesamiento de datos y configurado para provocar la ejecución del método de acuerdo con cualquiera de las reivindicaciones 1 a 6 cuando el programa informático es ejecutado por la unidad de procesamiento de datos.
8. El producto de programa informático de acuerdo con la reivindicación 7, que comprende un medio legible por ordenador no transitorio (500), que tiene en el mismo el programa informático.
9. Un aparato para la clasificación de una pluralidad de partes de un código de software para la identificación de una o más partes candidatas del código de software para su alteración,
en donde el código de software está asociado con un registro de historial de cambios indicativo de alteraciones previas de las partes del código de software, estando, cada indicación de una alteración previa de una parte del código de software, asociada en el registro de historial de cambios con una indicación de tiempo, y
en donde el código de software y el registro de historial de cambios están comprendidos en una circuitería de almacenamiento (401, 402, 403, 404),
comprendiendo la disposición una circuitería de control (410) asociada con la circuitería de almacenamiento y configurada para provocar:
para cada una de la pluralidad de partes del código de software, la determinación de una pluralidad de métricas constituyentes de la parte del código de software mediante el análisis del registro de historial de cambios y el código de software, comprendiendo la pluralidad de métricas constituyentes:
- una métrica de complejidad de código de la parte del código de software derivada basándose en el código de software;
- una métrica de frecuencia de cambios de la parte del código de software determinada usando las indicaciones de tiempo del registro de historial de cambios para calcular cuántas alteraciones ha experimentado la parte por unidad de tiempo, en donde el cálculo se basa en un número de alteraciones en una primera ventana de tiempo que excluye las alteraciones que son más antiguas que un tiempo de rastreo máximo;
para cada una de la pluralidad de partes del código de software, la determinación de una métrica de actualidad de alteración para la parte del código de software usando las indicaciones de tiempo del registro de historial de cambios para determinar cuánto tiempo hace que tuvo lugar la alteración más reciente de la parte y/o para calcular cuántas alteraciones ha experimentado la parte por unidad de tiempo en una segunda ventana de tiempo que excluye las alteraciones que son más antiguas que un tiempo de rastreo de actualidad que es más reciente que el tiempo de rastreo máximo;
para cada una de la pluralidad de partes del código de software, el ajuste a escala de una o más de las métricas constituyentes basándose en la métrica de actualidad de alteración;
la clasificación de la pluralidad de partes del código de software basándose en sus métricas constituyentes respectivas; y
la generación de una señal indicativa de las una o más partes candidatas del código de software basándose en la clasificación.
10. El aparato de acuerdo con la reivindicación 9, estando comprendido dicho aparato en un nodo servidor (400).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| SE1751166A SE1751166A1 (en) | 2017-09-20 | 2017-09-20 | Ranking of software code parts |
| PCT/EP2018/075181 WO2019057700A1 (en) | 2017-09-20 | 2018-09-18 | CLASSIFICATION OF SOFTWARE CODE PARTS |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2923100T3 true ES2923100T3 (es) | 2022-09-23 |
Family
ID=63685952
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES18778845T Active ES2923100T3 (es) | 2017-09-20 | 2018-09-18 | Clasificación de partes de código de software |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US11487535B2 (es) |
| EP (1) | EP3685258B1 (es) |
| DK (1) | DK3685258T3 (es) |
| ES (1) | ES2923100T3 (es) |
| PL (1) | PL3685258T3 (es) |
| PT (1) | PT3685258T (es) |
| SE (1) | SE1751166A1 (es) |
| WO (1) | WO2019057700A1 (es) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11531536B2 (en) * | 2019-11-20 | 2022-12-20 | Red Hat, Inc. | Analyzing performance impacts of source code changes |
| US11363109B2 (en) * | 2020-03-23 | 2022-06-14 | Dell Products L.P. | Autonomous intelligent system for feature enhancement and improvement prioritization |
| US11269625B1 (en) * | 2020-10-20 | 2022-03-08 | International Business Machines Corporation | Method and system to identify and prioritize re-factoring to improve micro-service identification |
| US11392375B1 (en) | 2021-02-18 | 2022-07-19 | Bank Of America Corporation | Optimizing software codebases using advanced code complexity metrics |
| US20220300884A1 (en) * | 2021-03-16 | 2022-09-22 | Hcl Technologies Limited | Method and system for evaluating performance of developers using artificial intelligence (ai) |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8713513B2 (en) * | 2006-12-13 | 2014-04-29 | Infosys Limited | Evaluating programmer efficiency in maintaining software systems |
| US9378015B2 (en) * | 2009-08-11 | 2016-06-28 | Microsoft Technology Licensing, Llc | Predicting defects in code |
| US9304760B2 (en) * | 2012-11-12 | 2016-04-05 | International Business Machines Corporation | Identifying software code experts |
| US8924932B2 (en) * | 2013-04-11 | 2014-12-30 | International Business Machines Corporation | Using stack data and source code to rank program changes |
| US20150370685A1 (en) * | 2014-06-24 | 2015-12-24 | Juergen Heymann | Defect localization in software integration tests |
| WO2016190876A1 (en) * | 2015-05-28 | 2016-12-01 | Hewlett Packard Enterprise Development Lp | Dependency rank based on commit history |
| US10866804B2 (en) * | 2016-01-27 | 2020-12-15 | Micro Focus Llc | Recommendations based on the impact of code changes |
-
2017
- 2017-09-20 SE SE1751166A patent/SE1751166A1/en not_active Application Discontinuation
-
2018
- 2018-09-18 ES ES18778845T patent/ES2923100T3/es active Active
- 2018-09-18 PL PL18778845.0T patent/PL3685258T3/pl unknown
- 2018-09-18 US US16/648,898 patent/US11487535B2/en active Active
- 2018-09-18 DK DK18778845.0T patent/DK3685258T3/da active
- 2018-09-18 PT PT187788450T patent/PT3685258T/pt unknown
- 2018-09-18 EP EP18778845.0A patent/EP3685258B1/en active Active
- 2018-09-18 WO PCT/EP2018/075181 patent/WO2019057700A1/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| US11487535B2 (en) | 2022-11-01 |
| PL3685258T3 (pl) | 2022-09-12 |
| WO2019057700A1 (en) | 2019-03-28 |
| DK3685258T3 (da) | 2022-07-11 |
| SE1751166A1 (en) | 2019-03-21 |
| EP3685258B1 (en) | 2022-05-04 |
| EP3685258A1 (en) | 2020-07-29 |
| PT3685258T (pt) | 2022-07-08 |
| US20200249941A1 (en) | 2020-08-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2923100T3 (es) | Clasificación de partes de código de software | |
| US10032114B2 (en) | Predicting application performance on hardware accelerators | |
| US10705795B2 (en) | Duplicate and similar bug report detection and retrieval using neural networks | |
| Panichella et al. | Would static analysis tools help developers with code reviews? | |
| US20150370685A1 (en) | Defect localization in software integration tests | |
| US11200377B2 (en) | Cluster model to predict build failure | |
| Alrubaye et al. | On the use of information retrieval to automate the detection of third-party java library migration at the method level | |
| Maplesden et al. | Performance analysis for object-oriented software: A systematic mapping | |
| US9389852B2 (en) | Technique for plagiarism detection in program source code files based on design pattern | |
| JP2019021303A (ja) | ソフトウェアプログラムフォールト位置特定 | |
| Feng et al. | Hierarchical abstraction of execution traces for program comprehension | |
| CN109344017A (zh) | 一种基于机器学习预测内存故障的方法，设备及可读存储介质 | |
| US10311404B1 (en) | Software product development defect and issue prediction and diagnosis | |
| CN105765561B (zh) | 根据跟踪数据的生产对比开发使用的确定 | |
| US9176732B2 (en) | Method and apparatus for minimum cost cycle removal from a directed graph | |
| Roth et al. | Automated characterization of parallel application communication patterns | |
| US9619364B2 (en) | Grouping and analysis of data access hazard reports | |
| JP2015219906A (ja) | ソフトウェア確認方法およびプロセッサ | |
| KR102490539B1 (ko) | 딥러닝을 위한 가속기용 프로그램 생성 방법 | |
| Prats et al. | Automatic generation of workload profiles using unsupervised learning pipelines | |
| US9703547B2 (en) | Computing program equivalence based on a hierarchy of program semantics and related canonical representations | |
| US20220326915A1 (en) | Method for generating program for use in accelerator for deep learning | |
| US10528691B1 (en) | Method and system for automated selection of a subset of plurality of validation tests | |
| JP6665576B2 (ja) | 支援装置、支援方法及びプログラム | |
| Silva et al. | Predicting Prime Path Coverage Using Regression Analysis |