Esta presentacion nos menciona que son las metricas, sus caracteristicas, usos, utlilidades y tipos.

1. METRICAS INGENIERIA DE SOFTWARE

2. DEFINICION Una métrica es una medida efectuada sobre los programas, documentación, su desarrollo y mantenimiento, o sobre algún aspecto del sistema en desarrollo o del proceso empleado que permite, previa comparación con unos valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar las decisiones necesarias. 2 © Marisol Viramontes Aguilar, Claudia Pérez Becerra, Alan Josué González de la Cruz, Ricardo Esparza Peña.

3. DEFINICION Una métrica no es un objetivo en sí mismo sino un medio para controlar el desarrollo de un sistema de software. El proceso de planificación del desarrollo de cualquier sistema debe hacerse partiendo de una estimación del trabajo a realizar. Sólo a partir de ello es factible conocer los recursos necesarios y el tiempo necesario para su realización. 3 © Marisol Viramontes Aguilar, Claudia Pérez Becerra, Alan Josué González de la Cruz, Ricardo Esparza Peña.

4. DEFINICION La estimación precisa de ciertas métricas como el esfuerzo de desarrollo es indispensable para la adecuada planificación de las actividades de desarrollo y mantenimiento. 4 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

5. DEFINICION Por ejemplo,Para aplicar el sistema de calidad al ciclo de vida es necesaria la utilización de métricas adecuadas que permitan medir la calidad del proyecto. (En realidad, comparamos los parámetros de calidad de éste con estimaciones realizadas mediante el uso de estándares o datos que aporta la experiencia en otros proyectos). 5 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

6. CALCULO DE METRICAS 6 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

7. VENTAJAS DEL USO DE METRICAS 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. 7 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

8. VENTAJAS DEL USO DE METRICAS Se tendrá un soporte para la estimación y la planificación. Evaluar los beneficios (en cuanto a calidad y productividad) derivados del uso de nuevos métodos y herramientas de ingeniería del software. Establecer una línea base para la estimación. Justificar el uso de nuevas herramientas o de formación adicional. 8 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

9. CARACTERISTICAS DE LAS METRICAS Exactas Precisas: No se debe perder información en los redondeos ya que la información se desvirtúa. Consistentes: Una medición de un atributo debe dar el mismo valor independientemente de la medición. Comparables: Para ello, debe estar normalizada. 9 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

10. PROCESO PARA LA ADOPCION DE METRICAS Fase de aprendizaje: No se tienen métricas y es necesario realizar muchas medidas porque no se sabe cuál son las métricas útiles. Esto implica mucho esfuerzo y poco beneficio. Fase de uso: Una vez que se tienen las métricas, el esfuerzo es cada vez menor y aumenta el beneficio. 10 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

11. USO DE LAS METRICAS Las métricas deben ser implantadas paso a paso en cinco niveles, correspondientes al nivel de madurez del proceso de desarrollo. El marco del nivel de madurez del proceso de desarrollo fue establecido por la SEI 11 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

12. USO DE LAS METRICASProceso Inicial (Nivel 1) Su objetivo es formar una base de comparación con la forma en que las mejoras se realicen y se incremente la madurez, estos incluyen: a) El tamaño del producto. b) El esfuerzo del personal (Utilidades para determinar una tasa de productividad). 12 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

13. USO DE LAS METRICASProceso Repetible (Nivel 2) Las métricas a este segundo nivel incluyen como objetivos de medición: 1. La cantidad de esfuerzo necesaria para desarrollar un sistema 2. La duración del proyecto 3. El tamaño y la volatilidad de los requerimientos 13 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

14. USO DE LAS METRICASProceso Repetible (Nivel 2) 4. El costo global del proyecto (Por lo que el tipo de métrica que se recomiendan incluye a las siguientes): a) Tamaño del software (Líneas de codillo fuente no comentadas) b) Puntos de Función c) Cuenta de objetos y métodos 5. Esfuerzo del trabajo de personal: a) Esfuerzo real medido en unidades persona/mes b) Esfuerzo reportado en unidades persona/mes 14 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

15. USO DE LAS METRICASProceso Repetible (Nivel 2) 6. Volatilidad de los requerimientos (Cambios de los requerimientos). Éstas como métricas principales, además las siguientes pueden añadirse a consideración de la administración del proyecto de software: 7. Experiencia (del dominio o aplicación, de la arquitectura de desarrollo utilizada, de las herramientas y métodos empleados, años globales de experiencia en el desarrollo) 8. Rotación de personal 15 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

16. USO DE LAS METRICASProceso definido (Nivel 3) En este nivel de madurez, se recomienda evaluar la complejidad de los requerimientos, el diseño, el código y los planes de prueba, y evaluar la calidad de los requerimientos del diseño del código y de las pruebas. En términos de complejidad, se sugiere que los siguientes puntos se midan a este nivel: 16 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

17. USO DE LAS METRICASProceso definido (Nivel 3) 1. Complejidad de los requerimientos (Número de distintos objetos y acciones llevadas a cabo en los requerimientos). 2. Complejidad del Diseño (Número de módulos de diseño, Complejidad Ciclomática, Complejidad de Diseño de McCabe. 3. Complejidad del Código (Números de Módulos de Código, Complejidad Ciclomática. 17 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

18. USO DE LAS METRICASProceso definido (Nivel 3) 4. Complejidad de las pruebas (Número de Caminos a probar, Si el desarrollo es orientado a objetos, debe de considerarse el número de interfaces de objetos a probar. Se puede evaluar la minuciosidad de las pruebas. Así, por mencionar algunas métricas recomendadas de calidad, podemos decir las siguientes: 18 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

19. USO DE LAS METRICASProceso definido (Nivel 3) a) Defectos descubiertos. b) Defectos descubiertos por unidad de tamaño (densidad de defectos). c) Fallas de requerimientos descubiertos. d) Fallas de diseño descubiertas. e) Fallas de Código descubiertas. f) Densidad de fallas por cada producto. 19 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

20. USO DE LAS METRICASProceso definido (Nivel 3) Se enfatiza que este conjunto no es representativo del espectro completo de medidas que pueden ser empleadas. Aspectos tales como facilidad de mantenimientos, grado de utilización facilidad de uso y otros atributos de calidad de software que no son considerados por la cuenta de defectos. 20 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

21. USO DE LAS METRICASProceso Administrado (Nivel 4) En este nivel la retroalimentación determina cómo son asignados los recursos pues las actividades básicas por sí mismas no cambian. Las métricas recolectadas son utilizadas para encontrar y estabilizar el proceso, así la productividad y la calidad coinciden con las expectativas. Se recomienda por lo tanto recolectar información al respecto de los siguientes aspectos: 21 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

22. USO DE LAS METRICASProceso Administrado (Nivel 4) Tipo de proceso,se refiere a qué tipo de modelo se utiliza para el desarrollo de software. Cantidad de rehusó del productor,este aspecto se relaciona con que tanto se diseña el software para su rehusó. Cantidad de rehusó del Consumidor,Este aspecto es establecido en consideración a cuanto rehúsa un proyecto componentes de otros aspectos. Identificación de defectos,se relaciona con cómo y cuándo se descubren los defectos. 22 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

23. USO DE LAS METRICASProceso Administrado (Nivel 4) Uso de la densidad de defectos para las pruebas,se relaciona con la extensión del número de defectos que determina cuándo están completas las pruebas. Uso de la administración de la configuración,cuestiona acerca de que si la configuración de la administración es un esquema impuesto sobre el proceso de desarrollo. Terminación de módulos sobre tiempo,considera en qué porcentaje los módulos están siendo debidamente terminados. 23 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

24. USO DE LAS METRICAS Optimización del Proceso (Nivel 5) A este nivel las métricas de las actividades son utilizadas para mejorar el proceso. Como ejemplo a ello, y como parte del desarrollo de esta investigación, se constato que de las cuatro empresas que se han considerado como entidades a entrevistar (Icave, Tamsa, C.F.E) de todas ellas solo dos de ellas (C.F.E., Tamsa) se encuentran en los niveles 4 o 5 niveles del modelo de madurez, por lo que las métricas recomendadas sólo incluyen los primeros cuatro niveles, es decir, estas entidades aún no cumplen con ciertas métricas y prácticas que los lleven al 100% al máximo nivel de madurez. 24 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

25. Utilidad de las Métricas Las métricas se utilizan para evaluar y controlar el proceso de desarrollo del software, de forma que permitan: - Indicar la calidad del producto. - Evaluar la productividad de los desarrolladores. - Evaluar los beneficios (en cuanto a calidad y productividad). - Derivados del uso de nuevos métodos y herramientas de ingeniería del software. - Establecer una línea base para la estimación. - Justificar el uso de nuevas herramientas o de formación adicional. 25 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

26. Utilidad de las Métricas Pero es necesario utilizar las métricas más adecuadas para conseguir el control, seguimiento y mejora de la calidad, y para ello es necesario determinar los factores de calidad más importantes dentro del proyecto. - Medición “objetiva antes que subjetiva” - Especificar en el mundo formal, la correspondencia de un atributo del mundo empírico - Operacionalizar Heurísticas 26 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

27. Utilidad de las Métricas - Servir de “base” a Métodos Cuantitativos de Evaluación o Predicción. - La métrica NO puede interpretar por sí sola un concepto medible (Necesidad de INDICADORES) ¿Qué son los indicadores? El método de cálculo y la escala definidos, además del modelo y criterios de decisión con el fin de proveer una evaluación o estimación de un concepto medible con respecto a una necesidad de información. 27 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

28. TIPOS DE METRICAS DEL PRODUCTO Tamaño Estructura de datos Lógica DEL PROCESO Tiempo de desarrollo Reusabilidad Productividad 28 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

29. Métricas del software Métricas de tamaño Métricas de estructuras de control Métricas compuestas Métricas de esfuerzo Métricas de calidad y fiabilidad Métricas de diseño Otras métricas del software 29 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

30. Métricas de tamaño. Los programas se escriben en lenguajes muy distintos y con propósitos muy diferentes, usando técnicas y métodos dispares, pero con una característica común: tienen un tamaño. Este tamaño se determina habitualmente tomando como referencia el programa en código fuente El tamaño es una medida empleada fundamentalmente por tres razones: es fácil de obtener una vez que el programa ha sido completado, es uno de los factores más importantes en los métodos de desarrollo, y la productividad se expresa tradicionalmente con el tamaño del código. La medida de tamaño más usada es la cantidad de líneas de código que se representa como Ss, y se mide en LOC (Lines Of Code, líneas de código). Para programas grandes es más adecuado el uso de KLOC (miles de líneas de código) representadas como S. 30 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

31. Métricas de estructuras de datos. Una de las razones fundamentales de la programación es el proceso de datos. Parte de estos datos constituyen la entrada del sistema, parte tiene un uso exclusivamente interno y, por último, una tercera parte constituye la salida del sistema. Así pues, disponer de un conjunto de métricas con el que medir la cantidad de datos usado en la entrada, la salida, e internamente resultará de utilidad para valorar el software. Este conjunto es el formado por las métricas de estructuras de datos que atienden a la cantidad de datos, al uso que se les da, y a su aparición en distintas partes del sistema. 31 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

32. Métricas de estructuras de datos. Un método para determinar la cantidad de datos es contar las entradas de la tabla de referencias cruzadas asociada al código. Esta tabla contiene fundamentalmente las variables del programa, aunque también puede incluir otros elementos como etiquetas, tipos, o el propio nombre del programa. En general, se puede considerar datos de un programa todos aquellos elementos no pertenecientes al lenguaje (instrucciones, signos, operadores, constantes de todo tipo) que aparecen a lo largo del código. 32 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

33. Métricas de estructuras de datos. El proceso de programación, que depende casi en exclusiva del esfuerzo humano, debe contar con las limitaciones de la mente. Una de estas limitaciones se refiere a la cantidad de información diferente que puede tener una persona "en mente" al tiempo que realiza una tarea determinada. 33 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

34. Métricas de estructuras de datos. El concepto de variables vivas en una instrucción determinada representa esta limitación. Las variables tienen un periodo de vida que empieza con su primer uso (no con la declaración) y termina con la última mención que se hace de una de ellas. El número de variables vivas en una instrucción determinada indica la cantidad de información que el programador debe tener presente al construir el código. LV (variables vivas) indica la complejidad del código en un punto determinado (al margen de la propia complejidad del algoritmo desarrollado). Una medida global referida a todo el código sería el número medio de variables vivas por instrucción (LV ) que puede servir como referencia en comparaciones entre distintos programas. 34 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

35. Métricas de estructuras de control. La estructura lógica de un programa es el mecanismo que le permite realizar las distintas funciones para las que fue construido. La estructura lógica del programa representa los algoritmos empleados en su diseño y procesa los datos. La estructura de un algoritmo se representa perfectamente con las gráficas denominadas diagramas de flujo. Son muchos los métodos de medición del software que se basan en estos diagramas. 35 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

36. Métricas de estructuras de control. El flujo de control en un programa es habitualmente secuencial, aunque puede ser interrumpido en ciertas ocasiones: En una decisión, se divide en dos nuevas líneas de flujo que responden a la evaluación de una condición determinada. Un salto hacia atrás devuelve el flujo de control a una instrucción que ya ha sido ejecutada. Normalmente son la base de los bucles. Una transferencia de control a una rutina o procedimiento externo, hace que el flujo discurra por un camino externo al programa. 36 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

37. Métricas de estructuras de control. La métrica denominada cuenta de decisión (DE) mide la cantidad de veces que ocurren situaciones como las mencionadas en primer y segundo lugar. Esto es, cuenta el número de instrucciones de decisión y bucles condicionales. A la hora de contar decisiones debe tenerse en cuenta los casos en que estas son compuestas, en esta situaciones DE cuenta predicados más que instrucciones en sí, por lo que las situaciones en las que se usan los operadores AND y OR incrementan en más de uno el valor de DE(algo similar ocurre con instrucciones del tipo CASE). 37 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

38. Métricas Compuestas Las medidas descritas hasta ahora miden una única magnitud para darle sentido como una característica del software. Sin embargo, ocurre con frecuencia que para describir una determinada cualidad del software es preciso componer (construir un par) de medidas simples. 38 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

39. Métricas de esfuerzo. El desarrollo del software es una actividad humana que depende en gran medida del trabajo personal. A la hora de valorar un sistema software debe considerarse la cantidad de esfuerzo que debe invertir el equipo de desarrollo para culminar su construcción. El coste del desarrollo es prácticamente el del trabajo empleado, pues la parte asignada a materiales es de tan poca entidad que resulta despreciable frente a la mano de obra.El esfuerzo requerido para construir un sistema puede ser medido con muchas unidades. 39 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

40. Métricas de esfuerzo. El número real de horas y minutos que invierte un programador, es enorme, sin embargo hay una medida que destaca por su universalidad: la personames o meses -hombre. Por otra parte, aunque el esfuerzo es muy importante, en realidad la más importante métrica del esfuerzo es el coste. La importancia de la medida del esfuerzo y coste responde más a necesidades de tipo administrativo y de gestión que estrictamente técnicas. 40 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

41. Métricas de esfuerzo. Otro elemento importante al trabajar a escala reducida es el tiempo de comprensión y aprendizaje que el programador requiere para comprender los requerimientos, el diseño, o cualquier documento previo a la codificación. Aprender a manejar las herramientas y lenguajes, conocer los interfaces, la metodología empleada, etc. Supone retrasos importantes en proyectos unipersonales. 41 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

42. Métricas de calidad y fiabilidad. El estudio de la calidad y fiabilidad tiene una importancia cada vez mayor en el mundo de la Ingeniería del Software. No sólo se trata de obtener sistemas desarrollados correctamente, de acuerdo a los requerimientos y a los estándares establecidos, sino que se pretenda conseguir programas fáciles de mantener y, lo que es más importante, sistemas fiables en tareas críticas. 42 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

43. Métricas de calidad y fiabilidad. A pesar de los avances en las técnicas de generación de código, no se pueden producir programas totalmente libres de errores. De esta forma, entre las distintas fases del ciclo de desarrollo se van filtrando una serie de errores que obligan a emplear mucho esfuerzo en su detección y corrección. 43 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

44. Métricas de calidad y fiabilidad. Los errores de codificación, con ser los más conocidos, no son los más importantes, son los más tratados pues es más simple automatizar su detección. Los errores en las pruebas son muy importantes pues dan por válido un código que no lo es, y permiten que se entregue un sistema defectuoso. Los errores de mantenimiento pueden deberse a la ignorancia de fallos antiguos o a la introducción de otros nuevos. 44 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

45. Métricas de calidad y fiabilidad. La prueba del software se encarga de someter un programa a una revisión de todos los estados posible por los que puede atravesar en algún momento de su vida útil. Los tres objetivos que dirigen la prueba del software son: La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces. Sin embargo, la característica más destacable de la prueba del software es que la prueba no puede asegurar la ausencia de defectos: sólo puede demostrar que existen defectos en el software. 45 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

46. Métricas de diseño Como ya se ha visto por las distintas métricas estudiadas, la complejidad de un programa crece con su tamaño: los programas largos son más difíciles de escribir y comprender, contienen habitualmente más errores, y su depuración resulta más compleja. Con objeto de reducir esta complejidad, los diseñadores de software han hecho un uso progresivo de técnicas de modularización y diseño estructurado. 46 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

47. Métricas de diseño Entre las diversas ventajas de las técnicas de diseño se pueden destacar las siguientes: Comprensibilidad: programadores y usuarios pueden comprender fácilmente la lógica del programa. Manejabilidad: los gestores pueden asignar fácilmente personal y recursos a los distintos módulos representados por tareas. 47 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

48. Métricas de diseño Eficiencia: el esfuerzo de implementación puede reducirse. Reducción de errores: los planes de prueba se simplifican notablemente. Reducción del esfuerzo de mantenimiento: la división en módulos favorece que las distintas funciones las lleven a cabo módulos diferenciados. 48 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

49. Otras métricas del software. Además de las mencionadas, existen algunas otras métricas que valoran ciertos aspectos del software. Las métricas de reusabilidad tratan de medir el grado en que un elemento software puede ser empleado por otros programas, en otras palabras, su independencia. Debido a que es difícil valorar objetivamente esta independencia, la referencia más común es la independencia del hardware expresada en número de cambios en el código al adaptar un programa a una nueva plataforma. 49 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

50. Otras métricas del software. Esta medida puede ampliarse al número de cambios realizados en el código por líneas al adaptarlo a un nuevo sistema operativo, o a un nuevo sistema gráfico. Las métricas de portabilidad valoran aspectos muy similares. Las métricas de mantenibilidad se enuncian como función de los valores de concisión, consistencia, instrumentación, modularidad, auto documentación y simplicidad. 50 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

51. Otras métricas del software. Las métricas de testeabilidad (o capacidad de probar el software) son función de la auditabilidad (capacidad de someter el software a auditoría), la complejidad de software (ciclomática, contando los GOTO y bucles, o según los valores de la Ciencia del Software), instrumentación, modularidad, auto documentación y simplicidad. Las de flexibilidad tienen como componentes a la complejidad, la concisión, la consistencia, la expansibilidad, la generalidad, la auto documentación, y la simplicidad. 51 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.

52. Otras métricas del software. La interpretación que se da de los componentes de cada una de estas métricas es, no obstante, discutible e imprecisa, sin un método definido para obtener una valoración. También se carece de expresiones que determinen el peso que cada componente tiene en la métrica. 52 © Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo Esparza Peña.