m e t r i c a s i n g e n i e r i a d e s o f t w a r e

52
METRICAS INGENIERIA DE SOFTWARE

Upload: ricardo

Post on 04-Jul-2015

993 views

Category:

Economy & Finance


1 download

DESCRIPTION

esta presentacion nos dice que es una metrica, sus caracteristicas, usos, utilidad, tipos.

TRANSCRIPT

Page 1: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

METRICAS

INGENIERIA DE SOFTWARE

Page 2: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 3: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 4: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 5: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 6: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

CALCULO DE METRICAS6

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

Page 7: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 8: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 9: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 10: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 11: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 12: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 13: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 14: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

USO DE LAS METRICASProceso Repetible (Nivel 2)

4. El costo global del proyecto (Por lo que el tipo demétrica que se recomiendan incluye a las siguientes):

a) Tamaño del software (Líneas de codillo fuente no comentadas)

b) Puntos de Funciónc) Cuenta de objetos y métodos

5. Esfuerzo del trabajo de personal:

a) Esfuerzo real medido en unidades persona/mesb) Esfuerzo reportado en unidades persona/mes

14

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

Page 15: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 16: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 17: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 18: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 19: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 20: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 21: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 22: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 23: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 24: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 25: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 26: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 27: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

Utilidad de las Métricas

- Servir de “base” a Métodos Cuantitativos deEvaluación o Predicción.

- La métrica NO puede interpretar por sí sola unconcepto medible (Necesidad de INDICADORES)

¿Qué son los indicadores?

El método de cálculo y la escala definidos, ademásdel modelo y criterios de decisión con el fin deproveer una evaluación o estimación de un conceptomedible con respecto a una necesidad deinformación.

27

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

Page 28: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 29: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 30: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 31: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 32: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 33: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 34: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 35: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 36: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 37: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 38: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 39: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 40: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 41: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 42: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 43: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 44: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 45: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 46: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 47: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 48: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 49: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 50: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 51: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.

Page 52: M E T R I C A S  I N G E N I E R I A  D E  S O F T W A R E

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.