Clase Práctica No. 1: Métricas de Calidad de Software: Listas de comprobación.

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Clase Práctica No. 1: Métricas de Calidad de Software: Listas de comprobación."

Eugenia Toledo Gallego
hace 6 años
Vistas:

1 Introducción a la Gestión de Software Actividad # 2 Tema 1. Calidad de Software. Clase Práctica No. 1: Métricas de Calidad de Software: Listas de comprobación. Temario: Introducción Métricas de calidad del Modelo McCall. Listas de comprobación. Conclusiones Bibliografía: 1. Pressman, Roger S. Ingeniería de Software. Un enfoque práctico. Editorial Félix Varela, Cuba, Capítulo 4. Epígrafe 4.5. Métricas para la calidad del software. Capítulo 19. Métricas técnicas del software. 2. Material Modelos de Calidad disponible en la red. 3. Listas de chequeo para los roles de programador y diseñador disponibles en la red. Objetivos: Que los estudiantes sean capaces de: Identificar los factores y criterios del Modelo McCall. Construir listas recomprobación. INTRODUCCIÓN Los problemas a los que nos enfrentamos a la hora de hablar de la calidad de un producto software son: - La definición misma de la calidad del software: Es realmente posible encontrar un conjunto de propiedades en un producto software que nos den una indicación de su calidad? La calidad es un concepto que se deriva de un conjunto de sub-conceptos. - La comprobación de la calidad del software: Cómo medir el grado de calidad de un producto software? Control de Calidad: Actividades para evaluar la calidad de los productos desarrollados. Para dar respuestas a estas interrogantes de han definido numerosos modelos de calidad que la definen de forma jerárquica. Tienen una estructura, por lo general, en tres niveles: 1

En la conferencia anterior vimos cómo es la relación entre estos conceptos y hablamos de la necesidad de poder medirlos para evaluar el grado de calidad de un producto de software.

2 En la conferencia anterior vimos cómo es la relación entre estos conceptos y hablamos de la necesidad de poder medirlos para evaluar el grado de calidad de un producto de software. El modelo McCall establece la siguiente relación entre factores y criterios de calidad: Perspectivas Factor Criterios Facilidad de uso - Facilidad de operación - Facilidad de comunicación - Facilidad de aprendizaje Integridad - Control de accesos - Facilidad de auditoría Operación del producto Corrección - Completitud - Trazabilidad Fiabilidad - Precisión - Tolerancia a fallos Eficiencia - Eficiencia en ejecución - Eficiencia en almacenamiento Revisión del producto Facilidad de mantenimiento - Concisión Facilidad de prueba - Instrumentación Flexibilidad 2

3 Transición del producto DESARROLLO Facilidad de reutilización Interoperabilidad Portabilidad - Capacidad de expansión - Generalidad - Generalidad - Independencia entre sistema y software - Independencia del hardware - Compatibilidad de comunicaciones - Compatibilidad de datos - Independencia entre sistema y software - Independencia del hardware A partir de esta definición de factores y criterios se aplican las métricas para hacer la evaluación. McCall propuso 41 métricas, sobre todo métricas de tipo subjetivo, es decir, métricas que evaluadas por personas diferentes podrían dar como resultado valores diferentes. Para cada uno de los criterios de calidad se definen entonces un conjunto de MÉTRICAS, que son medidas cuantitativas de ciertas características del producto que, cuando están presentes, dan una indicación del grado en que dicho producto posee un determinado atributo de calidad. Vamos a ver como ejemplo las métricas asociadas al criterio de calidad completitud, dentro del factor de calidad corrección, según McCall. Corrección: Hasta qué punto un programa cumple sus especificaciones y satisface los objetivos del usuario. Por ejemplo, si un programa debe ser capaz de sumar dos números y en lugar de sumar los multiplica, es un programa incorrecto. Es quizás el factor más importante, aunque puede no servir de nada sin los demás factores. Completitud: Atributos del software que proporcionan la implementación completa de todas las funciones requeridas. En este punto es dónde se hace necesario definir los mejores instrumentos para evaluar cada uno el los criterios. La propuesta del Modelo McCall es dar respuesta a la siguiente lista de comprobación (lista de chequeo): Lista de comprabación 1. No hay referencias ambiguas [R,D,I] 2. Todas las referencias a datos definidas son calculadas u obtenidas de una fuente externa [R,D,I] 3

4 3. Todas las funciones definidas son utilizadas [R,D,I] 4. Todas las referencias a funciones están definidas [R,D,I] 5. Se han definido todas las condiciones y procesamientos para cada punto de decisión [R,D,I] 6. Concuerdan todos los parámetros de llamada a funciones definidos y referenciados [D,I] 7. Todos los informes de problemas se han resuelto [R,D,I] 8. El diseño concuerda con los requisitos [D] 9. El código concuerda con el diseño [I] Las letras R, D e I indican si la lista de comprobación es aplicable a los requisitos (R), el diseño (D) y/o la implementación (I). Se contesta a estas preguntas con un SI o NO, y luego se aplica la siguiente fórmula matemática que da como resultado el grado o nivel de calidad para dicho atributo (criterio): (número de SI para R/6) +(número de SI para D/8) + (número de SI para I/8) 3 De esta forma, la medida para la completitud es un número entre 0 y 1. De forma similar se pueden definir listas de comprobación para evaluar otros atributos y en cada caso definir las posibles respuestas de las listas y su impacto en la evaluación final del atributo en cuestión. Otros ejemplos de métricas del Modelo McCall se pueden definir de forma aritmética de la siguiente forma. Noten que en todos los casos se evalúa para valores entre 0-1: Fiabilidad = 1 - (número de errores/ número de líneas de código) Facilidad de mantenimiento = (número medio de días-hombre por corrección) Portabilidad = 1 - (esfuerzo para portar / esfuerzo para implementar) Flexibilidad = (número medio de días-hombre por cambio) En el caso de la fiabilidad está evaluada en términos de la proporción de errores por líneas de código. La facilidad de mantenimiento se evalúa considerando el gasto de tiempo-especialista por corrección. La portabilidad se evalúa considerando la proporción entre los esfuerzos para portar y para implementar. La flexibilidad se evalúa considerando el gasto de tiempo-especialista por cambio. ACTIVIDAD EN EQUIPOS 1. A partir del a lista de comprobación del atributo completitud, veamos en equipos cómo definir una lista de comprobación para evaluar a los miembros del equipo de desarrollo en cada uno de los siguientes roles: Diseñador (evaluar calidad de la interfaz de usuario) Programador (evaluar estilo de código y cumplimiento de las funcionalidades) 4

5 Una posible respuesta: Sí (S), En alguna medida (AM), No (N) Diseñador. Diseño de la Interfaz de Usuario S AM N 1- El diseño es sencillo, consistente y atractivo para el usuario 2- El usuario manipula directamente los componentes teniendo el control de la aplicación 3- Las acciones del usuario son reversibles 4- Existe una correcta manipulación de los errores 5- La organización de la información es adecuada 6- Utiliza un solo idioma 7- Correcta ortografía Programador Estilo de Código Calificación: S AM N 1- Utiliza un estilo de código consistente 2- Utiliza un solo idioma 3- Utiliza una identación consistente 4- Utiliza espacios y líneas en blanco para facilitar la legibilidad 5- Hace uso de los comentarios 6- Correcta declaración y utilización de clases y variables 7- Correcto uso de instrucciones (if, switch, while, for, etc.) 8- Es consistente al nombrar cada elemento (clases, variables, componentes) Cumplimiento de las funcionalidades planteadas Calificación: S AM N 1- Se implementa todas las funcionalidades 2- Alta, Baja y Modificación de todos los datos 3- Prepara un juego de datos que permita verificar todas las funcionalidades ESTUDIO INDIVIDUAL 1. De forma similar a estas listas de comprobación podrán definir qué factores y criterios evaluarán en sus proyectos de curso y para ellos construir sus propias listas de chequeo. CONCLUSIONES La evaluación de la calidad resulta ser una tarea compleja y existen diferentes modelos que establecen cómo hacerlo. Las listas de comprobación ofrecen un conjunto de indicadores que deben ser evaluados para garantizar un atributo. Existen listas de comprobación para evaluar determinados atributos y se pueden definir nuevas listas para chequear otros atributos. Pero será suficiente con evaluar la calidad de un producto o proceso una vez haya sido desarrollado? En la próxima actividad veremos como la industria de software debe definir un área que se ocupe del aseguramiento de la calidad y que vele por la calidad de todo el proceso de desarrollo para obtener un producto adecuado. 5

Documentos relacionados

CUADRO COMPARATIVO DE LOS MODELOS DE CALIDAD ELABORADO POR: EDUARD ANTONIO LOZANO CÓRDOBA. (Documento: ) PRESENTADO A:

CUADRO COMPARATIVO DE LOS MODELOS DE CALIDAD ELABORADO POR: EDUARD ANTONIO LOZANO CÓRDOBA (Documento: 12.022.957) PRESENTADO A: ASTRID VICTORIA CARDENAS CHICANGANA Ingeniera de sistemas - Magister en dirección