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, 2005.
• 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:
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 Corrección - Completitud - Consistencia - Trazabilidad Fiabilidad - Precisión - Consistencia - Tolerancia a fallos - Modularidad - Simplicidad Operación del producto
Eficiencia - Eficiencia en ejecución
- Eficiencia en almacenamiento Facilidad de mantenimiento - Modularidad - Simplicidad - Consistencia - Concisión - Auto descripción Facilidad de prueba - Modularidad - Simplicidad - Auto descripción - Instrumentación Revisión del producto
- Capacidad de expansión - Generalidad - Modularidad Facilidad de reutilización - Auto descripción - Generalidad - Modularidad
- Independencia entre sistema y software
- Independencia del hardware
Interoperabilidad
- Modularidad - Compatibilidad de comunicaciones
- Compatibilidad de datos Transición del producto
Portabilidad
- Auto descripción - Modularidad
- Independencia entre sistema y software
- Independencia del hardware DESARROLLO
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. 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 = 1 - 0.1 (número medio de días-hombre por corrección)
Portabilidad = 1 - (esfuerzo para portar / esfuerzo para implementar) Flexibilidad = 1 - 0.05 (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)
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.
