Guía de verificación y validación de productos
Nombre | Rol |
---|---|
Erwin | Dueño de la guía |
Yaf | Autor |
Brindar una vista general a la forma de ejecutar las áreas de proceso de Verificación y Validación con la intención de que el trabajo del departamento sea el correcto y tenga la suficiente calidad.
Tanto el área de verificación como la de validación están muy relacionadas entre sí y por lo mismo, pueden ser abarcadas dentro de esta guía. Mientras que la validación asegura que se hace lo correcto, la verificación se asegura de que se haga de forma correcta
- Selección de productos y métodos
- Entorno de verificación y validación
- Criterios de verificación y validación
- Realizar la verificación y validación
- Análisis de resultados
-
Verificación: Para que sea considerado realizar una verificación a un producto de trabajo, este debe de cumplir los objetivos y requisitos del proyecto por medio de métodos de verificación. Estos métodos buscan verificar que un producto de trabajo específico cumple con sus requisitos propuestos. Algunos ejemplos de métodos son:
- Pruebas de aceptación
- Integración continua
- Reutilización de casos de pruebas
- Pruebas basadas en descomposición funcional
- Evaluación de arquitectura de software y de conformidad de implementación
-
Validación: Para que sea considerado realizar una validación a un producto de trabajo, este debe cumplir con las necesidades del usuario final. Los productos se clasifican en cuatro áreas: comportamiento operativo, mantenimiento, formación e interfaz de usuario. Algunos ejemplos de productos son:
- Requisitos y diseños de productos
- Productos y componentes
- Interfaz de usuario
- Manual de usuario
Al igual que la verificación existen métodos para validar los productos, los cuales permiten el desarrollo, mantenimiento, soporte y formación del producto. Algunos ejemplos de métodos son: * Juntas con los usuarios finales * Demostración de prototipos * Demostraciones funcionales * Entrega incremental del trabajo y del producto potencialmente aceptable * Análisis de producto y de componentes de producto
-
Verificación: Es necesario establecer un entorno con el fin de llevar a cabo la verificación, este puede ser adquirido, desarrollado, reutilizado, etc., según las necesidades del proyecto. Algunos ejemplos de entornos son: Herramientas:
- Emuladores
- Simuladores
- Interfaces con otros sistemas
- APIs
- Servidor de prueba
- Infrastructura:
- Salón de trabajo
- Equipo de trabajo
- Oficinas de la organización
- Ambiente para la revisión entre pares
- Producto de trabajo
- Checklists
- Procesos
- Guías
-
Validación: El entorno de validación depende de los productos seleccionados y al tipo de producto de trabajo, este puede incluir la reutilización de recursos existentes. Algunos ejemplos de entornos son:
- Servidor de prueba
- Hardware y software necesarios
- Métodos de usabilidad
- Acceso a Internet
- Instalaciones y productos proporcionados por el cliente
- Espacios para juntas con cliente
- Oficinas de trabajo
Los entornos utilizados para la verificación y validación de los productos pueden considerarse en colaboración con el fin de reducir costes y mejorar la eficiencia o la productividad. Una vez identificados, estos se deben de incluir en los productos y procesos del departamento o proyectos tal como en el WBS, juntas con cliente, juntas de iteración, guías y políticas.
-
Verificación:
- Estándares
- Requisitos de producto
- Políticas de la organización
- Tipos de prueba
- Revisión de clientes con los POs
- Checklists
- Programación entre pares
-
Validación:
- Estándares
- Requisitos de producto
- Criterios de aceptación del cliente
- Encuestas de satisfacción
- Juntas con cliente
-
Verificación: Con el fin de detectar problemas o defectos en el sistema se ejecutan diversas pruebas de verificación. Tras dichas pruebas los resultados obtenidos ahorran un coste considerable en resolución de fallos y el posible re-trabajo asociado con ellos.
-
Validación: Con el fin de que el cliente acepte un producto, este debe funcionar como se espera en su entorno previsto. Para esto se ejecutan las pruebas donde se obtienen los datos según los métodos y criterios establecidos para la validación. Estos procedimientos luego se documentan anotando las posibles desviaciones que ocurran durante la ejecución.
-
Verificación: Todos los errores o defectos detectados en los productos tras una verificación se deben de analizar tomando los datos del documento antes creado llamado defect log. Con base en el defect log se obtiene información tal como la calidad del sistema y productos, mayor fases de inyección, mayor fase de detección y el costo al equipo para su resolución.
-
Validación_ Se debe de analizar los resultados obtenidos en las pruebas y demostraciones con el cliente, cuyo objetivo es indicar si las necesidades fueron cumplidas de manera correcta. Cualquier deficiencia, o comentario trás hacer la validación pertinente se debe crear un documento detallando lo anterior mencionado (por ejemplo: minutas con cliente, manuales de usuarios, pruebas de usabilidad). En este documento se debe anotar el grado de éxito o fallo y sus posibles causas. Al finalizar, compare los datos obtenidos con los criterios de evaluación establecidos con el fin de determinar si se continúa con los productos o se trabaja en la corrección de requisitos o de diseño en los procesos o un posible cambio en la solución técnica.
versión 2.0
Nova Offical Wiki
- [PRO01] Proceso para generar un backlog
- [PRO02] Proceso de auditorías
- [PRO03] Proceso para definir un proceso
- [PRO04] Proceso para institucionalizar procesos, guías o políticas
- [PRO05] Proceso de Daily Meeting
- [PRO06] Proceso de inicio de iteración
- [PRO07] Proceso de cierre de iteración
- [PRO08] Proceso de modificación de línea base
- [PRO09] Proceso de gestión de historias de usuario
- [PRO10] Proceso para desarrollar una historia de usuario - Cannis Majoris
- [PRO11] Proceso de gestión de métricas
- [PRO13] Proceso de gestión de riesgos
- [PRO15] Proceso de acciones correctivas
- [PRO16] Proceso de reporte de estado
- [PRO17] Proceso de asignación de roles
- [PRO18] Proceso de validación
- [PRO20] Proceso de involucramiento de stakeholders
- [PRO21] Proceso para junta con el cliente
- [PRO22] Proceso de Pair Review
- [PRO23] Proceso de toma de decisiones
- [PRO24] Proceso de gestion de cambios a historias de usuario
- [PRO25] Proceso de recolección de requisitos
- [PRO26] Proceso para definir el alcance
- [PRO27] Proceso de SCAMPI
- [PRO28] Proceso de mejora continua
- [PRO29] Proceso de presentaciones
- [PRO30] Proceso de Acompañamiento para Competencia Oral
- [PRO31] Proceso de inspección
- [PRO32] Proceso de desarrollo de historias de usuario - Andrómeda
- [GUI01] Guía de CMMI
- [GUI02] Guía de manejo de configuración
- [GUI03] Guía de versionado
- [GUI04] Guía para institucionalizar procesos, guías y políticas
- [GUI05] Guía para agendar eventos
- [GUI06] Guía de Nova Flow
- [GUI07] Guía para definir un WBS
- [GUI08] Guía de especificación de requisitos
- [GUI09] Guía del ciclo de vida del proyecto
- [GUI10] Guía de petición de cambios a historias de usuario
- [GUI11] Guía de creación de métricas
- [GUI12] Guía de uso de Clockify
- [GUI13] Guía de entorno de verificación
- [GUI14] Guía de determinación de evaluación de decisiones
- [GUI15] Guía para estimar
- [GUI16] Guía de identificación de inconsistencias
- [GUI18] Guía del Program Manager
- [GUI19] Guía del Team Leader
- [GUI20] Guía para juntas de desempeño
- [GUI21] Guía para juntas de seguimiento personal
- [GUI22] Guía del Product Owner
- [GUI24] Guía de identificación de riesgos
- [GUI25] Guía del Team Member
- [GUI26] Guía de Validación de historias de usuario
- [GUI27] Guía para identificar procesos, guías y políticas
- [GUI28] Guía de resolución de conflictos
- [GUI29] Guía de denuncias
- [GUI30] Guía de estrategia técnica
- [GUI31] Guía de exposición oral
- [GUI32] Guía para la identificación de recursos del proyecto
- [GUI33] Guía de verificación y validación de productos
- [GUI34] Guía del Architect Owner
- [GUI35] Guía de Manuales
- [POL02] Política de juntas
- [POL03] Política de Nova WoW
- [POL04] Política de comunicación
- [POL05] Política de elementos de la configuración
- [POL06] Política de líneas base
- [POL07] Política de Configuration Control Board
- [POL09] Política de manejo de datos
- [POL11] Política de gestión de métricas
- [POL18] Política de gestión de habilidades y conocimientos
- [PLA01] Plantilla de proceso
- [PLA02] Plantilla de política
- [PLA03] Plantilla de guía
- [PLA04] Backlog de decisiones
- [PLA05] Backlog de requisitos
- [PLA06] Backlog de métricas
- [PLA07] Hoja de SCAMPI
- [PLA08] Checklist de SCAMPI
- [PLA09] Matriz de riesgos
- [PLA10] Reporte de inspección
- [PLA11] Checklist de institucionalización
- [PLA12] Plan de involucramiento de stakeholders
- [PLA13] Backlog de patrones
- [PLA14] Plan de iteración
- [PLA15] Plan de presentación
- [PLA16] Retrospectiva de la iteración
- [PLA17] Acta de proyecto
- [PLA18] Backlog de PIPs
- [PLA19] Hoja de especificación de requisitos
- [PLA20] Reporte de Pair Review
- [PLA21] Backlog de roles
- [PLA22] Plantilla de auditorías
- [PLA23] Checklist de reporte de estado
- [PLA24] Plantilla para validación con cliente
- [PLA25] Plantilla de minuta de junta