Verificacion y Validacion de Requerimientos

Universidad

Nacional “San Luis Gonzaga” de Ica

AGRADECIMIENTO Este trabajo se lo agradecemos primero a Dios quién 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, comprensión, amor, ayuda en los momentos difíciles, y por ayudarnos con los recursos necesarios para estudiar. A nuestros docentes por dejarnos sus enseñanzas, 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”. Thomas Chalmers

FIS

1

Universidad


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, hábitos y valores; lo cual nos ha ayudado a salir adelante buscando

FIS

2

Universidad


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

¿QUÉ ES VERIFICACIÓN? .............................................................................................................7

2.

DIFERENCIA ENTRE VALIDACIÓN Y VERIFICACIÓN .....................................................................7

3.

REQUERIMIENTOS .......................................................................................................................8 3.1 DEFINICIÓN DE REQUERIMIENTO ..............................................................................................8 3.2 ANÁLISIS DE REQUERIMIENTO ...................................................................................................8 3.3 COMO REALIZAR EL ANÁLISIS DE REQUERIMIENTO ..................................................................9 3.4 TIPOS DE REQUERIMIENTO ........................................................................................................9 3.4.1 AMBIENTE FÍSICO ................................................................................................................9 3.4.2 INTERFACES ...................................................................................................................... 10 3.4.3 USUARIOS Y FACTORES HUMANOS ................................................................................. 10 3.4.4 FUNCIONALIDAD .............................................................................................................. 10 3.4.5 DOCUMENTACIÓN ........................................................................................................... 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 CARACTERÍSTICAS 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.

GESTIÓN DE REQUERIMIENTOS ............................................................................................... 13 4.1 CLASIFICACIÓN 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.

CLASIFICACIÓN DE LOS REQUERIMIENTOS SEGÚN A QUIEN VA D IRIGIDO............................ 15 FIS

3

Universidad


5.1 REQUERIMIENTOS DEL USUARIO............................................................................................ 15 5.2 REQUERIMIENTOS DEL SISTEMA ............................................................................................ 16 6.

VERIFICACIÓN DEL REQUERIMIENTO ...................................................................................... 16 6.1 TÉCNICAS DE VERIFICACIÓN DEL REQUERIMIENTO ................................................................ 17 6.1.1 AD – HOC .......................................................................................................................... 17 6.1.2 REVISIÓN DE PARES(PEER DESKCHECK) ........................................................................... 17 6.1.3 REVISIÓN DE PARES MULTIPLE(PASSAROUND) ............................................................... 17 6.1.4 PROGRAMACIÓN DE A PARES(PAIR PROGRAMMING) .................................................... 18 6.1.5 COMPROBACIÓN DE ESCRITORIO .................................................................................... 18 6.1.6

PRESENTACIÓN (WALKTHROUGH) ............................................................................ 19

6.1.7 REVISIÓN EN EQUIPO ....................................................................................................... 20 6.1.8 INSPECCIONES .................................................................................................................. 21 CONCLUSIONES................................................................................................................................. 23 RECOMENDACIONES PARA UNA PRUEBA EXITOSA ........................................................................ 24 BIBLIOGRAFÍA ................................................................................................................................... 25

FIS

4

Universidad


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

FIS

5

Universidad


La Verificación de requerimientos es el conjunto de actividades que aseguran que el software implemente correctamente una función, La verificación y la validación abarcan una amplia lista de actividades de aseguramiento de la calidad del software, estas incluyen: Revisiones técnicas formales, auditorias de calidad, simulación, factibilidad, revisión de documentación, y pruebas de diversos tipos. Las pruebas son la mejor forma de evaluar la calidad y de descubrir errores. Por definición, la verificación implica la comparación entre la línea 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 verificación comienzan en la fase diseño de producto y concluyen con la aceptación del mismo. Estas actividades no conducen a cambios en los requerimientos iniciales, sólo a los cambios en los refinamientos que descienden de él. Por otro lado, la verificación identifica los problemas que deben resolverse por un cambio de la especificación de requerimientos. Por ejemplo, una simulación del diseño del producto puede mostrar no sólo que el diseño no puede cumplir con los requerimientos de rendimiento iniciales (verificación), sino también que los requerimientos de rendimiento son demasiado estrictos para los diseños de productos rentables, y por lo tanto necesitan ser cambiadas (validación). Aunque verificación y validación implica que el proceso de revisión de un flujo de trabajo puede esperar hasta el final de ese flujo, es decir, al final de un proceso. El proceso de validación verificación es un ciclo vital, y debe aplicarse en cada etapa del software .

FIS

6

Universidad


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

Ilustración 1 Documento de verificacion

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

FIS

7

Universidad


3.1 DEFINICIÓN 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 comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema sin considerar COMO se va a implantar. En otras palabras, los requerimientos identifican el QUÉ del sistema, mientras que el diseño establece el cómo del sistema. La captura y el análisis de los requerimientos del sistema es una de las fases más importantes para que el proyecto tenga éxito.

Ilustración 2 Estadisticas, tipos de pruebas

3.2 ANÁLISIS DE REQUERIMIENTO Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. Es una tarea de ingeniería del software que permite especificar las características operacionales del software, indicar la interfaz del software con otros elementos del sistema y establecer las restricciones que debe cumplir el software. El análisis de requerimientos proporciona una vía para que los clientes y lo desarrolladores lleguen a un acuerdo sobre lo que debe hacer el sistema. La especificación, producto de este análisis proporciona las pautas a seguir a los diseñadores del sistema.

FIS

8

Universidad


3.3 COMO REALIZAR EL ANÁLISIS DE REQUERIMIENTO Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y además contienen múltiples relaciones entre sí . Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema. Esto se logra mediante la clasificación, estructuración y organización de todo lo que el sistema debe de hacer. - Obtener información 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 jerarquía 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 descripción. - 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 comunicación 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 documentación original del usuario, así como cada revisión o cambio que se haga a esta documentación. 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 Según el estándar internacional de Especificación de Requerimientos 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:

3.4.1 AMBIENTE FÍSICO -

¿Dónde esta el equipo que el sistema necesita para funcionar? ¿Existe una localización o varias? ¿Hay restricciones ambientales como temperatura, humedad o interferencia magnética? FIS

9

Universidad


3.4.2 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?

3.4.3 USUARIOS Y FACTORES HUMANOS -

¿Quien usará el sistema? ¿Habrá varios tipos de usuario? ¿Cuál es el nivel de habilidad de cada tipo de usuario? ¿Qué clase de entrenamiento requerirá cada tipo de usuario? ¿Cuán fácil le será al usuario comprender y utilizar el sistema? ¿Cuán difícil le resultará al usuario hacer uso indebido del sistema?

3.4.4 FUNCIONALIDAD -

¿Qué hará el sistema? ¿Cuándo lo hará? ¿Existen varios modos de operación? ¿Cómo y cuando puede cambiarse o mejorarse un sistema? ¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?

3.4.5 DOCUMENTACIÓN -

¿Cuánta documentación se requiere? ¿Debe estar en línea, en papel o en ambos? ¿A que audiencia está orientado cada tipo de información?

3.4.6 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? ¿Cuántos datos fluyen a través del sistema? ¿Debe retenerse algún dato por algún período 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

-


¿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? ¿Existe un límite 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 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 ag ua o el robo?

3.4.9 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? ¿El mantenimiento corregirá los errores, o incluirá también el mejoramiento del sistema? ¿Qué medidas de eficiencia se aplicarán al uso de recursos y al tiempo de respuesta? ¿Cuán fácil debe ser mover el sistema de una ubicación a otra o de un tipo de computadora a otro?

FIS

11

Universidad


Ilustración 3 Tipos de requerimientos

3.5 CARACTERÍSTICAS DE REQUERIMIENTO Los requerimientos permiten que los desarrolladores expliquen cómo han entendido lo que el cliente pretende del sistema. También, indican a los diseñadores qué funcionalidad y que características va a tener el sistema resultante. Y además, 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 características de los requerimientos mencionados en el estándar 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 simultáneamente.

3.5.3 DEBE ESTAR COMPLETO 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.

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


3.5.6 DEBE SER RASTREABLE ¿Se puede rastrear cada función del sistema hasta el conjunto de requerimientos que la establece?

Ilustración 4 Caracteristicas de requerimientos

Es un documento que debe escribirse en términos 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 definición de los requerimientos es importante conseguir que los requerimientos sean claramente definidos para minimizar la ambigüedad de los requerimientos, para esto es importante tener en cuenta lo siguiente: 



Definir los requerimientos teniendo en cuenta la información 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




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

4.1 CLASIFICACIÓN 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 r ealiza 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). •

•

•

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 g eneral. Cuando se expresan como requerimiento del sistema describen con detalle la función 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 específicas que entrega el sistema, sino a las propiedades emergentes de éste, como la fiabilidad, la respuesta en el t iempo y la capacidad de almacenamiento. Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. 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).

4.1.3 REQUERIMIENTO DE DOMINIO Estos son requerimientos que provienen del dominio de aplicación del sistema y reflejan características y restricciones de ese dominio. Estos pueden ser funcionales o no funcionales.

FIS

14

Universidad


Ilustración 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 simultáneamente.

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 técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema.

FIS

15

Universidad


Ilustración 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 especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software. Son descripciones más detalladas de los requerimientos del usuario. Sirven como base para definir el contrato de la especificación del sistema y, por lo tanto, debe ser una especificación completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseño del sistema.

Ilustración 7 Verificacion de requerimientos de sistemas

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.

FIS

16

Universidad


6.1 TÉCNICAS DE VERIFICACIÓN DEL REQUERIMIENTO 6.1.1 AD – HOC Es una forma rápida de obtener otra perspectiva para encontrar problemas que el autor del proyecto no puede ver por sí mismo. La técnica no sigue un proceso establecido y sus resultados no se registran de una manera predefinida.

6.1.2 REVISIÓN DE PARES(PEER DESKCHECK) Involucra a una sola persona (distinta al autor del proyecto) quien recibe una copia del proyecto para su revisión. El revisor puede utilizar checklists u otras técnicas de análisis que incrementen la efectividad del proceso. La llamada revisión por pares es un conocido método de control de la calidad de los artículos y productos.

Ilustración 8 Esquema de revision de pares

6.1.3 REVISIÓN DE PARES MULTIPLE(PASSAROUND) Es una revisión de pares realizada concurrentemente. El proyecto a revisar es distribuido entre 3 y 15 personas quiénes revisan y dan su devolución 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


Ilustración 9 Revision de Passaround

6.1.4 PROGRAMACIÓN DE A PARES(PAIR PROGRAMMING) Esta técnica consiste en dos desarrolladores trabajando en un mismo producto simultáneamente, 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.

Ilustración 10 Recision Pair Programming

6.1.5 COMPROBACIÓN DE ESCRITORIO 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.    

FIS

18

Universidad

  


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.

Ilustración 11 Algoritmo para la revision de escritorio

6.1.6 PRESENTACIÓN (WALKTHROUGH) 6.1.6.1 DEFINICIÓN 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.

FIS

19

Universidad


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 DURACIÓN DE UN WALKTHROUGH 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. 6.1.6.4 FASES 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.

Ilustración 12 Presentacion d walkthrougth

6.1.7 REVISIÓN EN EQUIPO Comienza con una planificación seguida de una de preparación donde los participantes reciben el material necesario varios días antes. Luego el equipo (con roles definidos) se reúne para discutir los resultados donde participan el líder de revisión (puede ser el propio autor del artefacto revisado), registrador y moderador (no puede ser del propio autor). La última etapa es la corrección de los defectos encontrados. Existe un cierto paralelismo entre la Revisión en equipo de Wiegers y la Revisión técnica planteada en el estándar IEEE 1028-2008. Ambos métodos tienen en común la idea de un rol de líder de revisión o moderador y de un registrador. También ambas técnicas incluyen una etapa de reunión y la necesidad de una etapa de preparación previa a la misma.

FIS

20

Universidad


Ilustración 13 Revisiones en equipo

6.1.8 INSPECCIONES 6.1.8.1 DEFINICIÓN 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. 6.1.8.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 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". 6.1.8.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. FIS

21

Universidad


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.

Ilustración 14 Inspecciones de pruebas.

6.1.8.4 DIFERENCIAS ENTRE INSPECCIONES Y WALKTHROUGH

Ilustración 15 Puntos comparativos de inspecciones vs. Walkthrougth

FIS

22

Universidad


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. Dentro de los aspectos más importantes que se encontraron al estudiar el tema son: 

Que con el análisis requerimientos están sujetos a muchas mejoras para el desarrollo del software, dando satisfacción al cliente al obtener las características del software deseadas.



Las actividades en el análisis de requerimientos dentro de toda empresa se llevan a cabo a través de diferentes herramientas y estrategias: los enfoques que se orienten a solucionar problemáticas 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 construcción de un software debemos cubrir las necesidades de análisis de riesgos asociados a los requerimientos en etapas tempranas, de los proyectos de software en forma estructurada: cada actividad del análisis de requerimientos consiste de una serie de pasos organizados y bien definidos.



Toda técnica 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 análisis de requerimientos.



La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.), y el modelo se orienta mejorar estos aspectos.

FIS

23

Universidad

-

-


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 síntomas de defectos. Al generar casos de prueba, se deben incluir tanto datos de entrada válidos como no válidos. 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, prácticamente, 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 número de defectos ya descubierto. Las pruebas son una tarea tanto o más creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.

FIS

24

Universidad


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

Verificacion y Validacion de Requerimientos

Recommend Documents