14 de noviembre de 2012

Calidad del Software

Un elemento clave de cualquier proceso de ingeniería es la medición. Empleamos medidas para entender mejor los atributos de los modelos que creamos. Pero, fundamentalmente, empleamos las medidas para valorar la calidad de los productos de ingeniería o de los sistemas que construimos.
A diferencia de otras disciplinas, la ingeniería del software no está basada en leyes cuantitativas básicas de la Física. Las medidas absolutas, tales como el voltaje, la masa, la velocidad o la temperatura no son comunes en el mundo del software. En su lugar, intentamos obtener un conjunto de medidas indirectas que dan lugar a métricas que proporcionan una indicación de la calidad de algún tipo de representación del software. Como las medidas y métricas del software no son absolutas, están abiertas a debate. Fenton trata este aspecto cuando dice:
La medición es el proceso por el que se asignan números o símbolos a los atributos de las entidades en el mundo real, de tal manera que las definan de acuerdo con unas reglas claramente definidas .... En las ciencias físicas, medicina y, más recientemente, en las ciencias sociales, somos ahora capaces de medir atributos que previamente pensábamos que no eran medibles ... Por supuesto, tales mediciones no están tan refinadas como las de las ciencias físicas ..., pero existen [y se toman importantes decisiones basadas en ellas]. Sentimos que la obligación de intentar «medir lo no medible» para mejorar nuestra comprensión de entidades particulares es tan poderosa en la ingeniería del software como en cualquier disciplina.


CALIDAD DEL SOFTWARE
  • Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
  • Unos estándares específicos definen un conjunto de criterios de desarrollo que guían la manera en que se hace la ingeniería del software. Si no se siguen los criterios, habrá seguramente poca calidad.
  • Existe un conjunto de requisitos implícitos que a menudo no se nombran (por ejemplo, facilidad de mantenimiento). Si el software cumple con sus requisitos explícitos pero falla en los implícitos, la calidad del software no será fiable.
• Pressman (Pressman, 1998) define la calidad del software como:

“la concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”.

• En la definición de la calidad del software pueden estar involucrados aspectos como la ausencia de defectos, aptitud para el uso, seguridad, confiabilidad y reunión de especificaciones. Sin embargo, hay algo importante que se debe tener presente: la calidad del software debe ser construida desde el comienzo, no es algo que puede ser añadido después.

• Para que el producto final sea de calidad, el proceso por medio del cual éste es elaborado debe ser también de calidad.


ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

• Sridharan (Sridharan, 2000) indica que mientras el software que se está desarrollado reúne los requerimientos y su desempeño es el esperado, es preciso que se supervisen las actividades de desarrollo del software y su rendimiento, en distintas oportunidades durante cada fase del ciclo de vida. Este es el papel del aseguramiento de la calidad del software.

• Hay tres (3) aspectos muy importantes con relación al aseguramiento de la calidad del software: (Wiegers, 1990)

– La calidad no se puede probar, se construye.
– El aseguramiento de la calidad del software no es una tarea que se realiza en una fase particular del      ciclo de vida de desarrollo.
– Las actividades asociadas con el aseguramiento de la calidad del software deben ser realizadas por personas que no estén directamente involucradas en el esfuerzo de desarrollo.

• Pressman (Pressman, 1998) considera que el aseguramiento de la calidad del software comprende una gran variedad de tareas asociadas:

– Preparar u plan de aseguramiento de la calidad del software para un proyecto.
– Participar en el desarrollo del proceso de descripción del proyecto de software.
– Revisar las actividades de ingeniería del software para verificar su consistencia con el proceso de software definido.
– Auditar el producto de software para verificar el cumplimiento del proceso de software definido
– Asegurar que las divergencias en el trabajo de software sean documentadas de acuerdo a los estándares definidos.
– Alamacenar cualquier inconformidad y reportarla a la gerencia media.


CONTROL DE LA CALIDAD DEL SOFTWARE


• Según Monsalve (Monsalve, 1998), el control de la calidad se relaciona con la vigilancia permanente de todo el proceso de desarrollo y el ciclo de vida del software. Se logra mediante la observación constante del cumplimiento de cada una de las fases y actividades involucradas en el proceso de desarrollo.

• Para realizar un control de calidad deben ejecutarse frecuentes inspecciones a las metodologías de trabajo y a el uso de las herramientas, revisiones de prototipos y de las pruebas formales de los productos finales.

• El control de la calidad permite realizar las rectificaciones necesarias a cualquier falla encontrada durante el proceso de desarrollo.

• Adicionalmente, el asegurar la calidad en las primeras fases del proceso de desarrollo del software implica que los costos del control en las etapas posteriores tiende a disminuir al tener menos aspectos que controlar, además de que la calidad estaría asegurada en sus bases.


AUDITORIA DE LA CALIDAD DEL SOFTWARE


• La auditoría de la calidad se utiliza para descubrir y detener los errores del software. Se lleva a cabo para monitorear eventos específicos, o bien para revisar todas las actividades de un sistema.

• Las auditorías permiten garantizar la calidad del software: luego de llevar a cabo una auditoría de calidad, es más fácil mantener un registro con las deficiencias presentadas.

• La auditoría de la calidad del software tiene tres (3) metas de seguridad importantes:

  1. Revisar los modelos de acceso a los componentes, las historias de acceso a los procesos y el uso de los mecanismos de protección soportados por el sistema.
  2. Descubrir los usuarios frecuentes y esporádicos que se esfuerzan por desviar los mecanismos de protección.
  3. Descubrir cualquier uso de privilegios que pueden ocurrir cuando un usuario asume una funcionalidad con privilegios mayores que el suyo propio.

CALIDAD DEL PRODUCTO DE SOFTWARE

• Para Monsalve (Monsalve, 1998), la principal meta de un equipo desarrollador de software debe ser siempre producir software de calidad; para ello, se deben tener en cuenta dos (2) ideas muy importantes:
– Los productos de software son realizados por personas y para personas.
– Muchas personas asocian la calidad a un atributo exclusivo del producto y que comienza a considerarse una vez que se escriben las primeras líneas de código.

• La calidad que pueden alcanzar los productos de software, y en general cualquier tipo de producto, está sometida a la manera cómo se desarrolla cada una de las etapas de la vida del producto, iniciándose con la concepción de la idea del producto hasta la entrega final y mantenimiento del mismo.

• La calidad del producto de software involucra actividades como:
– Administración de la calidad.
– Uso de tecnología de Ingeniería de Software eficiente.
– Aplicación de técnicas formales a lo largo de todo el proceso de desarrollo.
–Minimización de las variaciones entre productos.
– Verificación y pruebas formales en las diferentes etapas del desarrollo.
– Control de la documentación.
– Correcto mantenimiento y servicios de post-venta.


CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE

La calidad está presente en todas las etapas del proceso de desarrollo de los productos de software. A grandes rasgos:

 Calidad en el diseño. Se basa en definir un listado de especificaciones a seguir; involucra la descripción de los procesos de desarrollo, tareas y responsabilidades de los equipos de desarrollo; dichos procesos pueden estar estandarizados.

 Calidad en la implementación. Se enfoca al grado de cumplimiento de los requerimientos de diseño. Si los requerimientos está bien definidos y especificados, el cumplimiento de la calidad en esta fase no debe tornarse difícil.

• Calidad en la satisfacción. Es la medida de calidad apreciada por los usuarios finales de los productos de software. No puede esperarse calidad en esta fase si no hubo preocupación por ella en las etapas anteriores.

MÉTRICAS DE CALIDAD

Métricas para determinar los factores de calidad:

· Facilidad de auditoria.
· Exactitud.
· Normalización de las comunicaciones.
· Completitud.
· Concisión.
· Consistencia.
· Estandarización de los datos.
· Tolerancia de errores.
· Eficiencia de la ejecución.
· Facilidad de expansión.
· Generalidad.
· Independencia del hardware.
· Instrumentación.
· Modularidad.
· Facilidad de operación.
· Seguridad.
· Autodocumentación.
· Simplicidad.
· Independencia del sistema software.
· Facilidad de traza.
· Formación.



MODELOS CONOCIDOS
  • MODELO DE McCALL (1977)
Los factores que afectan la calidad del software se pueden categorizar en dos amplios grupos:
   (1) Factores que se pueden medir directamente (por ejemplo, defectos por punto de función) 
   (2) Factores que se pueden medir sólo indirectamente (por ejemplo, facilidad de uso o de mantenimiento).

En todos los casos debe aparecer la medición. Debemos comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad.

Factores de calidad de McCall y colegas (1997)


Refiriéndose a los factores anotados en la figura anterior, McCall proporciona las siguientes descripciones:

Operación del Producto
  • Corrección. Hasta dónde satisface un programa su especificación y logra los objetivos propuestos por el cliente.
  • Fiabilidad. Hasta dónde se puede esperar que un programa lleve a cabo su función con la exactitud requerida. 
  • Eficiencia. La cantidad de recursos informáticos y de código necesarios para que un programa realice su función.
  • Integridad. Hasta dónde se puede controlar el acceso al software o a los datos por personas no autorizadas.
  • Usabilidad (facilidad de manejo). El esfuerzo necesario para aprender a operar con el sistema, preparar los datos de entrada e interpretar las salidas (resultados) de un programa.
Revisión del Producto
  • Facilidad de mantenimiento. El esfuerzo necesario para localizar y arreglar un error en un programa. (Esta es una definición muy limitada).
  • Flexibilidad. El esfuerzo necesario para modificar un programa que ya está en funcionamiento.
  • Facilidad de prueba. El esfuerzo necesario para probar un programa y asegurarse de que realiza correctamente su función.
Transición del Producto
  • Portabilidad. El esfuerzo necesario para transferir el programa de un entorno hardware/software a otro entorno diferente.
  • Reusabilidad (capacidad de reutilización). Hasta dónde se puede volver a emplear un programa (o partes de un programa) en otras aplicaciones, en relación al empaquetamiento y alcance de las funciones que realiza el programa.
  • Interoperatividad. El esfuerzo necesario para acoplar un sistema con otro.
Es difícil, y en algunos casos imposible, desarrollar medidas directas de los factores de calidad anteriores.
Por tanto, se definen y emplean un conjunto de métricas para desarrollar expresiones para todos los factores, de acuerdo con la siguiente relación:
F = cI x mI -E c2 x m2 +....+ c, x m,
donde:

                                                     F es un factor de calidad del software, 
                                                     c son coeficienles de regresión 
                                                     m son las métricas que afectan al factor de calidad. 

  • Desgraciadamente, muchas de las métricas definidas por McCall pueden medirse solamente de manera subjetiva. 
  • Las métricas pueden ir en forma de lista de comprobación que se emplea para «puntuar» atributos específicos del software.
  • El esquema de puntuación propuesto por McCall es una escala del O (bajo) al 10 (alto).

Métrica para el esquema de puntuación
  • Facilidad de auditoría. La facilidad con la que se puede comprobar el cumplimiento de los estándares.
  • Exactitud. La exactitud de los cálculos y del control.
  • Estandarización de comunicaciones. El grado de empleo de estándares de interfaces, protocolos y anchos de banda.
  • Complección. El grado con que se ha logrado la implementación total de una función.
  • Concisión. Lo compacto que es el programa en términos de líneas de código.
  • Consistencia. El empleo de un diseño uniforme y de técnicas de documentación a lo largo del proyecto de desarrollo del software.
  • Estandarización de datos. El empleo de estructuras y tipos de datos estándares a lo largo del programa.
  • Tolerancia al error. El daño causado cuando un programa encuentra un error.
  • Eficiencia de ejecución. El rendimiento del funcionamiento de un programa.
  • Capacidad de expansión. El grado con que se pueden ampliar el diseño arquitectónico, de datos o procedimental.
  • Generalidad. La amplitud de aplicación potencial de los componentes del programa.
  • Independencia del hardware. El grado con que se desacopla el software del hardware donde opera.
  • Instrumentación. El grado con que el programa vigila su propio funcionamiento e identifica los errores que ocurren.
  • Modularidad. La independencia funcional de componentes de programa.
  • Operatividad. La facilidad de operación de un programa.
  • Seguridad. La disponibilidad de mecanismos que controlan o protegen los programas y los datos.
  • Autodocumentación. El grado en que el código fuente proporciona documentación significativa.
  • Simplicidad. El grado de facilidad con que se puede entender un programa.
  • Independencia del sistema software. El grado de independencia de programa respecto a las características del lenguaje de programación no estándar, características del sistema operativo y otras restricciones del entorno.
  • Trazabilidad. La capacidad de seguir una representación del diseño o un componente real del programa hasta los requisitos.
  • Formación. El grado en que ayuda el software a manejar el sistema a los nuevos usuarios.

  • MODELO DE FURPS (1987)
Hewlett-Packard ha desarrollado un conjunto de factores de calidad del software al que se le ha  dado el acrónimo de FURPS: funcionalidad, facilidad de uso, fiabilidad, rendimiento y capacidad de soporte.
Los factores de calidad FURPS provienen de trabajos anteriores, definiendo los siguientes atributos para cada uno de los cinco factores principales:

Funcionalidad. se valora evaluando el conjunto de características y capacidades del programa, la generalidad de las funciones entregadas y la seguridad del sistema global.
Facilidad de uso. se valora considerando factores humanos, la estética, la consistencia y la documentación general.
Fiabilidad. se evalúa midiendo la frecuencia y gravedad de los fallos, la exactitud de las salidas (resultados),
el tiempo de medio de fallos (TMDF), la capacidad de recuperación de un fallo y la capacidad de predicción del programa.
Rendimiento. se mide por la velocidad de procesamiento, el tiempo de respuesta, consumo de recursos, rendimiento efectivo total y eficacia.
Capacidad de soporte. combina la capacidad de ampliar el programa (extensibilidad), adaptabilidad y servicios (estos tres atributos representan un término más común -mantenimiento-), así como capacidad de hacer pruebas, compatibilidad, capacidad de configuración, la facilidad de instalación de un sistema y la facilidad con que se pueden localizar los problemas.


  • MODELO DE DROMEY (1996)

Resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo (incluyendo documentos de requerimientos, guías de usuarios, diseños, y código).

Sugiere el uso de cuatro categorías que implican propiedades de calidad, que son: correctitud, internas, contextuales y descriptivas.




  • NORMAS ISO 9000 - ISO 9126
El estándar identifica seis atributos clave de calidad:
  • Funcionalidad. El grado en que el software satisface las necesidades indicadas por los siguientes subatributos: idoneidad, corrección, interoperatividad, conformidad y seguridad.
  • Confiabilidad. Cantidad de tiempo que el software está disponible para su uso. Está referido por los siguientes subatributos: madurez, tolerancia a fallos y facilidad de recuperación.
  • Usabilidad. Grado en que el software es fácil de usar. Viene reflejado por los siguientes subatributos: facilidad de comprensión, facilidad de aprendizaje y operatividad.
  • Eficiencia. Grado en que el software hace Óptimo el uso de los recursos del sistema. Está indicado por los siguientes subatributos: tiempo de uso y recursos utilizados.
  • Facilidad de mantenimiento. La facilidad con que una modificación puede ser realizada. Está indicada por los siguientes subatributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.
  • Portabilidad. La facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes subatributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio.



  • MOSCA (Modelo Sistemático de Calidad)
Consta de 4 niveles: dimensiones, categorías, características y las métricas. En base de tres ramas: el producto, el proceso y la humana. Contiene un total de 715 métricas.









1 comentario: