La revisin tcnica formal (RTF), a veces llamada inspeccin, es el filtro ms

efectivo desde el punto de vista del aseguramiento de la calidad y es un medio

efectivo para mejorar la calidad del software. El defecto se define como una
anomala del producto. Dentro del contexto del proceso del software, los
trminos defecto y fallo son sinnimos. Ambos implican un problema de calidad
que es descubierto despus de entregar el software a los usuarios finales. El
objetivo principal de las RTF es encontrar errores durante el proceso, de forma
que se conviertan en defectos despus de la entrega del software. El beneficio
de estas RTF es el descubrimiento de errores al principio para que no se
propaguen al paso siguiente del proceso de software. Las actividades de diseo
introducen entre el 50 y 65% de todos los errores durante el proceso de
software. Sin embargo, se ha demostrado que las RTF son efectivas en un 75%
a la hora de detectar errores. Con la deteccin y la eliminacin de un gran
porcentaje de errores, el proceso de revisin reduce substancialmente el coste
de los pasos siguientes en las fases de desarrollo y mantenimiento. 11
Pressman, R.S: Ingniera del Software. Un enfoque prctico. Mc Graw Hill, 2002
18 Los objetivos de la RTF son: (1) Descubrir errores en la funcin, la lgica o la
implementacin de cualquier representacin del software, (2) Verificar que el
software bajo revisin alcanza sus requisitos, (3) Garantizar que el software ha
sido representado de acuerdo con ciertos estndares predefinidos, (4)
Conseguir un software desarrollado en forma uniforme y (5) Hacer que los
proyectos sean ms manejables. La RTF sirve para promover la seguridad y la
continuidad, ya que varias personas se familiarizarn con partes del software
que, de otro modo, no hubieran visto nunca. Es una clase de revisin que
incluye recorridos, inspecciones, revisione s cclicas y otro pequeo grupo de
evaluaciones tcnicas del software. Cada RTF se lleva a cabo mediante una
reunin y solo tendr xito si es bien planificada, controlada y atendida. El
aseguramiento de calidad se refiere a validar los procesos usados para crear
los productos. Es una herramienta especialmente til para administradores y
patrocinadores, ya que permite discutir los procesos usados para crear los
productos para determinar si son razonables. Este aseguramiento tiene
asociado 2 constitutivos diferentes: los Ingenieros de Software que realizan el
trabajo tcnico y un grupo de SQA (Software Quality Assurance) que tiene la
responsabilidad de la planificacin de aseguramiento de la calidad, supervisin,
mantenimiento de registros, anlisis e informes. Las Actividades del SQA son:
(1) Establecimiento de un plan de SQA para un proyecto, (2) Participacin en el
desarrollo de la descripcin del proceso de software del proyecto, (3) Revisin
de las actividades de Ingeniera del Software para verificar su ajuste al proceso
de software definido, (4) Auditoria de los productos de software designados
para verificar el ajuste con los definidos como parte del proceso del software,
(5) Asegurar que las desviaciones del trabajo y los productos del software se
documentan y se manejan de acuerdo con un procedimiento establecido, y (6)
Registrar lo que no se ajuste a los requisitos e informar a sus superiores.
Adems de estas actividades, el grupo de SQA coordina el control y la gestin
de cambios y; ayuda a recopilar y analizar las mtricas del software. Las
mtricas son escalas de unidades sobre las cuales puede medirse un atributo
cuantificable12. Cuando se habla de software nos referimos a la disciplina de

recopilar y analizar datos basndonos en mediciones reales de software, as

como a las escalas de 12 Pressman, R.S: Ingniera del Software. Un enfoque
prctico. Mc Graw Hill, 2002 19 medicin. Los atributos son caractersticas
observables del producto o del proceso de software, que proporciona alguna
informacin til sobre el estado del producto o sobre el progreso del
proyecto13. El trmino producto se utiliza para referirse a las especificaciones,
a los diseos y a los listados del cdigo. Los valores de las mtricas no se
obtienen slo por mediciones. Algunos valores de mtricas se derivan de los
requisitos del cliente o de los usuarios y, por lo tanto, actan como
restricciones dentro del proyecto. Los principios bsicos de la medicin son: (1)
los objetivos de la medicin deberan establecerse antes de empezar la
recopilacin de datos, (2) todas las tcnicas sobre mtricas deberan definirse
sin ambigedades, (3) las mtricas deberan obtenerse basndose en una
teora vlida para el dominio de aplicacin, (4) hay que hacer las mtricas a
medida para acomodar mejor los productos y procesos especficos, (5) siempre
que sea posible, la recopilacin de datos y el anlisis debera automatizarse, y
(6) se deberan aplicar tcnicas estadsticas vlidas para establecer las
relaciones entre los atributos internos del producto y las caractersticas
externas de la calidad. Las Razones que justifican la Medicin del Software son:
(1) Para indicar la calidad del producto, (2) Para evaluar la productividad de la
gente que desarrolla el producto, (3) Para evaluar los beneficios (en trminos
de productividad y calidad) derivados del uso de nuevos mtodos y
herramientas de Ingeniera de Software, (4) Para establecer una lnea base de
estimacin y (5) Para ayudar a justificar el uso de nuevas herramientas o
formacin adicional. Las actividades del proceso de medicin son: (1)
Formulacin: Obtencin de medidas y mtricas apropiadas para la presentacin
del software, (2) Coleccin: Mecanismo empleado para acumular datos
necesarios para obtener las mtricas formuladas, (3) Anlisis: Clculo de las
mtricas y aplicacin de herramientas matemticas, (4) Interpretacin: La
evaluacin de los resultados de las mtricas en un esfuerzo por conseguir una
visin interna de la calidad de la presentacin, (5) Retroalimentacin:
Recomendaciones obtenidas de la interpretacin de mtricas y tcnicas
transmitidas al equipo de desarrollo de software. Los sistemas mtricos
necesitan tres tipos de valores: (1) Objetivos: Se basan habitualmente en
consideraciones comerciales, (2) Predicciones: Indican la viabilidad de 13
Pressman, R.S: Ingniera del Software. Un enfoque prctico. Mc Graw Hill, 2002
20 los objetivos. Se basan en las caractersticas del producto con el que
tratamos. y (3) Valores reales: Pueden ser comparados con los objetivos para
supervisar la progresin del proyecto. Son mediciones discretas de los atributos
del software. Es preferible utilizar mediciones objetivas basadas en reglas.
Algunas mediciones se basan en estimaciones donde un valor ms que medirse
se evala. Las medidas de Calidad del Software deben comenzar desde la
especificacin y terminar con la implementacin, implantacin y
mantenimiento o post-implantacin. Debe aplicarse a lo largo de todo el
proceso de Ingeniera de Software. Bsicamente, la medicin es una fase
normal de cualquier actividad industrial Sin mediciones es imposible perseguir
objetivos comerciales normales de una manera racional. Existen mtricas a

nivel Proyecto, Proceso y Producto respectivamente. Las mtricas del Proyecto

se consolidan para crear mtricas de proceso que sean pblicas para toda la
organizacin del software. El uso de mtricas para el Proyecto tiene 2 aspectos
fundamentales: (1) minimizar la planificacin del desarrollo haciendo los
ajustes necesarios que eviten retrasos y reducir problemas/riesgos potenciales;
y (2) evaluar la calidad de los productos en el momento actual y cuando sea
necesario, modificando el enfoque tcnico que mejore la calidad. Los
indicadores de proyecto permiten al gestor de proyectos de software: (1)
evaluar el estado del proyecto, (2) seguir la pista de los riesgos potenciales, (3)
detectar las reas de problemas antes de que se conviertan en "crticas", (4)
ajustar el flujo y las tareas del trabajo; y (5) evaluar la habilidad del equipo del
proyecto en controlar la calidad de los productos de trabajo del software. Las
mtricas del Proceso se recopilan de todos los proyectos y durante un largo
perodo de tiempo. Su intento es proporcionar indicadores que lleven a mejorar
los procesos de software a largo plazo. Se tendrn mtricas asociadas a cada
proceso del software (p.e mtricas de implementacin). Estos indicadores de
proceso permiten que una organizacin de Ingeniera de Software pueda tener
una visin ms profunda de la eficacia de un proceso ya existente y permiten
que los gestores evalen lo que funciona y lo que no. En realidad, las medidas
que recopila un equipo de proyecto y las convierte en mtricas para utilizarse
durante un proyecto, tambin pueden trasmitirse a los que tienen la 21
responsabilidad de mejorar el proceso de software. Por esta razn, se utilizan
muchas de las mismas mtricas tanto en el dominio del proceso como en el del
proyecto. La nica forma racional de mejorar cualquier proceso es medir
atributos del proceso, desarrollar un juego de mtricas significativas segn
estos atributos y utilizar las mtricas para proporcionar indicadores que
conducirn a una estrategia de mejora. Las mtricas del proceso se
caracterizan por: (1) El control y ejecucin del proyecto, (2) Medicin de
tiempos del anlisis, diseo, implementacin, implantacin y postimplantacin,
(3) Medicin de las pruebas (errores, cubrimiento, resultado en nmero de
defectos y nmero de xito) y (4) Medicin de la transformacin o evolucin del
producto. Las mtricas de Producto son privadas para un individuo y a menudo
se combinan para desarrollar mtricas del proyecto que sean pblicas para un
equipo de software. Estn enfocadas a predecir y controlar: (1) El tamao
(lneas de cdigo, bytes de cdigo, operadores y operandos), (2) La estructura
(control de flujo, relacin entre componentes, cohesin y acoplamiento), (3) La
complejidad (combinacin de tamao y estructura), (4) Los ndices para
controlar la documentacin, (5) La calidad (independencia, completo,
entendible, aumentado) y (6) La estabilidad (los cambios aumentan el nmero
de fallas, los cambios se pueden dar por definicin de requerimientos o por
cambios del entorno). Las mtricas del software deberan tener las siguientes
caractersticas: (1) Simple y fcil de calcular, (2) Emprica e intuitivamente
persuasiva: Debe satisfacer las nociones intuitivas del desarrollador sobre el
atributo del producto en evaluacin, (3) Consistente y objetiva: Presentar
resultados sin ambigedad, (4) Consistente en el empleo de unidades y
tamaos: Deben emplearse medidas que no conduzcan a extraas
combinaciones de unidades, (5) Independiente del lenguaje de programacin y

(6) Mecanismo para retroalimentacin de calidad: Debe proporcionar

informacin para obtener un producto final de mayor calidad. Las mtricas a
recabar dependen de los objetivos del negocio en particular. Los
desarrolladores tienen a la vez objetivos comunes como, respetar el
presupuesto y respetar los plazos, minimizar las tasas de defectos antes y
despus de la entrega del producto e intentar mejorar la calidad y la
productividad. Las mtricas deben ayudar a la evaluacin de las
representaciones del modelo lgico y fsico, deben tener la capacidad de intuir
sobre la complejidad del diseo y construccin; y deben ayudar en el diseo de
casos de prueba.