Validación de Requisitos

1. Validación de requisitos

1.1. Validación de los requisitos que comprenden las actividades

1.1.1. Obtención una primera versión de la documentación de requisitos

1.1.1.1. captura de requisios

1.1.1.2. Requisitos Informales

1.1.1.2.1. Análisis y negociación de requisitos

1.1.1.3. requisitos negociados

1.1.2. Borrador documentos de requisitos

1.1.2.1. Documentación de requisitos

1.1.3. Documentos de requisitos e informe de validación

1.1.3.1. Validación de requisitos

1.1.3.1.1. Punto de decision

1.1.4. Borrador de documento de requisistos

1.1.4.1. Documentación de requisitos

1.1.5. Documentento de requisitos e informes de validación

1.1.5.1. Validación de requisitos

1.2. Concepto

1.2.1. Proceso tiene por la finalidad comprobar que los requisitos del software, ya que posee atributos de calidad:

1.2.1.1. Concistentes

1.2.1.2. Competos

1.2.1.3. Presisos

1.2.1.4. Realista

1.2.1.5. Verificables y define lo que el usuario desea del producto final

1.2.2. La validación tiene como entrada del documento de requisito, estándares y relacionados y el conocimiento de las organización como salida se obtiene la lista de problemas una lista de acción recomendadas

1.2.2.1. Entradas

1.2.2.1.1. Documentos de requisitos

1.2.2.1.2. Estándares

1.2.2.1.3. Conocimiento de la organización

1.2.2.2. Proceso

1.2.2.2.1. Validación de requisitos

1.2.2.3. Salida

1.2.2.3.1. Lista de problemas

1.2.2.3.2. Lista de acción

1.3. Métodos

1.3.1. Revisión de requisitos

1.3.1.1. Revisión de requisitos, en reuniones de equipos de analistas, localizan error en el documento de especificación

1.3.2. Prototipo

1.3.2.1. Consiste en construir maquetas del futuro sistema de software, la maqueta sera evaluado por el cliente y usuarios para comprobar su corrección de completitud

1.3.3. Generación de casos de prueba (test de requisitos)

1.3.3.1. Verificabilidad de los requisitos de la definición de casos de prueba de los requisitos

1.4. Otras técnicas alternativas

1.4.1. Creación de manuales de usuario

1.4.1.1. Cociste en la verificación si la especificación de requisitos para preparar un manual de usuario del sistema

1.4.2. Animación y validación de modelos o especificación formales

1.4.2.1. Cuando los requisitos se han utilizado modelos durante el análisis o métodos de especificación formales durante la documentación, esto consiste en la animación tanto de modelos como de especificaciones formales, con el objetivo de verificar que el funcionamiento del sistema

2. Revisión de requisitos

2.1. Concepto

2.1.1. La revisión de requisitos es uno de los mejores métodos de validación de requisitos la revisión de requisitos permite

2.1.1.1. Descubrir una gran cantidad de defectos en los requisitos

2.1.1.2. Reducir los costos de desarrollo entre 25% y un 30%

2.1.1.3. Reducir el tiempo de pruebas entre un 50% y un 90%

2.1.2. Distribuir los documentos a revisar

2.1.2.1. El único documento a revisar será el documento de especificación, también es necesario remitir a los participantes en la revisión ya que ayuden a comprender adecuadamente el documento de especificación

2.1.3. La revisión de requisitos consisten en una o varias reuniones planificada, ya que posee los atributos de calidad deseados, reunión son llevadas a cabo por el analista encargado del proyecto y un conjunto de colegas

2.1.4. El resultado final de las reuniones de revisión es un documento que contiene la lista de defectos localizados y una lista de acción recomendadas

2.2. Procedimientos compuesto por seis paso:

2.2.1. Preparar el plan de la revisión

2.2.1.1. La tarea a realizar (esto es, las que se indican a continuación)

2.2.1.1.1. la planificación temporal

2.2.1.1.2. personas que participarán en la revisión

2.2.2. Preparar la reunión

2.2.2.1. Para el analista promotor de la reunión, esta es la tarea es fundamentalmente logística, básicamente consiste en reservar una sala donde realizar la revisión, solicitar los materiales que sean necesario (desde papel, lápiz a cañones de proyección), preparar justificante el tiempo empleado por el personal

2.2.2.2. Para los analistas participantes, la preparación de la reunión es, probablemente, las mas importante de las tareas de revisión. Durante esta tarea se debe leer cuidadosamente los documentos recibidos y anotar todas aquellos defectos (o cosas que parezcan defectos) con la finalidad de ponerlos de manifiesto durante la reunión posterior

2.2.3. Realizar la reunión de revisión

2.2.3.1. El formato de esta reunión diversos: puede oscilar desde una total falta de control, grupos muy formalizados sujetos a protocolos de actuación

2.2.4. Identificar los defectos y acciones a realizar.

2.2.4.1. la lista de defectos y acciones recomendadas es el documentos final obtenidos en las revisiones de requisitos

2.2.5. Realizar las correcciones que sean precisas a los documentos revisados

2.2.5.1. El analistas promotor de la reunión (esto es, el analista encargado del documento de especificación) debe evaluar estima conveniente, las acciones recomendadas en las reunión de revisión

2.3. Concepto

2.3.1. Preparación de la reunión de revisión, como la reunión en si misma se utiliza checklist de validación. Dos checklist de validación se adjuntan, dichos checklist, al igual que lo que ocurría durante el análisis consisten en una serie de preguntas a realizar

2.3.2. Cada organización desarrolle y mantenga checklists propios y adaptados, las experiencias muestran que los checklists adaptados son los proporcionan siempre los mejores resultados no disponer de un checklists propios utilizarse un cheklist mas o menos general

2.3.3. las pre-revisiones permiten habitualmente identificar errores sencillos (por ejemplo, desviaciones de los éstandares , omisiones etc), que pueden detectarse fácilemente sin necesitar de un procesos tan largo como son las revisiones

2.3.3.1. En consecuencia, las pre-revisiones son un buen medio de:

2.3.3.1.1. Permitir que los participantes se concentren en los defectos difíciles de identificar:

2.3.3.1.2. Disminuir el número de errores y acción a realizar

3. Prototipos

3.1. Concepto

3.1.1. Los prototipos son métodos de validación ampliamente utilizado en muchas disciplinas: el prototipo consiste en la creación de una maqueta o versión del producto final, los objetivos de los prototipos varían en función de la disciplina. Varios tipos de prototipos los cuales permiten la realización de un tipo determinado de pruebas y con un determinado nivel de realismo

3.1.1.1. Mock-ups

3.1.1.1.1. se trata de pantallas, típicamente dibujadas a mano en papel, que se representa a un aspecto concreto del sistema. El soporte que proporcionan a la validación es muy limitado con las excepción, quizás, de aclarar el interfaz gráfico desado en casos complejos

3.1.1.2. Storyboards

3.1.1.2.1. Son una evolución de los mock-ups, ya que además del interfaz, se muestra la secuencia de acciones, o escenarios, que se debe realizar con el programa. Existen varias alternativas para crear storyboards

3.1.1.3. Maquetas

3.1.1.3.1. una maqueta es una versión simplificada del sistema software deseados. Típicamente, una maqueta representa únicamente el interfaz del sistema y, opcionalmente, las conexiones entre pantallas mediante las utilización del elemento activo como los botones. Si fuera necesario mayor finalidad, podrían codificarse parte del sistema, de tal modo que además de interfaz, el software pudiera ofrecer algunos resultados reales. Ellos es lo que se conoce como "Prototipos funcionales". Las maquetas acostumbran a realizarse mediante programas gráficas de diseño, tales como Visual Basic o PowerBuilder, por citar únicamente.

3.2. ¿Qué tipo de prototipos se debe construir?

3.2.1. Los recurso y tiempo disponible

3.2.1.1. Cuanto más limitados sean esto recursos, más conveniente es construir prototipos sencillos como los mock-ups o storyboards

3.2.2. La fidelidad deseada

3.2.2.1. este es un problema de índole psicológico. Si el usuario experimenta rechazo por el prototipo, al no ser capaz de entender que el prototipo es sólo una versión simplificada del producto fina, se debe tener a construir prototipos más complejos. Tampoco se debe olvidar que el analista deberá suplir al usuario la información que el prototipo no puede suministrar (mensaje de error, resultado de los cálculos etc). Ellos es también un argumentos para preferir prototipos más complejos

3.3. Comentario

3.3.1. Construir e prototipo es únicamente una parte, y quizás la más sencillas, de la tarea de validación

3.3.2. Ampliar el prototipo

3.3.2.1. Seleccionar quién evaluará el prototipo

3.3.2.2. Desarrollar escenarios de validación

3.3.2.3. Ejecutar escenarios

3.3.2.4. Documentar problemas

3.3.3. Tareas indicadas

3.3.3.1. seleccionar quién evaluará el prototipo

3.3.3.1.1. para que la evaluación del prototipo sea lo mas efectiva posible, debe seleccionarse adecuadamente los usuarios que participarán.

3.3.3.1.2. Siempre que sea posible, debe seleccionarse un conjunto de usuarios representativos de los distintos perfiles, de tal modo que sea posible validar el software en todo sus modos de utilizacion

3.3.3.2. Desarrollar escenarios de validación

3.3.3.2.1. pueden identificarse directamente a partir del detalle de la especificación. Otra alternativa para generar los escenarios es intentar confeccionar un manual de usuario para el sistema

3.3.3.3. Ejecutar los escenarios

3.3.3.3.1. Esta tarea consiste en que el usuario realice los escenarios previstos, dependiendo del tipo de prototipos utulizados (mock-up, storyboard, maquetas)

3.3.3.4. Documentar los problemas

3.3.3.4.1. En la confección de la lista de problemas encontrados, el mismo que valida el prototipo con los usuarios, no es usual confeccionar una lista de problemas recomendados