técnicas de lectura para revisiones de software
DESCRIPTION
Definición de técnica de lectura, generalidades. Técnicas: Ad-hoc, Checklist based reading (CBR), Stepwise abstraction, Use Case Reading (UCR), Abstraction-Driven Reading (ADR), Traceability-Based Reading (TBR), Usage based reading (UBR), Perspective based reading (PBR)TRANSCRIPT
CURSO DE POSGRADO
Inspección de SoftwareTécnicas de lectura
Darío MacchiDOCENTE
Inspección de software
Técnicas de lectura
abril de 2013
P. 2
Inspección de software
Visión GeneralVariabilidad 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. 3
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].
Inspección de software
Visión GeneralBeneficios:• 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. 4
Inspección de software
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. 5
Inspección de software
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. 6
Inspección de software
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. 7
Inspección de software
Checklist Based Reading (CBR)abril de 2013
P. 8
Inspección de software
Checklist Based Reading (CBR)abril de 2013
P. 9
Inspección de software
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. 10
Inspección de software
Stepwise Abstraction
Ejercicio(20 mins.)
abril de 2013
P. 11
Inspección de software
abril de 2013
P. 12
Inspección de software
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. 13
Inspección de software
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. 14
Inspección de software
Abstraction-Driven Reading (ADR)
abril de 2013
P. 15
Ejemplo [Dunsmore, 2001]
c
Inspección de software
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. 16
Inspección de software
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. 17
Inspección de software
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. 18
Inspección de software
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. 19
Inspección de software
Perspective Based Reading (PBR)
Ejercicio(30 mins.)
abril de 2013
P. 20
Inspección de software
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. 21