Métricas del código de software. Métricas principales

En este artículo quiero analizar algunas de las métricas de control de calidad más importantes en mi opinión. Estos serán indicadores, coeficientes e indicadores que le permitirán captar una imagen general de lo que está sucediendo en el proyecto en términos de calidad y determinar los pasos para mejorarlo. Las métricas cubrirán cinco áreas diferentes: requisitos, calidad del software, efectividad del equipo de pruebas, calidad del trabajo de control de calidad y retroalimentación. Es importante medir y rastrear indicadores simultáneamente en varias secciones del proceso de desarrollo de software para detectar problemas comunes y raíz y poder configurar y optimizar todo el proceso.

Grupo 1 - Requisitos para el software que se está desarrollando

Este grupo de métricas nos permitirá evaluar qué tan bien hemos elaborado los requisitos (historia de usuario) del software, identificar vulnerabilidades y las características de software más complejas y potencialmente problemáticas, y comprender dónde se requiere un control especial:

1. Requisitos de cobertura de la prueba

En otras palabras, este es el número de pruebas por requisito.

Propósito de la métrica: identificar debilidades en la cobertura de las pruebas y resaltar los riesgos.

• Por supuesto, esta métrica sólo funcionará si los requisitos están bien descompuestos y son más o menos equivalentes. Por supuesto, esto no siempre es posible, pero si puede hacer que los requisitos sean lo suficientemente atómicos, esta métrica mostrará la desviación de la cobertura de cada requisito del nivel promedio. Cuanto más difiere el valor de 1, se escriben menos o más pruebas de lo habitual para un requisito.
• Lo más importante a lo que hay que prestar atención son los requisitos para los cuales el coeficiente será igual o cercano a 0. Para estos, es necesario considerar agregar pruebas.
• Si los requisitos no son atómicos, entonces esta métrica solo garantizará que haya al menos una prueba para cada requisito. Para ello el coeficiente siempre debe ser mayor que 0.

2. Grado de interconexión de los requisitos

La métrica se calcula como el número promedio de conexiones de cada requisito con otros requisitos.

Propósito de la métrica: Proporcionar una base para evaluar el momento de las pruebas y tener en cuenta los posibles riesgos. Conociendo el grado de influencia mutua de los requisitos entre sí, puede, por ejemplo, planificar tiempo y casos adicionales para pruebas de un extremo a otro, trabajar en comprobaciones de regresión, mirar hacia la integración, etc.

• El valor de esta métrica oscilará entre 0 y 1. 1 significa que cada requisito está relacionado con cada uno y 0 significa que no existe relación.
• Es difícil introducir restricciones sobre los valores de este coeficiente; mucho depende de las características específicas de la funcionalidad, la arquitectura y las tecnologías. Sin embargo, por mi propia experiencia puedo decir que es bueno cuando el grado de conectividad no supera los 0,2-0,3. De lo contrario, la modificación en el marco de uno de los requisitos dará lugar a una cadena de cambios y, por tanto, a posibles errores en una parte importante del producto.

3. Factor de estabilidad de requisitos

Propósito de la métrica: muestre cuántos requisitos ya implementados deben rehacerse de una versión a otra al desarrollar nuevas funciones.

• Por supuesto, no existe una funcionalidad completamente aislada, pero el número de requisitos nuevos debe prevalecer sobre los cambiantes y el coeficiente debe ser preferiblemente inferior a 0,5. En este caso, introducimos el doble de funciones nuevas que reelaboramos las existentes.
• Si el coeficiente es superior a 0,5, especialmente si es superior a 1, lo más probable es que esto signifique que anteriormente hicimos algo que resultó innecesario. El equipo no se centra en crear nuevos valores comerciales, sino en reelaborar funciones lanzadas anteriormente.
• La métrica también da una idea de la facilidad con la que se puede escalar la funcionalidad del sistema y agregar nuevas funciones.

Grupo 2 - Calidad del producto que se desarrolla

Como sugiere el nombre, este grupo de métricas demuestra la calidad del software, así como la calidad del desarrollo en sí.

1. Densidad de defectos

Se calcula el porcentaje de defectos por módulo individual durante una iteración o lanzamiento.

Propósito de la métrica: resalte qué parte del software es la más problemática. Esta información ayudará a evaluar y planificar el trabajo con este módulo, así como en el análisis de riesgos.

• Las razones de una gran cantidad de defectos en cualquier módulo específico (coeficiente superior a 0,3) pueden ser diferentes: requisitos de calidad deficientes, calificaciones de los desarrolladores, complejidad técnica, etc. En cualquier caso, esta métrica llamará inmediatamente nuestra atención sobre el área del problema.

2. Coeficiente de regresión

Propósito de la métrica: muestre hacia dónde van los esfuerzos del equipo: ¿estamos más involucrados en la creación y depuración de nuevas funciones o nos vemos obligados a parchear partes existentes del software la mayor parte del tiempo?

• Cuanto más cerca esté el coeficiente de 0, menos errores se introdujeron en la funcionalidad existente al implementar nuevos requisitos. Si el valor es superior a 0,5, dedicamos más de la mitad del tiempo a restaurar funciones del software que funcionaban anteriormente.

3. Tasa de defectos reabiertos

Propósito de la métrica: evaluar la calidad del desarrollo y la corrección de defectos, así como la complejidad del producto o módulo individual

• Esta métrica se puede calcular para todo el software, módulo individual o funcionalidad. Cuanto más cercano a 0 esté el valor resultante, menos errores antiguos se repetirán durante el desarrollo.
• Si el coeficiente resulta ser superior a 0,2-0,3, esto puede indicar la complejidad técnica del módulo y los requisitos altamente relacionados que contiene, o una arquitectura torpe, o que la solución anterior se realizó mal.

4. Costo promedio de arreglar un defecto

La relación entre el monto de los costos incurridos por el equipo al trabajar con todos los defectos (por ejemplo, como parte de una versión) y el número total de defectos.

Propósito de la métrica: muestran lo caro que nos resulta detectar y corregir cada defecto. Esto permitirá calcular los beneficios de reducir el número de errores cometidos y evaluar la viabilidad de las técnicas adecuadas.

• Por supuesto, aquí no existen valores correctos; todo estará determinado por las características específicas de una situación particular;

5. Número de defectos en el código de un desarrollador específico

Propósito de la métrica: resaltar posibles dificultades en el equipo de desarrollo, qué especialistas carecen de experiencia, conocimiento o tiempo y necesitan ayuda.

• Si, por ejemplo, el 50% de todos los defectos son causados ​​por 1 desarrollador y hay 5 de ellos en el equipo, entonces claramente hay un problema. Esto no significa que este programador no funcione bien, pero indica que es imperativo comprender las razones de esta situación.
• La métrica, entre otras cosas, puede ser un indicador de un módulo/funcional/sistema particularmente difícil de desarrollar y soportar.

Grupo 3: Capacidad y eficacia del equipo de control de calidad

El objetivo principal de este grupo de métricas es expresar en números de lo que es capaz el equipo de pruebas. Estos indicadores se pueden calcular y comparar periódicamente, se pueden analizar tendencias y se puede observar cómo el trabajo del equipo se ve afectado por ciertos cambios.

1. Velocidad del equipo de control de calidad

Se calcula como la relación entre los puntos de la historia implementados (o requisitos, o historias de usuarios) en varias, por ejemplo, 4-5 iteraciones (Sprint) con respecto al número de iteraciones seleccionadas.

Propósito de la métrica: Expresar numéricamente las capacidades y la velocidad del trabajo del equipo para una mayor planificación del alcance del trabajo y el análisis de las tendencias de desarrollo.

• La métrica le permite monitorear la velocidad del trabajo de control de calidad y observar qué procesos internos o influencias externas en el equipo pueden afectar esta velocidad.

2. Vida media de los defectos

El tiempo total durante el cual los defectos encontrados dentro de una iteración o versión estuvieron abiertos a la suma de defectos.

Propósito de la métrica: muestra cuánto tiempo se tarda en promedio en trabajar con un defecto: registrarlo, corregirlo y reproducirlo. Este indicador le permitirá estimar el tiempo necesario para las pruebas y resaltar las áreas del software con las que surgen las mayores dificultades.

• Normalmente, la vida útil de un defecto es el tiempo completo desde su creación (estado Creado) hasta su cierre (Cerrado), menos todos los posibles Pospuestos y Retenidos. Cualquier rastreador de errores le permite calcular y cargar esta información para un sprint o lanzamiento por separado.
• Además, la vida media de un defecto se puede calcular para varios módulos y funciones de software o, lo que es más interesante, por separado para cada uno de los evaluadores y desarrolladores del equipo. Esto le brinda la oportunidad de identificar módulos particularmente complejos o un eslabón débil en el equipo de software.

Grupo 4 - Calidad del trabajo del equipo de pruebas.

El propósito de este conjunto de métricas es evaluar qué tan bien los evaluadores realizan sus tareas y determinar el nivel de competencias y madurez del equipo de control de calidad. Al tener este conjunto de indicadores, puede comparar el equipo consigo mismo en diferentes momentos o con otros grupos de prueba externos.

1. Eficiencia de las pruebas y casos de prueba.

Propósito de la métrica: muestre cuántos errores en promedio nuestros casos pueden detectar. Esta métrica refleja la calidad del diseño de la prueba y ayuda a monitorear la tendencia de sus cambios.

• Es mejor calcular esta métrica para todos los conjuntos de pruebas: para grupos separados de pruebas funcionales, conjuntos de regresión, pruebas de humo, etc.
• Este indicador de "letalidad" de las pruebas permite monitorear la efectividad de cada uno de los kits, cómo cambia con el tiempo y complementarlos con pruebas "nuevas".

2. Tasa de errores omitidos por producción

Número de errores descubiertos después del lanzamiento \ número total de errores en el software descubiertos durante las pruebas y después del lanzamiento

Propósito de la métrica: demostrar la calidad de las pruebas y la eficiencia de la detección de errores: qué proporción de defectos se filtraron y qué proporción pasó a producción.

• El porcentaje aceptable de errores que se omitieron en la producción dependerá, por supuesto, de muchos factores. Sin embargo, si el coeficiente es >0,1, esto es malo. Esto significa que durante las pruebas no se detectó uno de cada diez defectos y provocó problemas en el software ya distribuido a los usuarios.

3. Tiempo real dedicado por el equipo de control de calidad

La relación entre el tiempo dedicado por el equipo directamente a las actividades de control de calidad y el número total de horas.

Propósito de la métrica: en primer lugar, aumentar la precisión de la planificación y, en segundo lugar, monitorear y gestionar el desempeño de un equipo en particular.

• Las actividades objetivo incluyen análisis, diseño, evaluaciones, pruebas, reuniones de trabajo y mucho más. Los posibles efectos secundarios son tiempo de inactividad debido a bloqueadores, problemas de comunicación, falta de disponibilidad de recursos, etc.
• Naturalmente, este coeficiente nunca será igual a 1. La práctica muestra que para equipos efectivos puede ser 0,5-0,6.

4. Precisión de la estimación del tiempo por área\tipos\tipos de trabajo

Propósito de la métrica: permite el uso de un factor de corrección para evaluaciones posteriores.

• El grado de precisión de la evaluación se puede determinar para todo el equipo o para los evaluadores individuales, para todo el sistema o para módulos de software individuales.

5. Proporción de defectos no confirmados (rechazados)

Propósito de la métrica: muestre cuántos defectos se crearon "inactivamente".

• Si el porcentaje de defectos rechazados supera el 20%, entonces el equipo puede experimentar una desincronización al comprender qué es un defecto y qué no.

Grupo 5 - Comentarios y satisfacción del usuario

Y finalmente, un grupo de métricas que muestran cómo el producto fue aceptado por los usuarios finales, qué tan bien cumplió con sus expectativas. Pero no sólo la retroalimentación del software es importante: otra tarea importante de este grupo de métricas es mostrar si los usuarios están satisfechos con el proceso de interacción con el equipo de TI en general y con el control de calidad en particular.

1. Satisfacción del usuario con los servicios de TI

Encuesta periódica de satisfacción de los usuarios con los servicios TI con puntuación.

Propósito de la métrica: mostrar si los usuarios confían en el equipo de TI, si entienden cómo y por qué está organizado su trabajo y en qué medida este trabajo cumple con las expectativas.

• La métrica puede servir como indicador de que es necesario centrarse en optimizar el proceso o hacerlo más claro y transparente para los usuarios.
• El indicador de satisfacción se puede calcular en función de los resultados de una encuesta posterior al lanzamiento. Recopilamos todas las calificaciones y calculamos la puntuación media. Esta puntuación se puede volver a calcular después de realizar cambios en el proceso.

2. Satisfacción del usuario con el producto

Encuesta periódica a los usuarios sobre su grado de satisfacción con el producto.

Propósito de la métrica: determinar qué tan bien el producto que se está desarrollando cumple con las expectativas del usuario, si nos estamos moviendo en la dirección correcta, si determinamos correctamente la importancia de las características y elegimos las opciones de solución.

• Para calcular esta métrica, también realizamos una encuesta a los usuarios y calculamos la puntuación media. Al calcular este indicador periódicamente (por ejemplo, después de cada lanzamiento), puede monitorear la tendencia en la satisfacción del usuario.

3. Participación de las partes interesadas

Número de iniciativas y propuestas para mejorar el proceso y producto recibidas durante la iteración (lanzamiento) de las partes interesadas

Propósito de la métrica: determinar el grado de participación de las partes interesadas externas en el trabajo sobre el producto. Teniendo esa métrica a mano, puedes navegar hacia donde necesitas obtener retroalimentación para que algún día no enfrentes desprecio y odio, problemas y malentendidos.

Métrica Es una escala y un método cuantitativos que se pueden utilizar para medir.

Nos gustaría agregar que la introducción y el uso de métricas es necesario para mejorar el control sobre el proceso de desarrollo y, en particular, sobre el proceso de prueba, que consideraremos más adelante.

El propósito del control de pruebas es obtener retroalimentación y visualizar el proceso de prueba..

La información necesaria para el control se recopila (tanto manual como automáticamente) y se utiliza para evaluar el estado y tomar decisiones como la cobertura (por ejemplo, cobertura de requisitos o código con pruebas) o criterios de salida (por ejemplo, criterios de finalización de pruebas).

Las métricas también se pueden utilizar para evaluar el progreso del trabajo planificado y la implementación del presupuesto.

1. Crear, usar y analizar métricas.
2. En nuestra opinión, para mayor claridad, tiene sentido agrupar las métricas por tipos de entidades involucradas en el aseguramiento de la calidad y las pruebas de software, a saber:
3. Métricas por casos de prueba

Métricas para errores/defectos

Métricas por tarea

Echemos un vistazo más de cerca a cada uno de ellos:

Métricas para casos de prueba

Métricas de errores

Nos gustaría señalar que las métricas "Errores abiertos/cerrados", "Errores por gravedad" y "Errores por prioridad" visualizan claramente el grado en que el producto se acerca al logro de los criterios de calidad para errores. Al tener requisitos para la cantidad de errores abiertos, después de cada iteración de prueba los comparamos con datos reales, viendo así los lugares donde debemos mejorar para lograr el objetivo lo más rápido posible.:
Digamos que tenemos una situación en la que la cantidad de errores reabiertos después de corregirlos no disminuye o incluso aumenta. Esta es una señal de que es necesario analizar las causas, porque Una situación similar puede mostrar que:

1. Solución de mala calidad al problema (corrección de errores)

Segundo ejemplo mostrará por qué se necesita la métrica "Errores rechazados/abiertos":
Observamos que el porcentaje de errores rechazados es muy alto. Esto podría significar:

1. Los requisitos funcionales se pueden interpretar de diferentes maneras.
2. El evaluador no describió con precisión el problema.
3. El desarrollador no quiere corregir el error que cometió o no cree que en realidad sea un error. (Este problema es consecuencia directa del segundo, que surgió debido a una descripción inexacta)

Todos estos problemas desestabilizan significativamente la situación del proyecto. Por ello, cuando surjan, se recomienda mantener una breve conversación con los líderes del equipo del proyecto para posteriormente reducir el número de defectos redescubiertos y rechazados.

Métricas por casos de prueba

Nombre	Descripción
Tareas de implementación	La métrica muestra el número y los resultados de las instalaciones de aplicaciones. El procedimiento para instalar la aplicación se describió en el artículo Procedimiento para instalar una nueva versión de software (Deployment WorkFlow). Si el número de versiones rechazadas por el equipo de pruebas es críticamente alto, se recomienda analizar e identificar urgentemente los motivos, así como resolver el problema existente lo antes posible.
Tareas aún abiertas	La métrica muestra la cantidad de problemas aún abiertos. Al final del proyecto, todas las tareas deben estar completadas. Por tareas nos referimos a los siguientes tipos de trabajo: redacción de documentación (arquitectura, requisitos, planos), implementación de nuevos módulos o cambio de los existentes en función de solicitudes de cambio, trabajos de montaje de stands, estudios diversos y mucho más.

Las métricas para las tareas pueden ser diferentes, solo hemos proporcionado dos de ellas. La métrica del tiempo de finalización de tareas y muchas otras también pueden resultar interesantes.

En conclusión, nos gustaría señalar que la presencia de las métricas y gráficos necesarios que reflejen los cambios en el estado del proyecto a lo largo del tiempo permitirá mejorar no solo el proceso de prueba, sino también el desarrollo en su conjunto, y también Facilitar el procedimiento de análisis del proyecto terminado, lo que le permitirá prevenir futuros errores en el futuro.

Saludos amigos. Después de una larga etapa de desarrollo y pruebas beta aún más largas, el nuevo Yandex Metrica 2.0 está emergiendo de las sombras. A partir del 22 de junio se convertirá en la principal herramienta para recopilar y analizar estadísticas, mientras que la versión anterior se transferirá al subdominio old.metrika.yandex.ru, donde vivirá sus últimos meses.

Estoy encantado con Yandex Metrika Beta, aunque me llevó algún tiempo profundizar en él y comprender sus capacidades. Pero vale la pena: al menos encontré algunas cosas que ni la versión actual ni Analytics pueden hacer.

En realidad, en este material intentaré analizar el proceso de trabajo para usted, redactar instrucciones para análisis web en el nuevo Yandex Metrica, ya que es algo diferente de su predecesor y puede causar disonancia cognitiva en el primer contacto.

- Así que mira la métrica beta.
- No quiero, le tengo miedo.

Conversación con un especialista en SEO conocido.

Entonces primero la parte conceptual. ¿Cuál es la principal diferencia? Old Metrica es principalmente un conjunto de sectores (informes) ya preparados para su análisis. Configurarlos y crear tus propios sectores es difícil e inconveniente. Por eso, para muchos, este proceso consiste únicamente en trabajar con “Objetivos”, que, afortunadamente, están destinados a algo completamente diferente, y los “Informes” quedan en algún lugar por ahí, en un estante polvoriento, fuera de los corchetes.

La actual ya es una plastilina completa que le permite personalizar absolutamente cualquier sección según sus necesidades, configurar los datos iniciales, filtrar lo innecesario y seleccionar una opción conveniente para la presentación de datos. Personalice completamente su espacio de trabajo, lo cual es especialmente apreciado por los especialistas en marketing de Internet.

Y ahora en orden

Por el momento, la versión beta todavía se encuentra en https://beta.metrika.yandex.ru/ y la vista de la lista de sitios no ha sufrido cambios fundamentales, con la excepción de algunas adiciones y el porcentaje mostrado de crecimiento relativo del tráfico. al día anterior, que ahora con tanto cuidado han eliminado de la versión antigua (dicen, vamos, sigue adelante, acostúmbrate).

El nuevo sistema de etiquetas y el panel de acceso rápido son muy convenientes. Le permite crear varias etiquetas en el panel de definición de etiquetas y asignar una o más de ellas a cada sitio (de hecho, incluirlas en grupos de estas etiquetas). Luego, al seleccionar la opción del mismo nombre en el panel de definición de etiquetas, muestra los grupos a los que accedes con más frecuencia en el panel de acceso rápido. Además, al visualizar uno de los grupos, se presentarán estadísticas resumidas de tráfico de los sitios incluidos en él.

Pero una vez que pasas a un mostrador separado, puedes empezar a perderte. Miremos la interfaz.

Menú de la nueva interfaz Yandex Metrika

Los elementos del menú superior no necesitan presentación, pero sí la estructura y algunos elementos del menú de la izquierda. Primero que nada, lo que sabemos:

• Resumen: la página principal del contador del sitio.
• Mapas: mapas de clics, desplazamiento, enlaces y análisis de formularios. En general, la mayoría del contenido del elemento "Comportamiento" es la versión anterior.
• Configuración: en realidad, la configuración del contador actual de Yandex Metrica.

Pero el último elemento, "Informes", es la piedra angular de la herramienta actualizada.

• Mis informes son todos los sectores que creó y guardó.
• Los elegidos son lo mismo, solo los elegidos (despierta, Neo).
• Informes estándar: aquí es donde se encuentran todas las secciones antiguas y dolorosamente familiares. Volveremos a ellos más adelante en el material.

Interfaz de la página principal del contador

El creador de páginas de inicio es similar al del antiguo Yandex Metrica, pero, a diferencia de este último, es más ergonómico y tiene un impresionante conjunto de widgets listos para usar. Bueno, aquí también se hace sentir la flexibilidad de configuración de segmentos inherente a la nueva versión.

Puede seleccionar un widget ya preparado de la biblioteca o crear uno nuevo: una métrica, un gráfico circular, un gráfico o una tabla de datos. Personalice una porción de la información que se muestra en ellos y fíjela en la parte deseada de la pantalla de resumen usando un simple botón de colocar.

Trabajar con segmentos en Yandex Metrica

Entonces, llegamos a lo principal: una descripción del esquema de generación de informes. En primer lugar nos dirigimos a los informes estándar mencionados anteriormente (“Informes” - “Informe Estándar”) y seleccionamos la información que luego segmentaremos. Por ejemplo, "Fuentes" - "Fuentes, resumen".

Y ahora comenzamos a seleccionar sólo aquellas visitas que queremos analizar. Por ejemplo, queremos saber la cantidad de personas que visitaron el sitio desde una tableta desde el motor de búsqueda Yandex para una consulta que incluía la palabra "SEO". Para ello, configuramos tres niveles de segmentación:

• “Segmento” - “Tecnologías” - “Dispositivos” - en la ventana de opciones que se abre, seleccione “Tabletas”.
• "Segmento" - "Fuentes" - "Última fuente" - "Buscar" - "Motor de búsqueda" - en la ventana de opciones que se abre, seleccione "Yandex".
• “Segmento” - “Fuentes” - “Última fuente” - “Buscar” - “Frase de búsqueda” - en la ventana que se abre, ingrese *SEO* (los operadores de asterisco indican cualquier conjunto de caracteres en ambos lados de esta palabra).

Total: los gráficos y la tabla con la información quedarán reordenados como necesitemos, listos para su descarga o análisis. Sobre la marcha, puede cambiar, eliminar o agregar nuevos niveles de refinamiento; la información mostrada se actualizará sobre la marcha.

Aquí podemos comparar el segmento resultante con otro, utilizando la herramienta “Comparar Segmentos” - “Especificado Manualmente”. Sin embargo, no podemos cambiar la composición del segmento, sino simplemente comparar varios períodos de un segmento usando la opción "Período anterior".

Aquí tampoco se han olvidado los viejos “Objetivos”, que podemos utilizar como otro parámetro clarificador para construir un segmento.

La cantidad de opciones para construir segmentos es prácticamente ilimitada. A continuación, podemos analizar la información recibida y olvidarnos de la selección, o guardarla y acceder a ella más tarde desde el menú “Informes” - “Mis Informes”, o simplemente subir los datos.

Métricas de Yandex del webvisor

El proceso de segmentación anterior resultó muy útil para esta herramienta. Seleccionar registros de visitas a grupos de usuarios de interés se ha vuelto aún más fácil. El procedimiento es el mismo: vaya a "Webvisor", configure un segmento (o cárguelo desde los guardados) y mire.

Aquí termino esta instrucción de revisión y, como siempre, espero sus preguntas en los comentarios.

Con nuevas metodologías como Extreme Programming o Scrum, el desarrollo se puede realizar más rápido y la disponibilidad de nuevas plataformas y la abstracción de capas inferiores permite evitar muchos errores. Sin embargo, el control de calidad debe llevarse a cabo en una variedad de niveles, desde el nivel metodológico hasta el tecnológico, cuando los procesos de control de calidad ocurren automáticamente, por ejemplo, durante los ensamblajes automáticos del proyecto. Sin embargo, cualquier control presupone la presencia de métricas que permitan evaluar el logro de un nivel particular de calidad de un proyecto de software.

Métricas de código

Métrica de software (métrica de software): una medida numérica que le permite evaluar ciertas propiedades de una sección específica del código del programa. Para cada métrica, suele haber puntos de referencia que indican en qué valores extremos vale la pena prestar atención a una determinada sección de código. Las métricas de código se dividen en categorías y pueden evaluar aspectos completamente diferentes de un sistema de software: la complejidad y estructura del código de software, la conectividad de los componentes, el volumen relativo de los componentes de software, etc. La métrica más fácil de entender es el número de líneas. del código en un sistema de software, aunque se puede calcular fácilmente, en combinación con otras métricas puede servir para obtener datos formalizados para la evaluación del código. Por ejemplo, se puede construir una relación entre el número de líneas de código de una clase y el número de métodos/propiedades de la clase, obteniendo una característica que muestra qué tan extensos son los métodos de una clase determinada. Además, dichas estimaciones se pueden utilizar junto con métricas de complejidad (por ejemplo, complejidad ciclomática de McCabe) para identificar las áreas más difíciles en el código del programa y tomar las medidas adecuadas.

Las métricas de código también pueden servir para identificar características arquitectónicas. El uso de tales métricas tiene el mayor efecto cuando se analizan grandes sistemas de software, cuando el análisis manual y la revisión del código fuente pueden llevar un tiempo considerable. Por ejemplo, puede visualizar métricas de diferentes maneras, como se muestra en la Fig. 1, donde cada bloque de programa se representa como un rectángulo, donde la longitud de cada lado del rectángulo refleja el valor de cualquiera de las métricas (por ejemplo, complejidad, estructura, etc.). Esta representación se puede construir tanto para entidades de software de alto nivel (ensamblados, bibliotecas, espacios de nombres) como para elementos más privados (propiedades, métodos). Al mismo tiempo, al analizar un diagrama de alto nivel, puede identificar rápidamente bibliotecas problemáticas y bajar a un nivel inferior para examinar entidades problemáticas.

Las métricas de código de programa son una herramienta importante y muchos fabricantes de software ya las utilizan en la actualidad. Así, a la hora de certificar a niveles superiores según los modelos ISO/IEC o CMM/CMMI, es obligatorio el uso de métricas de código, lo que permite, en cierta medida, lograr la controlabilidad del proceso de desarrollo.

Existen muchas clasificaciones diferentes de métricas de software, que se interpretan desde diferentes perspectivas y clasifican las mismas características según diferentes criterios. Una de esas clasificaciones puede ser la división de métricas en grupos según los temas de evaluación:

tamaño– evaluación comparativa de tamaños de software;

complejidad– evaluación de la arquitectura y algoritmos del sistema de software (los indicadores negativos de este grupo de métricas indican problemas que pueden surgir durante el desarrollo, soporte y depuración del código del programa);

soportabilidad– evaluación del potencial del sistema de software para su posterior modificación.

Por supuesto, hay otros grupos que no entran en esta clasificación, por ejemplo, las métricas de satisfacción del usuario o los indicadores de cumplimiento de los requisitos iniciales, pero en este caso nos interesará la calidad del software desde el punto de vista de la implementación técnica. .

¿Importa el tamaño?

La métrica SLOC (líneas de código fuente) refleja el número de líneas de código fuente. Este indicador no siempre se puede utilizar para evaluar objetivamente el volumen de un sistema de software; su valor numérico depende de muchos factores aleatorios, como el estilo de codificación. No es legítimo comparar dos sistemas de software únicamente según este criterio, por lo que han aparecido muchos indicadores derivados para SLOC: el número de líneas vacías; número de líneas que contienen comentarios; porcentaje de comentarios; número de líneas de código contenidas en métodos/funciones; número promedio de líneas de código por método/función; número promedio de líneas de código por clase/paquete; número promedio de líneas de código por módulo, etc.

Además de SLOC, al estimar el tamaño, a menudo se utiliza el indicador de líneas de código “lógicas” LSI (instrucciones fuente lógicas), calculadas después de la normalización (llevar el código fuente a la forma adecuada) del listado: eliminando la colocación de varias instrucciones en una línea, líneas vacías, borrar comentarios, formatear líneas de código para inicializar datos, etc. Un indicador de este tipo puede servir para una evaluación más objetiva del volumen del sistema (el indicador que utiliza la normalización tiene el mismo aspecto que SLOC: el número de líneas, pero no físico, sino lógico). LSI también tiene derivados, como una métrica que se calcula no como el número físico de líneas de código en el lenguaje de programación fuente, sino como el número de instrucciones en un lenguaje de nivel inferior (lenguaje ensamblador, MSIL, etc.), que elimina la necesidad de normalización.

Otras métricas de este tipo se basan en entidades específicas de un paradigma de programación específico. El más popular hoy en día es el paradigma de programación orientada a objetos, pero los enfoques funcionales y procedimentales de la programación también tienen su propio conjunto específico de métricas. Desde un enfoque orientado a objetos, el tamaño de un sistema se puede calcular como el número de clases que contiene. El indicador del número de clases es una de las métricas principales en este enfoque, sin embargo, dependiendo del lenguaje de programación utilizado, se pueden usar métricas como el número de espacios de nombres en el proyecto, el número de estructuras, enumeraciones, el número de métodos, etc. Se puede utilizar. Además, puede calcular la "densidad" de estos indicadores determinando la relación de los valores de estas métricas. Por ejemplo, puede calcular la relación entre el número de clases y el número de métodos y comprender cuántos métodos contiene una clase en promedio. Sin embargo, se requieren más investigaciones para determinar los valores umbral para este tipo de métrica. La forma más sencilla de determinar los valores límite puede ser un experimento en el que se calculen los valores de estas métricas para los sistemas existentes. El cálculo de dichos ratios nos permitirá corregir la idea del sistema que se ha desarrollado sobre la base de métricas cuantitativas.

La calidad del sistema no depende directamente del uso de estos indicadores; sin embargo, con el tiempo, los desarrolladores experimentados pueden predecir aproximadamente el volumen del sistema para una determinada funcionalidad requerida por el cliente. En este caso, si hay una desviación notable de los indicadores especificados (por ejemplo, un aumento significativo en el número de clases con un número bajo de métodos por clase), vale la pena pensar en el hecho de que puede haber un número excesivo. de objetos en el sistema y refactorizar el código en una etapa anterior.

Complejidad

Para evaluar y controlar la calidad del código, se pueden utilizar directamente métricas de complejidad: complejidad ciclomática, coherencia del código, profundidad de herencia, etc.

La métrica de complejidad ciclomática muestra el número de ramas del flujo de control del programa, aumentado en uno. Para calcular esta métrica, se construye un gráfico dirigido basado en el código fuente, que contiene una entrada y una salida. En este caso, los vértices del gráfico están correlacionados con aquellas secciones del código del programa que contienen solo cálculos secuenciales y no contienen operadores de rama y bucle. Los arcos en este caso se correlacionan con las transiciones de un bloque a otro. Además, cada vértice del gráfico es accesible desde el punto inicial y el punto final es accesible desde cualquier otro. En este caso, la complejidad ciclomática se puede calcular como la diferencia entre el número de arcos y el número de vértices, incrementado en dos. Un indicador de este tipo puede reflejar la complejidad del flujo de control del programa y dar una señal sobre la posible presencia de una sección de código de baja calidad. Desafortunadamente, a pesar de su evidente utilidad práctica, esta métrica no puede distinguir entre operadores cíclicos. Además, los códigos de programa representados por los mismos gráficos pueden tener predicados (expresiones lógicas que contienen una variable) que son completamente diferentes en complejidad. Por este motivo, en ocasiones la complejidad ciclomática se utiliza simultáneamente con otras métricas, por ejemplo, con la métrica del número de operadores.

La métrica de conectividad de clase le permite determinar el grado de dependencia de los componentes de software del sistema entre sí. Los valores elevados de esta métrica en relación con los valores umbral pueden indicar un acoplamiento excesivo del sistema, que aparece debido a una encapsulación modular débil. Esta propiedad de un sistema de software puede generar dificultades a la hora de reutilizar el código. Esta métrica se puede utilizar como guía al construir y rediseñar la arquitectura de un sistema de software. Las principales formas de reducir la cohesión de los objetos son encapsular más estrictamente la lógica en los objetos, revisar el funcionamiento de los algoritmos desde un punto de vista conceptual y la descomposición estructural. En este caso se utilizan fábricas de objetos, que evitan conectividad innecesaria al momento de crear instancias de clase. Gracias al uso de valores brutos de esta métrica, es posible reducir la coherencia del sistema software, y por tanto la complejidad del código.

A veces se utiliza una variación de la métrica que refleja la coherencia del código: el número de llamadas a operaciones. Esta métrica le permite cuantificar la conectividad del sistema en forma de llamadas a métodos. La métrica cuenta las llamadas solo a aquellas operaciones definidas por el usuario. Por ejemplo, si el método A() llama al método B() tres veces, entonces el valor de esta métrica será uno; Si se llama al método B() una vez desde los métodos A(), C() y D(), entonces el valor de la métrica será igual a tres. Sin embargo, el valor absoluto de esta métrica puede variar significativamente de un proyecto a otro dependiendo de los enfoques para diseñar y codificar sistemas de software. Incluso dentro del mismo equipo de desarrollo en proyectos idénticos, el valor de esta métrica puede diferir debido a factores subjetivos (por ejemplo, el estilo de un desarrollador en particular al separar la lógica en métodos separados) que influyeron en la construcción del sistema de software.

El resultado directo del cálculo de esta métrica tiene una importancia práctica dudosa, pero junto con el valor total de la métrica, el número de métodos en una clase puede dar una evaluación objetiva de la coherencia del sistema. Por ejemplo, si utiliza esta métrica junto con la métrica de complejidad, así como las características volumétricas, entonces, en función de la totalidad de los valores de estas métricas, puede detectar código de calidad insuficiente.

Otra métrica importante para evaluar la complejidad es la profundidad promedio de herencia, que se calcula como el valor promedio de la profundidad de herencia para todas las clases definidas por el usuario en el sistema. Esto no tiene en cuenta las clases que no se encuentran en el nivel más bajo de la jerarquía de herencia. Los valores altos de la métrica pueden indicar que los arquitectos del sistema de software se dejan llevar demasiado por las técnicas de programación orientada a objetos, y esto puede afectar negativamente el desarrollo posterior del sistema. La herencia aumenta significativamente la coherencia, lo que puede no reflejarse en otras métricas de evaluación del sistema. A menudo, al crear código de programa, se puede evitar el uso de la herencia reemplazándola con técnicas equivalentes. Por ejemplo, puede utilizar la inyección de dependencia y los contenedores IoC. El resultado del cálculo de esta métrica se suele utilizar en su forma original en tareas prácticas de arquitectura y refactorización. Las métricas resultantes también se pueden utilizar en métricas más complejas. En otras palabras, si el valor de esta métrica es grande, entonces se puede identificar inmediatamente una anomalía. Además, esta métrica se puede utilizar junto con otras, como la complejidad y el volumen del sistema McCabe, para medir con mayor precisión un sistema de software.

En general, las métricas de complejidad pueden brindar una ayuda significativa a los fabricantes de software en el proceso de monitoreo y gestión de la calidad del software.

Soportabilidad

Las métricas de este tipo muestran la complejidad del proceso de mantenimiento y desarrollo del código del programa y, por regla general, están estrechamente relacionadas con las métricas de complejidad, pero tienen sus propias características que reflejan las capacidades de soporte del sistema.

Una de las principales métricas de esta categoría es la métrica de Halstead, que define cuatro características mensurables de un programa: el número de declaraciones únicas del programa, incluidos caracteres separadores, nombres de procedimientos y signos de operación (diccionario de declaraciones); número de operandos únicos del programa (diccionario de operandos); número total de declaraciones en el programa; el número total de operandos en el programa. A partir de estas características se realizan valoraciones básicas: se elabora un diccionario del programa; Se determina la duración del programa, su volumen y complejidad. A continuación, se propone calcular varias medidas que le permitan evaluar el código del programa. Por ejemplo, una expresión para calcular la calidad de la programación, la dificultad de entender un programa, el coste mental de crear un programa, etc.

La métrica de Halstead es puramente informativa; sin embargo, sigue siendo una de las pocas que nos permite cuantificar el indicador de soporte del sistema en el futuro, y este indicador tiene una correlación directa con la calidad del producto que se lanza.

Herramienta de análisis de código

Los desarrolladores de la plataforma Microsoft pueden aprovechar Visual Studio 2008, que les permite calcular un conjunto básico de métricas clave y realizar un seguimiento de ellas en tiempo real (Figura 2). Sin embargo, el principal caso de uso de las métricas es informar a los gerentes de desarrollo que la calidad de un producto puede haber disminuido o aumentado. Por lo tanto, tiene sentido calcular dichas métricas durante el proceso de construcción del proyecto.

Visual Stuido 2008 y Microsoft Build no permiten construir una jerarquía seria de métricas, y para ello conviene utilizar otras herramientas, como NDepend, que permite a la plataforma .NET calcular varios tipos de cohesión, herencia y abstracción, integrándose en el proceso de creación del programa de acuerdo con los requisitos de un equipo de desarrollo específico.

Problemas con el uso de métricas de código

A pesar de que las métricas permiten controlar el proceso de desarrollo, trabajar con ellas conlleva una serie de problemas.

En primer lugar, todas las métricas de código conocidas actualmente no son lo suficientemente significativas o precisas. No pueden proporcionar una imagen objetiva del estado del sistema de software, solo proporcionan indicadores que se calculan utilizando un algoritmo determinado. En segundo lugar, el proceso de medición puede distorsionarse artificialmente debido al hecho de que los empleados “optimizarán” el código de su programa para que las métricas produzcan mejores resultados. Además, el uso formal de métricas no tiene en cuenta la experiencia de los empleados, el nivel de la empresa y puede traer no solo beneficios sino también daños.

Sin embargo, las métricas son una herramienta bastante útil en manos de desarrolladores y gerentes de proyectos, ya que les permiten identificar momentos en los que el desarrollo ha caído a un nivel de calidad más bajo y reconocer las áreas más difíciles del sistema. La determinación de indicadores numéricos puede proporcionar nueva información sobre el producto que se está desarrollando y ayudar a planificar de manera más competente los costos para su desarrollo posterior.

Serguéi Zvezdin ([correo electrónico protegido]) – estudiante de posgrado en la Universidad Estatal de los Urales del Sur (Chelyabinsk).

Se ha abierto un portal de educación a distancia en MSU

Escuela de Educación a Distancia de la Universidad Estatal de Moscú. M.V. Lomonosov abrió su propio portal en Internet. Ofrece acceso a la biblioteca electrónica abierta conjunta de la Universidad Estatal de Moscú y la Academia de Ciencias de Rusia, libros de texto y cursos, materiales de audio y video, así como programas educativos que utilizan tecnologías de aprendizaje a distancia. Algunos de los recursos del portal están disponibles únicamente para estudiantes de programas de educación a distancia que hayan pagado su educación de acuerdo con un acuerdo con la universidad. Los videos de MSU ahora están disponibles en canal universidad en youtube. El canal educativo contiene grabaciones de conferencias y eventos universitarios.

eLearning solo para el 17% de las empresas rusas

El centro de investigación del portal SuperJob.ru presentó los resultados de una encuesta sobre la formación online del personal de las empresas rusas. Entre los empleadores nacionales, el uso del aprendizaje electrónico para trabajar con personal no es muy común. Sólo el 17% de las empresas ofrecen esta forma de formación al personal. Estas tecnologías se utilizan principalmente en grandes empresas con una plantilla de 5 mil personas (50%). El 79% de los empleadores no utiliza esta práctica en absoluto. Las razones radican en la falta de equipamiento técnico necesario o en la reticencia de la dirección a aplicar este tipo de formación. En general, sólo el 11% de los rusos tiene experiencia en educación a distancia. De este número, el 9% de los encuestados se mostró satisfecho con el resultado y el 2% no estudió y abandonó los estudios. Entre quienes completaron la formación, había casi el doble de hombres que de mujeres (11% y 6%, respectivamente). Al mismo tiempo, los rusos de entre 35 y 55 años estudian a través de Internet con más frecuencia que los jóvenes. El 12% de los encuestados de entre 40 y 50 años y sólo el 9% de los rusos menores de 23 años pueden presumir de una experiencia exitosa en la educación a distancia.

Resultados del concurso “Máxima Escalabilidad 2009”

El concurso de proyectos de computación de alto rendimiento “Máxima escalabilidad”, como el año pasado, se programó para coincidir con el foro internacional de nanotecnología. Los científicos de veinte ciudades rusas cantaron victoria, pero los organizadores, Intel y la Corporación Rusa de Nanotecnología, otorgaron todos los premios a proyectos en la capital. El Gran Premio lo recibió Vladimir Bochenkov de la Facultad de Química de la Universidad Estatal de Moscú. Lomonosov por el proyecto “Desarrollo e implementación de un algoritmo paralelo para dinámica acelerada por temperatura”. El sistema propuesto por el autor permite estudiar la condensación de nanoestructuras, la epitaxia de haces moleculares y la interacción de moléculas biológicas.

El Campeonato Mundial de Programación ha comenzado

La final del 34º Concurso Universitario Internacional de Programación (ICPC), organizado por la Association for Computing Machinery (ACM) y patrocinado por IBM, enfrentará a cien equipos de estudiantes ganadores en competencias regionales entre sí. Se les plantearán al menos ocho problemas que deberán resolver en 5 horas. La final tendrá lugar el 5 de febrero de 2010 en la Universidad de Ingeniería de Harbin (China). Los problemas en el pasado han incluido, por ejemplo, encontrar un barco perdido en el mar, triangular la ubicación de un transmisor de radio dañado, calcular obstáculos en un juego de golf, codificar y decodificar mensajes, imprimir en Braille y encontrar una salida a un laberinto. . El año pasado, tres de cada cuatro medallas de oro las ganaron equipos rusos. En la fase de clasificación participaron en el campeonato 7.109 equipos de 1.838 universidades de 88 países. Por segundo año consecutivo, el equipo de la Universidad Estatal de Tecnologías de la Información, Mecánica y Óptica de San Petersburgo se proclamó campeón del mundo.

Chernikov Alexéi

1. Introducción

A diferencia de la mayoría de las industrias de producción de materiales, en materia de proyectos de desarrollo de software, los enfoques simples basados ​​en multiplicar la intensidad del trabajo por la productividad laboral promedio son inaceptables. Esto se debe, en primer lugar, al hecho de que los indicadores económicos del proyecto dependen de forma no lineal del volumen de trabajo y se permite un gran error al calcular la intensidad del trabajo.

Por tanto, para solucionar este problema se utilizan métodos complejos y bastante complejos, que requieren una gran responsabilidad en la aplicación y un cierto tiempo de adaptación (ajustando coeficientes).

Los sistemas integrales modernos para evaluar las características de los proyectos de desarrollo de software se pueden utilizar para resolver los siguientes problemas:

• evaluación preliminar, permanente y final de los parámetros económicos del proyecto: intensidad de mano de obra, duración, costo;
  
• evaluación de riesgos del proyecto: riesgo de incumplimiento de los plazos e incumplimiento del proyecto, riesgo de mayor intensidad de mano de obra en las etapas de depuración y soporte del proyecto, etc.;
  
• tomar decisiones de gestión operativa: basándose en el seguimiento de ciertas métricas del proyecto, es posible prevenir rápidamente la aparición de situaciones indeseables y eliminar las consecuencias de decisiones de diseño mal concebidas.

1 Introducción
2 métricas
2.1 Métricas orientadas a dimensiones (indicadores de estimación de volumen)
2.1.1 Evaluación LOC (Lines Of Code)
2.1.1.1 Métricas de estilo y comprensibilidad de los programas.
2.1.2 Total por SLOC
2.2 Métricas de dificultad
2.2.2 Métricas de Halstead
2.2.4 Métricas de Chapín

2.4 Lista general de métricas
2.4 Resumiendo
6 recursos de Internet

2. Métricas

Las métricas de complejidad del programa generalmente se dividen en tres grupos principales:

• métricas del tamaño del programa;
  
• métricas de complejidad del flujo de control del programa;
  
• métricas de complejidad del flujo de datos del programa.
  

Las métricas del primer grupo se basan en determinar características cuantitativas relacionadas con el tamaño del programa y son relativamente simples. Las métricas más conocidas de este grupo incluyen la cantidad de declaraciones del programa, la cantidad de líneas de texto fuente y un conjunto de métricas de Halstead. Las métricas de este grupo se centran en analizar el texto fuente de los programas. Por lo tanto, pueden utilizarse para evaluar la complejidad de los intermediarios del desarrollo.

Las métricas del segundo grupo se basan en el análisis del gráfico de control del programa. Un representante de este grupo es la métrica de McCabe.

El gráfico de control del programa, que utilizan las métricas de este grupo, se puede construir sobre la base de algoritmos de módulo. Por tanto, las métricas del segundo grupo se pueden utilizar para evaluar la complejidad de los productos de desarrollo intermedio.

Las métricas del tercer grupo se basan en evaluar el uso, configuración y ubicación de los datos en el programa. En primer lugar, se trata de variables globales. Este grupo incluye las métricas de Chapin.

2.1 Métricas orientadas a dimensiones (indicadores de evaluación de volumen)

2.1.1 Evaluación LOC (Lines Of Code)

Las métricas orientadas a dimensiones miden directamente un producto de software y su proceso de desarrollo. Estas métricas se basan en estimaciones de LOC.

Este tipo de métricas mide indirectamente el producto de software y su proceso de desarrollo. En lugar de calcular puntuaciones LOC, analiza la funcionalidad o utilidad del producto en lugar del tamaño.

Las métricas orientadas a dimensiones son las más utilizadas en la práctica del desarrollo de software. En las organizaciones involucradas en el desarrollo de productos de software, se acostumbra registrar los siguientes indicadores para cada proyecto:

• costos laborales totales (en meses-hombre, horas-hombre);
  
• tamaño del programa (en miles de líneas de código fuente -LOC);
  
• costo de desarrollo;
  
• volumen de documentación;
  
• errores descubiertos durante un año de operación;
  
• la cantidad de personas que trabajan en el producto;
  
• periodo de desarrollo.
  

Con base en estos datos, generalmente se calculan métricas simples para evaluar la productividad laboral (KLOC/mes-hombre) y la calidad del producto.

Estas métricas no son universales ni controvertidas, especialmente para un indicador como LOC, que depende en gran medida del lenguaje de programación utilizado.

El número de líneas de código fuente (Líneas de código - LOC, Líneas de código fuente - SLOC) es la forma más sencilla y común de estimar la cantidad de trabajo de un proyecto.

Inicialmente, este indicador surgió como una forma de evaluar la cantidad de trabajo en un proyecto que utilizaba lenguajes de programación con una estructura bastante simple: “una línea de código = un comando de lenguaje”. También se sabe desde hace mucho tiempo que la misma funcionalidad se puede escribir en diferentes números de líneas, y si tomamos un lenguaje de alto nivel (C++, Java), entonces es posible escribir de 5 a 6 líneas de funcionalidad en una línea. esto no es un problema. Y eso no sería tan malo: las propias herramientas de programación modernas generan miles de líneas de código para una operación insignificante.

Por lo tanto, el método LOC es sólo un método de evaluación (que debe tenerse en cuenta, pero no basarse en él en las evaluaciones) y de ninguna manera es obligatorio.

Dependiendo de cómo se tenga en cuenta un código similar, existen dos indicadores SLOC principales:

1. el número de líneas de código "físicas" - SLOC (las abreviaturas utilizadas son LOC, SLOC, KLOC, KSLOC, DSLOC) - se define como el número total de líneas de código fuente, incluidos comentarios y líneas vacías (al medir el indicador en el número de líneas vacías generalmente se introduce un límite: al calcular, se tiene en cuenta el número de líneas vacías, que no excede el 25% del número total de líneas en el bloque de código medido).
   
2. El número de líneas de código "lógicas" (SLOC (las abreviaturas utilizadas son LSI, DSI, KDSI, donde "SI" son instrucciones fuente)) se define como el número de comandos y depende del lenguaje de programación utilizado. Si el lenguaje no permite colocar varios comandos en una línea, entonces el número de SLOC "lógicos" corresponderá al número de "físicos", con la excepción del número de líneas vacías y líneas de comentarios. Si un lenguaje de programación admite la colocación de varios comandos en una línea, entonces una línea física debe contarse como varias líneas lógicas si contiene más de un comando del lenguaje.
   

Para la métrica SLOC existe una gran cantidad de derivados diseñados para obtener indicadores individuales del proyecto, siendo los principales:

• número de líneas vacías;
  
• número de líneas que contienen comentarios;
  
• porcentaje de comentarios (relación entre líneas de código y líneas de comentario, métrica estilística derivada);
  
• número promedio de líneas para funciones (clases, archivos);
  
• número promedio de líneas que contienen código fuente para funciones (clases, archivos);
  
• número promedio de filas para módulos.
  

2.1.1.1 Métricas de estilo y comprensibilidad de los programas.

A veces es importante no sólo contar el número de líneas de comentarios en el código y simplemente correlacionarlas con líneas lógicas de código, sino también averiguar la densidad de los comentarios. Es decir, el código primero estaba bien documentado y luego mal. O esta opción: el encabezado de una función o clase está documentado y comentado, pero el código no.

Fi = SIGNO (Ncomm. i / Ni – 0,1)

La esencia de la métrica es simple: el código se divide en n partes iguales y se determina Fi para cada una de ellas.

2.1.2 Total por SLOC

Posibles desventajas de SLOC que son objeto de críticas:

• Es feo e incorrecto reducir la evaluación del trabajo de una persona a unos pocos parámetros numéricos y juzgar la productividad en función de ellos. El gerente puede asignar a los programadores más talentosos al área de trabajo más difícil; esto significa que el desarrollo de esta área será el que tomará más tiempo y generará la mayor cantidad de errores debido a la complejidad de la tarea. Sin conocer estas dificultades, otro gerente puede decidir, basándose en los indicadores obtenidos, que el programador hizo mal su trabajo.
  
• La métrica no tiene en cuenta la experiencia de los empleados y sus otras cualidades.
  
• Distorsión: El proceso de medición puede distorsionarse debido a que los empleados conocen los indicadores que se miden y buscan optimizarlos en lugar de su desempeño. Por ejemplo, si el número de líneas de código fuente es un indicador importante, entonces los programadores se esforzarán por escribir tantas líneas como sea posible y no utilizarán técnicas de simplificación de código que reduzcan el número de líneas (consulte la barra lateral sobre India).
  
• Inexactitud: no existen métricas que sean lo suficientemente significativas y precisas. El número de líneas de código es simplemente el número de líneas; este indicador no da una idea de la complejidad del problema que se está resolviendo. El análisis de puntos de función se desarrolló para medir mejor la complejidad del código y las especificaciones, pero utiliza el criterio personal del medidor, por lo que diferentes personas obtendrán resultados diferentes.
  

Y lo más importante para recordar: La métrica SLOC no refleja la intensidad laboral de la creación de un programa.
.

Ejemplo de la vida : En una de las empresas, durante la implementación, utilizamos esta métrica: contamos líneas de código. El responsable de la organización estaba de vacaciones, pero al regresar de las mismas decidió aprovechar la transparencia y trazabilidad de los cambios y ver cómo les iba a sus directivos con sus proyectos. Y para comprender completamente el curso, bajé al nivel más bajo (es decir, no evalué la densidad de defectos, la cantidad de errores corregidos), al nivel de los textos originales. Decidí contar quién escribió y cuántas líneas. Y para que sea realmente divertido, compara el número de días laborables por semana y la cantidad de código escrito (la lógica es simple: una persona trabaja 40 horas a la semana, lo que significa que tiene que escribir muchas cosas). Naturalmente, hubo una persona que escribió solo una línea en una semana, ni siquiera la escribió, solo corrigió la existente... La ira del gerente no tuvo límites: ¡encontró a un holgazán! Y sería malo para el programador si el director del proyecto no le explicara que: se encontró un error en el programa, lo encontró un cliente VIP, el error afecta el negocio del cliente y era necesario solucionarlo con urgencia, para ello este particular Se seleccionó al contratista, quien desplegó el stand, inundó el entorno del cliente, confirmó la ocurrencia del error y comenzó a buscarlo y eliminarlo. Naturalmente, al final cambió el fragmento de código que tenía la condición incorrecta y todo funcionó.

De acuerdo, es una estupidez calcular los costes laborales utilizando esta métrica: es necesaria una evaluación exhaustiva...

2.2 Métricas de dificultad

Además de los indicadores para evaluar el volumen de trabajo de un proyecto, los indicadores para evaluar su complejidad son muy importantes para obtener estimaciones objetivas del proyecto. Como regla general, estos indicadores no se pueden calcular en las primeras etapas del trabajo de un proyecto, ya que requieren, como mínimo, un diseño detallado. Sin embargo, estos indicadores son muy importantes para obtener estimaciones previstas de la duración y el costo del proyecto, ya que determinan directamente su intensidad laboral.

2.2.1 Métricas orientadas a objetos

En las condiciones modernas, la mayoría de los proyectos de software se crean en base al enfoque OO y, por lo tanto, existe una cantidad significativa de métricas que permiten evaluar la complejidad de los proyectos orientados a objetos.

Métrica	Descripción
Métodos ponderados por clase (WMC)	Refleja una medida relativa de la complejidad de una clase basada en la complejidad ciclomática de cada uno de sus métodos. Una clase con métodos más complejos y más métodos se considera más compleja. Las clases principales no se tienen en cuenta al calcular la métrica.
Métodos ponderados por clase (WMC2)	Una medida de la complejidad de una clase basada en la idea de que una clase con más métodos es más compleja y que un método con más parámetros también es más complejo. Las clases principales no se tienen en cuenta al calcular la métrica.
Profundidad del árbol de herencia	La longitud de la ruta de herencia más larga que termina en este módulo. Cuanto más profundo sea el árbol de herencia de un módulo, más difícil será predecir su comportamiento. Por otro lado, aumentar la profundidad proporciona un mayor potencial para que un módulo determinado reutilice el comportamiento definido para las clases antecesoras.
Número de niños	La cantidad de módulos que heredan directamente un módulo determinado. Los valores grandes de esta métrica indican una alta reutilización; en este caso, un valor demasiado grande puede indicar una abstracción mal elegida.
Acoplamiento entre objetos	El número de módulos asociados con este módulo en el rol de cliente o proveedor. Un acoplamiento excesivo indica una encapsulación modular débil y puede impedir la reutilización del código.
Respuesta para la clase	El número de métodos que pueden ser llamados por instancias de la clase; calcula tanto la suma del número de métodos locales como el número de métodos remotos

2.2.2 Métricas de Halstead

La métrica de Halstead se refiere a métricas calculadas en base al análisis del número de líneas y elementos sintácticos del código fuente del programa.

La métrica de Halstead se basa en cuatro características medibles del programa:

• NUOprtr (Número de operadores únicos): el número de operadores de programa únicos, incluidos caracteres delimitadores, nombres de procedimientos y signos de operación (diccionario de operadores);
  
• NUOprnd (Número de operandos únicos): el número de operandos únicos del programa (diccionario de operandos);
  
• Noprtr (Número de operadores): el número total de operadores en el programa;
  
• Noprnd (Número de operandos): el número total de operandos del programa.
  

En base a estas características se calculan las puntuaciones:

• Diccionario de programas
  (Vocabulario del programa Halstead, HPVoc): HPVoc = NUOprtr + NUOprnd;
  
• Duración del programa
  (Duración del programa Halstead, HPLen): HPLen = Noprtr + Noprnd;
  
• Alcance del programa
  (Volumen del programa Halstead, HPVol): HPVol = HPLen log2 HPVoc;
  
• Complejidad del programa
  (Dificultad de Halstead, HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd);
  
• Con base en el indicador HDiff, se propone evaluar los esfuerzos de desarrollo del programador utilizando el indicador HEff (Halstead Effort): HEff = HDiff × HPVol.
  

2.2.3 Métricas de complejidad ciclomática de McCabe

El indicador de complejidad ciclomática es uno de los indicadores más comunes para evaluar la complejidad de proyectos de software. Este indicador fue desarrollado por el científico McCabe en 1976, pertenece al grupo de indicadores para evaluar la complejidad del flujo de control del programa y se calcula en base al gráfico del flujo de control del programa. Este gráfico se construye en forma de gráfico dirigido, en el que los operadores o expresiones computacionales se representan como nodos y la transferencia de control entre nodos se representa como arcos.

El indicador de complejidad ciclomática permite no solo evaluar la intensidad laboral de implementar elementos individuales de un proyecto de software y ajustar los indicadores generales para estimar la duración y el costo del proyecto, sino también evaluar los riesgos asociados y tomar las decisiones de gestión necesarias.

Una fórmula simplificada para calcular la complejidad ciclomática es la siguiente:

C = mi – norte + 2,

Dónde mi – numero de costillas , y norte – número de nodos
en el gráfico de lógica de control.

Normalmente, los operadores lógicos no se tienen en cuenta al calcular la complejidad ciclomática.

En el proceso de cálculo automatizado del indicador de complejidad ciclomática, por regla general, se utiliza un enfoque simplificado, según el cual no se construye el gráfico, sino que el indicador se calcula contando el número de operadores lógicos de control (si, cambiar, etc.) y el número posible de rutas de ejecución de programas.

El número ciclomático de McCabe indica el número de pasadas necesarias para cubrir todos los contornos de un gráfico estrechamente conectado, o el número de ejecuciones de prueba de un programa necesarias para una prueba exhaustiva de "todas las ramas funcionan".

El indicador de complejidad ciclomática se puede calcular para un módulo, método y otras unidades estructurales del programa.

Hay un número significativo de modificaciones del indicador de complejidad ciclomática.

• Complejidad ciclomática “modificada”: no considera cada rama de un operador de opción múltiple (interruptor), sino todo el operador como un todo.
  
• Complejidad ciclomática “estricta”: incluye operadores lógicos.
  
• Cálculo "simplificado" de la complejidad ciclomática: implica el cálculo no sobre la base de un gráfico, sino sobre la base del conteo de operadores de control.
  

2.2.4 Métricas de Chapín

Hay varias modificaciones del mismo. Consideremos una versión más simple y, desde el punto de vista del uso práctico, bastante efectiva de esta métrica.

La esencia del método es evaluar la solidez de la información de un único módulo de software analizando la naturaleza del uso de variables de la lista de entrada y salida.

Todo el conjunto de variables que componen la lista de E/S se divide en cuatro grupos funcionales.

Q = a1P + a2M + a3C + a4T, donde a1, a2, a3, a4 son coeficientes de ponderación.

Q = P + 2M + 3C + 0,5T.

2.3 Evaluación preliminar basada en métodos estadísticos según las etapas de desarrollo del programa

Al utilizar herramientas integradas, las empresas que desarrollan soluciones estándar (esta categoría incluye los llamados "inhausers", empresas dedicadas al servicio del negocio principal) tienen la oportunidad de hacer pronósticos de la complejidad de los programas basándose en las estadísticas recopiladas. El método estadístico es muy adecuado para resolver problemas tan típicos y prácticamente no es adecuado para predecir proyectos únicos. En el caso de proyectos únicos, se utilizan otros enfoques, cuya discusión está fuera del alcance de este material.

Las tareas típicas provienen de una gran cantidad de departamentos de negocios a departamentos de desarrollo, por lo que una evaluación preliminar de la complejidad podría simplificar enormemente las tareas de planificación y gestión, especialmente porque existe una base de datos acumulada para proyectos en la que no solo se almacenan los resultados finales, sino también todos los iniciales y los intermedios.

Destaquemos etapas típicas en el desarrollo de un programa:

• desarrollo de especificaciones de requisitos del programa;
  
• definición de arquitectura;
  
• desarrollo de la estructura modular del programa, desarrollo de interfaces entre módulos. Desarrollo de algoritmos;
  
• Desarrollo y prueba de código.
  

Ahora intentemos observar una serie de métricas que se utilizan a menudo para la evaluación preliminar en las dos primeras etapas.

2.3.1 Evaluación preliminar de la complejidad del programa en la etapa de desarrollo de las especificaciones de requisitos del programa

Para evaluar los resultados de esta etapa se puede utilizar la métrica del número previsto de operadores Nprog del programa:

Nprogn =NF*Nunidad

Donde: NF – número de funciones o requisitos en la especificación de requisitos para el programa que se está desarrollando;
Ned: un valor único del número de operadores (el número promedio de operadores por función o requisito promedio). El valor de Ned es estadístico.

2.3.2 Evaluación preliminar de la complejidad en la etapa de definición de la arquitectura

Si = NI / (NF * NIed * Ksl)

Dónde:
NI – el número total de variables transferidas a través de interfaces entre componentes del programa (también estadístico);
NIed: un valor único del número de variables transferidas a través de interfaces entre componentes (el número promedio de variables transferidas a través de interfaces por una función o requisito promedio);
Ksl es el coeficiente de complejidad del programa que se está desarrollando, tiene en cuenta el aumento en la complejidad unitaria del programa (complejidad por una función o requisito de la especificación de requisitos del programa) para programas grandes y complejos en comparación con el software promedio.

2.4 Lista general de métricas

La Tabla 1 contiene una breve descripción de las métricas que no están incluidas en la descripción detallada anterior, pero, sin embargo, estas métricas son necesarias e importantes, solo que estadísticamente son mucho menos comunes.

Tenga en cuenta también que el propósito de este artículo es mostrar el principio y no describir todas las métricas posibles en muchas combinaciones.