Post on 29-Sep-2018
Aseguramiento de la calidad y pruebas de software
3- Verificación y validación de software
Blanca A. Vargas Govea vargasgovea@itesm.mxFebrero 19, 2013
2
Objetivo
Identificar la integración del plan de verificación y validación en el proceso de desarrollo de software.
3
¿Cómo se integra la V&V?
¿Y cómo voy a integrar la verificación y validación
en mi proyecto?
4
Requerimientosde uso
Diseño lógico
Diseño físico
Diseño de programasunitarios
Codificación
Metodología de desarrollo en cascada.
Fases discretas, cada fase se termina antes de que la siguiente inicie. En teoría, una vez terminada una fase, no se regresa a cambiarla.
1
2
3
4
5
5
¿Esperar hasta tener el programa hecho?
Se puede hacer desde la Fase 1. Para cada fase
se utilizan distintas técnicas.
6
Fases de desarrollo vs. tipos de pruebas
7
Fase 1
Requerimientos de uso
8
Fase 1: Requerimientos de uso
● Los usuarios son entrevistados.
● Los requerimientos son recolectados y analizados.
● Se genera un documento detallando los requerimientos.
● Descomposición jerárquica de funciones (e.g., descripción, diagramas).
● Descripción de datos: e.g., si la bd es relacional, entidades, atributos, relaciones.
● Descripción de interfaces: entre el sistema y entidades externas.
● Descripción de cómo los usuarios interactuarán con el sistema: forma de la interfaz y las capacidades tácnicas del usuario.
¿Qué se hace en fase 1? ¿Qué se debe incluir?
9
Fase 1: Requerimientos de uso
● Verificación de requerimientos. Los documentos deben ser correctos y completos.
● Requerimientos pobres
– Conjunto parcial de funciones definidas.
– Requerimientos ambiguos, contradictorios redundantes.
– Interfaces no documentadas.
● Inspecciones: revisión formal de documentación.
● Recorridos: revisión informal de documentación.
● Checklists.● Matriz de rastreo de
requerimientos● Construcción del plan de
pruebas.
Actividades V&V Técnicas V&V
Técnicas estáticas: no ejecución de la aplicación
10
Registro de defectos de la fase de requerimientos
11
Fase 2
Diseño Lógico
12
Fase 2: Diseño lógico
● Refina la fase de requerimientos.
● Punto de vista de datos y funcional.– Modelo de datos– Modelo de proceso– Enlace entre ambos
● Modelo de datos: define entidades y relaciones– Entidad: persona, lugar, cosa,
evento– Relaciones: asociación de 2 o
más entidades
● Modelo de proceso:– Actividades, entradas y
salidas asociadas.– No describen por qué o cómo
o cuándo.
¿Qué se hace en la fase 2? Modelos esperados
13
Fase 2: Diseño lógico
● Diagrama de asociaciones: – Matriz CRUD (Create,
Read, Update, Delete). Mapea procesos vs entidades mostrando qué procesos crean, leen, actualizan o borran las instancias en una entidad.
● El analista:– Verifica que haya un
proceso asociado para crear instancias de una entidad.
– Si hay una entidad no asociada a un proceso, falta, hay que definirlo.
Modelos esperados Actividades V&V
Entidad: persona, lugar, cosa o evento de interés al usuario. Todo aquéllo sobre lo que querríamos guardar información.
14
Fase 2: Diseño lógico
● Verificar la adherencia a convenciones de las especificaciones y completez de los modelos.
● Se evaluarán los modelos de datos, de procesos y de asociación.
● Cada defecto debe documentarse.– Descripción del defecto.– Documento de referencia.
Actividades V&V Actividades V&V
Técnicas estáticas: no ejecución de la aplicación
15
Matriz CRUD (Create, Read, Update, Delete)
16
Fase 3
Diseño físico
17
Fase 3: Diseño físico
● Supone que los requerimientos y diseño lógico están correctos.
● Se concentra en la integración misma del diseño.
● Diagramas de estructura.
● Diagramas Warnier Orr.
● Diagramas Jackson.
¿Qué se hace en la fase 3? Modelos esperados
Técnicas estáticas: no ejecución de la aplicación
18
Fase 3: Diseño físico
● Inconsistencias al especificar el flujo de control y entre módulos. Un módulo puede requerir datos que otro módulo crea pero no lo proporciona.
● Acoplamiento entre módulos. Revisar el grado de independencia entre módulos.
Ejemplos de errores Ejemplos de errores
20
Fase 4
Diseño de unidad de programa
21
Fase 4: Diseño de unidad de programa
● Es la especificación del flujo de control que se traducirá a código de programación.– Algoritmos específicos.– Estructuras de datos.
● Verifica los flujos de control y estructuras de datos.
● Se crean casos de prueba unitaria.
¿Qué se hace en la fase 4? Actividades V&V
Técnicas estáticas: no ejecución de la aplicación
22
Registro de defectos de la fase de unidad de programa
23
Fase 5
Codificación
24
Fase 5: Codificación
● Traducción a código ejecutable.
● Módulos ejectuables.● Estándares:
comentarios, identación, inicialización.
● Técnicas estáticas– Inspecciones.– Recorridos
estructurados.
Aseguran la forma adecuada de código y documentación.
¿Qué se hace en la fase 5? Actividades V&V
Técnicas estáticas: no ejecución de la aplicaciónTécnicas dinámicas: ejecutar secuencia
25
Fase 5: Codificación
● Técnicas dinámicas– Ejecutar una secuencia
específica de instrucciones– Estudian la correctez
funcional y computacional.
● Pruebas de integración. Los módulos se agregan de forma incremental.
● Pruebas de sistema. Se prueba el sistema completo.
● Pruebas de aceptación. Se certifica que el sistema satisface los requerimientos originales.
Actividades V&V Actividades V&V
26
Registro de defectos de la fase de codificación
27
Actividad: en equipo
● Con base en su proyecto, elaborar un reporte en el cual– Se determine la técnica de modelado qué usarán.– Para la fase 1: requerimientos de uso. Elaborar la
descomposición jerárquica de su proyecto. Por ejemplo, si se usa el Proceso Unificado con UML, la descomposición estará representada por1. Diagramas de Actividades
2. Descripciones y Diagramas de Casos de uso
28
Tarea: en equipo
● Revisar la primera parte del estándar IEEE-1012 “Standard for Software Verification and Validation” secciones 1 a 5.
● Con base en la sesión de hoy, ¿qué características del proceso de verificación y validación propuesto por esos puntos (1-5) estándar se aplicarán en tu proyecto?
Elabora un reporte y envíalo por correo.
Fecha de entrega: Viernes Febrero 22