isw07_revisiones de sw

7/22/2019 ISW07_Revisiones de Sw

1/30

CALIDAD DE SOFTWARE

Inspecciones de SW

Erick Vicente


2/30

.REVISIONES

Informales Tcnicas

-ComprobacinEscritorio

-Revisin por

pares

-Inspecciones

-Recorridos

Tipos de verificacin


3/30

Ventajas No requiere ejecutable, por lo que puede ser

realizada desde el inicio del proceso de desarrollo

de software Se encuentran varios defectos a la vez. Hasta un

85% de los defectos del software.

Podemos localizar la posicin exacta del defecto

Refuerza el uso de estndares. Mejora la capacitacin de los ingenieros de

software.

Revisiones de software


4/30

Desventajas

Requiere del tiempo de los expertos.

No se pueden verificar caractersticas nofuncionales (Ej. Rendimiento).

Validan el cumplimiento de lo que se especific envez de lo que realmente desea el cliente.

Difcil de implementar (es vista como improductivapor los desarrolladores ).

Revisiones de software


5/30

Los requerimientos son las fuentes ms comunesde problemas dentro del proceso de desarrollode software.

Los requerimientos estn escritos en lenguajenatural, por personas que tienen poca o ningunacapacitacin en captura de requerimientos.

El lenguaje es impreciso, ambiguo y nodeterminstico. Por el contrario un software espreciso, no ambiguo y determinstico.

Importancia de las

revisiones


6/30

.Anlisis de

requerimientos

Anlisis

Diseo

Implementacin

Pruebas

Mantenimiento

1$

5$

20$

50$

100$

Costo de encontrar y corregir

defectos


7/30

Sin revisiones

6

2

4x1

9

7

8x3.5

20

40

15x5

30

Defectos

Defectos

en cadena

Nuevosdefectos

SRS

SDD

Code

6

15

55

50%

50%

50%

Pruebas

unitarias

Pruebas

del sistema

Pruebas

de aceptacin

145

72

36

18

Fuente IBM

Propagacin de errores


8/30

Con revisiones

6

1

2x1

9

4

2x3.5

20

12

3x5

30

Defectos

Defectos

en cadena

Nuevosdefectos

SRS

SDD

Code

3

6

15

50%

50%

50%

Pruebas

unitarias

Pruebas

del sistema

Pruebas

de aceptacin

28

14

7

3.5

Fuente IBM

50%

50%

50%

50%

Propagacin de errores


9/30

.Inspecciones

Walkthrough

Pair Review

Desk Checking

Ad-Hoc

Formales

Informales

Tipos de revisin


10/30

Son realizadas por el propio autor(es) o personas de lamisma categora del artefacto generado durante elproceso de desarrollo. Los artefactos a revisar son:

Especificaciones : SRS, UCS, SDS, etc.

Modelos de anlisis y diseo

Cdigo fuente

Son llevadas a cabo de manera informal, por tantodepende de la experiencia del autor o sus pares.

Revisiones informales


11/30

Revisin del artefacto o documentorecientemente elaborado.

Puede ser aplicado a todos los artefactosrealizados durante el proceso de desarrollo

Por ejemplo, despus de escribir unprogramas se verifica que cumpla con losestndares establecidos de programacin.

Desk Checking


12/30

Consiste en la revisin de un artefacto porpersonas que pertenecen a la misma rea y nivel

que el autor. Se puede poner en prctica cuando un panel

dentro del rea se encarga de revisarperidicamente muestras de cdigo.

Por ejemplo, se puede someter a revisin delcdigo de un programador por otrosprogramadores (sus pares).

Revisin por pares (Pair

review)


13/30

Los artefactos producidos durante el procesode desarrollo son revisados por un grupo

especializado de personas. La responsabilidad de la calidad del artefacto

producido no recae solamente sobre eldesarrollador, analista o diseador o sus

pares.

Revisiones tcnicas


14/30

Una inspeccin es una revisin formal, rigurosa y tcnicamentedetallada para identificar problemas, los mas cerca posible al punto deorigen.

Son realizadas hasta la implementacin del programa. Se analizan:

Especificaciones

Modelos Cdigo en lenguaje de alto nivel

Son tcnicas altamente efectivas:

En una sesin de inspeccin se pueden detectar varios defectos,mientras que las pruebas dinmicas pueden detectar un error porprueba

Se aprovecha el conocimiento sobre los errores comunes en unlenguaje de programacin y aplicacin.

Inspecciones


15/30

No deben reemplazar a las pruebas dinmicas

(validacin), sino como un proceso de verificacin

inicial para encontrar muchos defectos en el programa

o especificaciones. Verifica que los programas se encuentren codificados

de acuerdo a las especificaciones, pero no validan elcomportamiento dinmico del mismo.

Son un mtodo eficaz para detectar desviacionesrespecto a las especificaciones en las etapas inicialesdel proceso de desarrollo de software.

Inspecciones


16/30

Objetivos

Encontrar problemas los mas temprano posible dentro del

proceso de desarrollo.

Asegurar que las modificaciones solicitadas sean realizadas. Mejorar el conocimiento tcnico de los miembros del

equipo.

Incrementar la efectividad de la validacin de software.

Incrementar la calidad de los productos realizados por losingenieros de software.

Inspecciones


17/30

EquipoParticipante Descripcin

Autor El productor del artefacto sometido a revisin

Moderador Un inspector responsable de organizar (planificar, preparar

los checklist y distribuir los documentos) y ejecutar unainspeccin de software

Lector Presentar y guiar la revisin del artefacto durante la reunin

Registrador Registrar y documentar problemas, defectos y

recomendaciones encontrados durante la reunin en el

inspection issue log.

Inspector Un miembro de un equipo de inspeccin adems del autor.

Se elige de acuerdo a los skills necesarios para revisar el

artefacto.

Inspecciones - Roles


18/30

Caractersticas

Todos son inspectores El autor no puede ser ni moderador, ni registrador, ni inspector. Los otros roles pueden ser compartidos.

No son para evaluar el progreso de un producto, ni evaluar alautor del producto Esta orientado a encontrar defectos y no en corregirlos Existe un registro de la deteccin y correccin de defectos. El gerente no deben asistir a las reuniones de revisin. El autor debe estar para esclarecer, no para justificar el producto. No se debe preguntar el porqu, sino el para qu?

Inspecciones


19/30

Son revisiones en las que se intentademostrar la funcionalidad del objetorevisado, mediante la simulacin de sufuncionamiento con casos de prueba yejemplos.

Se introducen al objeto los casos de prueba y

se van registrando los resultados intermedios.

Recorridos Walkthrough


20/30

Atributos Inspeccin Walkthrough

Objetivo Encontrar problemas

Seguimiento a las

correcciones

Centrado en que el productocumpla con los

requerimientos

Encontrar problemas

Discutir alternativas de solucin

Centrado en demostrar que el

producto cumple con losrequerimientos.

Toma de decisiones El equipo de inspeccin

toma decisiones basado en

consenso

El autor toma todas las

decisiones

Lder El moderador El autor

Reunin Inspectores con

documentacinPares y gerentes. No

documentados

Inspecciones y recorridos


21/30

. .

Atributos Inspeccin Walkthrough

Presentacin dematerial

El material es presentadopor el lector

El material es presentado por elproductor

Procedimientos Formalmente documentados Informal

Capacitacin Requerida para todos los

participantes

No requiere

Inspecciones y recorridos


22/30

Quin decide que debe ser inspeccionado? El autor y el gerente del autor. No todos los

productos deben ser inspeccionados. Ej. criterios

para revisar el cdigo: Mdulos que son crticos para el correcto

funcionamiento del producto. Mdulos que son relativamente ms complejos que

otros (mayor complejidad ciclomtica).

En el pasado se han tenido gran cantidad errores enmdulos de similares caractersticas. Cuando un nuevo miembro del equipo o con poca

experiencia ha escrito el cdigo.

Preguntas frecuentes


23/30

Cules son los materiales necesarios para realizar la inspeccin?

Tipo Producto Inspeccionar si Materiales requeridos

Requerimientos SRSUCS

El equipo se encuentracapacitado

Los documentos previos se

encuentra aprobados

Documento de SRS UCSChecklist de req. o casos de

uso.

Diseo SDD El SRS ha sido inspeccionado y

las correcciones resueltas

SRS y SDD checklist

Cdigo Cdigofuente

El SDD ha sido inspeccionado ylas correcciones resueltas.

Elegir segn criterio.

Cdigo compilado

Cdigo listado yenumerado. Documento de

SDD y estndares de

programacin.

Checklist de cdigo



24/30

Quin decide si es un problema?

Para poner una observacin como error o defecto, la decisin setoma por consenso.

Qu es un error? Un error es un problema en el cual el software o su

documentacin no concuerda con los requerimientos y esencontrado en su punto de origen.

Qu es un defecto? Es tambin un problema, pero es encontrado como una

consecuencia, no en su punto de origen. Por ejemplo: unproblema en los requerimientos encontrado durante la inspeccinde cdigo.



25/30

Quin es el responsable de distribuir elmaterial? El autor es responsable de enviar todos los materiales

requeridos al moderador. El moderador es responsablede distribuir el material al equipo de inspeccin.

Qu pasa si el autor no esta de acuerdo con la

decisin? El equipo de inspeccin es quien decide cuales de los

problemas son registrados como errores o defectos. Elautor no participa en esta decisin.



26/30

Inicializacin

Preparacin

Ejecucin

Reporte de

Resultados

Modificacin

y

seguimiento

Inicio

Fin

Politicas y

planes

Checklist

Defectos

Proceso de inspeccin


27/30

La inspeccin de los requerimientos debe ser una de lasactividades que nunca debe ser dejada de lado, enmuchos casos los requerimientos no son interpretadosde manera correcta porque estn escritos de manera

deficiente, incompleta, inconsistente y ambigua.

Muchas personas con diferente formacin yconocimientos se encuentran involucrados en elproceso de captura de requerimientos, y no son

consientes del impacto que tienen un requerimientosescrito de manera deficiente en el proceso de desarrollode software.

Inspeccin de requerimientos


28/30

Una especificacin de requerimientos debe tener lossiguientes atributos: No ambiguo: Cada requerimientos debe tener una sola

interpretacin

Completo: Un SRS es completo si tiene requerimientosrelacionados a la funcionalidad, performance, tiempos derespuesta, restricciones de diseo, interfaces externas, etc.Adems, debe contener la definicin de las respuestas atodas entradas conocidas en todas las situacionesconocidas.

Verificable: Cada requerimiento debe ser verificable por unproceso finito y efectivo.



29/30

Consistente: No hay conflicto entrerequerimientos.

Modificable: Puede ser cambiado de manera

completa y consistente.

Rastreable: Cada requerimiento debe serclaramente rastreable a los documentospredecesores y tambin a los documentossubsecuentes.

Usable: Debe proveer suficiente informacin paralos futuros mantenimientos.



30/30

P R E G U N T A S ?

isw07_revisiones de sw

Documents