Error

Un error es cuando una persona hace algo que genera resultados incorrectos. Y
como en todas las etapas del desarrollo participan personas, en todas las etapas
pueden surgir errores.

Defectos
A las consecuencias de los errores les vamos a llamar “defectos”. Definimos
“defecto” como algo no funciona correctamente debido a que hubo un error en su
construcción.

Falla
Falla, es cuando el error es detectado durante el uso del software.

Ejemplo
 Ejemplo
Un desarrollador puede omitir poner una validación de la
fecha de nacimiento en un módulo de registro de empleados,
éste es el error.
El defecto es que, al tratar de guardar la información en la
base de datos, el gestor de base de datos no lo permitirá.
Este defecto se volverá una falla cuando el usuario vea el
mensaje de error, que no fue previsto por el desarrollador, al
tratar de guardar la información.

¿Porque será importante detectar los defectos los más pronto posible?
Porque de no hacerlo así, se convierten en una bola de hielo en una pendiente.

¿Qué significa esto?

Los defectos que pasan a la siguiente etapa en primer lugar serán más caros de
corregir. En segundo lugar, esos defectos que pasaron inadvertidos podrían
generar muchos defectos más, lo cual generaría aún más costos.
Los defectos se pueden dar en cualquier etapa del desarrollo de software. Por lo
en cada etapa se deben aplicar técnicas para detectarlos y eliminarlos antes de
que se pasen a la siguiente etapa y se conviertan en fallas.

Las revisiones forman parte de las pruebas estáticas, pues se realizan sin ejecutar
el código. Es decir, se revisan documentos o inclusive el código, pero sin
ejecutarlo.

Entre las cosas que se comprueban están: cumplimiento de los requisitos

establecidos; ajuste a los estándares; y, en algunos casos, mejoras en los
productos ya desarrollados.

Hay diferentes grados de formalidad: desde una inspección en la que solamente

participan dos personas -el autor del producto y la persona que realiza la revisión-,
hasta una revisión técnica formal.
Planeación
Planear con anticipación, y que exista una agenda de las actividades a realizar.
Usualmente duran al menos dos horas.

Participantes
En esta reunión participaran de tres a cinco personas, cada una con un rol
asignado.
Se les pide que se preparen con un estudio previo de lo que se va a inspeccionar
en la reunión; no se le debe dedicar más de dos horas a esta actividad, y se debe
generar un listado de lo que se va a revisar en cada producto.

Responsable o director
Uno de los participantes de la reunión debe ser el autor del(os) producto(s) que se
evaluarán. También debe haber un responsable o “director” de la reunión.

Técnicas
Algunas técnicas que se pueden utilizar en las reuniones formales son:
∙Recorridos
∙Inspecciones
∙Revisiones cíclicas
∙Evaluaciones técnicas de software
Entre más formal sea la revisión, más seguimiento se le dará a la solución de los
defectos.

Decisión
Al terminar la reunión, se debe determinar si los productos revisados son
aceptados, son rechazados por la cantidad de defectos o son aceptados
provisionalmente pues se encontraron defectos que deben ser corregidos.

Enfoque
Es importante centrarse en una parte del software para que se logren resultados
efectivos.

Reporte
 Durante la revisión se genera un reporte, que debe contener:

Descripción, y si es posible, identificador del producto revisado.

•Participantes de la reunión.
•Lista de los puntos revisados y quién los reviso.
•Listado de defectos encontrados y su clasificación: no graves (se resuelven
con una sola acción) o graves (se resuelven con varias acciones).
•Acciones a realizar, y si es posible, asignar fechas a estas acciones.
•Si es necesario, fecha de la próxima revisión.

Cuestionario