domingo, 2 de enero de 2011

Calidad del Software

Conceptos de calidad

El American Heritage Dictionary, define la calidad como «una característica o atributo de algo». Como un atributo de un elemento, la calidad se refiere a las características mensurables -cosas que se pueden comparar con estándares conocidos como longitud, color, propiedades eléctricas, maleabilidad, etc.-. Sin embargo, el software en su gran extensión, como entidad intelectual, es más difícil de caracterizar que los objetos físicos.

No obstante, existen las medidas de características de un programa. Entre estas propiedades se incluyen complejidad ciclomática, cohesión, número de puntos de función, líneas de código y muchas otras. Cuando se examina un elemento según sus características mensurables, se pueden encontrar dos tipos de calidad: calidad del diseño y calidad de concordancia.

La calidad de diseño se refiere a las características que especifican los ingenieros de software para un elemento. El grado de materiales, tolerancias y las especificaciones del rendimiento contribuyen a la calidad del diseño. Cuando se utilizan materiales de alto grado y se especifican tolerancias más estrictas y niveles más altos de rendimiento, la calidad de diseño de un producto aumenta, si el producto se fabrica de acuerdo con las especificaciones.

La calidad de concordancia es el grado de cumplimiento de las especificaciones de diseño durante su realización.

Una vez más, cuanto mayor sea el grado de cumplimento, más alto será el nivel de calidad de concordancia.

Concordancia con los requisitos 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.


La tendencia de la calidad

Hoy en día los responsables expertos de compañías de todo el mundo industrializado reconocen que la alta calidad del producto se traduce en ahorro de coste y en una mejora general. Sin embargo, esto no era siempre el caso. La tendencia de la calidad comenzó en los años cuarenta con el influyente trabajo de W. Edwards Deming. Mediante las ideas de Deming como piedra angular, los japoneses han desarrollado un enfoque sistemático para la eliminación de las causas raíz de defectos en productos.

A lo largo de los años setenta y ochenta, su trabajo emigró al mundo occidental y a veces se llama «gestión total de calidad (GTC). Aunque la terminología difiere según los diferentes países y autores, normalmente se encuentra una progresión básica de cuatro pasos que constituye el fundamento de cualquier programa de GTC.


Garantía de calidad del software

La garantía de calidad consiste en la auditoría y las funciones de información de la gestión. El objetivo de la garantía de calidad es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más profunda y segura de que la calidad del producto está cumpliendo sus objetivos. Por supuesto, si los datos proporcionados mediante la garantía de calidad identifican problemas, es responsabilidad de la gestión afrontar los problemas y aplicar los recursos necesarios para resolver aspectos de calidad.


Revisiones del software

Las revisiones del software son un «filtro» para el proceso de ingeniería del software. Esto es, las revisiones se aplican en varios momentos del desarrollo del software y sirven para detectar errores y defectos que puedan así ser eliminados. Las revisiones del software sirven para «purificar» las actividades de ingeniería del software que suceden como resultado del análisis, el diseño y la codificación.


Revisiones técnicas formales

Una revisión técnica formal (RTF) es una actividad de garantía de calidad del software llevada a cabo por los ingenieros del software (y otros). Los objetivos de la

RTF son:

· Descubrir errores en la función, la lógica o la implementación de cualquier representación del software

· Verificar que el software bajo revisión alcanza sus requisitos

· Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos

· Conseguir un software desarrollado de forma uniforme

· Hacer que los proyectos sean más manejables.

Además, la RTF sirve como campo de entrenamiento, permitiendo que los ingenieros más jóvenes puedan observar los diferentes enfoques de análisis, diseño e implementación del software. La RTF también sirve para promover la seguridad y la continuidad, ya que varias personas se familiarizarán con partes del software que, de otro modo, no hubieran visto nunca.



Fiabilidad del software

La fiabilidad del software, a diferencia de otros factores de calidad, puede ser medida o estimada mediante datos históricos o de desarrollo. La fiabilidad del software se define en términos estadísticos como «la probabilidad de operación libre de fallos de un programa de computadora en un entorno determinado y durante un tiempo específico» [MUS87]. Por ejemplo, un programa X puede tener una fiabilidad estimada de 0,96 durante un intervalo de proceso de ocho horas. En otras palabras, si se fuera a ejecutar el

Programa X 100 veces, necesitando ocho horas de tiempo de proceso (tiempo de ejecución), lo probable es que funcione correctamente (sin fallos) 96 de cada 400 veces.



Prueba de errores para el software

En los años sesenta, un ingeniero industrial japonés, Shigeo Shingo, que trabajaba en Toyota, desarrolló una técnica de garantía de calidad que conducía a la prevención

y/o a la temprana corrección de errores en el proceso de fabricación. Denominado poku-yoke (prueba de errores), el concepto de Shingo hacía uso de dispositivospoku-yoke -mecanismos que conducen:

(1) a la prevención de un problema de calidad potencial antes de que éste ocurra, o

(2) a la rápida detección de problemas de calidad si se han introducido ya-.

Nosotros encontramos dispositivos poka-yoke en nuestra vida cotidiana (incluso si nosotros no tenemos conciencia de este concepto). Por ejemplo, el interruptor de arranque de un coche no trabaja si está metida una marcha en la transmisión automática (un dispositivo de prevención); un pitido de aviso del coche sonará si los cinturones de seguridad no están bien sujetos (un dispositivo de detección de fallos).

Un dispositivo de poku-yoke presenta un conjunto de características comunes:

  • Es simple y barato -si un dispositivo es demasiado complicado y caro, no será efectivo en cuanto a costo-;
  • Es parte del proceso - esto es, el dispositivo pokuyoke está integrado en una actividad de ingeniería
  • Está localizado cerca de la tarea del proceso donde están ocurriendo los errores -por consiguiente proporciona una realimentación rápida en cuanto a la corrección de errores se refiere-.


El estándar de calidad iso 9001

Es el estándar, que ha sido adoptado por más de 130 países para su uso, se está convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de un desarrollador de software. Uno de los problemas con el estándar ISO 9001 está en que no es específico de la industria: está expresado en términos generales, y puede ser interpretado por los desarrolladores de diversos productos como cojinetes de bolas (rodamientos), secadores de pelo, automóviles, equipamientos deportivos y televisiones, así como por desarrolladores de software. Se han realizado muchos documentos que relacionan el estándar con la industria del software, pero no entran en una gran cantidad de detalles. El objetivo de esta sección es describir lo que significa el ISO 9001 en términos de elementos de calidad y técnicas de desarrollo.

Para la industria del software los estándares relevantes son:

ISO 9001. Quality Systems- Model for Quality Assurance in Design, Development, Production, Installation and Servicing. Este es un estándar que describe el sistema de, calidad utilizado para mantener el desarrollo de un producto que implique diseño.

ISO 9000-3. Guidelines for Application of ISO 9001 to the Development, Supply and Maintainance of Software. Este es un documento específico que interpreta el ISO 9001 para el desarrollador de software.

ISO 9004-2. Quality Management and Quality System Elements -Part 2-. Este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios.

Los requisitos se agrupan bajo 20 títulos:

  • Responsabilidad de la gestión.
  • Inspección, medición y equipo de pruebas
  • Sistema de calidad.
  • Inspección y estado de pruebas.
  • Revisión de contrato.
  • Acción correctiva.
  • Control de diseño.
  • Control de producto no aceptado.
  • Control de documento.
  • Tratamiento, almacenamiento, empaquetamiento y entrega.
  • Compras.
  • Producto proporcionado al comprador.
  • Registros de calidad.
  • Identificación y posibilidad de seguimiento del producto,
  • Auditorías internas de calidad
  • Formación
  • Control del proceso
  • Servicios.
  • Inspección y estado de prueba.
  • Técnicas estadísticas.


Fuente:

Roger Pressman, Ingenieria del Software un enfoque practico, Edición V.

Análisis y Gestión de Riesgo



¿Qué es?

El análisis y la gestión del riesgo son una serie de pasos que ayudan al equipo del software a comprender y a gestionar la incertidumbre.

Un proyecto de software puede estar lleno de problemas. Un riesgo es un problema potencial –puede ocurrir o no-. Pero sin tener en cuenta el resultado, realmente es una buena idea identificarlo, evaluar su probabilidad de aparición, estimar su impacto, y establecer un plan de contingencia por si ocurre el problema.

¿Quién lo hace?

Todos los que estén involucrados en el proceso del software

-gestores, ingenieros de software y clientes- participan en el análisis y la gestión del riesgo.


¿Por qué es importante?

Pensemos en el lema de los boys scout: «estar preparados». El software es una empresa difícil.

Muchas cosas pueden ir mal, y francamente, a menudo van mal. Esta es la razón para estar preparados –comprendiendo los riesgos y tomando las medidas proactivas para evitarlo o gestionarlo- es un elemento clave de una buena gestión de proyectos de software.

¿Cuáles son los pasos?

El reconocimiento de que algo puede ir mal es el primer puso, llamado identificación del riesgo. A continuación, cada riesgo es analizado para determinar la probabilidad de que pueda ocurrir y el daño que puede causar si ocurre. Una vez establecida esta información, se priorizan los riesgos, en función de la probabilidad y del impacto. Por último, se desarrolla un plan para gestionar aquellos riesgos con gran probabilidad e impacto.


¿Cuál es el producto obtenido?

Se realiza un Plan de Reducción, Supervisión y Gestión del Riesgo (RSGR) o un informe de riesgos.


¿Cómo puedo estar seguro de que lo he hecho correctamente?

Los riesgos analizados y gestionados deberían derivarse del estudio del personal, del producto, del proceso y del proyecto.

El RSGR debe ser revisa do mientras el proyecto se realiza para asegurar que los riesgos están siendo controlados hasta la fecha. Los planes de contingencia para la gestión del riesgo deben ser realistas.


Estrategias:

Reactivo

En el mejor de los casos, la estrategia reactiva supervisa el proyecto en previsión de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas reales. Pero lo más frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal. Después el equipo vuela para corregir el problema rápidamente. Este es el método denominado a menudo «de bomberos». Cuando falla, «la gestión de crisis» [CHA92] entra en acción y el proyecto se encuentra en peligro real.

Proactiva

Una estrategia considerablemente más inteligente para el control del riesgo es ser proactivo. La estrategia proactiva empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se evalúa su probabilidad y su impacto y se establece una prioridad según su importancia. Después, el equipo de Software establece un plan para controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se pueden evitar todos los riesgos, el equipo trabaja para desarrollar un plan de contingencia que le permita responder de una manera eficaz y controlada. A lo largo de lo que queda de este capítulo, estudiamos la estrategia proactiva para el control de riesgos.

Características

Aunque ha habido amplios debates sobre la definición adecuada para riesgo de software, hay acuerdo común en que el riesgo siempre implica dos características

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por 100 de probabilidad'.

Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

Tipos de riesgos

Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costes aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos, cliente y requisitos y su impacto en un proyecto de software. En el Capítulo 5, la complejidad del proyecto, tamaño y el grado de incertidumbre estructural fueron también definidos como factores (y estimados) de riesgo del proyecto.

Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, de interfaz, verificación y de mantenimiento. Además, las ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las «tecnologías punta» son también factores de riesgo.

Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos.

Los riesgos del negocio amenazan la viabilidad del software a construir. Los riesgos del negocio a menudo ponen en peligro el proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son:

1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado).

2. Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico).

3. Construir un producto que el departamento de ventas no sabe cómo vender.

4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección).

5. Perder presupuesto o personal asignado (riesgos de presupuesto).

Es extremadamente importante recalcar que no siempre funciona una categorización tan sencilla. Algunos riesgos son simplemente imposibles de predecir.

Otra categorización general de los riesgos ha sido pre puesta por Charette. Los riesgos conocidos son todos aquellos que se pueden descubrir después de una cuidadosa evaluación del plan del proyecto, del entorno técnico y comercial en el que se desarrolla el proyecto y otras fuentes de información fiables (por ejemplo: fechas de entrega poco realistas, falta de especificación de requisitos o de ámbito del software, o un entorno pobre de desarrollo).

Los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (por ejemplo: cambio de personal, mala comunicación con el cliente, disminución del esfuerzo del personal a medida que atienden peticiones de mantenimiento).

Los riesgos impredecibles son el comodín de la baraja. Pueden ocurrir, pero son extremadamente difíciles de identificar por adelantado.

¿Qué es la identificación de un riesgo y cuál es su clasificación?

La identificación del riesgo es un intento sistemático para especificar las amenazas al plan del proyecto (estimaciones, planificación temporal, carga de recursos,

etc.). Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario.

Existen dos tipos diferenciados de riesgos para cada categoría presentada:

Riesgos genéricos y riesgos específicos del producto.

Los riesgos genéricos son una amenaza potencial para todos los proyectos de software.

Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión. Para identificar los riesgos específicos del producto, se examinan el plan del proyecto y la declaración del ámbito del software y se desarrolla una respuesta a la siguiente pregunta:

«¿Qué características especiales de este producto pueden estar amenazadas por nuestro plan del proyecto?»

¿Cuál es la evaluación global del riesgo del proyecto, los componentes y controladores del riesgo?


Evaluación Global del Riesgo del Proyecto

Las siguientes preguntas provienen de los datos del riesgo obtenidos mediante las encuestas realizadas a gestores de proyectos de software expertos de diferentes partes del mundo [KEI98]. Las preguntas están ordenadas por su importancia relativa para el éxito de un proyecto.


¿Corre un riesgo grave el proyecto de software en el que estamos trabajando?

1. ¿Se han entregado los gestores del software y clientes formalmente para dar soporte al proyecto?

2. ¿Están completamente entusiasmados los usuarios finales con el proyecto y con el sistema/producto a construir?

3. ¿Han comprendido el equipo de ingenieros de software y los clientes todos los requisitos?

4. ¿Han estado los clientes involucrados por completo en la definición de los requisitos?

5. ¿Tienen los usuarios finales expectativas realistas?

6. ¿Es estable el ámbito del proyecto?

7. ¿Tiene el ingeniero de software el conjunto adecuado de habilidades?

8. ¿Son estables los requisitos del proyecto?

9. ¿Tiene experiencia el equipo del proyecto con la tecnología a implementar?

10. ¿Es adecuado el número de personas del equipo del proyecto para realizar el trabajo?

11. ¿Están de acuerdo todos los clientes/usuarios en la importancia del proyecto y en los requisitos del sistema/ producto a construir?


Componentes y controladores del riesgo


Se requiere que el gestor del proyecto identifique los controladores del riesgo que afectan a los componentes de riesgo del software, rendimiento, coste, soporte y planificación temporal-.

En el contexto de este estudio, los componentes de riesgo se definen de la siguiente manera:

Riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su empleo pretendido;

Riesgo de coste: el grado de incertidumbre que mantendrá el presupuesto del proyecto;

Riesgo de soporte: el grado de incertidumbre de la facilidad del software para corregirse, adaptarse y ser mejorado;

Riesgo de la planificación temporal: el grado de incertidumbre con que se podrá mantener la planificación temporal y de que el producto se entregue a tiempo.

El impacto de cada controlador del riesgo en el componente de riesgo se divide en cuatro categorías de impacto



¿Cómo se realiza la estimación del riesgo?

La proyección del riesgo, también denominada estimación del riesgo, intenta medir cada riesgo de dos maneras

-la probabilidad de que el riesgo sea real

-las consecuencias de los problemas asociados con el riesgo, si ocurriera-.

El jefe del proyecto, junto con otros gestores y personal técnico, realiza cuatro actividades de proyección del riesgo:

-establecer una escala que refleje la probabilidad percibida del riesgo;

-definir las consecuencias del riesgo;

-estimar el impacto del riesgo en el proyecto y en el producto

-apuntar la exactitud general de la proyección del riesgo de manera que no haya confusiones.


¿Cuáles son los beneficios de realizar una estimación de proyectos?

El tiempo invertido identificando, analizando y gestionando el riesgo merece la pena por muchas razones:

-menos trastornos durante el proyecto

-una mayor habilidad de seguir y controlar el proyecto

-la confianza que da planificar los problemas antes de que ocurran.

El análisis de riesgos puede absorber una cantidad significativa del esfuerzo de planificación del proyecto.