Catedrtico:

Ing. Eva Mora Colorado

Alumno:
Ernesto Granillo Pablo

Materia:
Proceso Personal Para Desarrollo De Software

Semestre:
8

Inspecciones, guas y revisiones
Las inspecciones de software son un mtodo de anlisis esttico para verificar y validar un
producto software manualmente. Los trminos Inspecciones y Revisiones se emplean a
menudo como sinnimos. Sin embargo, como ya se ha visto, este uso intercambiable no
es correcto.
Las Inspecciones son un proceso bien definido y disciplinado donde un equipo de personas
cualificadas analiza un producto software usando una tcnica de lectura con el propsito
de detectar defectos. El objetivo principal de una inspeccin es detectar faltas antes de
que la fase de prueba comience. Cualquier desviacin de una propiedad de calidad
predefinida es considerada un defecto.
Las Inspecciones constan de dos partes: Primero, la comprensin del artefacto que se
inspecciona; Y en segundo lugar, la bsqueda de faltas en dicho artefacto. Ms
concretamente, una inspeccin tiene cuatro fases principales:
Inicio
El objetivo es preparar la inspeccin y proporcionar la informacin que se necesita sobre
el artefacto para realizar la inspeccin.
Deteccin de defectos
Cada miembro del equipo realiza individualmente la lectura del materia, compresin del
artefacto a revisar y la deteccin de faltas. Las Tcnicas de Lectura ayudan en esta etapa al
inspector tanto a comprender el artefacto como a detectar faltas. Basndose en las faltas
detectadas cada miembro debe realizar una estimacin subjetiva del nmero de faltas
remanentes en el artefacto.
Coleccin de defectos
El registro de las faltas encontrada por cada miembro del equipo es compilado en un solo
documento que servir de basa a la discusin sobre faltas que se realizar en grupo.
Utilizando como base las faltas comunes encontradas por los distintos inspectores se
puede realizar una estimacin objetiva del nmero de faltas remanentes. En la reunin se
discutir si las faltas detectadas son falsos positivos (faltas que algn inspector cree que
son defectos pero que en realidad no lo son) y se intentar encontrar ms faltas ayudados
por la sinergia del grupo.
Correccin y seguimiento
El autor del artefacto inspeccionado debe corregir las faltas encontradas e informar de las
correcciones realizadas a modo de seguimiento.

Revisiones
Las Revisiones son actividades de control de calidad, que permiten detectar defectos en
los proyectos de software. Las Revisiones pueden ser de dos tipos, tal y como se muestra
en la Figura 1, dinmicas y estticas. Las primeras son las que detectan los defectos
ejecutando el software, fundamentalmente son las ejecutadas en la fase de prueba del
proyecto. Las segundas son visuales y se realizan sin necesidad de que el software est
ejecutndose. Ambas son de suma importancia y una combinacin adecuada puede
detectar gran cantidad de defectos y por tanto mejorar la calidad del producto final.

Estrategia de revisin de PSP
Es producir la ms alta calidad de programa posible en cada fase del proceso.
La estrategia de revisin para lograrlo es:
Recolectar datos de sus revisiones
Estudiar estos datos
Decidir que le est funcionando mejor
Ajustar su proceso de acuerdo con esto
Las revisiones en PSP siguen un proceso disciplinado con
Criterios de entrada y salida
Una estructura de la revisin
Guas, listas de comprobacin y estndares
El objetivo de la revisin sugerido por el PSP es encontrar todo defecto antes de la
primera compilacin o prueba.
Para lograr ese objetivo, usted debe
Usar estndares de codificacin
Usar criterios que aseguren que el diseo es completo
Medir y mejorar su proceso de revisin
Principios de la revisin de diseo:
1. Producir diseos que puedan ser revisados.
2. Seguir una estrategia explicita de revisin.
3. Revisar el diseo en etapas.
4. Verificar que la lgica implanta correctamente los requerimientos.
Producir Diseos que puedan ser revisados
Un diseo revisable tiene:
Un contexto definido
Una representacin precisa
Una estructura clara y consistente
Esto sugiere que
El propsito y funcin del diseo estn explcitamente establecidas
Usted tiene un criterio para asegurar que el diseo est completo
El diseo est estructurado en elementos lgicos

Siguiendo una Estrategia de Revisin
La estrategia de revisin especifica el orden en el que usted revisa los elementos de
diseo.
Esto depende de la estructura del producto.
De esta forma, la estrategia de revisin debe ser considerada durante el diseo.
El objetivo debe ser producir un diseo que pueda ser
Revisado en etapas
Probado en etapas
Integrado en etapas
Revisar el Diseo en Etapas
Al revisar en etapas, usted asegura que todos los temas seleccionados se revisan
cuidadosamente.
Las etapas sugeridas de la revisin son las siguientes:
Revise que todos los elementos han sido diseados.
1. Verifique el flujo y la estructura del programa completo.
2. Revise que sean correctas las estructuras lgicas.
3. Revise para asegurar la robustez.
4. Revise las llamadas a funciones, mtodos y procedimiento para asegurar su uso
apropiado.
5. Revise variables especiales, parmetros, tipos y archivos para asegurar su uso
apropiado.
Verifique que la Lgica Implementa Correctamente los Requerimientos
Revise los requerimientos para asegurar que cada funcin requerida es tomada en cuenta
por el diseo.
Revise cuidadosamente por equivocaciones u omisiones.
Control de proceso
De poco sirve la implantacin de un sistema de calidad y sus procesos de control si no se
tienen herramientas que agilicen y aseguren su seguimiento y puesta en marcha.
Si el lector entiende que el sistema de control de su empresa es lento, pesado, complicado
o poco efectivo, aqu puede encontrar la forma de remediarlo.
Control de procesos significa el conjunto de conocimientos, mtodos,
herramientas, tecnologas, aparatos y experiencia que se necesitan para medir y regular
automticamente las variables que afectan a cada proceso de produccin, hasta lograr su
optimizacin en cuanto a mejoras del control, productividad, calidad, seguridad, u otros
criterios.
Listas de verificacin
Instrumento que contiene criterios o indicadores a partir de los cuales se miden y evalan
las caractersticas del objeto, comprobando si cumple con los atributos establecidos. La
lista de verificacin se utiliza bsicamente en la prctica de la investigacin que forma
parte del proceso de evaluacin.
Una lista de verificacin es una de las formas ms objetivas de valorar el estado de aquello
que se somete a control. El carcter cerrado de las respuestas y su limitado nmero
proporciona esta objetividad, pero tambin elimina informacin muy til, porque no
puede recoger todos los matices, detalles, y singularidades. Si queremos hacer una buena
lista de verificacin, hay que pensar en los matices, detalles y singularidades que
queremos capturar.
Revisiones de diseo y cdigo
Entre los mtodos para verificar nuestro software tenemos:
Inspecciones: Fueron introducidas por Fagan en IBM en 1976, siguen un proceso
estructurado y son tiles para requerimientos, diseos, casos de prueba, planes y todo lo
que se les parezca. Cuentan con las siguientes caractersticas:
Son realizadas por los compaeros.
Los administradores no asisten.
Cada participante tiene un papel definido.
El objetivo es encontrar problemas.
Recorridas: Siguen el formato de las juntas o reuniones. Son tiles para aspectos de
requerimientos o diseo del sistema.
La audiencia puede incluir compaeros, administradores u otras partes
interesadas.
El objetivo es comunicar u obtener la aprobacin.
No se requiere ninguna preparacin.
Revisiones: Es una forma de examinar personalmente su propio trabajo, tiene el objetivo
de descubrir y resolver los productos de manera temprana en el proceso de desarrollo. Se
usan para requerimientos, diseo y cdigo.
Un profesionista revisa de manera privada su producto.
El objetivo es encontrar defectos antes de la primera compilacin y las pruebas.
Mtodos para evaluar y mejorar la calidad de las revisiones
Medidas de las revisiones
Medidas Explcitas:
Tamao del programa que se revisa
Tiempo de revisin
Nmero de defectos encontrados
Nmero de defectos no encontrados (los que se escaparon)
Medidas derivadas:
Rendimiento (yield) de revisin (porcentaje de descubiertos)
LOC revisadas por hora
Defectos descubiertos por KLOC
Defectos encontrados por hora de revisin
Influencia de la revisin
El rendimiento (yield) se puede definir como:
Una medida de la calidad del proceso
El porcentaje de defectos en el producto al momento de la revisin que fueron
encontrados por la revisin
Una medida de efectividad de un paso del proceso
Revisiones de diseo y cdigo
Del proceso completo (antes de las pruebas)
Del proceso de desarrollo (incluyendo las pruebas)
Yield = 100 x (defectos encontrados) / (defectos encontrados + defectos no encontrados)
El rendimiento no puede ser calculado hasta que todos los defectos hayan sido
encontrados a travs de las pruebas y el uso del producto.
El rendimiento puede ser til de manera temprana en el proceso si todos o la mayora de
los defectos estn contabilizados.
Defectos en revisin de diseo y cdigo
Defectos en compilacin
Defectos en pruebas unitarias
El uso de datos del proceso y parmetros de control puede ayudar a asegurar revisiones
con altos rendimientos.
La DRL (Influencia de la eliminacin de defectos) mide la efectividad relativa de un paso
del proceso en la eliminacin de defectos, tambin es el nmero de defectos eliminados
por hora por un paso del proceso en relacin a un proceso base. Usualmente se toma
como base las pruebas unitarias (UT).

De esta manera DRL (X/UT) es la DRL para la fase X con respecto a las pruebas unitarias.
La DRL se calcula como sigue:
DRL (X/UT) = (Defectos / hora fase X) / defectos / Hora Pruebas Unitarias)
Desafortunadamente estas medidas se encuentran disponibles hasta despus de
terminado el proceso.
Necesidades y beneficios de las revisiones de diseo
La razn para buscar defectos en productos tempranos es porque stos se traducen en
defectos en el producto final. Es decir, defectos en los requisitos se traducirn en defectos
en el sistema final. Veamos una analoga con la arquitectura de edificios. Si en un plano el
color de una lnea indica su significado, una confusin en el color se traducir en un error
en el edificio.
Por ejemplo, si el azul indica tuberas de agua y el amarillo cables elctricos y el arquitecto
comete un error usando el azul en una conduccin elctrica, los electricistas que usen el
plano como gua para su trabajo no colocarn cables elctricos mientras que los
fontaneros colocarn tuberas de agua donde no deban ir. El plano de un edificio es el
artefacto equivalente al diseo de un producto software. Si un diseo contiene defectos,
seguramente estos defectos se trasmitirn al cdigo cuando los programadores usen ese
diseo como gua para su trabajo.
La deteccin temprana de errores acarrea grandes beneficios. Si las revisiones nicamente
se aplican al cdigo mejoran la calidad y producen ahorros en los costos del proyecto.
Pero los ahorros son mayores si se inspeccionan artefactos tempranos del desarrollo. La
experiencia demuestra que entre el 30% y el 70% de los defectos, de diseo y cdigo son
detectados por las tcnicas estticas. Esto supone un gran ahorro, pues la correccin es
ms fcil y menos costosa durante la evaluacin esttica que durante la dinmica.
Ntese que cuando durante la evaluacin dinmica del sistema se detecta un fallo en un
programa, lo que se detecta es el fallo, no la falta que lo provoca. Es decir, tras la
deteccin del fallo, se requiere una labor de localizacin en el programa de la falta que
provoc el fallo. Sin embargo, con las tcnicas estticas, lo que se detecta son
directamente faltas. Por tanto, una vez detectada, se puede pasar a la fase de correccin.
Es decir, desaparece la tarea de localizacin de la falta. Esto significa, que las tcnicas
estticas son ms baratas por falta que las dinmicas.
Las revisiones tambin proporcionan beneficios ms generales. Entre stos se pueden
citar estn:
Evaluacin del progreso del proyecto.
Potencia las capacidades de los participantes.
Mejoran la comunicacin entre el equipo de desarrollo, aumentando su
motivacin, pues los productos pasan a ser documentos pblicos.
Proporciona aprendizaje, retroalimentacin y prevencin.
Forma y educa a los participantes.
En el caso concreto de las revisiones de cdigo, stas, adems, permiten localizar
secciones crticas, lo que permitir dedicar un mayor esfuerzo a ellas en la fase de
pruebas.
Tpicos de verificacin de diseo
Se define verificacin como la confirmacin mediante la aportacin de datos que
respalden la existencia o veracidad del cumplimiento con los requisitos especificados
(UNE-EN-ISO 9000:2005).
La confirmacin puede comprender acciones tales como:
Elaboracin de clculos alternativos.
Comparacin de una especificacin de un diseo nuevo con una especificacin de
un diseo similar probado.
Realizacin de ensayos/pruebas y demostraciones.
Revisin de los documentos antes de su emisin.
La verificacin se aplica sobre todo en el mbito del proceso de diseo y desarrollo de un
producto.
Es un trmino de gran ayuda para los responsables del sistema de gestin de calidad,
puesto que supone cotejar los resultados obtenidos con los requisitos que se
establecieron como necesarios en la fase inicial del proceso, de acuerdo a lo planificado.
La verificacin de los resultados del diseo se debe realizar al final de cada una de las
actividades.