Organizar los requisitos en un plan de producto

Después de analizar detenidamente los requisitos del cliente para poder determinar las características de un producto, es preciso elaborar un plan para implementar el producto. En el caso de un producto existente, hay que identificar la funcionalidad que falta y definir un plan para realizar las modificaciones. Sin embargo, los requisitos no conducen automáticamente al plan.

En este tema, se describe un método para elaborar un plan a partir de un conjunto de requisitos. Se trata simplemente de uno de los diversos métodos que se pueden usar en Visual Studio, por lo que cada uno tendrá que ajustarlo a sus necesidades.

Puede utilizar el trabajo pendiente y los trabajos pendientes de cartera para definir y asignar requisitos y características.

Requisitos y características

En este método, hay dos tipos de requisitos: requisitos del cliente y características. Los requisitos del cliente representan lo que se obtiene tras analizar lo que el cliente espera del producto. Las características son los elementos del plan de producto, que corresponden a pequeños subconjuntos de los requisitos del cliente. Cada característica puede incluir partes de los requisitos del cliente que son fruto de la experiencia de los usuarios y que proceden de diferentes áreas funcionales.

Requisitos del cliente

• Los requisitos del cliente se determinan hablando con los posibles usuarios y las demás partes interesadas.

• Para poder analizar estos requisitos, normalmente se crean guiones gráficos y modelos y se desglosan los escenarios en pasos más pequeños que forman un árbol. Los elementos de los modelos, como casos de uso y actividades, se pueden vincular a los elementos de trabajo de los escenarios.

• Hay dos tipos de requisitos del cliente:

  • Los escenarios, también denominados casos de uso, representan secuencias de interacciones entre los usuarios y el producto para lograr determinados objetivos. Un escenario de ejemplo podría denominarse "El usuario compra un libro".

  • Entre los requisitos referentes a la calidad de servicio se encuentran el rendimiento, la seguridad, la facilidad de uso y otros criterios.

• Estos requisitos se pueden representar como elementos de trabajo de requisito, con el campo Tipo de requisito establecido en Escenario o Calidad de servicio. Para obtener más información, vea el tema sobre cómo Desarrollar requisitos.

• Estos elementos de trabajo de requisito deben vincularse a las pruebas del sistema para garantizar que se han sometido a prueba todos los requisitos. Vea el tema sobre cómo Planear pruebas manuales con Team Web Access.

• Vea el trabajo pendiente o abra la consulta Requisitos del cliente para mostrar estos elementos de trabajo de requisito.

• Utilice el informe Informe Progreso de los requisitos (CMMI) para supervisar qué requisitos se han cumplido.

Características

• Una característica es un elemento de un plan de producto que representa un grupo de tareas. En la fase de planeación del producto, los representantes del equipo de desarrollo y de las partes interesadas asignan las características a las iteraciones. Para obtener más información, vea el tema sobre cómo Planear un proyecto (CMMI).

• Las características se introducen como elementos de trabajo de requisito con el campo Tipo de requisito establecido en Característica.

• El título de la característica indica lo que los usuarios podrán hacer con el producto con respecto a lo que les permitía hacer en las iteraciones anteriores. No hay ningún elemento, o muy pocos elementos, en el plan que no aporte ningún valor nuevo al usuario.

  Por ejemplo, esta secuencia de características podría constituir un plan de implementación:

  • "Un comprador puede elegir un libro de una lista y agregarlo a una lista de deseos."

  • "En la lista de libros, se muestran los precios. En la lista de deseos, se muestra el precio total."

  • "Los proveedores pueden adjuntar etiquetas a los libros. Los compradores pueden filtrar la lista de libros por etiqueta."

  Observe que ninguna característica toca solamente un paso en la experiencia del usuario, y ninguna característica implica solamente una parte de la arquitectura del producto. Cuando se implementan las características, se revisan varias funciones y se les agrega un nuevo valor para el usuario.

• Una característica se asigna a una iteración durante la fase de planeación del producto. Todas las tareas correspondientes a una característica deben asignarse a la misma iteración.

• Una característica describe un cumplimiento parcial de los requisitos del cliente. Es un subconjunto de los requisitos del cliente y podría implementar cada uno de dichos requisitos hasta cierto punto.

• Cada característica puede vincularse a uno o varios casos de prueba que someten a prueba la parte de los requisitos que la característica representa. Estos casos de prueba son un subconjunto de las pruebas del sistema que están vinculadas a los requisitos del cliente.

• El estado de la característica no debe marcarse como Completado hasta que se definan y se realicen correctamente las correspondientes pruebas.

• Cada característica es un grupo de tareas de desarrollo y de prueba. Es la raíz de un árbol de tareas. Las tareas de desarrollo implementan los requisitos parciales descritos por la característica. Las tareas de prueba diseñan y ejecutan los casos de prueba adecuados.

• Se utiliza la consulta Requisitos del producto para mostrar las características.

Buscar características

La separación de los requisitos en características incrementales es una tarea creativa en la que se deben implicar los desarrolladores, analistas y partes interesadas. Una característica define una parte de la funcionalidad del producto que se puede implementar de manera independiente de las demás funciones. Por consiguiente, un conjunto factible de definiciones de característica y su inclusión ordenada en un plan dependen en parte de la arquitectura del sistema.

Por esta razón, es preciso que la planeación y el diseño inicial del producto se lleven a cabo en paralelo, sobre todo en la iteración 0, donde se elabora la mayor parte del plan.

Desglose de los escenarios

Para poder organizar los requisitos en características, se recomienda desglosar los escenarios en pasos más pequeños.

En muchas ocasiones, los guiones gráficos ayudan a realizar esta actividad. Un guion gráfico es una secuencia de imágenes que ilustran el escenario. Los diagramas de actividades de UML resultan útiles para mostrar rutas alternativas; los diagramas de secuencia de UML pueden ayudar a tratar las interacciones entre las diversas partes implicadas. Después de utilizar estas herramientas para analizar un escenario, se pueden registrar los escenarios desglosados en Team Explorer. De este modo, se vinculan los casos de prueba a los escenarios, por lo que se garantiza el cumplimiento de los requisitos. Para obtener más información, vea Diagramas de actividades UML: Instrucciones y Diagramas de secuencia de UML: Instrucciones.

Características: requisitos que se cumplen en cada iteración

Una característica es un requisito que resume lo que los usuarios pueden hacer al término de cada iteración. Se puede crear más de una característica para cada iteración. Las características se representan como elementos de trabajo de requisito con el campo Tipo de requisito establecido en Característica.

Las asignaciones de los escenarios a los elementos de trabajo ayudan a definir las características. El siguiente plan de características de ejemplo se deriva de las asignaciones de los escenarios a las iteraciones que se han realizado en la sección anterior:

• Iteración 1

  • El cliente elige platos de un menú, los agrega a un pedido y agrega una dirección de entrega.

• Iteración 2

  • El cliente muestra primero una lista de restaurantes y, a continuación, elige uno.

  • Cuando el cliente completa un pedido, dicho pedido aparece en la pantalla del restaurante elegido.

  • En el pedido, se muestran los precios de los platos así como el precio total.

• Iteración 3

  • El restaurante marca el pedido como "Listo" una vez enviada la comida preparada. Se registra la comida en el restaurante.

  • Cada restaurante puede escribir y actualizar su menú.

  • El cliente puede examinar el menú de cada restaurante antes de realizar una selección.

• Iteración 4

  • El cliente escribe los datos de pago cuando completa el pedido. Se pasa el cargo a la tarjeta del cliente cuando el restaurante marca el pedido como Listo.

  • Se paga al restaurante por los pedidos marcados como Listo.

• Iteración 5

  • Los restaurantes pueden definir su área de entrega. El cliente escribe su código postal cuando inicia sesión. En el sitio web se muestran únicamente los restaurantes que pueden realizar entregas en el área local.

Escenarios parcialmente implementados

Desglosar los escenarios en pasos más pequeños ayuda a separar los pasos que se pueden implementar antes de los pasos que se pueden implementar más adelante.

Sin embargo, a veces también permite separar otros aspectos de los escenarios. En este ejemplo, el equipo podría implementar una versión básica de la experiencia del usuario en las primeras iteraciones y mejorarla posteriormente. Por lo tanto, se podría agregar la siguiente característica:

• Iteración 6: el restaurante puede elegir la combinación de colores y la fuente de su menú y puede cargar su logotipo así como imágenes de las comidas.

Este tipo de característica no es un resultado directo del desglose en pasos sino que suele surgir a raíz de las conversaciones que se mantienen sobre los guiones gráficos. Las características relacionadas con la experiencia del usuario se prestan especialmente para las iteraciones posteriores.

Escribir e inspeccionar las características

Cree elementos de trabajo con el tipo de elemento de trabajo del requisito y establezca el campo Tipo de requisito en Característica. Escriba una breve descripción en el campo Título de la característica.

Vincular las características a los requisitos

Las características se pueden vincular a los requisitos de las siguientes maneras:

• Vinculando los elementos de trabajo de característica a los requisitos de escenario hoja de sus iteraciones. Es preciso vincularlos mediante los vínculos Elementos relacionados porque los escenarios hoja ya tienen elementos primarios.

• Vinculando los elementos de trabajo de caso de prueba a los escenarios y los requisitos en materia de calidad de servicio que someten a prueba. Las características deben vincularse al subconjunto de los casos de prueba que deben superarse una vez desarrollada la característica. De esta manera, los casos de prueba actúan como vínculo entre las características y los requisitos del cliente.

Características de calidad de servicio

Los requisitos de calidad de servicio suelen ser ubicuos con respecto al diseño del software. Por ejemplo, los requisitos de seguridad no suelen estar relacionados con una tarea de desarrollo concreta.

No obstante, para cada requisito de calidad de servicio, se debe crear un elemento de trabajo de característica cuyos elementos secundarios sean principalmente tareas de prueba que garantizan el cumplimiento de un criterio de calidad de servicio. Estos elementos de trabajo se denominan características de calidad de servicio.

Algunas de estas características pueden tener tareas de desarrollo. Por ejemplo, en una iteración temprana, se podrá implementar una versión del sistema que sea capaz de administrar solo unos pocos usuarios, como una prueba de concepto. En una iteración posterior, se podrá agregar una característica que especifique la capacidad de destino indicada en los requisitos del cliente.

Planeación del producto

Antes de iniciar cada iteración, se debe celebrar una reunión para revisar el plan del producto. En la primera reunión para planear el producto, se crea el plan y, en las reuniones subsiguientes, se revisa dicho plan en función de las iteraciones anteriores. Para obtener más información, vea el tema sobre cómo Planear un proyecto (CMMI).

Cuando se revisa el plan del producto, se debe hablar de las características con las partes interesadas y, si es necesario, cambiar su prioridad y organizarlas en iteraciones diferentes. A la reunión deben asistir las partes interesadas y los representantes del equipo de desarrollo.

En la reunión, se debe abordar la secuencia en la que se van a desarrollar las características. Para ello, se puede proyectar o compartir la pantalla de la vista en Office Excel de la consulta Requisitos del producto y ordenar las características por iteración.

También se puede optar por colocar las características en una secuencia concreta y, a continuación, considerar cuánto se puede hacer en cada iteración. Por ejemplo, los desarrolladores podrían hablar de la posibilidad de mover el paso "El cliente puede mostrar los precios" de la iteración 2 a la iteración 3, sin moverlo en la secuencia. Para colocar los elementos en una secuencia, se debe agregar a la hoja de cálculo una columna adicional denominada Rango e insertar enteros que denoten la secuencia. A continuación, se debe ordenar la hoja de cálculo por esta columna. Los rangos no se almacenarán en Team Foundation Server, pero se puede guardar la hoja de cálculo. Cuando se vuelve a abrir la hoja de cálculo, se debe hacer clic en cualquier celda de la tabla de elementos de trabajo y, a continuación, hacer clic en la opción Actualizar de la pestaña Equipo.

En la fase de planeación del producto, se consideran las prioridades de las características y los costos de desarrollo. Las prioridades las indican las partes interesadas y los desarrolladores aportan algunos datos sobre los riesgos. Las estimaciones de los costos las aportan los desarrolladores. Para hacerse una idea exacta de los costos, el equipo de desarrollo ya debe haber trabajado sobre la arquitectura del producto y seguramente necesitará la información que aportan las primeras iteraciones. Por esta razón, las estimaciones de los costos deben ajustarse cada vez que se revisa el plan del producto.

Planeación de las iteraciones

Después de revisar el plan del producto, se debe planear la iteración. El plan del producto determina las características que se entregarán al término de la iteración. El plan de iteración determina el trabajo que el equipo llevará a cabo para implementar y probar las características.

Las siguientes actividades forman parte de la planeación de las iteraciones:

• Crear tareas para el desarrollo y las pruebas, y vincularlas como elementos secundarios a los requisitos en materia de características.

• Crear casos de prueba para los aspectos de los requisitos del cliente que deben desarrollarse en cada característica. Los casos de prueba deben vincularse a los requisitos del cliente para que se pueda supervisar el grado en que se cumplen dichos requisitos.

Los casos de prueba también se pueden vincular a las características para que se pueda realizar un seguimiento de la correspondencia entre las características y los requisitos. Las características no deben marcarse como completadas hasta que se ejecuten correctamente los casos de prueba vinculados.

Para obtener más información, vea Planear una iteración (CMMI).