Este documento presenta varias técnicas de lectura para la inspección de software, incluyendo Checklist Based Reading, Stepwise Abstraction, Use Case Reading, Abstraction-Driven Reading, Traceability-Based Reading, Usage Based Reading y Perspective Based Reading. Explica los objetivos, procedimientos y artefactos a los que se aplican cada una de estas técnicas para mejorar la detección de defectos durante el proceso de revisión de software.

1. CURSO DE POSGRADO
Inspección de Software
Técnicas de lectura
Darío Macchi
DOCENTE

2. Técnicas de lectura
abril de 2013
P. 2Inspección de software

3. Visión General
Variabilidad de resultados de procesos de revisión son independientes
del proceso utilizado [Land et al., 1997], [Porter and Johnson, 1997], [Votta, 1993].
• ¿De qué depende?
abril de 2013
P. 3Inspección de software
Para que las necesitamos:
• Durante nuestra formación aprendemos a escribir artefactos pero no a
leerlos ni analizarlos [Basili et al., 1996].
• Capturan el conocimiento obtenido de buenas prácticas en detección
de defectos [Melo & Shull, 2001].
• Independizar resultados de habilidades del revisor.
Definición:
Serie de pasos cuyo propósito es lograr un entendimiento profundo
del artefacto revisado [Laitenberger & DeBaud, 2000].

4. Visión General
Beneficios:
• Aumentan la eficacia y eficiencia de los revisores en la detección de
defectos [Melo & Shull, 2001]
• Minimizan la influencia del revisor
(estándar de análisis de artefactos)
• Organizan la lectura y sirven de guía para el revisor
• Minimizan interrupciones (revisiones espontáneas)
• Muchas de ellas pueden adaptarse a cada equipo de
trabajo.
abril de 2013
P. 4Inspección de software

5. Técnicas
• Ad-hoc
• Checklist based reading (CBR)
• Stepwise abstraction
• OO code
• Use Case Reading (UCR) (McMeekin, 2005)
• Abstraction-Driven Reading (ADR)
• Traceability-Based Reading (TBR)
• Usage based reading (UBR)
• Perspective based reading (PBR)
abril de 2013
P. 5Inspección de software

6. Ad-hoc Reading (AHR)
• Depende de la habilidad, conocimiento y experiencia
para detectar defectos.
• Simple pero considerada como muy efectiva [McMeekin, 2005].
• Libertad (expertos) vs. falta de proceso (inexpertos).
Aplicable a:
• cualquier artefacto
abril de 2013
P. 6Inspección de software

7. Checklist Based Reading (CBR)
• Estándar usado en la industria [Laitenberger and DeBaud, 2000]
• La primera técnica recomendada por Fagan [Fagan, 1976].
• Describe “qué” buscar y no “cómo” encontrarlo [Laitenberger, 2000].
Heurísticas para creación/mantenimiento de checklists:
[A survey of software inspection checklists, Brykczynski, 1999]
• Deben ser actualizadas regularmente (incentiva lectura y uso).
• Deben ser de una página de largo.
• Deben escribirse de tal forma que la respuesta “no” indique un defecto.
• Los items no deben ser vagos/ambiguos.
• No se deben usar cuando otros métodos sean más eficientes.
Aplicable a:
• cualquier artefacto
abril de 2013
P. 7Inspección de software

8. Checklist Based Reading (CBR)
abril de 2013
P. 8Inspección de software

9. Checklist Based Reading (CBR)
abril de 2013
P. 9Inspección de software

10. Stepwise abstraction
• Introducido por la comunidad Cleanroom.
• Propuesta para casos en que CBR era inadecuado.
• Procedimiento:
– Consiste en leer una secuencia de sentencias y abstraer su
funcionalidad.
– Luego se continúa “hacia afuera” abstrayendo la funcionalidad del
siguiente bloque.
– Finaliza cuando se “deduce” la funcionalidad del conjunto
(requerimiento)
Aplicable a:
• Código
abril de 2013
P. 10Inspección de software

11. Stepwise Abstraction
Ejercicio
(20 mins.)
abril de 2013
P. 11Inspección de software

12. abril de 2013
P. 12Inspección de software

13. Use Case Reading (UCR)
• Busca asegurar que cada objeto es capaz de responder
de forma correcta a todos los posibles escenarios.
• Procedimiento:
– Elaborar escenarios a partir de los casos de uso basados en
precondiciones, criterios de entrada y salida, etc..
• Escenarios se “corren” en diagramas de secuencia.
– Cuando se llama a la clase inspeccionada en el diagrama, se cambia de
artefacto y se baja al código de dicha clase.
– Se verifica que el comportamiento de la clase y el estado posterior al
llamado sea el esperado.
Se aplica a:
• Código (OOP), aunque involucra artefactos de diseño.
abril de 2013
P. 13Inspección de software

14. Abstraction-Driven Reading (ADR)
• Busca obtener especificaciones abstractas de código en
lenguaje natural.
• Procedimiento:
– Se analiza el acoplamiento entre las clases de un sistema.
– Las de menor acoplamiento se analizan primero.
• Se analiza el acoplamiento entre los métodos.
• Los de menor acoplamiento se analizan primero.
• Se realiza una abstracción en lenguaje natural y luego se comienza a subir
el nivel de abstracción.
– Al escribir abstracciones se van escribiendo defectos detectados.
Se aplica a:
• Código (OOP)
abril de 2013
P. 14Inspección de software

15. Abstraction-Driven Reading (ADR)
abril de 2013
P. 15Inspección de software
Ejemplo [Dunsmore, 2001]

16. Traceability-Based Reading (TBR)
• Busca que los documentos de diseño sean claros y
libres de ambigüedad [Travassos, 1999].
• Documentos deben ser leídos:
• “horizontalmente” para asegurar la consistencia de los mismos.
• Diagrama de clases vs. descripción de clases
• Diagramas de secuencia vs. diagramas de estado
• “verticalmente” para asegurar que correctitud y completitud respecto
a requerimientos funcionales.
• Descripción de clases vs. requerimientos
• Diagramas de secuencia vs. casos de uso
Aplicable a:
• Artefactos de diseño de alto nivel (OOP)
abril de 2013
P. 16Inspección de software

17. Usage Based Reading (UBR)
• Se enfoca en la calidad del producto desde la perspectiva del
usuario.
• Defectos con más impacto negativo según percepción de
calidad del usuario.
• Se priorizan los casos de uso por percepción.
• Procedimiento:
– Una vez priorizados los casos de uso se elaboran escenarios (como en
UCR).
– Se desarrolla el escenario desde los requerimientos hasta el artefacto en
revisión.
– Defectos detectados no son tratados como iguales.
Aplicable a:
• Cualquier artefacto
abril de 2013
P. 17Inspección de software

18. Usage Based Reading (UBR)
Ejemplo sobre documento de diseño:
1. Se elige el caso de uso de mayor prioridad.
2. Se “corre” el caso de uso en el documento de diseño identificando
posibles defectos.
3. Se continúa con el procedimiento hasta agotar el tiempo o los
casos de uso relacionados con el documento de diseño.
abril de 2013
P. 18Inspección de software

19. Perspective Based Reading (PBR)
• Busca que la lectura se realiza desde la perspectiva de
distintos stakeholders [Basili et al., 1996], [Laitenberger and DeBaud, 1997].
• No existe una definición monolítica de calidad.
• Procedimiento:
– Se determinan las perspectivas de lectura (roles).
– Se elaboran escenarios para cada perspectiva (reutilizables).
– Se realiza la lectura siguiendo el escenario.
Aplicable a:
• Cualquier artefacto
abril de 2013
P. 19Inspección de software

20. Perspective Based Reading (PBR)
Ejercicio
(30 mins.)
abril de 2013
P. 20Inspección de software

21. Referencias
[Basili et al, 1996] Basili, V., Green, S., Laitenberger, O., Lanubile, F., Shull, F., Sorumgard, S., and Zelkowitz, M. (1996). The
Empirical Investigation of Perspective-based Reading. Journal of Empirical Software Engi- neering, 2(1):133–164.
[Basili et al., 1996] Basili, VR, Scott Green, & Oliver Laitenberger. 1996. “The empirical investigation of perspective-based
reading”. Empirical Software …
[Brykczynski, 1999] Brykczynski, Bill. 1999. “A survey of software inspection checklists”. ACM SIGSOFT Software Engineering
Notes 24(1)
(Dunsmore, 2001) Dunsmore, A. 2001. “An Empirical Investigation of Three Reading Techniques for Object-Oriented Code
Inspection”. : 1–44.
[Laitenberger & DeBaud, 1997] Laitenberger, O. and DeBaud, J.-M. (1997). Perspective-based Reading of Code Documents at
Robert Bosch GmbH. Information and Software Technology, 39:781–791.
[Laitenberger & DeBaud, 2000] Laitenberger, Oliver, & Jean Marc DeBaud. 2000. “An Encompassing Life-Cycle Centric Survey of
Software Inspection”. Journal of Systems and Software 50(1): 5–31.
[Laitenberger, 2000] Laitenberger, Oliver. 2000. “Cost-effective Detection of Software Defects through Perspective-based
Inspections”.
[McMeekin, 2005] McMeekin, David Andrew. 2005. “A Comparison of Code Inspection Techniques.”.
[Melo & Shull, 2001] Melo, Walcélio, & Forrest Shull. 2001. Software Review Guidelines.
[Oladele, 2010] Oladele, Rufus O. 2010. “Reading Techniques for Software Inspection: Review and Analysis”. Journal of Institute
of Mathematics & Computer Sciences (Computer Science Series) 21(2): 199–209.
[Travassos et al., 1999] Travassos, Guilherme Horta et al. 1999. “Detecting Defects in Object Oriented Designs?: Using Reading
Techniques to Increase Software Quality.” In Conference on Object-Oriented Programming, Systems, Languages, and
Applications (OOPSLA),
[Wong, 2006) Wong, Yuk Kuen. 2006. Modern Software Review?: Techniques and Technologies.
abril de 2013
P. 21Inspección de software