Universidad Nacional San Luis Gonzaga de Ica

AGRADECIMIENTO
Este trabajo se lo agradecemos primero a Dios quin supo guiarnos y darnos
fuerzas para encarar las adversidades sin perder nunca la dignidad, ni
desfallecer en el intento.
A nuestras familias quienes por ellos somos lo que somos. A nuestros
padres por su apoyo, consejos, comprensin, amor, ayuda en los momentos
difciles, y por ayudarnos con los recursos necesarios para estudiar.
A nuestros docentes por dejarnos sus enseanzas, sus experiencias y
abrirnos el camino para ser grandes triunfadores.
La dicha de la vida consiste en tener siempre algo que hacer, alguien a quien amar y
alguna cosa que esperar.

FIS - UNICA

Thomas Chalmers

FIS

Universidad Nacional San Luis Gonzaga de Ica

DEDICATORIA
A Dios en primer lugar le dedicamos nuestro
trabajo ya que l nos ha dado fortaleza para
continuar.
A nuestros padres quienes han sabido formarnos
con buenos sentimientos, hbitos y valores; lo cual
nos ha ayudado a salir adelante buscando

siempre el mejor camino.

A nuestro docente por su tiempo,FISapoyo
2 y
sabidura que nos transmite en el desarrollo
del curso.

Universidad Nacional San Luis Gonzaga de Ica

Contenido
INTRODUCCION ...................................................................................................................................6
1.

QU ES VERIFICACIN? .............................................................................................................7

2.

DIFERENCIA ENTRE VALIDACIN Y VERIFICACIN .....................................................................7

3.

REQUERIMIENTOS .......................................................................................................................8
3.1 DEFINICIN DE REQUERIMIENTO ..............................................................................................8
3.2 ANLISIS DE REQUERIMIENTO ...................................................................................................8
3.3 COMO REALIZAR EL ANLISIS DE REQUERIMIENTO ..................................................................9
3.4 TIPOS DE REQUERIMIENTO ........................................................................................................9
3.4.1 AMBIENTE FSICO ................................................................................................................9
3.4.2 INTERFACES ...................................................................................................................... 10
3.4.3 USUARIOS Y FACTORES HUMANOS ................................................................................. 10
3.4.4 FUNCIONALIDAD .............................................................................................................. 10
3.4.5 DOCUMENTACIN ........................................................................................................... 10
3.4.6 DATOS .............................................................................................................................. 10
3.4.7 RECURSOS ........................................................................................................................ 10
3.4.8 SEGURIDAD ...................................................................................................................... 11
3.4.9 ASEGURAMIENTO DE LA CALIDAD ................................................................................... 11
3.5 CARACTERSTICAS DE REQUERIMIENTO ................................................................................. 12
3.5.1 DEBE SER CORRECTO........................................................................................................ 12
3.5.2 DEBE SER CONSISTENTE ................................................................................................... 12
3.5.3 DEBE ESTAR COMPLETO................................................................................................... 12
3.5.4 DEBE SER REALISTA .......................................................................................................... 12
3.5.5 DEBE SER VERIFICABLE ..................................................................................................... 12
3.5.6 DEBE SER RASTREABLE ..................................................................................................... 13

4.

GESTIN DE REQUERIMIENTOS ............................................................................................... 13

4.1 CLASIFICACIN DEL REQUERIMIENTO .................................................................................... 14
4.1.1 REQUERIMIENTOS FUNCIONALES .................................................................................... 14
4.1.2 REQUERIMIENTOS NO FUNCIONALES.............................................................................. 14
4.1.3 REQUERIMIENTO DE DOMINIO........................................................................................ 14
4.2 PREGUNTAS QUE RESPONDEN LOS REQUERIMIENTOS .......................................................... 15

5.

CLASIFICACIN DE LOS REQUERIMIENTOS SEGN A QUIEN VA DIRIGIDO............................ 15

FIS

Universidad Nacional San Luis Gonzaga de Ica

5.1 REQUERIMIENTOS DEL USUARIO............................................................................................ 15

5.2 REQUERIMIENTOS DEL SISTEMA............................................................................................ 16
6.

VERIFICACIN DEL REQUERIMIENTO ...................................................................................... 16

6.1 TCNICAS DE VERIFICACIN DEL REQUERIMIENTO ................................................................ 17
6.1.1 AD HOC .......................................................................................................................... 17
6.1.2 REVISIN DE PARES(PEER DESKCHECK) ........................................................................... 17
6.1.3 REVISIN DE PARES MULTIPLE(PASSAROUND) ............................................................... 17
6.1.4 PROGRAMACIN DE A PARES(PAIR PROGRAMMING) .................................................... 18
6.1.5 COMPROBACIN DE ESCRITORIO .................................................................................... 18
6.1.6

PRESENTACIN (WALKTHROUGH) ............................................................................ 19

6.1.7 REVISIN EN EQUIPO ....................................................................................................... 20

6.1.8 INSPECCIONES .................................................................................................................. 21
CONCLUSIONES................................................................................................................................. 23
RECOMENDACIONES PARA UNA PRUEBA EXITOSA ........................................................................ 24
BIBLIOGRAFA ................................................................................................................................... 25

FIS

Universidad Nacional San Luis Gonzaga de Ica

NDICE DE TABLAS Y FIGURAS

Ilustracin 1 Documento de verificacion ..............................................................................................7
Ilustracin 2 Estadisticas, tipos de pruebas .........................................................................................8
Ilustracin 3 Tipos de requerimientos ............................................................................................... 12
Ilustracin 4 Caracteristicas de requerimientos................................................................................ 13
Ilustracin 5 Clasificacion de requerimientos ................................................................................... 15
Ilustracin 6 Verificacion de requerimientos de usuarios ................................................................. 16
Ilustracin 7 Verificacion de requerimientos de sistemas ................................................................. 16
Ilustracin 8 Esquema de revision de pares ...................................................................................... 17
Ilustracin 9 Revision de Passaround ................................................................................................ 18
Ilustracin 10 Recision Pair Programming ........................................................................................ 18
Ilustracin 11 Algoritmo para la revision de escritorio ..................................................................... 19
Ilustracin 12 Presentacion d walkthrougth ..................................................................................... 20
Ilustracin 13 Revisiones en equipo .................................................................................................. 21
Ilustracin 14 Inspecciones de pruebas ............................................................................................ 22
Ilustracin 15 Cuadro comparativo de inspecciones vs. Walkthrougth ............................................ 22

FIS

Universidad Nacional San Luis Gonzaga de Ica

INTRODUCCION
La Verificacin de requerimientos es el conjunto de actividades que aseguran que el software
implemente correctamente una funcin, La verificacin y la validacin abarcan una amplia lista de
actividades de aseguramiento de la calidad del software, estas incluyen: Revisiones tcnicas
formales, auditorias de calidad, simulacin, factibilidad, revisin de documentacin, y pruebas de
diversos tipos.
Las pruebas son la mejor forma de evaluar la calidad y de descubrir errores. Por definicin, la
verificacin implica la comparacin entre la lnea de base y los requerimientos de los refinamientos
sucesivos que descienden de el a fin de mantener estos refinamientos en consonancia con los
requerimientos del usuario.
Por lo tanto, las actividades de verificacin comienzan en la fase diseo de producto y concluyen
con la aceptacin del mismo. Estas actividades no conducen a cambios en los requerimientos
iniciales, slo a los cambios en los refinamientos que descienden de l.
Por otro lado, la verificacin identifica los problemas que deben resolverse por un cambio de la
especificacin de requerimientos.
Por ejemplo, una simulacin del diseo del producto puede mostrar no slo que el diseo no puede
cumplir con los requerimientos de rendimiento iniciales (verificacin), sino tambin que los
requerimientos de rendimiento son demasiado estrictos para los diseos de productos rentables, y
por lo tanto necesitan ser cambiadas (validacin).
Aunque verificacin y validacin implica que el proceso de revisin de un flujo de trabajo puede
esperar hasta el final de ese flujo, es decir, al final de un proceso. El proceso de validacin
verificacin es un ciclo vital, y debe aplicarse en cada etapa del software.

FIS

Universidad Nacional San Luis Gonzaga de Ica

1. QU ES VERIFICACIN?
La verificacin es la comprobacin o examinacin de los procesos de desarrollo de un producto,
para comprobar si est construido en base a las especificaciones iniciales.
En la verificacin de un sistema comprobamos que este cumple con los requerimientos funcionales
y no funcionales que se le han especificado.

Ilustracin 1 Documento de verificacion

2. DIFERENCIA ENTRE VALIDACIN Y VERIFICACIN

La verificacin y la validacin aseguran que el software que se desarrolla est acorde a su
especificacin y cumple las necesidades de los clientes.
VERIFICACIN:
Comprueba que el producto cumple su especificacin inicial. Se entiende con la pregunta Estamos
construyendo correctamente el producto?
VALIDACIN:
Es un proceso ms general. Comprueba que el producto satisface los requerimientos del usuario.
Se entiende con la pregunta Estamos construyendo el producto correcto?

FIS

Universidad Nacional San Luis Gonzaga de Ica

3. REQUERIMIENTOS
3.1 DEFINICIN DE REQUERIMIENTO
Los requerimientos especifican qu es lo que el sistema debe hacer (sus funciones) y sus
propiedades esenciales y deseables. La captura de los requerimientos tiene como objetivo principal
la comprensin de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento
expresa el propsito del sistema sin considerar COMO se va a implantar. En otras palabras, los
requerimientos identifican el QU del sistema, mientras que el diseo establece el cmo del
sistema.
La captura y el anlisis de los requerimientos del sistema es una de las fases ms importantes para
que el proyecto tenga xito.

Ilustracin 2 Estadisticas, tipos de pruebas

3.2 ANLISIS DE REQUERIMIENTO

Es el conjunto de tcnicas y procedimientos que nos permiten conocer los elementos necesarios
para definir un proyecto de software. Es una tarea de ingeniera del software que permite
especificar las caractersticas operacionales del software, indicar la interfaz del software con otros
elementos del sistema y establecer las restricciones que debe cumplir el software.
El anlisis de requerimientos proporciona una va para que los clientes y lo desarrolladores lleguen
a un acuerdo sobre lo que debe hacer el sistema. La especificacin, producto de este anlisis
proporciona las pautas a seguir a los diseadores del sistema.

FIS

Universidad Nacional San Luis Gonzaga de Ica

3.3 COMO REALIZAR EL ANLISIS DE REQUERIMIENTO

Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y
detallados, y adems contienen mltiples relaciones entre s.
Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples
y concisas para el sistema. Esto se logra mediante la clasificacin, estructuracin y organizacin de
todo lo que el sistema debe de hacer.
- Obtener informacin por diferentes medios de lo que los usuarios desean y dejar escritas esas
necesidades
- Clasificar esas necesidades para poder estructurar los requerimientos o necesidades del
sistema.
- Identificar los niveles de jerarqua del sistema y empezar a alojar los requerimientos en el nivel
que les corresponda.
- Especificar los requerimientos de acuerdo al nivel de audiencia que se requiera
- Especificar completamente cada necesidad, sin ahorrar tiempo y espacio en su descripcin.
- Entender correctamente las necesidades y cuando afecten dos o mas usuarios, para llegar a
acuerdos entre las partes.
- Manejar las expectativas y estar dispuesto a realizar cambios.
- Involucrar a todos los que tengan inherencia en el proyecto (Jefes, subalternos, usuarios en
general)
- Se debe mantener una perfecta comunicacin entre todos quienes participan en el proceso de
levantamiento de los requerimientos
Los requerimientos son el punto de acuerdo entre el usuario y el proyecto de desarrollo de software,
este entendimiento es necesario para poder construir software que satisfaga las necesidades de los
usuarios.
Las necesidades y/o requerimientos del usuario evolucionan con el tiempo y cada cambio involucra
un costo. Por eso es necesario tener archivada una copia de la documentacin original del usuario,
as como cada revisin o cambio que se haga a esta documentacin. Para poder establecer o estimar
el costo de un proyecto es necesario contar con los requerimientos iniciales en su mejor nivel de
detalle

3.4 TIPOS DE REQUERIMIENTO

Segn el estndar internacional de Especificacin de Requerimientos IEEE830, los documentos
de definicin y especificacin de requerimientos deben contemplar los siguientes aspectos
resumidos por [Pfleeger, 2002] como se indica a continuacin:

3.4.1 AMBIENTE FSICO

-

Dnde esta el equipo que el sistema necesita para funcionar?

Existe una localizacin o varias?
Hay restricciones ambientales como temperatura, humedad o interferencia magntica?
FIS

Universidad Nacional San Luis Gonzaga de Ica

3.4.2 INTERFACES
-

La entrada proviene de uno o ms sistemas?

La salida va a uno o ms sistemas?
Existe una manera preestablecida en que deben formatearse los datos?

3.4.3 USUARIOS Y FACTORES HUMANOS

-

Quien usar el sistema?

Habr varios tipos de usuario?
Cul es el nivel de habilidad de cada tipo de usuario?
Qu clase de entrenamiento requerir cada tipo de usuario?
Cun fcil le ser al usuario comprender y utilizar el sistema?
Cun difcil le resultar al usuario hacer uso indebido del sistema?

3.4.4 FUNCIONALIDAD
-

Qu har el sistema?
Cundo lo har?
Existen varios modos de operacin?
Cmo y cuando puede cambiarse o mejorarse un sistema?
Existen restricciones de la velocidad de ejecucin, tiempo de respuesta o rendimiento?

3.4.5 DOCUMENTACIN
-

Cunta documentacin se requiere?

Debe estar en lnea, en papel o en ambos?
A que audiencia est orientado cada tipo de informacin?

3.4.6 DATOS
-

Cul ser el formato de los datos, tanto para la entrada como para la salida?
Cun a menudo sern recibidos o enviados?
Cun exactos deben ser?
Con qu grado de precisin deben hacerse los clculos?
Cuntos datos fluyen a travs del sistema?
Debe retenerse algn dato por algn perodo de tiempo?

3.4.7 RECURSOS
-

Qu recursos materiales, personales o de otro tipo se requieren para construir, utilizar y

mantener el sistema?
Qu habilidades deben tener los desarrolladores?
FIS

10

Universidad Nacional San Luis Gonzaga de Ica

Cunto espacio fsico ser ocupado por el sistema?

Cules son los requerimientos de energa, calefaccin o acondicionamiento de aire?
Existe un cronograma prescrito para el desarrollo?
Existe un lmite sobre la cantidad de dinero a gastar en el desarrollo o en hardware y
software?

3.4.8 SEGURIDAD
-

Debe controlarse el acceso al sistema o a la informacin?

Cmo se podrn aislar los datos de un usuario de los de otros?
Cmo podrn aislarse los programas de usuario de los otros programas y del sistema
operativo?
Con qu frecuencia deben hacerse copias de respaldo?
Las copias de respaldo deben almacenarse en un lugar diferente?
Deben tomarse precauciones contra el fuego, el dao provocado por agua o el robo?

3.4.9 ASEGURAMIENTO DE LA CALIDAD

-

Cules son los requerimientos para la confiabilidad, disponibilidad, facilidad de

mantenimiento, seguridad y dems atributos de calidad?
Cmo deben demostrarse las caractersticas del sistema a terceros?
- El sistema debe detectar y aislar defectos?
- Cul es el promedio de tiempo prescrito entre fallas?
Existe un tiempo mximo permitido para la recuperacin del sistema despus de una falla?
El mantenimiento corregir los errores, o incluir tambin el mejoramiento del sistema?
Qu medidas de eficiencia se aplicarn al uso de recursos y al tiempo de respuesta?
Cun fcil debe ser mover el sistema de una ubicacin a otra o de un tipo de
computadora a otro?

FIS

11

Universidad Nacional San Luis Gonzaga de Ica

Ilustracin 3 Tipos de requerimientos

3.5 CARACTERSTICAS DE REQUERIMIENTO

Los requerimientos permiten que los desarrolladores expliquen cmo han entendido lo que el
cliente pretende del sistema. Tambin, indican a los diseadores qu funcionalidad y que
caractersticas va a tener el sistema resultante. Y adems, indican al equipo de pruebas qu
demostraciones llevar a cabo para convencer al cliente de que el sistema que se le entrega es lo que
solicit. Las caractersticas de los requerimientos mencionados en el estndar IEEE830 los explica
[Pfleeger, 2002] como sigue:

3.5.1 DEBE SER CORRECTO

Tanto el cliente como el desarrollador deben revisarlos para asegurar que no tienen errores.

3.5.2 DEBE SER CONSISTENTE

Dos requerimientos son inconsistentes cuando es imposible satisfacerlos simultneamente.

3.5.3 DEBE ESTAR COMPLETO

El conjunto de requerimientos est completo si todos los estados posibles, cambios de estado,
entradas, productos y restricciones estn descritos en alguno de los requerimientos.

3.5.4 DEBE SER REALISTA

Todos los requerimientos deben ser revisados para asegurar que son posibles.

3.5.5 DEBE SER VERIFICABLE

Se deben poder preparar pruebas que demuestren que se han cumplido los requerimientos.
FIS

12

Universidad Nacional San Luis Gonzaga de Ica

3.5.6 DEBE SER RASTREABLE

Se puede rastrear cada funcin del sistema hasta el conjunto de requerimientos que la establece?

Ilustracin 4 Caracteristicas de requerimientos

4. GESTIN DE REQUERIMIENTOS
Es un documento que debe escribirse en trminos que el cliente pueda entender. Es decir, este
documento es un listado completo de todas las cosas que el cliente espera que haga el sistema
propuesto. Este documento es escrito en forma conjunta por el cliente y el desarrollador.
Para realizar con xito la definicin de los requerimientos es importante conseguir que los
requerimientos sean claramente definidos para minimizar la ambigedad de los requerimientos,
para esto es importante tener en cuenta lo siguiente:

Definir los requerimientos teniendo en cuenta la informacin identificada con la

perspectiva del usuario.
Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen material
potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un
requisito ha sido especificado satisfactoriamente para un producto y que el producto ha
tenido xito, el requerimiento no tendr que volverse a inventar, podr ser utilizado las
veces que se desee teniendo en cuenta los derechos de autor.
FIS

13

Universidad Nacional San Luis Gonzaga de Ica

Se debe documentar los requerimientos de una forma clara y correcta.

4.1 CLASIFICACIN DEL REQUERIMIENTO

4.1.1 REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales definen, precisamente, las funciones que el sistema ser capaz de
realizar. Describen las transformaciones que el sistema realiza en las entradas para producir salidas
y especifican los servicios que debe proporcionar la aplicacin (por ejemplo, la aplicacin debe
calcular los gastos totales realizados en el mes actual).

Describen la funcionalidad o los servicios que se espera que el sistema proveer. Dependen del
tipo de software, del sistema que se desarroll y de los posibles usuarios.

Cuando se expresan como Requerimientos del usuario, se definen de forma general.

Cuando se expresan como requerimiento del sistema describen con detalle la funcin de ste,
sus entradas y salidas, excepciones, etc.

4.1.2 REQUERIMIENTOS NO FUNCIONALES

Son los requerimientos que no se refieren directamente a las funciones especficas que entrega el
sistema, sino a las propiedades emergentes de ste, como la fiabilidad, la respuesta en el tiempo y
la capacidad de almacenamiento.
Muchos requerimientos no funcionales se refieren al sistema como un todo ms que a rasgos
particulares del mismo.
Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma
puedan limitar el sistema (por ejemplo, el rendimiento, en tiempo y espacio, interfaces de usuario,
fiabilidad, robustez del sistema, mantenimiento, seguridad, portabilidad).

4.1.3 REQUERIMIENTO DE DOMINIO

Estos son requerimientos que provienen del dominio de aplicacin del sistema y reflejan
caractersticas y restricciones de ese dominio. Estos pueden ser funcionales o no funcionales.

FIS

14

Universidad Nacional San Luis Gonzaga de Ica

Ilustracin 5 Clasificacion de requerimientos

4.2 PREGUNTAS QUE RESPONDEN LOS REQUERIMIENTOS

_los requerimientos son correctos?. Cliente y desarrollador deben revisarlos para asegurarse que
no tienen errores.
_los requerimientos son consistentes?. Es decir, los requerimientos planteados son no
conflictivos ni ambiguos?. Dos requerimientos son inconsistentes cuando es imposible satisfacerlos
simultneamente.

5. CLASIFICACIN DE LOS REQUERIMIENTOS SEGN A QUIEN VA

DIRIGIDO
5.1 REQUERIMIENTOS DEL USUARIO
Declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema
provea y de las restricciones bajo las cuales debe operar.
Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por
los usuarios del sistema que no posean un conocimiento tcnico detallado.
nicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las
caractersticas de diseo del sistema.

FIS

15

Universidad Nacional San Luis Gonzaga de Ica

Ilustracin 6 Verificacion de requerimientos de usuarios

5.2 REQUERIMIENTOS DEL SISTEMA

Establecen con detalle los servicios y restricciones del sistema.

El documento de requerimientos del sistema, algunas veces denominado especificacin
funcional, debe ser preciso.
ste sirve como un contrato entre el comprador del sistema y el desarrollador del software.
Son descripciones ms detalladas de los requerimientos del usuario.
Sirven como base para definir el contrato de la especificacin del sistema y, por lo tanto, debe
ser una especificacin completa y consistente del sistema.
Son utilizados por los ingenieros de software como el punto de partida para el diseo del sistema.

Ilustracin 7 Verificacion de requerimientos de sistemas

6. VERIFICACIN DEL REQUERIMIENTO

La verificacin del requerimiento es una rigurosa demostracin de la concordancia del cdigo
fuente con las especificaciones dadas en primera instancia por el cliente.
Es la valoracin de los productos de trabajo, para determinar el apego a las especificaciones de
requisitos, la documentacin del diseo, los diversos principios generales de estilo, estndares del
lenguaje de instrumentacin, del proyecto, organizaciones y expectativas del usuario.

FIS

16

Universidad Nacional San Luis Gonzaga de Ica

6.1 TCNICAS DE VERIFICACIN DEL REQUERIMIENTO

6.1.1 AD HOC
Es una forma rpida de obtener otra perspectiva para encontrar problemas que el autor del
proyecto no puede ver por s mismo. La tcnica no sigue un proceso establecido y sus resultados no
se registran de una manera predefinida.

6.1.2 REVISIN DE PARES(PEER DESKCHECK)

Involucra a una sola persona (distinta al autor del proyecto) quien recibe una copia del proyecto
para su revisin. El revisor puede utilizar checklists u otras tcnicas de anlisis que incrementen la
efectividad del proceso.
La llamada revisin por pares es un conocido mtodo de control de la calidad de los artculos y
productos.

Ilustracin 8 Esquema de revision de pares

6.1.3 REVISIN DE PARES MULTIPLE(PASSAROUND)

Es una revisin de pares realizada concurrentemente. El proyecto a revisar es distribuido entre 3 y
15 personas quines revisan y dan su devolucin por separado. Una variante es compartir un
documento donde los revisores realicen sus comentarios para minimizar la redundancia y mostrar
diferentes interpretaciones de lo revisado.

FIS

17

Universidad Nacional San Luis Gonzaga de Ica

Ilustracin 9 Revision de Passaround

6.1.4 PROGRAMACIN DE A PARES(PAIR PROGRAMMING)

Esta tcnica consiste en dos desarrolladores trabajando en un mismo producto simultneamente,
en una sola computadora, compartiendo un teclado y un monitor. Uno hace de controlador y es el
que efectivamente programa; el otro es el navegador que observa el trabajo del controlador e
identifica errores.

Ilustracin 10 Recision Pair Programming

6.1.5 COMPROBACIN DE ESCRITORIO

Una comprobacin de escritorio es una prueba muy til para entender que hace un determinado
algoritmo, sin necesidad que ponerlo en ejecucin en un software en especfico.
En pocas palabras, una comprobacin de escritorio es una ejecucin a mano de un algoritmo,
donde vamos llevando registro de los valores que va tomando, por ejemplo una variable, a lo largo
del mismo.
La prueba de escritorio nos permite:
Saber si un algoritmo est bien hecho de acuerdo a las especificaciones iniciales.
Eliminar variables no necesarias.
Crear variables faltantes.
Usar los bucles adecuados.
FIS

18

Universidad Nacional San Luis Gonzaga de Ica

Saber si algn paso o instruccin no est en el orden correcto.

Saber si los pasos o instrucciones que se repiten lo hacen ms o menos veces de lo debido.
Reconocer otros errores que pueden presentarse.

Ilustracin 11 Algoritmo para la revision de escritorio

6.1.6 PRESENTACIN (WALKTHROUGH)

6.1.6.1 DEFINICIN
Walkthrough es una reunin de revisin, donde una persona o varias examinan el cdigo de otro.
Su funcin principal no es establecer ninguna clase de intercomunicacin entre partes, como parece
que debera de ser el objetivo de una reunin, sino que lo que pretende es establecer una evaluacin
del trabajo de una persona por parte del Equipo de Proyecto.
Por lo general, un Walkthrough se convoca cuando un miembro del Equipo (normalmente un
programador) considera que una parte de su trabajo est completa y puede ser revisada. En este
momento, invita a otros miembros del Equipo para que revisen su trabajo y le ayuden a detectar
errores potenciales. Esta es la labor fundamental de un walkthrough: la deteccin de errores. Por
tanto debe de evitarse por todos los medios el utilizarlo para otros propsitos, (como por ejemplo
evaluar a los programadores) que indudablemente invalidaran los resultados.

FIS

19

Universidad Nacional San Luis Gonzaga de Ica

6.1.6.2 PARTES INVOLUCRADAS EN UN WALKTHROUGH

Las personas involucradas en un walkthrough son:
-

La persona a ser revisada.

El revisador o los revisadores.
Un moderador.
Un secretario.

Una persona puede realizar varias de estas funciones a la misma persona.

6.1.6.3 DURACIN DE UN WALKTHROUGH
El tiempo mximo de un walkthrough suele estipularse en dos horas, pasado el cual est
comprobado que ya no se obtienen los resultados apetecidos de deteccin de errores.
6.1.6.4 FASES UN WALKTHROUGH
1. Planificacin: El moderador es quien organiza la reunin.
2. Preparacin individual: Cada revisor realiza la revisin.
3. Reunin del walkthrough: Reunin de mximo 2 horas, donde se muestran los errores al revisado.

Ilustracin 12 Presentacion d walkthrougth

6.1.7 REVISIN EN EQUIPO

Comienza con una planificacin seguida de una de preparacin donde los participantes reciben el
material necesario varios das antes. Luego el equipo (con roles definidos) se rene para discutir los
resultados donde participan el lder de revisin (puede ser el propio autor del artefacto revisado),
registrador y moderador (no puede ser del propio autor). La ltima etapa es la correccin de los
defectos encontrados. Existe un cierto paralelismo entre la Revisin en equipo de Wiegers y la
Revisin tcnica planteada en el estndar IEEE 1028-2008. Ambos mtodos tienen en comn la idea
de un rol de lder de revisin o moderador y de un registrador. Tambin ambas tcnicas incluyen
una etapa de reunin y la necesidad de una etapa de preparacin previa a la misma.

FIS

20

Universidad Nacional San Luis Gonzaga de Ica

Ilustracin 13 Revisiones en equipo

6.1.8 INSPECCIONES
6.1.8.1 DEFINICIN
Introducido por Michael Fagan de IBM en 1972, la inspeccin de software es una tcnica para
eliminar defectos lo ms tempranamente posible en el ciclo de vida del Software, siguiendo un plan
bien definido y detallado, para asegurar de que esa un proceso repetible y mejorable.
Las inspecciones se llevan a cabo al final de cada una de las fases de desarrollo: requerimientos,
especificacin, diseo, implementacin, e integracin y testing.
6.1.8.2 ROLES
Los siguientes roles son utilizados en una inspeccin:
1. Autor: La persona que cre el producto que se inspecciona.
2. Moderador: Este es el lder de la inspeccin. El moderador tiene previsto la inspeccin y coordina
la misma.
3. Lector: La persona que lee a travs de los documentos, un elemento a la vez. Los inspectores
luego sealar los defectos.
4. Documentador: La persona que documenta los defectos que se encuentren durante la inspeccin.
5. Inspector: La persona que examina el producto para identificar posibles defectos.
El proceso debe tener criterios de ingreso que determinan si el proceso de inspeccin est listo para
comenzar. Esto evita que los productos no terminados de trabajo entren en el proceso de
inspeccin. Los criterios de entrada podra ser una lista de comprobacin incluyendo elementos
tales como "Al documento se le ha revisado la ortografa".
6.1.8.3 ETAPAS
Las etapas en el proceso de las inspecciones son:
1. Reunin de Planificacin: La inspeccin se debe planear con anticipacin por un moderador..
2. Informacin general: Se deben describir los antecedentes del producto.
3. Preparacin: Cada inspector examina el producto para identificar posibles defectos.

FIS

21

Universidad Nacional San Luis Gonzaga de Ica

4. Reunin de inspeccin: Durante esta reunin, el lector lee parte por parte del producto y los
inspectores marcan de los defectos de cada parte.
5. Repeticin del trabajo y seguimiento: El autor realiza cambios en el producto de acuerdo a los
planes de accin de la reunin de la inspeccin. Tambin, Los cambios del autor son revisados para
asegurarse de que todo est correcto.
El proceso es finalizado por el moderador cuando satisface algunos criterios de salida predefinidos.

Ilustracin 14 Inspecciones de pruebas.

6.1.8.4 DIFERENCIAS ENTRE INSPECCIONES Y WALKTHROUGH

Ilustracin 15 Puntos comparativos de inspecciones vs. Walkthrougth

FIS

22

Universidad Nacional San Luis Gonzaga de Ica

CONCLUSIONES
Es muy importante realizar procesos de verificacin del requerimiento, ya que estos, desde las
primeras etapas, nos dan una visin clara de cmo est avanzando el proyecto de acuerdo a los
requerimientos de los usuarios.
Ahora, podemos ver lo necesario que es entender las diferencias de conceptos entre validacin y
verificacin, y aplicar tcnicas como Comprobacin de escritorio, Walkthroughs e inspeccin para
examinar el avance de las especificaciones, con un bajo riesgo y un bajo costo.
Dentro de los aspectos ms importantes que se encontraron al estudiar el tema son:
Que con el anlisis requerimientos estn sujetos a muchas mejoras para el desarrollo del
software, dando satisfaccin al cliente al obtener las caractersticas del software deseadas.
Las actividades en el anlisis de requerimientos dentro de toda empresa se llevan a cabo a
travs de diferentes herramientas y estrategias: los enfoques que se orienten a solucionar
problemticas de este proceso deben ser abiertos y flexibles de manera que no se restrinjan
a herramientas o estrategias particulares.
Cualquier elemento que facilite la mejora de la calidad de los procesos en el desarrollo de
software (Requerimientos) al interior de una empresa desarrolladora permitir a las mismas
tener mayores posibilidades de xito en el mercado nacional como internacional.
En la construccin de un software debemos cubrir las necesidades de anlisis de riesgos
asociados a los requerimientos en etapas tempranas, de los proyectos de software en forma
estructurada: cada actividad del anlisis de requerimientos consiste de una serie de pasos
organizados y bien definidos.
Toda tcnica debe ser util, adaptable y modular: la estructura en el desarrollo del software
no se debe restringir a ninguna herramienta, o estrategia para desarrollo de actividades del
anlisis de requerimientos.
La calidad en el software tiene que ver con cumplir un conjunto de requerimientos
(funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.), y el modelo se orienta
mejorar estos aspectos.

FIS

23

Universidad Nacional San Luis Gonzaga de Ica

RECOMENDACIONES PARA UNA PRUEBA EXITOSA

-

Cada caso de prueba debe definir el resultado de salida esperado que se comparar con el
realmente obtenido.
El programador debe evitar probar sus propios programas, ya que desea (consciente o
inconscientemente) demostrar que funcionan sin problemas.
Se debe inspeccionar a conciencia el resultado de cada prueba, para as, poder descubrir posibles
sntomas de defectos.
Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos como no vlidos.
Las pruebas deben centrarse en dos objetivos: probar si el software no hace lo que debe hacer o
viceversa, es decir, si provoca efectos secundarios adversos
No deben hacerse planes de prueba suponiendo que, prcticamente, no hay defectos en los
programas y, por lo tanto, dedicando pocos recursos a las pruebas siempre hay defectos.
La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de
descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya
descubierto.
Las pruebas son una tarea tanto o ms creativa que el desarrollo de software. Siempre se han
considerado las pruebas como una tarea destructiva y rutinaria.

FIS

24

Universidad Nacional San Luis Gonzaga de Ica

BIBLIOGRAFA
http://www.qvision.us/es/servicios/gestion-de-requerimientos-de-software/verificacionde-requisitos
http://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is09-VerificacionValidacion.pdf
http://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.html
http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_Verificacio
nValidacion-2011.pdf
https://www.scribd.com/doc/92756471/Plan-de-Verificacion-de-Requerimientos
http://www.plm.automation.siemens.com/es_sa/products/nx/for-design/visualanalytics/design-requirements-validation.shtml
http://clases3gingsof.wikifoundry.com/page/Verificaci%C3%B3n+y+Validaci%C3%B3n
http://www.slideshare.net/videoconferenciasutpl/validacin-de-requerimientos
http://www.suit.gov.co/VisorSUIT/index.jsf?FI=566
http://www.qvision.us/es/servicios/gestion-de-requerimientos-de-software/verificacionde-requisitos
http://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is09-VerificacionValidacion.pdf
http://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.html
http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_Verificacio
nValidacion-2011.pdf
https://www.scribd.com/doc/92756471/Plan-de-Verificacion-de-Requerimientos
http://www.plm.automation.siemens.com/es_sa/products/nx/for-design/visualanalytics/design-requirements-validation.shtml
http://clases3gingsof.wikifoundry.com/page/Verificaci%C3%B3n+y+Validaci%C3%B3n
http://www.slideshare.net/videoconferenciasutpl/validacin-de-requerimientos
http://www.suit.gov.co/VisorSUIT/index.jsf?FI=566
http://ingenieriadesoftware.bligoo.com.mx/requerimientos-funcionales-y-nofuncionales-rf-rnf#.VVQkmPl_Oko
https://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?media=princip
al:csof5101-requerimientos.pdf
http://www.alegsa.com.ar/Dic/requerimientos.php
https://sites.google.com/site/metodologiareq/capitulo-iii#_Toc324280458
http://elvex.ugr.es/idbis/db/docs/design/2-requirements.pdf
http://es.wikipedia.org/wiki/Requisito_funcional

FIS

25