Please enable JavaScript.
Coggle requires JavaScript to display documents.
TÉCNICAS DE EVALUACIÓN ESTÁTICA, Carlos Josías Zárate Velásquez 1490-12…
TÉCNICAS DE EVALUACIÓN ESTÁTICA
Pretenden detectar manualmente defectos en cualquier producto del
desarrollo
Por manualmente queremos decir que el producto en cuestión (sea requisito, diseño, código, etc.)
Está impreso en papel y los revisores están analizando ese producto mediante la lectura del mismo, sin ejecutarlo.
Existen varios tipos de revisiones, dependiendo de qué se busca y cómo se analiza ese producto. Podemos distinguir entre:
Walkthrough.
Auditorias
Las auditorias contrastan los artefactos generados durante el desarrollo con
estándares, generales o de la organización.
Típicamente pretenden comprobar formatos
de documentos, inclusión de toda la información necesaria. Es decir sino de gestión o administración del proyecto.
Es una revisión que consiste en simular la ejecución de casos de prueba
para el programa que se está evaluando.
La mejor traducción es: Recorrido. De hecho, con los walkthrough se recorre el programa imitando lo que haría la computadora.
Revisiones formales o Inspecciones
Revisiones informales
También llamadas inadecuadamente sólo Revisiones
Las Revisiones
Informales no dejan de ser un intercambio de opiniones entre los participantes.
los participantes son responsables de la fiabilidad de la evaluación, y generan un informe que refleja el acto de la revisión
Las inspecciones de software son un método de análisis estático para verificar y validar un producto
software manualmente.
Las Inspecciones son un proceso bien definido y disciplinado donde un equipo de personas cualificadas analiza un producto software usando una técnica de lectura con el propósito de detectar defectos antes de que la fase de prueba
comience.
PROCESO DE INSPECCIÓN
Las Inspecciones constan de dos partes: Primero, la comprensión del artefacto que se inspecciona; Y en segundo lugar, la búsqueda de faltas en dicho artefacto. Más concretamente, una inspección tiene cuatro fases principales:
Inicio
Detección de defectos
Cada miembro del equipo realiza individualmente la lectura del material, compresión del artefacto a revisar y la detección de faltas
Las Técnicas de Lectura ayudan en esta etapa al inspector tanto a comprender el artefacto como a detectar faltas.
Basándose en las faltas detectadas cada miembro debe realizar una estimación subjetiva del número de faltas remanentes en el artefacto
Colección de defectos
Corrección y seguimiento
El autor del artefacto inspeccionado debe corregir las faltas encontradas e informar de las correcciones realizadas a modo de seguimiento.
El registro de las faltas encontrada por cada miembro del equipo es compilado en un solo documento que servirá de basa a la discusión sobre faltas que se realizará en grupo.
Utilizando como base las faltas comunes encontradas por los distintos inspectores se puede realizar una estimación objetiva del número de faltas remanentes.
En la reunión se discutirá si las faltas detectadas son falsos positivos (faltas que algún inspector cree que son defectos pero que en realidad no lo son)
1 more item...
El objetivo es preparar la inspección y proporcionar la información que se
necesita sobre el artefacto para realizar la inspección
Planificación
Lanzamiento
se deben seleccionar los participantes, asignarles roles, preparar un calendario para la reunión y distribuir el material a inspeccionar
consiste en una primera reunión donde el autor explica el producto a
inspeccionar a los otros participantes
La evaluación estática de los distintos artefactos o productos que se generan en el desarrollo de software (especificación de requisitos, modelos conceptuales, diseño, código, etc.) pretende comprobar su calidad
Los defectos que se buscan al evaluar estáticamente los productos software son:
Para los requisitos
:
Corrección
Compleción
Consistencia
Ambigüedad
Claridad
Se entiende claramente lo que está especificado.
Los requisitos no pueden estar sujetos a interpretación
Las ambigüedades provocan interpretación por parte de la persona que use o lea los requisitos. Por tanto, una especificación debe carecer de ambigüedades.
No hay requisitos contradictorios.
Especificado todo lo que tiene que hacer el sistema y no incluye nada que el sistema no deba hacer
Los requisitos especifican correctamente lo que el sistema debe hacer
Es decir, un requisito incorrecto es un requisito que no cumple bien su función
Para el diseño:
Consistencia
Compleción
Corrección
El diseño no debe contener errores
Defectos de “escritura”, es decir, defectos en el
uso de la notación de diseño empleada
Defectos con respecto a los requisitos: el diseño no realiza lo que el requisito establece
El diseño debe estar completo. Ya sea que diseña todo el sistema marcado por los requisitos
Factibilidad
Trazabilidad
Se debe poder navegar desde un requisito hasta el fragmento de diseño donde éste se encuentra representado.
El diseño debe ser realizable.
Debe poderse implementar.
Debe ser consistente entre todas sus partes.
No puede indicarse algo en una parte del diseño, y lo contrario en otra.
Código Fuente
Corrección
Compleción
Consistencia
Trazabilidad
Se debe poder navegar desde un requisito hasta el fragmento de código donde éste se ejecute, pasando por el fragmento de diseño.
El código debe ser consistente entre todas sus partes. No puede hacerse algo en una parte del código, y lo contrario en otra.
El código debe estar completo
El código no debe contener errores
Defectos con respecto al diseño: el
diseño no realiza lo que el diseño establece
Defectos de “escritura”, es decir, lo que
habitualmente se conoce por “programa que no funciona”
Carlos Josías Zárate Velásquez
1490-12-6976