Aseguramiento de la calidad y pruebas de software

4- Revisiones del software

Blanca A. Vargas Govea vargasgovea@itesm.mx

Febrero 22, 2013

2

Objetivo

Conocer los tipos de revisiones y sus características para poder seleccionar la más adecuada.

3

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?

Recordando

4

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

Recordando

5

Revisiones

● Analistas y equipo de desarrollo → dificultad de detectar los propios errores.

● Es mejor colegas, →superiores, expertos, representantes del cliente.

¿Errores yo?

6

Proceso de revisión

“Proceso o reunión durante el cual, un producto de trabajo, o conjunto de productos es presentado a personal, mánagers, usuarios, clientes y partes interesadas para comentar o aprobar”.

7

Motivación

● Proporcionan detección temprana de errores.

● Ayudan a identificar requerimientos faltantes o ambiguos.

● Permiten encontrar discrepancias.

● Reducen el número de fallas durante testing.

● Reducen costo de desarrollo.

¡Terminamos a tiempo!

8

Objetivos

● Detectar errores de análisis y diseño así como aspectos en los cuales se requieran correcciones y cambios en relación a las especificaciones originales.

● Identificar riesgos probables que afecten la terminación del proyecto.

● Identificar desviaciones a los estándares.

● Aprobar el análisis/diseño del producto.

9

Tipos de revisiones

2. Informales

Inspecciones

Recorridos

1. Formales

10

1. Revisiones formales

● Son las únicas necesarias para aprobar el diseño del producto.

● Pueden aplicarse en cada fase. Ejemplos:– Especificación de

requerimientos.– Plan de instalación.

Requieren definir:

1. Participantes.

2.Preparación previa.

3.Desarrollo de la sesión.

4.Actividades post-reunión.

11

1. Revisiones formales: participantes

● Conducidas por un líder revisor y su equipo.

● Líder: – Conocedor y

experimentado. – De preferencia de mayor

nivel que el líder del proyecto.

– Buena relación con el líder de proyecto.

– Externo al equipo desarrollador.

● Equipo:– De 3 a 5 personas

seleccionadas por el líder por su experiencia.

– Externos al equipo desarrollador.

● Si la organización es pequeña se sugieren consultores externos.

12

1. Revisiones formales: preparación previa

● Líder revisor– Designar a los

miembros de su equipo.

– Calendarizar sesiones de revisión.

– Distribuir el documento de diseño entre su equipo.

● Equipo:– Revisar el documento

de diseño y listar sus comentarios.

– Aplicar checklists.

13

1. Revisiones formales: desarrollo de la sesión

● Presentación corta del documento de diseño.

● Comentarios del equipo revisor.

● Verificación & validación, comentarios para determinar acciones requeridas: correcciones, cambios.

● Emitir la decisión– Aprobación total.– Aprobación parcial.– Aprobación denegada.

14

1. Revisiones formales: tipos de decisión

● Aprobación total →permite la continuación inmediata a la siguiente fase. Puede ir acompañada de correcciones menores.

15

1. Revisiones formales: tipos de decisión

● Aprobación parcial permite →la continuación inmediata a la siguiente fase para algunas partes del proyecto con correcciones, cambios y adiciones mayores para el resto del proyecto.

16

1. Revisiones formales: tipos de decisión

● Aprobación denegada se aplica en casos →

de defectos mayores múltiples, particularmente defectos críticos. Se realiza una repetición.

Qué exigentes, snif

17

1. Revisiones formales: actividades post-reunión

● Emitir un reporte después de la sesión de revisión.

● Secciones:– Resumen de las discusiones.– Decisión.– Lista de acciones requeridas,

correcciones, cambios y adiciones.

– Responsables y fechas de entrega.

– Nombre de equipo asignado para seguimiento.

● Formatos – Apéndice 8A– Apéndice 8B

En el archivo: revisionesFormatos.pdf

18

1. Revisiones formales: actividades post-reunión

Características de un mal reporte:– Muy corto, limitado a

aprobar/desaprobar el diseño sin listar defectos detectados.

– Aprueba totalmente y lista los defectos pero sin acciones a realizar.

● Aprueba total o parcialmente y lista las acciones pero no indica actividades de seguimiento.

19

Revisión formal

20

2. Revisiones informales: inspecciones

● Revisión formal el →líder revisor tiene mayor posición que el líder de proyecto y representante del cliente.

● Revisión informal son →iguales.

● No se enfocan en aprobar/desaprobar.

● Objetivo– Detectar errores y

desviaciones de los estándares.

21

2. Revisiones informales: inspecciones

1. Participantes– Líder entrenamiento →

como moderador.– Equipo revisor.– Presentador de documento

(neutro).– Secretario.– Autor.– Profesionales especializados

diseñador, programador, →tester.

– Representante del cliente.

2.Preparación– Líder determinar junto →

con el autor, qué secciones del documento de diseño se revisarán: las más difíciles y complejas, las más críticas, las más propensas a defectos.

– Seleccionar a los miembros del equipo.

– Calendarizar sesiones.– Distribuir el documento al

equipo.

22

2. Revisiones informales: inspecciones

– Equipo leer el →documento y emitir comentarios antes de la inspección.

– Checklists.

3.Sesión― El presentador lee una

sección del documento.― Los participantes comentan.― La discusión se centra en la

identificación de errores.― El secretario documenta

cada error, ubicación, tipo, severidad.

23

3. Revisiones informales: inspecciones

Documentación– Reporte de hallazgos

Apéndice 8B– Reporte de inspección

Apéndice 8C– Se envían al equipo de

desarrollo

4.Actividades post-revisión― Objetivo: corrección de

errores por el autor y su equipo.

― Envío de reportes.

24

4. Revisiones informales: recorridos

● Presentación en la cual el desarrollador describe el documento de diseño y el grupo proporciona retroalimentación.

● Se limita a los comentarios sobre los documentos revisados.

● Localización de desviaciones de los estándares.

● Localización de defectos de diseño.

● Completez y correctez de documentación.

● Representante del usuario.

25

26

¿Qué tipo de revisión aplicarías a los proyectos del grupo? ¿por qué?

27

Para la fase de diseño se aplicará:

Inspección ● No se asigna aprobación o desaprobación.

● Todos iguales.● Se identifican errores

y se dan métricas básicas.

28

¿Qué necesitan tener? - equipo de desarrollo

● Documento de requerimientos – Apéndice C (formatos1.pdf)– Ejemplo(http://blancavg.com/tc3044swq/CMMsmallorg.pdf)– Modelado orientado a requerimientos: e.g., casos de uso,

interfaces de usuario.

29

¿Qué necesitan tener? - equipo de revisión

● Plan de aseguramiento de calidad. Apéndice B (formatos1.pdf).– Secciones: 1, 2.4, 4, 5 y 6

● Checklists (formatos1.pdf)● Formatos para el reporte de inspección

(revisionesFormatos.pdf)

30

Actividad 9 - Equipo

● Hacer una lista TODO para sus dos roles:– Equipo de desarrollo– Equipo revisor de calidad

● Seleccionar herramienta de control de tareas y tiempo.

Elaborar un reporte de ambos puntos en un documento pdf. Enviar por correo.

31

Tarea 9 - Equipo

● Elaborar el modelado orientado a requerimientos para su proyecto– Funcional– Interfaces de usuario

Fecha de entrega: Martes 26 de Febrero

32

Herramientas de tracking

● Linux– KTimetracker http://userbase.kde.org/KTimeTracker– Getting things gnome + hamster tracker gnome

● http://gtg.fritalk.com/● http://projecthamster.wordpress.com/

● Windows:– http://www.epiforge.com/grindstone/