lunes, 12 de julio de 2010

UNIDAD 1.


GESTIÓN, CONTROL Y GARANTÍA
DE LA CALIDAD DEL SOFTWARE
ÍNDICE
ÍNDICE.........................2
GUÍA AL ESTUDIO DE LA UNIDAD DIDÁCTICA .....................................4
FILOSOFÍA DE LA UNIDAD DIDÁCTICA........................4
ESTRUCTURA DE LA UNIDAD DIDÁCTICA........................4
OBJETIVOS ........................................... 4
UNIDAD 1. DEFINICIÓN DE CALIDAD DEL SOFTWARE..................6
1.1. ¿QUÉ ES LA CALIDAD DEL SOFTWARE?.............. 6
1.2. MODELOS DE CALIDAD DEL SOFTWARE ............................................ 9
1.2.1. Estructura de los modelos de calidad .............................................9
1.2.2. El modelo de McCall ...........................................10
1.2.3. Otras métricas............................ 16
1.3. ¿CÓMO UTILIZAR UN MODELO DE CALIDAD?......................... 17
1.3.1. Estrategias de uso de un Modelo de Calidad.............................. 17
1.3.2. Pasos para el uso de un Modelo de Calidad............................. 18
1.4. VISIÓN SIMPLISTA DE LA CALIDAD......................... 20
1.5. TERMINOLOGÍA.......21
EJERCICIOS DE AUTOCOMPROBACIÓN .......................................... 21
GUÍA AL ESTUDIO DE LA UNIDAD DIDÁCTICA
Filosofía de la Unidad Didáctica
La integridad de un producto software depende de la acción combinada de tres tipos de disciplinas:
- Desarrollo
- Gestión
- Control
Dentro de las disciplinas de control se encuentra la Garantía de Calidad del Software, cuyo objetivo es asegurar un cierto nivel de calidad en el producto software desarrollado.
Estructura de la Unidad Didáctica
Esta asignatura consta de cuatro unidades. En la primera de ellas se pretende introducir al alumno en la terminología y conceptos básicos que se manejan en relación con la Calidad del Software.
En la segunda unidad se profundiza en las actividades de Control de Calidad, es decir, aquellas cuyo objetivo es evaluar la calidad que posee un producto.
En la tercera unidad se profundiza en las actividades de Garantía de Calidad de tipo constructivo, es decir, aquellas que ayudan a imprimir calidad en el producto.
En la cuarta y última unidad se habla de la Gestión de la Calidad, a nivel organizativo, y de los estándares y guías existentes para la implantación de Sistemas de Calidad y para la elaboración de Planes de Garantía de Calidad.
Al final de algunas secciones el alumno encontrara una serie de ejercicios de autocomprobación. La solución a estos ejercicios se encuentra al final de la unidad didáctica.
Al terminar el estudio de esta unidad didáctica el alumno deberá realizar un control, con el que se procura que el mismo fije y ponga en práctica las ideas expuestas en la unidad.
Objetivos
Al finalizar el estudio de esta unidad didáctica el estudiante:
- Comprenderá el significado de la terminología utilizada.
- Será capaz de caracterizar la calidad de un producto software en términos de un modelo de calidad.
- Comprenderá el objetivo de las diferentes actividades de Control de Calidad del
Software.
- Comprenderá en qué consiste la Garantía de Calidad en un proyecto de desarrollo de
Software.
- Conocerá las consideraciones que se debe tener en cuenta a la hora de construir un
Sistema de Garantía de Calidad.
- Será capaz de participar en una revisión o auditoría.
- Será capaz de planificar y efectuar la prueba de un programa reducido.
- Será consciente de aquellas medidas que puede tomar para construir productos de mayor calidad.
UNIDAD 1.
DEFINICIÓN DE CALIDAD DEL SOFTWARE
En este apartado se van a presentar los conceptos básicos y la terminología propia de este área.
En primer lugar aclararemos qué se entiende por calidad en el contexto de la Ingeniería del Software.
A continuación pasaremos a analizar qué estructura y utilidad tiene un Modelo de
Calidad.
1.1. ¿Qué es la calidad del software?
La calidad está de moda, en todos los aspectos, pero especialmente en el desarrollo de software. El interés por la calidad crece de forma continua, a medida que los clientes se vuelven más selectivos y comienzan a rechazar los productos poco fiables o que realmente no dan respuesta a sus necesidades. Ahora bien, ¿qué es la calidad del software?
A la hora de definir la calidad del software se pueden adoptar diferentes aproximaciones.
Como primera aproximación es importante diferenciar entre la calidad del PRODUCTO software y la calidad del PROCESO de desarrollo. No obstante, las metas que se establezcan para la calidad del producto van a determinar las metas a establecer para la calidad del proceso de desarrollo, ya que la calidad del producto va a estar en función de la calidad del proceso de desarrollo. Sin un buen proceso de desarrollo es casi imposible obtener un buen producto.
La calidad del producto software se diferencia de la calidad de otros productos de fabricación industrial, ya que el software tiene ciertas características especiales:
· El software es un producto mental, no restringido por las leyes de la Física o por los límites de los procesos de fabricación. Es algo abstracto, y su calidad también lo es.
· Se desarrolla, no se fabrica. El coste está fundamentalmente en el proceso de diseño, no en la producción. Y los errores se introducen también en el diseño, no en la producción.
· El software no se deteriora con el tiempo. No es susceptible a los efectos del entorno, y su curva de fallos es muy diferente de la del hardware. Todos los problemas que surjan durante el mantenimiento estaban allí desde el principio, y afectan a todas las copias del mismo; no se generan nuevos errores.
· Es artesanal en gran medida. El software, en su mayoría, se construye a medida, en vez de ser construido ensamblando componentes existentes y ya probados, lo que dificulta aún más el control de su calidad. Aunque se ha escrito mucho sobre la reutilización del software, hasta ahora se han conseguido pocos éxitos tangibles.
· El mantenimiento del software es mucho más complejo que el mantenimiento del hardware. Cuando un componente hardware se deteriora se sustituye por una pieza de repuesto, pero cada fallo en el software implica un error en el diseño o en el proceso mediante el cual se tradujo el diseño en código máquina ejecutable.
· Es engañosamente fácil realizar cambios sobre un producto software, pero los efectos de estos cambios se pueden propagar de forma explosiva e incontrolada.
· Como disciplina, el desarrollo de software es aún muy joven, por lo que las técnicas de las que disponemos aún no son totalmente efectivas o no están totalmente calibradas.
· El software con errores no se rechaza. Se asume que es inevitable que el software presente errores.
También es importante destacar que la calidad de un producto software debe ser considerada en todos sus estados de evolución (especificaciones, diseño, código, ...). No basta con tener en cuenta la calidad del producto una vez finalizado, cuando los problemas de mala calidad ya no tienen solución o la solución es muy costosa.
Los principales 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? Para dar respuesta a estas preguntas aparecen los Modelos de Calidad.
- Modelos de calidad: En los modelos de calidad, la calidad se define de forma jerárquica. Resuelven la complejidad mediante la descomposición.
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? Aquí aparece el concepto de Control de Calidad, del que hablaremos en la unidad 2.
- Control de Calidad: Actividades para evaluar la calidad de los productos desarrollados.
- La mejora de la calidad del software: ¿Cómo utilizar la información disponible acerca de la calidad del producto software para mejorar su calidad a lo largo del ciclo de vida? Tal y como veremos, no sólo es posible “medir” la calidad, sino también “construir” la calidad durante el proceso de desarrollo del producto. En este eje aparecen dos conceptos importantes:
- Gestión de Calidad: Determinación y aplicación de las políticas de calidad de la empresa (objetivos y directrices generales)
- Garantía o Aseguramiento de Calidad: Conjunto de actividades planificadas y sistemáticas necesarias para proporcionar confianza en que el producto software satisfará los requisitos dados de calidad.
En esta unidad nos vamos a ocupar de la primera cuestión, la definición de la calidad.
Veamos la definición que dan de la calidad algunos de los padres de la idea de la gestión de la calidad:
Según Deming, calidad es “Conformidad con los requisitos y confianza en el funcionamiento”
Según Juran, calidad es “Adecuación para su uso”
Crosby pone más énfasis en la prevención: “hacerlo bien a la primera”
Veamos otras definiciones de calidad extraídas de estándares internacionales:
“La calidad es la suma de todos aquellos aspectos o características de un producto o servicio que influyen en su capacidad para satisfacer las necesidades, expresadas o implícitas” (ISO 8402)
“Grado con el cual el cliente o usuario percibe que el software satisface sus expectativas” (IEEE 729-83)
“Capacidad del producto software para satisfacer los requisitos establecidos”
(DoD 2168)
Lo que está claro a partir de estas definiciones es que la calidad es algo relativo. Siempre va a depender de los requisitos o necesidades que se desee satisfacer. Por eso, la evaluación de la calidad de un producto siempre va a implicar una comparación entre unos requisitos preestablecidos y el producto realmente desarrollado.
El problema es que, por lo general, una parte de los requisitos van a estar explícitos (se encontrarán en la ERS, tanto los funcionales como otros requisitos), pero otra parte van a quedar implícitos (el usuario sabe lo que quiere, pero no siempre es capaz de expresarlo). Hay que intentar que queden implícitos la menor cantidad de requisitos posible. No se podrá conseguir un producto de buena calidad sin una buena ERS.
Teniendo esto en cuenta, en un producto software vamos a tener diferentes visiones de la calidad:
- Necesaria o Requerida: La que quiere el cliente.
- Programada o Especificada: La que se ha especificado explícitamente y se intenta conseguir.
- Realizada: La que se ha conseguido.
Nuestro objetivo es conseguir que las tres visiones coincidan. A la intersección entre la calidad Requerida y la calidad Realizada se le llama calidad Percibida, y es la única que el cliente valora. Toda aquella calidad que se realiza pero no se necesita es un gasto inútil de tiempo y dinero.
También está claro que las definiciones que se han dado de la calidad son demasiado generales e imprecisas como para que resulten de utilidad a la hora de construir un software de calidad. Por eso surge el concepto de Modelo de Calidad, que nos ayuda a definir la calidad del software de una forma más precisa y útil.
1.2. Modelos de calidad del software
1.2.1. Estructura de los modelos de calidad
Los modelos de calidad del software vienen a ayudar en la puesta en práctica del concepto general de calidad que vimos en el apartado anterior, ofreciendo una definición más operacional.
Unos de los modelos de calidad más antiguos y extendidos es el de McCall [McCall,
1977], y de él han derivado otros modelos, como el de Boehm [Boehm, 78] o el SQM
[Murine, 1988]
En los modelos de calidad, la calidad se define de forma jerárquica. Es un concepto que se deriva de un conjunto de sub-conceptos, cada uno los cuales se va a evaluar a través de un conjunto de indicadores o métricas.
Tienen una estructura, por lo general, en tres niveles:

- En el nivel más alto de la jerarquía se encuentran los FACTORES de calidad, que representan la calidad desde el punto de vista del usuario. Son las características que componen la calidad. También se les llama Atributos de Calidad Externos.
- Cada uno de los factores se descompone en un conjunto de CRITERIOS de calidad.
Son atributos que, cuando están presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visión de la calidad desde el punto de vista del producto software. También se les llama Atributos de Calidad Internos.
- 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.
La ventaja de los modelos de calidad es que la calidad se convierte en algo concreto, que se puede definir, que se puede medir y, sobre todo, que se puede planificar.
Los modelos de calidad ayudan también a comprender las relaciones que existen entre diferentes características de un producto software.
Una desventaja es que aún no ha sido demostrada la validez absoluta de ninguno de estos modelos. Las conexiones que establecen entre características, atributos y métricas se derivan de la experiencia, y de ahí que existan múltiples modelos.
1.2.2. El modelo de McCall
Como ejemplo vamos a ver el modelo de McCall.
El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto:
- Operación del producto
- Revisión del producto
- Transición del producto
El modelo de McCall se basa en 11 factores de calidad, que se organizan en torno a los tres ejes de la siguiente forma:
PUNTO DE VISTA FACTORES


Los factores de McCall se definen como sigue:
1. 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.
2. Fiabilidad: Hasta qué punto se puede confiar en el funcionamiento sin errores del programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25% de los casos el resultado que da no es correcto, es poco fiable.
3. Eficiencia: Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un programa para desempeñar su función. Un programa que suma dos números y necesita 2 MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta, es poco eficiente.
4. Integridad: Hasta qué punto se controlan los accesos ilegales a programas o datos. Un programa que permite el acceso de personas no autorizadas a ciertos datos es poco íntegro.
5. Facilidad de uso: El coste y esfuerzo de aprender a manejar un producto, preparar la entrada de datos e interpretar la salida del mismo.
6. Facilidad de mantenimiento: El coste de localizar y corregir defectos en un programa que aparecen durante su funcionamiento.
7. Facilidad de prueba: El coste de probar un programa para comprobar que satisface sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de un sistema para poder probar que funciona bien, es un programa difícil de probar.
8. Flexibilidad: El coste de modificación del producto cuando cambian sus especificaciones.
9. Portabilidad (o Transportabilidad): El coste de transportar o migrar un producto de una configuración hardware o entorno operativo a otro.
10. Facilidad de Reutilización: Hasta qué punto se puede transferir un módulo o programa del presente sistema a otra aplicación, y con qué esfuerzo.
11. Interoperabilidad: El coste y esfuerzo necesario para hacer que el software pueda operar conjuntamente con otros sistemas o aplicaciones software externos.
Cada uno de estos factores se descompone, a su vez, en criterios. En el modelo de
McCall se definen un total de 23 criterios, con el siguiente significado:
1. Facilidad de operación: Atributos del software que determinan la facilidad de operación del software.
2. Facilidad de comunicación: Atributos del software que proporcionan al usuario entradas y salidas fácilmente asimilables.
3. Facilidad de aprendizaje: Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición desde el modo actual de operación.
4. Control de accesos: Atributos del software que proporcionan control de acceso al software y los datos que maneja.
5. Facilidad de auditoría: Atributos del software que facilitan el registro y la auditoría de los accesos al software.
6. Eficiencia en ejecución: Atributos del software que minimizan el tiempo de procesamiento.
7. Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de almacenamiento necesario.
8. Precisión: Atributos del software que proporcionan el grado de precisión requerido en los cálculos y los resultados.
9. Consistencia: Atributos del software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación utilizadas.
10. Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales.
11. Modularidad: Atributos del software que proporcionan una estructura de módulos altamente independientes.
12. Simplicidad: Atributos del software que posibilitan la implementación de funciones de la forma más comprensible posible.
13. Completitud: Atributos del software que proporcionan la implementación completa de todas las funciones requeridas.
14. Trazabilidad (Rastreabilidad): Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto.
15. Auto descripción: Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.
16. Capacidad de expansión: Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos.
17. Generalidad: Atributos del software que proporcionan amplitud a las funciones implementadas.
18. Instrumentación: Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución (para facilitar las mediciones del uso o la identificación de errores).
19. Independencia entre sistema y software: Atributos del software que determinan su independencia del entorno operativo.
20. Independencia del hardware: Atributos del software que determinan su independencia del hardware.
21. Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos de comunicación e interfaces estándar.
22. Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estándar.
23. Concisión: Atributos del software que posibilitan la implementación de una función con la menor cantidad de código posible.
La relación Factores - Criterios que establece el modelo queda plasmada en la siguiente tabla:
Factor
Criterios
Facilidad de uso
- Facilidad de operación
- Facilidad de Comunicación
- Facilidad de Aprendizaje
Integridad
- Control de Accesos
- Facilidad de Auditoria
Corrección
- Completitud
- Consistencia
- Trazabilidad
Fiabilidad
- Precisión
- Consistencia
- Tolerancia a fallos
- Modularidad
- Simplicidad
Eficiencia
- Eficiencia en ejecución
- Eficiencia en almacenamiento
Facilidad de mantenimiento
- Simplicidad
- Consistencia
- Concisión
- Auto descripción
Facilidad de Prueba
- Simplicidad
- Auto descripción
- Instrumentación
Flexibilidad
- Auto descripción
- Capacidad de expansión
- Generalidad
- Modularidad
Reusabilidad
- Generalidad
- Modularidad
- Independencia entre Sistema y Software
- Independencia del hardware
Interoperabilidad
- Modularidad
- Compatibilidad de comunicaciones
- Compatibilidad de datos
Portabilidad
- Auto descripción
- Independencia entre Sistema y Software
- Independencia del hardware
En cuanto a las métricas, 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. Aún hoy en día no hay métricas formales y objetivas que cubran todos los criterios del modelo de McCall.
Vamos a ver como ejemplo las métricas asociadas al criterio de calidad “completitud”, dentro del factor de calidad “corrección”, según McCall.
Para evaluar la completitud es necesario dar respuesta a la siguiente lista de comprobació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:
De esta forma, la medida para la completitud es un número entre 0 y 1.
En general, el modelo de McCall propone asociar a cada criterio una fórmula deregresión del tipo:

donde los rj son los coeficientes de regresión, y donde los mj representan las distintas métricas asociadas al criterio. De la misma forma se propagarán a los factores los valores calculados para los criterios.
La medida para la corrección, por ejemplo, se calculará aplicando la fórmula:

donde x es la medida para la completitud, y la medida para la trazabilidad y z la medida para la consistencia.
Para que todas las métricas se puedan combinar sin problemas, lo habitual es que se normalicen sus valores dentro del intervalo [0,1].
1.2.3. Otras métricas
Otros ejemplos de métricas son los siguientes:
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)
Otros indicadores que se pueden utilizar para evaluar la fiabilidad de un producto son los siguientes:

La medida de la Facilidad de Uso se puede basar en la probabilidad de que el operador del sistema no se encuentre con problemas en la interfaz de usuario durante un cierto periodo de operación. El problema de esta métrica es recoger los datos necesarios para calcular la función de distribución de probabilidad de los problemas con la interfaz.
Los manuales bien estructurados, los mensajes de error informativos, las funciones de ayuda y los interfaces consistentes también contribuyen a la facilidad de uso, pero no basta con contar el número de mensajes o pantallas de ayuda para tener una métrica de la facilidad de uso.
Otras métricas propuestas se refieren a la comprensibilidad o legibilidad de las pantallas de ayuda y los textos de mensajes de error y manuales. Estas métricas son sin embargo poco indicativas.
Otras métricas se refieren al esfuerzo necesario para aprender a manejar el sistema, o la velocidad a la que trabaja el usuario una vez entrenado, o los errores que se cometen en el trabajo normal. Pero para medir lo agradable que resulta el interfaz, lo mejor es hacer encuestas a los usuarios.
En cuanto a la facilidad de mantenimiento, la métrica ideal sería la probabilidad de que la causa de un incidente será diagnosticada o un fallo corregido con una cierta cantidad de esfuerzo en un determinado entorno.
Otras métricas se refieren al proceso de mantenimiento, como:
à Tiempo medio de reparación o cambio
à Número de problemas sin resolver
à Tiempo empleado en problemas sin resolver
à Porcentaje de cambios que introducen defectos
à Número de módulos afectados por cada cambio
También las métricas de complejidad se utilizan como indicadores de la facilidad de mantenimiento. La estructuración del código y de la documentación asociada suele estar muy relacionada con la facilidad de mantenimiento. Pero es más una forma de identificar potenciales puntos peligrosos que una predicción de pobre mantenibilidad.
1.3. ¿Cómo utilizar un Modelo de Calidad?
1.3.1. Estrategias de uso de un Modelo de Calidad
Dependiendo del grado de conformidad con el modelo de calidad seleccionado como referencia para un proyecto, se pueden adoptar dos estrategias:
· MODELO FIJO:
à Se aceptan los factores, criterios y métricas que propone el modelo
à Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas
à Sólo es necesario seleccionar un subconjunto de los factores de calidad como requisitos de calidad para el proyecto.
· DEFINICIÓN PARTICULAR DE LA CALIDAD:
à Se acepta la filosofía de la descomposición
à Se selecciona un subconjunto de los factores de calidad como requisitos de calidad para el proyecto.
à Se decide la descomposición más adecuada para los factores de calidad seleccionados.
1.3.2. Pasos para el uso de un Modelo de Calidad
· AL PRINCIPIO DEL PROYECTO:
Al especificar la calidad requerida de un producto software hay que:
1) Seleccionar cuáles de los factores de calidad van a ser requisitos de calidad del sistema. Para ello hay que tener varias cosas en consideración:
¨ La relación que tienen los factores con las características peculiares del producto o proyecto. Así, por ejemplo, si se espera que el ciclo de vida del sistema sea largo, la ‘facilidad de mantenimiento’ y la ‘flexibilidad’ se convierten en un requisito; si el sistema es experimental y se espera que las especificaciones del sistema cambien frecuentemente, la ‘flexibilidad’ será importante y sin embargo la ‘eficiencia’ apenas tendrá importancia; si el sistema se desarrolla para un entorno en el que el hardware evoluciona rápidamente, la ‘portabilidad’ es esencial; si se espera que ciertas funciones del sistema se utilicen por un largo período de tiempo, aunque el resto del sistema cambie, la ‘facilidad de reutilización’ será fundamental, etc.
¨ El coste del factor de calidad frente al beneficio que proporciona. La siguiente tabla indica, para cada factor, el ahorro que se puede esperar cuando se consigue frente al coste necesario para conseguir dicho factor.

¨ Las implicaciones de los factores de calidad sobre el ciclo de vida, es decir, en qué etapas es necesario evaluar cada uno de los factores de calidad, y en qué etapas se dejan sentir los efectos de una calidad pobre con respecto a cada uno de estos factores.
¨ Las interrelaciones entre factores. Algunos factores pueden ser conflictivos entre sí. La eficiencia, por ejemplo, está en conflicto con prácticamente todos los demás factores de calidad. La siguiente tabla indica la dependencia entre los factores de McCall.

2) Una vez seleccionados los factores de calidad que son requisitos para el producto, es necesario organizarlos en orden de importancia.
3) Una vez establecidos los factores de calidad, el modelo de calidad proporciona automáticamente el conjunto de atributos o criterios relacionados con dichos factores.
4) Para cada uno de los criterios de calidad se definen o eligen entonces un conjunto de métricas.
5) Se debe entonces establecer valores deseables para los criterios en función de datos históricos, el promedio en la industria, etc. Se pueden establecer valores finales, es decir, los que se desea obtener una vez finalizado el desarrollo, y también valores intermedios o predictivos en cada período de medición durante el desarrollo.
6) Por último, se deberán establecer los valores mínimos aceptables.
La explicación para cualquier selección o decisión deberá ser adecuadamente documentada.
· DURANTE EL DESARROLLO:
Todo lo anterior se realizará al principio del proyecto. Ahora bien, durante el desarrollo
será necesario:
à Implementar las métricas, es decir, tomar las medidas necesarias
à Analizar los resultados de las métricas
à Tomar medidas correctivas si es necesario, es decir, si los valores obtenidos están por debajo de los valores mínimos aceptables. Estas medidas correctivas pueden afectar tanto al proceso de desarrollo como al proceso de gestión.
· AL FINAL DEL PROYECTO:
Una vez finalizado el proyecto, será necesario validar las medidas predictivas utilizadas, y comprobar si en efecto se pueden tomar como indicadores de los valores finales.
1.4. Visión Simplista de la Calidad
Los modelos de calidad requieren una planificación detallada y una cuidadosa recolección de medidas. Puede ser muy costoso incluso para un número reducido de factores, por lo que requieren recursos extras y, como consecuencia de ello, se usan con poca frecuencia.
En la mayor parte de los casos se adopta una visión de la calidad mucho más restringida, basada únicamente en el número de fallos (defectos conocidos).
La métrica de calidad única que se utiliza es la
DENSIDAD DE DEFECTOS = número de defectos / tamaño del producto.
Oscila en la industria, según datos publicados, entre 2 y 60 defectos/KNCSS, donde
KNCSS significa Kilo Non Comment Source Statements, es decir, mil instrucciones de código fuente sin comentarios.
Esta métrica se puede usar no sólo para código, sino también para análisis y diseño, tomando una definición de defecto adecuada, basada en el número de cambios requeridos.
El peligro de esta aproximación es el de utilizar mal esta medida simplificada de la calidad.
En primer lugar, no todos los defectos conducen a un fallo. Sólo los fallos son percibidos por el usuario, y son los que por lo tanto inciden en la calidad. Según un estudio realizado por Adams, en sistemas grandes y complejos un tercio de los defectos totales conducen a fallos que sólo ocurren como promedio cada 5000 años de tiempo de ejecución o más, y sólo un 2% de los defectos son responsables de los fallos que ocurren cada 5 años o menos.
Puede haber productos con un número de defectos alto que sin embargo apenas fallen, y que serán percibidos por el usuario como de alta calidad.
Por otro lado, esta medida está muy relacionada con la forma y el proceso de búsqueda y detección de defectos. Nos puede decir más de la calidad de este proceso que del producto. Un producto en el que se han detectado pocos defectos puede indicar que el proceso de pruebas ha sido poco exhaustivo y la mayor parte de los defectos permanecen ocultos.
1.5. Terminología
Se puede definir un ERROR como una incorrección cometida por un humano durante el proceso de desarrollo.
DEFECTO es la consecuencia de un error. Así, por ejemplo, si una función tiene el objetivo de sumar 10 al valor que recibe como entrada, y en realidad está sumando 20, eso es un defecto, debido al error del programador que escribió 20 en lugar de 10.
Se entiende por FALLO (failure) la manifestación de un defecto en el software. Por ejemplo, cuando a la función anterior se le da como entrada el valor 10 y la salida que se obtiene es 30 en lugar de 20, que es el valor esperado.
A veces se habla también de FALLAS (fault). Las fallas son los defectos que aún no han sido detectados y eliminados cuando comienzan las pruebas. Algunas de estas fallas se convertirán en fallos si se detectan durante las pruebas o el uso del sistema.
Por último, se llama INCIDENTE a una situación en la que se produce y se informa de un comportamiento no esperado en el sistema.
Una segunda acepción, más general, llama DEFECTO a una desviación en el valor esperado para una cierta característica. Los defectos no tienen porqué afectar al funcionamiento del objeto defectuoso. Un programa poco mantenible, por ejemplo, puede ser totalmente correcto.
Ejercicios de Autocomprobación
1.1. ¿Cree que se podría encontrar una única fórmula matemática que permitiese calcular el grado de calidad de cualquier producto software?
1.2. Elija 3 de entre las 11 características de calidad del modelo de McCall y sugiera 2 o
3 posibles métricas que se podrían utilizar para evaluar dicha característica.

2 comentarios:

  1. Excelente artículo, es de mucha ayuda para personas que estamos empezando con estos nuevos temas, muchas gracias por el aporte.

    Un detalle, no es posible ver algunas imágenes de las formulas que utiliza el modelo de McCall, espero se pueda solucionar este detalle. Gracias y saludos

    ResponderEliminar