Validación

Elaborado por: *Jesús Alberto Sosa Barón*

**La verificación y validación:** tiene como propósito ayudar a la organización en el desarrollo, a incorporar calidad en el sistema durante el ciclo de vida. Los procesos de V&V proporcionan una evaluación objetiva de productos y procesos a lo largo del ciclo de vida. Esta evaluación demuestra si los requisitos son correctos, completos, precisos, consistentes y comprobables. Los procesos de V&V determinan si los productos de desarrollo de una actividad determinada se ajustan a los requisitos de esa actividad y si el producto satisface el uso previsto y las necesidades del usuario (IEEE, 2012, p.15).

La verificación es un intento de garantizar que el producto se construye correctamente, en el sentido de que los productos de una actividad cumplen con las especificaciones que se les impusieron en actividades anteriores (IEEE, 2012, p.15).

La validación es un intento de garantizar que se construya el producto correcto, es decir, que el producto cumpla su propósito específico. Tanto el proceso de verificación como el proceso de validación comienzan temprano en la fase de desarrollo o mantenimiento. Proporcionan un examen de las características clave del producto en relación tanto con el predecesor inmediato del producto como con las especificaciones que deben cumplirse. El propósito de planificar V&V es garantizar que cada recurso, función y responsabilidad esté claramente asignado. Los documentos del plan V&V resultantes describen los diversos recursos y sus funciones y actividades, así como las técnicas y herramientas que se utilizarán. La comprensión de los diferentes propósitos de cada actividad de V&V ayuda a planificar cuidadosamente las técnicas y recursos necesarios para cumplir sus propósitos. El plan también aborda la gestión, comunicación, políticas y procedimientos de las actividades de V&V y su interacción, así como los requisitos de documentación e informes de defectos (IEEE, 2012, p.15 ).

Ejemplo:

**Revisiones y Auditorías**

Los procesos de revisión y auditoría están ampliamente definidos. como estático, lo que significa que ningún programa de software o Se ejecutan los modelos: examen del software. artefactos de ingeniería con respecto a los estándares que han sido establecidos por la organización o proyecto para esos artefactos. Diferentes tipos de reseñas y las auditorías se distinguen por su propósito, niveles de independencia, herramientas y técnicas, roles, y por el tema de la actividad. Las auditorías de garantía del producto y de garantía del proceso suelen ser realizado por control de calidad del software (SQA) personal independiente del desarrollo Calidad del software. Las revisiones de la gestión son realizadas por gestión organizacional o de proyectos. El personal de ingeniería realiza revisiones técnicas (IEEE, 2012, p.15).

1. • Las revisiones de la dirección evalúan el proyecto real. resultados con respecto a los planes (IEEE, 2012, p.15).
2. • Revisiones técnicas (incluidas inspecciones, recorrido y verificación de escritorio) examinar productos de trabajo de ingeniería (IEEE, 2012, p.15).
3. • Auditorías de aseguramiento de procesos. proceso SQA Las actividades de aseguramiento aseguran que procesos utilizados para desarrollar, instalar, operar, y mantener el software conforme a los contratos, cumplir con las leyes, reglas y regulaciones y son adecuados, eficientes y eficaces para el fin previsto(IEEE, 2012, p.15).
4. • Auditorías de aseguramiento de producto. Producto SQA Las actividades de aseguramiento se aseguran de proporcionar evidencia de que los productos de software y relacionados (IEEE, 2012, p.15).

La documentación está identificada y cumple. con contratos; y garantizar que se identifiquen y aborden las no conformidades.

**Consideraciones**

1. Consideraciones prácticas
2. Requisitos de calidad del software
3. Factores de influencia

Varios factores influyen en la planificación, la gestión, y selección de actividades y técnicas de SQM, incluido (IEEE, 2012, p.15).

1. el dominio del sistema en el que reside el software; las funciones del sistema podrían ser críticos para la seguridad, críticos para la misión, críticos para el negocio, críticos para la seguridad (IEEE, 2012, p.15).
2. el entorno físico en el que reside el sistema de software (IEEE, 2012, p.15).
3. sistema y software funcional (cuál lo hace el sistema) y los requisitos de calidad (qué tan bien el sistema realiza sus funciones) (IEEE, 2012, p.15).
4. los componentes comerciales (externos) o estándar (internos) que se utilizarán en el sistema (IEEE, 2012, p.15).

rendimiento deseado, confiabilidad u otras características únicas del proyecto que definen La importancia del software para el usuario. y adquirente. Las características utilizadas para determinar el nivel de integridad del software variar dependiendo de la aplicación prevista y uso del sistema. El software es parte del sistema y su nivel de integridad debe ser determinado como parte de ese sistema. Los niveles de integridad del software asignados pueden cambian a medida que el software evoluciona. Diseño, codificación, características procesales y tecnológicas implementadas en el sistema o software puede aumentar o disminuir el nivel de integridad del software asignados. El software Niveles de integridad establecidos para el resultado de un proyecto. de acuerdos entre el adquirente, proveedor, desarrollador y autoridades de aseguramiento independientes. Un esquema de niveles de integridad del software es una herramienta utilizada en Determinar los niveles de integridad del software.  Como se señala. “los niveles de integridad pueden ser aplicados durante el desarrollo para asignar recursos adicionales esfuerzos de verificación y validación para componentes de alta integridad” (IEEE, 2012, p.15).

**Referencias**

IEEE Computer Society. (2014). Guide to the Software Engineering Body of Knowledge. En *IEEE Computer Society.*