Manejo de requerimientos.

Validación de requisitos Este proceso generalmente se realiza una vez obtenida una primera versión de la documentación de requisitos.

La validación en el proceso de los requisitos.

¿Aburridos? Dos estudiantes de ingeniería estaban caminando por el ITSAO cuando uno de ellos dijo -¿de donde diablos sacaste esa magnifica bicicleta? El segundo contesto: -bueno yo estaba caminando por ahí ayer, pensando en mis Trabajos, cuando una hermosa chica apareció sobre esta bicicleta. Tiro la Bicicleta al suelo, se saco toda su ropa y dijo -”toma lo que quieras” El segundo ingeniero cabeceo afirmativamente : -buena elección!! La ropa probablemente no te hubiera entrado!!

Validación de requisitos Tiene por finalidad comprobar que los requisitos del software poseen todos los atributos de calidad enunciados a continuación. Consistentes, Completos, Precisos, Realistas, Verificables Estas actividades pretenden evitar los altos costos que significaría el tener que corregir una vez avanzado el desarrollo

La validación en el proceso de requisitos

Métodos mas habituales. Revisión de requisitos: consisten en reuniones donde el equipo de analistas intentan localizar los errores en el documentos de la especificación. Prototipado: consiste en construir una maqueta del futuro sistema a partir de requisitos recogidos en la especificación. (evaluada por el cliente y usuarios) Generación de casos de prueba: consiste en la definición de casos de prueba que permitan verificar el complimiento de los requisitos funcionales.

Revisión de los requisitos Consisten en una o varias reuniones, planificadas donde se intenta confirmar que los requisitos poseen los atributos de calidad deseados. El resultado final de las reuniones de revisión es un documento que contiene la lista de defectos localizados y una lista de acciones recomendadas.

Revisión de los requisitos La revisión de los requisitos es uno de los mejores métodos de validación de requisitos ya que permiten Descubrir una gran cantidad de defectos en los requisitos Reducir los costos de desarrollo entre un 20% y un 30% Reducir el tiempo de pruebas entre un 50% y un 90%

Dichas reuniones se realizan en 6 pasos Preparar el plan de revisión (las tareas a realizar, planificación temporal y las personas participantes) Distribuir el documento a revisar (generalmente el único documento a revisar será el documento de especificación ) Preparar la reunión generalmente es muy diferente para quien la realice Analista promotor de la reunión –logística Analistas - revisión deben leer cuidadosamente los documentos recibidos y anotar aquellos defectos con la finalidad de ponerlos en manifiesto durante la reunión

Realizar la reunión de revisión Realizar la reunión de revisión. El formato de la reunión puede ser muy diverso, puede ser una total falta de control o puede ser muy formalizado y sujeto a protocolos de actuación. Identificar los defectos y acciones a realizar. La lista de defectos y acciones recomendadas es el documento final obtenido en las revisiones de requisitos Realizar correcciones que sean precisas: el promotor de la reunión debe evaluar y llevar a acabo las acciones recomendadas que han surgido en la reunión. Informar de las modificaciones realizadas: una vez que los defectos han sido subsanados, se envía un informe de tareas realizadas y una copia corregida de los documentos de especificación a los participantes de la reunión.

Un posible formato para la lista de errores y acciones recomendadas

El informático La mujer de un programador informático le deja una nota en la Nevera: -ve al mercado y compra una barra de pan. Si tienen huevos, toma una docena Cuando la mujer regreso a casa su marido había comprado 12 barras De pan .

Prototipos Consiste en la creación de una maqueta o versión del producto, existen varios tipos de prototipos cada uno de los cuales permiten la realización de un tipo determinado de pruebas, los prototipos mas comunes son : Mock-up: se trata de pantallas, dibujadas típicamente a mano, que representan un aspecto concreto del sistema (el soporte que proporciona a la validación es muy limitado) Storyboards: son una evolución de los anteriores ya que además de la interfaz, se muestra la secuencia de acciones, o escenarios, que se deben realizar con el programa Maquetas- una maqueta representa únicamente la interfaz del sistema y, opcionalmente las conexiones entre pantallas mediante la utilización de elementos activos como los botones.

Que tipos de prototipos de deben construir?

Generación de casos de prueba. Son artefactos bien definidos en el contexto de la prueba de software, un caso de prueba es la descripción de una acción bien definida que se debe realizar con el software (que están perfectamente descritos tanto los datos de entrada como las tareas a realizar y los resultados esperados)

Por ejemplo Dado el requisito X. el sistema deberá generar facturas. Este requisito no esta bien definido No se indica como se debe generar la facturas (una única factura, una factura por cliente, una factura por pedido) No se indica que se factura(un pedido especifico, los pedidos entre fechas, etc.)

Los defectos anteriores no están presentes en la siguiente definición. X. el sistema deberá generar facturas X.1 se generara una factura por cliente, esta factura incluirá todos los pedidos no facturados del cliente en cuestión X2. el formato de la factura será el especificado en el anexo 1

1. Se introducirán en el sistema los pedidos A, B, C, ... Estos pedidos A, B y C se tratarían de pedidos bien definidos, indicando todos los datos necesarios (cantidades, productos, etc.) 2. Se invocará la función de generar factura 3. Se deberán obtener las facturas X, Y, ... Estas facturas X e Y se tratarían, de nuevo, de facturas bien definidas Para el caso de pruebas

Un profesor de lógica La mujer de un profesor de lógica acaba de dar a luz. El padre Sostiene el bebe en brazos y la madre le pregunta -es niño o niña El padre responde -si