Metricas Ingenieria De Software

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.

© 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.

© 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.

© 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).


6

CALCULO DE METRICAS


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.


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.


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.


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.


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


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).


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


14


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

15


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© 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:


17


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.


18


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:


19


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.


20


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.


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:


22


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.© Marisol Viramontes Aguilar, Claudia Perez Becerra, Alan Josue Gonzalez de la Cruz, Ricardo

Esparza Peña.

23


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.


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.


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

26


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


27


- 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.


28

TIPOS DE METRICAS

DEL PRODUCTO Tamaño Estructura de datos Lógica

DEL PROCESO Tiempo de desarrollo Reusabilidad Productividad


29

Métricas del software

Métricas de tamañoMétricas de estructuras de controlMétricas compuestasMétricas de esfuerzoMétricas de calidad y fiabilidadMétricas de diseñoOtras métricas del software


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.


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.


32


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.


33


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.


34


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.


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.


36


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.


37


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).


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. © 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.


40


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.


41


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.


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.


43


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.


44


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.


45


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. © 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.


47


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.


48


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.© 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.


50


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.


51


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.


52


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.


Metricas Ingenieria De Software

Career

Transcript of Metricas Ingenieria De Software