Verificacion Del Requerimiento-1.1

“AÑO DE LA PROMOCIÓN DE LA INDUSTRIA RESPONSABLE Y

DEL COMPROMISO CLIMÁTICO”

Universidad Nacional

San Luis Gonzaga de Ica FACULTAD DE INGENIERIA DE SISTEMAS

VERIFICACIÓN DEL

REQUERIMIENTO

CURSO : PRUEBAS DE SOFTWARE

INTEGRANTES : CARDENAS PEÑA, Christopher.

ESPINOZA JAYO, Ricardo.

HUAMANI PALACIOS, Kevin

RODRIGUEZ AYBAR, Bryam

SOTELO ESPINO, Carlos

ICA - PERÚ

2014

VERIFICACION DE REQUERIMIENTOS

PRUEBAS DE SOFTWARE 2

DEDICATORIA ESTE TRABAJO MONOGRÁFICO ESTÁ

DEDICADO A MIS COMPAÑEROS DE

CLASE, PARA QUE A TRAVÉS DE ÉL SE

PUEDAN INFORMAR Y CONOCER MÁS

ACERCA DEL TEMA DE CICLOS DE VIDA

DEL SOFTWARE, Y ASÍ MISMO PUEDA SER

DE REFERENCIA PARA OCASIONES

FUTURAS.



AGRADECIMIENTO A MIS COMPAÑEROS DEL EQUIPO DE

TRABAJO, YA QUE GRACIAS A SU APORTE

DE INFORMACIÓN SE PUDO LLEVAR A

CABO EL PRESENTE TRABAJO

MONOGRÁFICO.



ÍNDICE

CONTENIDO

Dedicatoria ............................................................................................................................................................................................... 2

Agradecimiento ...................................................................................................................................................................................... 3

Índice ......................................................................................................................................................................................................... 4

I. INTRODUCCIÓN ........................................................................................................................................................................... 7

II. Marco TEÓRICO ............................................................................................................................................................................ 8

1. ¿Qué es verificación? ................................................................................................................................................................. 8

2. Diferencia entre Validación y Verificación......................................................................................................................... 8

• Verificación: ................................................................................................................................................................................. 8

• Validación:.................................................................................................................................................................................... 9

3. ¿Qué es un Requerimiento? ................................................................................................................................................. 10

a) Características ....................................................................................................................................................................... 10

b) Tipos ......................................................................................................................................................................................... 10

Ambiente físico ..................................................................................................................................................................... 11

Interfaces................................................................................................................................................................................. 11

Usuarios y factores humanos .......................................................................................................................................... 12

Funcionalidad ........................................................................................................................................................................ 12

Documentación .................................................................................................................................................................... 12

Datos ........................................................................................................................................................................................ 13

Recursos .................................................................................................................................................................................. 13

Seguridad................................................................................................................................................................................ 14

Aseguramiento de la calidad .......................................................................................................................................... 14

c) Division .................................................................................................................................................................................... 14

Los requerimientos Funcionales .................................................................................................................................... 15

Los Requerimientos no Funcionales ............................................................................................................................ 15

III. Verificación del requerimiento ....................................................................................................................................... 15

1. Concepto.- .................................................................................................................................................................................. 15

2. Técnicas ........................................................................................................................................................................................ 15

A. Comprobaciones de escritorio ...................................................................................................................................... 15



A.1. Concepto ........................................................................................................................................................................ 15

B. Walkthroughs ....................................................................................................................................................................... 18

B.1. Concepto ........................................................................................................................................................................ 18

B.2. Partes involucradas en un walkthrough ............................................................................................................. 18

B.3. Duración ......................................................................................................................................................................... 19

B.4. Fases de un walkthrough ......................................................................................................................................... 19

C. Inspecciones .......................................................................................................................................................................... 19

C.1. Concepto ........................................................................................................................................................................ 19

C.2. Roles ................................................................................................................................................................................. 19

C.3. Etapas .............................................................................................................................................................................. 20

D. Diferencias entre Inspecciones y Walkthrough .................................................................................................. 21

IV. CONCLUSIONES ................................................................................................................................................................... 22

V. Recomendaciones .................................................................................................................................................................... 23

VI. bibliografía ............................................................................................................................................................................. 24



Índice de Figuras

Figura 1. Lista de Requerimientos.................................................................................................................................................. 7

Figura 2. Cheklist .................................................................................................................................................................................. 8

Figura 3. Verificación y Validación son excluyentes ............................................................................................................... 9

Figura 4. Requerimientos de Ambiente Físico ....................................................................................................................... 11

Figura 5. Sistemas Operativos en el mercado Actual .......................................................................................................... 11

Figura 6. Usuario usando un sistema de software ............................................................................................................... 12

Figura 7. Funcionalidad de un sistema ..................................................................................................................................... 12

Figura 8. Exceso de documentación .......................................................................................................................................... 13

Figura 9. Inspección de Información.......................................................................................................................................... 13

Figura 10. Locked File ..................................................................................................................................................................... 14

Figura 11. . Diagrama de flujo de una suma ........................................................................................................................... 16

Figura 12. Tabla de Comprobación de Escritorio ................................................................................................................. 17

Figura 13. Diferencia entre Inspección y Walkthrough ...................................................................................................... 21



I. INTRODUCCIÓN

La verificación de requerimientos es un proceso muy importante a la hora de desarrollar

software, pero muchas veces esta se deja de lado o se le dedica menos tiempo, en

comparación con otras tareas del proyecto.

En el presente trabajo damos a conocer conceptos básicos sobre verificación y su diferencia

con el término 'validación', así como también definimos lo que son los requerimientos, para

luego adentrarnos en lo que es la verificación de requerimientos propiamente dicha.

En la verificación de requerimientos estudiamos las distintas técnicas que se usan para

llevarla a cabo. Entre estas técnicas tenemos: las comprobaciones de escritorio, los

walkthroughs y las inspecciones.

Figura 1. Lista de Requerimientos



II. MARCO TEÓRICO

1. ¿QUÉ ES VERIFICACIÓN?

La verificación es la comprobación o examinación de los procesos de desarrollo de un

producto, para comprobar si está construido en base a las especificaciones iniciales.

En la verificación de un sistema comprobamos que este cumple con los requerimientos

funcionales y no funcionales que se le han especificado.

Figura 2. Cheklist

2. DIFERENCIA ENTRE VALIDACIÓN Y VERIFICACIÓN

La verificación y la validación aseguran que el software que se desarrolla está acorde a su

especificación y cumple las necesidades de los clientes.

Muchas veces la diferencia entre estos conceptos no se entiende, es por eso que Barry W.

Boehm (1979) puso en claro, con pocas palabras, su diferencia:

• VERIFICACIÓN: Comprueba que el producto cumple su especificación inicial. Se

entiende con la pregunta ¿Estamos construyendo correctamente el producto?



• VALIDACIÓN: Es un proceso más general. Comprueba que el producto satisface los

requerimientos del usuario. Se entiende con la pregunta ¿Estamos construyendo el producto

correcto?

Para aclarar aún más la diferencia entre validación y verificación veamos un ejemplo:

Un sistema puede pasar la validación, sin embargo, no pasa la verificación. Es decir, cumple

con los requerimientos del usuario, con lo que él quería, cubre sus necesidades pero

internamente puede adolecer de graves detalles como: un precario diseño en la base de

datos; uso de un excesivo e innecesario número de líneas de código, por desconocer las

potencialidades del lenguaje de desarrollo o de técnicas avanzadas de programación como

la POO y uso incorrecto en la BD de instrucciones propias del lenguaje de desarrollo, en

lugar de las sentencias adecuadas de SQL. Todo lo anterior son las especificaciones iniciales

que no se han cumplido.

Las dos utilizan métodos de diseño de casos de prueba y estrategias de prueba, para la

validación usamos Pruebas de Caja Negra (Grafos, partición equivalente y prueba de valores

límites) para la verificación empleamos Pruebas de Caja Blanca (Prueba de Camino crítico:

Grafo de flujo, complejidad ciclomática; prueba de Condición: ramificaciones, dominio,

operador relacional y de ramificación; Prueba de Flujo de datos y Prueba de Bucles).

Figura 3. Verificación y Validación son excluyentes



3. ¿QUÉ ES UN REQUERIMIENTO?

Existen muchas definiciones de requerimientos, en el Glosario de la IEEE se presenta las

siguientes definiciones:

1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un

objetivo.

2) Una condición o capacidad que debe estar presente en un sistema o componentes de

sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

3) Una representación documentada de una condición o capacidad como en (1) o (2).

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 comprensión de los que los

clientes y los usuarios esperan que haga el sistema.

Un requerimiento expresa el propósito del sistema sin considerar cómo se va a implementar.

A) CARACTERÍSTICAS

Las características de los requerimientos mencionados en el estándar de Especificación de

requerimientos IEEE830 los explica Shari Lawrence Pfleeger (2002). Los requerimientos deben

ser:

* CORRECTOS: Tanto el cliente como el desarrollador deben revisar los requerimientos

para asegurar que no tienen errores.

* CONSISTENTES: Dos requerimientos son inconsistentes cuando es imposible

satisfacerlos simultáneamente.

* COMPLETOS: El conjunto de requerimientos está completo si todos los estados posibles,

cambios de estado, entradas, productos y restricciones están descritos en alguno de los

requerimientos.

* REALISTAS: Todos los requerimientos deben ser revisados para asegurar que son

posibles.

B) TIPOS



Según el estándar IEEE830, los documentos de definición y especificación de requerimientos

deben contemplar los siguientes aspectos resumidos por Pfleeger (2002) como se indica a

continuación:

AMBIENTE FÍSICO

- ¿Dónde está el equipo que el sistema necesita para funcionar?

- ¿Existe una localización o varias?

- ¿Hay restricciones ambientales como temperatura, humedad o interferencia magnética?

Figura 4. Requerimientos de Ambiente Físico

INTERFACES

- ¿La entrada proviene de uno o más sistemas?

- ¿La salida va a uno o más sistemas?

- ¿Existe una manera preestablecida en que deben formatearse los datos?

Figura 5. Sistemas Operativos en el mercado Actual



USUARIOS Y FACTORES HUMANOS

- ¿Quién usará el sistema?

- ¿Habrá varios tipos de usuario?

- ¿Qué clase de entrenamiento requerirá cada tipo de usuario?

- ¿Cuán fácil le será al usuario comprender y utilizar el sistema?

Figura 6. Usuario usando un sistema de software

FUNCIONALIDAD

- ¿Qué hará el sistema?

- ¿Cuándo lo hará?

- ¿Existen varios modos de operación?

- ¿Cómo y cuándo puede cambiarse o mejorarse un sistema?

- ¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?

Figura 7. Funcionalidad de un sistema

DOCUMENTACIÓN



- ¿Cuánta documentación se requiere?

- ¿Debe estar en línea, en papel o en ambos?

- ¿A qué audiencia está orientado cada tipo de información?

Figura 8. Exceso de documentación

DATOS

- ¿Cuál será el formato de los datos, tanto para la entrada como para la salida?

- ¿Cuán a menudo serán recibidos o enviados?

- ¿Cuán exactos deben ser?

- ¿Con qué grado de precisión deben hacerse los cálculos?

Figura 9. Inspección de Información

RECURSOS

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

mantener el sistema?



- ¿Qué habilidades deben tener los desarrolladores?

- ¿Cuánto espacio físico será ocupado por el sistema?

- ¿Cuáles son los requerimientos de energía, calefacción o acondicionamiento de aire?

- ¿Existe un cronograma prescrito para el desarrollo?

SEGURIDAD

- ¿Debe controlarse el acceso al sistema o a la información?

- ¿Cómo se podrán aislar los datos de un usuario de los de otros?

- ¿Cómo podrán 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 daño provocado por agua o el robo?

Figura 10. Locked File

ASEGURAMIENTO DE LA CALIDAD

- ¿Cuáles son los requerimientos para la confiabilidad, disponibilidad, facilidad de

mantenimiento, seguridad y demás atributos de calidad?

- ¿Cómo deben demostrarse las características del sistema a terceros?

- ¿El sistema debe detectar y aislar defectos?

- ¿Cuál es el promedio de tiempo prescrito entre fallas?

-¿Existe un tiempo máximo permitido para la recuperación del sistema después de una falla?

C) DIVISION



Los requerimientos se pueden dividir en funcionales y no funcionales, a continuación se

definen:

LOS 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 aplicación (por ejemplo,

la aplicación debe calcular los gastos totales realizados en el mes actual).

LOS REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales tienen que ver con características 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).

III. VERIFICACIÓN DEL REQUERIMIENTO

1. CONCEPTO.-

La verificación del requerimiento es una rigurosa demostración de la concordancia del

código fuente con las especificaciones dadas en primera instancia por el cliente.

Es la valoración de los productos de trabajo, para determinar el apego a las especificaciones

de requisitos, la documentación del diseño, los diversos principios generales de estilo,

estándares del lenguaje de instrumentación, del proyecto, organizaciones y expectativas del

usuario.

2. TÉCNICAS

A. COMPROBACIONES DE ESCRITORIO

A.1. CONCEPTO

Una comprobación de escritorio es una prueba muy útil para entender que hace un

determinado algoritmo, sin necesidad que ponerlo en ejecución en un software en

específico.



En pocas palabras, una comprobación de escritorio es una ejecución “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

Saber si algún paso o instrucción no está en el orden correcto

Saber si los pasos o instrucciones que se repiten lo hacen más o menos veces de lo

debido

Reconocer otros errores que pueden presentarse

Veamos un ejemplo de una prueba de escritorio en acción:

Figura 11. . Diagrama de flujo de una suma



De acuerdo a ese diagrama y a nuestro pseudocódigo, haríamos la siguiente comprobación:

Inicio num1: Entero num2: Entero Suma: Entero

Leer num1 //3 Leer num2: //5

Suma = num1 + num2 //8

Mostrar suma //8 Fin

Los resultados de la comprobación de escritorio se pueden documentar en una tabla para

una fácil referencia. Hay muchas formas de presentar la información en tablas.

Figura 12. Tabla de Comprobación de Escritorio

Una comprobación de escritorio es realizada antes de que el algoritmo sea codificado.



La comprobación de escritorio no se utiliza tan frecuentemente como se hacía hace unos

años. Muchos controles a los programas se realizan en pantalla o con sistemas de

depuración avanzados, reduciendo la necesidad de bolígrafo y papel.

B. WALKTHROUGHS

B.1. CONCEPTO

Walkthrough es una reunión de revisión, donde una persona o varias examinan el código de

otro.

Su función principal no es establecer ninguna clase de intercomunicación entre partes, como

parece que debería de ser el objetivo de una reunión, sino que lo que pretende es establecer

una evaluación 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

detección de errores. Por tanto debe de evitarse por todos los medios el utilizarlo para otros

propósitos, (como por ejemplo evaluar a los programadores) que indudablemente

invalidarían los resultados.

B.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.

B.3. DURACIÓN

El tiempo máximo de un walkthrough suele estipularse en dos horas, pasado el cual está

comprobado que ya no se obtienen los resultados apetecidos de detección de errores.

B.4. FASES DE UN WALKTHROUGH

1. Planificación: El moderador es quien organiza la reunión.

2. Preparación individual: Cada revisor realiza la revisión.

3. Reunión del walkthrough: Reunión de máximo 2 horas, donde se muestran los errores

al revisado.

C. INSPECCIONES

C.1. CONCEPTO

Introducido por Michael Fagan de IBM en 1972, la inspección de software es una técnica para

eliminar defectos lo más 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, especificación, diseño, implementación, e integración y testing.

C.2. ROLES

Los siguientes roles son utilizados en una inspección:

1. Autor: La persona que creó el producto que se inspecciona.

2. Moderador: Este es el líder de la inspección. El moderador tiene previsto la inspección

y coordina la misma.



3. Lector: La persona que lee a través de los documentos, un elemento a la vez. Los

inspectores luego señalar los defectos.

4. Documentador: La persona que documenta los defectos que se encuentren durante la

inspección.

5. Inspector: La persona que examina el producto para identificar posibles defectos. El

Proceso

El proceso de inspección desarrollado por Michael Fagan en mediados de 1970 ha sido

posteriormente ampliado y modificado.

El proceso debe tener criterios de ingreso que determinan si el proceso de inspección está

listo para comenzar. Esto evita que los productos no terminados de trabajo entren en el

proceso de inspección. Los criterios de entrada podría ser una lista de comprobación

incluyendo elementos tales como "Al documento se le ha revisado la ortografía".

C.3. ETAPAS

Las etapas en el proceso de las inspecciones son:

1. Reunión de Planificación: La inspección se debe planear con anticipación por un

moderador..

2. Información general: Se deben describir los antecedentes del producto.

3. Preparación: Cada inspector examina el producto para identificar posibles defectos.

4. Reunión de inspección: Durante esta reunión, el lector lee parte por parte del

producto y los inspectores marcan de los defectos de cada parte.

5. Repetición del trabajo y seguimiento: El autor realiza cambios en el producto de

acuerdo a los planes de acción de la reunión de la inspección. También, 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.



D. DIFERENCIAS ENTRE INSPECCIONES Y WALKTHROUGH

Figura 13. Diferencia entre Inspección y Walkthrough



IV. CONCLUSIONES

Es muy importante realizar procesos de verificación del requerimiento, ya que estos, desde

las primeras etapas, nos dan una visión clara de cómo 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

validación y verificación, y aplicar técnicas como Comprobación de escritorio, Walkthroughs

e inspección para examinar el avance de las especificaciones, con un bajo riesgo y un bajo

costo.



V. RECOMENDACIONES

Cada proyecto es diferente, y deberíamos ser capaces de seleccionar que técnicas de

verificación del requerimiento nos va convenir usar. También debemos reconocer que

técnicas como la comprobación de escritorio, son técnicas desfasadas en estas épocas y que

existe software de mucha más calidad, que realizan el mismo proceso por nosotros, pero a

una gran velocidad.

Por esto es que debemos escoger bien las técnicas que vayamos a usar.



VI. BIBLIOGRAFÍA

http://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is09-Verificacion-

Validacion.pdf

http://web.cua.uam.mx/publicaciones/Notas_Analisis_Requerimiento.pdf

http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/231104/415/1/Ingenieria%20de%20re

querimientos.pdf

http://www.qvision.us/index.php/es/servicios/gestion-de-requerimientos-de-

software/verificacion-de-requisitos

http://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.html

http://hustariz.cs.umss.edu.bo/algPruEscr.htm

http://www.ehowenespanol.com/comprobacion-escritorio-hechos_110680/

http://www.scaridad.com/sites/default/files/asignatura/descargas/tema_1_-

_direccion_y_gestion_de_proyectos_software.pdf

http://www.reocities.com/ramonroque/slides_calidad_software.pdf

http://es.wikipedia.org/wiki/Inspecci%C3%B3n_de_software

http://hustariz.cs.umss.edu.bo/algPruEscr.htm

Documents

Verificacion Del Requerimiento-1.1