Introducing
Your new presentation assistant.
Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.
Trending searches
Torices Cabrera Ricardo Alfonso
25/10/18
Las revisiones técnicas son una de las muchas acciones que se requieren como parte de las
buenas prácticas de la ingeniería de software. Cada acción requiere un esfuerzo humano dirigido.
Como el esfuerzo disponible para el proyecto es finito, es importante que una organización
de software comprenda la eficacia de cada acción, definiendo un conjunto de métricas que puedan utilizarse para evaluar esa eficacia.
Esfuerzo de preparación, Ep: esfuerzo (en horas-hombre) requerido para revisar un
producto del trabajo antes de la reunión de revisión real.
Esfuerzo de evaluación, Ea: esfuerzo requerido (en horas-hombre) que se dedica a la
revisión real.
Esfuerzo de la repetición, Er: esfuerzo (en horas-hombre) que se dedica a la corrección de
los errores descubiertos durante la revisión.
Tamaño del producto del trabajo, TPT: medición del tamaño del producto del trabajo que
se ha revisado (por ejemplo, número de modelos UML o número de páginas de
documento o de líneas de código).
Errores menores detectados, Errmenores: número de errores detectados que pueden clasificarse
como menores (requieren menos de algún esfuerzo especificado para corregirse).
Errores mayores detectados, Errmayores: número de errores encontrados que pueden clasificarse
como mayores (requieren más que algún esfuerzo especificado para corregirse).
Si las revisiones se llevan a cabo para varios tipos distintos de productos del trabajo (por
ejemplo, modelo de requerimientos, modelo del diseño, código, casos de prueba, etc.), el porcentaje
de errores no descubiertos por cada revisión se confronta con el número total de errores
detectados en todas las revisiones. Además, puede calcularse la densidad del error para cada
producto del trabajo.
Es difícil medir en tiempo real la eficacia del costo de cualquier revisión técnica. Una organización
de ingeniería de software puede evaluar la eficacia de las revisiones y su relación costo-
beneficio sólo después de que éstas han terminado, de que las unidades de medida de la revisión
se han recabado, de que los datos promedio han sido calculados y de que la calidad posterior
del software ha sido medida (mediante pruebas)
En su libro sobre la revisión por pares, Karl Wiegers [Wie02] analiza datos procedentes de
anécdotas de compañías grandes que han utilizado inspecciones (un tipo relativamente formal
de revisión técnica) como parte de sus actividades de control de calidad del software.
Pero para muchos profesionales del software, esta afirmación va contra la intuición. “Las
revisiones toman tiempo”, dicen, “y no tenemos tiempo que perder…”. Afirman que el tiempo es
precioso en cada proyecto de software y que la actividad de revisar “todo producto del trabajo
con detalle” absorbe demasiado.
Las revisiones técnicas deben aplicarse con un nivel de formalidad apropiado para el producto
que se va a elaborar, para el plazo que tiene el proyecto y para el personal que realice el trabajo.
La figura 15.5 ilustra un modelo de referencia para las revisiones técnicas [Lai02] que identifica
cuatro características que contribuyen a la formalidad con la que se efectúa una revisión.
Cada una de las características del modelo de referencia ayuda a definir el nivel de formalidad
de la revisión. La formalidad de una revisión se incrementa cuando: 1) se definen explícitamente
roles distintos para los revisores, 2) hay suficiente cantidad de planeación y preparación para la
revisión, 3) se define una estructura distinta para la revisión (incluso tareas y productos internos
del trabajo) y 4) el seguimiento por parte de los revisores tiene lugar para cualesquiera correcciones
que se efectúen.