El aseguramiento de calidad del software está presente en:

• Métodos y herramientas de análisis, diseño, programación y prueba.
• Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del software. Estrategias de prueba multisecular.
• Control de la documentación del software y de los cambios realizados.
• Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de ellos).
• Mecanismos de medida (métricas).
• Registro de auditorias y realización de informes.

Actividades del SQA

Establecimiento de un plan de SQA. El plan se desarrolla durante la planificación del proyecto y es revisado por todas las partes interesadas.

• Participación en el desarrollo de la descripción del proceso de software. El equipo selecciona el proceso para el desarrollo del software.
• Revisión de las actividades de ingeniería el software para verificar su ajuste al proceso de software definido. El grupo SQA identifica, documenta y sigue la pista de las desviaciones; verifica que se hayan hecho las correcciones e informa periódicamente de los resultados.
• Auditoria de los productos de software. El grupo SQA revisa los productos seleccionados y sigue la pista de las desviaciones.
• Asegurar que las estaciones de trabajo y los productos de software se documenten y se manejen conforme al proceso establecido.

Factores de Calidad

Son indicadores de la calidad del producto final según MacCall:

Operaciones del producto: características operativas

• Corrección: El grado en que una aplicación satisface sus especificaciones y consigue los objetivos encomendados por el cliente.
• Fiabilidad: El grado que se puede esperar de una aplicación lleve a cabo las operaciones especificadas y con la precisión requerida.
• Eficiencia: La cantidad de recursos hardware y software que necesita una aplicación para realizar las operaciones con los tiempos de respuesta adecuados.
• Integridad: El grado con que puede controlarse el acceso al software ó a los datos a personal no autorizado.
• Facilidad de uso: El esfuerzo requerido para aprender el manejo de una aplicación, trabajar con ella, introducir datos y conseguir resultados.

Revisión del producto: capacidad para soportar cambios

• Facilidad de mantenimiento: El esfuerzo requerido para localizar y reparar errores.
• Flexibilidad: El esfuerzo requerido para modificar una aplicación en funcionamiento.
• Facilidad de prueba: El esfuerzo requerido para probar una aplicación de forma que cumpla con lo especificado en los requisitos.

Transición del producto: adaptabilidad a nuevos entornos

• Portabilidad (¿Podré usarlo en otra máquina?): El esfuerzo requerido para transferir la aplicación a otro hardware o sistema operativo.
• Reusabilidad (¿Podré utilizar alguna parte del software en otra aplicación?): Grado en que partes de una aplicación pueden utilizarse en otras aplicaciones.
• Interoperabilidad (¿Podrá comunicarse con otras aplicaciones o sistemas informáticos?): El esfuerzo necesario para comunicar la aplicación con otras aplicaciones o sistemas informáticos.

Revisiones del Software

Es un filtro que se aplica durante el desarrollo del proyecto para detectar errores y defectos que puedan eliminarse.

Uno de estos filtros es la Revisión Técnica Formal (RTF). La cual es una actividad que garantiza la calidad del software, la cual tiene varios objetivos:

1. Descubrir errores en la función lógica o funcional.
2. Verificar que el software cumpla requisitos.
3. Garantiza los estándares en el software.
4. Construir un software uniforme.
5. Hacer que los proyectos sean manejables.

Reunión de RTF

Cada RFT se lleva acabo mediante una reunión la cual debe llevar ciertas características para tener éxito:

• Planificarla
• Controlarla
• Tener antecedentes

Restricciones de la RTF

1. Convocar a la reunión de 3 a 4 personas.
2. Preparación por adelantado (sin que se requiera mas de 2 hrs de trabajo).
3. La duración de la revisión debe ser menor a 2 hrs.

3.1 Análisis de Riesgos

Los riesgos son las posibles situaciones que se pueden presentar en el futuro y que puede implicar inesperadas situaciones en el desarrollo del proyecto, así como también pueden hacer fracasar el proyecto. Los riesgos pueden deberse a cuestiones económicas, cambios en los requerimientos del sistema, cuestiones técnicas, del personal.

El análisis de riesgos implica cuatro actividades:

1- Categorizar los riesgos

Consiste en enumerar los riesgos concretos de un proyecto de entre los que aparecen en las siguientes categorías:

• Riesgo del proyecto: estos provocan que la planificación se retrase y que los costos aumenten. Identifican potenciales problemas presupuestarios, de agenda, de personal (de la organización y de la asignación de personal), de recursos, de clientes y de requisitos, así como su impacto sobre el proyecto de software.
• Riesgos técnicos: estos amenazan la calidad y planificación temporal. Si se convierte en realidad, la implementación puede ser difícil o imposible. Identifican problemas de diseño, implementación, interfaz, verificación y mantenimiento. También la ambigüedad de la especificación, incertidumbre técnica, obsolescencia técnica, estos ocurren porque el problema es más difícil de resolver de lo que se pensaba.
• Riesgos de negocio: estos son los que amenazan la viabilidad del proyecto. Estos ponen en peligro el proyecto, los cinco principales son:
  1. Mercado: La construcción de un producto excelente que en realidad nadie quiere.
  2. Estratégico: la construcción de un producto que no se ajusta a la estrategia global de la empresa.
  3. La construcción de un producto que el departamento de ventas no sabe como vender.
  4. Dirección:
  5. Presupuestario: las perdidas presupuestarias o de personal asignado.

2.- Proyección de los Riesgos

La proyección del riesgo intenta evaluar cada riesgo de dos formas: la probabilidad de que el riesgo sea real y las consecuencias de los problemas asociados con el riesgo; así como el impacto que tenga el mismo (elevado costo, planeación temporal y bajo rendimiento, entre otros).

Para esto debemos realizar cuatro actividades:

1. Establecer una escala que refleje la probabilidad percibida del riesgo.
2. Definir las consecuencias del riego.
3. Estimar el impacto del riesgo en el proyecto.
4. Apuntar la exactitud general de la proyección del riego de manera que no haya confusiones.

3.- Evaluación del Riesgo

En este punto del proceso de análisis de riesgos, se han establecido un conjunto de ternas de la forma siguiente: [ri, li, xi]

1. ri: El riesgo
2. li: La probabilidad del riesgo
3. xi: El impacto del riesgo.

4.- Gestión de Riesgo

Se usa la terna [ri, li, xi] asociada con cada riesgo, como base a partir de la cual desarrollar los objetos de la gestión del riesgo:

1. Detectar la ocurrencia de un riesgo.
2. Detectar que las posibles soluciones del riesgo, estén aplicadas correctamente.
3. Recopilar la información que se pueda utilizar para futuros análisis de riesgos.

3.2 Control de Calidad

Buscar de forma activa la satisfacción del cliente, priorizando en sus objetivos la satisfacción de sus necesidades y expectativas (haciéndose eco de nuevas especificaciones para satisfacerlos).

1. Motivar a sus empleados para que sean capaces de producir productos o servicios de alta calidad.

Control de Calidad

En general son las actividades para evaluar la calidad de los productos desarrollados. Son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales:

• Mantener bajo control un proceso.
• Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

Aseguramiento de la Garantía de Calidad (SQA)

El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) que satisfará los requisitos dados de calidad. El objetivo de la SQA es proporcionar la administración para informar los datos necesarios sobre la calidad del producto.