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