Ingeniería de software

Trabajo investigativo No. 04

Presentado por:

Hasbleydi Yurani Reyes Saldaña

Camilo Esteban Rodriguez Forero

Marlon Sebastián Castañeda Aponte

Presentado a:

Juan Carlos Guevara Bolaños

Universidad Distrital Francisco José de Caldas, Facultad Tecnológica

Bogotá D.C.

2017

Contenido1. Métricas de software.....................................................................................3

2. Definición y características de medidas........................................................3

3. Definición y características de métricas........................................................5

4. Definición y características de indicadores...................................................8

5. Ventajas del uso de métricas......................................................................10

6. Tipos de métricas.......................................................................................11

7. Métricas de proceso...................................................................................14

8. Métricas de proyecto..................................................................................15

9. Métricas de producto..................................................................................15

10. Métricas de calidad..................................................................................16

11. Otras........................................................................................................18

12. Organización de un taller sobre el uso de una herramienta de métricas.18

13. Estudio de caso donde se analice la aplicación de métricas de software20

14. Explicación del uso de una herramienta de métricas de software (4 ejemplos)...........................................................................................................26

15. Conclusión...............................................................................................32

16. Bibliografía...............................................................................................32

Métricas de software

1. Definición y características de medidas

La medición del software se refiere a derivar un valor numérico desde algún atributo del software o del proceso software. Comparando estos valores entre sí y con los estándares aplicados en la organización, es posible sacar conclusiones de la calidad del software o de los procesos para desarrollarlo. Por ejemplo supóngase que una determinada organización está planeando introducir una nueva herramienta de prueba de software. Antes de introducir la herramienta, se registra el número de defectos descubiertos en el software en un tiempo dado; después de introducir la herramienta, se repite este proceso de validación del software.

Las mediciones del software pueden utilizarse para:

Hacer predicciones generales acerca del sistema: Haciendo mediciones de las características de los componentes del sistema y reuniendo estas, podremos derivar una estimación general de algunos atributos del sistema, como el número de fallas.

Identificar componentes anómalos: Mediante las mediciones se puede identificar los componentes que se salgan de lo normal.

Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de mantenimiento, integridad y facilidad de uso suministran indicadores útiles para el equipo del proyecto. Gilb [Len O. Ejiogo ‘90] sugiere definiciones y medidas para cada uno de ellos, tales como:

* Corrección: A un programa le corresponde operar correctamente o suministrará poco valor a sus usuarios. La corrección es el grado en el que el software lleva a cabo una función requerida. La medida más común de corrección son los defectos por KLDC, en donde un defecto se define como una falla verificada de conformidad con los requisitos.

* Facilidad de mantenimiento. El mantenimiento del software cuenta con más esfuerzo que cualquier otra actividad de ingeniería del software. La facilidad de mantenimiento es la habilidad con la que se puede corregir un programa si se encuentra un error, se puede adaptar si su entorno cambia o optimizar si el cliente desea un cambio de requisitos. No hay forma de medir directamente la facilidad de mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una métrica orientada al tiempo simple es el tiempo medio de cambio (TMC), es decir, el tiempo que se tarda en analizar la petición de cambio, en diseñar una modificación apropiada, en efectuar el cambio, en probarlo y en distribuir el cambio a todos los usuarios. En promedio, los

programas que son más fáciles de mantener tendrán un TMC más bajo (para tipos equivalentes de cambios) que los programas que son más difíciles de mantener.

Hitachi ha empleado una métrica orientada al costo (precio) para la capacidad de mantenimiento, llamada “desperdicios”. El costo estará en corregir defectos hallados después de haber distribuido el software a sus usuarios finales.

Cuando la proporción de desperdicios en el costo global del proyecto se simboliza como una función del tiempo, es aquí donde el administrador logra determinar si la facilidad de mantenimiento del software producido por una organización de desarrollo está mejorando y asimismo se pueden emprender acciones a partir de las conclusiones obtenidas de esa información.

* Integridad. En esta época de intrusos informáticos y de virus, la integridad del software ha llegado a tener mucha importancia. Este atributo mide la habilidad de un sistema para soportar ataques (tanto accidentales como intencionados) contra su seguridad. El ataque se puede ejecutar en cualquiera de los tres componentes del software, ya sea en los programas, datos o documentos.

Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad. La amenaza es la probabilidad (que se logra evaluar o concluir de la evidencia empírica) de que un ataque de un tipo establecido ocurra en un tiempo establecido. La seguridad es la probabilidad (que se puede estimar o deducir de la evidencia empírica) de que se pueda repeler el ataque de un tipo establecido, en donde la integridad del sistema se puede especificar como:

integridad = Ó[1- amenaza x (1- seguridad)]

donde se suman la amenaza y la seguridad para cada tipo de ataque.

* Facilidad de uso. El calificativo “amigable con el usuario” se ha transformado universalmente en disputas sobre productos de software. Si un programa no es “amigable con el usuario”, prácticamente está próximo al fracaso, incluso aunque las funciones que realice sean valiosas. La facilidad de uso es un intento de cuantificar “lo amigable que pude ser con el usuario” y se consigue medir en función de cuatro características: (1) destreza intelectual y/o física solicitada para aprender el sistema; (2) el tiempo requerido para alcanzar a ser moderadamente eficiente en el uso del sistema; (3) aumento neto en productividad (sobre el enfoque que el sistema reemplaza) medida cuando alguien emplea el sistema moderadamente y eficientemente, y (4) valoración subjetiva (a veces obtenida mediante un cuestionario) de la disposición de los usuarios hacia el sistema.

Los cuatro factores anteriores son sólo un ejemplo de todos los que se han propuesto como medidas de la calidad del software.

Medidas de fiabilidad y de disponibilidad.

Los trabajos iniciales sobre fiabilidad buscaron extrapolar las matemáticas de la teoría de fiabilidad del hardware a la predicción de la fiabilidad del software.

La mayoría de los modelos de fiabilidad relativos al hardware van más orientados a los fallos debidos al desajuste, que a los fallos debidos a defectos de diseño, ya que son más probables debido al desgaste físico (p. ej.: el efecto de la temperatura, del deterioro, y los golpes) que los fallos relativos al diseño.

Desgraciadamente, para el software lo que ocurre es lo contrario. De hecho, todos los fallos del software, se producen por problemas de diseño o de implementación.

Considerando un sistema basado en computadora, una medida sencilla de la fiabilidad es el tiempo medio entre fallos (TMEF) [Mayrhauser´91], donde:

TMEF = TMDF+TMDR

(TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparación)).

Muchos investigadores argumentan que el TMDF es con mucho, una medida más útil que los defectos/KLDC, simplemente porque el usuario final se enfrenta a los fallos, no al número total de errores. Como cada error de un programa no tiene la misma tasa de fallo, la cuenta total de errores no es una buena indicación de la fiabilidad de un sistema. Por ejemplo, consideremos un programa que ha estado funcionando durante 14 meses.

Muchos de los errores del programa pueden pasar desapercibidos durante décadas antes de que se detecten. El TMEF de esos errores puede ser de 50 e incluso de 100 años. Otros errores, aunque no se hayan descubierto aún, pueden tener una tasa de fallo de 18 ó 24 meses, incluso aunque se eliminen todos los errores de la primera categoría (los que tienen un gran TMEF), el impacto sobre la fiabilidad del software será muy escaso.

Además de una medida de la fiabilidad debemos obtener una medida de la disponibilidad. La disponibilidad (4.1.3.2) del software es la probabilidad de que un programa funcione de acuerdo con los requisitos en un momento dado, y se define como:

Disponibilidad = TMDF/(TMDF + TMDR) x 100 %

La medida de fiabilidad TMEF es igualmente sensible al TMDF que al TMDR. La medida de disponibilidad es algo más sensible al TMDR ya que es una medida indirecta de la facilidad de mantenimiento del software.

2. Definición y características de métricas

Una métrica es un contenedor de información en un contexto de supervisión. Las métricas se asocian con una o más expresiones de valores de métricas que, cuando se evalúan, dan un valor a la métrica. Son ejemplos de métricas la duración de trabajo de un proceso y la hora de respuesta del proveedor.

Para definir una métrica, realice los pasos siguientes:

1. Pulse la pestaña Modelo de detalles de Monitor del editor, pulse con el botón derecho del ratón el contexto de supervisión (o cualquier elemento del contexto de supervisión) en el árbol de modelo y pulse Nuevo > Métrica.

2. En la ventana Crear nueva métrica, escriba un nombre en el campo Nombre. El nombre tiene un límite de 256 caracteres. Al escribir el nombre se creará automáticamente un ID por omisión, aunque puede cambiarlo si lo prefiere. El ID es necesario y debe ser exclusivo en el contexto de supervisión. El ID debe ser un NCName (nombre que no utilice los dos puntos) XML, lo que quiere decir que debe empezar por una letra o carácter de subrayado y sólo puede contener letras, números, caracteres de subrayado, guiones y puntos. Seleccione el tipo de métrica de la lista de tipos disponibles y pulse Aceptar.

La métrica se añade al árbol de modelos bajo el contexto de supervisión y el editor de formularios se abre para que pueda definir la métrica.

3. En el editor de formularios, especifique los detalles de la métrica de la manera siguiente:

a. Opcional: Escriba una descripción en el campo Descripción. La descripción se utiliza únicamente en el editor de modelo de Monitor y no se muestra en ningún lugar de WebSphere Business Monitor. El juego de caracteres no está restringido.

b. Opcional: Escriba la longitud máxima de la serie en el campo Longitud máxima de la serie. Esta opción sólo está disponible si el tipo es Serie. El valor por omisión es 256 y puede escribir cualquier valor superior a 0. La longitud máxima de la serie se añade como restricción a la base de datos.

c. Opcional: Si el tipo es de serie y la serie de caracteres se convertirá a otros idiomas, seleccione Asignar espacio adicional en una base de datos para alojar series Unicode para la globalización. Esta opción sólo está disponible si el tipo es Serie.

d. Opcional: Si esta métrica es un origen de un nivel de dimensión, seleccione Se requiere un valor para esta métrica y también especifique

un valor por omisión. Si se requiere un valor se asegura que todas las instancias estén en un nivel de dimensión determinado al revisar dimensiones o informes en los paneles de control.

e. Opcional: Para especificar un valor por omisión, escriba un número o una función en el recuadro o pulse Editar para especificar una expresión. Si pulsa Control+espacio para obtener ayuda sobre el contenido, se muestra una ventana pequeña que le ayudará a escribir la expresión. En esta ventana, puede seleccionar operadores o funciones válidos. Para las métricas cuyo tipo no es serie, entero o decimal, debe convertir el valor por omisión al tipo adecuado mediante una función de constructor. Puede seleccionar la función de la ayuda de contenido antes de especificar el valor o escribir la función manualmente. Por ejemplo, si el tipo es Duración, un valor por omisión válido sería: duration('P0Y0M1DT0H0M0.000S'), que representa un valor por omisión de 1 día.

f. Opcional: Si desea que la métrica se indexe en la base de datos de manera que pueda utilizarse para realizar la clasificación en Instancias de los paneles de control, seleccione Esta métrica se puede utilizar para clasificar. En el documento XML, esta opción corresponde al atributo isSortable de la métrica.

4. Para añadir una expresión de valor de métrica a la tabla, pulse Añadir o pulse dos veces una fila. Cada métrica debe tener asignado un valor por omisión o tener una expresión de valor de métrica para establecer el valor de la métrica durante la ejecución. La expresión se evalúa en función de las siguientes apariciones:

Se activa un desencadenante. Si proporciona un desencadenante explícito, la expresión de valor de métrica sólo se ejecutará cuando se active el desencadenante.

Llega un suceso de entrada al que se hace referencia en la expresión del valor de métrica. Si una expresión de valor de métrica hace referencia a un suceso de entrada, la expresión se evalúa únicamente cuando llega el suceso de entrada. Una expresión de valor de métrica puede hacer referencia como máximo a un suceso de entrada.

Se actualiza una métrica o un contador al que se hace referencia en la expresión de valor de métrica. Si la expresión de valor de métrica no tiene ningún desencadenante y no hace referencia a un suceso de entrada, la expresión se evalúa cuando se actualiza una métrica o contador al que se hace referencia en la expresión (incluso si la actualización no da como resultado un valor nuevo).

a. Opcional: Para proporcionar un desencadenante explícito, pulse la celda Desencadenante y pulse el botón que se muestra para abrir la ventana Seleccionar un desencadenante. Seleccione un desencadenante que ha creado previamente.

b. Pulse la casilla Expresión y añada una expresión. Puede escribir directamente en la casilla o, en el caso de una expresión de gran tamaño, pulsar el botón visualizado para abrir una ventana dimensionable. Si pulsa Control+espacio para obtener ayuda sobre el contenido, se muestra una ventana pequeña que le ayudará a escribir la expresión. En esta ventana, puede seleccionar operadores, funciones y los siguientes elementos válidos en el modelo:

o Atributos de suceso de entrada.o Métricas, contadores y cronómetros en el mismo contexto de

supervisión.o Métricas, contadores y cronómetros en contextos hijos e

inferiores, pero sólo si la expresión de valor de métrica se ejecuta debido a que se activa un desencadenante en el contexto hijo.

Para emitir literales o subexpresiones con el tipo de datos adecuado, puede elegir una función de constructor de la ayuda de contenido antes de especificar su argumento o puede escribir manualmente la función. Por ejemplo, si define una métrica de fecha (por ejemplo, para definir un período de tiempo para un ICR), puede utilizar la ayuda de contenido para seleccionar Funciones > date() y, a continuación, Mi modelo de Monitor > Mi contexto de supervisión > Mi suceso de entrada > Datos predefinidos > creationTime. Consulte "Soporte de expresiones" para conocer las expresiones soportadas y ver la definición de esquema de suceso para una lista de atributos válidos.

c. Continúe añadiendo las expresiones de valores de métricas, pulsando Añadir o pulsando dos veces una fila de la tabla hasta que haya especificado todos los modos en los que se puede asignar un valor de la métrica.

3. Definición y características de indicadores

Un indicador es una métrica  o combinación de métricas que proporcionan una visión profunda del proceso de software.Un indicador permite al gestor ajustar el producto, proyecto o proceso a mejorar.

los indicadores del proyecto permiten al gestor:

Evaluar el estado del proyecto en curso. seguir la pista de riesgos. detectar áreas problemáticas antes de que se conviertan en críticas. Ajustar el flujo y tareas del trabajo. Evaluar la habilidad del equipo.Los indicadores del proceso permiten:

Evaluar lo que funciona o no. En la organización permite tener una visión profunda de la eficacia de un

proceso ya existente.

Caracteristicas:

- Medible: anteriormente se ha mencionado que los indicadores son métricas, por tanto su principal característica es que son medibles en unidades. Ejemplo: 1,2, 100, 1000, 1000.000.

- Cuantificable: si se puede medir, se puede cuantificar. Por ejemplo si hablamos de unidades monetaria las cuantificaríamos en € o $. También existen muchos indicadores de gestion que se miden en porcentaje.

- Especifico: se debe centrar en un único aspecto a medir, hemos de ser concretos.

- Temporal: debe poder medirse en el tiempo. Por ejemplo podemos querer medir a diario, de forma semanal, mensual o anual.

- Relevante: el propio término hace referencia a esta característica “indicadores clave de gestión”. Únicamente sirven aquellos factores que sean relevantes para nuestra empresa.

Los indicadores tienen que informar, controlar, evaluar y por último ayudar a que se tomen decisiones. Cada empresa tiene sus propios indicadores de gestión, puesto que cada organización y cada modelo de negocio tienen factores clave a medir diferentes.

En la siguiente imagen se presentan los pasos para definir los KPI que apoyen una estrategia o la evaluación de procesos. Se deben tener metas y definir el responsable de obtenerlas, así como proveer evidencia de si se están cumpliendo o no. Finalmente, se muestran de una manera que permita una precisa interpretación.

Como fue especificado en el alcance, no se incluye la descripción de los pasos para la ejecución del cálculo del indicador, su seguimiento y la generación de acciones que puedan salir de este seguimiento, por esta razón la línea punteada de la imagen. Estas actividades están a cargo del responsable del indicador.

4. Ventajas del uso de métricas

Diversidad: muestran datos sobre otro tipo de resultados de investigación, como conjuntos de datos, presentaciones, software, patentes, monografías, etc.

Otros impactos: no sólo ofrecen información sobre el impacto académico y científico, sino también en otras audiencias y tipos de impacto: social, económico, medioambiental, cultural, etc. 

Ampliación del impacto: amplian la imagen del impacto de una investigación, con datos más allá de las propias citas.

Métricas a nivel de artículo: miden el impacto del artículo o resultado de investigación, no solo de la revista que lo contiene.

Inmediatez de los datos: ofrecen información desde el mismo momento de la publicación e incluso antes.

Contexto: permiten visualizar la acogida de un producto de investigación  y la respuesta inmediata del autor.

Visibilidad: permiten  realizar el seguimiento de la difusión de los resultados de investigación y tomar decisiones para obtener mayor visibilidad e impacto.

Determinar la calidad del producto

Evaluar la productividad de los desarrolladores Conocimiento cuantitativo de las características del proceso y del

producto Se podrán realizar comparaciones con otros proyectos Se podrá mejorar el producto ya que las métricas sirven para detectar

defectos Se tendrá un soporte para la estimación y la planificación

Evaluar los beneficios derivados del uso de nuevos métodos y herramientas de ingeniería de software

Establecer una línea base para la estimación Justificar el uso de nuevas herramientas o de formación adicional

o Limitaciones Falta de normalización: presentan problemas de normalización

tanto para su recopilación como para su uso en la evaluación científica. No están reguladas: al tratarse de herramientas poco controladas,

pueden dar lugar a la manipulación y falsificación. Fiabilidad: no está tan claro que sirvan para medir la calidad científica. Tiempo y dificultad: hacer un seguimiento de las altmetricas puede ser

difícil y llevar mucho tiempo si no se utiliza un proveedor de datos altmétricos.

Saturación: existen muchas medidas y proveedores diferentes, por lo que puede ser difícil determinar cuáles son las más relevantes para la evaluación científica.

Aceptación: aunque se empiezan a tener en cuenta como medidas complementarias de evaluación, en España evaluadores y organismos de financiación aún no las están teniendo en cuenta.

Contexto: el uso de las aplicaciones de la web social puede variar según la disciplina, la ubicación geográfica o a lo largo del tiempo, haciendo difícil interpretarlas.

Falta de correlación: no se ha podido demostrar que exista una correlación clara entre las citas recibidas por un trabajo y las altmetrics cosechadas, aunque esto varía según las fuentes. No obstante, al ser de una naturaleza diferente a las tradicionales y al valorar otros impactos, esta correlación no debería ser determinante.

5. Tipos de métricasUn tipo de métrica define los atributos para una colección de métricas. Normalmente, un tipo de métrica identifica un aspecto del rendimiento, como los ingresos.

Por ejemplo, el tipo de métrica de ingresos puede asociarse a métricas como Ingresos - País o Región, Ingresos - Distrito, Ingresos - Ciudad, etc. Si visualiza un tipo de métrica, IBM® Cognos Metric Studio mostrará las métricas que pertenezcan a ese tipo independientemente de la tabla de puntuación a la que pertenezca la métrica.

Dado que las definiciones de tipos de métrica no suelen almacenarse en las bases de datos existentes, es posible que deba crear el tipo de métrica directamente en Metric Studio.

Puede asignar diagramas e informes a un tipo de métrica de manera que aparezcan en la pestaña de diagrama y de informe de cada métrica de ese tipo.

Un tipo de métrica también puede definir cálculos para el tipo de métrica y para los valores de métrica reales, de destino y de tolerancia. Puede calcular columnas definidas por el usuario mediante ecuaciones definidas por el usuario. El cálculo para el tipo de métrica se aplica a todas las métricas que pertenecen a él. También puede definir un cálculo para una métrica determinada que reemplazará un cálculo definido para el tipo de métrica.

Un tipo de métrica no contiene otros tipos de métrica.

DE USUABILIDAD:

Al evaluar la usabilidad de una interfaz muchas veces oímos (o leemos) esa frase que dice “Hay que contar con las opiniones de los usuarios para adecuar la aplicación a sus necesidades”. Sí, pero con matices importantes. Es cierto que hay que escuchar sus opiniones, pero más importante es saber interpretarlas adecuadamente. Haciendo caso solo de todas las opiniones de los usuarios NO resolveremos todos los problemas. La principal tarea del experto en usabilidad es detectar también aquellos problemas que están implícitos en los comentarios y en el uso. Éstos, la mayoría de veces no se expresan de forma verbal. Una forma de detectar parte de éstos problemas es a través de la medición de métricas. ¿Qué son las métricas de usabilidad? Podríamos definirlas como aquellos criterios o variables que son medibles de forma objetiva. Mientras que la interpretación de una opinión es un análisis cualitativo o subjetivo por parte del experto, la interpretación de datos objetivos responde a un análisis cuantitativo. Este tipo de variables se estructuran, como norma general, en tres grandes grupos: Efectividad: variables que nos permiten medir la exactitud y la plenitud con la que se alcanzan los objetivos de una tarea concreta. Algunas de las variables más típicas son: Porcentaje total de tareas completadas. Porcentaje de tareas completadas en el primer intento. Porcentaje de usuarios que completan las tareas. Ratio de éxitos y fracasos. Número de veces que los usuarios solicitan ayuda por no saber qué hacer. Eficiencia: se refiere al esfuerzo que un usuario tiene que hacer para conseguir un objetivo. Algunas variables típicas son: Tiempo empleado en completar cada tarea. Porcentaje o número de errores cometidos. Porcentaje de errores o problemas según su severidad. Tiempo empleado en recuperarse de los errores. Número de clics realizados para completar una tarea. Número de páginas visitadas para completar una tarea. Tiempo empleado en determinadas páginas o grupos de páginas. Porcentaje o número de veces que se acude a ayudas, FAQ o similar. Satisfacción: se refiere a aquellas que tienen que ver más con lo emocional o subjetivo. Para medir el grado de satisfacción puedes utilizar criterios como: Porcentaje de usuarios que después de utilizar el producto lo recomendaría a un amigo. Proporción de adjetivos positivos o negativos que cada usuario de al producto. Porcentaje de usuarios que califican el producto más fácil de usar que cualquiera de la competencia

directa. Número de veces que el usuario expresa satisfacción o insatisfacción. Además de las reflejadas aquí, es posible crear cualquier otra métrica que resulte de utilidad. Por ejemplo, puedes medir el porcentaje de incremento de ventas que tienes antes y después de hacer un rediseño.

DE CALIDAD:

El concepto de métrica es el término que describe muchos y muy variados casos de medición. Siendo una métrica una medida estadística (no cuantitativa como en otras disciplinas ejemplo física) que se aplica a todos los aspectos de calidad de software, los cuales deben ser medidos desde diferentes puntos de vista como el análisis, construcción, funcional, documentación, métodos, proceso, usuario, entre otros. El concepto de métrica es el término que describe muchos y muy variados casos de medición. Siendo una métrica una medida estadística (no cuantitativa como en otras disciplinas ejemplo física) que se aplica a todos los aspectos de calidad de software, los cuales deben ser medidos desde diferentes puntos de vista como el análisis, construcción, funcional, documentación, métodos, proceso, usuario, entre otros.

DE PUNTO DE FUNCION DE ALBRECHT:

Miden la aplicación desde una perspectiva del usuario dejando de lado los detalles de codificación, estos evalúan con fiabilidad.

El valor comercial de un sistema para el usuario.

Tamaño del proyecto, costo y tiempo de desarrollo.

Calidad y productividad del programados.

Esfuerzo de adaptación, modificación y mantenimiento.

Posibilidad de desarrollo propio.

Beneficios de implementación en 4GL.

METRICAS DE MANTENIBILIDAD DEL SOFTWARE:

Las métricas de mantenibilidad no pueden medir el coste de realizar un cambio particular al sistema software, sino que miden aspectos de la complejidad y la calidad de los programas ya que existe una alta correlación entre la complejidad y la mantenibilidad (a mayor complejidad menor mantenibilidad) y

entre la calidad y la mantenibilidad (a mayor calidad mayor mantenibilidad – y viceversa – ).Existen maneras de medir la mantenibilidad para todos los elementos software que están o estarán sometidos a mantenimiento: código, documentos de usuario, documentos de análisis o diseño, etc.Las métricas del software se pueden clasificar en tres categorías (véase (Kan1, 2002)):

Métricas de producto. Estas métricas describen las características del producto que de alguna forma determinan la mantenibilidad, por ejemplo, el tamaño, complejidad o características del diseño.

Métricas del proceso. Las métricas del proceso pueden ser utilizadas para mejorar el desarrollo y mantenibilidad del software. Algunos ejemplos incluyen la eficacia de eliminar defectos durante el desarrollo, el patrón en el que aparecen los defectos durante las pruebas o el tiempo fijo de respuesta del proceso.Métricas de proyecto. Las métricas de proyecto describen las características y ejecución del proyecto. Por ejemplo, el número de desarrolladores, el patrón de staffing en el ciclo de vida, coste, planificación y productividad del software.

6. Métricas de proceso

Las métricas de proceso se realizan en todo el desarrollo del proyecto con un tiempo determinado, normalmente extenso y son los que permiten al gestor:

Evaluar qué es lo que funciona y lo que no funciona. Obtener un conjunto de indicadores de proceso para llevar a cabo el

mejoramiento en el proceso.

Y a la organización:

Adoptar una visión estratégica.

El proceso es uno de los varios factores controlables para la calidad del software y el buen desempeño organizacional.

En las métricas del software al medir el proceso, existen usos privados y públicos que los explicaremos a continuación:

Métricas privadas

Métricas públicas

Medida Medición Métrica Indicador

o Métricas privadas: Para el uso de cada persona, con las siguientes características:

Índices de defectos. Errores encontrados durante el desarrollo.

o Métricas públicas: A diferencia de la anterior, esta métrica se caracteriza por el uso de todo el equipo y cuenta con las siguientes características:

Índices de defectos. Errores encontrados en revisiones técnicas del proyecto. LDC (Líneas de código producidas). Puntos de fusión por módulo y función.

7. Métricas de proyectoLas métricas del proyecto proporcionan una visión del proceso y los avances detallados acerca del proyecto que se lleva a cabo, y pue den usarse en todo tipo de proyectos.

Estas métricas son efectuadas para conocer el avance o los desvíos al plan original. Pueden ser usadas para medir el estado, efectividad o progreso de las actividades de un proyecto y así contribuir a tomar decisiones estratégicas ante los desvíos, incidentes o diferentes problemas que surgen en la ejecución.

Además, sirven para conocer los resultados de un equipo de trabajo y aumentar la productividad.

En el contexto de un proyecto en las métricas describen las expectativas sobre un determinado entregable o sobre las tareas que se ejecutarán para

producirlo. Por ejemplo, si el entregable del proyecto es “Datos convertidos al nuevo sistema y validados por el cliente interno”, un grupo de métricas podría ser:

¿Cuántas tablas de los sistemas legacy fueron migradas al nuevo sistema hasta hoy? ¿Cuántas tablas del nuevo sistema fueron validadas por el cliente interno hasta hoy? ¿En qué pantallas del sistema se encuentran las tablas convertidas y cuántas de ellas han sido validadas por el cliente interno?

Este conjunto de tres métricas se mediría cada semana durante el proceso de conversión, para tener una idea acerca del avance y los desvíos.

8. Métricas de productoLas métricas de producto permiten medir de forma cuantitativa la calidad de los atributos internos de un producto. Permite evaluar la calidad antes de la construcción y conocer, por ejemplo: la calidad del software, quién lo hace, por qué es importante, cuáles son los pasos, cuál es el producto obtenido, cómo estar seguro de hacerlo correctamente, entre otros.

Estas medidas se utilizan además para comprender los atributos de los modelos que se crean y evaluar la calidad de los productos de la ingeniería o de los sistemas que se construyen.

9. Métricas de calidadPara llegar a la definición de métricas de calidad, es necesario primero definir que es calidad, llegar a un significado o definición global de este término es una cuestión compleja, debido a la pluralidad de definiciones que puede llegar a tener, a continuación se mostraran algunas:

La calidad es el conjunto de propiedades y características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explicitas o implícitas [ISO 8402].

La calidad del software es el grado con el que cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario [IEEE Std 610].

La concordancia con los requisitos funcionales y de rendimientos explícitamente documentados y características implícitas que se espera de

todo software desarrollado profesionalmente [Pressman].

Analizando estas definiciones es posible establecer una general: “Es el grado de respuesta del conjunto de características o propiedades de un objeto, que se le da a los requerimientos establecidos”.

Con esto es posible definir lo es métricas de calidad es “la medida cuantitativa del grado en que un sistema, componente o proceso evalúa su calidad”.

Puntos importantes de la calidad de software:

Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.

Unos estándares específicos definen un conjunto de criterios de desarrollo que guían la manera en que se hace la ingeniería del software. Si no se siguen los criterios, habrá seguramente poca calidad.

Existe un conjunto de requisitos implícitos que a menudo no se nombran. Si el software cumple con sus requisitos explícitos, pero falla en los implícitos, la calidad del software no será fiable.

Existen muchas medidas de calidad del software en las que se encuentran: Exactitud:

Un programa debe operar correctamente o proporcionara poco valor a sus usuarios.

Es el grado en el cual el software realiza la función requerida. La medida más común son los defectos. Los defectos son aquellos problemas reportados por un usuario de

programa.

Capacidad de mantenimiento:

El m a n t e n i m i e n t o y soporte del software r e p r e s e n t a n m á s esfuerzo que cualquiera otra actividad de ingeniería de software.

La capacidad de mantenimiento es la facilidad con la que un programa puede corregirse si se encuentra un error, se adapta a un entorno cambiante o cambio en requerimientos.

Integridad:

Mide la habilidad de un sistema para resistir ataques a su seguridad.

Los ataques pueden hacer a programas, datos y documentación.

Tiene dos atributos adicionales: amenaza y seguridad.

Amenaza es la probabilidad de que un ataque de un tipo específico ocurrirá dentro de un tiempo dado.

Seguridad es la probabilidad de que el ataque de un tipo específico se repelerá.

Integridad = Sumatoria∑ [1 − (𝑎𝑚𝑒𝑛𝑎𝑧𝑎 × (1 − 𝑠𝑒𝑔𝑢𝑟𝑖𝑑𝑎𝑑))]

A continuación se podrá observar una tabla interrelacionada entre las métricas de calidad existentes y una serie de factores de calidad, en la que se muestra factores que son usados por la métrica de calidad y que nos permiten escoger más específicamente que métricas son las adecuadas para evaluar ciertos aspectos de nuestro producto.

10. Otras

11. Organización de un taller sobre el uso de una herramienta de métricas

CheckStyle

CheckStyle es una herramienta de desarrollo que ayuda a los programadores a escribir código que se adhiera a un estándar de codificación. Automatiza el proceso de comprobación de código java. Esto lo hace ideal para los proyectos a los que se desea aplicar un estándar de codificación.

CheckStyle es altamente configurable y se puede hacer para apoyar casi cualquier estándar de codificación. De tal manera que se puedan suministrar diferentes estándares de código para su posterior comprobación mediante la herramienta.

Funcionalidades

● Comentarios JavaDoc: Te permite, por ejemplo, obligar a comentar los nombres de clases, todos los métodos menos los set/get y los atributos públicos.

● Convenciones de nombre: Pueden definir una expresión regular para el nombre de todo.

● Cabeceras: Expresiones regulares para la cabecera de los ficheros.● Imports: Reglas para los imports, como no usar *, imports sin usar, etc.● Violaciones de tamaño: define un máximo para el tamaño de tus clases,

métodos, líneas y números de parámetros de un método.● Espacios en blanco;: Un montón de reglas para definir donde se ponen

espacios en blanco y tabuladores de código.● Modificadores: Establece un orden para los modificadores y evita

modificadores innecesarios.● Bloques: Reglas para los bloques de código y sus llaves.

● Problemas en la codificación: Aca hay de todo, desde malas prácticas tipo asignaciones internas y posibles fuentes de bugs como definir un método equals que no es equals(Object)m a cosas más estéticas o poco prolijas, como que el default sea el último elemento en un switch o paréntesis innecesarios

Requerimientos tecnológicos

● Netbeans 8.1 / Eclipse● Internet● Windows 7 o superior

Tutorial de Instalación y explicación de plugin en CheckStyle Netbeans

https://www.youtube.com/watch?v=w8F_S1DiUaU

o

https://www.youtube.com/watch?v=w-U7yc_VPR4

o

https://www.youtube.com/watch?v=iiTW8rjYaSo

Página de CheckStyle

http://eclipse-cs.sourceforge.net/#!/

Documentación de CheckStyle

http://checkstyle.sourceforge.net/

Plugin de CheckStyle de Netbeans

http://plugins.netbeans.org/plugin/3413/checkstyle-beans

12. Estudio de caso donde se analice la aplicación de métricas de software

FASES DE LA INVESTIGACIÓN PREGUNTAS DE LA INVESTIGACIÓN

ESTUDIO EXPLORATORIO 1. ¿Siguen las empresas desarrolladoras de software en Ecuador un proceso estandarizado o basan esta actividad en la experiencia de su personal?

2. ¿Hacen las empresas ecuatorianas mediciones en las diferentes etapas del ciclo de vida del desarrollo de software?

3. ¿Cuáles son los factores que las empresas consideran

más significativos para ayudar a una mejor gestión de los proyectos de software?

APLICACIÓN PILOTO DEL PLAN DE MÉTRICAS

4. ¿Los resultados observados de las métricas e indicadores propuestos reflejan la situación real del proceso de desarrollo de software de tal forma que se aproxime y sea consistente con la percepción que tienen los administradores acera del estado y avance esperado del proyecto de software?

RESULTADOS (FRP)

El 71% de los proyectos corresponden al desarrollo de “nuevos” proyectos de software.

El 30% de los proyectos evaluados duraron menos de tres meses mientras que un 43% entre 3 y 9 meses.

El 80& de los proyectos se desenvuelve en un entorno de “situación de negocio difícil”.

Solo un 29% de los proyectos terminaron el 80% de sus tareas planificadas dentro del plazo establecido para hacerlo.

La mayor cantidad de defectos aparecen durante las fases de construcción (35%) y pruebas (36%).

Solo el 20% de los proyectos detectaron y resolvieron más del 90% de los defectos en la aplicación de software.

RESULTADOS DE PLAN DE MÉTRICAS

Conclusiones

El uso de métricas en la mayoría de empresas es ocasional y depende mucho del estado y avance del proyecto, ya que al experimentar retrasos la actividad de recopilación de datos para la formación de métricas se suspende, debido a que la documentación del proyecto se posterga o no se realiza.

13. Explicación del uso de una herramienta de métricas de software (4 ejemplos)

Software de métricas 01

PMD

PMD es una herramienta que prueba que nuestra aplicación cumpla una serie de reglas que nos ayudan a obtener un código más elegante, sencillo y mantenible. Estas reglas se agrupan por conjuntos y pueden ser reglas de complejidad, como que la complejidad ciclomática no sea demasiado alta; de diseño, como no usar interfaz como meros contenedores de constantes; de optimización, como procurar utilizar arraylist en lugar de vector; etc.

PMD se puede utilizar desde línea de comandos,o puede integrarse con multitud de IDEs y herramientas como Eclipse, Netbeans, Maven o JEdit. Y Aunque algunos de los casos que comprueba PMD ya se tengan en cuenta en Eclipse, sigue siendo una utilidad muy interesante para añadir a nuestra caja de herramientas.

Requerimientos tecnológicos

● Netbeans 8.1● Internet● Window 7 o superior

Funcionalidades

● Detectar duplicación de código.● Detectar código muerto(Variables, parámetros o métodos sin usar).● Detectar complejidad de métodos.● NPlathComplexity: es el número de rutas de ejecución a cíclicos a través

de ese método.● ExcessiveMethodLength: el método está haciendo demasiado.● ExcessiveParameterLsit: Lista de parámetros largos pueden indicar que

un nuevo objeto debe ser creado para envolver los numerosos parámetros

● ExcessiveClassLength: Archivos de clase largos son indicios de que la clase puede estar tratando de hacer demasiado..

● Complejjidad ciclomatica: Complejidad se determina por el número de puntos de decisión en un método más uno para la entrada metodo.

● ExcessivePublicCount: Puede necesitar un gran número de métodos y atributos declarados en una clase puede indicar la clase de públicos para romperse como requerirá un mayor esfuerzo para poner a prueba a tope.

● TooManyFields: Las clases que tienen demasiados campos podrían ser rediseñados con pocos campos, posiblemente a través de algún objeto agrupación anidada de parte de la información.

● NcssMethodCount: Esta regla utiliza el algoritmo NCSS para determinar el numero de lineas de codigo para un método dado. NCSS ignora los comentarios y cuenta las declaraciones reales.

● TooManyMethods: Una clase con demasiados métodos es probablemente un buen objetivo para la refactorización, con el fin de reducir su complejidad y encontrar una manera de tener objetos de grano más fino.

Software de métricas 02

CheckStyle

CheckStyle es una herramienta de desarrollo que ayuda a los programadores a escribir código que se adhiera a un estándar de codificación. Automatiza el proceso de comprobación de código java. Esto lo hace ideal para los proyectos a los que se desea aplicar un estándar de codificación.

CheckStyle es altamente configurable y se puede hacer para apoyar casi cualquier estándar de codificación. De tal manera que se puedan suministrar diferentes estándares de código para su posterior comprobación mediante la herramienta.

Requerimientos tecnológicos

● Netbeans 8.1 / Eclipse● Internet● Windows 7 o superior

Funcionalidades

● Comentarios JavaDoc: Te permite, por ejemplo, obligar a comentar los nombres de clases, todos los métodos menos los set/get y los atributos públicos.

● Convenciones de nombre: Pueden definir una expresión regular para el nombre de todo.

● Cabeceras: Expresiones regulares para la cabecera de los ficheros.● Imports: Reglas para los imports, como no usar *, imports sin usar, etc.● Violaciones de tamaño: define un máximo para el tamaño de tus clases,

métodos, líneas y números de parámetros de un método.● Espacios en blanco;: Un montón de reglas para definir donde se ponen

espacios en blanco y tabuladores de código.● Modificadores: Establece un orden para los modificadores y evita

modificadores innecesarios.

● Bloques: Reglas para los bloques de código y sus llaves.● Problemas en la codificación: Aca hay de todo, desde malas prácticas

tipo asignaciones internas y posibles fuentes de bugs como definir un método equals que no es equals(Object)m a cosas más estéticas o poco prolijas, como que el default sea el último elemento en un switch o paréntesis innecesarios.

● Diseño de clases: Varias reglas sobre el diseño de interfaces y clases, con especial atención en las excepciones.

● Duplicados: Te permite definir un mínimo de líneas para buscar codigo duplicado en tus clases.

● Métricas: Define máximo para métricas como complejidad ciclomática, complejidad de expresiones lógicas , npath, líneas de código seguidas sin comentar y dependencia de clases.

● Misceláneo: Variables final, indentación, un buscador de expresiones regulares y varias cosas mas.

● J2EE: Reglas para EJBs.● Otros: Internos de CheckStyle y activados por defecto.● Filtros: Para eventos de auditoría del propio CheckStyle, no hace falta

mirarlos.

Software de métricas 03

COCOMO II

(Constructive Cost Model) surge como una alternativa para incluir componentes de incerteza en las estimaciones conforme al nivel de información disponible. Este es un modelo paramétrico que establece ecuaciones matemáticas para describir las relaciones entre el tamaño del software - factor primario de costo usualmente representado en términos de puntos de función - y otros factores secundarios que buscan capturar particularidades de producto, proceso, personas y plataforma. Esos factores son denominados Cost Drivers, siendo algunos de efecto proporcional y otros de efecto exponencial.

El modelo ofrece un framework completo para determinar factores de productividad locales(Constantes de productividad) a partir de datos como el plazo y el esfuerzo de proyectos pasados. Una de las principales virtudes de COCOMO II es ofrecer una estimación de plazo y esfuerzo, y a partir de estos sugerir el tamaño del equipo y no lo opuesto; como sucede generalmente.

Funcionalidades

● Hacer que la inversión u otras decisiones financieras que implican un esfuerzo de desarrollo de software.

● Configuración de los presupuestos y programas de proyectos como base para la planificación y el control.

● Decidir o negociar compensaciones entre los factores de costo de software, programación, funcionalidad, rendimiento o calidad.

● Hacer costos de software y las decisiones de gestión de riesgo horario.● Decidir qué partes de un sistema de software para desarrollar,

reutilización, arrendamiento o compra.● Decisiones de inventario de software legado hacer: que partes se

modifican, eliminar gradualmente, extemalizar.● Establecer estrategias de inversión mixtos para mejorar la calidad del

software de la organización, a través de la reutilización, las herramientas, la madurez del proceso, la subcontratación, etc.

Ejemplo de aplicación

https://www.youtube.com/watch?v=nRchCHu4tL0

Software de métricas 04

Resource Standard Metrics, or RSM

11.2. Requerimientos tecnológicos

Requisitos de hardware

● RSM utiliza 1,0 a N megabytes de memoria (virtual) + físicas en función del número de archivos de origen procesados.

● RSM requiere espacio de disco para el almacenamiento de informes. Los requisitos de espacio dependen del número y tamaño de los informes.

Requisitos de Software

● RSM se procesa ningún archivo de longitud y cualquier número de archivos hasta que su memoria local se ha agotado.

● RSM se ejecutará precompilado en Windows 9x, Windows NT / 2000 / XP / Vista y Linux.

● RSM licencias UNIX vienen con el código fuente y son conocidos para compilar en Mac OS X, OS Sun, Sun Solaris, HP-UX, SGI IRIX, IBM AIX y Linux.

Funcionalidades

Recursos Standard Metrics es una herramienta de métricas de código fuente y análisis de calidad para ANSI C, ANSI C ++, C # y Java para su uso en todos los sistemas operativos Windows y UNIX. La velocidad, facilidad de uso y portabilidad de los RSM que sea diferente a cualquier otra herramienta de análisis de código fuente en el mercado hoy en día. RSM proporciona métricas estándar y análisis de código fuente automatizado y es indispensable para cualquier empresa que desea obtener la certificación ISO-9001, TickIT y certificaciones SEI.Ahora su empresa puede correr la misma herramienta en varios idiomas, en múltiples sistemas operativos, la creación de un estándar más alto para su colección de métricas y la calidad del código fuente.

Características principales

● Utilice una herramienta a través de todos los sistemas operativos - Instalación RSM

● Utilice una herramienta a través de todos los idiomas del proyecto para K & R y C ANSI, ANSI C ++ y Java 2.0+ - Opciones e Informes de RSM

● No hay limitaciones a la longitud del archivo, proyectos de número de archivos o el uso, RSM ha procesados que consta de más de 10.000 archivos y 7.000.000 líneas de código

● Utilizar RSM para satisfacer ISO9001, TickIT, el cumplimiento de los niveles 3 y 4 de SEI

● Determinar exactamente cómo RSM ve su código - determinista Informe● Recoger 100 de Código Fuente Métrica por la función, clase, archivo, y

el proyecto - RSM Métrica● Recoger estándar de la industria y del objeto funcional métricas

orientadas - RSM Métrica● Realizar mediciones entre dos líneas de base de código - Línea de base

Diferenciales● Crear factores laborales y de estimación de costos de las métricas -

Factores de estimación

● Analizar el código fuente desde hace más de 50 años los errores de programación latentes que los compiladores se pierda - Análisis de Calidad de RSM

● Analizar el código fuente de la aplicación de estilo de código - Análisis de Calidad de RSM

● Crear un árbol de herencia directamente del código - Herencia Árbol● Analizar la herencia de clases del sistema por la profundidad y la

derivación● Interactiva con Visual Studio 6.0 - Estudio de Integración Visual● Interactiva con Visual Studio .Net - Visual Studio .NET Integración● Integrado con JBuilder - JBuilder● Integrado con Eclipse - Eclipse● Comentario extraer y cuerdas de corrección ortográfica y

comprensibilidad - Comentarios Extracción Cadena Extracción ● Generar código fuente imprimible con los números de títulos, línea y de

página - Código de Formato de Impresión● Regenerar código fuente para quitar las pestañas, y convertir entre DOS

y Unix - Modo De-Carácter● Crear informes en HTML con hipervínculos en el código - Modo de salida

HTML● Crear informes en formato CSV para la entrada directa a MS hojas de

cálculo Excel - CSV Informes● Crear informes en XML con XSL traducción opcional para informes

personalizados - Informe XML ,XML / XSL Informe● Crear informes en formato de texto para la pantalla, imprimir y la

importación en los documentos - Textos de mensajes● la operación de línea de comandos simple con opciones de tiempo de

ejecución - Opciones de RSM e Informes● RSM es ideal para recogida automática de métricas de código de rutinas

de script - RSM Operación● El producto es de cinco años maduro y utilizado por las compañías líder

a nivel mundial - Muestra Base de usuarios● Disponible en las licencias de un solo usuario, Red y del sitio para la

solución de las métricas más rentables y análisis de código en el mercado hoy en día. - Formulario de Pedido métricas estándar de recursos

http://msquaredtechnologies.com/m2rsm/docs/tutorials/command_line_differentials/RSM%20Diff%20Command%20Line%20Tutorial.pdf

14. Conclusión

Como se logró apreciar en esta investigación las métricas son realmente importantes a la hora de garantizar un software de calidad, sin embargo, el saber que existen no quiere decir que sepamos cuales son y de que trata cada una por lo que al sumergirse en este mundo de las métricas adoptamos una posición mucho más crítica a la hora de escoger la métrica que debemos usar en nuestro proyecto de software.

15. Bibliografía http://www.ibm.com/support/knowledgecenter/es/SSBN76_7.0.1/

com.ibm.btools.help.monitor.dev.doc/mme/definingmetrics.html https://www.ibm.com/support/knowledgecenter/es/SSEP7J_10.1.1/

com.ibm.swg.ba.cognos.ug_mm.10.1.1.doc/c_cmm_intro_metric_types.html http://metricasneider.blogspot.com.co/2008/11/tipos-de-matricas.html http://www.marcoteorico.com/curso/91/ingenieria-de-software/862/medida-

metrica-e-indicador http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/

capitulo4.pdf http://sw-ufps.blogspot.com.co/2011/05/metricas-aplicadas-al-software.html http://robertoespinosa.es/2016/09/08/indicadores-de-gestion-que-es-kpi/ https://planeacion.uniandes.edu.co/dmdocuments/INS-45-1-01-

04%20Definicion%20de%20Indicadores%20de%20Desempeno.pdf http://guiasbus.us.es/altmetrics/ventajas